Re: [Pharo-users] How to install stripe library on Pharo 7 64bit ?

[jmathews via Pharo-users]

--- Begin Message ---
Hi Paul,

Thanks for the update.  I tried your new code and it went futher than last
time.  However the debugger shows up during cleanup and the entire image
hangs.  I've attached a screenshot.

I also retested this with a completely fresh image using pharolauncher with
the same results.

-James
 



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--- End Message ---

Re: [Pharo-users] How to install stripe library on Pharo 7 64bit ?

[Paul DeBruicker]

Oh sorry.  I haven't updated the load instructions in a while.  I'll edit
them there today.

Try this instead.


Metacello new
 baseline:'Stripe';
 repository: 'http://smalltalkhub.com/mc/pdebruic/Stripe/main';
 load:#('Tests' 'Seaside-Example')






Pharo Smalltalk Users mailing list wrote
> Hi, 
> 
> I am just starting to work with Pharo and Seaside to create a website that
> accepts payments though stripe.  Smalltalk is supported as a third party
> library according to https://stripe.com/docs/libraries#third-party
> 
> However I cannot get it to install.  Is the stripe library still
> supported? 
> If anyone can help me with this I would really appreciate it.  
> 
> I am using Pharo 7.0 64bit on Ubuntu linux.
> 
> I followed the instructions to install the library as per
> http://smalltalkhub.com/#!/~pdebruic/Stripe/
> 
> 
> Gofer new
>   url:  'http://smalltalkhub.com/mc/pdebruic/Stripe/main';
>   package: 'ConfigurationOfStripe';
> load.
> 
> (Smalltalk at: #ConfigurationOfStripe) project stableVersion
> load:#('Tests'
> 'Seaside-Example').
> 
> 
> Transcript log:
> 
> ConfigurationOfStripe>>initializeEnvironment (ZnZodiacNetworkingUtils is
> Undeclared) 
> 
> Loading 20161203 of ConfigurationOfStripe...
> Fetched -> ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.120 ---
> http://mc.stfx.eu/ZincHTTPComponents ---
> http://mc.stfx.eu/ZincHTTPComponents
> Loaded -> ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.120 ---
> http://mc.stfx.eu/ZincHTTPComponents ---
> http://mc.stfx.eu/ZincHTTPComponents
> Fetched -> ConfigurationOfHTTPAPIClient-PaulDeBruicker.10 ---
> http://smalltalkhub.com/mc/pdebruic/HTTPAPIClient/main/ ---
> http://smalltalkhub.com/mc/pdebruic/HTTPAPIClient/main/
> Loaded -> ConfigurationOfHTTPAPIClient-PaulDeBruicker.10 ---
> http://smalltalkhub.com/mc/pdebruic/HTTPAPIClient/main/ ---
> http://smalltalkhub.com/mc/pdebruic/HTTPAPIClient/main/
> Fetched -> ConfigurationOfSeaside3-topa.337 ---
> http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/ ---
> http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/
> Loaded -> ConfigurationOfSeaside3-topa.337 ---
> http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/ ---
> http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/
> 
> 
> Debugger triggered:
> Error:Name not found: Seaside-Pharo-Development
> 
> 
> p.s. - I am a beginner at smalltalk, so thank you for your patience
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[giorgio ferraris]

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 
wrote:

>
>
> On 7 Oct 2019, at 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.
>
> > 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) 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Shaping]

 

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

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Shaping]

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-boun...@lists.pharo.org] On Behalf Of 
Noury Bouraqadi
Sent: Monday, 7 October, 2019 09:03
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

 

 





On 7 Oct 2019, at 15:27, Shaping mailto:shap...@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

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Noury Bouraqadi]

> On 7 Oct 2019, at 15:41, Shaping  wrote:
> 
> On 7 Oct 2019, at 05:12, Shaping  > 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.   
>  
>  
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

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Noury Bouraqadi]

> On 7 Oct 2019, at 15:27, Shaping  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

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[David Mason]

The PharoJS FAQ page describes this:

    https://pharojs.github.io/faq.html

