July 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Memory usage

by David T. Lewis

Hi Jannik, I am not a Mac user, and I have only ever done this on Linux, so I cannot promise that it will be easy. Possibly Esteban can give us some advice here, and correct my errors. Also, if you are going to try this, we may want to take the discussion to the vm-dev list. You will need to install the Mac tools for compiling Unix programs (sorry I do not know what this is called) and you will need to be able to compile programs using CMake and the gcc tools on a Mac. I know very little about this myself, but I'm sure others can give some tips. The actual VM that you will need to build will be an interpreter VM, and you will be building it with a preprocessor macro set to force use of the 64-bit object format. The resulting VM will be slow compared to what you are used to with Cog, and it may not have all the features that you would expect from a Mac VM (i.e. the VM that Esteban supports), but I expect that it should work on Mac and that it would allow you to run a 64-bit image prepared with the SystemTracer. As luck would have it, Ian Piumarta is in the process of updating the unix VM code right now, and this will make it easier to do the build for 64-bit images. I would say that we should wait a couple of days before starting any new work on this so that we have all of the latest updates. I'm not sure if this is something that you want to get into, and it is not what I would call "easy" ;) But if you want to try it I will do my best to step you through the process. Dave On Tue, Jul 31, 2012 at 03:18:19PM +0200, jannik.laval wrote: > Hi Dave, > > I begin with a small problem (is it ?): my os is the latest apple macos. > It seems that there is no squeak vm 64 for macos (I did not find it). > > How can I build one "easily" ? > > Thanks, > Jannik > > On Jul 24, 2012, at 2:04 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: > >> Hi Dave, > >> > >> Should I load the SystemTracer available on SqueakSource ? The last version is from 2011, and seems old, no ? > >> When I try it, it calls some methods that do not exist in Pharo. > >> > >> Do you have more information on how to use it ? > > > > Hi Jannik, > > > > The system tracer is explained in the class comment of class SystemTracer. > > The comment was written by Dan Ingalls (I think), and gives credit to Ted > > Kaehler as the inventor of the original. Class SystemTracer2 has additional > > documentation including how to run the trace. SystemTracer2 is a newer > > version that you will actually be using, so you can think of SystemTracer > > as the original reference implementation, while SystemTracer2 and its > > subclasses are variations on the original. SystemTracer64 is the subclass > > that implements conversion logic for copying 32-bit objects into the > > experimental 64-bit object memory format. This object format is described > > in the SystemTracer64 class comment, and more information is available at > > http://squeakvm.org/squeak64. > > > > A system tracer will first put your image into a "quiet" mode, then copy > > and convert the running object memory to a new image file, and then wake up > > and return to normal. This is similar to saving your image and restarting > > from a disk file, except that the system tracer will trace your object > > memory to a new format rather than saving it unchanged. > > > > To trace your running image to a new 64-bit image file, you would do this: > > > > SystemTracer64 writeImage: 'new64bitImage.image' > > > > The last update I did to SystemTracer (SystemTracing-dtl.23) works with > > closure-enabled images, including Pharo at one time. I have a 64-bit > > Pharo 1.4 image that I made about a year and a half ago. I don't know > > what has changed in Pharo since then, so probably some updates will be > > needed, or possibly a Pharo-specific version. I know that others on the > > Pharo list have worked on this, so hopefully someone else can give you > > some pointers about that. > > > > Dave > > > > > > --- > Jannik Laval >

July 31, 2012

[Pharo-project] Pharo Core 1.3 - Build # 44 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 31, 2012

[Pharo-project] Pharo Core 1.3 - Build # 43 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 31, 2012

Re: [Pharo-project] Memory usage

by jannik.laval

Hi Dave, I begin with a small problem (is it ?): my os is the latest apple macos. It seems that there is no squeak vm 64 for macos (I did not find it). How can I build one "easily" ? Thanks, Jannik On Jul 24, 2012, at 2:04 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: >> Hi Dave, >> >> Should I load the SystemTracer available on SqueakSource ? The last version is from 2011, and seems old, no ? >> When I try it, it calls some methods that do not exist in Pharo. >> >> Do you have more information on how to use it ? > > Hi Jannik, > > The system tracer is explained in the class comment of class SystemTracer. > The comment was written by Dan Ingalls (I think), and gives credit to Ted > Kaehler as the inventor of the original. Class SystemTracer2 has additional > documentation including how to run the trace. SystemTracer2 is a newer > version that you will actually be using, so you can think of SystemTracer > as the original reference implementation, while SystemTracer2 and its > subclasses are variations on the original. SystemTracer64 is the subclass > that implements conversion logic for copying 32-bit objects into the > experimental 64-bit object memory format. This object format is described > in the SystemTracer64 class comment, and more information is available at > http://squeakvm.org/squeak64. > > A system tracer will first put your image into a "quiet" mode, then copy > and convert the running object memory to a new image file, and then wake up > and return to normal. This is similar to saving your image and restarting > from a disk file, except that the system tracer will trace your object > memory to a new format rather than saving it unchanged. > > To trace your running image to a new 64-bit image file, you would do this: > > SystemTracer64 writeImage: 'new64bitImage.image' > > The last update I did to SystemTracer (SystemTracing-dtl.23) works with > closure-enabled images, including Pharo at one time. I have a 64-bit > Pharo 1.4 image that I made about a year and a half ago. I don't know > what has changed in Pharo since then, so probably some updates will be > needed, or possibly a Pharo-specific version. I know that others on the > Pharo list have worked on this, so hopefully someone else can give you > some pointers about that. > > Dave > > --- Jannik Laval

