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

Falsehoods programmers believe about Smalltalk

by HernÃ¡n Morales Durand

Hi there, I just created a GitHub repo to collect myths around Smalltalk-based technologies: Pharo, Squeak, VW, VAST, Smalltalk/X, GNU/ST, etc. in the spirit of the Falsehoods lists [1-4]. This is just a draft now but please feel free to add falsehoods based on your own experiences. Examples are greatly appreciated. https://github.com/hernanmd/falsehoods_smalltalk Cheers, HernÃ¡n [1] https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-ab… [2] https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/false… [3] https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md [4] https://meta-package-manager.readthedocs.io/en/develop/falsehoods.html

Jan. 20, 2019

Re: [Pharo-users] Transforming objects

by Richard O'Keefe

I note that #become: is not in the ANSI Smalltalk standard (am I the last person in the world to care about that? Probably) and that several of the Smalltalk systems I have on my machine don't support it. In Squeak 5.2, there were 17 references to #become:. Four of those were just testing it. One is just a mention in a collection of dangerous things to not be tried. Several are ways of changing an object's class. Several are ways of forcibly deleting an object by turning it into something trivial but safe. And a couple, I don't understand. Thing is, #become: is *not* something to do lightly, and the code that calls "x become: y" should "own" both x and y. (In fact one of them is often "self".) About The Design Patterns Smalltalk Companion, draft chapters are available at http://sdmeta.gforge.inria.fr/FreeBooks/SmalltalkDesignPatternCompanion/ When I read the Gang of Four book, it seemed to me that most of it was about fighting the fact that C++ and Java aren't Smalltalk. Read a draft chapter or two to make up your own mind. One difference between the State pattern and #become: is that an object can be an instance of the State pattern in more than one way at the same time. On Thu, 17 Jan 2019 at 05:58, Ben Coman via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > > > On Wed, 16 Jan 2019 at 17:16, LoÃ¯c PagÃ¨s <loic.pages(a)inra.fr> wrote: > >> Dear Pharo users, >> >> I develop software dedicated to the simulation of plant development and >> 3D architecture. >> >> In the past, I used Java, > > but I am very interested in translating code >> in Pharo. I appreciated very much the language and the course. >> >> I have a question for you all : >> >> During plant development (ontogeny), new organs appear, that are >> gradually tranformed. For example, a bud can make a flower, and then a >> fruit. >> >> Organs are conveniently modelled as classes. During the course, I >> learned that it was better to make several classes (bud, flower, fruit) >> instead of a "fat class" such as "reproductive organ" with many >> attributes and stages (bud stage, flower stage, fruit stage). I wonder >> how to transform an object into another one, to represent for example >> the fact that the flower may become a fruit. >> >> Maybe a naive question ? >> > > Maybe #become: ... > https://gbracha.blogspot.com/2009/07/miracle-of-become.html > > but it might be a misuse for your purpose. The following book will > provide some good insights... > https://www.amazon.com/Design-Patterns-Smalltalk-Companion/dp/0201184621 > > cheers -ben > > > >

Jan. 20, 2019

Re: [Pharo-users] Limits of ZnManagingMultiThreadedServer

by Stephan Eggermont

Ah, found another consumer of sockets :). For reliable systems, putting limits on the number of retries seems a useful idea. Thanks Sven, Stephan

Jan. 18, 2019

[ Save The Date ] Pharo Days 2019: Thursday April 4 & Friday April 5 @ Lille, FR

by Sven Van Caekenberghe