../Dave
On Oct 7, 2019, 8:41 AM -0400, Noury Bouraqadi , wrote:
>
>
> > On 7 Oct 2019, at 05:12, Shaping  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
>

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Shaping]

On 7 Oct 2019, at 05:12, Shaping mailto:shap...@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

 

 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Shaping]

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

 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[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

 

Re: [Pharo-users] Installing PharoJS

[Shaping]

Thanks, Ben.

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of Ben 
Coman
Sent: Monday, 7 October, 2019 06:16
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Installing PharoJS

 

 

 

On Mon, 7 Oct 2019 at 09:57, Shaping mailto:shap...@uurda.org> > wrote:

File name or extension is too long, but length is 118, well under 260.  So….

 

Failed to stat file?  Is that supposed to be “start”?

 

No. Its from the Cygwin stat() system call ...

https://en.wikipedia.org/wiki/Stat_(system_call)

 

cheer s-ben

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[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

 

Re: [Pharo-users] JS charting widgets in PharoJS

[Noury Bouraqadi]

I'm not aware of anyone doing it.

Noury

> On 7 Oct 2019, at 06:44, Shaping  wrote:
> 
> Does anyone have experience with JS financial charting widgets like
>  
> https://app.fintatech.com/demo 
>  
> in PharoJS?
>  
>  
> Shaping

Re: [Pharo-users] Installing PharoJS

[Noury Bouraqadi]

Some of my students reported similar errors with gitlib on Windows on other 
projects (not PharoJS).
Removing spaces from the image name helps.

Noury


> On 7 Oct 2019, at 14:23, Shaping  wrote:
> 
> Correction length is 264.  The debugger abbreviates the string with an 
> ellipsis.Registry entry removes the 260-character limit.   Not sure why 
> this does not work:
>  
> 'C:/Users/Crypto/Documents/Pharo/images/PharoJS in 7.0 
> 64-bit/pharo-local/iceberg/bouraqadi/PharoJS/CordovaExamples/Counter/node_modules/cordova-ios/tests/spec/unit/fixtures/ios-config-xml/SampleApp/Images.xcassets/LaunchImage.launchimage/Default-568h@2x~iphone.png'
>  size "264"
>  
>  
> I’ve installed PharoLauncher on the root of C.
>  
> I need to move the images to the root too or to my RAID.
>  
> I’m not able to move the folder from documents to another drive with a 
> shorter path, without doing folder surgery.  Also, I don’t see a way to save 
> the launcher image after I’ve tweaked the settings to point to the new 
> directories.   Further when I specify the new directory, the specific image 
> folder is moved (or regenerated) but no new /image folder is created.  Do the 
> new directory location does not reflect the old folder structure (in the user 
> documents folder), and requires manual work to be synced.  We probably don’t 
> want that.  Is there a more convenient and reliable way to have Launcher just 
> move all images and VMs to a new folder?
>  
>  
> --
> File name or extension is too long, but length is 118, well under 260.  So….
>  
> Failed to stat file?  Is that supposed to be “start”?
>  
> 
>  
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> Christopher Fuhrman
> Sent: Sunday, 6 October, 2019 11:34
> To: Any question about pharo is welcome 
> Subject: Re: [Pharo-users] Installing PharoJS
>  
> Hello,
>  
> The screenshot cuts off the error, but it may be the problem with file names 
> that are too long in libgit2.
>  
> It's a controversial problem in libgit2 for at least six years. 
> https://github.com/libgit2/libgit2/issues/1899 
> 
>  
> Hitting this problem is what drove me to install WSL on Windows 10 and use 
> Pharo that way, effectively not using Windows 10 for Pharo.
>  
> Other workarounds exist, including a short image name in the launcher, 
> putting image folders at the root level, telling Pharo to put iceberg repos 
> in a fixed directory closer to the root, etc. You want a way to prevent a 
> Pharo file path that's longer than 260 chars. 
>  
> Cheers,
>  
> Cris
> 
> On Sun, Oct 6, 2019, 10:52 Shaping  > wrote:
>> All you need to do is evaluating the following expression in a playground.
>> I suggest you do it in a fresh image.
>>  
>>> Metacello new 
>>>baseline: 'PharoJS';
>>>repository: 'github://bouraqadi/PharoJS';
>>>load
>>> 
>>  
>> That was one of the tests mentioned.   See the screenshot below.  The 
>> problem seems Git-related:
>>  
>>  
>> 
>>  
>>  
>> Shaping
>>  
>> 
>>> On 6 Oct 2019, at 14:49, Shaping >> > wrote:
>>>  
>>> Hi.
>>> 
>>> Can someone explain exactly how to install the latest version of PharoJS,
>>> and verify that the proedure really works?
>>> 
>>> I've tried:
>>> 
>>> 1) cloning the PharoJS repo in Pharo 8.0 with Iceberg, and get a Not Loaded
>>> final state for the repo.
>>> 2) loading into Pharo 7, 6.1, and 5 using
>>> 
>>> Metacello new 
>>>baseline: 'PharoJS';
>>>repository: 'github://bouraqadi/PharoJS';
>>>load
>>> 
>>> All tries fail with a walkback.
>>> 
>>> 3) loading into Pharo 4.0 using
>>> 
>>> Gofer it
>>> smalltalkhubUser: 'noury' project: 'PharoJS';
>>> addPackage: #ConfigurationOfPharoJS ;
>>> loadStable.
>>> 
>>> The walkback here mentions missing dependency RBGlobalNode.
>>> 
>>> 
>>> Suggestions are welcome.  
>>> 
>>> Thanks.
>>> 
>>> 
>>> Shaping
>>> 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Noury Bouraqadi]

