- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Syntax Visualisation in the C# infrastructure

by Alexandre Bergel

Do you have screenshots? I can advertise your work on our Facebook website. Alexandre On Apr 5, 2014, at 11:38 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Yeah I use Roassal + Mondrian to visualize my intermediate representations in the compiler and doing it for the AST is really simple (like 5 min of work). > > In addition the GTInspector view on trees/graph is really nice. > > So basically we have all the tools they provide. > > > 2014-04-05 17:56 GMT-07:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > I am not sure to what syntax visualization is useful for, but indeed, this is easy in Roassal > > Assuming a class MyVisitor, that simples collect the nodes of the AST. > > -=-=-=-=-=-=-=-=-=-= > | ast visitor g | > "We get the nodes from the AST" > ast := RBParser parseMethod: (ArrayTest>>#testReplaceFromToWithStartingAt) getSource. > visitor := MyVisitor new. > ast acceptVisitor: visitor. > > "Visualization" > g := RTGraphBuilder new. > g node > if: #isMessage shape: (RTEllipse new size: 10; color: Color red ) + (RTLabel new text: #selector); > if: #isReturn shape: (RTEllipse new size: 10; color: Color red ); > if: #isBlock shape: (RTBox new size: 10; color: Color blue ); > shape: (RTEllipse new size: 10; color: Color gray ). > g layout use: RTTreeLayout new. > g edge connectTo: #parent. > > g addAll: visitor nodes. > > g applyLayout. > g view > -=-=-=-=-=-=-=-=-=-= > > > <Screen Shot 2014-04-05 at 9.56.35 PM.png> > Cheers, > Alexandre > > > On Apr 4, 2014, at 4:34 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> It seems that Microsoft has opened interesting parts of the C# compilation infrastructure, including syntax visualisation. >> >> http://roslyn.codeplex.com/wikipage?title=Syntax%20Visualizer&referringTitl… >> >> Ideas for Opal+Roassal2 ? >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2014

Re: [Pharo-dev] Problem with Finder

by Nicolai Hess

Use Nautilus, right click on the package, choose "browse scoped". In the new browser, search for senders/implementers is scoped on this package. (it doesn't fully work. If you use a scoped browser, the search envirionment includes the whole class of other packages, for which your package defines an extions, even if the search result is not the extension). 2014-04-06 21:30 GMT+02:00 jannik laval <jannik.laval(a)gmail.com>: > Probably, you can answer another problem: > > During reengineering a system (Phratch), I need to know senders / > implementors in a specific group of package. > The only way I found to do this is to use the Finder. > Does exist another way ? > > Jannik > > > 2014-04-06 11:05 GMT+02:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > >> On 06 Apr 2014, at 08:20, jannik laval <jannik.laval(a)gmail.com> wrote: >> >> Hi guys, >> >> When I use the Finder, on a specific package, it does not take into >> account the class extensions. >> >> Is this bug already reported ? >> >> >> >> No and this is probably a bug because you may be the first one to use >> this feature :) >> >> >> -- >> >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://car.mines-douai.fr/ >> >> >> > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://car.mines-douai.fr/ >

April 6, 2014

Re: [Pharo-dev] Problem with Finder

by jannik laval

13179: Finder does not take Class extensions into account 2014-04-06 21:31 GMT+02:00 jannik laval <jannik.laval(a)gmail.com>: > Should I ask it for Pharo 3.0 or Pharo 4.0 ? > > Jannik > > > 2014-04-06 11:05 GMT+02:00 Pharo4Stef <pharo4Stef(a)free.fr>: > >> >> On 06 Apr 2014, at 08:20, jannik laval <jannik.laval(a)gmail.com> wrote: >> >> Hi guys, >> >> When I use the Finder, on a specific package, it does not take into >> account the class extensions. >> >> Is this bug already reported ? >> >> >> >> No and this is probably a bug because you may be the first one to use >> this feature :) >> >> >> -- >> >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://car.mines-douai.fr/ >> >> >> > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://car.mines-douai.fr/ > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

April 6, 2014

Re: [Pharo-dev] Problem with Finder

by jannik laval

Should I ask it for Pharo 3.0 or Pharo 4.0 ? Jannik 2014-04-06 11:05 GMT+02:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > On 06 Apr 2014, at 08:20, jannik laval <jannik.laval(a)gmail.com> wrote: > > Hi guys, > > When I use the Finder, on a specific package, it does not take into > account the class extensions. > > Is this bug already reported ? > > > > No and this is probably a bug because you may be the first one to use this > feature :) > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://car.mines-douai.fr/ > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

