Huston, we have a problem, or two.. with 7.1.
After upgrading to 7.1 from 7.0 I can say that: a) my 1996 Sony VAIO P166 with 64MB of RAM runs about 1/2 as fast. "locate" for example, use to snap back. Now it can take 30 secs to a minute. SO5.2, slow to load to begin with but acceptable in 7.0, has about doubled it's load time in 7.1 (But, it will be fast eought for my wife, who would make a newbie look like a seasoned pro :-) b) the REAL REASON for this missive: MuPAD-1.4.2, on the SuSE CD, will not run under KDE2. When you click on xmupad or chose it from the KDE2 menu structure what pops up is Hytex, the xwindow mupad manual. Xmupad never appears. When you close Hytex it disappears off the screen but stays in memory hogging up to 30% of the CPU resources doing nothing. I have to kill it manually. To test things out, I downloaded and installed the tar version of MuPAD-1.4.0 (notice the prior to 1.4.2) and encountered the same problem. The 1.4 tar version of MuPAD behaves identically. AND, while I can use my registration on the 1.4.0 tar version of MuPAD to remove the memory restraint, the registration code fails under 1.4.2, Now I believe this is just a library problem. Which library do I have to load to get 1.4.2 xmupad to run? I can always get another registration number. JLK
Quoting Jerry Kreps on Sat, Mar 03, 2001 at 05:11:39PM -0600:
After upgrading to 7.1 from 7.0 I can say that: a) my 1996 Sony VAIO P166 with 64MB of RAM runs about 1/2 as fast. "locate" for example, use to snap back. Now it can take 30 secs to a minute. SO5.2, slow to load to begin with but acceptable in 7.0, has about doubled it's load time in 7.1 (But, it will be fast eought for my wife, who would make a newbie look like a seasoned pro :-)
b) the REAL REASON for this missive: MuPAD-1.4.2, on the SuSE CD, will not run under KDE2. When you click on xmupad or chose it from the KDE2 menu structure what pops up is Hytex, the xwindow mupad manual. Xmupad never appears. When you close Hytex it disappears off the screen but stays in memory hogging up to 30% of the CPU resources doing nothing. I have to kill it manually.
To test things out, I downloaded and installed the tar version of MuPAD-1.4.0 (notice the prior to 1.4.2) and encountered the same problem. The 1.4 tar version of MuPAD behaves identically.
AND, while I can use my registration on the 1.4.0 tar version of MuPAD to remove the memory restraint, the registration code fails under 1.4.2,
Now I believe this is just a library problem. Which library do I have to load to get 1.4.2 xmupad to run? I can always get another registration number. JLK
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq
You could take the tar version and use the configure script to see what libraries it looks for or wants or capture the results of the ./configure to a logfile and see what it looks for. It may be a "newer library problem". I used to have this problem with my builds of gnome before SuSE and Gnome came together on the naming sequences of gnome packages. Then a gnome application would "expect glib.xxx.xxx.x". If it found something else, it would probably run but it would start acting wierd or eating memory when I closed it down. I stopped using a few programs (games especially) in gnome back then because I could not track the issues down. If I backcycled the library to something which appeared closer then some gnome core stuff would complain. Luckily, I had backed up the build a few times when I saw this happening so recovery was a bit easier. I also had a "junk install" of SuSE which I played with and tried different things on. When SuSE and gnome came together on package naming, things became much easier. I don't mess anymore with kde or gnome, but I would suspect that there is a library incompatability which you have found. Try trapping what the configure or make programs do and see if you spot something suspect like a rather significant change in libraries from what the program wants to what you have. I would also check on google for others which may have had this problem in the past with other applications. -- Michael Perry mperry@tsoft.com ------------------
Uh, oh! I'm hosed! Free licenses (unsupported) for MuPAD 1.4.2 are not available for a GNU Linux (at86) platform. The registered version costs 398,-DM. Well, since both the new 1.4.2 version and the 1.4.0 version exhibit the same failure mode running in KDE2 then my solution will probably be the same for 1.4.0, which does accept my registration and removed the memory limitation. How about SuSE. What's the clue to getting MuPAD 1.4.x running in the 7.1 release under KDE2? JLK On Saturday 03 March 2001 17:11, you wrote:
After upgrading to 7.1 from 7.0 I can say that: a) my 1996 Sony VAIO P166 with 64MB of RAM runs about 1/2 as fast. "locate" for example, use to snap back. Now it can take 30 secs to a minute. SO5.2, slow to load to begin with but acceptable in 7.0, has about doubled it's load time in 7.1 (But, it will be fast eought for my wife, who would make a newbie look like a seasoned pro :-)
b) the REAL REASON for this missive: MuPAD-1.4.2, on the SuSE CD, will not run under KDE2. When you click on xmupad or chose it from the KDE2 menu structure what pops up is Hytex, the xwindow mupad manual. Xmupad never appears. When you close Hytex it disappears off the screen but stays in memory hogging up to 30% of the CPU resources doing nothing. I have to kill it manually.
To test things out, I downloaded and installed the tar version of MuPAD-1.4.0 (notice the prior to 1.4.2) and encountered the same problem. The 1.4 tar version of MuPAD behaves identically.
AND, while I can use my registration on the 1.4.0 tar version of MuPAD to remove the memory restraint, the registration code fails under 1.4.2,
Now I believe this is just a library problem. Which library do I have to load to get 1.4.2 xmupad to run? I can always get another registration number. JLK
Quoting Michael Perry on Sat, Mar 03, 2001 at 03:25:27PM -0800:
You could take the tar version and use the configure script to see what libraries it looks for or wants or capture the results of the ./configure to a logfile and see what it looks for. It may be a "newer library problem". I used to have this problem with my builds of gnome before SuSE and Gnome came together on the naming sequences of gnome packages. Then a gnome application would "expect glib.xxx.xxx.x". If it found something else, it would probably run but it would start acting wierd or eating memory when I closed it down. I stopped using a few programs (games especially) in gnome back then because I could not track the issues down. If I backcycled the library to something which appeared closer then some gnome core stuff would complain. Luckily, I had backed up the build a few times when I saw this happening so recovery was a bit easier. I also had a "junk install" of SuSE which I played with and tried different things on. When SuSE and gnome came together on package naming, things became much easier.
I don't mess anymore with kde or gnome, but I would suspect that there is a library incompatability which you have found. Try trapping what the configure or make programs do and see if you spot something suspect like a rather significant change in libraries from what the program wants to what you have.
I would also check on google for others which may have had this problem in the past with other applications.
One other thing that occurs to me is that you could use rpm itself to find out what applications/libraries, etc are dependencies for the program in question. YOu could use some of the rpm metadata commands and check out what is required or what the package needs to operate correctly. We used to start with "rpm -qi nameofpackage.rpm" and start from there. That gives a good amount of info about the baseline capabilities of the package. Then you could go on with some more detailed rpm commands like "rpm -qR nameofpackage.rpm". This command provides: -R, --requires List packages on which this package depends. I got most of these awhile ago from Maximum RPM but they are also explained in the rpm man pages. -- Michael Perry mperry@tsoft.com ------------------
On Saturday 03 March 2001 17:25, you wrote:
Quoting Jerry Kreps on Sat, Mar 03, 2001 at 05:11:39PM -0600:
After upgrading to 7.1 from 7.0 I can say that: a) my 1996 Sony VAIO P166 with 64MB of RAM runs about 1/2 as fast. "locate" for example, use to snap back. Now it can take 30 secs to a minute. SO5.2, slow to load to begin with but acceptable in 7.0, has about doubled it's load time in 7.1 (But, it will be fast eought for my wife, who would make a newbie look like a seasoned pro :-)
b) the REAL REASON for this missive: MuPAD-1.4.2, on the SuSE CD, will not run under KDE2. When you click on xmupad or chose it from the KDE2 menu structure what pops up is Hytex, the xwindow mupad manual. Xmupad never appears. When you close Hytex it disappears off the screen but stays in memory hogging up to 30% of the CPU resources doing nothing. I have to kill it manually.
To test things out, I downloaded and installed the tar version of MuPAD-1.4.0 (notice the prior to 1.4.2) and encountered the same problem. The 1.4 tar version of MuPAD behaves identically.
AND, while I can use my registration on the 1.4.0 tar version of MuPAD to remove the memory restraint, the registration code fails under 1.4.2,
Now I believe this is just a library problem. Which library do I have to load to get 1.4.2 xmupad to run? I can always get another registration number. JLK
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq
You could take the tar version and use the configure script to see what libraries it looks for or wants or capture the results of the ./configure to a logfile and see what it looks for. It may be a "newer library problem". I used to have this problem with my builds of gnome before SuSE and Gnome came together on the naming sequences of gnome packages. Then a gnome application would "expect glib.xxx.xxx.x". If it found something else, it would probably run but it would start acting wierd or eating memory when I closed it down. I stopped using a few programs (games especially) in gnome back then because I could not track the issues down. If I backcycled the library to something which appeared closer then some gnome core stuff would complain. Luckily, I had backed up the build a few times when I saw this happening so recovery was a bit easier. I also had a "junk install" of SuSE which I played with and tried different things on. When SuSE and gnome came together on package naming, things became much easier.
I don't mess anymore with kde or gnome, but I would suspect that there is a library incompatability which you have found. Try trapping what the configure or make programs do and see if you spot something suspect like a rather significant change in libraries from what the program wants to what you have.
I would also check on google for others which may have had this problem in the past with other applications.
The 1.4.0 xmupad script is the same as the 1.4.2, even has the same date on it. The XView libraries are identical. I would have assumed that someone in the SuSE testing dept ran MuPAD 1.4.2 and confirmed that in the version on the CD Xmupad would indead come up under KDE2. I don't run KDE1 and I don't run fwm95 so I don't know or care if it would run under them. MuPAD does run in an xterm, but the graphics doesn't pop up and hypage won't run in the graphical mode. JLK
On Saturday 03 March 2001 17:32, you wrote:
Quoting Michael Perry on Sat, Mar 03, 2001 at 03:25:27PM -0800:
You could take the tar version and use the configure script to see what libraries it looks for or wants or capture the results of the ./configure to a logfile and see what it looks for. It may be a "newer library problem". I used to have this problem with my builds of gnome before SuSE and Gnome came together on the naming sequences of gnome packages. Then a gnome application would "expect glib.xxx.xxx.x". If it found something else, it would probably run but it would start acting wierd or eating memory when I closed it down. I stopped using a few programs (games especially) in gnome back then because I could not track the issues down. If I backcycled the library to something which appeared closer then some gnome core stuff would complain. Luckily, I had backed up the build a few times when I saw this happening so recovery was a bit easier. I also had a "junk install" of SuSE which I played with and tried different things on. When SuSE and gnome came together on package naming, things became much easier.
I don't mess anymore with kde or gnome, but I would suspect that there is a library incompatability which you have found. Try trapping what the configure or make programs do and see if you spot something suspect like a rather significant change in libraries from what the program wants to what you have.
I would also check on google for others which may have had this problem in the past with other applications.
One other thing that occurs to me is that you could use rpm itself to find out what applications/libraries, etc are dependencies for the program in question.
YOu could use some of the rpm metadata commands and check out what is required or what the package needs to operate correctly. We used to start with "rpm -qi nameofpackage.rpm" and start from there. That gives a good amount of info about the baseline capabilities of the package.
Then you could go on with some more detailed rpm commands like "rpm -qR nameofpackage.rpm". This command provides:
-R, --requires List packages on which this package depends.
I got most of these awhile ago from Maximum RPM but they are also explained in the rpm man pages.
Ya. Using sux -x in an xterm and running kpackage will show you the dependencies, which are all satisfied, obviously. I still think it is a base library incompatibility. JLK
Quoting Jerry Kreps on Sat, Mar 03, 2001 at 05:47:50PM -0600:
Ya. Using sux -x in an xterm and running kpackage will show you the dependencies, which are all satisfied, obviously. I still think it is a base library incompatibility. JLK
-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq
That's kinda what happened to me with gnome early on. I satisfied all the dependencies on some packages like gnotepad+ but upon compiling it and using it I got tons of gdk errors and finally had the program blowup and consume large amounts of memory in a zombie state. My issue was one library which was required by gnotepad+ at one revision level. By updating the core libraries, I still satisfied the dependencies but the application itself divebombed with the later library. I wrote the author and he informed that he recently had found the same thing and that a new revision would be coming out soon which would deal with a memory issue in one of the gnome core libs. It took me a few hours of tracing the configure options of the tarball packages before I found the one library which was somewhat different. As I said though, gnome then possessed (and still does) a complex inter-relationship of different core and supporting applications. Good luck finding the needle :) -- Michael Perry mperry@tsoft.com ------------------
I can open an xterm and run mupad, but the HyPage help file won't open up and neither will plotfunc() work, the call to vcam fails with: Error: Dumb terminal: Plotdata saved in binary file save.mp [plot]; in procedure 'plot2d' So, MuPAD's functionality is greatly reduced. JLK On Sunday 04 March 2001 00:06, you wrote:
On Saturday 03 March 2001 17:27, Jerry Kreps wrote:
solution will probably be the same for 1.4.0, which does accept my registration and removed the memory limitation.
Jerry,
I am also a MuPaD user, and I believe that the reason 1.4.2 does not accept your registration code is the fact that you are entering>> plotfunc(x^2,x=1..10);
it as "yourself", rather than as root.
## root@friedman:/home/anovo ## mupad
*----* MuPAD 1.4.2 -- The Open Computer Algebra System /| /| *----* | Copyright (c) 1997 - 1999 by SciFace Software
| *--|-* All rights reserved. |/ |/
*----* UNREGISTERED VERSION Please contact info@sciface.com to register.
register("Alvaro Novo", "1xxx99-24xxx4-xxxxxx");
Memory limitation removed.
TRUE
How about SuSE. What's the clue to getting MuPAD 1.4.x running in the 7.1 release under KDE2?
Yes, Xmupad fails under KDE2.1... we need a fix!
Hope it helps,
Alvaro Novo
SuSE 7.1 -=- Kernel 2.4.2-4 -=- KDE 2.1 12:06am up 2:06, 6 users, load average: 0.10, 0.04, 0.01
On Saturday 03 March 2001 17:27, Jerry Kreps wrote:
solution will probably be the same for 1.4.0, which does accept my registration and removed the memory limitation.
Jerry, I am also a MuPaD user, and I believe that the reason 1.4.2 does not accept your registration code is the fact that you are entering it as "yourself", rather than as root. ## root@friedman:/home/anovo ## mupad *----* MuPAD 1.4.2 -- The Open Computer Algebra System /| /| *----* | Copyright (c) 1997 - 1999 by SciFace Software | *--|-* All rights reserved. |/ |/ *----* UNREGISTERED VERSION Please contact info@sciface.com to register.
register("Alvaro Novo", "1xxx99-24xxx4-xxxxxx"); Memory limitation removed.
TRUE
How about SuSE. What's the clue to getting MuPAD 1.4.x running in the 7.1 release under KDE2?
Yes, Xmupad fails under KDE2.1... we need a fix! Hope it helps, Alvaro Novo SuSE 7.1 -=- Kernel 2.4.2-4 -=- KDE 2.1 12:06am up 2:06, 6 users, load average: 0.10, 0.04, 0.01
participants (3)
-
Jerry Kreps
-
Michael Perry
-
Álvaro A. Novo