> On 7 Oct 2019, at 05:12, Shaping  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

Re: [Pharo-users] Installing PharoJS

[pmissech]

On 07/10/2019 14:23, Shaping wrote:


Correction length is 264.  The debugger abbreviates the string with an 
ellipsis.    Registry entry removes the 260-character limit.   Not 
sure why this does not work:


'C:/Users/Crypto/Documents/Pharo/images/PharoJS in 7.0 
64-bit/pharo-local/iceberg/bouraqadi/PharoJS/CordovaExamples/Counter/node_modules/cordova-ios/tests/spec/unit/fixtures/ios-config-xml/SampleApp/Images.xcassets/LaunchImage.launchimage/Default-568h@2x~iphone.png' 
size "264"


I’ve installed PharoLauncher on the root of C.

I need to move the images to the root too or to my RAID.

I’m not able to move the folder from documents to another drive with a 
shorter path, without doing folder surgery. Also, I don’t see a way to 
save the launcher image after I’ve tweaked the settings to point to 
the new directories.   Further when I specify the new directory, the 
specific image folder is moved (or regenerated) but no new /image 
folder is created.  Do the new directory location does not reflect the 
old folder structure (in the user documents folder), and requires 
manual work to be synced.  We probably don’t want that.  Is there a 
more convenient and reliable way to have Launcher just move all images 
and VMs to a new folder?



open settings  (bottom left of the launcher)

-Pharo Launcher settings

--Locations of your images

 -> change the path


Pierre

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Esteban Lorenzano]

> On 7 Oct 2019, at 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.
>  
> > 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 

[Pharo-users] How to install stripe library on Pharo 7 64bit ?

[jmathews via Pharo-users]

--- Begin Message ---
Hi, 

I am just starting to work with Pharo and Seaside to create a website that
accepts payments though stripe.  Smalltalk is supported as a third party
library according to https://stripe.com/docs/libraries#third-party

However I cannot get it to install.  Is the stripe library still supported? 
If anyone can help me with this I would really appreciate it.  

I am using Pharo 7.0 64bit on Ubuntu linux.

I followed the instructions to install the library as per
http://smalltalkhub.com/#!/~pdebruic/Stripe/


Gofer new
  url:  'http://smalltalkhub.com/mc/pdebruic/Stripe/main';
  package: 'ConfigurationOfStripe';
load.

