- Pharo-users - lists.pharo.org

[ANN] Embedding Image Example (Win)

by tesonep＠gmail.com

Hi, I have produced an example of using the headless VM to have an embedded image in Windows. The example is hosted in Github (https://github.com/tesonep/pharo-vm-embedded-example) The example is a CMake project to generate a new small executable that uses the VM as a library. Also, it shows how to perform the branding of applications (I have used the same Pharo icon, but we can use anything else). In the example, I am opening one of the SDL2 examples, it opens a window where we can draw in an Athens Canvas. It requires a Cygwin environment, but if you are able to build the headless VM you already have it!. I will do other examples of the use case we are thinking for the headless VM! Cheers, Pablo -- Pablo Tesone. tesonep(a)gmail.com

Jan. 13, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by Richard O'Keefe

I wonder how many people in this thread have VisualWorks and/or VisualAge on their machine as well as Pharo? They haven't pushed the user interface the way Squeak and Pharo have, and I personally find the VisualAge interface to be unpleasant. But they both offer a ton of support for connecting to other things. Let's take this list: - lots of good communication libraries into it yes and yes - spread it over Windows, Mac and Linux, yes and yes - make it open source VW and VA are proprietary, but you can get free versions (if you think I can afford to pay for stuff you are sadly mistaken) with all the usual access to the sources. - put some XML and JSON yes and yes - and solve printing, not quite clear, but I think the answer is yes and yes - multithreading/multiprocessing (framework) runtime AND (!) debugging, VW has recently made a lot of progress in that area - scripting it is not clear what you want here. - interconnections with other languages. yes and yes. C, and VA also talks to COBOL nicely. - Try adding a modelling and source code generator VW: very much so. VA: I have a lot of exploring to do yet, but I think so. - Build the whole stuff with concurrency in mind - offer specific data structure to help you here. Not clear what you want here. Smalltalk has had threads since at least 1980. If you built the whole stuff with concurrency in mind, you would not end up with Smalltalk, you'd get Erlang/Elixir. My Smalltalk has concurrent stacks, sets, bags, and dictionaries, and 'aCollection par collect:/select:/inject:into:/...' - Look for suitable persistency options. VW and VA both support serialisation. Pharo of course has Fuel. The big thing that VW and VA offer that Pharo does not -- for obvious reasons -- is stability, with the quantity of documentation that stability makes possible. On Sat, 11 Jan 2020 at 05:15, Marten Feldtmann <itlists(a)schrievkrom.de> wrote: > > Am 10.01.20 um 15:42 schrieb horrido: > > > > >> So let's stop trying to convince people with things that mattered some > >> 20 years ago. Even the function point thingie we keep carrying in front > >> of our bellies (Capers-Jones was it?) is a lie when you want to build an > >> application for today's markets. > > > > I disagree that it's a lie. The study is based on thousands of projects and > > millions of lines of code over a period of several decades, including recent > > Well, naming it a "lie" is perhaps too strong - but Joachim (did you > have a bad Smalltalk day ?????) statement is from my point of view > correct - this talking about function point and productivity is an > academic point. > > If I am a Java developer and my productivity is around 10% compared to > Smalltalk developer it is still useful to use Java - because for my > problem there might exists already dozen of libraries and solutions. > > Using Smalltalk today is matter of personal taste and love - like many > other developers in other languages. > > Joachim mentioned the critical points and for me perhaps the following > statements are true: > > * Smalltalk development over the last decade ran in circles > > and due to that > > * Smalltalk is not solving the biggest problems any more > > So many time has been wasted to make a Smalltalk dialect running in a > browser. > > I would use (my loved) Smalltalk today only, if > > * I have an application, which was written in Smalltalk (and I have one) > > * Smalltalk is superior to other solutions in a specific topic (and with > Gemstone I have one topic) > > When I would start from scratch ... build a headless Smalltalk, put lots > of good communication libraries into it, spread it over Windows, Mac and > Linux, make it open source and put some XML and JSON and solve printing, > multithreading/multiprocessing (framework) runtime AND (!) debugging, > scripting, interconnections with other languages. Try adding a modelling > and source code generator. Build the whole stuff with concurrency in > mind - offer specific data structure to help you here. Look for suitable > persistency options. > > Go back to the time, where Smalltalk source code was hold in a > repository to manually work with it and and not getting software via > Github with some broken relationships between packages and nobody knows why. > > Use the browser (with Javascript) as the main UI and build a superior > interface in Javascript to the backend Smalltalk. Use the Electron > framework and build some specific support for Smalltalk into that. > > But even with that in mind you will not catch the Javascript developers > (because they are on that way already and they do not need Smalltalk), > but you may survive as a Smalltalk developer. > > Spread the word around, that multi-language development is a MUST and > one should support it. > > So, to summarize - this is my personal view of Smalltalk today - since > 1986, where I first met Georg Heeg on a Atari fair in DÃ¼sseldorf seeing > the first Smalltalk system in my life. > > Marten > > > > > -- > Marten Feldtmann >

Jan. 13, 2020

Re: [Pharo-users] Floating point arithmetic

by Sven Van Caekenberghe

> On 13 Jan 2020, at 00:28, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Whats wrong with #roundedTo: ? > > > If you actually need it calculated to 8 significant digits then you can use > scaled decimals e.g. > > (0.09560268 asScaledDecimal - 0.005 asScaledDecimal) The weird thing is though, that is still does not behave 100% as one would expect (i.e. it does not seem exact). 0.09560268 asScaledDecimal - 0.005 asScaledDecimal. "0.09060268s8" 0.09560268 asScaledDecimal - 0.005 asScaledDecimal = 0.09060268 asScaledDecimal. "false" 0.09560268 asScaledDecimal - 0.005 asScaledDecimal = 0.09060268s8. "false" The internal fractions are not the same ... While (9560268 / 1e8) - (5 / 1e3) = (9060268 / 1e8). "true" So, is the equality test of ScaledDecimal correct ? > see https://0.30000000000000004.com for more about why floating point math > does this sometimes > > > > > > Donald Howard wrote >> Hello everyone, >> >> This is an issue I've had awareness of going way back but it's the first >> time I've had to personally deal with it. I've done some research and >> found it addressed in a number of ways but given current time pressures >> and >> a huge list of to-dos, I thought I'd turn to the community for rapid >> advice >> to get me over the hump. The circumstances are summarized below in code >> and comments suitable for a playground. >> >> "This is the actual arithmetic I want to do... >> 0.09560268 - 0.005 = 0.09060268" >> >> "Evaluate this in a playground and you'll see this is what >> floating point arithmetic produces --the first two are wrong, every one >> after is correct" >> 0.09560268 - 0.005 "=> 0.09060267999999999". >> 0.0956026 - 0.005 "=> 0.09060259999999999". >> 0.095602 - 0.005 "=> 0.090602". >> 0.09560 - 0.005 "=> 0.0906". >> 0.0956 - 0.005 "=> 0.0906". >> 0.095 - 0.005 "=> 0.09". >> >> "This workaround works" >> 0.09560268 - 0.005 roundTo: 0.00000001 "=> 0.09060268". >> "but one has to compute number of digits of precision >> and according to study above, it's not necessary at >> precisions >= 0.000001" >> >> "What are other suggestions, workarounds or approaches community has?" >> "THANKS!" >> >> >> Don Howard >> >> <https://objectguild.com> >> *Founding Member* > >> dhoward@ > >> +31653139744 >> (US) 651-253-7024 > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 13, 2020

Re: [Pharo-users] Floating point arithmetic

by Ben Coman

On Mon, 13 Jan 2020 at 19:42, Richard O'Keefe <raoknz(a)gmail.com> wrote: > You say that the first two results are wrong. > No. The first two results are *exactly* what they are supposed to be. > Floating point arithmetic is NOT mathematical real arithmetic. > The floating point *numbers* are exact rational numbers of the form > n * 2^k where n is a (bounded) integer and k is a (bounded) integer. > If you enter a number that is not of this form (and within bounds) > you will get a *different* number that *is* of that form and is close. > The floating point *operations* in IEEE arithmetic are exact > when and only when the result is a number of that form (and within > bounds), otherwise the result is *approximate*. > > If you want exact arithmetic on numbers of the form n * 10^k, > ANSI Smalltalk provides the ScaledDecimal class, which, sigh, > How could this be improved? > Squeak and Pharo interpret as "rational number *printed* in > decimal form but not *computed* using decimal arithmetic" > I'm interested to understand what is the benefit of doing it this way. Anyone know history of it? cheers -ben , so > that can give extremely confusing results too. > > So what you are going to have to do is use rational numbers, > which are in Smalltalk the union of Integer and Fraction. > > > On Mon, 13 Jan 2020 at 09:13, Donald Howard <dhoward(a)objectguild.com> > wrote: > >> Hello everyone, >> >> This is an issue I've had awareness of going way back but it's the first >> time I've had to personally deal with it. I've done some research and >> found it addressed in a number of ways but given current time pressures and >> a huge list of to-dos, I thought I'd turn to the community for rapid advice >> to get me over the hump. The circumstances are summarized below in code >> and comments suitable for a playground. >> >> "This is the actual arithmetic I want to do... >> 0.09560268 - 0.005 = 0.09060268" >> >> "Evaluate this in a playground and you'll see this is what >> floating point arithmetic produces --the first two are wrong, every one >> after is correct" >> 0.09560268 - 0.005 "=> 0.09060267999999999". >> 0.0956026 - 0.005 "=> 0.09060259999999999". >> 0.095602 - 0.005 "=> 0.090602". >> 0.09560 - 0.005 "=> 0.0906". >> 0.0956 - 0.005 "=> 0.0906". >> 0.095 - 0.005 "=> 0.09". >> >> "This workaround works" >> 0.09560268 - 0.005 roundTo: 0.00000001 "=> 0.09060268". >> "but one has to compute number of digits of precision >> and according to study above, it's not necessary at >> precisions >= 0.000001" >> >> "What are other suggestions, workarounds or approaches community has?" >> "THANKS!" >> >> >> Don Howard >> >> <https://objectguild.com> >> *Founding Member* >> dhoward(a)objectguild.com >> +31653139744 >> (US) 651-253-7024 >> >

Jan. 13, 2020

Re: [Pharo-users] As promised, the sequel!

by xap

Richard, another entertaining smalltalk read; thx :) If when you wrote the prequel you hadn't already meant to follow up w/ the e-car parallel, perhaps refer to this mailing list and attendant discussion and tbrunz' specific comments here: http://forum.world.st/Smalltalk-It-s-Not-Your-Grandfather-s-Programming-Lan… ? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 13, 2020

