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

Re: [Pharo-project] Parsing problem

by StÃ©phane Ducasse

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

Dec. 18, 2008

[Pharo-project] Parsing problem

by Gwenael Casaccio

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

Dec. 18, 2008

Re: [Pharo-project] Multi-core Pharo?

by Igor Stasenko

2008/12/18 Oscar Nierstrasz <oscar(a)iam.unibe.ch>: > > 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? > First, I think this discussion missing two important persons: Eliot and Andreas. Andreas is one, who behind the idea of Hydra VM. Eliot is making serious rewritings of squeak VM (namely Cog). There are plans to merge Hydra & Cog and continue with a new VM. This is beneficial in many aspects: i really think that best for all of us is to join efforts to produce better VM, instead in having multiple branches Squeak/Cog/Hydra VMs. Currently, works on Hydra is suspended because the more changes i do, the harder it would be to merge with Cog. Merging mess of low-structured low-level code of VMMaker is tough task, so i don't want to make it harder. :) Moreover, Hydra initially was proposed as experiment initiated by Qwaq, implemented by me. It turned out to be successfull one. :) But to leverage it, we need a much more than just VM - we need people who think/know how to adopt things to get benefits from multithreading. Squeak images simply not ready for this. We should have a better ways to scale: instead of loading bloated images (each for own interpter), we should think how to lessen the bloat and use single central image, which then managing smaller/nimble ones. That's why i keep making noise about modularity: we need modules which can be easily installed and run more or less standalone without cross-package dependencies. There is nothing wonderful in Hydra alone: we should attack the problem from both ends - language side and VM. > - 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 >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > -- Best regards, Igor Stasenko AKA sig.

Dec. 18, 2008

Re: [Pharo-project] Multi-core Pharo?

by Oscar Nierstrasz

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

Dec. 18, 2008

[Pharo-project] Fwd: [squeak-dev] Cog VM status update

by StÃ©phane Ducasse

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

Dec. 18, 2008

[Pharo-project] Fwd: Multi-core Pharo?

by StÃ©phane Ducasse

> > Ok this is clearer now. > > Stef

Dec. 18, 2008

Re: [Pharo-project] FreeType scanning Font folders

by Marcus Denker

On 16.12.2008, at 05:38, Rob Rothwell wrote: > Here is a change set that adds an "Update" button to the font list > dialog. I have never created a change set before, or submitted > anything for that matter. I used my full name (not initials), but > don't know if I am supposed to do anything else. > No, thats fine. > I like not re-scanning unless you need to, but I bet it might break > if the Fonts have NEVER been loaded...I'll have to think about how > to test that. > Yes, we need to think a bit what is most clever... the whole font- picture is not yet completely clear to me. I will check over the holidays. > You still need to remove FreeTypeFontProvider from the startup list > as well... > ok -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Dec. 18, 2008

Re: [Pharo-project] [update] #10194

by Marcus Denker

On 17.12.2008, at 18:53, StÃ©phane Ducasse wrote: > marcus did you fix the [ : x problems? > I just removed some . that where not supposed to be there.... Marcus > Stef > > On Dec 17, 2008, at 2:38 PM, Marcus Denker wrote: > >> 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 >> >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Dec. 18, 2008

[Pharo-project] Fwd: Multi-core Pharo?

by StÃ©phane Ducasse

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

Dec. 18, 2008

Re: [Pharo-project] Multi-core Pharo?

by Igor Stasenko

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.

Dec. 18, 2008