- Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20251

by Marcus Denker

20251 ----- Issue 6559: RPackage importing does not honor class side extension methods http://code.google.com/p/pharo/issues/detail?id=6559 Issue 6558: CompiledMethod>>#package does not resolve well with Class side methods http://code.google.com/p/pharo/issues/detail?id=6558 Issue 6450: typo exitSucess http://code.google.com/p/pharo/issues/detail?id=6450 -- Marcus Denker -- http://marcusdenker.de

Aug. 17, 2012

Re: [Pharo-project] Dr. Geo for acadamy

by Hilaire Fernandes

Hi Philip, > Doing nice formulas in Pharo would be of interest to me. And > manipulating them even more (I am busy with that now). So this make one project of interest for the community. > As for Geogebra as competition, these guys are now doing a ton of 3D (we > use GG here with my wife, a maths teacher) and their DSL is pretty > useful once mastered. I find myself constructing a lot of things from > the little "command prompt" of theirs. That would be an interesting > addition to DrGeo (and why not being GG-compatible on the commands). Yes, should be easy to do. Dr. Geo already comes with a nice API to describe geometry object with Smalltalk. It could be hooked to an existing canvas. > DrGeo is Java-free, so where can we use it where Java is not fine? I am not sure, but I think even ARM architecture comes with some sort of optimization for Java. Smalltalk is hard winner when the host architecture comes without OS. (i.e. SqueakNOS). > I'll look at what I can propose for engineers to work on. I'd add that a > solver for constraints would be nice to have (like Simplex). Do you have any ideas about case use of Simplex in Dr. Geo? > Also, a good thing to add to DrGeo is a window with a list of entities > with their name and possibility to rename/change attributes from there. > Once the things get complex, this is a godsend in GeoGebra... Yes, I use to have that feature in Dr. Geo 1.1 many years ago. It will appear in someway in DrGeoII, but hopefully with Smalltalkish spirit, not sure how yet. Thanks Hilaire

Aug. 17, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > I could also be that Sean committed something. > I'll take a look tomorrow at the latest. If it's an emergency, I might be able to check later tonight... -- View this message in context: http://forum.world.st/serializing-DynamicVariables-Zinc-so-far-tp4643514p46… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by StÃ©phane Ducasse

>>> I read a paper once (at the University of New Brunswick (Canada)) >>> library in which the grammar for a language was used to construct a >>> data compressor for syntaxly correct programs. The output was a >>> compressed form of a parse/syntax tree with comments and white space >>> included. Once decompressed, the tree could be used to reconstruct >>> the source. I don't know if a compressed syntax tree would be very useful for >>> programming tasks but it could be used to compress Smalltalk's source >>> file and changes file. This assumes the time saved by filing in >>> smaller chucks of programs segments would greater than the cost of >>> decompression. >> >> do you have the reference? >> One guy told me and in Oberon or something like that the ast was compressed long time ago. > > Franz, M. & Kistler, T. (1997), 'Slim Binaries', Commun. ACM 40 (12) , 87--94 . > http://dl.acm.org/citation.cfm?id=265576 Ok we know this one :) Stef

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Stefan Marr

On 16 Aug 2012, at 19:29, StÃ©phane Ducasse wrote: > > On Aug 16, 2012, at 6:13 PM, Ralph Boland wrote: > >> I read a paper once (at the University of New Brunswick (Canada)) >> library in which the grammar for a language was used to construct a >> data compressor for syntaxly correct programs. The output was a >> compressed form of a parse/syntax tree with comments and white space >> included. Once decompressed, the tree could be used to reconstruct >> the source. I don't know if a compressed syntax tree would be very useful for >> programming tasks but it could be used to compress Smalltalk's source >> file and changes file. This assumes the time saved by filing in >> smaller chucks of programs segments would greater than the cost of >> decompression. > > do you have the reference? > One guy told me and in Oberon or something like that the ast was compressed long time ago. Franz, M. & Kistler, T. (1997), 'Slim Binaries', Commun. ACM 40 (12) , 87--94 . http://dl.acm.org/citation.cfm?id=265576 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by StÃ©phane Ducasse

On Aug 16, 2012, at 6:13 PM, Ralph Boland wrote: > I read a paper once (at the University of New Brunswick (Canada)) > library in which the grammar for a language was used to construct a > data compressor for syntaxly correct programs. The output was a > compressed form of a parse/syntax tree with comments and white space > included. Once decompressed, the tree could be used to reconstruct > the source. I don't know if a compressed syntax tree would be very useful for > programming tasks but it could be used to compress Smalltalk's source > file and changes file. This assumes the time saved by filing in > smaller chucks of programs segments would greater than the cost of > decompression. do you have the reference? One guy told me and in Oberon or something like that the ast was compressed long time ago. > I am designing and planning to implement a parser generator tool > (yes, another parser generator tool, something the world really needs ;-) ). This is another questions :) Why don't you want to improve petitparser? > If/when this project is complete perhaps I'll give this compressed AST > idea a try. > > Convincing the Squeak/Pharo world that it should be used is another matter > entirely. Since marcus PhD we want to have AST stored in the system, we just need to have a compressed version of AST to make an experiment and measure. Stef > > Ralph Boland >

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Ralph Boland