Re: [Pharo-users] Floating point arithmetic

by Richard O'Keefe

You say that the first two results are wrong. No. The first two results are *exactly* what they are supposed to be. Floating point arithmetic is NOT mathematical real arithmetic. The floating point *numbers* are exact rational numbers of the form n * 2^k where n is a (bounded) integer and k is a (bounded) integer. If you enter a number that is not of this form (and within bounds) you will get a *different* number that *is* of that form and is close. The floating point *operations* in IEEE arithmetic are exact when and only when the result is a number of that form (and within bounds), otherwise the result is *approximate*. If you want exact arithmetic on numbers of the form n * 10^k, ANSI Smalltalk provides the ScaledDecimal class, which, sigh, Squeak and Pharo interpret as "rational number *printed* in decimal form but not *computed* using decimal arithmetic", so that can give extremely confusing results too. So what you are going to have to do is use rational numbers, which are in Smalltalk the union of Integer and Fraction. On Mon, 13 Jan 2020 at 09:13, Donald Howard <dhoward(a)objectguild.com> wrote: > Hello everyone, > > This is an issue I've had awareness of going way back but it's the first > time I've had to personally deal with it. I've done some research and > found it addressed in a number of ways but given current time pressures and > a huge list of to-dos, I thought I'd turn to the community for rapid advice > to get me over the hump. The circumstances are summarized below in code > and comments suitable for a playground. > > "This is the actual arithmetic I want to do... > 0.09560268 - 0.005 = 0.09060268" > > "Evaluate this in a playground and you'll see this is what > floating point arithmetic produces --the first two are wrong, every one > after is correct" > 0.09560268 - 0.005 "=> 0.09060267999999999". > 0.0956026 - 0.005 "=> 0.09060259999999999". > 0.095602 - 0.005 "=> 0.090602". > 0.09560 - 0.005 "=> 0.0906". > 0.0956 - 0.005 "=> 0.0906". > 0.095 - 0.005 "=> 0.09". > > "This workaround works" > 0.09560268 - 0.005 roundTo: 0.00000001 "=> 0.09060268". > "but one has to compute number of digits of precision > and according to study above, it's not necessary at > precisions >= 0.000001" > > "What are other suggestions, workarounds or approaches community has?" > "THANKS!" > > > Don Howard > > <https://objectguild.com> > *Founding Member* > dhoward(a)objectguild.com > +31653139744 > (US) 651-253-7024 >

