December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Roeltyper

by Tudor Girba

Hi, Cyrille published it in the method: TypeCollector>>handleAssignment: val forTmp: index There is a guard condition with a comment. Cheers, Doru On 28 Dec 2011, at 11:10, StÃ©phane Ducasse wrote: > Did you publish the patch? > What is wrong? > What would be good is to remove the VW compliant classes and layers because like that it should be really simple. > > Stef > >> Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. >> >> Cheers, >> Doru >> >> >> On 26 Dec 2011, at 09:40, Lukas Renggli wrote: >> >>> Does it actually work? I haven't seen a version that correctly works >>> in recent closure images. >>> >>> Lukas >>> >>> On 26 December 2011 05:18, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>> I added a little blurb w. link to the collaborative book - >>>> http://book.pharo-project.org/book/PharoTools/roeltyper/ >>>> >>>> -- >>>> View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> -- >> www.tudorgirba.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> >> > > -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Dec. 28, 2011

Re: [Pharo-project] Roeltyper

by StÃ©phane Ducasse

Did you publish the patch? What is wrong? What would be good is to remove the VW compliant classes and layers because like that it should be really simple. Stef > Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. > > Cheers, > Doru > > > On 26 Dec 2011, at 09:40, Lukas Renggli wrote: > >> Does it actually work? I haven't seen a version that correctly works >> in recent closure images. >> >> Lukas >> >> On 26 December 2011 05:18, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> I added a little blurb w. link to the collaborative book - >>> http://book.pharo-project.org/book/PharoTools/roeltyper/ >>> >>> -- >>> View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > >

Dec. 28, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Philippe Marschall

On 27.12.2011 22:39, Eliot Miranda wrote: > Hi Phillipe, > > On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall > <kustos(a)gmx.net <mailto:kustos@gmx.net>> wrote: > > On 27.12.2011 19:18, Eliot Miranda wrote: > > Hi Phillipe, > > what does ldd answer for the squeak vm? > > > $ldd coglinux/lib/squeak/4.0-2515/__squeak > linux-gate.so.1 => (0xffffe000) > libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) > libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) > libm.so.6 => /lib32/libm.so.6 (0xf7687000) > libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) > libc.so.6 => /lib32/libc.so.6 (0xf750c000) > /lib/ld-linux.so.2 (0xf76fe000) > > It's a 64bit system with 32bit compatibility libraries (only for > cog, everything else is 64bit). > > > Ah, ok. Makes sense. So I expect the relevant code needs to read > > # On some old linuxes there is a /lib/tls thread-local-storage version > of the C > # library which the VM may use and if so should take precedence over > /lib libc. > case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in > /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; > /lib/libc*) SVMLLP="/lib:/usr/lib";; > /lib32/libc*) SVMLLP="/lib32:/usr/lib32";; > *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; > exit 1 > esac > > Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of > /usr/lib? Yes there is. Not for the whole /usr/lib, but only the 32bit compatibility libraries. Which was enough to run Squeak so far. Contents attached. Cheers Philippe

Dec. 28, 2011

Re: [Pharo-project] Roeltyper

by Tudor Girba

Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. Cheers, Doru On 26 Dec 2011, at 09:40, Lukas Renggli wrote: > Does it actually work? I haven't seen a version that correctly works > in recent closure images. > > Lukas > > On 26 December 2011 05:18, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> I added a little blurb w. link to the collaborative book - >> http://book.pharo-project.org/book/PharoTools/roeltyper/ >> >> -- >> View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

Dec. 28, 2011

Re: [Pharo-project] SystemTracer

by StÃ©phane Ducasse

