January 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Floating point arithmetic

by Pierce Ng

On Tue, Jan 14, 2020 at 12:41:51AM +1300, Richard O'Keefe wrote: > 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. Can you expand on this please? For money-related calculations I have been using HernÃ¡n Morales Durand's FixedDecimal: https://github.com/hernanmd/FixedDecimal. Pierce

Jan. 14, 2020

Re: [Pharo-users] Floating point arithmetic

by Pierce Ng

On Sun, Jan 12, 2020 at 02:13:00PM -0600, Donald Howard wrote: > "What are other suggestions, workarounds or approaches community has?" This is a good read on the subject: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html Title is "What every computer scientist should know about floating point arithmetic". Pierce

Jan. 14, 2020

Re: [Pharo-users] Grafoscopio accepted at FOSDEM :-)... Now looking for travel funds :-/

by Offray Vladimir Luna CÃ¡rdenas

Hi again, FOSDEM is approaching and I don't think I will get an sponsor in such brevity. Santiago, Phill, are you willing to take care of this talk? I can coach and support you, if needed. The details about the proposal are here: https://fosdem.org/2020/schedule/event/open_research_pocket_infrastructures/ Cheers, Offray On 19/12/19 4:30 p.Â m., Offray Vladimir Luna CÃ¡rdenas wrote: > Hi, > > The subject pretty much resumes the current situation: organizers at > FOSDEM[1] approved my talk about Grafoscopio for the 2020 version (Feb 1 > and 2). They tell me that they don't provide travel funds, but because I > spoke about the voluntary and self funded nature of the project and > asked for travel funds, the usual route here is trying to find an > entity, located in Brussels that would be interested in some workshops > about the tool and that will cover travel expenses. Ideally such entity > would be related with the subjects and themes we have been working with > the Grafoscopio community: civic tech, hacktivism, reproducible > research, data journalism, data feminism, critical science and > technology studies, open data, collective writing self publishing and > book sprints. > > As you can see, Grafoscopio and its community are pretty versatile and > diverse in their concerns and approaches, so I hope that opens > possibilities for a lot of interested sponsors, located in Brussels. > Even sponsors in Europe could work, as internal travel is kind of cheap > and the biggest part of the expenses are inter continental travel. I > don't know of any particular European entity that could sponsor my > travel funds for FOSDEM, but hopefully the European pharoers know of > some. The FOSDEM organizers asked me for some possible entities so, I'm > all ears :-) > > Santiago and Phill, any particular ideas? If not, remember that we can > prepare a remote talk :-) > > [1] https://fosdem.org/2020/ > > Thanks, > > Offray > > >

Jan. 14, 2020

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

by tbrunz

Thanks, xap! Great sequel, Richard. I really like the lead image, too. (Red was a good choice.) This makes me wonder what other technology turn-arounds and revivals exist in history... ;^) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 13, 2020

Re: [Pharo-users] [ANN] Embedding Image Example (Win)

by ducasse

this is really nice. This is with such nice example that people will be able to build App with Pharo. Thanks Pablo I like C code with nice comments :). > On 13 Jan 2020, at 14:32, tesonep(a)gmail.com wrote: > > Hi,

Jan. 13, 2020

Re: [Pharo-users] [Pharo-dev] [ANN] Embedding Image Example (Win)

by Ben Coman

Thanks Pablo. This will be cool to try sometime, and likely useful if I want to distribute an app. Now what woudl be great is an example something like embedding the VM within a simple REPL written in C. or something like a simple Pong game where the main loop is in C and does the rendering, but the game logic run in Pharo. cheers -ben On Mon, 13 Jan 2020 at 21:34, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > 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] Floating point arithmetic

by Sven Van Caekenberghe

Ah, yes, yes, sending #asScaledDecimal to a Float is too late, the precision is already lost. It makes total sense now. Thank you, Werner, for the explanation. > On 13 Jan 2020, at 16:13, werner kassens <wkassens(a)libello.com> wrote: > > Hi Sven, > > if you dont transform floats, that are not always exactly what they seem > to be, you get what you would expect: > 0.09560268s8 - 0.005s8 = 0.09060268s8. "true" > "of course" > a:=0.09560268 asScaledDecimal. > 0.09560268s8=a . "false" > "you could eg do this:" > b:=a roundTo: 0.00000001s8. > "then" > 0.09560268s8=b . "true" > > but if you do something like this generally in Float>>asScaledDecimal > you could loose some precision that could be unwanted in some other > circumstances (or perhaps not). > > werner > > On 1/13/20 2:13 PM, Sven Van Caekenberghe wrote: >> 0.09560268 asScaledDecimal - 0.005 asScaledDecimal = 0.09060268s8. "false" >

Jan. 13, 2020

Re: [Pharo-users] Floating point arithmetic

by werner kassens

Hi Sven, if you dont transform floats, that are not always exactly what they seem to be, you get what you would expect: 0.09560268s8 - 0.005s8 = 0.09060268s8. "true" "of course" a:=0.09560268 asScaledDecimal. 0.09560268s8=a . "false" "you could eg do this:" b:=a roundTo: 0.00000001s8. "then" 0.09560268s8=b . "true" but if you do something like this generally in Float>>asScaledDecimal you could loose some precision that could be unwanted in some other circumstances (or perhaps not). werner On 1/13/20 2:13 PM, Sven Van Caekenberghe wrote: > 0.09560268 asScaledDecimal - 0.005 asScaledDecimal = 0.09060268s8. "false"

Jan. 13, 2020

[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