- Pharo-dev - lists.pharo.org

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

by Marcus Denker

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. 14, 2012

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

by Mariano Martinez Peck

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 ? thanks -- Mariano http://marianopeck.wordpress.com

Aug. 14, 2012

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

by Lorenzo Schiavina

Hi Stef, I will be very happy to release my Simplex application; I developed it some years ago in VSE. 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. 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. 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

Aug. 14, 2012

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

by Rafael Luque

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

Aug. 14, 2012

Re: [Pharo-project] Questions on Traits

by Marcus Denker

On Aug 14, 2012, at 12:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 13, 2012, at 4:31 PM, Noury Bouraqadi wrote: > >> Hi, >> >> -Why new methods are compiled from the ones of traits? I remember that in the first implementation, when a trait was used by a class, new entries were introduced to the methodDict where the values are the compiled methods from the trait. Currently, a new compiled method is introduced with the exact code of the on from the trait. Why? >> >> -It is possible to compile a method that includes a super send in traits. Does it make sense? > > I think yes. But indeed the application of the trait should rebind the "super" encoding > for super sends, the vm looks at the same literal that is returned when calling #methodClass. So this means that due to updating that, the super sends will just work. Marcus -- Marcus Denker -- http://marcusdenker.de

Aug. 14, 2012

Re: [Pharo-project] Pharo on retina display

by Henrik Sperre Johansen

On 01.08.2012 21:56, Sean P. DeNigris wrote: > Like all apps not upgraded for retina, Pharo looks pixelated and fuzzy on the > new MBPs. Is there any workaround which at least makes the text less fuzzy? > > http://forum.world.st/file/n4642567/Screen_Shot_2012-08-01_at_3.48.23_PM.png > > > > -- > View this message in context: http://forum.world.st/Pharo-on-retina-display-tp4642567.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > There is TextStyle pixelsPerInch, which is adherred to by the TrueType fonts, but setting that to a correct value probably plays badly with whatever post-scaling OSX does for non-retina aware apps... Cheers, Henry

Aug. 14, 2012

Re: [Pharo-project] New Adventure.

by Diogenes Moreira

Oki i'll fork IT... Thank you Lic. DiÃ³genes A. Moreira Desde mi celular El ago 14, 2012 7:00 a.m., "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> escribiÃ³: > diogenes > > it would be good that you use the git repository so that we can capitalize > on your experience. > > Stef > > On Aug 11, 2012, at 10:38 PM, Diogenes Moreira wrote: > > > Hi folks, I wanna tell you my new adventure, that i'll start today. > > > > I'll be try compile and fix the VM and FFI for run on 64 bits systems, > > > > the idea is run dbxtalk over a Windows 2008 server.. > > > > Any Clue o Tip are welcome. > > > > Best D, > > > > > > http://about.me/diogenes.moreira > > > > >

Aug. 14, 2012

Re: [Pharo-project] Fwd: [Seaside] Squeak 4.3 and Seaside

by Frank Shearar

On 14 August 2012 11:30, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Funny and sad. For both Pharo and Squeak! frank > If people do not even report problems, it simply means that we should not > spend time for them :) > > Begin forwarded message: > > From: recursive68(a)gmail.com > Subject: [Seaside] Squeak 4.3 and Seaside > Date: August 12, 2012 5:35:49 PM GMT+02:00 > To: seaside(a)lists.squeakfoundation.org > Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> > > Hi, > > I've downloaded squeak 4.3 (usually use Pharo but getting fed up with some > packages I need not working with the latest version of Pharo) and then tried > to install Seaside using the ConfigurationOfSeaside via Monticello. It fails > to work, it seems problem is with Zinc-HTTP, plus Seaside Control panel > doesn't work either. DoI have to install an older version, or something or > is Seaside only now supported on Pharo ? > > Thanks > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > >

Aug. 14, 2012

[Pharo-project] Fwd: [Seaside] Squeak 4.3 and Seaside

by stephane ducasse

Funny and sad. If people do not even report problems, it simply means that we should not spend time for them :) Begin forwarded message: > From: recursive68(a)gmail.com > Subject: [Seaside] Squeak 4.3 and Seaside > Date: August 12, 2012 5:35:49 PM GMT+02:00 > To: seaside(a)lists.squeakfoundation.org > Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org> > > Hi, > > I've downloaded squeak 4.3 (usually use Pharo but getting fed up with some packages I need not working with the latest version of Pharo) and then tried to install Seaside using the ConfigurationOfSeaside via Monticello. It fails to work, it seems problem is with Zinc-HTTP, plus Seaside Control panel doesn't work either. DoI have to install an older version, or something or is Seaside only now supported on Pharo ? > > Thanks > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Aug. 14, 2012

Re: [Pharo-project] Questions on Traits

by StÃ©phane Ducasse

On Aug 13, 2012, at 4:31 PM, Noury Bouraqadi wrote: > Hi, > > -Why new methods are compiled from the ones of traits? I remember that in the first implementation, when a trait was used by a class, new entries were introduced to the methodDict where the values are the compiled methods from the trait. Currently, a new compiled method is introduced with the exact code of the on from the trait. Why? > > -It is possible to compile a method that includes a super send in traits. Does it make sense? I think yes. But indeed the application of the trait should rebind the "super" encoding Stef > > Noury > -- > http://twitter.com/#!/NouryBouraqadi > http://www.kroobe.com/profile/noury > > > Afin de contribuer au respect de l'environnement, > merci de n'imprimer ce courriel qu'en cas de necessite > > Please consider the environment before you print > > > >

Aug. 14, 2012