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

[Pharo-project] [update] #10196
by Marcus Denker Dec. 18, 2008

Dec. 18, 2008

Issue 270: remove TranslatedMethod Issue 414: randomcleans Issue 416: remove preference #simpleHalosInForce Issue 417: remove CustomEventsRegistry Issue 415: instVarNamed speedup Issue 412: update button for FontChooser Removed: - TranslatedMethod - method updateReferencesUsing: everywhere PasteUpMorph #viewingByNameString Morph #downshiftedNameOfObjectRepresented #nameOfObjectRepresented #randomBoundsFor: Preferences class #simpleHalosInForce -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

Re: [Pharo-project] Parsing problem
by Bill Schwab Dec. 18, 2008

Dec. 18, 2008

Stef, FWIW, my biggest priority is to be able to use underscores in class and method names (very useful when talking to the outside world - I don't care if it's ugly, it works<g>). Pharo will help me reduce Microsoft's influence over my future, but while one source of underscores goes away, things like GSL and other libraries becoming increasingly important to me are littered with them. Many "details" along the way would apparently go away if the compiler and image stopped abusing $_. To those who insist that it saves them time, I have long asserted, and continue to do so, that the editor can map _ to := for them, as well as take out a preceding colon when deleting $=. Done. The compiler gets its sanity back, and they type one character for assignment. Does that help at all?? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 12/18/08 11:36 AM >>> Thanks gwenael I will intergrate your fix. Now pharoers what do we do with _ and external code using [ : x instead of [:x for _ Gwenael proposed to have the parser been able to parse and fix the _ into := but also to be able to have a strict parser. For :x we should have a parser that reject : x code. But what do you think On Dec 18, 2008, at 5:05 PM, Gwenael Casaccio wrote: > Hi, > > I've discussed with Stephane and may be we can fix all the methods > that have : > _ instead of := > or some methods have [ : myArg ... ] instead of [ :myArg .... ] > > So we can use a parser that strictly check that we respect grammar. > There is in this mail an attach file that contains the list of the > classes and > methods that are not corrects. > > Cheers, > Gwenael Casaccio > > > > <parsingerrors.txt.zip>_______________________________________________ > 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

3 2

Re: [Pharo-project] Parsing problem
by Bill Schwab Dec. 18, 2008

Dec. 18, 2008

+1. Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> renggli(a)gmail.com 12/18/08 12:34 PM >>> > I've discussed with Stephane and may be we can fix all the methods that have : > _ instead of := > or some methods have [ : myArg ... ] instead of [ :myArg .... ] I agree that the use of := should be enforced. I would also like to be able to use _ in names. However: The parser should allow spaces after the $: in block arguments. This is essentially the same syntax as for keyword method declarations without a keyword and there you also allow arbitrary spaces after the colon (normally you even put them there). So I understand when people write block arguments the same way as they do for keyword method declarations: to: stop by: step ... [ : stop : step | ... ] > So we can use a parser that strictly check that we respect grammar. > There is in this mail an attach file that contains the list of the classes and > methods that are not corrects. All Smalltalk allow spaces after the $: in blocks. Disallowing this makes porting unnecessary hard. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] [ANN] iStoa.net v. 8.12-alpha1
by Hilaire Fernandes Dec. 18, 2008

Dec. 18, 2008

