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
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
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! Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
Hi all,
From my point of view, I like the progrss on the ARM VM. I hope to have an Android VM that works. Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. Is it possible to integrate them in the VM build ? Thank you guys for all the work done. Jannik 2014-06-04 20:53 GMT+02:00 stepharo <stepharo@free.fr>:
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!
Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
-- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact. However, here's my personal top 5: - **Git in the image**, that would be awesome to be able integrate the gitflow way of developing in team. Easy branching/merging is a must. - **Slots**. I still need to check the current implementation and see what's possible (Property slots?) but as I have understood you've planned even more for pharo4? - **Text Editor with sensible keybindings**. - **ARM support** - **Athens** On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval@gmail.com> wrote:
Hi all,
From my point of view, I like the progrss on the ARM VM. I hope to have an Android VM that works. Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. Is it possible to integrate them in the VM build ?
Thank you guys for all the work done. Jannik
2014-06-04 20:53 GMT+02:00 stepharo <stepharo@free.fr>:
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!
Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
--
~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
On Thu, Jun 5, 2014 at 8:31 AM, François Stephany <tulipe.moutarde@gmail.com
wrote:
As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
However, here's my personal top 5:
- **Git in the image**, that would be awesome to be able integrate the gitflow way of developing in team. Easy branching/merging is a must. - **Slots**. I still need to check the current implementation and see what's possible (Property slots?) but as I have understood you've planned even more for pharo4? - **Text Editor with sensible keybindings**. - **ARM support** - **Athens**
Keybindings that do work on Linux VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15 Debugger that actually doesn't throws you in space after a couple of restart/through/over (this one really is taking power away from the whole experience) Faster UI in general Easier Git merges without metadata issues etc Ability to recover frozen images (as in "Oz") Ability to somehow get back control of the image through some mechanism at the VM level when frozen and no way to interrupt anything. I am ready to pay some performance in order to work that way. Removal of all passwords, including whatever could be in the .changes (which will disappear per se but you get my drift). +1 for Mpeg and Camera plugins; Traits should indeed be given a better treatment in Nautilus. Phil
On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval@gmail.com> wrote:
Hi all,
From my point of view, I like the progrss on the ARM VM. I hope to have an Android VM that works. Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. Is it possible to integrate them in the VM build ?
Thank you guys for all the work done. Jannik
2014-06-04 20:53 GMT+02:00 stepharo <stepharo@free.fr>:
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!
Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
--
~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
Here is my short, ordered list: - VM should run as a normal 64-bit citizen with the current 32-bit address space (it is really annoying that we need 32-bit libraries, it hinders deployment on modern virtual hardware like Xen, Docker, .. - and it makes us look weird and old) - VM should break the 32-bit memory limitation and use a 64-bit address space (we are currently limited to 1GB of memory in use, http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a4... - today's hardware easily offers many times more for little money, which we should be able to use for monolithic memory persistent data structures) - Modularity in the core development (we have to keep Pharo lean and mean, we cannot make another mess like the one we are still cleaning up) - Capitalize on our tool set by improving it (the magic of Pharo is, for a large part, situated in the IDE, but we have to invest in that area to remain relevant) Of course, handle format X, talk protocol Y, connect to database Z are all important, but can contributed externally. But to remain successful, we need a solid, modern base. Sven On 05 Jun 2014, at 10:14, phil@highoctane.be wrote:
On Thu, Jun 5, 2014 at 8:31 AM, François Stephany <tulipe.moutarde@gmail.com> wrote: As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
However, here's my personal top 5:
- **Git in the image**, that would be awesome to be able integrate the gitflow way of developing in team. Easy branching/merging is a must. - **Slots**. I still need to check the current implementation and see what's possible (Property slots?) but as I have understood you've planned even more for pharo4? - **Text Editor with sensible keybindings**. - **ARM support** - **Athens**
Keybindings that do work on Linux VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15 Debugger that actually doesn't throws you in space after a couple of restart/through/over (this one really is taking power away from the whole experience) Faster UI in general Easier Git merges without metadata issues etc Ability to recover frozen images (as in "Oz") Ability to somehow get back control of the image through some mechanism at the VM level when frozen and no way to interrupt anything. I am ready to pay some performance in order to work that way. Removal of all passwords, including whatever could be in the .changes (which will disappear per se but you get my drift). +1 for Mpeg and Camera plugins; Traits should indeed be given a better treatment in Nautilus.
Phil
On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval@gmail.com> wrote: Hi all,
From my point of view, I like the progrss on the ARM VM. I hope to have an Android VM that works. Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. Is it possible to integrate them in the VM build ?
Thank you guys for all the work done. Jannik
2014-06-04 20:53 GMT+02:00 stepharo <stepharo@free.fr>:
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! Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
-- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
+1 Alexandre On Jun 5, 2014, at 10:57 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Here is my short, ordered list:
- VM should run as a normal 64-bit citizen with the current 32-bit address space
(it is really annoying that we need 32-bit libraries, it hinders deployment on modern virtual hardware like Xen, Docker, .. - and it makes us look weird and old)
- VM should break the 32-bit memory limitation and use a 64-bit address space
(we are currently limited to 1GB of memory in use, http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a4... - today's hardware easily offers many times more for little money, which we should be able to use for monolithic memory persistent data structures)
- Modularity in the core development
(we have to keep Pharo lean and mean, we cannot make another mess like the one we are still cleaning up)
- Capitalize on our tool set by improving it
(the magic of Pharo is, for a large part, situated in the IDE, but we have to invest in that area to remain relevant)
Of course, handle format X, talk protocol Y, connect to database Z are all important, but can contributed externally. But to remain successful, we need a solid, modern base.
Sven
On 05 Jun 2014, at 10:14, phil@highoctane.be wrote:
On Thu, Jun 5, 2014 at 8:31 AM, François Stephany <tulipe.moutarde@gmail.com> wrote: As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
However, here's my personal top 5:
- **Git in the image**, that would be awesome to be able integrate the gitflow way of developing in team. Easy branching/merging is a must. - **Slots**. I still need to check the current implementation and see what's possible (Property slots?) but as I have understood you've planned even more for pharo4? - **Text Editor with sensible keybindings**. - **ARM support** - **Athens**
Keybindings that do work on Linux VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15 Debugger that actually doesn't throws you in space after a couple of restart/through/over (this one really is taking power away from the whole experience) Faster UI in general Easier Git merges without metadata issues etc Ability to recover frozen images (as in "Oz") Ability to somehow get back control of the image through some mechanism at the VM level when frozen and no way to interrupt anything. I am ready to pay some performance in order to work that way. Removal of all passwords, including whatever could be in the .changes (which will disappear per se but you get my drift). +1 for Mpeg and Camera plugins; Traits should indeed be given a better treatment in Nautilus.
Phil
On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval@gmail.com> wrote: Hi all,
From my point of view, I like the progrss on the ARM VM. I hope to have an Android VM that works. Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. Is it possible to integrate them in the VM build ?
Thank you guys for all the work done. Jannik
2014-06-04 20:53 GMT+02:00 stepharo <stepharo@free.fr>:
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! Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
-- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Sven, On Thu, Jun 5, 2014 at 1:57 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Here is my short, ordered list:
- VM should run as a normal 64-bit citizen with the current 32-bit address space
(it is really annoying that we need 32-bit libraries, it hinders deployment on modern virtual hardware like Xen, Docker, .. - and it makes us look weird and old)
Yes, this is annoying but unfortunately it does not make economic sense. To have a 64-bit compiled Cog VM with 32-bit objects means - developing an x86-64 code generator that moves 32-bit units instead of the more natural 64-bit units - developing a 64-bit FFI that uses the x86-64 ABIs and converts back and forth between 32-bit objects Both of these are expensive to develop (especially the former), but give us nothing beyond what installing 32-bit libraries gives us.
- VM should break the 32-bit memory limitation and use a 64-bit address space
Now this does make sense. In fact it is a key goal of the Spur work. That will produce a full 64-bit image complete with 61-bit SmallIntegers, and 61-bit immediate floats, and a full 64-bit FFI. This should be in production some time next year, probably second half.
(we are currently limited to 1GB of memory in use, http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a4... - today's hardware easily offers many times more for little money, which we should be able to use for monolithic memory persistent data structures)
In fact, we are able to allocate 1.9Gb reliably on Mac OS and 2.2Gb on linux at Cadence. But yes, the current ~ 2Gb limit is, um, limiting. The 64-bit Spur system will not suffer from this limitation. The 32-bit system may be able to grow above 2Bg on MacOS X, because Spur uses memory segments. But I haven't done any work to to ensure this works.
- Modularity in the core development
(we have to keep Pharo lean and mean, we cannot make another mess like the one we are still cleaning up)
- Capitalize on our tool set by improving it
(the magic of Pharo is, for a large part, situated in the IDE, but we have to invest in that area to remain relevant)
Of course, handle format X, talk protocol Y, connect to database Z are all important, but can contributed externally. But to remain successful, we need a solid, modern base.
+1 (in fact I'm in emphatic agreement about this one; it is my core direction to provide a great Smalltalk platform via Cog). Hence some other things that need to happen are: - refactor the VM into a small main program, a core execution engine dll/shared object, and a gui library/shared object to allow embedding Pharo/Squeak in other programs, and smaller footprint when running headless (AFAIA this is not being worked on) - provide web browser plugin capability, probably via a rendering and event channelling slave written in JavaScript that is connected to the Cog VM via sockets. (AFAIA this is not being worked on) - make NativeBoost cross platform, and implement the rules for the ARM and x86-64 ABIs in this system (this is being worked on by) - implement adaptive optimization ("sista") to provide another significant performance boost (this is being worked on). Again Clément and I think Sista could be in production in 2015. And related to this I hope to make alpha 32-bit Spur Squeak VMs and images available today. Sven
On 05 Jun 2014, at 10:14, phil@highoctane.be wrote:
On Thu, Jun 5, 2014 at 8:31 AM, François Stephany < tulipe.moutarde@gmail.com> wrote: As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
However, here's my personal top 5:
- **Git in the image**, that would be awesome to be able integrate the gitflow way of developing in team. Easy branching/merging is a must. - **Slots**. I still need to check the current implementation and see what's possible (Property slots?) but as I have understood you've planned even more for pharo4? - **Text Editor with sensible keybindings**. - **ARM support** - **Athens**
Keybindings that do work on Linux VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15 Debugger that actually doesn't throws you in space after a couple of restart/through/over (this one really is taking power away from the whole experience) Faster UI in general Easier Git merges without metadata issues etc Ability to recover frozen images (as in "Oz") Ability to somehow get back control of the image through some mechanism at the VM level when frozen and no way to interrupt anything. I am ready to pay some performance in order to work that way. Removal of all passwords, including whatever could be in the .changes (which will disappear per se but you get my drift). +1 for Mpeg and Camera plugins; Traits should indeed be given a better treatment in Nautilus.
Phil
On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval@gmail.com> wrote: Hi all,
From my point of view, I like the progrss on the ARM VM. I hope to have an Android VM that works. Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. Is it possible to integrate them in the VM build ?
Thank you guys for all the work done. Jannik
2014-06-04 20:53 GMT+02:00 stepharo <stepharo@free.fr>:
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! Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
-- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
-- best, Eliot
On 06 Jun 2014, at 17:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:
And related to this I hope to make alpha 32-bit Spur Squeak VMs and images available today.
Cool !
Sven
On 05 Jun 2014, at 10:14, phil@highoctane.be wrote:
On Thu, Jun 5, 2014 at 8:31 AM, François Stephany <tulipe.moutarde@gmail.com> wrote: As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
However, here's my personal top 5:
- **Git in the image**, that would be awesome to be able integrate the gitflow way of developing in team. Easy branching/merging is a must. - **Slots**. I still need to check the current implementation and see what's possible (Property slots?) but as I have understood you've planned even more for pharo4? - **Text Editor with sensible keybindings**. - **ARM support** - **Athens**
Keybindings that do work on Linux VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15 Debugger that actually doesn't throws you in space after a couple of restart/through/over (this one really is taking power away from the whole experience) Faster UI in general Easier Git merges without metadata issues etc Ability to recover frozen images (as in "Oz") Ability to somehow get back control of the image through some mechanism at the VM level when frozen and no way to interrupt anything. I am ready to pay some performance in order to work that way. Removal of all passwords, including whatever could be in the .changes (which will disappear per se but you get my drift). +1 for Mpeg and Camera plugins; Traits should indeed be given a better treatment in Nautilus.
Phil
On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval@gmail.com> wrote: Hi all,
From my point of view, I like the progrss on the ARM VM. I hope to have an Android VM that works. Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. Is it possible to integrate them in the VM build ?
Thank you guys for all the work done. Jannik
2014-06-04 20:53 GMT+02:00 stepharo <stepharo@free.fr>:
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! Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
-- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
However, here's my personal top 5:
- **Git in the image**, that would be awesome to be able integrate the gitflow way of developing in team. Easy branching/merging is a must. - **Slots**. I still need to check the current implementation and see what's possible (Property slots?) but as I have understood you've planned even more for pharo4? - **Text Editor with sensible keybindings**. - **ARM support** - **Athens**
We are getting there.
On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval@gmail.com <mailto:jannik.laval@gmail.com>> wrote:
Hi all,
>From my point of view, I like the progrss on the ARM VM. I hope to have an Android VM that works. Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. Is it possible to integrate them in the VM build ?
Thank you guys for all the work done. Jannik
2014-06-04 20:53 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
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!
Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
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
--
~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/
Le 04/06/2014 20:53, stepharo a écrit :
As an example I am slowly discovering announcement and now AFAIK the image use three different protocols for this: change/update, observer and Announcement! Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
change/update when:send:to:/triggerEvent: Announcement This is just an example where developer get confused. This is why I beg for consolidations, incidentally more people may be capable to help on that tasks -- Dr. Geo http://drgeo.eu
Le 04/06/2014 20:53, stepharo a écrit :
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! Yes we know that the situation is not ideal. We started to move more to announcement. The problem is that some of the widgets requires the change/update. For the observer I do not know what you mean.
change/update when:send:to:/triggerEvent: Announcement This is just an example where developer get confused. This is why I beg for consolidations, incidentally more people may be capable to help (and learn) on these tasks -- Dr. Geo http://drgeo.eu
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
Hi Esteban, The list you provide looks great. The main problem I am facing is about fonts. This is not completely solved. Alexandre
Le 04-06-2014 à 17:36, Esteban Lorenzano <estebanlm@gmail.com> 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
I can subscribe to most what others have said. Your list is pretty good and I like even the order of things. Only a few additions. âImproving toolsâ: One aspect is making the tools aware of new achievements in the core. Another aspect is to finish things that did change in the past like e.g. keybindings. Nautilus uses new keyboard shortcut while other tools use old ones. That is killing the development experience. âModularizationâ: I think this should be _the_ goal for pharo4: Changing the whole build process to a bootstrap+module approach. This is a huge step IMHO. To make it more modular also means things can get smaller and smaller. This also raises the necessity of having remote debugging tools because UI is suspect to not being there. This step will also improve the way we can manage deployed images which is especially important for a company like mine. And I hope having decent remote enabled model will also open new possibilities for image interoperation. 64bit vm: Like sven said it is necessary for us to have at least a 64bit vm with a 32bit address space. Without that we are somewhat way behind what is normal for others. 64bit address space should be a goal for pharo5. Slots: I would like it to see Slots being usable. It enables people to play with new things without having to tweak the vm. And I like all magritte like stuff being handled by slots which will improve the situation a lot. And thatâs one thing that sets us way ahead of what is normal for others. Remove old compiler for obvious reasons. So that would be one to two tasks for areas of improve existing (maintenance), change for the better, distribution and cleanup. That would be all for pharo4 for me. Norbert Am 04.06.2014 um 17:36 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
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
yeap I agree, 64bit is number one ... time for pharo to join with the others. On Thu, Jun 5, 2014 at 12:46 PM, Norbert Hartl <norbert@hartl.name> wrote:
I can subscribe to most what others have said. Your list is pretty good and I like even the order of things. Only a few additions.
âImproving toolsâ: One aspect is making the tools aware of new achievements in the core. Another aspect is to finish things that did change in the past like e.g. keybindings. Nautilus uses new keyboard shortcut while other tools use old ones. That is killing the development experience.
âModularizationâ: I think this should be _the_ goal for pharo4: Changing the whole build process to a bootstrap+module approach. This is a huge step IMHO. To make it more modular also means things can get smaller and smaller. This also raises the necessity of having remote debugging tools because UI is suspect to not being there. This step will also improve the way we can manage deployed images which is especially important for a company like mine. And I hope having decent remote enabled model will also open new possibilities for image interoperation.
64bit vm: Like sven said it is necessary for us to have at least a 64bit vm with a 32bit address space. Without that we are somewhat way behind what is normal for others. 64bit address space should be a goal for pharo5.
Slots: I would like it to see Slots being usable. It enables people to play with new things without having to tweak the vm. And I like all magritte like stuff being handled by slots which will improve the situation a lot. And thatâs one thing that sets us way ahead of what is normal for others.
Remove old compiler for obvious reasons.
So that would be one to two tasks for areas of improve existing (maintenance), change for the better, distribution and cleanup. That would be all for pharo4 for me.
Norbert
Am 04.06.2014 um 17:36 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
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
I can subscribe to most what others have said. Your list is pretty good and I like even the order of things. Only a few additions.
âImproving toolsâ: One aspect is making the tools aware of new achievements in the core. Another aspect is to finish things that did change in the past like e.g. keybindings. Nautilus uses new keyboard shortcut while other tools use old ones. That is killing the development experience.
I cannot agree more on that one :)
âModularizationâ: I think this should be _the_ goal for pharo4: Changing the whole build process to a bootstrap+module approach. This is a huge step IMHO. To make it more modular also means things can get smaller and smaller. This also raises the necessity of having remote debugging tools because UI is suspect to not being there. This step will also improve the way we can manage deployed images which is especially important for a company like mine. And I hope having decent remote enabled model will also open new possibilities for image interoperation.
that too.
64bit vm: Like sven said it is necessary for us to have at least a 64bit vm with a 32bit address space. Without that we are somewhat way behind what is normal for others. 64bit address space should be a goal for pharo5.
Slots: I would like it to see Slots being usable. It enables people to play with new things without having to tweak the vm. And I like all magritte like stuff being handled by slots which will improve the situation a lot. And thatâs one thing that sets us way ahead of what is normal for others.
Remove old compiler for obvious reasons.
So that would be one to two tasks for areas of improve existing (maintenance), change for the better, distribution and cleanup. That would be all for pharo4 for me.
Norbert
Am 04.06.2014 um 17:36 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
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
Le 14/06/2014 15:03, stepharo a écrit :
âImproving toolsâ: One aspect is making the tools aware of new achievements in the core. Another aspect is to finish things that did change in the past like e.g. keybindings. Nautilus uses new keyboard shortcut while other tools use old ones. That is killing the development experience.
I cannot agree more on that one :)
For me this is consolidation: making the whole system very consistent and coherent is damn important so that user (particularly new user) are surprised as few as possible. I am willing to help on that if any direction is decided. Thanks Hilaire -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa
I cannot agree more on that one :) For me this is consolidation: making the whole system very consistent and coherent is damn important so that user (particularly new user) are surprised as few as possible. I am willing to help on that if any direction is decided.
between you and me, I always raised this point but I was not heard (personally I'm not fan of composed keys) So hilaire to help we should use keybinding (check the draft chapter in pharo for the entreprise) and kill all the hardcoded bindings. We could make a list and fix them one by one. Stef
Thanks
Hilaire
Agree Le 15/06/2014 09:34, stepharo a écrit :
between you and me, I always raised this point but I was not heard (personally I'm not fan of composed keys) So hilaire to help we should use keybinding (check the draft chapter in pharo for the entreprise) and kill all the hardcoded bindings.
We could make a list and fix them one by one.
-- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa
In regard to improving tools. One of the most common criticism I hear about dynamically typed languages, is that you can't have precise code completion, and without this, it is impossible to know what methods can be used in given context. My usual response is, that you can, just ask the object what messages do you respond to. Then I explain what a live object is, and how coding inside the debugger work. The problem is, neither the Debugger nor the Workspace take advantages of this. If I start typing a message inside the Debugger, the code completion won't take the type of the receiver into consideration. -- View this message in context: http://forum.world.st/Brainstorming-Pharo4-tp4761647p4761805.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
It would also be amazing to have mouse wheel properly implemented in the VM. Or maybe we should just wait for the work of Ronie... Alexandre On Jun 4, 2014, at 5:36 PM, Esteban Lorenzano <estebanlm@gmail.com> 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 - 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
EstebanLM wrote
We would like to exchange ideas with you. So, what do you think?
For me, the two things that I wish for daily: - clean Morphic - new text editor ----- Cheers, Sean -- View this message in context: http://forum.world.st/Brainstorming-Pharo4-tp4761647p4762391.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi everyone. I would also add here the issue with side-scroll handling. I donât know if anybody uses this âfeatureâ but itâs really annoying that when you use trackpad it always switches focus to adjacent panels. Uko On 04 Jun 2014, at 17:36, Esteban Lorenzano <estebanlm@gmail.com> 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 - 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
Yes, this is a serious problem in my opinion. Alexandre On Jun 11, 2014, at 10:02 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
I would also add here the issue with side-scroll handling. I donât know if anybody uses this âfeatureâ but itâs really annoying that when you use trackpad it always switches focus to adjacent panels.
Uko
On 04 Jun 2014, at 17:36, Esteban Lorenzano <estebanlm@gmail.com> 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 - 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Can some low-priority consideration be given to the compiler accepting methods of the form: MyClass>>myMethod "in accessors" ^ 1 + 3 The current System Browser my also be switched to that method at the same time, or a new System Browser opened if this is entered from Workspace. I see some advantages for this for tutorials, where methods are presented using the ">>" convention, and readers might copy-paste the whole code. cheers -ben
Soon soon :) but in this form MyClass>>myMethod [ ^ 1 + 3 ] ;)
MyClass>>myMethod "in accessors" ^ 1 + 3
The current System Browser my also be switched to that method at the same time, or a new System Browser opened if this is entered from Workspace. I see some advantages for this for tutorials, where methods are presented using the ">>" convention, and readers might copy-paste the whole code.
cheers -ben
stepharo wrote:
Soon soon :) but in this form
MyClass>>myMethod [ ^ 1 + 3 ]
Glad to hear it. Can you consider some _optional_ way to also specify the protocol. Some random ideas... 1. MyClass>>accessors>>myMethod: anObject 2. MyClass>>'accessors'>>myMethod: anObject 3. MyClass(acccessors)>>myMethod: anObject 4. MyClass"accessors">>myMethod: anObject 5. MyClass^accessors>>myMethod: anObject cheers -ben
;)
MyClass>>myMethod "in accessors" ^ 1 + 3
The current System Browser my also be switched to that method at the same time, or a new System Browser opened if this is entered from Workspace. I see some advantages for this for tutorials, where methods are presented using the ">>" convention, and readers might copy-paste the whole code.
cheers -ben
and copy-paste that in playground and CTRL-O will open the Browser ;-) On Sun, Jun 15, 2014 at 2:17 PM, stepharo <stepharo@free.fr> wrote:
Soon soon :) but in this form
MyClass>>myMethod [ ^ 1 + 3 ]
;)
MyClass>>myMethod "in accessors" ^ 1 + 3
The current System Browser my also be switched to that method at the same time, or a new System Browser opened if this is entered from Workspace. I see some advantages for this for tutorials, where methods are presented using the ">>" convention, and readers might copy-paste the whole code.
cheers -ben
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Add this to the wishlist: - Scoped refactorings. Particularly method renames. I'd like to scope the refactorings to class, hierarchy, package or global level. :) Esteban A. Maringolo 2014-06-15 11:18 GMT-03:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
and copy-paste that in playground and CTRL-O will open the Browser ;-)
On Sun, Jun 15, 2014 at 2:17 PM, stepharo <stepharo@free.fr> wrote:
Soon soon :) but in this form
MyClass>>myMethod [ ^ 1 + 3 ]
;)
MyClass>>myMethod "in accessors" ^ 1 + 3
The current System Browser my also be switched to that method at the same time, or a new System Browser opened if this is entered from Workspace. I see some advantages for this for tutorials, where methods are presented using the ">>" convention, and readers might copy-paste the whole code.
cheers -ben
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Le 16/06/2014 16:13, Esteban A. Maringolo a écrit :
Add this to the wishlist:
- Scoped refactorings. Particularly method renames. I'd like to scope the refactorings to class, hierarchy, package or global level. :)
I think it's already there :) Just need a way to use them. I may already have that, need to test (scoped system browser with refactorings coupled to the scope). Try scoped browsing with Nautilus and apply refactorings... 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
2014-06-16 16:13 GMT+02:00 Esteban A. Maringolo <emaringolo@gmail.com>:
Add this to the wishlist:
- Scoped refactorings. Particularly method renames. I'd like to scope the refactorings to class, hierarchy, package or global level. :)
This is already in the image. You can click on "browse scoped" in Nautilus and then all the refactorings are scoped into what you browse.
Clement
Esteban A. Maringolo
2014-06-15 11:18 GMT-03:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
and copy-paste that in playground and CTRL-O will open the Browser ;-)
On Sun, Jun 15, 2014 at 2:17 PM, stepharo <stepharo@free.fr> wrote:
Soon soon :) but in this form
MyClass>>myMethod [ ^ 1 + 3 ]
;)
MyClass>>myMethod "in accessors" ^ 1 + 3
The current System Browser my also be switched to that method at the
same
time, or a new System Browser opened if this is entered from Workspace. I see some advantages for this for tutorials, where methods are presented using the ">>" convention, and readers might copy-paste the whole code.
cheers -ben
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
participants (19)
-
Alexandre Bergel -
Attila Magyar -
Ben Coman -
Clément Bera -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
François Stephany -
Goubier Thierry -
Hilaire Fernandes -
jannik laval -
kilon alios -
Norbert Hartl -
phil＠highoctane.be -
Sean P. DeNigris -
Serge Stinckwich -
stepharo -
Sven Van Caekenberghe -
Yuriy Tymchuk