Fwd: Squeak 5 on Raspberry Pi
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable. The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo. The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM. The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see. 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 25 Mar 2016, at 07:43, Clément Bera <bera.clement@gmail.com> wrote:
Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable.
The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo.
The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM.
The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see.
yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. For example, months ago I got pissed because our current list implementation was not fast enough for our tools and thatâs why I made FastTable: because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. As lists, some others widgets (notably tree) could be optimised⦠But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyable⦠but for example, the new debugger (which Iâm not criticising as a tool, I like it a lot) makes me hurt⦠is slower than eclipse debugger and thatâs a lot to say. Also new inspector: is good, but canât we optimise it? maybe we need to make some concession, but is the moment of doing it. Recently Iâm noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but Iâm not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless). Mea culpa: more than once I have not protested even knowing than solution X was â10% slower than the older one, but thatâs ok, we can live with itâ⦠guess what? once you accumulate enough of those 10% penalties, you have a barely usable system. We need to concentrate efforts on performance. There will not be magical solution: if we do not spend time on enhance tools for performance, they will be not good enough. Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for it in FogBugz). Esteban
2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>:
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html <http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 25 Mar 2016, at 09:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:
had improve and not using it is almost enjoyableâ¦
I meant â.. had improve and NOW using it is almost enjoyableâ⦠Freud could say a lot of things about that lapsus :P
You made my day. It is true the Pharo feels slow, even of a powerful machine [Core i7 @ 4.4Ghz] (e.g. vs Visual Studio, PhpStorm, ... which aren't little beasts). It is particularly frustrating when having to work with BIG FONTS like I do and inside a Linux VM. Squeak is indeed super zippy by comparison. That's frustrating. Phil On Fri, Mar 25, 2016 at 10:04 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 25 Mar 2016, at 09:45, Esteban Lorenzano <estebanlm@gmail.com> wrote:
had improve and not using it is almost enjoyableâ¦
I meant â.. had improve and NOW using it is almost enjoyableâ⦠Freud could say a lot of things about that lapsus :P
2016-03-25 9:45 GMT+01:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 25 Mar 2016, at 07:43, Clément Bera <bera.clement@gmail.com> wrote:
Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable.
The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo.
The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM.
The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see.
yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. For example, months ago I got pissed because our current list implementation was not fast enough for our tools and thatâs why I made FastTable:
But isn't the old list implementation (mostly) the same that is used in squeak (and feels faster there?) ?
because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. As lists, some others widgets (notably tree) could be optimised⦠But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyable⦠but for example, the new debugger (which Iâm not criticising as a tool, I like it a lot) makes me hurt⦠is slower than eclipse debugger and thatâs a lot to say. Also new inspector: is good, but canât we optimise it? maybe we need to make some concession, but is the moment of doing it. Recently Iâm noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but Iâm not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless).
Mea culpa: more than once I have not protested even knowing than solution X was â10% slower than the older one, but thatâs ok, we can live with itâ⦠guess what? once you accumulate enough of those 10% penalties, you have a barely usable system.
We need to concentrate efforts on performance. There will not be magical solution: if we do not spend time on enhance tools for performance, they will be not good enough.
Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for it in FogBugz).
Esteban
2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com>.
On 25 Mar 2016, at 11:50, Nicolai Hess <nicolaihess@gmail.com> wrote:
But isn't the old list implementation (mostly) the same that is used in squeak (and feels faster there?) ?
yes, but we use it very differently :) we add tons and tons of functionality on top of it, so we made, Nautilus for example, slower. Is not a problem of the list: is that we are/were using it differently, and in a very different way of his first intention (take a pluggable list, add 1k strings: works⦠add 1k icons⦠works worst, but works⦠add 1k buttons instead those icons⦠and suffer⦠:P). Esteban
Hi,
On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 25 Mar 2016, at 07:43, Clément Bera <bera.clement@gmail.com> wrote:
Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable.
The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo.
The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM.
The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see.
yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. For example, months ago I got pissed because our current list implementation was not fast enough for our tools and thatâs why I made FastTable: because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. As lists, some others widgets (notably tree) could be optimised⦠But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyable⦠but for example, the new debugger (which Iâm not criticising as a tool, I like it a lot) makes me hurt⦠is slower than eclipse debugger and thatâs a lot to say.
That is a good one :). There is an open issue with the blinking problem when you accept code which makes it appear slower than it actually is, but we are stuck with it and we could benefit from help.
Also new inspector: is good, but canât we optimise it? maybe we need to make some concession, but is the moment of doing it.
The optimization we should do now is to replace the appearances of MorphTreeMorph with FastTable. This would imply that the Raw presentation would not longer have a tree (because it is not supported in FastTable). I would be very happy if we could do that. Do we agree on this?
Recently Iâm noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but Iâm not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless).
Could you be more specific about the Spotter problem that you see? Also, in the last couple of days Alex Syrel improved the speed of Spotter significantly. It is not yet integrated. It would be useful to get feedback on this because maybe we missed something.
Mea culpa: more than once I have not protested even knowing than solution X was â10% slower than the older one, but thatâs ok, we can live with itâ⦠guess what? once you accumulate enough of those 10% penalties, you have a barely usable system.
We need to concentrate efforts on performance. There will not be magical solution: if we do not spend time on enhance tools for performance, they will be not good enough.
Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for it in FogBugz).
It would indeed be useful to get more eyes spent on this. Cheers, Doru
Esteban
2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."
2016-03-25 12:52 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 25 Mar 2016, at 07:43, Clément Bera <bera.clement@gmail.com> wrote:
Yeah this is very well-known. Note that here we are talking about the
pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable.
The Pharo UI has been focusing on IDE features at the cost of
performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo.
The Squeak UI has been focusing on performance and stability. It is
very convenient for slow devices but also for slow VM like for example the debug VM.
The official answer to this problem is that Block/Brick will be faster
so it will solve all this problems. We will see.
yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. For example, months ago I got pissed because our current list implementation was not fast enough for our tools and thatâs why I made FastTable: because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. As lists, some others widgets (notably tree) could be optimised⦠But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyable⦠but for example, the new debugger (which Iâm not criticising as a tool, I like it a lot) makes me hurt⦠is slower than eclipse debugger and thatâs a lot to say.
That is a good one :). There is an open issue with the blinking problem when you accept code which makes it appear slower than it actually is, but we are stuck with it and we could benefit from help.
"appear slower than it actually is" Really? Aliaksei comment was: "Each code accept triggers a lot of glamour inner stuff and in the end refreshes the almost whole debugger interface. (Panes, Tabulator, LazyTable and so on)" So, is it slow, or does it just look slow?
Also new inspector: is good, but canât we optimise it? maybe we need to make some concession, but is the moment of doing it.
The optimization we should do now is to replace the appearances of MorphTreeMorph with FastTable. This would imply that the Raw presentation would not longer have a tree (because it is not supported in FastTable). I would be very happy if we could do that. Do we agree on this?
Recently Iâm noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but Iâm not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless).
Could you be more specific about the Spotter problem that you see?
Also, in the last couple of days Alex Syrel improved the speed of Spotter significantly. It is not yet integrated. It would be useful to get feedback on this because maybe we missed something.
Mea culpa: more than once I have not protested even knowing than solution X was â10% slower than the older one, but thatâs ok, we can live with itâ⦠guess what? once you accumulate enough of those 10% penalties, you have a barely usable system.
We need to concentrate efforts on performance. There will not be magical solution: if we do not spend time on enhance tools for performance, they will be not good enough.
Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for it in FogBugz).
It would indeed be useful to get more eyes spent on this.
Cheers, Doru
Esteban
2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context:
http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
Hi,
On 25 Mar 2016, at 12:52, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 25 Mar 2016, at 07:43, Clément Bera <bera.clement@gmail.com> wrote:
Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable.
The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo.
The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM.
The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see.
yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. For example, months ago I got pissed because our current list implementation was not fast enough for our tools and thatâs why I made FastTable: because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. As lists, some others widgets (notably tree) could be optimised⦠But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyable⦠but for example, the new debugger (which Iâm not criticising as a tool, I like it a lot) makes me hurt⦠is slower than eclipse debugger and thatâs a lot to say.
That is a good one :). There is an open issue with the blinking problem when you accept code which makes it appear slower than it actually is, but we are stuck with it and we could benefit from help.
Also new inspector: is good, but canât we optimise it? maybe we need to make some concession, but is the moment of doing it.
The optimization we should do now is to replace the appearances of MorphTreeMorph with FastTable. This would imply that the Raw presentation would not longer have a tree (because it is not supported in FastTable). I would be very happy if we could do that. Do we agree on this?
actually there is a tree implementation based on fast table, but Iâm not sure is production ready (Cyril can say something about). But anyway since I never understood why we have a tree there (since we will âopenâ attribute in next panel), I do agree, strongly :)
Recently Iâm noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but Iâm not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless).
Could you be more specific about the Spotter problem that you see?
not sure, I open and it takes some seconds to actually show anything. I thought it was caused because of the catalog refresh to populate projects, but Iâm not sure. In any case, load catalog projects in spotter is cool, but we need to find a better implementation. One that does not freezes spotter until it refresh (remember, Pharo is also used in places with crapy connection or not connection at all).
Also, in the last couple of days Alex Syrel improved the speed of Spotter significantly. It is not yet integrated. It would be useful to get feedback on this because maybe we missed something.
Mea culpa: more than once I have not protested even knowing than solution X was â10% slower than the older one, but thatâs ok, we can live with itâ⦠guess what? once you accumulate enough of those 10% penalties, you have a barely usable system.
We need to concentrate efforts on performance. There will not be magical solution: if we do not spend time on enhance tools for performance, they will be not good enough.
Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for it in FogBugz).
It would indeed be useful to get more eyes spent on this.
yes! if you want to suffer, do this experiment: 1. open a Pharo2 and open debugger on anything 2. then Pharo3, 4 and 5⦠feel the incremental slowdown 3. cry :â( Esteban
Cheers, Doru
Esteban
2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Not knowing how to do something is not an argument for how it cannot be done."
well so far for me at least pharo 5 works ok perfomance wise on my quad core imac and my dual core macbook air. The only serious slow down I have is when loading images but I suspect this code is forked from Squeak anyway. System Browser was indeed a big issue with large classes but after FastTable it works fine. Overall I am very happy with Pharo. But I also avoid heavy computation with pharo. I am in favor of optimization coming later on development cycle. Like all things we need to grow a community of interested pharo developers that will us Pi not just as a toy but a useful device , the more we have the more likely is that someone will step in front of others to fix some of those issues. Personally I have a Pi which I bought mostly to support the project , I never found a reason to use it. I am actually on the opposite side of hi-tech graphics which also Pharo does not support at all. So I step in and bring that support to Pharo because I need it and because I love Pharo. Problems dont magically solve themselves, we need more contributors. On Fri, Mar 25, 2016 at 2:33 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
On 25 Mar 2016, at 12:52, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 25 Mar 2016, at 07:43, Clément Bera <bera.clement@gmail.com> wrote:
Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable.
The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo.
The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM.
The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see.
yes, this is the âsemi-officialâ answer and thatâs an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. For example, months ago I got pissed because our current list implementation was not fast enough for our tools and thatâs why I made FastTable: because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. As lists, some others widgets (notably tree) could be optimised⦠But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyable⦠but for example, the new debugger (which Iâm not criticising as a tool, I like it a lot) makes me hurt⦠is slower than eclipse debugger and thatâs a lot to say.
That is a good one :). There is an open issue with the blinking problem when you accept code which makes it appear slower than it actually is, but we are stuck with it and we could benefit from help.
Also new inspector: is good, but canât we optimise it? maybe we need to make some concession, but is the moment of doing it.
The optimization we should do now is to replace the appearances of MorphTreeMorph with FastTable. This would imply that the Raw presentation would not longer have a tree (because it is not supported in FastTable). I would be very happy if we could do that. Do we agree on this?
actually there is a tree implementation based on fast table, but Iâm not sure is production ready (Cyril can say something about). But anyway since I never understood why we have a tree there (since we will âopenâ attribute in next panel), I do agree, strongly :)
Recently Iâm noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but Iâm not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless).
Could you be more specific about the Spotter problem that you see?
not sure, I open and it takes some seconds to actually show anything. I thought it was caused because of the catalog refresh to populate projects, but Iâm not sure. In any case, load catalog projects in spotter is cool, but we need to find a better implementation. One that does not freezes spotter until it refresh (remember, Pharo is also used in places with crapy connection or not connection at all).
Also, in the last couple of days Alex Syrel improved the speed of Spotter significantly. It is not yet integrated. It would be useful to get feedback on this because maybe we missed something.
Mea culpa: more than once I have not protested even knowing than solution X was â10% slower than the older one, but thatâs ok, we can live with itâ⦠guess what? once you accumulate enough of those 10% penalties, you have a barely usable system.
We need to concentrate efforts on performance. There will not be magical solution: if we do not spend time on enhance tools for performance, they will be not good enough.
Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, âFirst impressions countsâ! (we even have a category for it in FogBugz).
It would indeed be useful to get more eyes spent on this.
yes!
if you want to suffer, do this experiment: 1. open a Pharo2 and open debugger on anything 2. then Pharo3, 4 and 5⦠feel the incremental slowdown 3. cry :â(
Esteban
Cheers, Doru
Esteban
2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com>.
-- www.tudorgirba.com www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
Le 25/03/2016 13:31, Esteban Lorenzano a écrit :
Hi,
actually there is a tree implementation based on fast table, but Iâm not sure is production ready (Cyril can say something about). But anyway since I never understood why we have a tree there (since we will âopenâ attribute in next panel), I do agree, strongly :)
Hi, There is a working FTTree with examples and doc in Pharo 5 and there is a Glamour adaptor as for FastTable (With examples in GLMExampleBrowser). Since it is not use for now they might be some bugs. I think that the code would benefits some review from experienced people since I am still far from being as good as most of the developers here :) For example some things I do not like: - Since I warped data into Items object I had to add a "realElementAt:" method in the dataSource. This is not wanted in my opinion but I don't know how to remove it and I don't have the time to work on it anymore. - Some features cause infinite loop if the number of children is infinite (for example, search in all the items). I wrote it in the documentation when that might happen but maybe we can reduce the number of feature that can provoke that? - I think that the search/filtering time can be improve when we have to check in the complete tree. I would like that experienced people check the code before we really use it because if there is some change in the design to do, we should do it now.
not sure, I open and it takes some seconds to actually show anything. I thought it was caused because of the catalog refresh to populate projects, but Iâm not sure. In any case, load catalog projects in spotter is cool, but we need to find a better implementation. One that does not freezes spotter until it refresh (remember, Pharo is also used in places with crapy connection or not connection at all).
yes!
if you want to suffer, do this experiment: 1. open a Pharo2 and open debugger on anything 2. then Pharo3, 4 and 5⦠feel the incremental slowdown 3. cry :â(
Esteban
-- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
Hi,
On Mar 26, 2016, at 5:04 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 25/03/2016 13:31, Esteban Lorenzano a écrit :
Hi,
actually there is a tree implementation based on fast table, but Iâm not sure is production ready (Cyril can say something about). But anyway since I never understood why we have a tree there (since we will âopenâ attribute in next panel), I do agree, strongly :)
Hi,
There is a working FTTree with examples and doc in Pharo 5 and there is a Glamour adaptor as for FastTable (With examples in GLMExampleBrowser). Since it is not use for now they might be some bugs. I think that the code would benefits some review from experienced people since I am still far from being as good as most of the developers here :) For example some things I do not like: - Since I warped data into Items object I had to add a "realElementAt:" method in the dataSource. This is not wanted in my opinion but I don't know how to remove it and I don't have the time to work on it anymore. - Some features cause infinite loop if the number of children is infinite (for example, search in all the items). I wrote it in the documentation when that might happen but maybe we can reduce the number of feature that can provoke that? - I think that the search/filtering time can be improve when we have to check in the complete tree.
I would like that experienced people check the code before we really use it because if there is some change in the design to do, we should do it now.
As far as I saw, this is just a tree, not a tree with table (like the one used in the Raw presentation). Am I wrong? Cheers, Doru
not sure, I open and it takes some seconds to actually show anything. I thought it was caused because of the catalog refresh to populate projects, but Iâm not sure. In any case, load catalog projects in spotter is cool, but we need to find a better implementation. One that does not freezes spotter until it refresh (remember, Pharo is also used in places with crapy connection or not connection at all).
yes!
if you want to suffer, do this experiment: 1. open a Pharo2 and open debugger on anything 2. then Pharo3, 4 and 5⦠feel the incremental slowdown 3. cry :â(
Esteban
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
-- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."
2016-03-25 7:43 GMT+01:00 Clément Bera <bera.clement@gmail.com>:
Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable.
The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo.
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints?
The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM.
The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see.
2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
[Squeak 5 is] so *fast* (I have it running next to Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping along at Windows desktop speeds on the Pi (Model B).
----- Cheers, Sean -- View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object. So some sometime what look like a cool stuff (decoupled objects) is just a drag. Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid. Hilaire Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
2016-03-25 18:30 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Agreed.
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks? I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set. If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph. We should clean Versionner- I have the impression that half of the classes are not mandatory. Stef
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit : > On 25-03-16 11:49, Nicolai Hess wrote: >> Morphic drasticallly slower ? I would expect morphic code is mostly >> the same in pharo and squeak. If pharo is slower, this is a good >> starting point for optimising. Can you gives some hints? > I do not have the impression that morphic is so much slower. > We had/have a problem of too many announcements being send and > too many redraws happening. > > Stephan > >
-- Dr. Geo http://drgeo.eu
2016-03-25 22:27 GMT+01:00 stepharo <stepharo@free.fr>:
So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
I want a clean and stable core. The way Rubric and GT-Tools were pushed into the core was a mess. Rubric is a big bad bunch of badly documented code with lots of copy-paste garbage - we should do better. And since it was included I hear it was abandoned by alain and TxText is the next. I see up to no development for TxText. The same for Athens, bugs or requests for conclusins I entered in FogBugz are, or will be closed (timout) because no one cares. Instead Athens is used as it is or change by others just for its own projects (roassal, Bloc, Brick).
I personnally want to have new widgets, a real UI builder and massively cleaning Spec.
me too, but what is the purpose of spec, if we replace all tools based on spec (debugger/inspector/...) with GT-Tools?
Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
If you want to clean Pharo
I fix bugs, there are many bugs.
you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
Our tools are in a much more worse state than in Pharo 4, not clean, not stable. We are in code freeze since 6 weeks, and there are still many new changes instead of only bug fixes.
Stef
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
I want a clean and stable core.
me too. Now you will not my core. Because there is no UI no announcement...
The way Rubric and GT-Tools were pushed into the core was a mess.
No I cannot let you to say that. I'm sorry. We spent 4 months cleaning Nautilus and Rubric is not optimal but we decided that forcing to adapt to Rubric was a good move for the next one. We did it to help - breakpoints - QA feedback Rubric was pushed in Pharo over the summer. So if we cannot change something as important that that more than 8 months before the release then we should better stop to do pharo. Because for Rubric ***I*** planned it in advance with a stabilisation phase. Now Pharo 50 got far too many new features We should have not include Spur and release Pharo 50 without it and keep new FFI and Spur for Pharo 60 and keep GTTools for Pharo 60 If this is your analysis then we are ok. Now you cannot tell me that pushing rubric was a mess. The state of the system (in particular the lack of good widgets) is a problem. Look at the keybindings why the keybinding is still the mess: simply because all the widgets and tools just nicely harcoded them. It does not mean that we should not fix them but you cannot fight day long against spur migration bugs fight day long against FFI glitches fix integration bugs of GT and get more steam for the rest Now let me tell you frankly I prefer to build useless mini new languages than fighting with ugly widgets so why did I supervised and worked with a guy to improve and push rubric? Because it was needed.
Rubric is a big bad bunch of badly documented code indeed it is badly documented. Now it has examples. Now synectique and moose have been using in their product rubric. with lots of copy-paste garbage - we should do better. And since it was included I hear it was abandoned by alain No alain helped each time we asked him but he has severe family problems (the kind of problems that you do not want to have but you have to face). and TxText is the next. What can we say? I have no idea why igor disappeared and kind of divorced. Now the design of TxText is nice and we will have to invest. Bricks already used it and people looking at it mentioned that it is good. So the objectives is to drop rubric (because it is a hack and we know it but a hack which supports embellisment and icons) and use TxText. I see up to no development for TxText. The same for Athens, bugs or requests for conclusins I entered in FogBugz are, or will be closed (timout) because no one cares. But you see you are becoming the most aware for athens and what we should do is document document. Now I got ****EXHAUSTED**** to document things that I did not build or use daily. This effort for me is gigantic and I cannot do it each time. Instead Athens is used as it is or change by others just for its own projects (roassal, Bloc, Brick). Do you think that roassal is extended privately Athens. I would be surprised. I know that we all like what you did with the widgets because blocers can work in athens with default widgets and our goal is to throw all the morphic layer away and only use Athens.
Now we should give feedback to blocers
I personnally want to have new widgets, a real UI builder and massively cleaning Spec.
me too, but what is the purpose of spec, if we replace all tools based on spec (debugger/inspector/...) with GT-Tools?
We need a UI Builder and spec is a way to build widgets. Now before we get the perfect solution we need to make sure that we clean it. I would like to do that with Peter. But again there is no magic: some part of spec are ugly because of design but others are ugly because the widgets are poor. Now for me I have no problem cleaning Spec even if at the end we replace it by something else. We did that for the compiler, we are doing it for Morphic, ....
Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
If you want to clean Pharo
I fix bugs, there are many bugs.
I know nicolai and I understand your frustration and I understand it:) I thank you everyday for that. I think that we should remove things from Pharo So the most important point for us is to get in place a process so that we can avoid to get monolithic again For example we need a process to have the possibility to remove project from the image and still build and modify an image with them. It will not change the problem that when a bug is there we have a bug but it should lower the stress.
you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
Our tools are in a much more worse state than in Pharo 4, not clean, not stable.
Where? Nautilus is much better to me. I used Versionner and it is working. CodeCritics I got some glitches with refactorings Do you have some issues?
We are in code freeze since 6 weeks, and there are still many new changes instead of only bug fixes. I thought that it was not the case and I do not think so. So this is side effect of the cleaning of foundations. The problems is that we cannot block people working on the bootstrap forever.
So nicolai what I would do is a roadmap for Pharo 60 - there will be no Spur and FFI :) - so it will be consolidation - I would like to have release every six months (but it should be discussed) - for me I would like to have - cleaning Spec - cleaning another time nautilus - cleaning versionner - cleaning Komitter - Now we have epicea waiting - So Xtreams will be probably for later.
On Sat, Mar 26, 2016 at 9:19 AM, stepharo <stepharo@free.fr> wrote:
I want a clean and stable core.
me too. Now you will not my core. Because there is no UI no announcement...
The way Rubric and GT-Tools were pushed into the core was a mess.
No I cannot let you to say that. I'm sorry. We spent 4 months cleaning Nautilus and Rubric is not optimal but we decided that forcing to adapt to Rubric was a good move for the next one. We did it to help - breakpoints - QA feedback
Rubric was pushed in Pharo over the summer. So if we cannot change something as important that that more than 8 months before the release then we should better stop to do pharo. Because for Rubric ***I*** planned it in advance with a stabilisation phase. Now Pharo 50 got far too many new features
We should have not include Spur and release Pharo 50 without it and keep new FFI and Spur for Pharo 60 and keep GTTools for Pharo 60
If this is your analysis then we are ok. Now you cannot tell me that pushing rubric was a mess. The state of the system (in particular the lack of good widgets) is a problem. Look at the keybindings why the keybinding is still the mess: simply because all the widgets and tools just nicely harcoded them. It does not mean that we should not fix them but you cannot fight day long against spur migration bugs fight day long against FFI glitches fix integration bugs of GT and get more steam for the rest
Now let me tell you frankly I prefer to build useless mini new languages than fighting with ugly widgets so why did I supervised and worked with a guy to improve and push rubric? Because it was needed.
Rubric is a big bad bunch of badly documented code
indeed it is badly documented. Now it has examples. Now synectique and moose have been using in their product rubric.
with lots of copy-paste garbage - we should do better. And since it was included I hear it was abandoned by alain
No alain helped each time we asked him but he has severe family problems (the kind of problems that you do not want to have but you have to face).
and TxText is the next.
What can we say? I have no idea why igor disappeared and kind of divorced. Now the design of TxText is nice and we will have to invest. Bricks already used it and people looking at it mentioned that it is good. So the objectives is to drop rubric (because it is a hack and we know it but a hack which supports embellisment and icons) and use TxText.
I see up to no development for TxText. The same for Athens, bugs or requests for conclusins I entered in FogBugz are, or will be closed (timout) because no one cares.
But you see you are becoming the most aware for athens and what we should do is document document. Now I got ****EXHAUSTED**** to document things that I did not build or use daily. This effort for me is gigantic and I cannot do it each time.
Instead Athens is used as it is or change by others just for its own projects (roassal, Bloc, Brick).
Do you think that roassal is extended privately Athens. I would be surprised. I know that we all like what you did with the widgets because blocers can work in athens with default widgets and our goal is to throw all the morphic layer away and only use Athens.
Now we should give feedback to blocers
I personnally want to have new widgets, a real UI builder and massively cleaning Spec.
me too, but what is the purpose of spec, if we replace all tools based on spec (debugger/inspector/...) with GT-Tools?
We need a UI Builder and spec is a way to build widgets. Now before we get the perfect solution we need to make sure that we clean it. I would like to do that with Peter. But again there is no magic: some part of spec are ugly because of design but others are ugly because the widgets are poor.
Now for me I have no problem cleaning Spec even if at the end we replace it by something else. We did that for the compiler, we are doing it for Morphic, ....
Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
If you want to clean Pharo
I fix bugs, there are many bugs.
I know nicolai and I understand your frustration and I understand it:) I thank you everyday for that. I think that we should remove things from Pharo So the most important point for us is to get in place a process so that we can avoid to get monolithic again For example we need a process to have the possibility to remove project from the image and still build and modify an image with them. It will not change the problem that when a bug is there we have a bug but it should lower the stress.
you can start cleaning Komitter stupid use of state pattern generating
a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
Our tools are in a much more worse state than in Pharo 4, not clean, not stable.
Where? Nautilus is much better to me. I used Versionner and it is working. CodeCritics
I got some glitches with refactorings
Do you have some issues?
We are in code freeze since 6 weeks, and there are still many new changes instead of only bug fixes.
I thought that it was not the case and I do not think so. So this is side effect of the cleaning of foundations. The problems is that we cannot block people working on the bootstrap forever.
So nicolai what I would do is a roadmap for Pharo 60 - there will be no Spur and FFI :) - so it will be consolidation - I would like to have release every six months (but it should be discussed) - for me I would like to have - cleaning Spec - cleaning another time nautilus - cleaning versionner - cleaning Komitter - Now we have epicea waiting - So Xtreams will be probably for later.
This is just too much indeed. But we are learning a lot by doing this. Phil
Le 26/03/2016 09:19, stepharo a écrit :
But you see you are becoming the most aware for athens and what we should do is document document. Now I got ****EXHAUSTED**** to document things that I did not build or use daily. This effort for me is gigantic and I cannot do it each time.
In my opinion Pharo should refuse to include any class without at least a one line documentation for the small classes. And when someone review a bug correction and see that an important class have a really small documentation it should be a stop for the integration. I never saw a Java class without documentation on oracle site. This will slow down the integration of some project, but since everyone agree that pharo included too many project, this should not be a problem. At least we would integrate only projects understandable by the others. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
Good luck with things like Roassal or Seaside. As of Java, sure, but Javadoc is only a small part. Try to understand Swing with Javadocs and no thick book, good luck with that. The Java Tutorial is another matter. Phil This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, Mar 26, 2016 at 3:50 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com
wrote:
Le 26/03/2016 09:19, stepharo a écrit :
But you see you are becoming the most aware for athens and what we should do is document document. Now I got ****EXHAUSTED**** to document things that I did not build or use daily. This effort for me is gigantic and I cannot do it each time.
In my opinion Pharo should refuse to include any class without at least a one line documentation for the small classes. And when someone review a bug correction and see that an important class have a really small documentation it should be a stop for the integration.
I never saw a Java class without documentation on oracle site.
This will slow down the integration of some project, but since everyone agree that pharo included too many project, this should not be a problem. At least we would integrate only projects understandable by the others.
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Le 26/3/16 15:50, Cyril Ferlicot D. a écrit :
Le 26/03/2016 09:19, stepharo a écrit :
But you see you are becoming the most aware for athens and what we should do is document document. Now I got ****EXHAUSTED**** to document things that I did not build or use daily. This effort for me is gigantic and I cannot do it each time. In my opinion Pharo should refuse to include any class without at least a one line documentation for the small classes. And when someone review a bug correction and see that an important class have a really small documentation it should be a stop for the integration.
I never saw a Java class without documentation on oracle site. :) at least you made my day comparing pharo with oracle I felt proud :)
This will slow down the integration of some project, but since everyone agree that pharo included too many project, this should not be a problem. At least we would integrate only projects understandable by the others.
Hi Stef, On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo@free.fr> wrote:
So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
yes, of course :-)
I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
+1
If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases". I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them. The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge. Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest? Stef
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
-- _,,,^..^,,,_ best, Eliot
2016-03-25 19:32 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Stef,
On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo@free.fr> wrote:
So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
yes, of course :-)
I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
+1
If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases".
I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them.
The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge.
Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest?
In my opinion, that sounds like a very good and more serious approach for the whole community. The only problem I see is an explosion of Pharo flavors like happened in Squeak years ago, because many people want promotion of their own image (which is ok but also reflects lack of consensus), but is better than having new core projects with developers abandoning before time or obscure decisions imposing a new debugger without ANY poll. Now I don't want to waste time on definitions of "solid", but I can tell you Pharo now feels slow. About having to ask "spend some time optimising tools" just a few weeks before a release... Sorry guys I know you work a lot on making good quality stuff, but seems like the current way of integrating tools **is NOT working**. Where is the policy for integrating packages and tools into the core? Where are the priorities? Why they are priorities? How many votes gets each? Want more contributors? Start with clean visible rules and listen to users. We all want UFFI, Xtreams, mini-image, new UI frameworks & builder, etc. but not at any cost. Hernán
I totally do not agree with many of the arguments in this thread. But I do not want to discuss them under this label. Please start a new thread, if you want to.
On 26 Mar 2016, at 05:40, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
2016-03-25 19:32 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>: Hi Stef,
On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo@free.fr> wrote: So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
yes, of course :-)
I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
+1
If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases".
I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them.
The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge.
Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest?
In my opinion, that sounds like a very good and more serious approach for the whole community. The only problem I see is an explosion of Pharo flavors like happened in Squeak years ago, because many people want promotion of their own image (which is ok but also reflects lack of consensus), but is better than having new core projects with developers abandoning before time or obscure decisions imposing a new debugger without ANY poll.
Now I don't want to waste time on definitions of "solid", but I can tell you Pharo now feels slow.
About having to ask "spend some time optimising tools" just a few weeks before a release... Sorry guys I know you work a lot on making good quality stuff, but seems like the current way of integrating tools **is NOT working**.
Where is the policy for integrating packages and tools into the core? Where are the priorities? Why they are priorities? How many votes gets each?
Want more contributors? Start with clean visible rules and listen to users.
We all want UFFI, Xtreams, mini-image, new UI frameworks & builder, etc. but not at any cost.
Hernán
In Tiki, our versioning policy is like this: https://tiki.org/Versions Going on nicely since 2009. Phil This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Mar 25, 2016 at 11:32 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Stef,
On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo@free.fr> wrote:
So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
yes, of course :-)
I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
+1
If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases".
I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them.
The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge.
Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest?
Stef
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
-- _,,,^..^,,,_ best, Eliot
Hi Phil, _,,,^..^,,,_ (phone)
On Mar 26, 2016, at 3:07 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
In Tiki, our versioning policy is like this:
Hmmph! :-). Tiki's "About" page is one of those maddeningly useless ones that speaks to the choir. It should start with a "Tiki is a ..." paragraph that explains what tiki is to those that have never heard of it before. Instead it gushes on for ages declaring "we have history", "we eat dog food", "we have a huge install base" but I still have /no idea/ what tiki is as a black box or a white box. Grrrr ;-)
Going on nicely since 2009.
Phil
This email has been sent from a virus-free computer protected by Avast. www.avast.com
On Fri, Mar 25, 2016 at 11:32 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote: Hi Stef,
On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo@free.fr> wrote: So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
yes, of course :-)
I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
+1
If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases".
I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them.
The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge.
Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest?
Stef
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
-- _,,,^..^,,,_ best, Eliot
My point was about the Versioning approach. Tiki is about all kinds of things. That's what you get with millions of lines of PHP code and, indeed, millions of downloads etc. It is a community building tool. Check https://tiki.org/Features and mix and match them as most things can be combined orthogonally (like security meet calendar, or trackers meet articles). That's a hell of a powerful tool I can tell you. I used it to support several businesses and it rocks. Like Squeak and Pharo, it may lead to some "what's this thing?" impressions. Phil On Sat, Mar 26, 2016 at 3:59 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Phil,
_,,,^..^,,,_ (phone) On Mar 26, 2016, at 3:07 AM, "phil@highoctane.be" <phil@highoctane.be> wrote:
In Tiki, our versioning policy is like this:
Hmmph! :-). Tiki's "About" page is one of those maddeningly useless ones that speaks to the choir. It should start with a "Tiki is a ..." paragraph that explains what tiki is to those that have never heard of it before. Instead it gushes on for ages declaring "we have history", "we eat dog food", "we have a huge install base" but I still have /no idea/ what tiki is as a black box or a white box. Grrrr ;-)
Going on nicely since 2009.
Phil
This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#m_-5685355456190387811_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Mar 25, 2016 at 11:32 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Stef,
On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo@free.fr> wrote:
So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
yes, of course :-)
I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
+1
If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases".
I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them.
The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge.
Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest?
Stef
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
-- _,,,^..^,,,_ best, Eliot
Yes, I want all of the good stuff. Let's always remember that when the platoon soldiers stop complaining, it is time to watch your back for a knife. Looks like we are a long way from there. Phil This email has been sent from a virus-free computer protected by Avast. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaig...> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Mar 25, 2016 at 10:27 PM, stepharo <stepharo@free.fr> wrote:
So guys, you do not want Xtreams (and prefer to use Streams that have been "designed" decades ago) ;D ? no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks?
I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set.
If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph.
We should clean Versionner- I have the impression that half of the classes are not mandatory.
Stef
2016-03-25 18:18 GMT+01:00 Hilaire <hilaire@drgeo.eu>:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
+1
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
yes! Maybe a solid core with a layer of fast evolving things. That's the model for Hortonworks now. A stable Hadoop core for stability and fast updates for things like Spark. Phil On Mar 25, 2016 6:19 PM, "Hilaire" <hilaire@drgeo.eu> wrote:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit :
On 25-03-16 11:49, Nicolai Hess wrote:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening.
Stephan
-- Dr. Geo http://drgeo.eu
But pharo is solid. When is the last time we changed FFI and GC and new object representations? You see FFI is really really important not having one = no Pharo. So yes Pharo is doing too much stuff and we should have sprint to clean and optimise but FFI and Spur are important. Stef Le 25/3/16 20:37, philippe.back@highoctane.be a écrit :
yes!
Maybe a solid core with a layer of fast evolving things.
That's the model for Hortonworks now. A stable Hadoop core for stability and fast updates for things like Spark.
Phil
On Mar 25, 2016 6:19 PM, "Hilaire" <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>> wrote:
Not exactly related to Announcement, but I remember when I first port DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object.
So some sometime what look like a cool stuff (decoupled objects) is just a drag.
Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid.
Hilaire
Le 25/03/2016 12:33, Stephan Eggermont a écrit : > On 25-03-16 11:49, Nicolai Hess wrote: >> Morphic drasticallly slower ? I would expect morphic code is mostly >> the same in pharo and squeak. If pharo is slower, this is a good >> starting point for optimising. Can you gives some hints? > I do not have the impression that morphic is so much slower. > We had/have a problem of too many announcements being send and > too many redraws happening. > > Stephan > >
-- Dr. Geo http://drgeo.eu
participants (15)
-
Clément Bera -
Cyril Ferlicot D. -
Dimitris Chloupis -
Eliot Miranda -
Esteban Lorenzano -
Hernán Morales Durand -
Hilaire -
Nicolai Hess -
phil＠highoctane.be -
philippe.back＠highoctane.be -
Sean P. DeNigris -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Tudor Girba