For our Pharo friends, iStoa.net is Phara based, and it is shipped with Seaside and Magma. Hilaire Le but du projet iSTOA.net est le dÃ©veloppement d'une plateforme pÃ©dagogique d'activitÃ©s interactives et de suivi par Internet. Il est multiplateforme et libre sous licence MIT. http://www.istoa.net QUOI DE NEUF DANS LA VERSION 8.12-alpha1 ? - RÃ©solution des bugs #6936, #6937, #6973, #6939 https://gforge.inria.fr/tracker/?atid=6332&group_id=1308 - Version basÃ©e sur Pharo #10192: rendu des fontes avec le plugin FreeType, vÃ©rifications et modifications de Pharo pour compatibilitÃ© avec la derniÃ¨re version stable 41.1 de Magma. - Refactorisation du code. Correction sur certains exercices. QUE TROUVE-T-ON DANS LA VERSION 8.12-alpha1 ? - Console web du maÃ®tre pour gÃ©rer les classes, groupes, Ã©lÃ¨ves, devoirs, et pour consulter les traces des Ã©lÃ¨ves. - Base de donnÃ©es objet pour enregistrer l'activitÃ© des Ã©lÃ¨ves. - Plus de 40 activitÃ©s (Ã©tayages pÃ©dagogiques) avec 160 exercices sur le thÃ¨me de la multiplication au cycle 3 (CE2 plus prÃ©cisÃ©ment). - Un Ã©diteur notionnel pour visualiser le modÃ¨le sous-jacent. Il permet en un coup d'oeil de visualiser les relations entre notions et activitÃ©s. En outre il permet Ã la fois l'Ã©valuation des activitÃ©s et leur modification. AIDER LE PROJET Que vous soyez enseignant ou non, je suis trÃ¨s intÃ©ressÃ© par vos impressions, remarques, suggestions d'amÃ©liorations portant sur les activitÃ©s. Je les intÃ©grerai pour la prochaine version. Contacter hilaire(a)ofset.org. OBJECTIFS DU PROJET A terme, la plateforme est destinÃ©e aux enseignements de mathÃ©matiques et de franÃ§ais de cycle 3 de l'Ã©cole primaire. Son utilisation est multiple : utilisation en classe, utilisation Ã la maison ou en remÃ©diation avec suivi diffÃ©rÃ© par l'enseignant pour "rejouer" les activitÃ©s de l'Ã©lÃ¨ve. Chaque acte de l'apprenant est enregistrable dans une base de donnÃ©es, dans un rÃ©seau local ou sur Internet. -- http://blog.ofset.org/hilaire

1 0

[Pharo-project] Fwd: [squeak-dev] Cog VM status update
by StÃ©phane Ducasse Dec. 18, 2008

Dec. 18, 2008