April 6, 2014

Re: [Pharo-dev] Problem with Finder

by jannik laval

Probably, you can answer another problem: During reengineering a system (Phratch), I need to know senders / implementors in a specific group of package. The only way I found to do this is to use the Finder. Does exist another way ? Jannik 2014-04-06 11:05 GMT+02:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > On 06 Apr 2014, at 08:20, jannik laval <jannik.laval(a)gmail.com> wrote: > > Hi guys, > > When I use the Finder, on a specific package, it does not take into > account the class extensions. > > Is this bug already reported ? > > > > No and this is probably a bug because you may be the first one to use this > feature :) > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://car.mines-douai.fr/ > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

April 6, 2014

Re: [Pharo-dev] MC diffs are seriously broken in Pharo2.0

by Pharo4Stef

On 06 Apr 2014, at 17:36, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I'm trying to fix some Pharo VM issues (11330), but have awfully bad experience with Pharo2.0 tools. > > The autocompletion stuff is a joke, it moves the input cursor randomly and spoils my input. That's the first thing I disable. Do you have the same with 30? Because I know that there were some problems when we merged OC and EC but this is nearly more than a year ago. > The pharo's PolyMorphDiffTool is good looking but awfully sloooow > It clearly does not scale (10 minutes or so to diff Eliot's branch) so I reverted to the old diff tool. > But of course, someone broke MCMethodDefinition>>summary (gratuitously?) and I had to revert this method to have class names displayed again. Nicolas this is probably not gratuitoulsy and you know it. Doing imply doing mistakes. Give me a fully tested system and you will see that we will not break it. So can you open a bug entry so that we do not forget to fix it. > But worse than all, there are insane caches operating in MCVersion that drove me crazy. > Here is the scenario: > 1) I diff working copy against package.branchA-version.mcz > 2) I cherry pick and install a few methods > 3) I diff against package.branchA-version.mcz again to check if I missed smthing > 4) Huh? it looks like my cherry pick have not been installed??? > Yes they were installed, but the completePackageSnapshot has been cached in MCVersion!!! > What a mistake! The working copy is going to evolve, caching a snapshot of it is a DUMB thing.It means that methods that I further change in the working copy will NEVER be taken into account next time I'll do a diff. > So I had to change MCVersion>>changes > ^ self completeSnapshot patchRelativeToBase: self loadCompletePackageSnapshot > > This is so broken that I have to report here. Thanks this is the best things to do. You see probably one guy tried to speed up the system and this happens. > Note that I did not check if symptoms are still in Pharo 3.0, but the working copy scnapshot cache still is for sure! > > Guys, it makes me wonder, who is eating the dog food? We are constantly using Pharo alpha the complete moose and pharo > Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;) I guess so. Esteban does not look like using Pharo2.0 but I will let him reply. > Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version. Us too. :) Thanks for reporting problems. Can you open bug entries so that we can handle these problems? Stef

April 6, 2014

Re: [Pharo-dev] Build process of Pharo image

by Pharo4Stef

On 06 Apr 2014, at 11:43, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > For me this should the responsibilities of the component developers. It > is more efficient as s/he knows the component and what may break at > installation time. Except that it requires a better infrastructure and who is in charge about - RB - RBenvironment - Smart Suggestions - â¦. Stef > > Le 06/04/2014 10:44, Pharo4Stef a Ã©crit : >> You take unReloader you run the scripts and you load the configurations. >> when they fail you fix them and restart. I have been doing that a lot and we will continue but this is booooooring. > > -- > Dr. Geo http://drgeo.eu > >

April 6, 2014

MC diffs are seriously broken in Pharo2.0

by Nicolas Cellier

