- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Handle Close Event in Image - necessary for 1.0?

by StÃ©phane Ducasse

Torsten I appreciate your effort but we can only do what can be done in the time we can allocate to do a task if you see what I mean. I cannot test on windows because we do not have a windows machine. We are doing an incredible amount of work but we cannot do more than it is reasonable to do. Then in freeze time this is freeze time. we will try to get shorter iteration cycles and this is not by delaying 1.0 that we are making progress on that front. And this is not by saying that pharo "will be less quality than" ... more or less that it helps. So 1.0 will be like it can. And if people bash us this is ok too. You remember a while ago one guy asked who is ready to pay 10 Euros per month to have a better pharo and we got 6 persons.... > However I still believe that fixing this in 1.0 would not only > be a plus - it will also prevent questions regarding this > new problem since people WILL use newer VM's after the > first 1.0 release of Pharo and then instantly step into the problem! > > > And it is not a Windows specific problem as Stef thinks it is. > > Bert requested John today (see [1]) to change the default for Mac too ... TODAY. Imagine I was painting my house.... and this evening this would have to be fixed? When is the last time that a bug that annoys you on windows got fixed in one day? because for me on mac so far it took months. > so if you upgrade your Mac VM for whatever reason (maybe to do > 1.1 work or since you need a newer VM for a commercial project) > then you will step into this with the 1.0 image. Yes and since you are a good pharoers you will know and you will understand and help us and help yourself. > Guess what people think when Pharo tries to bring Squeak to a > better quality level and then would not be able to close the > system as usual after upgrading to a newer and better VM. > > But maybe my expectations for a 1.0 release are too high... > > Bye > T. > > > > [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 6, 2010

Re: [Pharo-project] Handle Close Event in Image - necessary for 1.0?

by Adrian Lienhard

Yes, there will certainly be other important fixes, which â together with the new close logic â are going into a 1.0.1 maintenance release. Cheers, Adrian On Apr 6, 2010, at 22:40 , StÃ©phane Ducasse wrote: > +1 > > On Apr 6, 2010, at 7:53 PM, Michael Roberts wrote: > >> 1.0 will be a maintained release. I suggest we push out 1.0 and >> schedule this fix for the first maintenance release. otherwise we will >> never get it out the door. from a process point of view, there will >> always be another important bug to fix. >> >> thanks, >> Mike >> >> On Tue, Apr 6, 2010 at 6:08 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> So...which is the working Windows VM we should use for 1.0 ? the one before >>>> 4 version. >>> >>> Last one before this change was introduced was the 3.11.8 Squeak VM >>> which I adapted for Pharo. You can download it from: >>> >>> https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip >>> >>> >>> However I still believe that fixing this in 1.0 would not only >>> be a plus - it will also prevent questions regarding this >>> new problem since people WILL use newer VM's after the >>> first 1.0 release of Pharo and then instantly step into the problem! >>> >>> >>> And it is not a Windows specific problem as Stef thinks it is. >>> >>> Bert requested John today (see [1]) to change the default for Mac too ... >>> so if you upgrade your Mac VM for whatever reason (maybe to do >>> 1.1 work or since you need a newer VM for a commercial project) >>> then you will step into this with the 1.0 image. >>> >>> Guess what people think when Pharo tries to bring Squeak to a >>> better quality level and then would not be able to close the >>> system as usual after upgrading to a newer and better VM. >>> >>> But maybe my expectations for a 1.0 release are too high... >>> >>> Bye >>> T. >>> >>> >>> >>> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html >>> >>> -- >>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 6, 2010

Re: [Pharo-project] Handle Close Event in Image - necessary for 1.0?

by StÃ©phane Ducasse