[ Save The Date ] Pharo Days 2019: Thursday April 4 & Friday April 5 @ Lille, FR Dear members of the Pharo community, We are happy to announce that we will be organising Pharo Days this year, in Lille, France. This will be a two day event: Thursday April 4 & Friday April 5. The main venue will be the Amphitheatre of INRIA Lille - Nord Europe. Each day will consist of a number of short 20 to 30 minutes tech talks in the morning, with a more free format in the afternoon: general hacking space, pair programming, demos, side meetings, tutorials, coding sprints, Q&A's, shows us your projects - real life human interaction. Of course, there will be social events as well. Please join us to make this another successful edition, after Annecy (FR) 2011, Lille 2012, Bern (CH) & Lille 2013, Lille 2015, Namur (BE) 2016 and Lille 2017. Mark your calendars, we will provide more details when they become available. The Pharo Board, Association & Consortium http://pharo.org http://association.pharo.org http://consortium.pharo.org

Jan. 18, 2019

Re: Limits of ZnManagingMultiThreadedServer

by Stephan Eggermont

Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am not sure I understand correctly: does the error occur on the client > or server side (assuming they are both written in Pharo using Zinc HTTP Components). First Pharo server side, and afterwards of course the clients complain that they cannot connect to the server. Everything is Pharo. And running perhaps a bit too close to the machine capacity. At least memory wise > Because 'CreateThread() failed (1450) - Insufficient system resources > exist to complete the requested service' does not sound like a Pharo error. Itâs a vm error I suppose. Opening the output console > In any case, ZnEasy class>>#get: uses #beOneShot so that the client side > connection is closed after 1 request, it also uses the Connection:close > header so that the server knows it does not have to keep the connection open. Ok. Do I understand correctly that the server does not forcibly releases the connection and thread after a timeout, but continues waiting? > Server side, Zn should also clean up nicely (even for dirty requests). > But is also depends on what you do inside your server side request > handler. Maybe something prevents normal GC to clean up ? That is lightweight, telling the clients which tests to run and collecting the results > Although Pharo processes are like green threads (not OS threads) you can > technically use too many. Typically you will run out of sockets for IO. > Unless you have a a real leak, it might be a GC configuration problem: a > little used server might not invoke enough real/full GC cycles. So when running out of sockets, no GC is triggered? > In any case, I have many images with long running HTTP servers and > clients and I don't have any issues. How many requests are we talking > about, how many concurrent users, how long before things go wrong ? I havenât instrumented it yet, but after several hours. And the machine is pushed to its limits. Stephan

Jan. 18, 2019

Re: [Pharo-users] Limits of ZnManagingMultiThreadedServer

by Sven Van Caekenberghe

Hi Stephan, > On 18 Jan 2019, at 14:03, Stephan Eggermont via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Stephan Eggermont <stephan(a)stack.nl> > Subject: Limits of ZnManagingMultiThreadedServer > Date: 18 January 2019 at 14:03:43 GMT+1 > To: pharo-users(a)lists.pharo.org > > > I have a few images connecting regularly to a server using ZnEasy get: on > windows 64 bit and a recent vm and Pharo 7 image. At a certain point, the > server stops with âCreateThread() failed (1450) - Insufficient system > resources exist to complete the requested service. > > I probably should switch to keeping connections open and avoid this > problem, but it made me wonder about the limitations I should expect here. > What are the limits here and can I change them? > > Stephan I am not sure I understand correctly: does the error occur on the client or server side (assuming they are both written in Pharo using Zinc HTTP Components). Because 'CreateThread() failed (1450) - Insufficient system resources exist to complete the requested service' does not sound like a Pharo error. In any case, ZnEasy class>>#get: uses #beOneShot so that the client side connection is closed after 1 request, it also uses the Connection:close header so that the server knows it does not have to keep the connection open. Server side, Zn should also clean up nicely (even for dirty requests). But is also depends on what you do inside your server side request handler. Maybe something prevents normal GC to clean up ? Although Pharo processes are like green threads (not OS threads) you can technically use too many. Typically you will run out of sockets for IO. Unless you have a a real leak, it might be a GC configuration problem: a little used server might not invoke enough real/full GC cycles. In any case, I have many images with long running HTTP servers and clients and I don't have any issues. How many requests are we talking about, how many concurrent users, how long before things go wrong ? Sven

Jan. 18, 2019

Limits of ZnManagingMultiThreadedServer

