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

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

by Marcus Denker

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

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

by Fernando Olivero

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

Aug. 16, 2012

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

by Levente Uzonyi

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

Aug. 15, 2012

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

by Fernando Olivero

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

Aug. 15, 2012

Re: [Pharo-project] [Pharo-users] [ESUG 2012] Pharo/Moose workshop on Sunday 26th

by Rafael Luque

> > On the other hand, is there an "official" hashtag to use with the tweets > related with the event? > > pick one and let us know :) > > I think #esug2012 is the obvious one. Perhaps it will be good idea to publish it in the event's website, so people that cannot attend the conference can follow it through Twitter. Rafa

Aug. 15, 2012

Re: [Pharo-project] new Cog VMs

by StÃ©phane Ducasse

Hi eliot thanks. Now could you reply to the questions we asked with igor about the bug in the eeInstantiate methods? I'm curious to understand the logic of turning around the GC triggering on newly created objects. Are you fixes related to that because this impacts Moose large images? Stef > 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 >

Aug. 14, 2012

Re: [Pharo-project] Interest in another devroom at FOSDEM?

by StÃ©phane Ducasse

Me too Stef On Aug 14, 2012, at 5:23 PM, Francois Stephany wrote: > Interested! > > I'll live at ~1h from FOSDEM and have an available couch in case someone needs cheap (i.e., free) accomodation. > > Francois > > On 14/08/12 07:17, Stephan Eggermont wrote: >> Hello, >> >> Feb. 2 & 3 2013 there will be FOSDEM again in Brussels. >> Last year I organized a devroom where all kind of smalltalk related >> developments were shown. If there is sufficient interest, I'll ask for one >> again. Please tell me if you'd like to come/present and what you'd like >> to see. >> >> Stephan Eggermont >> >

Aug. 14, 2012

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

by StÃ©phane Ducasse

On Aug 14, 2012, at 1:49 PM, Lorenzo Schiavina wrote: > Hi Stef, > > I will be very happy to release my Simplex application; I developed it some > years ago in VSE. Excellent I thin that this is important to build a set of nice packages that people can use and enhance over time. > At present I am trying to port under Pharo (or Squeak) an expert system > generator based on fuzzy logic which name is FuzzyWorld and I have already > used for lot of real word applications. > I attach some documentation about a presentation I had at ESUG and of > current version of FuzzyWorld. Thanks I will have a look > An initial version of FuzzyWorld has been already ported by a student of > mine (Davide Arrigo)to Squeak; I am sure he will pleased to release it. > Please, tell what I have to do for releasing them. publish the code on smalltalkhub or ss3 and put a MIT or BSD license. If you have the time to flesh up a little web page describing it it would be great else do it incrementally. :) > > Ciao > > -----Messaggio originale----- > Da: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di StÃ©phane > Ducasse > Inviato: martedÃ¬ 14 agosto 2012 12.09 > A: Pharo-project(a)lists.gforge.inria.fr > Oggetto: Re: [Pharo-project] Dr. Geo for acadamy > > Lorenzo > > It would be great if you release your code under a friendly license so that > we can have a look. > I was refactoring for fun a little expert system too. > I never got until the end but I should finish once. > > Stef > On Aug 14, 2012, at 7:26 AM, Lorenzo Schiavina wrote: > >> Hi Phil and Hilaire, >> >> I have already developed a simplex in ST. >> >> Lorenzo >> >> Da: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di > phil(a)highoctane.be >> Inviato: lunedÃ¬ 13 agosto 2012 16.37 >> A: Pharo-project(a)lists.gforge.inria.fr >> Oggetto: Re: [Pharo-project] Dr. Geo for acadamy >> >> Hi, >> >> Doing nice formulas in Pharo would be of interest to me. And manipulating > them even more (I am busy with that now). >> >> 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). >> I know I can get a browser and all, but that's not cutting it the same > way. >> >> DrGeo is Java-free, so where can we use it where Java is not fine? >> >> 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). >> >> 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... >> >> KR >> Phil >> >> >> >> 2012/8/13 Hilaire Fernandes <hilaire.fernandes(a)gmail.com> >> >> 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 >> >> >> >> -- >> Philippe Back >> Dramatic Performance Improvements >> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be > | Web:http://philippeback.eu | Blog: http://philippeback.be >> >> High Octane SPRL >> rue cour Boisacq 101 >> 1301 Bierges >> Belgium > > <EnglishFuzzyWorld.ppt><englishFuzzyObjects.ppt>

Aug. 14, 2012

Re: [Pharo-project] [Pharo-users] [ESUG 2012] Pharo/Moose workshop on Sunday 26th

by StÃ©phane Ducasse

On Aug 14, 2012, at 1:10 PM, Rafael Luque wrote: > 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 accommodation. good question. What I suggest is: if you can come to the camp come at least the sunday because you will be able to meet a lot of people. Me and marcus will be there the sunday from the morning. Stef > > On the other hand, is there an "official" hashtag to use with the tweets related with the event? pick one and let us know :) > > Thank you, > > Rafael Luque

Aug. 14, 2012

[Pharo-project] new Cog VMs

by Eliot Miranda

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

Aug. 14, 2012