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

[Pharo-project] Issue 418 fixed (DNU when hitting Cmd+o)

by Torsten Bergmann

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

Dec. 18, 2008

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

by Chris Cunningham

On Thu, Dec 18, 2008 at 3:54 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > 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. > > Craig's work with Spoon sounds ideal for this. It sounds like the master could tell one of the other small images to run a message, and the spoon mechanisms would be invoked to make sure it has all of the code it needs - and no additional code.

Dec. 18, 2008

[Pharo-project] [update] #10196

by Marcus Denker

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

Dec. 18, 2008

Re: [Pharo-project] Parsing problem

by StÃ©phane Ducasse

On Dec 18, 2008, at 6:34 PM, Lukas Renggli wrote: >> 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 | ... ] It looks a weak argument to me :) I would hate to teach that. I neither thought you could even do that. >> 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. I was not aware of that. So this would be a reason to allow that but in pharo core code I would really like not to have that. To me this is a weakness of the parser and not a feature. > > > 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 >

Dec. 18, 2008

Re: [Pharo-project] Parsing problem

by StÃ©phane Ducasse

Gwenael is improving the parser/scanner after if people wants to grab the code this is their problem Our goal is not to end in endless squeaking discussions to build a better system. Stef On Dec 18, 2008, at 7:40 PM, Keith Hodges wrote: > Bill Schwab wrote: >> 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 >> > But lets solve this for squeak and pharo, otherwise we will have to > do it twice > > > Keith > > _______________________________________________ > 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] Parsing problem

by Keith Hodges

Bill Schwab wrote: > 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 > But lets solve this for squeak and pharo, otherwise we will have to do it twice Keith

Dec. 18, 2008

Re: [Pharo-project] Parsing problem

by Bill Schwab

+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

Dec. 18, 2008

Re: [Pharo-project] Parsing problem

by Lukas Renggli

> 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

Dec. 18, 2008

Re: [Pharo-project] Parsing problem

by Bill Schwab

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

Dec. 18, 2008

[Pharo-project] [ANN] iStoa.net v. 8.12-alpha1

by Hilaire Fernandes

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

Dec. 18, 2008