June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Brainstorming Pharo4

by Esteban Lorenzano

On 04 Jun 2014, at 14:46, Stephan Eggermont <stephan(a)stack.nl> wrote: > If we can integrate libtorrent as well, we should be able to use our dvcs as it is supposed to be used: peer-to-peer. Github is a fine place to store backups :) > > I assume the embeddable vm work includes resurrecting coral? no, it doesnât :) it means: correctly separate vm from UI and allow image to start or not start it. I donât know what coral has to do with that but probably coral can take benefit of it too. > > We can create a ConfigurationOfGlamour that avoids loading the whole of Moose ;) I think there is already one :) But even that is over bloated for our current proposal (nothing that we canât work on). Esteban > > Stephan

June 4, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Stephan Eggermont

If we can integrate libtorrent as well, we should be able to use our dvcs as it is supposed to be used: peer-to-peer. Github is a fine place to store backups :) I assume the embeddable vm work includes resurrecting coral? We can create a ConfigurationOfGlamour that avoids loading the whole of Moose ;) Stephan

June 4, 2014

Re: [Pharo-dev] Some PharoVM work news

by Esteban Lorenzano

On 04 Jun 2014, at 13:49, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Esteban, > > What does the work of Igor in finalization consists in ? it was easier (to find it, not to understand :P) than I thought. Is just a method and a couple of lines to introduce a proper weak finalisation. > Does it make sense to propose to Eliot to integrate it in his branch ? Iâm collecting a list of changes to propose to Eliot, so we can be even closer, yes :) Esteban > > Congrats for your work > > Clement > > > 2014-06-04 17:28 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Thanks Esteban! > > Hilaire > > > Le 04/06/2014 15:38, Esteban Lorenzano a Ã©crit : > > Hi, > > > > Iâve been working on re-aligning our sources to latest Eliot sources. > > This is a step previous to compile a spur vm for Pharo. > > So farâ¦ it was a lot of work but I have a working version (in mac, not yet tested in others)â¦ but I forget to port Igorâs finalization improvements (I forgot it was there and I passed over it when merging), now I have to put it back inâ¦ > > Overallâ¦ I have the impression latest Eliot versions are 5-10% faster than our current ones, but Iâm not sure (it could be just a good day for my machine), so we will need to wait until release. > > > > This is a necessary step: our codebase is diverging more and more from Eliotâs without any good reason, just a direct application of entropy laws, and we need to realign if we want to continue working together (and we certainly want :D). > > > > With luck, this work will be finished for the end of the week. > > > > cheers, > > Esteban > > > > > > > > -- > Dr. Geo http://drgeo.eu > > >

June 4, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Ben Coman

Esteban Lorenzano wrote: > Hi, > > A couple of weeks ago we started to plan Pharo4. This work became stagnated for many reasons, but mainly because I needed to travel to Argentina. > Now I'm slowly resuming the work and I wanted to share with you what we have been talking/dreaming. > In esence, we have two important drivers for this release: > > 1) Improving tools > Turns out that we have introduced a lot of kernel improvements (opal compiler, layouts, slots, etc.) and tools are still not aware of them. Even worst: we have traits since a lot of time and our tools are still now aware enough to provide good interoperability. > But not just that: we have introduced things that are not well used yet: keybindings (who do not want a better keybindings structure... coherent and editable?), spec should allow us to continue enhancing existing tools and to replace old ones. > > 2) Modularisation > One of the fundamental ideas behind Pharo is to provide a modular environment. But well... since Pharo start to the moment, we prepared things to allow it, but still few direct effort has been made. > In our dreams, Pharo should be built starting for a small kernel image and adding different modules to get a complete version. In this idea Pharo=Kernel+GUI(Morphic)+Tools. > This has huge advantages (I do not think is necesary to explain them, isn't ;)?) > > We brainstomed around this and we get this list of issues (not all of them directly related to the objectives, but well... good stuff also :) ) > > Web site: > - add catalog > Having the catalog accessible in-image from the Configuration Browser would be very useful. Also if when generating the catalog the system could would out what the versions are available from the Configuration, the being able to get a menu on an item in the Configuration Browser that should which versions were available would be super-cool. > - add videos > - enhance it in general > > Infrastructure: > - support more vm platforms > > VM: > - spur > - 64bits > - make vm embedable and UI independent (with SDL2 and OSWindow) > Those three for VM are super-cool. > Image: > - Modularisation > - Removing old compiler > - Repackage Morphic (to allow better modularisation) > - Athens (replace old bitblt) > > Tools > - Replace changes with Ombu/Epicea > - Replace sources with a better abstraction > Something that could grab additional version history from a repository would be good. Now that we are delivering images from CI which from Configurations, there is no version history, and I think we lose something there. > - Git support inside image (with libgit2 + tools) > Maybe this could facilitate a cool Roassal/Moose based "git analyser" application ? And maybe draw in some new end-users, who obviously once they want to customize it, will drawn into discovering Pharo. > - Pass on Spec > - Include Glamour? > - Make Ring unloadable > - Fonts with FreeType > > And lots of bugfixes :) > > We would like to exchange ideas with you. > So, what do you think? > > For KeyBindings, a useful tool would be one that: * could determine and display what the current bindings are - global, per tool and even per window if appropriate. * provided a history to help find what is overriding key bindings - including legacy methods of setting shortcuts. * allow end-users (even non-programmers) to define their own shortcuts similar to how other applications like MS Word do it - and all in the one place integrated with the previous two points. Now not one of the biggest issues in the world, but one annoyance when starting with Pharo was the yellowButton/redButton legacy. I guess that when the GUI was being invented they didn't have today's terminolgy, so using colour was beneficial as they explored the problem space - but are there better terms that could be used today - like "select" / "context" / "meta"?. Or is that too constraining even today. Maybe just "primary" "secondary" "tertiary" would be more understandable and familiar. Remote tools, that could help work with the minimal images, and on headless web servers. cheers -ben