Jan. 13, 2020

Re: [Pharo-users] Floating point arithmetic

by Konrad Hinsen

On 12/01/2020 21:13, Donald Howard wrote: > "Evaluate this in a playground and you'll see this is what > Â floating point arithmetic produces --the first two are wrong, every > one after is correct" > 0.09560268 - 0.005 "=> 0.09060267999999999". > 0.0956026 - 0.005 Â "=> 0.09060259999999999". > 0.095602 - 0.005 Â "=> 0.090602". Wrong in what sense? I am rather sure that the computation is done correctly, meaning that it follows the rules defined by IEEE standard 754. I am also relatively sure (meaning a bit less) that the conversion of the binary result to a decimal output string is correct, in the sense that it applies today's preferred practice of ensuring round-trip equality. So you probably mean that the result is no what you expected. The main point to be clear about is if you care about the binary value or about its decimal representation as a string. If you need the internal value to be exact, you have to switch to something other than binary floats - scaled decimals might work for you. If you only want nice-looking outputs, you can probably get what you want using roundTo: applied to the result. Cheers, Konrad.

Jan. 13, 2020

As promised, the sequel!

by Richard Kenneth Eng

https://levelup.gitconnected.com/how-is-smalltalks-revival-like-the-e-car-s…

Jan. 13, 2020

