Greetings all;
okular seems to run ok most of the time, but when run from the cli logs this:
gene@coyote:~/linuxcnc/nc_files$ okular okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x8cef5b0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
This is my fav pdf reader, and I get 3 to 4 weeks uptime before something goes to pot and I need to reboot this old wheezy install.
Connected? IDK, maybe... I have a stretch testing image from the LCNC folks that I put on an old Dell out in the garage as the sacrificial goat, and its running quite well so far, so this wheezy may get retired finally. Sometime in the next week or two if the creek doesn't get too high. :)
Cheers, Gene Heskett
On Tue, 30 Apr 2019 09:27:25 -0400 Gene Heskett gheskett@shentel.net wrote:
okular seems to run ok most of the time, but when run from the cli logs this:
gene@coyote:~/linuxcnc/nc_files$ okular okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x8cef5b0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
This is my fav pdf reader, and I get 3 to 4 weeks uptime before something goes to pot and I need to reboot this old wheezy install.
Connected? IDK, maybe... I have a stretch testing image from the LCNC folks that I put on an old Dell out in the garage as the sacrificial goat, and its running quite well so far, so this wheezy may get retired finally. Sometime in the next week or two if the creek doesn't get too high. :)
okular is kde5/qt5, so it's a moving target. A quick search suggests that this is a known bug (possibly two separate bugs), it's been fixed, and you're running a very old version.
So, yeah, you might want to update to something a little more modern.
E. Liddell
On Tuesday 30 April 2019 17:27:42 E. Liddell wrote:
On Tue, 30 Apr 2019 09:27:25 -0400
Gene Heskett gheskett@shentel.net wrote:
okular seems to run ok most of the time, but when run from the cli logs this:
gene@coyote:~/linuxcnc/nc_files$ okular okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x8cef5b0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
This is my fav pdf reader, and I get 3 to 4 weeks uptime before something goes to pot and I need to reboot this old wheezy install.
Connected? IDK, maybe... I have a stretch testing image from the LCNC folks that I put on an old Dell out in the garage as the sacrificial goat, and its running quite well so far, so this wheezy may get retired finally. Sometime in the next week or two if the creek doesn't get too high. :)
okular is kde5/qt5, so it's a moving target. A quick search suggests that this is a known bug (possibly two separate bugs), it's been fixed, and you're running a very old version.
So, yeah, you might want to update to something a little more modern.
Huh? I thought it was part of the kde fork?
If not, then what am I supposed to be using?
E. Liddell
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Cheers, Gene Heskett
On Tuesday 30 April 2019 15:06:22 Gene Heskett wrote:
On Tuesday 30 April 2019 17:27:42 E. Liddell wrote:
On Tue, 30 Apr 2019 09:27:25 -0400
Gene Heskett gheskett@shentel.net wrote:
okular seems to run ok most of the time, but when run from the cli logs this:
gene@coyote:~/linuxcnc/nc_files$ okular okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x8cef5b0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
This is my fav pdf reader, and I get 3 to 4 weeks uptime before something goes to pot and I need to reboot this old wheezy install.
Connected? IDK, maybe... I have a stretch testing image from the LCNC folks that I put on an old Dell out in the garage as the sacrificial goat, and its running quite well so far, so this wheezy may get retired finally. Sometime in the next week or two if the creek doesn't get too high. :)
okular is kde5/qt5, so it's a moving target. A quick search suggests that this is a known bug (possibly two separate bugs), it's been fixed, and you're running a very old version.
So, yeah, you might want to update to something a little more modern.
Huh? I thought it was part of the kde fork?
If not, then what am I supposed to be using?
E. Liddell
Cheers, Gene Heskett
Comes with new KDE, etc., not sure what else. It's not TDE.
Bill
On Tue, 30 Apr 2019 18:06:22 -0400 Gene Heskett gheskett@shentel.net wrote:
On Tuesday 30 April 2019 17:27:42 E. Liddell wrote:
On Tue, 30 Apr 2019 09:27:25 -0400
Gene Heskett gheskett@shentel.net wrote:
okular seems to run ok most of the time, but when run from the cli logs this:
gene@coyote:~/linuxcnc/nc_files$ okular okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x8cef5b0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
This is my fav pdf reader, and I get 3 to 4 weeks uptime before something goes to pot and I need to reboot this old wheezy install.
Connected? IDK, maybe... I have a stretch testing image from the LCNC folks that I put on an old Dell out in the garage as the sacrificial goat, and its running quite well so far, so this wheezy may get retired finally. Sometime in the next week or two if the creek doesn't get too high. :)
okular is kde5/qt5, so it's a moving target. A quick search suggests that this is a known bug (possibly two separate bugs), it's been fixed, and you're running a very old version.
So, yeah, you might want to update to something a little more modern.
Huh? I thought it was part of the kde fork?
Um, no. Note that your error messages above refer to kdeui and kdelibs, not tdeui and tdelibs, even though these modules were renamed in TDE.
If not, then what am I supposed to be using?
The default TDE program for viewing PDFs is kpdf, in tdegraphics. That doesn't mean you have to use it if it doesn't suit your needs, of course.
E. Liddell
On Tuesday 30 April 2019 20:34:09 E. Liddell wrote:
On Tue, 30 Apr 2019 18:06:22 -0400
Gene Heskett gheskett@shentel.net wrote:
On Tuesday 30 April 2019 17:27:42 E. Liddell wrote:
On Tue, 30 Apr 2019 09:27:25 -0400
Gene Heskett gheskett@shentel.net wrote:
okular seems to run ok most of the time, but when run from the cli logs this:
gene@coyote:~/linuxcnc/nc_files$ okular okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x8cef5b0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
This is my fav pdf reader, and I get 3 to 4 weeks uptime before something goes to pot and I need to reboot this old wheezy install.
Connected? IDK, maybe... I have a stretch testing image from the LCNC folks that I put on an old Dell out in the garage as the sacrificial goat, and its running quite well so far, so this wheezy may get retired finally. Sometime in the next week or two if the creek doesn't get too high. :)
okular is kde5/qt5, so it's a moving target. A quick search suggests that this is a known bug (possibly two separate bugs), it's been fixed, and you're running a very old version.
So, yeah, you might want to update to something a little more modern.
Huh? I thought it was part of the kde fork?
Um, no. Note that your error messages above refer to kdeui and kdelibs, not tdeui and tdelibs, even though these modules were renamed in TDE.
If not, then what am I supposed to be using?
The default TDE program for viewing PDFs is kpdf, in tdegraphics. That doesn't mean you have to use it if it doesn't suit your needs, of course.
E. Liddell
Thats a bit odd, this is an R14.0.6 install, but its not in either office or graphics sections of the menu. Xpdf is there, but its yet to do a print job anywhere near complete or correct. Reinstalled it, still can't be found. Does run by cli. But whats all this?
gene@coyote:~/linuxcnc/nc_files$ kpdf /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/trinity/magic/drgeo.magic, 2: Warning: using regular magic file `/etc/trinity/magic/cabri.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/trinity/magic/drgeo.magic, 2: Warning: using regular magic file `/etc/trinity/magic/cabri.magic' /etc/trinity/magic/cabri.magic, 2: Warning: using regular magic file `/etc/trinity/magic/kolf.magic'
I loaded up a 750 page linuxcnc documentation pdf, and while its all there, it doesn't quite have the pretty print pizzazz that evince or okular gives.
I am about to install stretch on this machine, from an image the LCNC folks are testing, so hopefully wheezy will have reached the end of its use here in the next couple weeks. And this time its a 64 bit install, something I've been avoiding because of the much larger IRQ latencies of a 64 bit install. But they've been fine tuning the preempt-rt kernel builds and now have it good enough (pretty steady 50 u-sec lag) the smarter interface cards can handle the remaining timeing wobblies. Their default windowing system is xfce4, quite capable these days but I'll likely do tde on it too just to get my old friend kmail.
You might think 50 u-secs is quick, but I have 2 machines here that can respond to a scheduled IRQ with a worst case wobble in the 4 to 6 u-sec range. Intel Atoms of course. Amd lost that fight years ago.
Cheers, Gene Heskett
On Tue, 30 Apr 2019 21:47:41 -0400 Gene Heskett gheskett@shentel.net wrote:
On Tuesday 30 April 2019 20:34:09 E. Liddell wrote:
On Tue, 30 Apr 2019 18:06:22 -0400
Gene Heskett gheskett@shentel.net wrote:
On Tuesday 30 April 2019 17:27:42 E. Liddell wrote:
On Tue, 30 Apr 2019 09:27:25 -0400
Gene Heskett gheskett@shentel.net wrote:
okular seems to run ok most of the time, but when run from the cli logs this:
gene@coyote:~/linuxcnc/nc_files$ okular okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(1985)/kdeui (kdelibs) KXMLGUIClient::~KXMLGUIClient: 0x8cef5b0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes.
This is my fav pdf reader, and I get 3 to 4 weeks uptime before something goes to pot and I need to reboot this old wheezy install.
Connected? IDK, maybe... I have a stretch testing image from the LCNC folks that I put on an old Dell out in the garage as the sacrificial goat, and its running quite well so far, so this wheezy may get retired finally. Sometime in the next week or two if the creek doesn't get too high. :)
okular is kde5/qt5, so it's a moving target. A quick search suggests that this is a known bug (possibly two separate bugs), it's been fixed, and you're running a very old version.
So, yeah, you might want to update to something a little more modern.
Huh? I thought it was part of the kde fork?
Um, no. Note that your error messages above refer to kdeui and kdelibs, not tdeui and tdelibs, even though these modules were renamed in TDE.
If not, then what am I supposed to be using?
The default TDE program for viewing PDFs is kpdf, in tdegraphics. That doesn't mean you have to use it if it doesn't suit your needs, of course.
E. Liddell
Thats a bit odd, this is an R14.0.6 install, but its not in either office or graphics sections of the menu. Xpdf is there, but its yet to do a print job anywhere near complete or correct. Reinstalled it, still can't be found. Does run by cli.
kpdf is on the menu under "Office" for me. No idea why it doesn't show up for you--it's probably a packaging boondoggle.
But whats all this?
gene@coyote:~/linuxcnc/nc_files$ kpdf /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/trinity/magic/drgeo.magic, 2: Warning: using regular magic file `/etc/trinity/magic/cabri.magic' /etc/magic, 4: Warning: using regular magic file `/etc/trinity/magic/tdeio.magic' /etc/trinity/magic/tdeio.magic, 17: Warning: using regular magic file `/etc/trinity/magic/drgeo.magic' /etc/trinity/magic/drgeo.magic, 2: Warning: using regular magic file `/etc/trinity/magic/cabri.magic' /etc/trinity/magic/cabri.magic, 2: Warning: using regular magic file `/etc/trinity/magic/kolf.magic'
It doesn't like the format of some magic number files, it looks like. Should be harmless.
I loaded up a 750 page linuxcnc documentation pdf, and while its all there, it doesn't quite have the pretty print pizzazz that evince or okular gives.
It all depends on what you need. My needs in terms of PDF viewing are pretty basic.
You might think 50 u-secs is quick, but I have 2 machines here that can respond to a scheduled IRQ with a worst case wobble in the 4 to 6 u-sec range. Intel Atoms of course. Amd lost that fight years ago.
Ah, well there we will have to disagree. I've always bought AMD CPUs, and I'm quite pleased with my current Threadripper. Mind you, I'm not using it for CNC or other realtime-sensitive applications.
E. Liddell
On Tuesday 30 April 2019 22:22:14 E. Liddell wrote:
[...]
Ah, well there we will have to disagree. I've always bought AMD CPUs, and I'm quite pleased with my current Threadripper. Mind you, I'm not using it for CNC or other realtime-sensitive applications.
E. Liddell
Actually, I've been generally pleased with this now elderly 2.1GHz phenom. But its not well equiped to run machinery. latency-test shows 70,000,000 ns for the 1 millisecond servo-thread. Thats 70 milliseconds. Take away the base-thread which runs at 25 microsecond intervals and it is still around 50 milliseconds. And it would be 10x worse than that if I was using an nvidia driver. So I'm using nouveau. I'm not much of a gamer ubless you count solitaire. :) For GP computing, I've always favored amd just to keep competition alive. To demo the diff between software stepping, one of those 6 u-s machines has run a small mill for years, at a maximum table speed of about 12 ipm. A damaged ball screw put that mill out of commission, so that computer is now driving a 600x390mm gantry style mill, but it now has Mesa fpga based cards for the i/o because one parport doesn't give near enough i/o. But with those cards to offload the high frequency base thread from the cpu, that machine is moving at 210mm/second top speed, almost 20x faster. It gets homed at about 100mm/sec, and overshoots the switch less that half the overtravel it has. One switch is a button, and is mounted on a spring to protect the switch from being smashed. A 2" piece of .0325" thick sheet alu is the spring. The max flex might allow a 24lb piece of paper to be inserted as thats how fast the machine can be stopped. The other 3 similar function switches are std mini-style microswitches with roller tipped levers. Neither allows a hard crash, stopping the machine about 10 thou from it. But thats not the "home" point because once the switch has tripped, the machine moves away from the switch at 1/20th the search speed because the software only samples the switch at millisecond intervals. So when the switch releases, is the actual home position reference, and that gives me .0001" accuracy. The switches aren't that accurate of course but the individual switch in a bag of 10 for 4 dollars is very very repeatable. Thats about how far the motors turn when being microstepped at 1/8 step, a full step being 1.8 degrees of the motor shaft. Top speed is limited by two things, 1st being the speed of the opto isolators in the motor drivers limits us to a step rate of 200 kilohertz, and how fast the motors inductance can be overcome to establish the magnetic position. To do that we use power supply's of 10x or more than the nameplate label, its the current regulation that counts.
Your trivia factoid for the day :)
Cheers, Gene Heskett
-
E. Liddell -
Gene Heskett -
William Morder via trinity-users