I read a paper once (at the University of New Brunswick (Canada)) library in which the grammar for a language was used to construct a data compressor for syntaxly correct programs. The output was a compressed form of a parse/syntax tree with comments and white space included. Once decompressed, the tree could be used to reconstruct the source. I don't know if a compressed syntax tree would be very useful for programming tasks but it could be used to compress Smalltalk's source file and changes file. This assumes the time saved by filing in smaller chucks of programs segments would greater than the cost of decompression. I am designing and planning to implement a parser generator tool (yes, another parser generator tool, something the world really needs ;-) ). If/when this project is complete perhaps I'll give this compressed AST idea a try. Convincing the Squeak/Pharo world that it should be used is another matter entirely. Ralph Boland

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Fernando Olivero

Yes, caching is what i do in my system. It would amazing that Pharo implements such a caching scheme for methods and their ast . If you evaluate the code i pasted before, you will note that it does preserve the actual source. RBMethodNode>>source ^ source instead, RBMethodNode>>formtattedSource , vists the ast to return the source. Fernando On Thu, Aug 16, 2012 at 4:20 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 16 Aug 2012, Fernando Olivero wrote: > >> NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE >> could be simplied and be more powerful. > > Let's be a bit more realistic. The current garbage collector is choking if > you add 100 MB of small objects to your image. Caching the recently > accessed ASTs sounds like a better idea. > >> >> For example, in gaucho i'm using the ast for pretty printing of the >> source, and for styling unsed variables differently, etc... > > You didn't answer yet if RB's AST can reproduce the exact same source > string or not. > > > Levente > >> >> >> Fernando >> >> On Thu, Aug 16, 2012 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Aug 16, 2012, at 9:32 AM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >>> >>>> I've been using RB, which allows to recreate on demand the ast, but in >>>> my system i cached those values. >>>> >>>> >>>> ast := RBParser parseMethod: 'parsingAMethod >>>> | yeah | >>>> yeah := self doesAMethodNode remember its source. >>>> yeah >>>> ifTrue:[ ^ #hurray]'. >>>> >>>> ast source. >>>> ast formattedCode. >>>> >>>> ast := (Object>>#at:) parseTree. >>>> ast source. >>>> ast formattedCode >>>> >>>> >>>> Regarding the memory usage, in my system only the methods which have a >>>> "method shape" opened in the IDE, store their ast, thus i cannot >>>> provide numbers of the overhead. But why should one extra object more >>>> per method be a problem? >>>> >>> >>> It's not one object... it's a tree. I did once a system that stored the AST for each method >>> (uncompressed) in addition to what is there now (CompiledMethod). >>> The system was 120MB instead of 20MB. (based on Squeak 3.9) >>> >>> Which means, even then smaller than Eclipse ;-) >>> >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >> >>

Aug. 16, 2012

[Pharo-project] [update 1.4] #14458

by Esteban Lorenzano

14458 ----- Issue 6555: DNU on ctrl home / ctrl end http://code.google.com/p/pharo/issues/detail?id=6555

Aug. 16, 2012

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)

by Levente Uzonyi

On Thu, 16 Aug 2012, Fernando Olivero wrote: > NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE > could be simplied and be more powerful. Let's be a bit more realistic. The current garbage collector is choking if you add 100 MB of small objects to your image. Caching the recently accessed ASTs sounds like a better idea. > > For example, in gaucho i'm using the ast for pretty printing of the > source, and for styling unsed variables differently, etc... You didn't answer yet if RB's AST can reproduce the exact same source string or not. Levente > > > Fernando > > On Thu, Aug 16, 2012 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 16, 2012, at 9:32 AM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> >>> I've been using RB, which allows to recreate on demand the ast, but in >>> my system i cached those values. >>> >>> >>> ast := RBParser parseMethod: 'parsingAMethod >>> | yeah | >>> yeah := self doesAMethodNode remember its source. >>> yeah >>> ifTrue:[ ^ #hurray]'. >>> >>> ast source. >>> ast formattedCode. >>> >>> ast := (Object>>#at:) parseTree. >>> ast source. >>> ast formattedCode >>> >>> >>> Regarding the memory usage, in my system only the methods which have a >>> "method shape" opened in the IDE, store their ast, thus i cannot >>> provide numbers of the overhead. But why should one extra object more >>> per method be a problem? >>> >> >> It's not one object... it's a tree. I did once a system that stored the AST for each method >> (uncompressed) in addition to what is there now (CompiledMethod). >> The system was 120MB instead of 20MB. (based on Squeak 3.9) >> >> Which means, even then smaller than Eclipse ;-) >> >> Marcus >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> > >

Aug. 16, 2012