September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Status of Alien FFI

by David T. Lewis

On Tue, Sep 22, 2009 at 04:47:56PM -0700, John M McIntosh wrote: > > On 2009-09-22, at 4:16 PM, Ken Treis wrote: > > > Eliot, Johan, Fernando, et. al.: > > > > On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote: > > > >> Hi Ken, > >> > >> On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis <ken(a)miriamtech.com> > >> wrote: > >> Perhaps there would need to be new primitives for the basic size of > >> each relevant C type? I'm anxious to hear what Eliot might have to > >> say about this since he's got about 2000x more experience with this > >> than I do. > > I'll note the most modern squeak VM's return wordSize, this might be > helpful somewhere. > > wordSize > "Answer the size (in bytes) of an object pointer." > "Smalltalk wordSize" > > ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4] Actually, this is just the size of an object "pointer" in the object memory (i.e. BytesPerWord in ObjectMemory), which is independent of the size of a C pointer. So you would need new primitives to get at the underlying machine data types. The implementations are trivial if you are writing a plugin anyway, for example see #primitiveSizeOfPointer and #primitiveSizeOfInt in OSProcessPlugin. The "pointer" terminology referring to words the object memory is needlessly confusing, I guess we should clean that up one of these days. Dave

Sept. 23, 2009

[Pharo-project] Proposal for usable Smalltalk IDE

by empty

Hi, I'm a ten year Smalltalker, in spare time. I found most IDE are not usable at all. To enable usable an IDE I suggest separating info input service and edit service and mouse selection services. In short, each inputting area on any browser/inspector/explorer/etc should have a visible reference Letter and a floating inputting window for inputting service. On that window you type cd target-area-ref-letter return then the floating input window move to the target area waiting for user input and auto-complete/in-line edit things will be supported by inputting service here in the input window. When user return, the text is send to the target. Mousing/key board selecting/editing etc. will be handled by the current topic area and one get the input window back to work on. This could be think of as a modernized xterm in Smalltalk. (sorry I'm not a native English speaker) ----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://n2.nabble.com/Proposal-for-usable-Smalltalk-IDE-tp3696754p3696754.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 23, 2009

[Pharo-project] Deploying Seaside: A tutorial

by Miguel Enrique CobÃ¡ Martinez

I have to written a tutorial about deploying Seaside applications to production servers. The tutorial uses a simple application to test a setup with following components: Debian GNU/Linux lighttpd Magma server Magma seasideHelper Seaside 2.8 PharoCore You can find the tutorial here: http://miguel.leugim.com.mx/index.php/2009/09/18/deploying-seaside-applicat… http://miguel.leugim.com.mx/index.php/2009/09/22/deploying-seaside-install-… http://miguel.leugim.com.mx/index.php/2009/09/22/deploying-seaside-prepare-… http://miguel.leugim.com.mx/index.php/2009/09/22/deploying-seaside-populate… http://miguel.leugim.com.mx/index.php/2009/09/22/deploying-seaside-configur… Hopefully this will add to the collective knowledge and will answer some questions we all have had with respect to deploying Seaside. There are a couple of post that I must write yet, the SeasideProxyTester explanation and the load testing ones but you can have a fully configured setup to try and adapt to your needs. Critics and comments are welcome. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 23, 2009

Re: [Pharo-project] Status of Alien FFI

by John M McIntosh

I'll note the most modern squeak VM's return wordSize, this might be helpful somewhere. wordSize "Answer the size (in bytes) of an object pointer." "Smalltalk wordSize" ^[SmalltalkImage current vmParameterAt: 40] on: Error do: [4] On 2009-09-22, at 4:16 PM, Ken Treis wrote: > Eliot, Johan, Fernando, et. al.: > > On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote: > >> Hi Ken, >> >> On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis <ken(a)miriamtech.com> >> wrote: >> Perhaps there would need to be new primitives for the basic size of >> each relevant C type? I'm anxious to hear what Eliot might have to >> say about this since he's got about 2000x more experience with this >> than I do. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Sept. 22, 2009

Re: [Pharo-project] Status of Alien FFI

by Ken Treis