+1 On Apr 6, 2010, at 7:53 PM, Michael Roberts wrote: > 1.0 will be a maintained release. I suggest we push out 1.0 and > schedule this fix for the first maintenance release. otherwise we will > never get it out the door. from a process point of view, there will > always be another important bug to fix. > > thanks, > Mike > > On Tue, Apr 6, 2010 at 6:08 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> So...which is the working Windows VM we should use for 1.0 ? the one before >>> 4 version. >> >> Last one before this change was introduced was the 3.11.8 Squeak VM >> which I adapted for Pharo. You can download it from: >> >> https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip >> >> >> However I still believe that fixing this in 1.0 would not only >> be a plus - it will also prevent questions regarding this >> new problem since people WILL use newer VM's after the >> first 1.0 release of Pharo and then instantly step into the problem! >> >> >> And it is not a Windows specific problem as Stef thinks it is. >> >> Bert requested John today (see [1]) to change the default for Mac too ... >> so if you upgrade your Mac VM for whatever reason (maybe to do >> 1.1 work or since you need a newer VM for a commercial project) >> then you will step into this with the 1.0 image. >> >> Guess what people think when Pharo tries to bring Squeak to a >> better quality level and then would not be able to close the >> system as usual after upgrading to a newer and better VM. >> >> But maybe my expectations for a 1.0 release are too high... >> >> Bye >> T. >> >> >> >> [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html >> >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 6, 2010

[Pharo-project] Expacted Resource (RAM) requirements to run Pharo

by Rudi Ludwig

Hello, so I got interested in Smalltalk (again) installed Pharo and ran the ProfStef tutorial. I'm not a programmer, just interested :-) To be more precise, I followed the link on the Pharo homepage Download directory and installed from squeakvm.org/unix : Squeak-3.11.3.2135-solaris2.10_i386.tar.gz in - /usr/local/Squeak-3.11.3.2135-solaris2.10_i386 and from Pharo: Pharo-1.0-10515-rc3dev10.03.1 in my home directory. OS: OpenSolaris b127. Now while that worked --I can start Squeak (/usr/local/../bin/squeak.sh) chose the Pharo Image form the file browser that opens and go. Just following the integrated tutorial (ProfStef) and having maybe one more ClassBrowser open, at some point consumed 780 MB RAM (RSS). Question: Is that the expacted behavior (resource requirement) or is there something wrong with the steps I choose to run Pharo, although apparently they worked? There is a "PharoDebug.log" 180+kB large from that session, I can provide on request. (Didn't want to send it to whole list directly). Rudi

April 6, 2010

Re: [Pharo-project] Making the operating system close window event prompt for squeak window closure.

by StÃ©phane Ducasse