July 31, 2012

[Pharo-project] Error messages on hitting debugger?

by Patrik Sundberg

Hi, When I hit an exception taking me into the debugger I get the message shown in the title. To see it I have to make the title very wide. That's obviously not the way to do it - what's the right way of seeing error messages? Thanks, Patrik

July 31, 2012

Re: [Pharo-project] Loading Nautilus / Spec in 1.4

by Benjamin

On Jul 31, 2012, at 2:53 PM, Patrik Sundberg wrote: > On Tue, Jul 31, 2012 at 11:33 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 31, 2012, at 11:47 AM, Benjamin wrote: > > > The last version loads in 1.4 if I remove the inst var duplication > > yes but for example we wanted to load versionner and this is not the client (the guy loading the other packages) that > have to know. > Anyway having duplicated instance variables is a bug so we should fix it. > > Try RPackageOrganizer initialize :) Ben > Btw, I quickly ran into problems - renaming a method throws DNU etc. Seems we're at an unfortunate point where 2.0 is at a point of instability (I run into metacello and announcement issues), and 1.4 doesn't play nicely with Nautilus. The bits I was hoping to use was nautilus and metacello and my code would use SystemAnnouncements :/ > > Perhaps I'll go with 1.4 and the old events for now. > > > Stef > > > > > > > Ben > > > > On Jul 31, 2012, at 9:47 AM, StÃ©phane Ducasse wrote: > > > >> > >> On Jul 31, 2012, at 4:14 AM, Benjamin wrote: > >> > >>> I will but when I publish a Spec version from 2.0, I can't know this kind of bug > >> > >> if you give me access to the spec repo I can do it. > >> The point is that for 1.4 do you want to publish the newest version? I would not I would simply take the old version > >> and make sure that it loads in 1.4 > >> > >> Stef > >>> > >>> Ben > >>> > >>> On Jul 30, 2012, at 11:15 PM, StÃ©phane Ducasse wrote: > >>> > >>>> ben > >>>> may be you should just fix the problem as I did and publish a stable version that load in 1.4 > >>>> This way people can load spec (the stable version for 1.4) in 1.4. > >>>> we can do it together. Now going to bed > >>>> > >>>> Stef > >>>> > >>>> On Jul 30, 2012, at 10:55 PM, Benjamin wrote: > >>>> > >>>>> NautilusRefactoring depends on Spec for the UI, that's all. > >>>>> > >>>>> But the problem is that in 2.0 a subclass can have an inst var named like ones of its superclasses ... > >>>>> > >>>>> Ben > >>>>> > >>>>> > >>>>> On Jul 30, 2012, at 10:22 PM, StÃ©phane Ducasse wrote: > >>>>> > >>>>>> > >>>>>> On Jul 30, 2012, at 9:54 PM, Benjamin wrote: > >>>>>> > >>>>>>> > >>>>>>> On Jul 30, 2012, at 7:22 PM, StÃ©phane Ducasse wrote: > >>>>>>> > >>>>>>>> Yes I got bitten by that today this is a problem you should remove the instance variable from the superclass then load and remove it from buttonModel > >>>>>>>> and add it to its superclass. > >>>>>>>> Now I suggest not to use nautilus for 1.4. > >>>>>>> > >>>>>>> Why ? > >>>>>> > >>>>>> Indeed nautilus is not base on spec. > >>>>>> Still let us focus on 2.0 > >>>>>> > >>>>>> Stef > >>>>>> > >>>>>>> > >>>>>>> Ben > >>>>>>> > >>>>>>>> > >>>>>>>> Stef > >>>>>>>> > >>>>>>>> On Jul 30, 2012, at 7:02 PM, Patrik Sundberg wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Loading nautilus #stable in 1.4 I get: > >>>>>>>>> DuplicatedVariableError: helpHolder is already defined in AbstractBasicWidget > >>>>>>>>> > >>>>>>>>> Looks to come when loading the dependency Spec-Widgets-BenjaminVanRyseghem.48. > >>>>>>>>> > >>>>>>>>> Any ideas? > >>>>>>>>> > >>>>>>>>> I can provide more of the stack trace if it's useful (I'd assume so), but would like a pointer what the best way to get that info in an emailable format (not obvious to me how I can just copy-paste it). > >>>>>>>>> > >>>>>>>>> This is the summer release. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Patrik > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > >

July 31, 2012

Re: [Pharo-project] Loading Nautilus / Spec in 1.4

by Patrik Sundberg

On Tue, Jul 31, 2012 at 11:33 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Jul 31, 2012, at 11:47 AM, Benjamin wrote: > > > The last version loads in 1.4 if I remove the inst var duplication > > yes but for example we wanted to load versionner and this is not the > client (the guy loading the other packages) that > have to know. > Anyway having duplicated instance variables is a bug so we should fix it. > > Btw, I quickly ran into problems - renaming a method throws DNU etc. Seems we're at an unfortunate point where 2.0 is at a point of instability (I run into metacello and announcement issues), and 1.4 doesn't play nicely with Nautilus. The bits I was hoping to use was nautilus and metacello and my code would use SystemAnnouncements :/ Perhaps I'll go with 1.4 and the old events for now. > Stef > > > > > > > Ben > > > > On Jul 31, 2012, at 9:47 AM, StÃ©phane Ducasse wrote: > > > >> > >> On Jul 31, 2012, at 4:14 AM, Benjamin wrote: > >> > >>> I will but when I publish a Spec version from 2.0, I can't know this > kind of bug > >> > >> if you give me access to the spec repo I can do it. > >> The point is that for 1.4 do you want to publish the newest version? I > would not I would simply take the old version > >> and make sure that it loads in 1.4 > >> > >> Stef > >>> > >>> Ben > >>> > >>> On Jul 30, 2012, at 11:15 PM, StÃ©phane Ducasse wrote: > >>> > >>>> ben > >>>> may be you should just fix the problem as I did and publish a stable > version that load in 1.4 > >>>> This way people can load spec (the stable version for 1.4) in 1.4. > >>>> we can do it together. Now going to bed > >>>> > >>>> Stef > >>>> > >>>> On Jul 30, 2012, at 10:55 PM, Benjamin wrote: > >>>> > >>>>> NautilusRefactoring depends on Spec for the UI, that's all. > >>>>> > >>>>> But the problem is that in 2.0 a subclass can have an inst var named > like ones of its superclasses ... > >>>>> > >>>>> Ben > >>>>> > >>>>> > >>>>> On Jul 30, 2012, at 10:22 PM, StÃ©phane Ducasse wrote: > >>>>> > >>>>>> > >>>>>> On Jul 30, 2012, at 9:54 PM, Benjamin wrote: > >>>>>> > >>>>>>> > >>>>>>> On Jul 30, 2012, at 7:22 PM, StÃ©phane Ducasse wrote: > >>>>>>> > >>>>>>>> Yes I got bitten by that today this is a problem you should > remove the instance variable from the superclass then load and remove it > from buttonModel > >>>>>>>> and add it to its superclass. > >>>>>>>> Now I suggest not to use nautilus for 1.4. > >>>>>>> > >>>>>>> Why ? > >>>>>> > >>>>>> Indeed nautilus is not base on spec. > >>>>>> Still let us focus on 2.0 > >>>>>> > >>>>>> Stef > >>>>>> > >>>>>>> > >>>>>>> Ben > >>>>>>> > >>>>>>>> > >>>>>>>> Stef > >>>>>>>> > >>>>>>>> On Jul 30, 2012, at 7:02 PM, Patrik Sundberg wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Loading nautilus #stable in 1.4 I get: > >>>>>>>>> DuplicatedVariableError: helpHolder is already defined in > AbstractBasicWidget > >>>>>>>>> > >>>>>>>>> Looks to come when loading the dependency > Spec-Widgets-BenjaminVanRyseghem.48. > >>>>>>>>> > >>>>>>>>> Any ideas? > >>>>>>>>> > >>>>>>>>> I can provide more of the stack trace if it's useful (I'd assume > so), but would like a pointer what the best way to get that info in an > emailable format (not obvious to me how I can just copy-paste it). > >>>>>>>>> > >>>>>>>>> This is the summer release. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Patrik > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > >

July 31, 2012

[Pharo-project] [update 2.0] #20237

by Esteban Lorenzano

20237 ----- Issue 6451: New version of Spec http://code.google.com/p/pharo/issues/detail?id=6451 Issue 5661: Clean morphic EventHandler http://code.google.com/p/pharo/issues/detail?id=5661 Issue 6454: UndeclaredVariableWarning does not show location http://code.google.com/p/pharo/issues/detail?id=6454 Issue 6455: New version of CI http://code.google.com/p/pharo/issues/detail?id=6455 Issue 6471: Remove RMockSystemAnnouncer http://code.google.com/p/pharo/issues/detail?id=6471 Issue 6473: update comment in vm parameterAt: http://code.google.com/p/pharo/issues/detail?id=6473 Issue 6474: Improve senders http://code.google.com/p/pharo/issues/detail?id=6474

July 31, 2012

[Pharo-project] Possible FFI issue

by Diego Lont

Hi all, I am working with Friedrich on the ODBC issue, that the doubles aren't read correctly, and this is the point where I got by following the code: in the class: 'ByteArray' the function "doubleAt:" is implemented as a FFI-Kernel primitive. <primitive:'primitiveFFIDoubleAt' module:'<SqeakFFIPrims>'> In a version based on the seaside one click (Pharo v 1.3) this results in the correct double, but in the Pharo one click v1.4, this results in a double that is way too small. Writing a C program that makes the "same" api calls in ODBC also results in the correct values, although it gives an funny value for sqlTypLen (53). But we are kinda stuck here. Can someone give us the code of FFI, so we can continue debugging here, and possibly making a fix here? Also: does someone know what has changed between v1.3 and v1.4 in FFI, because both are loaded with the same Configuration. Thanks in advance for all the help, Diego Lont

July 31, 2012

Re: [Pharo-project] Loading Nautilus / Spec in 1.4

by StÃ©phane Ducasse

On Jul 31, 2012, at 11:47 AM, Benjamin wrote: > The last version loads in 1.4 if I remove the inst var duplication yes but for example we wanted to load versionner and this is not the client (the guy loading the other packages) that have to know. Anyway having duplicated instance variables is a bug so we should fix it. Are you at the lab? Stef > > > Ben > > On Jul 31, 2012, at 9:47 AM, StÃ©phane Ducasse wrote: > >> >> On Jul 31, 2012, at 4:14 AM, Benjamin wrote: >> >>> I will but when I publish a Spec version from 2.0, I can't know this kind of bug >> >> if you give me access to the spec repo I can do it. >> The point is that for 1.4 do you want to publish the newest version? I would not I would simply take the old version >> and make sure that it loads in 1.4 >> >> Stef >>> >>> Ben >>> >>> On Jul 30, 2012, at 11:15 PM, StÃ©phane Ducasse wrote: >>> >>>> ben >>>> may be you should just fix the problem as I did and publish a stable version that load in 1.4 >>>> This way people can load spec (the stable version for 1.4) in 1.4. >>>> we can do it together. Now going to bed >>>> >>>> Stef >>>> >>>> On Jul 30, 2012, at 10:55 PM, Benjamin wrote: >>>> >>>>> NautilusRefactoring depends on Spec for the UI, that's all. >>>>> >>>>> But the problem is that in 2.0 a subclass can have an inst var named like ones of its superclasses ... >>>>> >>>>> Ben >>>>> >>>>> >>>>> On Jul 30, 2012, at 10:22 PM, StÃ©phane Ducasse wrote: >>>>> >>>>>> >>>>>> On Jul 30, 2012, at 9:54 PM, Benjamin wrote: >>>>>> >>>>>>> >>>>>>> On Jul 30, 2012, at 7:22 PM, StÃ©phane Ducasse wrote: >>>>>>> >>>>>>>> Yes I got bitten by that today this is a problem you should remove the instance variable from the superclass then load and remove it from buttonModel >>>>>>>> and add it to its superclass. >>>>>>>> Now I suggest not to use nautilus for 1.4. >>>>>>> >>>>>>> Why ? >>>>>> >>>>>> Indeed nautilus is not base on spec. >>>>>> Still let us focus on 2.0 >>>>>> >>>>>> Stef >>>>>> >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> On Jul 30, 2012, at 7:02 PM, Patrik Sundberg wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Loading nautilus #stable in 1.4 I get: >>>>>>>>> DuplicatedVariableError: helpHolder is already defined in AbstractBasicWidget >>>>>>>>> >>>>>>>>> Looks to come when loading the dependency Spec-Widgets-BenjaminVanRyseghem.48. >>>>>>>>> >>>>>>>>> Any ideas? >>>>>>>>> >>>>>>>>> I can provide more of the stack trace if it's useful (I'd assume so), but would like a pointer what the best way to get that info in an emailable format (not obvious to me how I can just copy-paste it). >>>>>>>>> >>>>>>>>> This is the summer release. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Patrik >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

July 31, 2012