Eliot, Johan, Fernando, et. al.: On Sep 16, 2009, at 3:09 PM, Eliot Miranda wrote: > Hi Ken, > > On Wed, Sep 16, 2009 at 12:17 PM, Ken Treis <ken(a)miriamtech.com> > wrote: > Perhaps there would need to be new primitives for the basic size of > each relevant C type? I'm anxious to hear what Eliot might have to > say about this since he's got about 2000x more experience with this > than I do. > > are you using the 64-bit VM? If you're using a 32-bit VM on a 64- > bit platform then yu're using 32-bits and you'll be linking against > 32-bit libraries and hence nothing will have changed. At present I'm on a 32-bit VM, but I'm trying to build a package that'll work both on Squeak/Pharo and on GemStone/S 64. > > Alien has support for 64-bit values. Of course it uses the Windows > choice, short = 2, int unused as a name, long = 4, longLong = 8. e.g. > anAlien unsignedByteAt: oneRelativeIndex > anAlien unsignedShortAt: oneRelativeIndex > anAlien unsignedLongAt: oneRelativeIndex > anAlien unsignedLongLongAt: oneRelativeIndex > are the basic primitives for fetching unsigned integers. > > But this needs to be wrapped with something that selects the right > sizes based on the current platform and that's yet to be addressed. OK, I took a first stab at this. In Alien-Core-KenTreis.57, I added the a class variable that holds a dictionary of platform sizes, along with accessors on Alien class for sizeof(type)[1]. I am imagining that this dictionary could be populated with a primitive, but for now it has to be set by hand. Probably high time I learned how to build Squeak primitives, but deadlines are calling... I also added Alien>>signedIntAt:/put: and unsignedIntAt:/put:. Right now these assume you're on an IA32 architecture (heck, that's the name of the plugin). But at least they hide that detail from the CairoGraphics package, which can simply use `Alien sizeofInt` in offset calculations and `Alien sizeofPointer` when data structures don't align nicely on 8-byte boundaries. Other changes in this version: * Class-side convenience callout helpers on AlienLibrary (e.g. int:with:, void:withArguments:, etc). These defer their actual behavior to primitives on the singleton instance, but provide for (IMHO) cleaner invocation from other objects. * Flush the list of loaded libraries at image startup, like the original Alien package did, instead of doing it at image shutdown as later versions do. This lets you save the image without dropping all of your libraries and invalidating external references. * A couple of accessors on AlienWeakTable that let you find a registered object by tag (analogous to Dictionary>>keyAtValue:), remove by tag, and return a strong reference to everything that the table currently holds weakly. The Cairo package uses these when handles are explicitly released and when flushing handles at image startup. I'm lobbying for inclusion of all of these in the trunk, but I'll be glad to defer to the better judgement of the package maintainers if my code is determined to be wrong/misguided. At this point this all works for me, and works well enough that I can load CairoGraphics and my "alien lite" in GemStone, and the various pointers, data offsets, etc. are right for Linux/x86_64. [1] I know there were some accessors for a few types already, but it seemed odd to have implementors for both signedLongSize and unsignedLongSize since the size doesn't depend on the sign-edness. I liked the C-like use of sizeofLong, sizeofPointer, etc but am willing to defer to somebody else's judgement on these method names. -- Ken Treis Miriam Technologies, Inc.

Sept. 22, 2009

Re: [Pharo-project] errata for pharo by example

by csrabak＠bol.com.br

Are we going to produce a pharo-by-example image as well? Em 22/09/2009 03:40, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: You should load the PharoMorphic/DemoAndExamplePackage they should be added to pharo-dev On Sep 22, 2009, at 12:06 AM, Chris Kassopulo wrote: > pg 8 > > BouncingAtomsMorph new openInWorld > > Unknown variable: BouncingAtomsMorph > > > _______________________________________________ > 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

Sept. 22, 2009

Re: [Pharo-project] [squeak-dev] Mutation Testing

by Nicolas Chillo

John, Thanks for the application feedback. We will take a look at those bugs. We expect to have an oficial release at soon. Thanks again and congrats for your well programed test suite ;-) Nicolas Chillo On Tue, Sep 22, 2009 at 6:43 PM, Hernan Wilkinson < hernan.wilkinson(a)gmail.com> wrote: > Hi John > great! so you covered all the cases!!.... it means you are a great > programmer or mutation testing is not good :-) haha. > Seriously, it is great you could try it and thank you for the report. > We will check to see if we can do something to avoid changing the memory > ceiling. > > Bye, > Hernan. > > > On Tue, Sep 22, 2009 at 6:28 PM, John M McIntosh < > johnmci(a)smalltalkconsulting.com> wrote: > >> Although I didn't get to see the presentation on Mutation Testing at ESUG, >> I did have a chance to >> see it the following week after my XtC talk in London. At the time I had >> promised to try it out. >> >> http://www.slideshare.net/esug/mutation-testing >> >> My Fractions Calculator has 105 Sunits to confirm the keyboard state >> machine works, the calculator grammar via Smacc is sane, >> and the math results are as defined by either Wolfram Alpha, or Microsoft >> Excel rules. Actually the number of tests are 210 because they are >> subclassed for Excel, but running just the Wolfram Alpha based ones were >> sufficient to test the code base. >> >> I had two problems, one where the RBParser choked on >> #(#foo:. #bar:.) >> Oops the code really should have been #(#foo: #bar:) or {#foo:. #bar:.}, >> still it shouldn't have given a walkback. >> >> The second was that I had to increase the memory ceiling of the macintosh >> squeak carbon VM from 512MB to 1.5GB via the info.plist >> so that a recursive error situation would not make the VM run out of >> memory before the Mutation testing runtime monitor would kill the >> runaway task. >> >> As a result over the 105 SUnits it reported: >> >> It made 874 mutants, 873 got killed, 1 was terminated. >> >> Which means I don't have any head scratching this afternoon. >> >> -- >> >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> >> =========================================================================== >> >> >> >> >> >> > > > >

