April 2010 - Pharo-dev - lists.pharo.org

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

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

by John M McIntosh

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 ===========================================================================

April 6, 2010

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

by Torsten Bergmann

>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

April 6, 2010

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

by Levente Uzonyi

On Tue, 6 Apr 2010, Mariano Martinez Peck wrote: > Thanks Torsten for reporting. I don't think this is a stopper for 1.0 at > all. > > We can release an older VM without that problem ? Even more because the new > version 4 doesn't bring anything new for Pharo. isn't it ? This should pass, shouldn't it? [ FileStream newFileNamed: 'foo.txt' do: [ :file | file position: 1. self assert: file next isNil. self assert: file atEnd ] ] ensure: [ FileDirectory default deleteFileNamed: 'foo.txt' ifAbsent: [] ] Levente > The only problem where ImageSegment...Ok, I rather to have working this > thing of closing the windows. > > Can you tell us exactly the link of the previous vm that was working ? > because we are doing the one-click now and we took the 4. > > Then, for 1.1 open a ticket so that someone try to fix the problem with the > version 4. > > Cheers > > Mariano > > On Tue, Apr 6, 2010 at 7:22 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> I think I've found something that should be fixed >> before releasing 1.0 since it is meanwhile a major problem on Windows. >> >> In "old" Squeak/Pharo you could close the native world window >> using the "X" or hit ALT+F4 on Windows and the system >> asked you if you really want to close the whole Smalltalk system >> using a native dialog which was provided by the VM. >> >> With the new VM's (4.0.1 and 4.0.2 on Windows, see [1]) the native >> "window close event" is now dispatched from the VM into >> the image so it could be handled by Smalltalk code. >> This is currently not done/handled in Pharo. Only in Squeak so far. >> >> The recent Squeak trunk/release candidate already handles the >> event within the image and now provides an in-image dialog >> to ask the user to quit. >> >> So: in Pharo now NOTHING happens when you try to close the window >> using "X", you can only quit using the world menu - which is IMHO really >> a show stopper since you cant close using "X" or ALT+F4 (the key >> combination to close any windows program). >> >> Two possible options: >> >> A) we should handle the event now in-image similar to Squeak >> by fixing and integration issue 2131 (see [2]), so not only >> for 1.1. but also for 1.0 >> >> B) release and distribute Pharo 1.0 with an old VM < 4.0 >> >> >> BTW: >> You can get the old behavior on Windows by additionally using SHIFT, so >> SHIFT + ALT + F4 allows to close. >> But this is not very convinient, doesnt follow what the typical >> Windows user expects and one has to know about it... >> >> Bye >> T. >> >> [1] >> http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/004142.html >> [2] http://code.google.com/p/pharo/issues/detail?id=2131 >> >> -- >> 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] SUnit (which tests call which methods?)

by Gabriel Brunstein

