[Pharo-dev] Brainstorming Pharo4

[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

[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

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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

[stepharo]

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

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.

Post by Hilaire Fernandes
Personally I beg for a great Pharo 4.x series of iterative
cleaning+consolidations.
Thanks
Hilaire

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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]

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

Hi Esteban,

Post by Hilaire Fernandes
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.

Post by Hilaire Fernandes
Personally I beg for a great Pharo 4.x series of iterative
cleaning+consolidations.
Thanks
Hilaire

Post 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.
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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140604/6d134aa5/attachment-0001.html>

[François Stephany]

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

Post by jannik laval
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

Post by Hilaire Fernandes
Hi Esteban,

Post by Hilaire Fernandes
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.

Post by Hilaire Fernandes
Personally I beg for a great Pharo 4.x series of iterative
cleaning+consolidations.
Thanks
Hilaire

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140605/35748f35/attachment.html>

[phil]

On Thu, Jun 5, 2014 at 8:31 AM, Fran?ois Stephany <tulipe.moutarde at gmail.com

Post by François Stephany
As Kilon say, this is a personal wishlist. Any direction you mentioned is
worth and will have impact.
- **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

Post by François Stephany

Post by jannik laval
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

Post by Hilaire Fernandes
Hi Esteban,

Post by Hilaire Fernandes
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.

Post by Hilaire Fernandes
Personally I beg for a great Pharo 4.x series of iterative
cleaning+consolidations.
Thanks
Hilaire

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140605/25b475ee/attachment-0001.html>

[Sven Van Caekenberghe]

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

As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
- **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
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
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
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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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]

+1

Alexandre

Post by Sven Van Caekenberghe
- 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#a4696306 - 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

As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
- **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
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
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
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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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/

[Eliot Miranda]

Hi Sven,

Post by Sven Van Caekenberghe
- 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.

Post by Sven Van Caekenberghe
- 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.

Post by Sven Van Caekenberghe
(we are currently limited to 1GB of memory in use,
http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a4696306
- 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.

Post by Sven Van Caekenberghe
- 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

Post by Sven Van Caekenberghe

Post by phil
On Thu, Jun 5, 2014 at 8:31 AM, Fran?ois Stephany <
As Kilon say, this is a personal wishlist. Any direction you mentioned

is worth and will have impact.

Post by phil
- **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.

Post by phil
- **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?

Post by phil
- **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)

Post by phil
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.

Post by phil
Removal of all passwords, including whatever could be in the .changes

(which will disappear per se but you get my drift).

Post by phil
+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 at gmail.com>
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.

Post by phil
Is it possible to integrate them in the VM build ?
Thank you guys for all the work done.
Jannik
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

Post by phil
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
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.

Post by phil
Now I'm slowly resuming the work and I wanted to share with you what we

have been talking/dreaming.

Post by phil
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.
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.

Post by phil
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.

Post by phil
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.

Post by phil
This has huge advantages (I do not think is necesary to explain them,

isn't ;)?)

Post by phil
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 :) )

Post by phil
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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/

[Sven Van Caekenberghe]

And related to this I hope to make alpha 32-bit Spur Squeak VMs and images available today.

Cool !

Sven

As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact.
- **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
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
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
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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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/

[stepharo]

Post by François Stephany
As Kilon say, this is a personal wishlist. Any direction you mentioned
is worth and will have impact.
- **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.

Post by François Stephany
On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval at gmail.com
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 at 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
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
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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and
OSWindow)
- 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140614/23d87729/attachment-0001.html>

[Hilaire Fernandes]

Post by stepharo

Post by Hilaire Fernandes
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

[Hilaire Fernandes]

Post by stepharo

Post by Hilaire Fernandes
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

[Ben Coman]

Post 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.
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 :) )
- 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.

Post by Esteban Lorenzano
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)

Those three for VM are super-cool.

Post by Esteban Lorenzano
- 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.

Post by Esteban Lorenzano
- 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.

Post by Esteban Lorenzano
- 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

[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

[Esteban Lorenzano]

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

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.

Post by Stephan Eggermont
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

Post by Stephan Eggermont
Stephan

[Esteban Lorenzano]

btw? a small clarification.
What I sent is just a brainstorm session.
That means: is something we would like, but

a) is open to discussion, and
b) not necessarily we will have the time to implement everything we want. For that, we also rely on the community? :)

cheers,
Esteban

Post 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

[kilon alios]

Disclaimer : The following ideas are general ideas of my own that I am not
even sure if I want to pursue them, in no way should be considered
recommendations for Pharo 4 and are nothing more than random thoughts that
make me curious.

1) Ok this one is a kinda crazy one but here we go. I was thinking of a
component based software synthesis system. "Component based" means that
every pharo tool and every pharo library is divided in a set of components.
So far in Pharo we have objects, the problem however with objects is that
offer complete freedom. A component on the other hand can be a single
object or a small selection of objects that however has severe limitations
in its design, meaning it follows a specific set of rules. These would be
there to make components compatible with each other which in turn leads to
the next part , "software synthesis". By software synthesis I mean the
ability to use components together with ease (maybe drag n drop ? ) to
create new libraries and new pharo tools. So in sort brake down Pharo into
small legos, legos however have a very rigid way how they can be connected
together.

The benefit of this system is to allow users to create their own set of
tools very quickly or to customise existing ones without the need of
understanding methods or classes. Ideally these components will be self
documented, meaning will come with its own component comments separate from
calls and method comments.

2) Unification of Documentation. Both Pillar and git integration have been
quite successful, continuing on this model make this a standard way of
documenting and provide users a way to view pillar documentation from
inside pharo and ideally offer a pillar editor too for easily expanding the
documentation always with full integration with git and github repos.