I'm trying to fix some Pharo VM issues (11330), but have awfully bad experience with Pharo2.0 tools. The autocompletion stuff is a joke, it moves the input cursor randomly and spoils my input. That's the first thing I disable. The pharo's PolyMorphDiffTool is good looking but awfully sloooow It clearly does not scale (10 minutes or so to diff Eliot's branch) so I reverted to the old diff tool. But of course, someone broke MCMethodDefinition>>summary (gratuitously?) and I had to revert this method to have class names displayed again. But worse than all, there are insane caches operating in MCVersion that drove me crazy. Here is the scenario: 1) I diff working copy against package.branchA-version.mcz 2) I cherry pick and install a few methods 3) I diff against package.branchA-version.mcz again to check if I missed smthing 4) Huh? it looks like my cherry pick have not been installed??? Yes they were installed, but the completePackageSnapshot has been cached in MCVersion!!! What a mistake! The working copy is going to evolve, caching a snapshot of it is a DUMB thing.It means that methods that I further change in the working copy will NEVER be taken into account next time I'll do a diff. So I had to change MCVersion>>changes ^ self completeSnapshot patchRelativeToBase: self loadCompletePackageSnapshot This is so broken that I have to report here. Note that I did not check if symptoms are still in Pharo 3.0, but the working copy scnapshot cache still is for sure! Guys, it makes me wonder, who is eating the dog food? Did anyone progress into developing VM in Pharo 3.0, because if I must eat it, I'd prefer the freshest ;) Or if I fix some more bug, I'd like my efforts to not apply to an obsolete version.

April 6, 2014

Re: [Pharo-dev] Build process of Pharo image

by Pharo4Stef

> > I can give you all the Monticello package list, but is it relevant? I > hardly know 10% of them. Some should probably belong to core other not. > >> do you want an image by default without any tools? I do but we need time. > > I don't understand: with times new important tools were developed, like > Nautilus and other I don't know I guess. Was it decided these tools > should be carved in the image or be loaded? No they should be loaded. Now we should not deliver an image that is not the one we use so we will put in place a building process from the smaller images, loading the tools we need. Now we rewrote slowly the tools and we are removing the ones that have been fully rewritten. But there is no magic: time and resources. So give me 1 engineer full time to have the process I dream and it will be there. Now igor is focusing on texteditor (beside fonts and NB) and esteban the rest :) > Was not removing old tools > and using new loadable ones the way to build step by step this core image? This is what we did: new finder, new message, new changesorter, new browserâ¦. > I confess I very likely don't see the subtle details. > >> so you are right we are concious about it but no resources. > > Is it really a resource problem? Yes. > With my scarce resources and knowledge I can build automatically drgeo > with a bash script and a .st file since 1.x for several platform. I > agree it is more complex with Pharo butâ¦ It is. And Drgeo is just managed by you and not by the community/independant projects. I asked already one year ago an engineer to build this but he was refused. We resubmitted the project and we are waiting. > > Hilaire > > > -- > Dr. Geo http://drgeo.eu

April 6, 2014

Re: [Pharo-dev] Build process of Pharo image

by Hilaire Fernandes

Le 06/04/2014 10:44, Pharo4Stef a Ã©crit : > > On 05 Apr 2014, at 21:48, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > >> Still, I do not get why the newer packages are not loadable with >> configurations instead of been carved in the image. Why can't packages >> developers provide such configurations? > > sure give us a list? > - RB > - Nautilus > - spec > - Keychain > - key mapping > - smart suggestions > - â¦.. > - and many more I can give you all the Monticello package list, but is it relevant? I hardly know 10% of them. Some should probably belong to core other not. > do you want an image by default without any tools? I do but we need time. I don't understand: with times new important tools were developed, like Nautilus and other I don't know I guess. Was it decided these tools should be carved in the image or be loaded? Was not removing old tools and using new loadable ones the way to build step by step this core image? I confess I very likely don't see the subtle details. > so you are right we are concious about it but no resources. Is it really a resource problem? With my scarce resources and knowledge I can build automatically drgeo with a bash script and a .st file since 1.x for several platform. I agree it is more complex with Pharo but... Hilaire -- Dr. Geo http://drgeo.eu

April 6, 2014