Given a set of tests you need to know which ones cover that method? is that what you want? We have a class to do that in MutationTesting package ( http://code.google.com/p/mutalk/) The class is called CoverageAnalysis. It has some tests to see how it works but you can ask me if you need help. On Tue, Apr 6, 2010 at 7:03 AM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > > Adrian Kuhn wrote: > > > > We got some more ideas (... search in test results) > > > > Is there a way to see which tests invoked a given method? Sometimes you're > trying to understand a method, to see if it does what you're trying to > achieve. In such cases, it would be really handy to see which tests used a > given method during a system-wide test, and then invoke one of those to > give > you a handle on the method. Does such a thing already exist? > > ...Stan > > > > > > Niko and me are thinking about doing some work on SUnit. > > > > Background is that we are working on Phexample, which extends SUnit with > > test > > that expand on one another [1]. We got test dependencies working with > the > > current SUnit, but had to do some quick ugly hacks. So we thought about > > cleaning the internals SUnit up, and then include test dependencies in > > the > > core. > > > > Things we would possible change (we will certainly identify more as we > > clean > > up SUnit...) > > > > - store test resources in a dynamic variable rather than a static one > > - refactor the assert: protocol to a trait, such that they can be used in > > setup and teardown of test resources as well (actually I already did > > that, > > you can find a version on my squeaksource account) > > - apply the fixes to test resources in Niall's slide deck that Lukas > > showed us > > - add expectations matchers as used in behavior-driven testing > > - break testcase into two classes, and to run the test and one to store > > the > > result (no more #cleanUpInstanceVariables hack to avoid memory leaks) > > - add test dependencies to test results, such that one test can extend on > > the > > return value of another test > > - fix expected failures such that they are a first-class result (no more > > #shouldPass with O(n^2) or worse behavior) > > > > So you see, the idea is twofold: first to clean up what is there, and > > second > > to add test dependencies as a new feature. For those that dont know test > > dependencies. They had first been proposed by Markus GÃ¤lli based on an > > analysis of all Squeak tests years ago. He found that most tests cover a > > superset of another test's coverage set. A prototype in Java as been > > implemented later by Lea HÃ¤nsenberger and me. We published a case study > > at > > XP 2008, which lead to PHP folks to include test dependencies in the > > latest > > PHPUnit. The idea of explicit test dependencies is to shift the burden > of > > isolating test cases from the developers to the framework. You avoid > > duplicate test code and you get less red test cases per failure. Please > > refer to Niko's blog post for more details [2]. > > > > We got some more ideas (such as API baseline testing, search in test > > results, > > etc...) but they will not likely make it into a first clean up. > > > > One thing we do not know is how many folks are out there that depend on > > internal representation of SUnit. I talked to some folks and identified > > two > > requirements, first that legacy tests should keep running and second > that > > contributions to other sunit forks should keep being mergeable. The > first > > seems feasible, the second sounds like it boils down to not cleaning > > anything :) > > > > What do you think? > > > > cheers, > > AA > > > > [1]: http://www.squeaksource.com/phexample.html > > [2]: > > > http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-ex… > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > View this message in context: > http://n4.nabble.com/SUnit-tp1297972p1752629.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.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] A small idea how to get closer to hardware with small efforts :)

by Marcus Denker

Hi, I always liked how Smalltalk X did it... they have -> an ivar in CompiledMethod that is the "native code pointer". -> Primitive methods are just methods that have this pointer set to the primitive in the vm. -> Methods with embedded C-code are compiled and linked with the Smtk->C cross-compiler, the pointer than points to that function -> the JIT just put a pointer to the code it generates. So they merge primitives / static compiling(+embedded c-code) *and* the JIT into one not that ugly mechanism. In STX, the memory is managed by the VM, though (the code is not allocated in the GCed object memory by the JIT). So: Yes, I like this :-) and your mechanism is a nice way to get it easily integrated into the current system. Q: what happens when code is moved by the GC? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 6, 2010

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

by Mariano Martinez Peck

2010/4/6 Torsten Bergmann <astares(a)gmx.de> > >open a ticket > > As I wrote, there is an issue 2131 already. > Sorry I missed that. > > >provide some tested code > > I can just provide an old changeset mixed up from Squeak code - > it works but I do not have tested or look if it merges correctly > with Pharo. At least it works, I dont like the "TheWorldMenu basicNew > quitSession" hack. > > Someone (with knowledge of the event handling system) should review > or enhance it (Marcus?). You will find it attached. > >I cannot do everything especially for platform I do not have access to. > > We should handle this in-image now for all platforms > since it is AFAIK this is now supported by all VM's. How is it done > on Mac and Linux these days? > > >Then, for 1.1 open a ticket so that someone try to fix the problem with > the > >version 4. > > There is already one: > http://code.google.com/p/pharo/issues/detail?id=2131 > > If we want to keep quality high we should care about this. > > yes, but not for 1.0 as it will be released TODAY (or tomorrow) So...which is the working Windows VM we should use for 1.0 ? the one before 4 version. > Bye > T. > > > -- > 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