Re: [Pharo-users] Floating point arithmetic

by Paul DeBruicker

Whats wrong with #roundedTo: ? If you actually need it calculated to 8 significant digits then you can use scaled decimals e.g. (0.09560268 asScaledDecimal - 0.005 asScaledDecimal) see https://0.30000000000000004.com for more about why floating point math does this sometimes Donald Howard wrote > Hello everyone, > > This is an issue I've had awareness of going way back but it's the first > time I've had to personally deal with it. I've done some research and > found it addressed in a number of ways but given current time pressures > and > a huge list of to-dos, I thought I'd turn to the community for rapid > advice > to get me over the hump. The circumstances are summarized below in code > and comments suitable for a playground. > > "This is the actual arithmetic I want to do... > 0.09560268 - 0.005 = 0.09060268" > > "Evaluate this in a playground and you'll see this is what > floating point arithmetic produces --the first two are wrong, every one > after is correct" > 0.09560268 - 0.005 "=> 0.09060267999999999". > 0.0956026 - 0.005 "=> 0.09060259999999999". > 0.095602 - 0.005 "=> 0.090602". > 0.09560 - 0.005 "=> 0.0906". > 0.0956 - 0.005 "=> 0.0906". > 0.095 - 0.005 "=> 0.09". > > "This workaround works" > 0.09560268 - 0.005 roundTo: 0.00000001 "=> 0.09060268". > "but one has to compute number of digits of precision > and according to study above, it's not necessary at > precisions >= 0.000001" > > "What are other suggestions, workarounds or approaches community has?" > "THANKS!" > > > Don Howard > > <https://objectguild.com> > *Founding Member* > dhoward@ > +31653139744 > (US) 651-253-7024 -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 12, 2020

Floating point arithmetic

by Donald Howard

Hello everyone, This is an issue I've had awareness of going way back but it's the first time I've had to personally deal with it. I've done some research and found it addressed in a number of ways but given current time pressures and a huge list of to-dos, I thought I'd turn to the community for rapid advice to get me over the hump. The circumstances are summarized below in code and comments suitable for a playground. "This is the actual arithmetic I want to do... 0.09560268 - 0.005 = 0.09060268" "Evaluate this in a playground and you'll see this is what floating point arithmetic produces --the first two are wrong, every one after is correct" 0.09560268 - 0.005 "=> 0.09060267999999999". 0.0956026 - 0.005 "=> 0.09060259999999999". 0.095602 - 0.005 "=> 0.090602". 0.09560 - 0.005 "=> 0.0906". 0.0956 - 0.005 "=> 0.0906". 0.095 - 0.005 "=> 0.09". "This workaround works" 0.09560268 - 0.005 roundTo: 0.00000001 "=> 0.09060268". "but one has to compute number of digits of precision and according to study above, it's not necessary at precisions >= 0.000001" "What are other suggestions, workarounds or approaches community has?" "THANKS!" Don Howard <https://objectguild.com> *Founding Member* dhoward(a)objectguild.com +31653139744 (US) 651-253-7024

Jan. 12, 2020