October 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Number to VT_DECIMAL

by Richard O'Keefe

VT_DECIMAL sounds like a very close match to ScaledDecimal. Or it would if ScaledDecimal were consistently implemented between Smalltalks. The intent behind ScaledDecimal in the ANSI Smalltalk standard appears to have been an (m,p) representation where m and p are Integers standing for m * 10^p, for interoperation with DECIMAL fields in SQL databases (and of course with legacy code in COBOL and PL/I). This seems clear enough: 'Scaled decimal objects provide a precise representation of decimal fractions with an explicitly specified number of fractional digits.' That's not what VisualWorks, Squeak, and Pharo actually do. Instead they use a (q,p) representation where q is an *arbitrary* Fraction and p just says how many decimal places to *print*. This leads to some very confusing results, and means that the class *invented* to handle decimal fixed point is no more helpful to you in Pharo than Fraction is. The reason VW gives is that it "seems useful" that 1000s0/7 * 7 should equal 1000s0, but that's actually *not* a useful property for an interoperability class. If I want a Fraction, I know where to find it, and if I want it printed to a certain number of decimal places, I know how to do *that* without needing a complete number class for the purpose. VisualAge Smalltalk represents a decimal number as an array of 17 bits, which is a bit more adequate than VT_DECIMAL, and is precisely the IBM mainframe "packed decimal" format with an extra byte for a scale. So what should you do? Basically, a VT_DECIMAL is a pair (m,p,s) where m between: 0 and: (2 raisedTo: 96) - 1, p between: 0 and: 28, and s between: 0 and 1. So Number methods for: 'converting' asVtDecimalParts: p "p is the desired scale" |m s| s := 0. m := (self * (10 raisedToInteger: p)) rounded. m < 0 ifTrue: [s := 1. m := m negated]. ^Array with: m with: p with: s Note that with a Fraction, saying "is the denominator a power of 10, and if so which?" won't work, because 7/5 has a denominator that is not a power of 10 but it is exactly representable as 1.4s1. And in both ANSI Smalltalk and VT_DECIMAL, the numbers 1.4s1, 1.40s2, 1.400s3, and so on are distinguishable. So the scale *has* to be something over and above the numeric value. To put it another way, the scale is determined by what the external application WANTS, not what the Smalltalk code HAS. On Wed, 9 Oct 2019 at 09:24, eftomi <tomaz.turk(a)ef.uni-lj.si> wrote: > > Hi, I'm preparing a method to write a given Pharo's numerical value into an > external variant of type VT_DECIMAL. The purpose of this type is to retain > accuracy, it uses 12 bytes for "mantissa" and two bytes for a sign and a > scale (i. e. the position of decimal point). What would be the best approach > for the conversion, taken all the possible subclasses of class Number, that > is a Float, a Fraction and the Integers, and to keep the accuracy at the > same level? > > For instance, Fraction's numerator and denominator could be directly imputed > into VT_DECIMAL's value and scale if denominator is a power of 10. What to > do in other cases? > > A nice description of VT_DECIMAL is here > <https://bytecomb.com/vba-internals-decimal-variables-and-pointers-in-depth/> > . > > Best wishes, > Tomaz > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Oct. 9, 2019

Re: [Pharo-users] voyage mongo and transactionality

by Jonathan van Alteren

Hi James, I see how my explanation might be unclear. We have a main form for the agenda and a subform for an item, which is shown using Seaside call/answer. The save button of the subform is clicked, which adds the item to the underlying agenda model object, but the save button of the main form is notÂ clicked by the user. The callback for the main save button sends the save message to the agenda object, causing the database to be updated. So yes, the browser does submit the data on the subform, it's the main form component that doesn't receive the save button callback. I realize that this is in large part an issue with our design. However, the way object persistence seems to work in the image environment plays a large role. Kind regards, Jonathan van Alteren Founding Member | Object Guild jvalteren(a)objectguild.com On 8 Oct 2019, 15:41 +0200, James Foster <Smalltalk(a)jgfoster.net>, wrote: > > > On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren <jvalteren(a)objectguild.com> wrote: > > > > We've encountered an issue where a user makes changes to an agenda, but does not click the Save button. Instead, the user closes the browser or uses the navigation to go to a different part of the application. When navigating back to the original agenda, the changes made previously (e.g. items added) are still being displayed, even though they were never explicitly saved. > > Here is what I donât understand: how did the change get from the userâs client agent (browser) to the server? If you make a change to a field in a form and then close the browser, who sent the change to the server? If you show the save domain value in a different location, with a dynamically-generated id and name (so it isnât cached in the browser), or written to the Pharo Transcript, does the value still change? That is, are you sure that the change is in the reflected in the Smalltalk image and not just somehow cached in the browser? > > James > >

Oct. 9, 2019

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

by Esteban Lorenzano