Sept. 22, 2009

Re: [Pharo-project] [squeak-dev] Mutation Testing

by Hernan Wilkinson

Hi John great! so you covered all the cases!!.... it means you are a great programmer or mutation testing is not good :-) haha. Seriously, it is great you could try it and thank you for the report. We will check to see if we can do something to avoid changing the memory ceiling. Bye, Hernan. On Tue, Sep 22, 2009 at 6:28 PM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > Although I didn't get to see the presentation on Mutation Testing at ESUG, > I did have a chance to > see it the following week after my XtC talk in London. At the time I had > promised to try it out. > > http://www.slideshare.net/esug/mutation-testing > > My Fractions Calculator has 105 Sunits to confirm the keyboard state > machine works, the calculator grammar via Smacc is sane, > and the math results are as defined by either Wolfram Alpha, or Microsoft > Excel rules. Actually the number of tests are 210 because they are > subclassed for Excel, but running just the Wolfram Alpha based ones were > sufficient to test the code base. > > I had two problems, one where the RBParser choked on > #(#foo:. #bar:.) > Oops the code really should have been #(#foo: #bar:) or {#foo:. #bar:.}, > still it shouldn't have given a walkback. > > The second was that I had to increase the memory ceiling of the macintosh > squeak carbon VM from 512MB to 1.5GB via the info.plist > so that a recursive error situation would not make the VM run out of memory > before the Mutation testing runtime monitor would kill the > runaway task. > > As a result over the 105 SUnits it reported: > > It made 874 mutants, 873 got killed, 1 was terminated. > > Which means I don't have any head scratching this afternoon. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > >

Sept. 22, 2009

[Pharo-project] Mutation Testing

by John M McIntosh

Although I didn't get to see the presentation on Mutation Testing at ESUG, I did have a chance to see it the following week after my XtC talk in London. At the time I had promised to try it out. http://www.slideshare.net/esug/mutation-testing My Fractions Calculator has 105 Sunits to confirm the keyboard state machine works, the calculator grammar via Smacc is sane, and the math results are as defined by either Wolfram Alpha, or Microsoft Excel rules. Actually the number of tests are 210 because they are subclassed for Excel, but running just the Wolfram Alpha based ones were sufficient to test the code base. I had two problems, one where the RBParser choked on #(#foo:. #bar:.) Oops the code really should have been #(#foo: #bar:) or {#foo:. #bar:.}, still it shouldn't have given a walkback. The second was that I had to increase the memory ceiling of the macintosh squeak carbon VM from 512MB to 1.5GB via the info.plist so that a recursive error situation would not make the VM run out of memory before the Mutation testing runtime monitor would kill the runaway task. As a result over the 105 SUnits it reported: It made 874 mutants, 873 got killed, 1 was terminated. Which means I don't have any head scratching this afternoon. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Sept. 22, 2009

Re: [Pharo-project] Less Complex Development Image

by StÃ©phane Ducasse

Ok we will probably remove it. stef On Sep 22, 2009, at 7:03 PM, Ken Dickey wrote: > Greetings, > > I was disappointed to download the latest development image and find > the old Complex cruft hanging around. > > Is there a compelling application that this enables? > > I would really prefer that the Complex class be removed from the 1.0 > candidate. > > Thanks for listening, > -KenD > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 22, 2009