Hi john for the moment we do nothing but we are ready to do something if somebody explains what exactly. Stef On Apr 6, 2010, at 7:14 PM, John M McIntosh wrote: > Ok, before I do this I need to ask the Pharo folks if they handle the close window event. > To test someone can alter the info.plist setting as describe below and see what happens. > > > Begin forwarded message: > >> From: Bert Freudenberg <bert(a)freudenbergs.de> >> Date: April 6, 2010 3:35:26 AM PDT >> To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> >> Subject: Re: [Vm-dev] New Windows VM: 4.0.1 >> Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> >> >> >> On 28.03.2010, at 22:59, Andreas Raab wrote: >>> >>> >>> 1) The VM will now default to pass the window close event to the image instead of handling it directly. You can see that in a current trunk image by clicking on the close button (you'll now get a Squeak notifier instead of the previous VM notifier). The old behavior is still available if you SHIFT-Click on the close button. This is very useful if your image hangs. >> >> John, >> >> could you change the default for the Mac VM too? Both Linux and Windows VMs now deliver the window event rather than killing the image. >> >> For Etoys we use >> >> SqueakWindowAttribute <8200001f> >> >> in the VM's Info.plist. That at least enables the red window close button (though "Quit" from the dock menu does not work). >> >> - Bert - >> >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 6, 2010

Re: [Pharo-project] Problem loading Exupery on PharoCore 1.0

by Javier PimÃ¡s

Not sure with this either, but I think it comes from a bug related to squeak and pharo syntax. Pharo admits a slightly modified Squeak syntax, probably this code that didn't compile was commited in Squeak and was perfectly valid there. When this happens, you get that window indicating the syntax error. If you change the code and then accept it, you get past this step, but then it fails in the place you are seeing now. Maybe there is a bug report for this problem already. To get out of it right now... maybe Bryce can commit the fixed code from squeak and you won't have the problem, or you can debug it and try to find the place in where nil appears (the error pops because its sending #methodClass: to nil). Remember, all this would be true if it is the error I think it is. Regards, Javier. 2010/4/6 laurent laffont <laurent.laffont(a)gmail.com> > 2010/4/5 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > > maybe you could try separating with spaces the elements of the array, I >> think I had a similar problem once, don't know if it is the case: >> >> #( (block 1 (mov (literalVariableAddress 10) t1) ) ) >> > > > Thanks Javier. I just have to put a space between mov and ( > (really strange). > > Then I have this error. I've tried with last Exupery and > Exupery-wbk.335.mcz. > > UndefinedObject(Object)>>doesNotUnderstand: #methodClass: > IntermediateSimplifierTests class(Behavior)>>basicAddSelector:withMethod: > IntermediateSimplifierTests > class(Behavior)>>methodDictAddSelectorSilently:withMethod: > IntermediateSimplifierTests > class(Behavior)>>addSelectorSilently:withMethod: > IntermediateSimplifierTests > class(ClassDescription)>>addSelectorSilently:withMethod: > MethodAddition>>installMethod > [] in [] in [] in MCPackageLoader>>basicLoad > OrderedCollection>>do: > [] in [] in MCPackageLoader>>basicLoad > BlockClosure>>on:do: > [] in MCPackageLoader>>basicLoad > BlockClosure>>ensure: > MCPackageLoader>>basicLoad > [] in MCPackageLoader>>loadWithNameLike: > [] in MCPackageLoader>>useChangeSetNamed:during: > BlockClosure>>ensure: > MCPackageLoader>>useChangeSetNamed:during: > MCPackageLoader>>useNewChangeSetNamedLike:during: > MCPackageLoader>>loadWithNameLike: > MCVersionLoader>>loadWithNameLike: > MCVersionLoader>>load > GoferLoad>>execute > Gofer>>execute:do: > Gofer>>execute: > Gofer>>load > > Laurent Laffont > > >> >> Regards, >> Javier. >> >> >> On Sun, Apr 4, 2010 at 9:49 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: >> >>> Maybe a non-visible character? >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 4 Apr 2010, at 04:32, laurent laffont wrote: >>> >>> I do: >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfMondrian'; >>>> load.. >>>> >>>> ConfigurationOfMondrian project latestVersion load. >>>> >>>> Then >>>> >>>> Gofer new >>>> squeaksource: 'Exupery'; >>>> package: 'Exupery'; >>>> load. >>>> >>>> ==> Syntax Error >>>> >>>> testLiteralVariableAddress >>>> source := MedMethod >>>> createIntermediate: >>>> #((block 1 >>>> (mov(literalVariableAddress 10) t1) )Nothing more expected ->) >>>> for: machine. >>>> mockEmitter expectEmission: >>>> #( (block1 >>>> (mov #(#emitFetchAddress 1 >>>> #(#simplifiedLiteralAddress 10)) t1)) >>>> (block2) ). >>>> >>>> self simplifyFullyMocked. >>>> >>>> self verify. >>>> mockEmitter verify. >>>> >>>> >>>> Laurent Laffont >>>> >>>> >>>> On Sun, Apr 4, 2010 at 10:26 AM, laurent laffont < >>>> laurent.laffont(a)gmail.com> wrote: >>>> OK Thanks. I will try. Would be cool to have a ConfigurationOfExupery >>>> :). >>>> >>>> Laurent Laffont >>>> >>>> >>>> On Sun, Apr 4, 2010 at 10:19 AM, Tudor Girba <tudor.girba(a)gmail.com> >>>> wrote: >>>> Hi Laurent, >>>> >>>> Something is wrong. MOAbstractLayout and MOGraphVizLayout come from >>>> Mondrian. Were these by mistake somehow added as dependencies to Exupery? >>>> Doru >>>> >>>> >>>> >>>> On 4 Apr 2010, at 10:06, laurent laffont wrote: >>>> >>>> Hi, >>>> >>>> I want to try to build Exupery VM. On PharoCore 1.0 I do: >>>> >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfVMMaker'; >>>> load. >>>> >>>> (ConfigurationOfVMMaker project version: '1.2') load. >>>> >>>> Then >>>> >>>> Gofer new >>>> squeaksource: 'Exupery'; >>>> package: 'Exupery'; >>>> load. >>>> >>>> I have this error: >>>> >>>> This package depends on the following classes: >>>> MOAbstractLayout >>>> You must resolve these dependencies before you will be able to load >>>> these definitions: >>>> MOGraphVizLayout >>>> MOGraphVizLayout>>doExecute: >>>> MOGraphVizLayout>>findTopLeftCorner: >>>> >>>> >>>> I suppose I need GraphViz package >>>> >>>> Gofer new >>>> squeaksource: 'GraphViz'; >>>> package: 'GraphViz'; >>>> load. >>>> >>>> But when I load it I have a Syntax Error: >>>> >>>> runWithSystemFramework: string >>>> <> expected ->apicall: short 'system' (char*) module: >>>> 'System.framework'> >>>> >>>> ^ self externalCallFailed >>>> >>>> Laurent Laffont >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "It's not how it is, it is how we see it." >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Javier PimÃ¡s Ciudad de Buenos Aires

April 6, 2010

Re: [Pharo-project] FFI+Linux+double return value

by Schwab,Wilhelm K

Nicolas, I am running this on Ubuntu (9.10) and have been using the Pharo 0.15.2f vm. I just tried a Squeak vm (3.11-3) and could not get it to load my library. I have been using an absolute path the the .so; could that be the problem with the Squeak vm?? There has been a lot of discussion of the Pharo Linux vm lately, with some links and corrections, so I'll have to look around a little. You asked if I can check the vm sources; the concern is whether or not I will have anything to add :) Is there something specific you want me to do? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Tuesday, April 06, 2010 1:46 PM To: Pharo-project(a)lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: [Pharo-project] FFI+Linux+double return value Hello all, I had some strange results with double return values and boiled it down to a C function Double AnyDouble() { return 1.0; } called via anyDouble < cdecl: double 'AnyDouble' () > and driven by | out | out := Array writeStream. 100 timesRepeat:[ out nextPut:Library default anyDouble ]. out contents. The results are not good. It works for the first three elements, after which it produces NaN. The real problem appears to be comparison of floats being broken after that point, as evidenced by a walkback that arises when trying to inspect the resulting collection - exploring it works. I need to try this on the latest image/vm, but wanted to start gathering opinions. Any ideas? Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 6, 2010

Re: [Pharo-project] Problem loading Exupery on PharoCore 1.0

by laurent laffont

2010/4/5 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > maybe you could try separating with spaces the elements of the array, I > think I had a similar problem once, don't know if it is the case: > > #( (block 1 (mov (literalVariableAddress 10) t1) ) ) > Thanks Javier. I just have to put a space between mov and ( (really strange). Then I have this error. I've tried with last Exupery and Exupery-wbk.335.mcz. UndefinedObject(Object)>>doesNotUnderstand: #methodClass: IntermediateSimplifierTests class(Behavior)>>basicAddSelector:withMethod: IntermediateSimplifierTests class(Behavior)>>methodDictAddSelectorSilently:withMethod: IntermediateSimplifierTests class(Behavior)>>addSelectorSilently:withMethod: IntermediateSimplifierTests class(ClassDescription)>>addSelectorSilently:withMethod: MethodAddition>>installMethod [] in [] in [] in MCPackageLoader>>basicLoad OrderedCollection>>do: [] in [] in MCPackageLoader>>basicLoad BlockClosure>>on:do: [] in MCPackageLoader>>basicLoad BlockClosure>>ensure: MCPackageLoader>>basicLoad [] in MCPackageLoader>>loadWithNameLike: [] in MCPackageLoader>>useChangeSetNamed:during: BlockClosure>>ensure: MCPackageLoader>>useChangeSetNamed:during: MCPackageLoader>>useNewChangeSetNamedLike:during: MCPackageLoader>>loadWithNameLike: MCVersionLoader>>loadWithNameLike: MCVersionLoader>>load GoferLoad>>execute Gofer>>execute:do: Gofer>>execute: Gofer>>load Laurent Laffont > > Regards, > Javier. > > > On Sun, Apr 4, 2010 at 9:49 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > >> Maybe a non-visible character? >> >> Cheers, >> Alexandre >> >> >> On 4 Apr 2010, at 04:32, laurent laffont wrote: >> >> I do: >>> Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: 'ConfigurationOfMondrian'; >>> load.. >>> >>> ConfigurationOfMondrian project latestVersion load. >>> >>> Then >>> >>> Gofer new >>> squeaksource: 'Exupery'; >>> package: 'Exupery'; >>> load. >>> >>> ==> Syntax Error >>> >>> testLiteralVariableAddress >>> source := MedMethod >>> createIntermediate: >>> #((block 1 >>> (mov(literalVariableAddress 10) t1) )Nothing more expected ->) >>> for: machine. >>> mockEmitter expectEmission: >>> #( (block1 >>> (mov #(#emitFetchAddress 1 >>> #(#simplifiedLiteralAddress 10)) t1)) >>> (block2) ). >>> >>> self simplifyFullyMocked. >>> >>> self verify. >>> mockEmitter verify. >>> >>> >>> Laurent Laffont >>> >>> >>> On Sun, Apr 4, 2010 at 10:26 AM, laurent laffont < >>> laurent.laffont(a)gmail.com> wrote: >>> OK Thanks. I will try. Would be cool to have a ConfigurationOfExupery :). >>> >>> Laurent Laffont >>> >>> >>> On Sun, Apr 4, 2010 at 10:19 AM, Tudor Girba <tudor.girba(a)gmail.com> >>> wrote: >>> Hi Laurent, >>> >>> Something is wrong. MOAbstractLayout and MOGraphVizLayout come from >>> Mondrian. Were these by mistake somehow added as dependencies to Exupery? >>> Doru >>> >>> >>> >>> On 4 Apr 2010, at 10:06, laurent laffont wrote: >>> >>> Hi, >>> >>> I want to try to build Exupery VM. On PharoCore 1.0 I do: >>> >>> Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: 'ConfigurationOfVMMaker'; >>> load. >>> >>> (ConfigurationOfVMMaker project version: '1.2') load. >>> >>> Then >>> >>> Gofer new >>> squeaksource: 'Exupery'; >>> package: 'Exupery'; >>> load. >>> >>> I have this error: >>> >>> This package depends on the following classes: >>> MOAbstractLayout >>> You must resolve these dependencies before you will be able to load these >>> definitions: >>> MOGraphVizLayout >>> MOGraphVizLayout>>doExecute: >>> MOGraphVizLayout>>findTopLeftCorner: >>> >>> >>> I suppose I need GraphViz package >>> >>> Gofer new >>> squeaksource: 'GraphViz'; >>> package: 'GraphViz'; >>> load. >>> >>> But when I load it I have a Syntax Error: >>> >>> runWithSystemFramework: string >>> <> expected ->apicall: short 'system' (char*) module: >>> 'System.framework'> >>> >>> ^ self externalCallFailed >>> >>> Laurent Laffont >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> www.tudorgirba.com >>> >>> "It's not how it is, it is how we see it." >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 6, 2010

[Pharo-project] FFI+Linux+double return value

by Schwab,Wilhelm K

Hello all, I had some strange results with double return values and boiled it down to a C function Double AnyDouble() { return 1.0; } called via anyDouble < cdecl: double 'AnyDouble' () > and driven by | out | out := Array writeStream. 100 timesRepeat:[ out nextPut:Library default anyDouble ]. out contents. The results are not good. It works for the first three elements, after which it produces NaN. The real problem appears to be comparison of floats being broken after that point, as evidenced by a walkback that arises when trying to inspect the resulting collection - exploring it works. I need to try this on the latest image/vm, but wanted to start gathering opinions. Any ideas? Bill

April 6, 2010

Re: [Pharo-project] Handle Close Event in Image - necessary for 1.0?

by Michael Roberts

1.0 will be a maintained release. I suggest we push out 1.0 and schedule this fix for the first maintenance release. otherwise we will never get it out the door. from a process point of view, there will always be another important bug to fix. thanks, Mike On Tue, Apr 6, 2010 at 6:08 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >>So...which is the working Windows VM we should use for 1.0 ? the one before >>4 version. > > Last one before this change was introduced was the 3.11.8 Squeak VM > which I adapted for Pharo. You can download it from: > > https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip > > > However I still believe that fixing this in 1.0 would not only > be a plus - it will also prevent questions regarding this > new problem since people WILL use newer VM's after the > first 1.0 release of Pharo and then instantly step into the problem! > > > And it is not a Windows specific problem as Stef thinks it is. > > Bert requested John today (see [1]) to change the default for Mac too ... > so if you upgrade your Mac VM for whatever reason (maybe to do > 1.1 work or since you need a newer VM for a commercial project) > then you will step into this with the 1.0 image. > > Guess what people think when Pharo tries to bring Squeak to a > better quality level and then would not be able to close the > system as usual after upgrading to a newer and better VM. > > But maybe my expectations for a 1.0 release are too high... > > Bye > T. > > > > [1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-April/004218.html > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 6, 2010