3) Morphic Cleanup. I know Spec is the new kid in the block , together with
Athens and Roassal. But the general design of Morphic is by far my
favourite. Instead of moving away from Morphic I would prefer to see
Morphic getting a clean up , make it smaller, easier and better documented
(I can help there). If possible kick out of the image morphic libraries
that are not necessary and have them only as optional third libraries.

I also love the idea of improving shortcuts they are a big deal for people
coming from emacs and vim.


On Wed, Jun 4, 2014 at 9:02 PM, Esteban Lorenzano <estebanlm at gmail.com>

Post by Esteban Lorenzano
btw? a small clarification.
What I sent is just a brainstorm session.
That means: is something we would like, but
a) is open to discussion, and
b) not necessarily we will have the time to implement everything we want.
For that, we also rely on the community? :)
cheers,
Esteban

Post 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 :)

Post by Stephan Eggermont
I assume the embeddable vm work includes resurrecting coral?
We can create a ConfigurationOfGlamour that avoids loading the whole of

Moose ;)

Post by Stephan Eggermont
Stephan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140604/4908683f/attachment.html>

[Alexandre Bergel]

Hi Esteban,

The list you provide looks great. The main problem I am facing is about fonts. This is not completely solved.

Alexandre

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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

[Norbert Hartl]

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

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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

[kilon alios]

yeap I agree, 64bit is number one ... time for pharo to join with the
others.

Post by Norbert Hartl
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

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

Post by Esteban Lorenzano
Now I'm slowly resuming the work and I wanted to share with you what we

have been talking/dreaming.

Post by Esteban Lorenzano
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.
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.

Post by Esteban Lorenzano
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.

Post by Esteban Lorenzano
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.

Post by Esteban Lorenzano
This has huge advantages (I do not think is necesary to explain them,

isn't ;)?)

Post by Esteban Lorenzano
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 :) )

Post by Esteban Lorenzano
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140605/b391a739/attachment.html>

[stepharo]

Post by Norbert Hartl
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 :)

Post by Norbert Hartl
?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.

Post by Norbert Hartl
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

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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

[Hilaire Fernandes]

Post by stepharo

Post by Norbert Hartl
?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

[stepharo]

Post by Hilaire Fernandes

Post by stepharo
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

Post by Hilaire Fernandes
Thanks
Hilaire

[Hilaire Fernandes]

Agree

Post by stepharo
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.

[Attila Magyar]

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.

[Alexandre Bergel]

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

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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

[Sean P. DeNigris]

Post by Esteban Lorenzano
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.

[Yuriy Tymchuk]

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

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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]

Yes, this is a serious problem in my opinion.

Alexandre

Post by Yuriy Tymchuk
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

Post 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.
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 :) )
- add catalog
- add videos
- enhance it in general
- support more vm platforms
- spur
- 64bits
- make vm embedable and UI independent (with SDL2 and OSWindow)
- 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

[Ben Coman]

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

[stepharo]

Soon soon :)
but in this form

MyClass>>myMethod
[
^ 1 + 3
]

;)

Post by Ben Coman
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

[Ben Coman]

Post by stepharo
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

Post by stepharo
;)

Post by Ben Coman
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]

and copy-paste that in playground and CTRL-O will open the Browser ;-)

Post by stepharo
Soon soon :)
but in this form
MyClass>>myMethod
[
^ 1 + 3
]
;)

Post by Ben Coman
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

[Esteban A. Maringolo]

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

Post by Serge Stinckwich
and copy-paste that in playground and CTRL-O will open the Browser ;-)

Post by stepharo
Soon soon :)
but in this form
MyClass>>myMethod
[
^ 1 + 3
]
;)

Post by Ben Coman
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/

[Goubier Thierry]

Post by Esteban A. Maringolo
- 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

[Goubier Thierry]

Post by Goubier Thierry

Post by Esteban A. Maringolo
- 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...

And once you're in there, you can refine by cascading scopes.

In package X, along hierarchy of class Y, find all methods with name
containing visit, rename #visitRootNode: as #acceptRootNode:

Can also be combined with RB pattern matching for searching in code, but
I'd like to see the GUI for that last one :) Who was said to be working
on that?

Thierry

[Tudor Girba]

I do :)

Doru


On Mon, Jun 16, 2014 at 4:35 PM, Goubier Thierry <thierry.goubier at cea.fr>

Post by Goubier Thierry

Post by Goubier Thierry

Post by Esteban A. Maringolo
- 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...

And once you're in there, you can refine by cascading scopes.
In package X, along hierarchy of class Y, find all methods with name
Can also be combined with RB pattern matching for searching in code, but
I'd like to see the GUI for that last one :) Who was said to be working on
that?
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Syst?mes Temps R?el Embarqu?s
91191 Gif sur Yvette Cedex
France
Phone/Fax: [phone] / 83 95

[Clément Bera]

Post by Esteban A. Maringolo
- 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

Post by Esteban A. Maringolo
Esteban A. Maringolo

Post by Serge Stinckwich
and copy-paste that in playground and CTRL-O will open the Browser ;-)

Post by stepharo
Soon soon :)
but in this form
MyClass>>myMethod
[
^ 1 + 3
]
;)

Post by Ben Coman
MyClass>>myMethod "in accessors"
^ 1 + 3
The current System Browser my also be switched to that method at the

same

Post by Serge Stinckwich

Post by stepharo

Post by Ben Coman
time, or a new System Browser opened if this is entered from

Workspace. I

Post by Serge Stinckwich

Post by stepharo

Post by Ben Coman
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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140616/f9f5461e/attachment.html>