but if we trace an image it should work so how can we make sure that the UI process is launched? Stef On Dec 2, 2011, at 12:15 PM, Igor Stasenko wrote: > On 2 December 2011 10:00, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Well, so it works, I only had to remove line >> >> SystemWindow wakeUpTopWindowUponStartup. >> > yes, now i remember we were patching that (among other things). > >> from the method SystemTracer2 processStartup. >> >> Cheers, >> -- Pavel >> >> >> On Fri, Dec 2, 2011 at 9:09 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> I published a new version in PharoTaskForces. >>> Thanks! >>> >>> stef >>> >>> >>> >>> On Dec 1, 2011, at 10:52 PM, Pavel Krivanek wrote: >>> >>>> What version of SystemTracer do you use, I would try Pharo-Kernel so >>>> we can see if it is UI related. >>>> >>>> -- Pavel >>>> >>>> On Thu, Dec 1, 2011 at 10:32 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> On Dec 1, 2011, at 10:19 PM, Igor Stasenko wrote: >>>>> >>>>>> On 1 December 2011 23:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>>>> Hi guys >>>>>>> >>>>>>> I made sure that SystemTracer is not invoking deprecated method in 1.4 >>>>>>> Now when I execute >>>>>>> SystemTracer2 writeImage: 'clone.image' >>>>>>> the process finishes, the image I obtain start but the UI is not working. >>>>>>> >>>>>>> Benjamin was it working when you tried with igor? >>>>>>> >>>>>> >>>>>> Yes, we had a working image, but not without some voodoo dance. >>>>>> But i don't remember what we did. >>>>>> In Hazel we are replacing a process, so there is no UI thread. A >>>>>> SystemTracer alone, however should copy stuff as it is. >>>>> >>>>> I just tried in 1.3 and I get the same problem. The UI is damaged and no interaction. >>>>> We should have a look at that. >>>>> BTW are you better or still sick? >>>>> >>>>> Stef >>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 28, 2011

Re: [Pharo-project] Pharo Launcher app

by StÃ©phane Ducasse

:) Stef On Dec 28, 2011, at 12:56 AM, Fernando Olivero wrote: > Hi, i created an app for launching Pharo, which remembers the last > opened vm+image . > Maybe some of you find it useful (for MacOS X) > Fernando > pd:Working on a version with arguments entry also. > <pharococoaUI.png><PharoCocoaUI.app.zip>

Dec. 28, 2011

Re: [Pharo-project] changing the class of an existing object to a subclass

by Schwab,Wilhelm K

Ben, That's a lot to read. If I'm getting the message, you want to subclass ODBCRow and are concerned about Metacello. Can't you simply subclass and then always load your code after the ODBC configuration does its thing in a new image? FWIW, I suspect I would make some type of wrapper class for the rows rather than subclass - the goal being to strive for uses-a vs. is-a. Idealistically (and perhaps naively) yours, Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Ben Coman [btc(a)openInWorld.com] Sent: Tuesday, December 27, 2011 11:46 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] changing the class of an existing object to a subclass greetings all, I am using ConfigurationOfODBC in Pharo 1.3. I have had success with getting an ODBCResultTable(OrderedCollection) containing ODBCRow containing about 30 fields. By default the fields are accessed by "row at: #fieldName" but I wanted to add some convenience methods to instead go "row fieldName." My searching and experimentation led me to subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on each ODBCRow to convert it to the subclass. This was to avoid having to having to understand and change any of the ConfigurationOfODBC code. I had tried copyFrom: but some of the instance variables inherited from ODBCRow were not filled in, generating exceptions in some of the inherited methods. I had also considered "become:" but that didn't seem appropriate. Using "adoptInstance:" worked fine until I added a new instance variable to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = #'bad receiver'. The "adoptInstance:" method comment says it follows the same rules as "primitiveChangeClassTo:" (yet note that "primitiveChangeClassTo:" never worked) The "primitiveChangeClassTo:" method comment says "The primitive will fail in most cases that you think might work [...] The facility is really provided for certain, very specific applications (mostly related to classes changing shape) and not for casual use" so I wondered if there was another way to achieve this. The full code is hopefully not too long to include for reference below. The use of "adoptInstance:" in the last section listed. ------ ODBCRow subclass: #EAPPackage instanceVariableNames: 'parent' "note adoptInstance works without this instance variable, and not with" classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackage >> name ^ self at: #Name ------ ODBCResultTable subclass: #EAPPackages instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackages class >> newFromConnection: connection | packages parent | packages := (connection query: 'select * from t_package;') execute asTable. self adoptInstance: packages. packages do: [ :row | EAPPackage adoptInstance: row. ]. ^packages. ------ In a Workspace I successfully evaluate the following three lines without : connection := ODBCConnection dsn: 'CIM' user: '' password: ''. packages := EAPPackages newFromConnection: connection. connection close. ------ I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One alternative I've considered is to somehow pass through a custom SomeClass in a variable to replace the hard reference to ODBCRow - but I don't want to chase back all the cascading call references. Is there another way to change an existing object to another class, such that it can be specialised with both additional methods and instance variables? I would appreciate any pointers. regards, Ben

