Bugreport?
Locked
 
|
I tried to proceed as described on
http://pharo-project.org/community/issue-tracking and tried to search in the mailing list in the archive. But in trying to access the archive I get the message from Nabble(?): This node has been deleted Here a problem description: I installed Pharo latest version on debian lenny 64 bit and it works properly from start on, but I had/have some problems with Squeak. I installed Pharo (same procedure as above) on red hat 64 bit Kernel 2.6.34.7-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it does not work, but Squeak works properly. The message is: [bb@localhost Pharo-1.1-OneClick.app]$ ./pharo.sh libGLU.so.1: cannot open shared object file: No such file or directory could not find module vm-display-X11 Abgebrochen (Speicherabzug geschrieben) [bb@localhost Pharo-1.1-OneClick.app] I installed repeatedly and tried to use available VM's from Squeak and also tried some other "tricks", i.e copy all Pharo-files in the same directory ... May be someone else has some experience with Pharon on red hat? Please tell me if it is worth to make a ticket? Regards BB |
|
|
Hello everyone,
I thing, there is a bug in WriteStream, but i'm not sure. When I look at this code, I guess aString is not always a String, and yesterday, I had a Text send to this method, which raised a DNU error. (in blue is what I have change to make it work in my case) WriteStream>>nextChunkPut: aString "Append the argument, aString, to the receiver, doubling embedded terminators." | i remainder terminator | terminator := $!. remainder := aString asString. [(i := remainder indexOf: terminator) = 0] whileFalse: [self nextPutAll: (remainder copyFrom: 1 to: i). self nextPut: terminator. "double imbedded terminators" remainder := remainder copyFrom: i+1 to: remainder size]. self nextPutAll: remainder. aString asString includesUnifiedCharacter ifTrue: [ self nextPut: terminator. self nextPutAll: ']lang['. aString asString writeLeadingCharRunsOn: self. ]. self nextPut: terminator. Is that a bug ? Regards, Ben
|
|
|
On 5 November 2010 11:20, Benjamin <[hidden email]> wrote:
> Hello everyone, > I thing, there is a bug in WriteStream, but i'm not sure. > When I look at this code, I guess aString is not always a String, and > yesterday, I had a Text send to this method, which raised a DNU error. > (in blue is what I have change to make it work in my case) > WriteStream>>nextChunkPut: aString > "Append the argument, aString, to the receiver, doubling embedded > terminators." > > | i remainder terminator | > terminator := $!. > remainder := aString asString. > [(i := remainder indexOf: terminator) = 0] whileFalse: > [self nextPutAll: (remainder copyFrom: 1 to: i). > self nextPut: terminator. "double imbedded terminators" > remainder := remainder copyFrom: i+1 to: remainder size]. > self nextPutAll: remainder. > aString asString includesUnifiedCharacter ifTrue: [ > self nextPut: terminator. > self nextPutAll: ']lang['. > aString asString writeLeadingCharRunsOn: self. > ]. > self nextPut: terminator. > > > Is that a bug ? > I'd say the whole method is a bug. Repeating aString asString multiple times in code cries out of loud that it could be anything but not right :) > Regards, > Ben -- Best regards, Igor Stasenko AKA sig. |
Re: WriteStream
|
|
On Nov 5, 2010, at 10:30 AM, Igor Stasenko wrote: > On 5 November 2010 11:20, Benjamin <[hidden email] > > wrote: >> Hello everyone, >> I thing, there is a bug in WriteStream, but i'm not sure. >> When I look at this code, I guess aString is not always a String, and >> yesterday, I had a Text send to this method, which raised a DNU >> error. >> (in blue is what I have change to make it work in my case) >> WriteStream>>nextChunkPut: aString >> "Append the argument, aString, to the receiver, doubling embedded >> terminators." >> >> | i remainder terminator | >> terminator := $!. >> remainder := aString asString. >> [(i := remainder indexOf: terminator) = 0] whileFalse: >> [self nextPutAll: (remainder copyFrom: 1 to: i). >> self nextPut: terminator. "double imbedded terminators" >> remainder := remainder copyFrom: i+1 to: remainder size]. >> self nextPutAll: remainder. >> aString asString includesUnifiedCharacter ifTrue: [ >> self nextPut: terminator. >> self nextPutAll: ']lang['. >> aString asString writeLeadingCharRunsOn: self. >> ]. >> self nextPut: terminator. >> >> >> Is that a bug ? >> > yes. > > I'd say the whole method is a bug. Repeating > aString asString multiple times in code cries out of loud that it > could be anything but not right :) I think so ^^ I'll create a bug entry Ben > > >> Regards, >> Ben > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
|
|
In reply to this post by bblochl
Am 05.11.2010 10:09, schrieb bb:
> I tried to proceed as described on > http://pharo-project.org/community/issue-tracking and tried to search in > the mailing list in the archive. But in trying to access the archive I > get the message from Nabble(?): > > This node has been deleted > > Here a problem description: > > I installed Pharo latest version on debian lenny 64 bit and it works > properly from start on, but I had/have some problems with Squeak. > > I installed Pharo (same procedure as above) on red hat 64 bit Kernel > 2.6.34.7-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it > does not work, but Squeak works properly. The message is: > > [bb@localhost Pharo-1.1-OneClick.app]$ ./pharo.sh > libGLU.so.1: cannot open shared object file: No such file or directory > could not find module vm-display-X11 > Abgebrochen (Speicherabzug geschrieben) > [bb@localhost Pharo-1.1-OneClick.app] > > I installed repeatedly and tried to use available VM's from Squeak and > also tried some other "tricks", i.e copy all Pharo-files in the same > directory ... > > May be someone else has some experience with Pharon on red hat? > > Please tell me if it is worth to make a ticket? > > Regards BB > installed. I will check if there is something on error with that packages on fedora/red hat. May be someone else has some extended expirence with this issue? Tegards BB |
|
|
Hi,
Have you checked http://forum.world.st/libGLU-so-1-cannot-open-shared-object-file-No-such-file-or-directory-tp2310764p2310811.html ?
Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ On Fri, Nov 5, 2010 at 10:31 AM, bb <[hidden email]> wrote: Am 05.11.2010 10:09, schrieb bb: |
|
|
In reply to this post by Benjamin Van Ryseghem (Pharo)
IMHO, asString should not be sent at all :)
If you want a WriteStream on a Texts string, provide the texts string as an argument This will likely not work as you want though, as there's no become of the underlying collection of the WriteStream when you attempt to write past the capacity of the original in Squeak/Pharo. So you'd probably end up wondering why your text does not display everything you wrote using the WriteStream. A good suggestion would be to treat Text objects wrt the string they represent as immutable objects. Cheers, Henry Den 05.11.2010 10:28, skrev Benjamin: > > On Nov 5, 2010, at 10:30 AM, Igor Stasenko wrote: > >> On 5 November 2010 11:20, Benjamin >> <[hidden email]> wrote: >>> Hello everyone, >>> I thing, there is a bug in WriteStream, but i'm not sure. >>> When I look at this code, I guess aString is not always a String, and >>> yesterday, I had a Text send to this method, which raised a DNU error. >>> (in blue is what I have change to make it work in my case) >>> WriteStream>>nextChunkPut: aString >>> "Append the argument, aString, to the receiver, doubling embedded >>> terminators." >>> >>> | i remainder terminator | >>> terminator := $!. >>> remainder := aString asString. >>> [(i := remainder indexOf: terminator) = 0] whileFalse: >>> [self nextPutAll: (remainder copyFrom: 1 to: i). >>> self nextPut: terminator. "double imbedded terminators" >>> remainder := remainder copyFrom: i+1 to: remainder size]. >>> self nextPutAll: remainder. >>> aString asString includesUnifiedCharacter ifTrue: [ >>> self nextPut: terminator. >>> self nextPutAll: ']lang['. >>> aString asString writeLeadingCharRunsOn: self. >>> ]. >>> self nextPut: terminator. >>> >>> >>> Is that a bug ? >>> >> yes. >> >> I'd say the whole method is a bug. Repeating >> aString asString multiple times in code cries out of loud that it >> could be anything but not right :) > > I think so ^^ > > I'll create a bug entry > Ben > >> >> >>> Regards, >>> Ben >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > |
|
|
In reply to this post by bblochl
On Fri, Nov 5, 2010 at 6:09 AM, bb <[hidden email]> wrote: I tried to proceed as described on I think Nabble has changed. Geert may help. This should work: http://forum.world.st/Pharo-Smalltalk-f1294837.html Adrian: can we update the Nabble link in http://www.pharo-project.org/community to this new link? Thanks Mariano This node has been deleted |
Administrator
|
On Fri, Nov 5, 2010 at 4:15 PM, Mariano Martinez Peck <[hidden email]> wrote:
Yes, the links look like they need updating, I placed all online forums under our own nicer "forum.world.st" subdomain rather than "nabble.com". I thought they said that the old links would keep working but it looks like that has changed.
|
|
|
In reply to this post by bblochl
Am 05.11.2010 10:31, schrieb bb:
> Am 05.11.2010 10:09, schrieb bb: >> I tried to proceed as described on >> http://pharo-project.org/community/issue-tracking and tried to search in >> the mailing list in the archive. But in trying to access the archive I >> get the message from Nabble(?): >> >> This node has been deleted >> >> Here a problem description: >> >> I installed Pharo latest version on debian lenny 64 bit and it works >> properly from start on, but I had/have some problems with Squeak. >> >> I installed Pharo (same procedure as above) on red hat 64 bit Kernel >> 2.6.34.7-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it >> does not work, but Squeak works properly. The message is: >> >> [bb@localhost Pharo-1.1-OneClick.app]$ ./pharo.sh >> libGLU.so.1: cannot open shared object file: No such file or directory >> could not find module vm-display-X11 >> Abgebrochen (Speicherabzug geschrieben) >> [bb@localhost Pharo-1.1-OneClick.app] >> >> I installed repeatedly and tried to use available VM's from Squeak and >> also tried some other "tricks", i.e copy all Pharo-files in the same >> directory ... >> >> May be someone else has some experience with Pharon on red hat? >> >> Please tell me if it is worth to make a ticket? >> >> Regards BB >> > Appendix: The libGLU runtime library + development package are > installed. I will check if there is something on error with that > packages on fedora/red hat. > > May be someone else has some extended expirence with this issue? > > Tegards BB > Thanks for the correct link for bug-reporting! Thanks for many helping contributions and help to that topic! At least I found a striking explanation and I think the developers of Pharo might take care of: The libGLU-files on fedora13 are not in the directory /usr/lib but in /usr/lib64. I cross-checked debian lenny and found that libs in /usr/lib. (lenny does have a directory usr/lib64 as well.) I had to deal with such differences of different Linux brands and while moving to 64 bit very often in the past. I am not a Pharo-developer, but I recommend to check the pathes set and eventually extend the settings with the 64-bit alternatives. An alternative might be a hard link? ~$ ln /usr/lib64/libGLU.so.1 /usr/lib/libGLU.so.1 But now I ave another error message: ~ Pharo-1.1-OneClick.app]$ ./pharo.sh libGLU.so.1: wrong ELF class: ELFCLASS64 could not find module vm-display-X11 Abgebrochen (Speicherabzug geschrieben) I am not allmighty and more or less just a hobbyist with just an underdeveloped CS knowledge, but I think that there is a trial to link a 32 bit Pharo with an object-file (libGLU.so.1) which was compiled for 64 bit? (May be that debian still delivers a 32 bit object file, so it works??) One might try to recompile with the '-m64' flag of gcc. May be a compilerrun with correct autoconf (configure) scripts, set to CC="gcc -m64" (or CC="gcc -m32") might help? So I would say, the problem is fixed but not solved. Regards BB |
|
|
Yes, usually, since SqueakVM is 32 bits, on a 64 bits OS, you need to install the 32bits OS libraries.
For example, in Ubuntu, I remember doing: "sudo apt-get install ia32-libs" cheers mariano On Fri, Nov 5, 2010 at 6:32 PM, bb <[hidden email]> wrote: Am 05.11.2010 10:31, schrieb bb: |
|
|
There is a SqueakVM for 64 bit as well, see:
http://www.squeakvm.org/squeak64/ As squeak is running on my machine with fedora13 64 bit WITHOUT the 32 bit libGLU.so.1 (as I have explained in another mail, the only libGLU is in the directory /usr/lib64) one can make sure that there is a 64 bit version running (and offered in the fedora13 64 bit repository, from where I have installed). Vice verse, on my 64 bit debian lenny installation squeak does not run. On that system as (nearly) only the 32 bit libs installed. (I will analyse that case if I find some time.) There seems to be a situation of shift to 64 bit with some library breaks in different systems. Indeed it is possible to install the 32 bit libs with apt-get on debian like machines and yum or rpm or other tools on other linux brands. That would not help so much because it does not solve he incompatibility of my installed 64 bit SqueakVM running on my machine with the 32 bit pharo-image. (I have not yet tried, but in this logic I would have to install a 32 bit squeak as well.) The file vm-display-X11 of my actual squeak version is in directory /usr/lib64/squeak/3.10-5. I tried to change pharo.sh to point explicitely to that directory to use that vm. The result: ~ Pharo-1.1-OneClick.app$ ./pharo2.sh libGLU.so.1: wrong ELF class: ELFCLASS64 could not find display driver vm-display-X11; either: - check that /usr/local/lib/squeak/4.0.3-2202/vm-display-X11.so exists, or - use the '-plugins <path>' option to tell me where it is, or - remove DISPLAY from your environment. Abgebrochen (Speicherabzug geschrieben) ~ Pharo-1.1-OneClick.app$ As you can see pharo is looking for the vm of squeak version 4.0.3-2202 instead of 3.10-5. I do not know where to change this path in pharo and if it makes sense? I do not understand, that there are so.*-versions in .../Contents/Linux/? In my oppinion the clean and save solution for the future is to provide an additional 64 bit pharo-image beside the 32 bit version. Regards BB Am 05.11.2010 22:57, schrieb Mariano Martinez Peck: > Yes, usually, since SqueakVM is 32 bits, on a 64 bits OS, you need to > install the 32bits OS libraries. > > For example, in Ubuntu, I remember doing: "*sudo* *apt*-*get* install > ia32-libs" > > cheers > > mariano > > On Fri, Nov 5, 2010 at 6:32 PM, bb <[hidden email]> wrote: > >> Am 05.11.2010 10:31, schrieb bb: >>> Am 05.11.2010 10:09, schrieb bb: >>>> I tried to proceed as described on >>>> http://pharo-project.org/community/issue-tracking and tried to search >> in >>>> the mailing list in the archive. But in trying to access the archive I >>>> get the message from Nabble(?): >>>> >>>> This node has been deleted >>>> >>>> Here a problem description: >>>> >>>> I installed Pharo latest version on debian lenny 64 bit and it works >>>> properly from start on, but I had/have some problems with Squeak. >>>> >>>> I installed Pharo (same procedure as above) on red hat 64 bit Kernel >>>> 2.6.34.7-61.fc13.x86_64, AMD Turion 64 X2 Mobile Technology TL-56 and it >>>> does not work, but Squeak works properly. The message is: >>>> >>>> [bb@localhost Pharo-1.1-OneClick.app]$ ./pharo.sh >>>> libGLU.so.1: cannot open shared object file: No such file or directory >>>> could not find module vm-display-X11 >>>> Abgebrochen (Speicherabzug geschrieben) >>>> [bb@localhost Pharo-1.1-OneClick.app] >>>> >>>> I installed repeatedly and tried to use available VM's from Squeak and >>>> also tried some other "tricks", i.e copy all Pharo-files in the same >>>> directory ... >>>> >>>> May be someone else has some experience with Pharon on red hat? >>>> >>>> Please tell me if it is worth to make a ticket? >>>> >>>> Regards BB >>>> >>> Appendix: The libGLU runtime library + development package are >>> installed. I will check if there is something on error with that >>> packages on fedora/red hat. >>> >>> May be someone else has some extended expirence with this issue? >>> >>> Tegards BB >>> >> >> Thanks for the correct link for bug-reporting! >> >> Thanks for many helping contributions and help to that topic! >> >> At least I found a striking explanation and I think the developers of >> Pharo might take care of: >> >> The libGLU-files on fedora13 are not in the directory /usr/lib but in >> /usr/lib64. I cross-checked debian lenny and found that libs in >> /usr/lib. (lenny does have a directory usr/lib64 as well.) >> >> I had to deal with such differences of different Linux brands and while >> moving to 64 bit very often in the past. >> >> I am not a Pharo-developer, but I recommend to check the pathes set and >> eventually extend the settings with the 64-bit alternatives. >> >> An alternative might be a hard link? >> >> ~$ ln /usr/lib64/libGLU.so.1 /usr/lib/libGLU.so.1 >> >> But now I ave another error message: >> >> ~ Pharo-1.1-OneClick.app]$ ./pharo.sh >> libGLU.so.1: wrong ELF class: ELFCLASS64 >> could not find module vm-display-X11 >> Abgebrochen (Speicherabzug geschrieben) >> >> I am not allmighty and more or less just a hobbyist with just an >> underdeveloped CS knowledge, but I think that there is a trial to link a >> 32 bit Pharo with an object-file (libGLU.so.1) which was compiled for 64 >> bit? (May be that debian still delivers a 32 bit object file, so it >> works??) >> >> One might try to recompile with the '-m64' flag of gcc. May be a >> compilerrun with correct autoconf (configure) scripts, set to CC="gcc >> -m64" (or CC="gcc -m32") might help? >> >> So I would say, the problem is fixed but not solved. >> >> Regards BB >> >> > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |