August 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20251
by Marcus Denker Aug. 17, 2012

Aug. 17, 2012

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

1 0

[Pharo-project] Dr. Geo for acadamy
by Hilaire Fernandes Aug. 17, 2012

Aug. 17, 2012

Hello, Thinking aloud. May be I already discussed the following ideas with some of you. Dr. Geo is now mature enough to learn from it and to propose it as a tool students in computer science and/or mathematics can use for final projects or study projects. The idea is to propose student programming projects around Dr. Geo. A list of projects should be drafted and designed to be appropriate for students. I am not really sure about the level of difficulties, the duration such project could take, but listing ideas could be a good start. Moreover, I don't know if the idea elaborated in this document make any sense, so your feedback on that point would be greatly appreciated as well. Another requirement could be to list why students will benefit working in a project around Dr. Geo, to be done later if the idea take off. Regarding Dr. Geo project itself the benefice is more to gain in visibility and not in contributions coming from students work, indeed sudents will more likely maintain the project only for the duration of their studies. But more visibility on Dr. Geo can mean more long term contributors, hopefully from the academic sector. Dr. Geo need it to scale up and to compete with other alike project like GeoGebra where the contributors are numerous. If not, Dr. Geo will remain an epiphenomena and the great concept behind Dr. Geo, modify me from myself, will be lost. Regarding the project ideas, I see two categories: projects of interest for Dr. Geo and other Smalltalk ones and projects tightly related to Dr. Geo core. 1. Projects of interest for Dr. Geo and other Smallktalk software: - framework to render latex formula - mini-worksheet package to embed in an application - supplementary Polymorph widgets - mini algebraic system for symbolic manipulation of mathematic expressions - proof system, prolog or purely Smalltalk based 2. Projects tightly tied to Dr. Geo: - SVG, EPS exporters - new UI paradigm to build interactive sketch - porting to other system, closely related to Virtual Machinery - More constructions tools, it is a very good teachable as it dives you in an application with a lot of design patterns in action. See following document https://blueprints.launchpad.net/drgeo/+spec/todo-to-implement-new-tool There are more ideas. If you think about any person involved in the academic sector, please forward, this is why I wrote the document in Frenglish after all. Thanks Hilaire Fernandes -- Dr. Geo - http://www.drgeo.eu -- Dr. Geo - http://www.drgeo.eu

5 6

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Ralph Boland Aug. 16, 2012

Aug. 16, 2012

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

3 3

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Fernando Olivero Aug. 16, 2012

Aug. 16, 2012

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

1 0

[Pharo-project] [update 1.4] #14458
by Esteban Lorenzano Aug. 16, 2012

Aug. 16, 2012

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

1 0

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Fernando Olivero Aug. 16, 2012

Aug. 16, 2012

NICE! I would say lets go for it, 120MB is nothing nowadays. The IDE could be simplied and be more powerful. For example, in gaucho i'm using the ast for pretty printing of the source, and for styling unsed variables differently, etc... 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 >

4 3

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Fernando Olivero Aug. 16, 2012

Aug. 16, 2012

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? Fernando On Wed, Aug 15, 2012 at 11:10 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 15 Aug 2012, Fernando Olivero wrote: > >> Hi, great point Marcus. I was wondering why cant a compiled method >> know the "ast" that generated it? > > Would you store all ASTs in memory all the time or recreate it every time > on demand? > >> >> It would ease the queries + manipulation, in the tools a lot! >> >> CompiledMethod>>getSourceReplacingSelectorWith: aSelector >> .... >> >> would be instead: >> >> CompiledMethod>>withSelector: aSelector >> ^ (self ast withSelector: aSelector) source. > > Is there an implementation of AST that can reproduce the exact same source > code? > > > Levente > >> >> >> I've been using an AST, instead of the CompiledMethods directly for >> this reason, to deal with more expressive power. >> >> Fernando >> >> On Tue, Aug 14, 2012 at 2:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Aug 14, 2012, at 2:01 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>>> Hi guys. Today, there is a part of the system coupled with Compiler. Issue is: http://code.google.com/p/pharo/issues/detail?id=6110 >>>> >>>> Now, if you see the method: >>>> >>>> getSourceReplacingSelectorWith: newSelector >>>> | oldKeywords newKeywords args newSelectorWithArgs source oldSelector s | >>>> source := self sourceCode. >>>> oldSelector := self parserClass new parseSelector: source. >>>> oldSelector = newSelector ifTrue: [ ^ source ]. >>>> oldKeywords := oldSelector keywords. >>>> newKeywords := (newSelector ifNil: [self defaultSelector]) keywords. >>>> [oldKeywords size = newKeywords size] assert. >>>> args := (self methodClass parserClass new >>>> parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. >>>> newSelectorWithArgs := String streamContents: [:stream | >>>> newKeywords withIndexDo: [:keyword :index | >>>> stream nextPutAll: keyword. >>>> stream space. >>>> args size >= index ifTrue: [ >>>> stream nextPutAll: (args at: index); space]]]. >>>> s := source string readStream. >>>> oldKeywords do: [ :each | s match: each ]. >>>> args isEmpty ifFalse: [ s match: args last ]. >>>> ^newSelectorWithArgs trimBoth, s upToEnd >>>> >>>> The 2 magic lines are: >>>> >>>> oldSelector := self parserClass new parseSelector: source. >>>> oldSelector = newSelector ifTrue: [ ^ source ]. >>>> >>>> So, why we cannot just replace "self parserClass new parseSelector: source." with "self selector". Well, I think (talking with Guille) this ONLY because of Trait transformation/aliases that associates a selector with a method of a different selector. >>>> >>>> If this is the case, it means that 99% of the cases,"oldSelector = newSelector ifTrue: [ ^ source ]. " is true. Because those aliases are only used in one trait in all the image (). >>>> >>>> So...if that is the case, can't we get the oldSelector from elsewhere rather than needing to use the Compiler to get the selector from the source code ? >>>> >>> As we now encode the selector in the CompiledMethod itself, this can be relaced with >>> >>> oldSelector := self selector. >>> >>> >>> But what you have left is the arguments... >>> >>> args := (self methodClass parserClass new >>> parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. >>> >>> The only way to get the the argument names (temps) of a method is to compile the source... no way around it. >>> >>> (I personally think this is another example why bytecode as the model for reflection is just wrong) >>> >>> >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >> >>

2 1

Re: [Pharo-project] Breaking another dependency to Compiler (related to Traits I think)
by Fernando Olivero Aug. 15, 2012

Aug. 15, 2012

Hi, great point Marcus. I was wondering why cant a compiled method know the "ast" that generated it? It would ease the queries + manipulation, in the tools a lot! CompiledMethod>>getSourceReplacingSelectorWith: aSelector .... would be instead: CompiledMethod>>withSelector: aSelector ^ (self ast withSelector: aSelector) source. I've been using an AST, instead of the CompiledMethods directly for this reason, to deal with more expressive power. Fernando On Tue, Aug 14, 2012 at 2:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 14, 2012, at 2:01 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi guys. Today, there is a part of the system coupled with Compiler. Issue is: http://code.google.com/p/pharo/issues/detail?id=6110 >> >> Now, if you see the method: >> >> getSourceReplacingSelectorWith: newSelector >> | oldKeywords newKeywords args newSelectorWithArgs source oldSelector s | >> source := self sourceCode. >> oldSelector := self parserClass new parseSelector: source. >> oldSelector = newSelector ifTrue: [ ^ source ]. >> oldKeywords := oldSelector keywords. >> newKeywords := (newSelector ifNil: [self defaultSelector]) keywords. >> [oldKeywords size = newKeywords size] assert. >> args := (self methodClass parserClass new >> parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. >> newSelectorWithArgs := String streamContents: [:stream | >> newKeywords withIndexDo: [:keyword :index | >> stream nextPutAll: keyword. >> stream space. >> args size >= index ifTrue: [ >> stream nextPutAll: (args at: index); space]]]. >> s := source string readStream. >> oldKeywords do: [ :each | s match: each ]. >> args isEmpty ifFalse: [ s match: args last ]. >> ^newSelectorWithArgs trimBoth, s upToEnd >> >> The 2 magic lines are: >> >> oldSelector := self parserClass new parseSelector: source. >> oldSelector = newSelector ifTrue: [ ^ source ]. >> >> So, why we cannot just replace "self parserClass new parseSelector: source." with "self selector". Well, I think (talking with Guille) this ONLY because of Trait transformation/aliases that associates a selector with a method of a different selector. >> >> If this is the case, it means that 99% of the cases,"oldSelector = newSelector ifTrue: [ ^ source ]. " is true. Because those aliases are only used in one trait in all the image (). >> >> So...if that is the case, can't we get the oldSelector from elsewhere rather than needing to use the Compiler to get the selector from the source code ? >> > As we now encode the selector in the CompiledMethod itself, this can be relaced with > > oldSelector := self selector. > > > But what you have left is the arguments... > > args := (self methodClass parserClass new > parseArgsAndTemps: source string notifying: nil) copyFrom: 1 to: self numArgs. > > The only way to get the the argument names (temps) of a method is to compile the source... no way around it. > > (I personally think this is another example why bytecode as the model for reflection is just wrong) > > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

2 1

[Pharo-project] [ESUG 2012] Pharo/Moose workshop on Sunday 26th
by Rafael Luque Aug. 15, 2012

Aug. 15, 2012

Hi all, I have just registered to attend the ESUG 2012 conference and I'd like to have more info about the Pharo/Moose Workshop that will be organized on Sunday, August 26th in order to plan the trip and accomodation. On the other hand, is there an "official" hashtag to use with the tweets related with the event? Thank you, Rafael Luque

2 2

[Pharo-project] new Cog VMs
by Eliot Miranda Aug. 14, 2012

Aug. 14, 2012

Hi All, please find new VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2585/. These VMs try and fix an occasional crash (try because the fix doesn't handle all cases yet), and at least turn it into an orderly exit with error message (no room on youngReferrers list/youngReferrers list overflowed) instead of a hard crash. ------------------------------------------------------------------------ Cog VM binaries as per VMMaker.oscog-eem.201/r2585. Make sure youngReferrersList has room for every method since become/cache implicit receiver can cause any method to gain a young reference. Do so by counting methods in the zone. Make overflowing the youngReferrers list a hard error (appears to happen quite often in Newspeak code). Fix assert in interpretMethodFromMachineCode. Fix bug in changeClassFrom:to: if receiver is a compact class instance with a large header. -- best, Eliot

2 1