Begin forwarded message: > From: Andreas Raab <andreas.raab(a)gmx.de> > Date: December 17, 2008 4:30:30 AM CEST > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: [squeak-dev] Cog VM status update > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > Folks - > > I just read Eliot's most recent blog post about the Cog VM and it > reminded me how difficult it must be for others to see where this > project stands. So here is a bit of an update on the current status: > > As you may recall we started this project in spring this year by > hiring Eliot for the express purpose of building us a new VM that > would speed up execution of our products. We decided to structure > the work into stages at the end of each there would be a tangible > deliverable i.e., a new VM that could be run and benchmarked. > > The first stage in this process is what we call the "Closure VM". It > is nothing more (and nothing less) than a Squeak VM with closures > and the required support (compiler, decompiler, debugger etc). Given > past experience, we had originally expected this stage to cost us > some speed (up to 20% were estimated) since closure support has a > cost which at that stage is hard to offset with other improvements. > However, thanks to a truly ingenious bit of engineering done by > Eliot in the design for the closure implementation the resulting > speed difference was negligible. Since there was no speed penalty we > decided to jump ship earlier than we originally anticipated and the > Closure VM has been the regular shipping VM with Qwaq products since > September this year. > > The second stage in the process is the "Stack VM". It is a Closure > VM that executes on the native stack and transparently maps contexts > from and to stack frames as required. The VM itself is still an > interpreter so any speed improvements come purely from the more > efficient organization of the stack layout (no allocations, > overlapping frames etc). For those of you having been around for > long enough it is equivalent to what Anthony Hanan did a few years > ago, except that it hides the existence of the native stack entirely > and gives the programmer the naive view of just dealing with linked > frames (contexts). The original expectations for the resulting > speedups by Eliot were a little higher than we've seen in practice, > but are in line with the results that Anthony got: approx. 30% > improvements across the board in macro benchmarks. The work on the > Stack VM was completed last month, we are currently rolling it out > internally and the next product release will ship with the Stack VM. > > The third stage which has just begun is what we call the "Simple JIT > VM" (well, really it doesn't have a name yet, I just made it up ;-) > Its focus is send performance (as we see send performance as the > single biggest current bottleneck). It will sport a very simple JIT > w/ inline caches with the idea being to bring up send performance to > the point where it's no longer the single biggest bottleneck, then > measure performance again and figure out what the next best target > is. I am not going to speculate on performance (we have been wrong > every single step of the way ;-) but both Eliot and I do think that > we'll see some nice improvements in application performance here. > > The fourth stage is a bit more speculation at this point because the > concrete direction depends on what the results of stage 3 really > show the new bottleneck to be. We have various candidates lined up: > Very high on the list is a delayed code generator which can > dramatically improve the code quality. Next to it are changes in the > object format moving to a unified 32/64bit header model which would > dramatically simplify some tests for inline caching and primitives > etc. However, since this work is driven by product performance, it > is possible (albeit unlikely at this point) that the focus might > shift towards FFI speed or float inlining. There is no shortage of > possible directions, the main issue will be to figure out what the > bottlenecks at that point are and how to address them most > efficiently. > > Stage four won't be the end of it, but from where we are this is how > far we've planned at this point. And if you want to know all the > gory details about the stuff that Eliot's working on, please do > check out his blog at: > > http://cogblog.mirandabanda.org/ > > Cheers, > - Andreas > > > >

1 0

[Pharo-project] Fwd: Multi-core Pharo?
by StÃ©phane Ducasse Dec. 18, 2008

Dec. 18, 2008

> > Ok this is clearer now. > > Stef

1 0

[Pharo-project] [update] #10194
by Marcus Denker Dec. 18, 2008

Dec. 18, 2008

Issue 410: Fix Object>>beep -> Beeper beep Issue 406: fixes for some methods to make the parsable with newparser Issue 402: MessageNode>>noteSpecialSelector: contains SQ2K legacy Issue 403: yet another etoy cleanup changeset Methods removed: ---------------- UpdatingStringMorph #variableDocks Presenter #toolToViewScriptInstantiations PasteUpMorph #showStatusOfAllScripts AlignmentMorph #addUpDownArrowsFor: Classes removed: ---------------- AllScriptsTool CardPlayer CategoryViewer TileMorph VariableDock -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

2 2

Dec. 18, 2008

Klaus if you want to have a clear answer from esug: - follow the process (cf the web page) - write a clear request So far it was a little mail about moebius and not Hydra. Stef PS: ESUG has a board and we discuss and vote before taking decision. On Dec 17, 2008, at 7:58 PM, Klaus D. Witzel wrote: > Hi Alex, > > I'm sorry I'm just a frequent reader of the Pharo mailing list, so > here's my response by email. Feel free to forward it. > > On Wed, 17 Dec 2008 15:11:52 +0100, you wrote: > >> Hi Igor and Klaus, >> >> Having a description about Hydra will really help promoting your >> project. >> Maybe we could continue what I started to write... > > The Hydra VM is usable as is and in production, serving heavy used > Croquet site, IIRC. Hydra has everything you need for the Multi-core > VM of Squeak: > > - launch and control multiple .images in native threads > - control these threads from the Smalltalk language level > - communicate beween .images through channels > - any number of related/unrelated .images can be run > > What is not done yet (Igor would correct me) is making Hydra > available on Mac and Linux(en). > > In light of recent discussion with Stef about ESUG founding, I would > suggest you perhaps consider to make Hydra available for you Mac > users. > > Cheers, > Klaus > > P.S. Alex the "rest" of the discussion you recalled above (the paper > you suggested) is about a very particular use of Hydra technology, > formost for and by enthusiastic VM engineers to be "the first" who > get it going. Hydra can do and does well without all that (without > the cloning of object subgraphs "baby Hydras" from the > running .image): just save an .image file and then start it up in > Hydra. > >> Alexandre >> >> On 17 Dec 2008, at 09:52, Oscar Nierstrasz wrote: >> >>> >>> Hi folks, >>> >>> Has anyone looked at the Qwac Hydra stuff? >>> >>> http://www.qwaq.com/HydraVM/ >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-February/125719… >>> >>> There was quite a lot of discussion on squeak-dev ast February, but >>> not much since then. >>> >>> I would really love to see a multi-core Pharo. If someone has an >>> idea >>> how this could be done, I would be interested to learn more. I >>> think >>> getting Pharo to exploit multi-cores could be a big selling point in >>> the future ... >>> >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > >

1 0

Re: [Pharo-project] Multi-core Pharo?
by Igor Stasenko Dec. 18, 2008

Dec. 18, 2008

2008/12/17 Klaus D. Witzel <klaus.witzel(a)cobss.ch>: > Hi Alex, > > I'm sorry I'm just a frequent reader of the Pharo mailing list, so here's my > response by email. Feel free to forward it. > > On Wed, 17 Dec 2008 15:11:52 +0100, you wrote: > >> Hi Igor and Klaus, >> >> Having a description about Hydra will really help promoting your project. >> Maybe we could continue what I started to write... > > The Hydra VM is usable as is and in production, serving heavy used Croquet > site, IIRC. Really? I didn't heard about that. I wouldn't recommend to use it in production before extensively testing the different plugins which has to be changed to work in multiple threads. I can only say, that after few hiccups, i managed to run Qwaq Forums image (networking + graphics + ffi + sound + ... ) . It proves that for main image, things are more or less comparable to original Squeak VM. But there is no such guarantees for multiple images in multiple threads - this requires serious testing before using in production. > Hydra has everything you need for the Multi-core VM of Squeak: > > - launch and control multiple .images in native threads > - control these threads from the Smalltalk language level > - communicate beween .images through channels > - any number of related/unrelated .images can be run > > What is not done yet (Igor would correct me) is making Hydra available on > Mac and Linux(en). > There is initial port on Mac, made by John. Some parts made by Matthew for linux but didn't finished. The main work is to visit all C sources and make them compatible with Hydra. Also , make plugin code be able to work with multiple threads. > In light of recent discussion with Stef about ESUG founding, I would suggest > you perhaps consider to make Hydra available for you Mac users. > > Cheers, > Klaus > > P.S. Alex the "rest" of the discussion you recalled above (the paper you > suggested) is about a very particular use of Hydra technology, formost for > and by enthusiastic VM engineers to be "the first" who get it going. Hydra > can do and does well without all that (without the cloning of object > subgraphs "baby Hydras" from the running .image): just save an .image file > and then start it up in Hydra. > >> Alexandre >> >> On 17 Dec 2008, at 09:52, Oscar Nierstrasz wrote: >> >>> >>> Hi folks, >>> >>> Has anyone looked at the Qwac Hydra stuff? >>> >>> http://www.qwaq.com/HydraVM/ >>> >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-February/125719… >>> >>> There was quite a lot of discussion on squeak-dev ast February, but >>> not much since then. >>> >>> I would really love to see a multi-core Pharo. If someone has an idea >>> how this could be done, I would be interested to learn more. I think >>> getting Pharo to exploit multi-cores could be a big selling point in >>> the future ... >>> >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > > -- Best regards, Igor Stasenko AKA sig.

1 0

[Pharo-project] alien os-x plugin goes to 1.1.0
by John M McIntosh Dec. 18, 2008

Dec. 18, 2008

I've updated the os-x alien plugin for powerpc and macintel, it is found on the usual sites via http://www.smalltalkconsulting.com/squeak.html in the Experimental directory as IA32ABI.1.1.0.bundle.zip The macintel flavour supports the ability to call foreign entry points with any type of data and the ability to callback to smalltalk code from the entered routine, plus the ability to get/set bytes, shorts, longs, float, and doubles. The powerpc flavour supports the ability to call foreign entry points with any type of data, and the ability to get/set bytes, shorts, longs, float, and doubles. Hopefully tomorrow I can look into the callback logic and propose some code/ assembler to enable that feature. It does btw run on 10.4 powerpc G3 machines now. There was a number of structural changes required enable the typeless Alien api to understand it must work with a floating point signature array that indicates how to deal with Float or Double data. I also added the ability to pass not only Alien and Integer data but also to pass Float/ Double objects as parm data. I note Squeak maintains floating point numbers as a Double. If you pass that as a Float by indicating that in the signature data (4 bytes versus 8 bytes) we convert the number from a double to a float before passing to the routine. On return the Alien api makes you explicitly indicate if the value is a double, integer, or float. Users should be aware it's possible to call a routine that returns a double but ask for a Float back. This might lead to unexpected numerical issues. Please ensure the size of the floating point value you want to return matches the function's actual return type. Lastly passing the wrong sized floating point values as parms (say a Float) versus an expected Double, will result in confused behaviour, or VM crashes as we are building the parm stack area based on information from the float signature array which must then match what the routine expects the stack to look like. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0