(Smalltalk at: #ConfigurationOfStripe) project stableVersion load:#('Tests'
'Seaside-Example').


Transcript log:

ConfigurationOfStripe>>initializeEnvironment (ZnZodiacNetworkingUtils is
Undeclared) 

Loading 20161203 of ConfigurationOfStripe...
Fetched -> ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.120 ---
http://mc.stfx.eu/ZincHTTPComponents ---
http://mc.stfx.eu/ZincHTTPComponents
Loaded -> ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.120 ---
http://mc.stfx.eu/ZincHTTPComponents ---
http://mc.stfx.eu/ZincHTTPComponents
Fetched -> ConfigurationOfHTTPAPIClient-PaulDeBruicker.10 ---
http://smalltalkhub.com/mc/pdebruic/HTTPAPIClient/main/ ---
http://smalltalkhub.com/mc/pdebruic/HTTPAPIClient/main/
Loaded -> ConfigurationOfHTTPAPIClient-PaulDeBruicker.10 ---
http://smalltalkhub.com/mc/pdebruic/HTTPAPIClient/main/ ---
http://smalltalkhub.com/mc/pdebruic/HTTPAPIClient/main/
Fetched -> ConfigurationOfSeaside3-topa.337 ---
http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/ ---
http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/
Loaded -> ConfigurationOfSeaside3-topa.337 ---
http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/ ---
http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/


Debugger triggered:
Error:Name not found: Seaside-Pharo-Development


p.s. - I am a beginner at smalltalk, so thank you for your patience



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--- End Message ---

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Thierry Goubier]

Hi Esteban,

Le lun. 7 oct. 2019 à 12:26, Esteban Maringolo  a écrit :
>
> On Mon, Oct 7, 2019 at 12:07 PM Esteban Lorenzano  wrote:
> > > On 7 Oct 2019, at 11:55, Esteban Maringolo  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
>

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[pmissech]

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 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[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), 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 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Esteban Maringolo]

On Mon, Oct 7, 2019 at 12:07 PM Esteban Lorenzano  wrote:
> > On 7 Oct 2019, at 11:55, Esteban Maringolo  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

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Esteban Lorenzano]

> On 7 Oct 2019, at 11:55, Esteban Maringolo  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
> 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Esteban Maringolo]

> 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

Re: [Pharo-users] Installing PharoJS

[Shaping]

Metacello new 
   baseline: 'PharoJS';
   repository: 'github://bouraqadi/PharoJS';
   load

 

This is the officiel way of loading PharoJS as stated in Github and
pharojs.org  .

It should work just fine but ONLY with Pharo 7.

 

I got the above baseline to load into Pharo 7.0 on Ubuntu, which is running
in a Virtual Box VM, which, in turn, has its own little speed problems
compounding those of Pharo.

 

I'll try to reinstall Launcher on Windows at some location closer to the
root.  I don't think this is the problem. I've done the registry tweak to
remove the 260-character limit on file names.

 

Shaping



On 6 Oct 2019, at 14:49, Shaping mailto:shap...@uurda.org> > wrote:

 

Hi.

Can someone explain exactly how to install the latest version of PharoJS,
and verify that the proedure really works?

I've tried:

1) cloning the PharoJS repo in Pharo 8.0 with Iceberg, and get a Not Loaded
final state for the repo.
2) loading into Pharo 7, 6.1, and 5 using

Metacello new 
   baseline: 'PharoJS';
   repository: 'github://bouraqadi/PharoJS';
   load

All tries fail with a walkback.

3) loading into Pharo 4.0 using

Gofer it
smalltalkhubUser: 'noury' project: 'PharoJS';
addPackage: #ConfigurationOfPharoJS ;
loadStable.

The walkback here mentions missing dependency RBGlobalNode.


Suggestions are welcome.  

Thanks.


Shaping







 

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Shaping]

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.

Re: [Pharo-users] Pharo: Git and GUI speed; JS widget reuse in PharoJS

[Esteban Lorenzano]

Hi,

> On 7 Oct 2019, at 05:12, Shaping  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