- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 419 fixed (DNU: #spawnIt:)
by Torsten Bergmann Dec. 19, 2008

Dec. 19, 2008

see http://code.google.com/p/pharo/issues/detail?id=419 -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

1 0

[Pharo-project] Issue 418 fixed (DNU when hitting Cmd+o)
by Torsten Bergmann Dec. 19, 2008

Dec. 19, 2008

see http://code.google.com/p/pharo/issues/detail?id=418 -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

1 0

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

Dec. 18, 2008

I didn't understand a thing :-( I seem to have touched a sore spot, but I do not know what the background is. Can someone summarize? Technically and politically, what is the current status of Hydra, and what are our options for using it as a basis for multi-core Pharo? - on On Dec 18, 2008, at 10:08, stephane ducasse wrote: > Ok this is clearer now. > > Stef > > On Dec 18, 2008, at 9:40 AM, Klaus D. Witzel wrote: > >> On Thu, 18 Dec 2008 09:13:11 +0100, Stef wrote: >> >>> Klaus >>> >>> if you want to have a clear answer from esug: >> >> You're mixing up things here. If Pharo people want to run Hydra on >> their Mac, they could approach ESUG for funding. >> >>> - follow the process (cf the web page) >>> - write a clear request >> >> Since you (not me) would be the benefitor, go ahead. I was only the >> man who suggested the combination. Don't blame the messenger, don't >> put your work on him. Is this clear now? >> >>> So far it was a little mail about moebius and not Hydra. >> >> Yes, clear. But it is the same developer, namely Igor, who would do >> that for Pharo Mac users. >> >> Cheers, >> Klaus >> >>> Stef >>> >>> PS: ESUG has a board and we discuss and vote before taking decision. >> >> Really? ;) to me you seem to be more concerned about your own >> political attitude than about getting Hydra to the Mac/Pharo >> community. >> >> Please take notice that I know precisely how the democratic process >> in the ESUG board is supposed to work, no lecture necessary from >> your side. You are wasting time (not the first time with me). >> >>> 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 >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> >

3 2

[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

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

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