by Stephan Eggermont

I have a few images connecting regularly to a server using ZnEasy get: on windows 64 bit and a recent vm and Pharo 7 image. At a certain point, the server stops with âCreateThread() failed (1450) - Insufficient system resources exist to complete the requested service. I probably should switch to keeping connections open and avoid this problem, but it made me wonder about the limitations I should expect here. What are the limits here and can I change them? Stephan

Jan. 18, 2019

Re: [Pharo-users] Transforming objects

by Offray Vladimir Luna CÃ¡rdenas

Hi, I would use an ad-hoc solution, modeling the Plant tree structure as a document tree in Grafoscopio [1]. The root of the plant representation would be the root of the document, the branches and sub-branches would be nodes and sub-nodes in the documents, respectively. And each node would contain a dictionary with the properties I want to reflect for that particular node. The header of the node would be a shortcut to the more detailed representation in the node body (the dictionary). Because Grafoscopio notebooks are just plain STON text, you could store plants history on a DVCS (Fossil, Git) and reify that ad-hoc model with methods that capture what started just as dictionaries. [1] http://mutabit.com/grafoscopio/index.en.html Notice that Grafoscopio documents are programmable, so, while Grafoscopio provides a GUI for editing them, you could access the API and create them by scripting/coding. Also the long, painful, joyful Karma of my PhDÂ is finishing with only public dissertation pending, so I will have more time to care for Grafoscopio source code and issues (hopefully I will send some updates, once the deserved quiet time after intense thesis writing have finished). Cheers, Offray On 16/1/19 4:15, LoÃ¯c PagÃ¨s wrote: > Dear Pharo users, > > I develop software dedicated to the simulation of plant development > and 3D architecture. > > In the past, I used Java, but I am very interested in translating code > in Pharo. I appreciated very much the language and the course. > > I have a question for you all : > > During plant development (ontogeny), new organs appear, that are > gradually tranformed. For example, a bud can make a flower, and then a > fruit. > > Organs are conveniently modelled as classes. During the course, I > learned that it was better to make several classes (bud, flower, > fruit) instead of a "fat class" such as "reproductive organ" with many > attributes and stages (bud stage, flower stage, fruit stage). I wonder > how to transform an object into another one, to represent for example > the fact that the flower may become a fruit. > > Maybe a naive question ? > > Thanks for your lights ! > > LoÃ¯c > > > >

Jan. 17, 2019

Smalltalks 2018 videos are live

by Gabriel Cotelli

Hi, We finished uploading all the videos of the conference. You can get the links and related info here <https://smalltalks2018.fast.org.ar/talks>. Regards, Gabriel in name of FAST

Jan. 16, 2019

Re: [Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

by Sven Van Caekenberghe

Great, thanks for sharing this. > On 16 Jan 2019, at 20:35, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > GemTalkSystems is pleased to announce SETT (Store Export to Tonel Tools)[1]. SETT is open source project with an MIT license. > > SETT (Store Export to Tonel Tools) is a set of tools to export Smalltalk code from Store and > write into the Tonel file format managed using Git. > > SETT is: > > â¢ a Pharo 6.1 application, that > â¢ connects to a Postgres Database > â¢ containing source code history in VisualWorks Store format; and > â¢ writes to a Git repository > â¢ in Tonel format > â¢ maintaining all version history, source code and SCM metadata. > > SETT was developed last year to support one of our commercial customers in their conversion From Store to Rowan[2]. Rowan artifacts are produced as part of the output of SETT, but the Rowan artifacts can be ignored. The important bit is that SETT converts from Store to Tonel and maintains version history in git. > > Please see the project ReadMe[3] and Wiki[4] for additional details. > > Dale > > [1] https://github.com/GemTalk/SETT > [2] https://github.com/GemTalk/Rowan > [3] https://github.com/GemTalk/SETT#overview > [4] https://github.com/GemTalk/SETT/wiki > >

Jan. 16, 2019