Dec. 28, 2011

[Pharo-project] changing the class of an existing object to a subclass

by Ben Coman

greetings all, I am using ConfigurationOfODBC in Pharo 1.3. I have had success with getting an ODBCResultTable(OrderedCollection) containing ODBCRow containing about 30 fields. By default the fields are accessed by "row at: #fieldName" but I wanted to add some convenience methods to instead go "row fieldName." My searching and experimentation led me to subclassing ODBCRow as EAPPackage and then using "adoptInstance:" on each ODBCRow to convert it to the subclass. This was to avoid having to having to understand and change any of the ConfigurationOfODBC code. I had tried copyFrom: but some of the instance variables inherited from ODBCRow were not filled in, generating exceptions in some of the inherited methods. I had also considered "become:" but that didn't seem appropriate. Using "adoptInstance:" worked fine until I added a new instance variable to EAPPackage. Subsequently for "<primitive: 160 error: ec>", ec = #'bad receiver'. The "adoptInstance:" method comment says it follows the same rules as "primitiveChangeClassTo:" (yet note that "primitiveChangeClassTo:" never worked) The "primitiveChangeClassTo:" method comment says "The primitive will fail in most cases that you think might work [...] The facility is really provided for certain, very specific applications (mostly related to classes changing shape) and not for casual use" so I wondered if there was another way to achieve this. The full code is hopefully not too long to include for reference below. The use of "adoptInstance:" in the last section listed. ------ ODBCRow subclass: #EAPPackage instanceVariableNames: 'parent' "note adoptInstance works without this instance variable, and not with" classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackage >> name ^ self at: #Name ------ ODBCResultTable subclass: #EAPPackages instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'BTC-EA-Explore' ------ EAPPackages class >> newFromConnection: connection | packages parent | packages := (connection query: 'select * from t_package;') execute asTable. self adoptInstance: packages. packages do: [ :row | EAPPackage adoptInstance: row. ]. ^packages. ------ In a Workspace I successfully evaluate the following three lines without : connection := ODBCConnection dsn: 'CIM' user: '' password: ''. packages := EAPPackages newFromConnection: connection. connection close. ------ I found the ODBCRow instance creation to ODBCResultSet>>fetchRow. One alternative I've considered is to somehow pass through a custom SomeClass in a variable to replace the hard reference to ODBCRow - but I don't want to chase back all the cascading call references. Is there another way to change an existing object to another class, such that it can be specialised with both additional methods and instance variables? I would appreciate any pointers. regards, Ben

Dec. 28, 2011

[Pharo-project] Pharo Launcher app

by Fernando Olivero

Hi, i created an app for launching Pharo, which remembers the last opened vm+image . Maybe some of you find it useful (for MacOS X) Fernando pd:Working on a version with arguments entry also.

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Schwab,Wilhelm K

FWIW, I see neither on Ubuntu lucid, 32 bit. There is not even a /lib32. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Tuesday, December 27, 2011 4:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting. and is there a /lib32/tls? (I hope not). Does anyone have a linux system with either of the following? /lib32/tls /lib64/tls TIA Eliot On Tue, Dec 27, 2011 at 1:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>> wrote: Hi Phillipe, On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <kustos(a)gmx.net<mailto:kustos@gmx.net>> wrote: On 27.12.2011 19:18, Eliot Miranda wrote: Hi Phillipe, what does ldd answer for the squeak vm? $ldd coglinux/lib/squeak/4.0-2515/squeak linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) libm.so.6 => /lib32/libm.so.6 (0xf7687000) libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) libc.so.6 => /lib32/libc.so.6 (0xf750c000) /lib/ld-linux.so.2 (0xf76fe000) It's a 64bit system with 32bit compatibility libraries (only for cog, everything else is 64bit). Ah, ok. Makes sense. So I expect the relevant code needs to read # On some old linuxes there is a /lib/tls thread-local-storage version of the C # library which the VM may use and if so should take precedence over /lib libc. case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; /lib/libc*) SVMLLP="/lib:/usr/lib";; /lib32/libc*) SVMLLP="/lib32:/usr/lib32";; *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; exit 1 esac Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of /usr/lib? Cheers Philippe -- best, Eliot -- best, Eliot

Dec. 27, 2011