> On 9 Oct 2019, at 10:33, giorgio ferraris <giorgio.ferraris(a)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(a)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(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > > > > > On 7 Oct 2019, at 12:39, Shaping <shaping(a)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 > > >

Oct. 9, 2019

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

by giorgio ferraris

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(a)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(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. 9, 2019

Re: [Pharo-users] Test method auto-generation in Calypso

by HernÃ¡n Morales Durand

Hi Denis, El vie., 4 oct. 2019 a las 5:09, Denis Kudriashov (<dionisiydk(a)gmail.com>) escribiÃ³: > Hi Hernan. > Sorry for late response (noticed mail just now). > > First try to implement just another browser tab which will show you > covering test or allow to create one. > Check for example how extra tab with test setup is done. > > Cool!! Well structured! > Then there is a feature in the tab manager to show multiple tabs at same > time. On the MacOS it is done by cmd+click on the tab header. > > That deserves a lot of points :) Thank you for sharing! Maybe it will be enough for your idea. > > I will keep you noticed HernÃ¡n Best regards, > Denis > > ÑÑ, 25 ÑÐµÐ½Ñ. 2019 Ð³., 5:07 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com > >: > >> Hi, >> >> I have this idea of typing a method in a Browser and have another code >> area in the same browser where the method test is "automagically >> generated". >> >> This is, divide the current method pane in two: One for the method being >> written itself, and another for its test, where at least the method >> selector could be autogenerated by writing testXXXX >> >> Of course being able to jump to the method test would be super nice! (and >> with a keyboard shortcut). This reminds myself to write the method now >> instead of forget it forever. >> >> Any hints to make this happen in Calypso? >> >> Cheers, >> >> HernÃ¡n >> >>

Oct. 9, 2019

Re: [Pharo-users] Test method auto-generation in Calypso

by HernÃ¡n Morales Durand

Hi Stephan El vie., 4 oct. 2019 a las 4:40, Stephan Eggermont (<stephan(a)stack.nl>) escribiÃ³: > HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: > > Hi, > > > > I have this idea of typing a method in a Browser and have another code > area > > in the same browser where the method test is "automagically generated". > > > > This is, divide the current method pane in two: One for the method being > > written itself, and another for its test, where at least the method > > selector could be autogenerated by writing testXXXX > > When do you find that useful? I have only a very small number of test cases > where the name of the test is that of the method. > > Actually I don't care too much about the test name, but it would be super for me to have a side code pane (IN the same browser window) to remember to write/update the current method test. It is more an usability issue. HernÃ¡n

Oct. 9, 2019

Re: [Pharo-users] [cormas-dev] OpenPonk ported to Pharo 7

by HernÃ¡n Morales Durand

s/ported/loadable/g Guys, you may help me on this one: I suspect some classes in OpenPonk-Spec-Commands are breaking Calypso in Pharo 7 at some point on usage (not really sure, but I need to discard possibilities). Do you know any way to specify conditional loading in a Baseline method? I want to load all OpenPonk-Spec categories except OpenPonk-Spec-Commands. Cheers, HernÃ¡n El mar., 8 oct. 2019 a las 11:03, HernÃ¡n Morales Durand (< hernan.morales(a)gmail.com>) escribiÃ³: > Hi Serge, > > Noy yet sadly, what I did was to make the changes to make OpenPonk just > loadable in Pharo 7. Besides additional needed OpenPonk porting tasks, now > I have to check why Calypso gets broken (unusable) and I have to compile > some methods by hand, for example: > > ClySwitchMethodViewModeCommand compile: 'isAppliedToBrowser > > ^browser methodGroupView showsItemsOfType: self methodGroupType' > > Also it seems Pharo 7 no longer includes a fallback Browser to solve this > type of problems... > Cheers, > > HernÃ¡n > > > > El mar., 8 oct. 2019 a las 5:12, Serge Stinckwich (< > serge.stinckwich(a)gmail.com>) escribiÃ³: > >> >> >> On Tue, Oct 8, 2019 at 4:57 AM HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> Hi guys!! >>> >>> Glad to write to you again. >>> >> >> Hi Hernan, >> >> thank you for your commitment. >> >>> It took me some days but now I've had a loadable OpenPonk in Pharo 7 :) >>> >>> " In case of empty Warning windows appearing you can uncomment:" >>> " Smalltalk tools debugger alwaysOpenFullDebugger: true. " >>> [ Metacello new >>> baseline: 'OpenPonk'; >>> repository: 'github://hernanmd/OpenPonk/repository'; >>> load ] >>> on: IceGenericError >>> do: [ : ex | ex retry ]. >>> >>> >> You mean OpenPonk is usable in Pharo 7 ? >> I will give a try. >> Regards, >> -- >> Serge Stinckwic >> h >> >> Int. Research Unit >> on Modelling/Simulation of Complex Systems (UMMISCO) >> Sorbonne University >> (SU) >> French National Research Institute for Sustainable Development (IRD) >> U >> niversity of YaoundÃ© I, Cameroon >> "Programs must be written for people to read, and only incidentally for >> machines to execute." >> https://twitter.com/SergeStinckwich >> >> -- >> You received this message because you are subscribed to the Google Groups >> "cormas-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to cormas-dev+unsubscribe(a)googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/cormas-dev/CAOysuxU92FFtx0i4Og-ak%3DQ3D%2… >> <https://groups.google.com/d/msgid/cormas-dev/CAOysuxU92FFtx0i4Og-ak%3DQ3D%2…> >> . >> >

Oct. 9, 2019

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

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

Oct. 9, 2019

Number to VT_DECIMAL

by eftomi

Hi, I'm preparing a method to write a given Pharo's numerical value into an external variant of type VT_DECIMAL. The purpose of this type is to retain accuracy, it uses 12 bytes for "mantissa" and two bytes for a sign and a scale (i. e. the position of decimal point). What would be the best approach for the conversion, taken all the possible subclasses of class Number, that is a Float, a Fraction and the Integers, and to keep the accuracy at the same level? For instance, Fraction's numerator and denominator could be directly imputed into VT_DECIMAL's value and scale if denominator is a power of 10. What to do in other cases? A nice description of VT_DECIMAL is here <https://bytecomb.com/vba-internals-decimal-variables-and-pointers-in-depth/> . Best wishes, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 8, 2019

keyboard shortcut for switching from "instance side" to "class side"

by Steve Quezadas

Does anyone know of a keyboard shortcut in pharo that switches from the method selectors in the "class side" to the "instance side"? I can't seem to find anything by browsing google. Ctrl-h seems to be an undocumented keystroke command to switch to "heirchy list" when the object in the browser is selected. So I would imagine there would also be something to switch to the class side/instance side. - Steve

Oct. 8, 2019