June 4, 2014

Re: [Pharo-dev] Some PharoVM work news

by ClÃ©ment Bera

Esteban, What does the work of Igor in finalization consists in ? Does it make sense to propose to Eliot to integrate it in his branch ? Congrats for your work Clement 2014-06-04 17:28 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Thanks Esteban! > > Hilaire > > > Le 04/06/2014 15:38, Esteban Lorenzano a Ã©crit : > > Hi, > > > > Iâve been working on re-aligning our sources to latest Eliot sources. > > This is a step previous to compile a spur vm for Pharo. > > So farâ¦ it was a lot of work but I have a working version (in mac, not > yet tested in others)â¦ but I forget to port Igorâs finalization > improvements (I forgot it was there and I passed over it when merging), > now I have to put it back inâ¦ > > Overallâ¦ I have the impression latest Eliot versions are 5-10% faster > than our current ones, but Iâm not sure (it could be just a good day for my > machine), so we will need to wait until release. > > > > This is a necessary step: our codebase is diverging more and more from > Eliotâs without any good reason, just a direct application of entropy laws, > and we need to realign if we want to continue working together (and we > certainly want :D). > > > > With luck, this work will be finished for the end of the week. > > > > cheers, > > Esteban > > > > > > > > -- > Dr. Geo http://drgeo.eu > > >

June 4, 2014

Re: [Pharo-dev] Pharo and Amber

by H. Hirzel

Thank you for the link, Damien. https://github.com/tide-framework/tide tells me to do TDDispatcher tideIndexPageUrl inspect which leads to a 'subscript out of bounds error'. Any suggestions? How do I proceed to start the server and use Amber? Regards Hannes On 6/2/14, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Sun, Jun 1, 2014 at 11:19 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> Is there an Amber-Pharo one click built with CI >> to allow development with both (amber for client, >> pharo on server). > > > https://ci.inria.fr/pharo-contribution/job/Tide/ > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

June 4, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Hilaire Fernandes

Hi Esteban, As you mentioned a lot of new tools and protocols were introduced, people (me included) does not well about those ones. As an example I am slowly discovering announcement and now AFAIK the image use three different protocols for this: change/update, observer and Announcement! Personally I beg for a great Pharo 4.x series of iterative cleaning+consolidations. Thanks Hilaire Le 04/06/2014 17:36, Esteban Lorenzano a Ã©crit : > Hi, > > A couple of weeks ago we started to plan Pharo4. This work became stagnated for many reasons, but mainly because I needed to travel to Argentina. > Now I'm slowly resuming the work and I wanted to share with you what we have been talking/dreaming. > In esence, we have two important drivers for this release: > > 1) Improving tools > Turns out that we have introduced a lot of kernel improvements (opal compiler, layouts, slots, etc.) and tools are still not aware of them. Even worst: we have traits since a lot of time and our tools are still now aware enough to provide good interoperability. > But not just that: we have introduced things that are not well used yet: keybindings (who do not want a better keybindings structure... coherent and editable?), spec should allow us to continue enhancing existing tools and to replace old ones. > > 2) Modularisation > One of the fundamental ideas behind Pharo is to provide a modular environment. But well... since Pharo start to the moment, we prepared things to allow it, but still few direct effort has been made. > In our dreams, Pharo should be built starting for a small kernel image and adding different modules to get a complete version. In this idea Pharo=Kernel+GUI(Morphic)+Tools. > This has huge advantages (I do not think is necesary to explain them, isn't ;)?) > > We brainstomed around this and we get this list of issues (not all of them directly related to the objectives, but well... good stuff also :) ) > > Web site: > - add catalog > - add videos > - enhance it in general > > Infrastructure: > - support more vm platforms > > VM: > - spur > - 64bits > - make vm embedable and UI independent (with SDL2 and OSWindow) > > Image: > - Modularisation > - Removing old compiler > - Repackage Morphic (to allow better modularisation) > - Athens (replace old bitblt) > > Tools > - Replace changes with Ombu/Epicea > - Replace sources with a better abstraction > - Git support inside image (with libgit2 + tools) > - Pass on Spec > - Include Glamour? > - Make Ring unloadable > - Fonts with FreeType > > And lots of bugfixes :) > > We would like to exchange ideas with you. > So, what do you think? > > Esteban > > > -- Dr. Geo http://drgeo.eu

