- Pharo-users - lists.pharo.org

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

by 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

Oct. 7, 2019

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

by 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 <estebanlm(a)gmail.com> wrote: > > > On 7 Oct 2019, at 12:39, Shaping <shaping(a)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 > > >

Oct. 7, 2019

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

by 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

Oct. 7, 2019

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

by 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-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(a)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(a)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

Oct. 7, 2019

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

by Noury Bouraqadi

> On 7 Oct 2019, at 15:41, Shaping <shaping(a)uurda.org> wrote: > > On 7 Oct 2019, at 05:12, Shaping <shaping(a)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

Oct. 7, 2019

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

by Noury Bouraqadi

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

Oct. 7, 2019

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

by 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 <bouraqadi(a)gmail.com>, wrote: > > > > On 7 Oct 2019, at 05:12, Shaping <shaping(a)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 >

Oct. 7, 2019

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

by Shaping

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

Oct. 7, 2019

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

by 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

Oct. 7, 2019

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

by 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

Oct. 7, 2019