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

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.  

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?

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 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 would like to know more about the native widgets in Pharo.  Does anyone know when this is likely to happen?

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 3^rd-party JS libs?

On 7 Oct 2019, at 05:12, Shaping <[hidden email]> wrote:

PharoJS allows to reuse existing JS libraries.

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