June 4, 2014

Brainstorming Pharo4

by Esteban Lorenzano

Hi, A couple of weeks ago we started to plan Pharo4. This work became stagnated for many reasons, but mainly because I needed to travel to Argentina. Now I'm slowly resuming the work and I wanted to share with you what we have been talking/dreaming. In esence, we have two important drivers for this release: 1) Improving tools Turns out that we have introduced a lot of kernel improvements (opal compiler, layouts, slots, etc.) and tools are still not aware of them. Even worst: we have traits since a lot of time and our tools are still now aware enough to provide good interoperability. But not just that: we have introduced things that are not well used yet: keybindings (who do not want a better keybindings structure... coherent and editable?), spec should allow us to continue enhancing existing tools and to replace old ones. 2) Modularisation One of the fundamental ideas behind Pharo is to provide a modular environment. But well... since Pharo start to the moment, we prepared things to allow it, but still few direct effort has been made. In our dreams, Pharo should be built starting for a small kernel image and adding different modules to get a complete version. In this idea Pharo=Kernel+GUI(Morphic)+Tools. This has huge advantages (I do not think is necesary to explain them, isn't ;)?) We brainstomed around this and we get this list of issues (not all of them directly related to the objectives, but well... good stuff also :) ) Web site: - add catalog - add videos - enhance it in general Infrastructure: - support more vm platforms VM: - spur - 64bits - make vm embedable and UI independent (with SDL2 and OSWindow) Image: - Modularisation - Removing old compiler - Repackage Morphic (to allow better modularisation) - Athens (replace old bitblt) Tools - Replace changes with Ombu/Epicea - Replace sources with a better abstraction - Git support inside image (with libgit2 + tools) - Pass on Spec - Include Glamour? - Make Ring unloadable - Fonts with FreeType And lots of bugfixes :) We would like to exchange ideas with you. So, what do you think? Esteban

June 4, 2014

TextMorph on Athens

by Hilaire Fernandes

Hi, DrGeo needs to know what is the status of TextMorph on Athens. I have been through most of the broken parts of DrGeo@Pharo3 (really a lot!), and this one is the last one AFAIK. Depending on, I may write a temporary hack to bypass textmorph, but may be it is not necessary and DrGeo can wait a bit, but I need to know. Thanks Hilaire -- Dr. Geo http://drgeo.eu

June 4, 2014

Re: [Pharo-dev] Some PharoVM work news

by Hilaire Fernandes

Thanks Esteban! Hilaire Le 04/06/2014 15:38, Esteban Lorenzano a Ã©crit : > Hi, > > Iâve been working on re-aligning our sources to latest Eliot sources. > This is a step previous to compile a spur vm for Pharo. > So farâ¦ it was a lot of work but I have a working version (in mac, not yet tested in others)â¦ but I forget to port Igorâs finalization improvements (I forgot it was there and I passed over it when merging), now I have to put it back inâ¦ > Overallâ¦ I have the impression latest Eliot versions are 5-10% faster than our current ones, but Iâm not sure (it could be just a good day for my machine), so we will need to wait until release. > > This is a necessary step: our codebase is diverging more and more from Eliotâs without any good reason, just a direct application of entropy laws, and we need to realign if we want to continue working together (and we certainly want :D). > > With luck, this work will be finished for the end of the week. > > cheers, > Esteban > > > -- Dr. Geo http://drgeo.eu

June 4, 2014