Pharo: Git and GUI speed; JS widget reuse in PharoJS
Are we sure that Git is really the best way to go? Yes, it's everywhere, but its representation in Iceberg seems awkward or incomplete. I've been able to crash several Pharo VMs with routine repo operations. This is why I backed away recently from Pharo--that and the mush (see below). The other thing that keeps me planted firmly in VW is the sheer speed of it. Pharo looks generally much better, but it's mushy, and that's a problem. VW is not. Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms. I'm seeing 100, 150, and 200 ms regularly in Pharo. It's too mushy, and that slows the mind. Any developer understands this, whether he talks about it or not. So I'm wondering when the Pharo GUI will snap as well as VW. One thing that would help is to give the option of button-down selection in Settings, but even this is not enough. I tweaked the code, and made it so, but still was not happy: not enough snap and crackle. You may have acclimated and not noticed the problem, depending on how long you've been using Pharo. Otherwise, I like the Pharo DSL idea for JS. I'm working with VW's AppeX now. I'm not sure I like it, but that's mostly about finding JS to be one of the worst languages ever invented. However, the reuse and leverage is there, but at what cost in poor reading/thinking? I'm on the fence with AppeX, but will probably give it a chance. How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we don't want to read JS if we don't have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not. Shaping
Hi,
On 7 Oct 2019, at 05:12, Shaping <shaping@uurda.org> wrote:
Are we sure that Git is really the best way to go?
Yes we are. But not because of git itself, but because we want to adopt a solution like git and it's ecosystem as storage for our software.
Yes, itâs everywhere, but its representation in Iceberg seems awkward or incomplete.
How? This requires an explanation at least, isnât? Because remember, what seems awkward to you, may fit others perfectly.
Iâve been able to crash several Pharo VMs with routine repo operations.
First, in any case this talks worst about the VM (and us developing it) than about git in particular :) Second, where are the reports so we can look at them? And third, there are known problems about file names and PATH length in windows, that are not related to git problems but the usage of git unveils it (which was the problem on the recent thread).
This is why I backed away recently from Pharo--that and the mush (see below).
Your choice, but we would have love to know your problems before. Yes, probably that wouldnât have change anything, but at least we would have put in the radar your problems. In particular what you try to explain below.
The other thing that keeps me planted firmly in VW is the sheer speed of it. Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not. Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms. Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind. Any developer understands this, whether he talks about it or not. So Iâm wondering when the Pharo GUI will snap as well as VW. One thing that would help is to give the option of button-down selection in Settings, but even this is not enough. I tweaked the code, and made it so, but still was not happy: not enough snap and crackle. You may have acclimated and not noticed the problem, depending on how long youâve been using Pharo.
⦠because I do not understand what are you talking about :) The word âmushyâ does not says a lot to me (as I am not native English speaker, I may lost something obvious). you talk about speed on response of the Pharo UI or something else? If you talk about that, well⦠we canât do much to help you in the short term, but we are certainly working to improve that for Pharo 8 and 9, so stay tuned :)
Otherwise, I like the Pharo DSL idea for JS. Iâm working with VWâs AppeX now. Iâm not sure I like it, but thatâs mostly about finding JS to be one of the worst languages ever invented. However, the reuse and leverage is there, but at what cost in poor reading/thinking? Iâm on the fence with AppeX, but will probably give it a chance.
How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we donât want to read JS if we donât have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not.
Shaping
Cheers, Esteban
Yes, itâs everywhere, but its representation in Iceberg seems awkward or incomplete. How? This requires an explanation at least, isnât? Iâve not been able to link to a repo and use it for any length of time without a problem. Sometimes the problem is a VM crash. Because remember, what seems awkward to you, may fit others perfectly. Store seems to work better, even with its problems. Iâve been able to crash several Pharo VMs with routine repo operations. First, in any case this talks worst about the VM (and us developing it) than about git in particular :) Second, where are the reports so we can look at them? I reported in the main list, but did not give a reproducible test-case. Iâve not much time to work on it, but the PharoJS is more interesting to me now than the rest of Pharo in general. And third, there are known problems about file names and PATH length in windows, that are not related to git problems but the usage of git unveils it (which was the problem on the recent thread). Right, the string in the last walkback was under the limit. What was that about? Shall I dump the stack trace? This is why I backed away recently from Pharo--that and the mush (see below). Your choice, but we would have love to know your problems before. Yes, probably that wouldnât have change anything, but at least we would have put in the radar your problems. In particular what you try to explain below. The other thing that keeps me planted firmly in VW is the sheer speed of it. Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not. Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms. Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind. Any developer understands this, whether he talks about it or not. So Iâm wondering when the Pharo GUI will snap as well as VW. One thing that would help is to give the option of button-down selection in Settings, but even this is not enough. I tweaked the code, and made it so, but still was not happy: not enough snap and crackle. You may have acclimated and not noticed the problem, depending on how long youâve been using Pharo. ⦠because I do not understand what are you talking about :) The word âmushyâ does not says a lot to me (as I am not native English speaker, I may lost something obvious). you talk about speed on response of the Pharo UI or something else? Yes. If you talk about that, well⦠we canât do much to help you in the short term, but we are certainly working to improve that for Pharo 8 and 9, so stay tuned :) Mushy == slow == high latencies following mostly mouse clicks. I think thatâs even a bigger problem for me than Iceberg, which can probably be fixed more easily.
Are we sure that Git is really the best way to go? Yes, itâs everywhere, but its representation in Iceberg seems awkward or incomplete. Iâve been able to crash several Pharo VMs with routine repo operations. This is why I backed away recently from Pharo--that and the mush (see below).
I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff. I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms. Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind. Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else. But VW event model is not better than Pharo's, so it might be something else. Regards, Esteban A. Maringolo
On 7 Oct 2019, at 11:55, Esteban Maringolo <emaringolo@gmail.com> wrote:
Are we sure that Git is really the best way to go? Yes, itâs everywhere, but its representation in Iceberg seems awkward or incomplete. Iâve been able to crash several Pharo VMs with routine repo operations. This is why I backed away recently from Pharo--that and the mush (see below).
I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing.
He is talking about the UI: While the VM is pretty fast, the first approach to it is our UI, and yes, it is slower (then some people may think the VM is slower, which is not the case).
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.
I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms. Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind. Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else.
Morphic + Glamour sometimes + bad UI/algorithms design put us in a bad place concerning UI speed. We are working to fix it, but this is not straightforward. Esteban
But VW event model is not better than Pharo's, so it might be something else.
Regards,
Esteban A. Maringolo
On Mon, Oct 7, 2019 at 12:07 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 7 Oct 2019, at 11:55, Esteban Maringolo <emaringolo@gmail.com> wrote:
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else.
Morphic + Glamour sometimes + bad UI/algorithms design put us in a bad place concerning UI speed.
Pharo 5 was the turning point when it comes to that, and it correlates with the introduction of the Glamour-based tools.
We are working to fix it, but this is not straightforward.
I know, and the effort put into that is really appreciated. I haven't used your latest "native widgets" (GTK) build, but as long as the UI isn't programmed to be as async as possible, then any non-UI related event will slowdown or micro-block the UI, causing the noticed latency. I know I'm speaking the obvious to you here, but if you look at things like Android Architecture there is a lot to learn from, because mobile users expect significantly faster, non-blocking UIs that desktop, and not to mention web (although this is is changing too). Regards, Esteban A. Maringolo
Hi Esteban, Le lun. 7 oct. 2019 à 12:26, Esteban Maringolo <emaringolo@gmail.com> a écrit :
On Mon, Oct 7, 2019 at 12:07 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 7 Oct 2019, at 11:55, Esteban Maringolo <emaringolo@gmail.com> wrote:
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else.
Morphic + Glamour sometimes + bad UI/algorithms design put us in a bad place concerning UI speed.
Pharo 5 was the turning point when it comes to that, and it correlates with the introduction of the Glamour-based tools.
We are working to fix it, but this is not straightforward.
I know, and the effort put into that is really appreciated.
I haven't used your latest "native widgets" (GTK) build, but as long as the UI isn't programmed to be as async as possible, then any non-UI related event will slowdown or micro-block the UI, causing the noticed latency.
I know I'm speaking the obvious to you here, but if you look at things like Android Architecture there is a lot to learn from, because mobile users expect significantly faster, non-blocking UIs that desktop, and not to mention web (although this is is changing too).
I would recommend that reference: https://danluu.com/input-lag/ to make sure we have a baseline to evaluate GUI responsiveness. In part because some objectives may be unrealistic, given the software and hardware layers involved. Thierry
Regards,
Esteban A. Maringolo
I haven't used your latest "native widgets" (GTK) build, but as long as the UI isn't programmed to be as async as possible, then any non-UI related event will slowdown or micro-block the UI, causing the noticed latency. That's interesting. Yes, we need async updating without the microblocking dragging down the speed. Is the GTK build ready for testing now? I know I'm speaking the obvious to you here, but if you look at things like Android Architecture there is a lot to learn from, because mobile users expect significantly faster, non-blocking UIs that desktop, and not to mention web (although this is is changing too). It's a good point. Shaping
I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward. Yes, lots of redirection and extra steps. Many degrees of freedom. Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing. Iâve donât plenty of informal comparative testing mostly with the GUI. Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer). VW is still noticeably quicker in GUI responsiveness, in most cases. One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about twice as fast as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there. Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you guys are waiting for the new GUI framework(s) to firm up? I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?). I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit. Yes, itâs like a creeping disease. Lol Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not. Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms.
Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind.
Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like <https://github.com/pavelfatin/typometer> https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency. Indeed. My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where you literally donât wait for anything, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else. I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen? But VW event model is not better than Pharo's, so it might be something else. Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is. Cheers, Shaping
On 07/10/2019 12:39, Shaping wrote:
I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward.
Yes, lots of redirection and extra steps. Many degrees of freedom.  Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing.
Iâve donât plenty of informal comparative testing mostly with the GUI.   Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer).  VW is still noticeably quicker in GUI responsiveness, in most cases.  One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about _twice as fast_ as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â
Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there.  Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you  guys are waiting for the new GUI framework(s) to firm up?  I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?).
I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit.
Yes, itâs like a creeping disease. Lol
Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not.  Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
You can take a look at that project for that : https://github.com/juliendelplanque/Mirage
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms.
Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind.
Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency.
Indeed.
My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where _you literally donât wait for anything_, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else.
I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen?
But VW event model is not better than Pharo's, so it might be something else.
Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is.
Cheers,
Shaping
Pierre
On 7 Oct 2019, at 12:39, Shaping <shaping@uurda.org> wrote:
I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward.
Yes, lots of redirection and extra steps. Many degrees of freedom. Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing.
Iâve donât plenty of informal comparative testing mostly with the GUI. Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer). VW is still noticeably quicker in GUI responsiveness, in most cases. One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about twice as fast as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â
Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there. Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you guys are waiting for the new GUI framework(s) to firm up? I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?).
I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit.
Yes, itâs like a creeping disease. Lol
Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not. Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms. Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind. Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like https://github.com/pavelfatin/typometer <https://github.com/pavelfatin/typometer>), Sublime, TextEdit, Notepad++ measure sub 10ms latency.
Indeed.
My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where you literally donât wait for anything, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else.
I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen?
I know, since Iâm doing it :) Native widgets (more like âgtk widgetsâ. This is technically just native under linux, but Gtk3 works very well both in Windows and Mac (you just has to ship it) will be available for development in Pharo 8. Now, moving the whole Pharo into it will take a bit longer, and we hope to be able to have a âPharo Gtk experienceâ for Pharo 9 (lots of tools to migrate to Spec2). Esteban
But VW event model is not better than Pharo's, so it might be something else.
Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is.
Cheers,
Shaping
I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen? I know, since Iâm doing it :) Native widgets (more like âgtk widgetsâ. This is technically just native under linux, but Gtk3 works very well both in Windows and Mac (you just has to ship it) will be available for development in Pharo 8. Now, moving the whole Pharo into it will take a bit longer, and we hope to be able to have a âPharo Gtk experienceâ for Pharo 9 (lots of tools to migrate to Spec2). Great. Looking forward to it. Shaping
Hello, Regarding native widget, on the VW side the usage on them brought slowness on the OSX platform. Windows platform is speedy, but OSX platform is slower using native widget than with emulated ones. So native widget alone are not always a solution. ciao giorgio On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 7 Oct 2019, at 12:39, Shaping <shaping@uurda.org> wrote:
I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward.
Yes, lots of redirection and extra steps. Many degrees of freedom. Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing.
Iâve donât plenty of informal comparative testing mostly with the GUI. Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer). VW is still noticeably quicker in GUI responsiveness, in most cases. One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about *twice as fast* as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â
Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there. Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you guys are waiting for the new GUI framework(s) to firm up? I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?).
I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit.
Yes, itâs like a creeping disease. Lol
Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not. Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms. Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind. Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency.
Indeed.
My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where *you literally donât wait for anything*, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else.
I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen?
I know, since Iâm doing it :) Native widgets (more like âgtk widgetsâ. This is technically just native under linux, but Gtk3 works very well both in Windows and Mac (you just has to ship it) will be available for development in Pharo 8. Now, moving the whole Pharo into it will take a bit longer, and we hope to be able to have a âPharo Gtk experienceâ for Pharo 9 (lots of tools to migrate to Spec2).
Esteban
But VW event model is not better than Pharo's, so it might be something else.
Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is.
Cheers,
Shaping
Regarding native widget, on the VW side the usage on them brought slowness on the OSX platform. Windows platform is speedy, but OSX platform is slower using native widget than with emulated ones. So native widget alone are not always a solution. Thatâs interesting and unexpected (I donât use OSX). I would think that something is wrong with the VW native implementation or interface to it. VW emulates GUIs well, but I would not expect it to beat native. Shaping On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> > wrote: On 7 Oct 2019, at 12:39, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward. Yes, lots of redirection and extra steps. Many degrees of freedom. Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing. Iâve donât plenty of informal comparative testing mostly with the GUI. Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer). VW is still noticeably quicker in GUI responsiveness, in most cases. One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about twice as fast as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there. Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you guys are waiting for the new GUI framework(s) to firm up? I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?). I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit. Yes, itâs like a creeping disease. Lol Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not. Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms.
Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind.
Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like <https://github.com/pavelfatin/typometer> https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency. Indeed. My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where you literally donât wait for anything, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else. I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen? I know, since Iâm doing it :) Native widgets (more like âgtk widgetsâ. This is technically just native under linux, but Gtk3 works very well both in Windows and Mac (you just has to ship it) will be available for development in Pharo 8. Now, moving the whole Pharo into it will take a bit longer, and we hope to be able to have a âPharo Gtk experienceâ for Pharo 9 (lots of tools to migrate to Spec2). Esteban But VW event model is not better than Pharo's, so it might be something else. Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is. Cheers, Shaping
for what I know it's the way it's integrated with the underlain OS. On windows things are much, much better. *VW emulates GUIs well, but I would not expect it to beat native*. I would restate it as : I would not expect native to be slower that emulated.... :) seems the same, but not exactly... ciao giorgio I hope to have time to look again at Pharo one of these days. But time is always a scarce resource :) On Wed, Oct 9, 2019 at 4:17 AM Shaping <shaping@uurda.org> wrote:
Regarding native widget, on the VW side the usage on them brought slowness on the OSX platform. Windows platform is speedy, but OSX platform is slower using native widget than with emulated ones.
So native widget alone are not always a solution.
Thatâs interesting and unexpected (I donât use OSX). I would think that something is wrong with the VW native implementation or interface to it. VW emulates GUIs well, but I would not expect it to beat native.
Shaping
On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 7 Oct 2019, at 12:39, Shaping <shaping@uurda.org> wrote:
I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward.
Yes, lots of redirection and extra steps. Many degrees of freedom. Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing.
Iâve donât plenty of informal comparative testing mostly with the GUI. Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer). VW is still noticeably quicker in GUI responsiveness, in most cases. One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about *twice as fast* as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â
Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there. Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you guys are waiting for the new GUI framework(s) to firm up? I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?).
I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit.
Yes, itâs like a creeping disease. Lol
Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not. Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms.
Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind.
Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency.
Indeed.
My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where *you literally donât wait for anything*, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else.
I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen?
I know, since Iâm doing it :)
Native widgets (more like âgtk widgetsâ. This is technically just native under linux, but Gtk3 works very well both in Windows and Mac (you just has to ship it) will be available for development in Pharo 8.
Now, moving the whole Pharo into it will take a bit longer, and we hope to be able to have a âPharo Gtk experienceâ for Pharo 9 (lots of tools to migrate to Spec2).
Esteban
But VW event model is not better than Pharo's, so it might be something else.
Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is.
Cheers,
Shaping
On 9 Oct 2019, at 10:33, giorgio ferraris <giorgio.ferraris@gmail.com> wrote:
for what I know it's the way it's integrated with the underlain OS. On windows things are much, much better.
VW emulates GUIs well, but I would not expect it to beat native. I would restate it as : I would not expect native to be slower that emulated.... :) seems the same, but not exactlyâ¦
There are a lot of things to consider, not just the native widgets. For example: how do you run those widgets? Because you need an event loop⦠and while linux and windows do not care in which thread you run this, macOS requires you to run it in the main thread. This means you need to run the VM using one of two strategies: 1) using the idle signal of Gtk (in case of gtk, but other frameworks have similar things). This is of course suboptimal and forget about real-time processing. 2) running the VM in a separated thread. This works as expected (and it also follow apple application design recommendations) but then you need to make sure the communication between the main thread and your vm thread work as expected (and is not so easy) With Pablo we are working on (2), and I have to say that yes, if you do not manage well things, you will not have more speed âjust becauseâ :) Esteban
ciao
giorgio
I hope to have time to look again at Pharo one of these days. But time is always a scarce resource :)
On Wed, Oct 9, 2019 at 4:17 AM Shaping <shaping@uurda.org <mailto:shaping@uurda.org>> wrote: Regarding native widget, on the VW side the usage on them brought slowness on the OSX platform. Windows platform is speedy, but OSX platform is slower using native widget than with emulated ones.
So native widget alone are not always a solution.
Thatâs interesting and unexpected (I donât use OSX). I would think that something is wrong with the VW native implementation or interface to it. VW emulates GUIs well, but I would not expect it to beat native.
Shaping
On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 7 Oct 2019, at 12:39, Shaping <shaping@uurda.org <mailto:shaping@uurda.org>> wrote:
I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward.
Yes, lots of redirection and extra steps. Many degrees of freedom. Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing.
Iâve donât plenty of informal comparative testing mostly with the GUI. Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer). VW is still noticeably quicker in GUI responsiveness, in most cases. One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about twice as fast as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â
Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there. Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you guys are waiting for the new GUI framework(s) to firm up? I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?).
I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit.
Yes, itâs like a creeping disease. Lol
Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not. Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms.
Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind.
Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like https://github.com/pavelfatin/typometer <https://github.com/pavelfatin/typometer>), Sublime, TextEdit, Notepad++ measure sub 10ms latency.
Indeed.
My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where you literally donât wait for anything, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else.
I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen?
I know, since Iâm doing it :)
Native widgets (more like âgtk widgetsâ. This is technically just native under linux, but Gtk3 works very well both in Windows and Mac (you just has to ship it) will be available for development in Pharo 8.
Now, moving the whole Pharo into it will take a bit longer, and we hope to be able to have a âPharo Gtk experienceâ for Pharo 9 (lots of tools to migrate to Spec2).
Esteban
But VW event model is not better than Pharo's, so it might be something else.
Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is.
Cheers,
Shaping
On 9 Oct 2019, at 10:33, giorgio ferraris <giorgio.ferraris@gmail.com <mailto:giorgio.ferraris@gmail.com> > wrote: for what I know it's the way it's integrated with the underlain OS. On windows things are much, much better. VW emulates GUIs well, but I would not expect it to beat native. I would restate it as : I would not expect native to be slower that emulated.... :) seems the same, but not exactly⦠There are a lot of things to consider, not just the native widgets. For example: how do you run those widgets? Because you need an event loop⦠and while linux and windows do not care in which thread you run this, macOS requires you to run it in the main thread. Okay. This means you need to run the VM using one of two strategies: 1) using the idle signal of Gtk (in case of gtk, but other frameworks have similar things). This is of course suboptimal and forget about real-time processing. Yes. 2) running the VM in a separated thread. This works as expected (and it also follow apple application design recommendations) but then you need to make sure the communication between the main thread and your vm thread work as expected (and is not so easy) How efficient is the signaling/queuing between the threads? Shaping On Wed, Oct 9, 2019 at 4:17 AM Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: Regarding native widget, on the VW side the usage on them brought slowness on the OSX platform. Windows platform is speedy, but OSX platform is slower using native widget than with emulated ones. So native widget alone are not always a solution. Thatâs interesting and unexpected (I donât use OSX). I would think that something is wrong with the VW native implementation or interface to it. VW emulates GUIs well, but I would not expect it to beat native. Shaping On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> > wrote: On 7 Oct 2019, at 12:39, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward. Yes, lots of redirection and extra steps. Many degrees of freedom. Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing. Iâve donât plenty of informal comparative testing mostly with the GUI. Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer). VW is still noticeably quicker in GUI responsiveness, in most cases. One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about twice as fast as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there. Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you guys are waiting for the new GUI framework(s) to firm up? I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?). I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit. Yes, itâs like a creeping disease. Lol Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not. Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms.
Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind.
Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like <https://github.com/pavelfatin/typometer> https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency. Indeed. My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where you literally donât wait for anything, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else. I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen? I know, since Iâm doing it :) Native widgets (more like âgtk widgetsâ. This is technically just native under linux, but Gtk3 works very well both in Windows and Mac (you just has to ship it) will be available for development in Pharo 8. Now, moving the whole Pharo into it will take a bit longer, and we hope to be able to have a âPharo Gtk experienceâ for Pharo 9 (lots of tools to migrate to Spec2). Esteban But VW event model is not better than Pharo's, so it might be something else. Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is. Cheers, Shaping
On Wed, Oct 9, 2019 at 10:50 AM Esteban Lorenzano <estebanlm@gmail.com> wrote:
There are a lot of things to consider, not just the native widgets.
For example: how do you run those widgets? Because you need an event loop⦠and while linux and windows do not care in which thread you run this, macOS requires you to run it in the main thread. This means you need to run the VM using one of two strategies:
1) using the idle signal of Gtk (in case of gtk, but other frameworks have similar things). This is of course suboptimal and forget about real-time processing. 2) running the VM in a separated thread. This works as expected (and it also follow apple application design recommendations) but then you need to make sure the communication between the main thread and your vm thread work as expected (and is not so easy)
With Pablo we are working on (2), and I have to say that yes, if you do not manage well things, you will not have more speed âjust becauseâ :)
This is great. Android does the same thing as MacOS, and it is even enforced by the OS, it will mark any app as unresponsive if it blocks the UI thread. You can fork Threads that communicate with the UI thread by means of a "Handler" [1], to map this using a dynamic language is simpler, but you'd need an event loop in the UI first (I don't know whether we have this in Pharo). Regards, [1] https://developer.android.com/training/multiple-threads/communicate-ui Esteban A. Maringolo
for what I know it's the way it's integrated with the underlain OS. On windows things are much, much better. VW emulates GUIs well, but I would not expect it to beat native. I would restate it as : I would not expect native to be slower that emulated.... :) seems the same, but not exactly... Indeed. I donât follow OSX design, but would not expect such poor native performance from Apple. I donât get it. Shaping On Wed, Oct 9, 2019 at 4:17 AM Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: Regarding native widget, on the VW side the usage on them brought slowness on the OSX platform. Windows platform is speedy, but OSX platform is slower using native widget than with emulated ones. So native widget alone are not always a solution. Thatâs interesting and unexpected (I donât use OSX). I would think that something is wrong with the VW native implementation or interface to it. VW emulates GUIs well, but I would not expect it to beat native. Shaping On Mon, Oct 7, 2019 at 2:08 PM Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com> > wrote: On 7 Oct 2019, at 12:39, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: I haven't seen is the instability of the VM you mention, it has worked pretty well for my average use, although the UX is not straightforward. Yes, lots of redirection and extra steps. Many degrees of freedom. Seemingly no good default âhappyâ path to simplify things a little before you start to investigate the variations/choices.
The other thing that keeps me planted firmly in VW is the sheer speed of it.
I don't know if there are recent benchmarks, but I've felt Pharo to be really fast compared to VW when it comes to computing. Iâve donât plenty of informal comparative testing mostly with the GUI. Iâve used VW continuously for 29 years and Pharo on and off since 2006. (Iâm really trying to port, but I keep failing to do it; getting closer). VW is still noticeably quicker in GUI responsiveness, in most cases. One big difference is the Pharo HTTP client, with all those wonderful primitives. Itâs about twice as fast as VWâs. Bravo. I meant to tell that to Sven recently, and forgot.
Pharo looks generally much better, but itâs mushy, and thatâs a problem. VW is not.
Working regularly with VW or VAST when I go back to Pharo the "mushiness" is significantly noticeable, but if you open a Pharo 3 image (or even Pharo 4) you'll feel it really "snappy", but of course you'll lose all the improvements since then; and that's the current tradeoff.â Yeah, I guess all the new slick GUIs are a bit heavier. This machine is just okay for speed â2.7 GHz Xeon, but VW feels okay. Pharo tends to put me slowly to sleep with the tiny but noticeable lags here and there. Iâm very fond of GT. Beautiful. Not sure what to do go get the GUI quickness back. Maybe you guys are waiting for the new GUI framework(s) to firm up? I tried Cuis, and was not impressed. Itâs too lean/Spartan and still not very fast (slower in some ways than Pharo). I like the Pharo creature-comforts (who wouldnât?). I never understood the reason for the incremental slowdown, it is even present in "modern" tools such as GTToolkit. Yes, itâs like a creeping disease. Lol Another thing I miss enough to want to implement (or fake-out somehow) is Alt-tabbing as a way to get around thru your browsers. Usually I have 4 to 6 up at once, if Iâm behaving, and as many as 20 if Iâm not. Looking about for the tabs at the bottom to click is not nearly as fun as Alt-Tabbing. Maybe I could emulate Alt-Tab with Alt-Shift-Tabâa bit of a finger twister, but it might work.
Gestural dynamics are very quick, well under 100 ms latency, often less than 20 ms.
Iâm seeing 100, 150, and 200 ms regularly in Pharo. Itâs too mushy, and that slows the mind.
Any developer understands this, whether he talks about it or not.
This is true, below 20ms is ideal, and top-notch CLI terminals are benchmarking this as a selling point (using stuff like <https://github.com/pavelfatin/typometer> https://github.com/pavelfatin/typometer), Sublime, TextEdit, Notepad++ measure sub 10ms latency. Indeed. My whole nervous system definitely feels this speed effect and starts to thought-glide better below these tiny latencies. Iâm sure many reading this have had similar experiences. Something similar happens when you are fortunate enough to use a machine with extremely fast striped SSD drives, where you literally donât wait for anything, except the bloody internet. This doesnât just change the speed at which you do the work. It reorganizes your mind and skills in ways you had not anticipated because you can flow so much more quickly, making connections further forward and backward in your thought stream. My point is that if the speed and low-latencies are made a priority, we can attract users just on this basis alone. Even I would be working harder at improving Pharo (and complaining less) if everything were snappy. I would probably just get on with doing the needed tasks. Interesting how that works. Speed: it changes you. It changes the whole game.
So Iâm wondering when the Pharo GUI will snap as well as VW.
Maybe with native widgets there will be a significant speedup, although I don't know whether the lag comes from rendering time or from something else. I would like to know more about the native widgets in Pharo. Does anyone know when this is likely to happen? I know, since Iâm doing it :) Native widgets (more like âgtk widgetsâ. This is technically just native under linux, but Gtk3 works very well both in Windows and Mac (you just has to ship it) will be available for development in Pharo 8. Now, moving the whole Pharo into it will take a bit longer, and we hope to be able to have a âPharo Gtk experienceâ for Pharo 9 (lots of tools to migrate to Spec2). Esteban But VW event model is not better than Pharo's, so it might be something else. Iâve not looked into the details, but I will sometimes just repeatedly click on a method name and watch how long the code pane takes to render in VW and Pharo, and I donât get what Pharo could be doing to make that time so long. Both are indexing into the sources file or the changes file to get some text, and then there is the TT-font rendering, which is probably where the CPU cycles are going. I should look into if further, but Iâm sure someone reading this knows enough about the rendering path to say where the bottleneck is. Cheers, Shaping
On 7 Oct 2019, at 05:12, Shaping <shaping@uurda.org> wrote:
How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we donât want to read JS if we donât have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not.
PharoJS allows to reuse existing JS libraries. Just reference constructors as you reference Pharo classes. Below is a link to an example, where we reuse the physics engine MatterJS https://pharojs.github.io/Demos/MatterJsDemo/ Noury
How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we donât want to read JS if we donât have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not. PharoJS allows to reuse existing JS libraries. Thatâs encouraging. Where is the most up-to-date tutorial on how to build an app in PharoJS using 3rd-party JS libs? Just reference constructors as you reference Pharo classes. Below is a link to an example, where we reuse the physics engine MatterJS https://pharojs.github.io/Demos/MatterJsDemo/ Impressive. Shaping
On 7 Oct 2019, at 15:27, Shaping <shaping@uurda.org> wrote:
How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we donât want to read JS if we donât have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not.
PharoJS allows to reuse existing JS libraries.
Thatâs encouraging. Where is the most up-to-date tutorial on how to build an app in PharoJS using 3rd-party JS libs?
The ESUG 2018 presentation with the MatterJs Demo is what you are looking for https://pharojs.github.io/doc.html Noury
Thanks, Noury. I got PharoJS baseline to load into a Widows 10 Pharo 7.0 64-bit, but the Launcher is still flaky. With the folder now moved (to where paths will be shorter and workable), I donât see the newly created images in the right pane. I have to cycle the Launcher for that to happen. In any case, the load worked and I can test on Windows 10 now. Can someone please work on the installer and the problem of changing directories using Launcher Settings (and saving the image more explicitly). Iâll be available for testing if that helps. Thanks. Shaping From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Noury Bouraqadi Sent: Monday, 7 October, 2019 09:03 To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS On 7 Oct 2019, at 15:27, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we donât want to read JS if we donât have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not. PharoJS allows to reuse existing JS libraries. Thatâs encouraging. Where is the most up-to-date tutorial on how to build an app in PharoJS using 3rd-party JS libs? The ESUG 2018 presentation with the MatterJs Demo is what you are looking for https://pharojs.github.io/doc.html Noury
On 7 Oct 2019, at 05:12, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we donât want to read JS if we donât have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not. PharoJS allows to reuse existing JS libraries. Just reference constructors as you reference Pharo classes. Below is a link to an example, where we reuse the physics engine MatterJS https://pharojs.github.io/Demos/MatterJsDemo/ Hi Noury. Are you saying that none of the JS was manually written or that some of it was and the rest is coming from an imported library. Iâm looking at the page in Chrome dev tools now. Shaping
On 7 Oct 2019, at 15:41, Shaping <shaping@uurda.org> wrote:
On 7 Oct 2019, at 05:12, Shaping <shaping@uurda.org <mailto:shaping@uurda.org>> wrote:
How does PharoJS deal with the JS reuse issue? There are lots of JS widgets out there that we would just like to use, but we donât want to read JS if we donât have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not.
PharoJS allows to reuse existing JS libraries. Just reference constructors as you reference Pharo classes.
Below is a link to an example, where we reuse the physics engine MatterJS https://pharojs.github.io/Demos/MatterJsDemo/ <https://pharojs.github.io/Demos/MatterJsDemo/>
Hi Noury.
Are you saying that none of the JS was manually written or that some of it was and the rest is coming from an imported library. Iâm looking at the page in Chrome dev tools now.
Exactly. That's the whole point of having PharoJS :-) The HTML file imports 2 js file. One is the MatterJS library, and the other is generated by PharoJS Noury
Are you saying that none of the JS was manually written or that some of it was and the rest is coming from an imported library. Iâm looking at the page in Chrome dev tools now. Exactly. That's the whole point of having PharoJS :-) Exactly. But then I donât understand Cincomâs motivation for architecting AppeX the way it did. The HTML file imports 2 js file. One is the MatterJS library, and the other is generated by PharoJS I prefer the DSL approach of PharoJS. The code is clean, brief, clear, and anglogrammatical. Easy to do in Smalltalk. Hard to impossible with JS. With AppeX you need to read and apparently write a good amount of JS. Whatâs the point? Much of the utility of Smalltalk is then lost except the debugging is better. Shaping
The PharoJS FAQ page describes this: Â Â Â https://pharojs.github.io/faq.html ../Dave On Oct 7, 2019, 8:41 AM -0400, Noury Bouraqadi <bouraqadi@gmail.com>, wrote:
On 7 Oct 2019, at 05:12, Shaping <shaping@uurda.org> wrote:
How does PharoJS deal with the JS reuse issue?  There are lots of JS widgets out there that we would just like to use, but we donât want to read JS if we donât have to. There are many wheels to reinvent, or at least recode in DSL, if I understand the PharoJS scheme correctly, but I may not.
PharoJS allows to reuse existing JS libraries. Just reference constructors as you reference Pharo classes.
Below is a link to an example, where we reuse the physics engine MatterJS https://pharojs.github.io/Demos/MatterJsDemo/
Noury
participants (9)
-
David Mason -
Esteban Lorenzano -
Esteban Maringolo -
giorgio ferraris -
giorgio ferraris -
Noury Bouraqadi -
pmissech -
Shaping -
Thierry Goubier