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

Territorial loading problems & alternative ways of loading data for making a choropleth map

by Offray Vladimir Luna CÃ¡rdenas

Hi, I would like a choropleth map of Colombian departments [1]. The first approach would be to use Territorial, but loading it is not working on Pharo 6.1 (used on Manjaro Linux): It doesn't appears in the Catalog, Gopher load gives me: "XMLFileException: File does does not exist: /home/offray/Programas/Pharo/6.1a/Dev24/territorial_files/fao/fao_country_names.xml" and loading Monticello bleeding edge gives me "FileDoesNotExist: File @ /home/offray/Programas/Pharo/6.1a/Dev24/territorial_files/opengeocode/wc-ASCII.csv". There is another way to make such choropleth map? [1] https://en.wikipedia.org/wiki/Departments_of_Colombia Thanks, Offray

Oct. 24, 2017

Re: [Pharo-users] [Seaside] [ANN] SeasideTesting recovered from oblivion

by Johan Brichau

I donât know... we maintained SeasideTesting at http://smalltalkhub.com/#!/~Seaside/SeasideTesting/ until we developed Parasol because it just covers some bare-bones html page testing. Forget about JavaScript and css influence on your tests in seaside testing. I think we prefer a slower but accurate testing proces, using Parasol. Johan > On 23 Oct 2017, at 22:22, Jon Paynter <kittle31(a)gmail.com> wrote: > > Great to hear! > > I use this on some older projects, and found the documentation helpful, but also sketchy. Hopefully you can update things. > > Will your resurected version work with Visualworks? > >> On Mon, Oct 23, 2017 at 3:04 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Hi, >> >> I spend some days last week woking with the guys of AFI (http://afi-sa.fr, yes they also use Pharo in some of their projects) and together we recovered SeasideTesting from Davis Shaffer to be used for their TDD experience. >> >> you can check it out here: https://github.com/Afibre/SeasideTesting >> >> Whatâs SeasideTesting? A package to test Seaside components. >> Why we do not use Parasol? Because it is based on selenium and that makes the process slow. >> Where can I know more? >> - there is some documentation here (for VW, I think): http://www.shaffer-consulting.com/david/Seaside/TestingComponents/TestingCo… >> - some slides here (on squeak): http://esug.org/data/ESUG2005/Wednesday/2005-ESUG-Shaffer.pdf >> but all that is old. Best way is to just install and see the tests, as always, >> >> >> cheers! >> Esteban >> >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Oct. 23, 2017

Re: [Pharo-users] Dynamically changing code in a safe way

by Richard Sargent

This is a great question, Abdelghani. It comes down to the meaning of the phrase "everything is an object". When you wrote "currentBloc value", that caused the block *[ 1 to:50 do: [:index |Transcript show: index. 100 milliSeconds asDelay wait]. Transcript cr. 1000 milliSeconds asDelay wait ]* to evaluate. The fact that you hold a reference to that block elsewhere and change what object is referenced at some point does not change the fact that the block itself is executing. Until your code executes *currentBloc value* again, it won't start the new block executing. Imagine if I were to hand you a loaf of bread and tell you to feed it to the dog. If I were then to hand you another loaf of bread, the dog would continue eating the first loaf. We never told the dog to do anything else. On Mon, Oct 23, 2017 at 1:53 PM, abdelghani ALIDRA via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: abdelghani ALIDRA <alidrandco(a)yahoo.fr> > To: <pharo-users(a)lists.pharo.org> > Cc: > Bcc: > Date: Mon, 23 Oct 2017 20:53:51 +0000 (UTC) > Subject: Dynamically changing code in a safe way > Hi, > > If I create a class HotSwapping with the instance variable currentBLoc > (and the corresponding accessors) and the following methods : > > HotSwapping>>initialize > currentBloc := [ 1 to:50 do: [:index |Transcript show: index. 100 > milliSeconds asDelay wait]. Transcript cr. 1000 milliSeconds asDelay wait ] > > HotSwapping>>run > [10 timesRepeat: [ currentBloc value ]] fork > > I then do : obj := HotSwapping new run > The âfunnyâ thing is that, when Transcript starts showing numbers, lets > say : 12345678910 (i.e. the bloc is in the middle of its execution), I do > obj currentBloc: [Transcript show: âHelloâ;cr. 1000 milliSeconds asDelay > wait ] > > The Transcript does not stop showing numbers. It shows the Hello message > only after the old bloc has finished executing (the entire line of number > form 0 to 50 has been printed in the Transcript) > > So why does not this happen this way? Why the assignment of the new code > is delayed until the end of the bloc execution? is it something related to > threads execution or does Pharo implement some safety hot swapping > mechanisms? > > Thanks in advance. > Abdelghani > > >

Oct. 23, 2017

Dynamically changing code in a safe way

by abdelghani ALIDRA

Hi, If I create a class HotSwapping with the instance variable currentBLoc (and the corresponding accessors) and the following methods : HotSwapping>>initialize currentBloc := [ 1 to:50 do: [:index |Transcript show: index. 100 milliSeconds asDelay wait]. Transcript cr. 1000 milliSeconds asDelay wait ] HotSwapping>>run [10 timesRepeat: [ currentBloc value ]] fork I then do : obj := HotSwapping new run The âfunnyâ thing is that, when Transcript starts showing numbers, lets say : 12345678910 (i.e. the bloc is in the middle of its execution), I do obj currentBloc: [Transcript show: âHelloâ;cr. 1000 milliSeconds asDelay wait ] The Transcript does not stop showing numbers. It shows the Hello message only after the old bloc has finished executing (the entire line of number form 0 to 50 has been printed in the Transcript) So why does not this happen this way? Why the assignment of the new code is delayed until the end of the bloc execution? is it something related to threads execution or does Pharo implement some safety hot swapping mechanisms? Thanks in advance. Abdelghani

Oct. 23, 2017

Re: [Pharo-users] About Ztimestamp

by Stephane Ducasse

Hi sven I read the class comments in fact :) and now rereading and your answer I start to understand. What the class comments did not convey to me was that you have to follow the 2001 example. The "#reference timestamp" was confusing to me. I could not undersrtand why you where talking about a method (that does not exist in fact). Then I could not understand how the numbering of the component of the example where related to the example you give below. And I can tell you that I browse the class side accessing but I could not find a simple date pattern. By the way using a number higher than 12 for days could help identifying the day from the month. And now I see that as I expected we can also pass a date and not be forced to pass a (ZTimestampFormat fromString: '03/02/2001') format: Date today. If you are interested I can try to propose a better class comment. And BTW I already used the formatter but more than one year ago. Stef On Sun, Oct 22, 2017 at 11:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Stef, > >> On 22 Oct 2017, at 17:45, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi sven >> >> I'm confused >> >> ft := ZTimestampFormat fromString: '02/11/2017'. >> ft format: DateAndTime now >> >> produces 10/11/1017060986 >> >> While I do not want time but just the date. >> and the date is wrong. >> >> So I will do it manually but I found sad that ZTimestampFormat cannot >> handle just handling days. >> I could then pass also a date and it would not ask for nanoseconds. >> >> Stef > > ZTimestampFormat works with example based format specifications. This works by making each component unique, using a sequential number. Consult the class comment for a full explanation. The class side's #formatSpecifications lists the tokens that are understood and their meaning. > > To go back to your issue, The year is the first component, written as 2001, the month the third and the day the second. So you probably want to do: > > (ZTimestampFormat fromString: '03/02/2001') format: DateAndTime now. > > => '22/10/2017' > > HTH, > > Sven > > >

Oct. 23, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by phil＠highoctane.be

I've callbacks all over in https://github.com/Pharophile/XmppTalk They do work. Phil On Mon, Oct 23, 2017 at 8:13 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz> wrote: > >> Hi, >> >> I would like to connect fingerprint reader to pharo - so far I am able to >> use C library to connect to it using UFFI, >> however the problem is that I can wait for fingerprint indefinitely ( >> blocking call to library) or register call-back for moment when fingerprint >> is available. >> The registration function returns immediately, so it is clear that the >> callback will be called from another thread. >> >> Is such situation supported by UFFI ? >> >> Thanks for any tip, >> >> Jan >> > > Callbacks are supported. Here is an example... > http://blog.openinworld.com/2016/09/pharo-libclang-ffi- > part-4-ast-walking-with-visitors-callbacks/ > > @Todd, How did find working through this part? > cheers -ben >

Oct. 23, 2017

Re: [Pharo-users] Zinc HTTP Component HTTP/2?

by Stephane Ducasse

We could run a bounty. Now here we are full of work. On Mon, Oct 23, 2017 at 6:59 PM, Volkert <volkert(a)komponentenwerkstatt.de> wrote: > So currently no plans and/or no sponsors, right? > > > On 22.10.2017 12:26, Esteban Lorenzano wrote: >> Hi Holger, >> >> We talked a bit about this last ESUG. >> Sadly, it requires serious work to have it so we hadnât put this in any schedule yet :( >> >> Esteban >> >>> On 21 Oct 2017, at 16:26, Volkert <volkert(a)komponentenwerkstatt.de> wrote: >>> >>> Dear all, >>> >>> the world is moving to http/2. Any plans for Zinc HTTP Components to >>> support this standard? >>> >>> BW, Volkert >>> >>> >>> >> > >

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by horrido

Thanks. Good answer. kilon.alios wrote > It all comes down to what you mean by "efficient". Obviously if you want > top performance on multiple cores you dont use any of those languages > including Pharo. Thats prettty much the sole reason why C++ is still a > relevant language. > > Now if you want ok performance you could use those languages. > > However in real case scenarios if you are worried about multi core support > then you have performance issues that you have to make sure its not the > code that has to be blamed before the language. > > For example yesterday I was loading a PNG file via Python to display on > screen via OpenGL and I was getting very slow performance 2.7 second for > 1.5 mb PNG. So my assumption as always "super slow python". But I decided > to give a try to another Python library and expected no more than 1.5 - 2 > seconds load time for the same file. It loaded in 0.03 seconds and took > some time to collect my jaw from the floor. > > Of course the previous library used a "pure python" approach , the other > library was the usual C library wrapped for Python. > > So the library and the code plays a massive role, and I mention this > example because Pharo works in a very similar way. If you do the code in > pure Pharo, Elixir or whatever you will be hit by the performance whale of > dynamic languages. Dynamic typing comes with a high cost as does a live > coding enviroment. Pharo is very lucky in that it has a JIT VM espeically > optimised for its language, so generally you wont get the slow speeds I > got. But still C will once more run circles around a Pharo implementation > , > especially if its an optimised library. > > Thus we have the UFFI. Esteban has done an excellent job and works like a > charm for using C libraries. > > Now if C also is proven slow then multi core wont help you much. > > You need the big guns , which is another name for "GPUs". A powerful GPU > is > even hundrends time faster than the most powerful CPU because it has > thousands of cores. But those cores are designed to compute similar tasks > hence why we dont throw CPUs away which are more versatile. > > So if you plan to do similar computations through millions of objects, > multi core wont help you much, you need the big guns a very expensive and > powerful GPU to do the heavy lifting. > > GPUs used to specialise only on Graphics, but 3d has become so complex > that > nowdays they can do all sort of computations and they have dedicate APIs > for accesing thousands of cores via OpenCL and CUDA. > > Unsuprisingly they run mainly on C/C++. > > The good news is that through the UFFI is possible to access a GPU via > Pharo, Ronie has done this. > > But to my experience most people dont realise what an extremely complex > field performance is and how it widely fluctuates from scenario to > scenario. So there is no "turbo" button to press. > > Now if you ask "but how I do this with pharo". Well technically you dont > do > this with Pharo because Pharo is made to run on CPU. > > GPUs run their own executables which means you have to use special > compilers , good news is that they can do compiling on the fly too so > Pharo > can leverage that. Again Ronie's works is relevant here. > > If you want to avoid all the complexity and go for the simplest solution , > then avoid the GPU. Because GPUs are kinda insane in terms of complexity. > > The easiest way is to fire up multiple Pharo and have them communicate > with > each other via socket or shared memory. The OS when it starts a new > process > it usually asigns it a core that is idle to take advantage of your > multiple > cores. > > Summary: > The answer is "Pharo can do this by accessing the GPU which much faster > than CPU or can access multiple cores through multiple instances running > at > the same time". > > So yes you can have top performance Pharo code if run this way, it wont be > up to C standards but it will be blazzing fast none the less. > > On Mon, Oct 23, 2017 at 4:28 PM horrido < > horrido.hobbies@ > > wrote: > >> With todayâs powerful multi-core processors, the demand for efficient >> software concurrency is high. We find strong support for such concurrency >> in >> the latest crop of âmodernâ languages such as Clojure, Elixir, Go, >> Haskell, >> and Scala. >> >> Whenever I present Smalltalk (Pharo) as a great language option, >> inevitably >> someone asks me about multi-core software concurrency. I have no response >> for them. >> >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. >> >> Do I say that doing concurrency right is very, very tough, even for the >> most >> experienced of developers? Let's focus on Pharo's strengths, instead. >> Sounds >> like an excuse. >> >> Can we safely ignore the multi-core reality? I welcome your feedback. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Re: [Pharo-users] UFFI with asynchronous callbacks

by Ben Coman

On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada <jan(a)cada.cz> wrote: > Hi, > > I would like to connect fingerprint reader to pharo - so far I am able to > use C library to connect to it using UFFI, > however the problem is that I can wait for fingerprint indefinitely ( > blocking call to library) or register call-back for moment when fingerprint > is available. > The registration function returns immediately, so it is clear that the > callback will be called from another thread. > > Is such situation supported by UFFI ? > > Thanks for any tip, > > Jan > Callbacks are supported. Here is an example... http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w… @Todd, How did find working through this part? cheers -ben

Oct. 23, 2017

Re: [Pharo-users] String >> #asSet

by Ben Coman

> > > On Oct 23, 2017, at 05:50, "Prof. Andrew P. Black" <black(a)cs.pdx.edu> > wrote: >> >> If you have a String (or a Symbol), and you sent it the message #asSet, what do you expect to get as an answer? >> >> A set of characters, one would think. But do you care what class is used to implement that set of characters? >> >> -- One argument says that it should be a Set, because thatâs what asSet answers when it is sent to other collections. Itâs conceivable that you might initially populate the set with Characters, but then add other kinds of object. >> >> -- Another argument says that it should be a CharacterSet (or a WideCharacterSet), because you know that the receiver contains characters. The expression 'abcd' asSet is a convenient way to create a CharacterSet with: $a with: $b with: $c with: $d >> >> -- A third argument says that you shouldnât care. If you really want a specific class, then you should use (aString as: Set) rather than aString asSet. >> >> Right now, in Pharo 7, there is a test in TConvertAsSetForMultiplinessTest that insists that the class of the result of asSet is actually Set. >> >> Hard coding a particular return class does seems to break the generality that make traits a good duck typing approach to testing. Instead you want to check it conforms to a series of tests like this... result := #(1 2 3 4) asSet. startSize := result size. result add: s anyOne. self assert: result size equals: startSize. but you don't want to repeat yourself reproduce similar tests by hand everywhere. One approach to reuse might be to refactor SetTest so it can be called like ... TConvertAsSetForMultiplinessTest>>testInQuestion result := self getResult. SetTest runDuckTestsFor: result where #runDuckTestsFor: would exclude Set instance creation tests and suchlike. Duck tests might all take a single argument, so SetTest could call them with a series of concrete cases. The leads me to a philosophical quesition... should methods providing concrete test samples be stored on the class-side. That is, its simple to use... MyClassTest >> someTest sample := self sample. etc... but would it be more correct to do... MyClassTest >> someTest sample := self class sample. etc... since #sample is unrelated to the state of any particularMyClass. And maybe its better to drive it all from the class side... SetTest>>runcase self samples do: [ :duck | self runDuckTestsFor: duck]. self runCreationTests. Now I'm not sure if the following is the RightThing(tm), but for discussion... SetTest>>runDuckTestsFor: duck self testsTakingOneArgument do: [ :method | self perform: method with: duck ]. cheers -ben

Oct. 23, 2017

Re: [Pharo-users] Zinc HTTP Component HTTP/2?

by Volkert

So currently no plans and/or no sponsors, right? On 22.10.2017 12:26, Esteban Lorenzano wrote: > Hi Holger, > > We talked a bit about this last ESUG. > Sadly, it requires serious work to have it so we hadnât put this in any schedule yet :( > > Esteban > >> On 21 Oct 2017, at 16:26, Volkert <volkert(a)komponentenwerkstatt.de> wrote: >> >> Dear all, >> >> the world is moving to http/2. Any plans for Zinc HTTP Components to >> support this standard? >> >> BW, Volkert >> >> >> >

Oct. 23, 2017

Re: [Pharo-users] Pharo/Win on a HiDPI display

by Torsten Bergmann

Hi Raffaello, see: http://forum.world.st/ANN-VistaCursor-now-scalable-td4961238.html Regards Torsten > Gesendet: Montag, 23. Oktober 2017 um 14:58 Uhr > Von: "Raffaello Giulietti" <raffaello.giulietti(a)lifeware.ch> > An: pharo-users(a)lists.pharo.org > Betreff: [Pharo-users] Pharo/Win on a HiDPI display > > Hi, > > not sure if this has already been discussed. > > I'm using Pharo/Win on a HiDPI (aka "retina") display scaled at 200%. > > Everything shows correctly scaled (widgets, fonts, icons, etc.), except > for the cursor, which is not scaled at all in Pharo, so it is rendered > half the expected size. Outside Pharo the cursor appears correctly. > > Is there something configurable in Pharo itself to overcome the tininess > of the cursor with respect to the rest of the GUI elements? > > (BTW, kudos for the otherwise excellent HiDPI support in Pharo. Nice work.) > > Greetings > Raffaello > >

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by Dimitris Chloupis

It all comes down to what you mean by "efficient". Obviously if you want top performance on multiple cores you dont use any of those languages including Pharo. Thats prettty much the sole reason why C++ is still a relevant language. Now if you want ok performance you could use those languages. However in real case scenarios if you are worried about multi core support then you have performance issues that you have to make sure its not the code that has to be blamed before the language. For example yesterday I was loading a PNG file via Python to display on screen via OpenGL and I was getting very slow performance 2.7 second for 1.5 mb PNG. So my assumption as always "super slow python". But I decided to give a try to another Python library and expected no more than 1.5 - 2 seconds load time for the same file. It loaded in 0.03 seconds and took some time to collect my jaw from the floor. Of course the previous library used a "pure python" approach , the other library was the usual C library wrapped for Python. So the library and the code plays a massive role, and I mention this example because Pharo works in a very similar way. If you do the code in pure Pharo, Elixir or whatever you will be hit by the performance whale of dynamic languages. Dynamic typing comes with a high cost as does a live coding enviroment. Pharo is very lucky in that it has a JIT VM espeically optimised for its language, so generally you wont get the slow speeds I got. But still C will once more run circles around a Pharo implementation , especially if its an optimised library. Thus we have the UFFI. Esteban has done an excellent job and works like a charm for using C libraries. Now if C also is proven slow then multi core wont help you much. You need the big guns , which is another name for "GPUs". A powerful GPU is even hundrends time faster than the most powerful CPU because it has thousands of cores. But those cores are designed to compute similar tasks hence why we dont throw CPUs away which are more versatile. So if you plan to do similar computations through millions of objects, multi core wont help you much, you need the big guns a very expensive and powerful GPU to do the heavy lifting. GPUs used to specialise only on Graphics, but 3d has become so complex that nowdays they can do all sort of computations and they have dedicate APIs for accesing thousands of cores via OpenCL and CUDA. Unsuprisingly they run mainly on C/C++. The good news is that through the UFFI is possible to access a GPU via Pharo, Ronie has done this. But to my experience most people dont realise what an extremely complex field performance is and how it widely fluctuates from scenario to scenario. So there is no "turbo" button to press. Now if you ask "but how I do this with pharo". Well technically you dont do this with Pharo because Pharo is made to run on CPU. GPUs run their own executables which means you have to use special compilers , good news is that they can do compiling on the fly too so Pharo can leverage that. Again Ronie's works is relevant here. If you want to avoid all the complexity and go for the simplest solution , then avoid the GPU. Because GPUs are kinda insane in terms of complexity. The easiest way is to fire up multiple Pharo and have them communicate with each other via socket or shared memory. The OS when it starts a new process it usually asigns it a core that is idle to take advantage of your multiple cores. Summary: The answer is "Pharo can do this by accessing the GPU which much faster than CPU or can access multiple cores through multiple instances running at the same time". So yes you can have top performance Pharo code if run this way, it wont be up to C standards but it will be blazzing fast none the less. On Mon, Oct 23, 2017 at 4:28 PM horrido <horrido.hobbies(a)gmail.com> wrote: > With todayâs powerful multi-core processors, the demand for efficient > software concurrency is high. We find strong support for such concurrency > in > the latest crop of âmodernâ languages such as Clojure, Elixir, Go, Haskell, > and Scala. > > Whenever I present Smalltalk (Pharo) as a great language option, inevitably > someone asks me about multi-core software concurrency. I have no response > for them. > > Do I just say that if you need concurrency, Pharo is the wrong choice? > After > all, no programming language can be good at everything. You must always > choose the right tool for the job. > > Do I say that doing concurrency right is very, very tough, even for the > most > experienced of developers? Let's focus on Pharo's strengths, instead. > Sounds > like an excuse. > > Can we safely ignore the multi-core reality? I welcome your feedback. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by stephan

On 23-10-17 16:16, horrido wrote: > Yes, but isn't there an important class of concurrent software where > lightweight threads work on shared state? Isn't that the reason for > "goroutines" in Go, and STM in Clojure, and actors in Scala? There are lots of different concurrency and performance problems and solutions. For certain ones we have good solutions, others less. For some, running many images scales much better than doing something with immutable data. Solutions with good O() are not necessarily fast, nor scale well. As we run them on machines with limited capacity, the constants might dominate. Stephan

Oct. 23, 2017

UFFI with asynchronous callbacks

by Jan Cada

Hi, I would like to connect fingerprint reader to pharo - so far I am able to use C library to connect to it using UFFI, however the problem is that I can wait for fingerprint indefinitely ( blocking call to library) or register call-back for moment when fingerprint is available. The registration function returns immediately, so it is clear that the callback will be called from another thread. Is such situation supported by UFFI ? Thanks for any tip, Jan

Oct. 23, 2017

Re: [Pharo-users] String >> #asSet

by Richard Sargent

In general, when desiring a specific class, to see (Specific collection class withAll: someOtherCollectionInstance). When sending a message, you don't typically expect a given class. Rather, you should expect a set of behaviour. (In this case, an object that behaves like a set.) On Oct 23, 2017, 05:50, at 05:50, "Prof. Andrew P. Black" <black(a)cs.pdx.edu> wrote: >If you have a String (or a Symbol), and you sent it the message #asSet, >what do you expect to get as an answer? > >A set of characters, one would think. But do you care what class is >used to implement that set of characters? > >-- One argument says that it should be a Set, because thatâs what asSet >answers when it is sent to other collections. Itâs conceivable that >you might initially populate the set with Characters, but then add >other kinds of object. > >-- Another argument says that it should be a CharacterSet (or a >WideCharacterSet), because you know that the receiver contains >characters. The expression 'abcd' asSet is a convenient way to create >a CharacterSet with: $a with: $b with: $c with: $d > >-- A third argument says that you shouldnât care. If you really want a >specific class, then you should use (aString as: Set) rather than >aString asSet. > >Right now, in Pharo 7, there is a test in >TConvertAsSetForMultiplinessTest that insists that the class of the >result of asSet is actually Set. This test is already overridden once, >in IdentityBagTest, because the result of sending asSet to an >IdentityBag is not a Set â itâs an IdentitySet. So, indeed, there is >already a precedent for asSet returning a set object that is not an >instance of Set. > >I think that the test is bad, and should be changed. But this raises >the larger question: if you want to know whether or not a collection >has set-like behaviour, what is the right way of finding out? >(aCollection isKindOf: Set) reads OK, but is actually wrong, because >itâs testing the implementation, and not the behaviour. A predicate >on all collections (isSet would be the obvious name) would seem to be >indicated. And thatâs what the test should be using. > >(You might ask why CharacterSet and WideCharacterSet are not subclasses >of Set. This answer is that subclassing Set implies inheriting a hash >table, and the raison dâÃªtre for CharacterSet is that it does not use a >hash table.)

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by Richard Sargent

That's the GemStone model. It works well for our customers. On Oct 23, 2017 07:03, "stephan" <stephan(a)stack.nl> wrote: > On 23-10-17 15:27, horrido wrote: > >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. >> > > No, you tell them to use many images and/or vms. We can effectively use > state-full micro services. Immutable data is still rather inefficient and > in many cases we can avoid needing that. > > Stephan > > >

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by horrido

Yes, but isn't there an important class of concurrent software where lightweight threads work on shared state? Isn't that the reason for "goroutines" in Go, and STM in Clojure, and actors in Scala? Stephan Eggermont-3 wrote > On 23-10-17 15:27, horrido wrote: >> Do I just say that if you need concurrency, Pharo is the wrong choice? >> After >> all, no programming language can be good at everything. You must always >> choose the right tool for the job. > > No, you tell them to use many images and/or vms. We can effectively use > state-full micro services. Immutable data is still rather inefficient > and in many cases we can avoid needing that. > > Stephan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Re: [Pharo-users] Multi-core Software Concurrency

by stephan

On 23-10-17 15:27, horrido wrote: > Do I just say that if you need concurrency, Pharo is the wrong choice? After > all, no programming language can be good at everything. You must always > choose the right tool for the job. No, you tell them to use many images and/or vms. We can effectively use state-full micro services. Immutable data is still rather inefficient and in many cases we can avoid needing that. Stephan

Oct. 23, 2017

Multi-core Software Concurrency

by horrido

With todayâs powerful multi-core processors, the demand for efficient software concurrency is high. We find strong support for such concurrency in the latest crop of âmodernâ languages such as Clojure, Elixir, Go, Haskell, and Scala. Whenever I present Smalltalk (Pharo) as a great language option, inevitably someone asks me about multi-core software concurrency. I have no response for them. Do I just say that if you need concurrency, Pharo is the wrong choice? After all, no programming language can be good at everything. You must always choose the right tool for the job. Do I say that doing concurrency right is very, very tough, even for the most experienced of developers? Let's focus on Pharo's strengths, instead. Sounds like an excuse. Can we safely ignore the multi-core reality? I welcome your feedback. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Re: [Pharo-users] Smalltalk Argument

by horrido

Of all the responses here, I like this one the best because it's right on the money. In my long career, I've been dropped into many software projects where I had to quickly ramp up with a new programming language. The employer didn't hire me for my language expertise; they hired me for my programming skill and ability to deliver good quality software on time. The programming tool used was a mere technicality, and hardly an obstacle. There is not a software developer alive who can coast through their entire career without ever needing to pick up another programming language. This is simply not an issue except for the most myopic of employers. Pharo Smalltalk Users mailing list wrote > Hi Paulo, > > I think this is not the right question to ask. > The problem is not "Where to find Smalltalk developers?", the problem is > rather > "How much effort does it take to help a good experienced OO developer to > transition to Smalltalk?" > > OO developers have to steadily gain and learn new technologies and > frameworks... > So why not Smalltalk? > Those developers that are not willing to learn a new language just > because they consider the trade-offs of not finding a job in that field > that easily, might not be the best choice for your team anyway... > > That is my experience... I know more developers missing the "Smalltalk > experience" than those hating Smalltalk once they left a team... > > Sebastian > > > On 2017-10-19 12:04 AM, Paulo R. Dellani wrote: >> Dear all, >> >> after using Smalltalk for several years I developed a passion for the >> language (how not to?), and Pharo is just so great to develop with. >> So thank you guys for keeping this wonderful project running. >> >> Unfortunately, it is not easy to always point out why Smalltalk >> should be employed as "main development language" in a team >> or for a project. In the last discussion of this sort I was confronted >> with the question "where are we going to get new smalltalk >> developers if our startup grows or if you go?". Well, I had no >> good answer to that. What would have you answered? >> >> Cheers, >> >> Paulo >> >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Pharo/Win on a HiDPI display

by Raffaello Giulietti

Hi, not sure if this has already been discussed. I'm using Pharo/Win on a HiDPI (aka "retina") display scaled at 200%. Everything shows correctly scaled (widgets, fonts, icons, etc.), except for the cursor, which is not scaled at all in Pharo, so it is rendered half the expected size. Outside Pharo the cursor appears correctly. Is there something configurable in Pharo itself to overcome the tininess of the cursor with respect to the rest of the GUI elements? (BTW, kudos for the otherwise excellent HiDPI support in Pharo. Nice work.) Greetings Raffaello

Oct. 23, 2017

String >> #asSet

by Prof. Andrew P. Black

If you have a String (or a Symbol), and you sent it the message #asSet, what do you expect to get as an answer? A set of characters, one would think. But do you care what class is used to implement that set of characters? -- One argument says that it should be a Set, because thatâs what asSet answers when it is sent to other collections. Itâs conceivable that you might initially populate the set with Characters, but then add other kinds of object. -- Another argument says that it should be a CharacterSet (or a WideCharacterSet), because you know that the receiver contains characters. The expression 'abcd' asSet is a convenient way to create a CharacterSet with: $a with: $b with: $c with: $d -- A third argument says that you shouldnât care. If you really want a specific class, then you should use (aString as: Set) rather than aString asSet. Right now, in Pharo 7, there is a test in TConvertAsSetForMultiplinessTest that insists that the class of the result of asSet is actually Set. This test is already overridden once, in IdentityBagTest, because the result of sending asSet to an IdentityBag is not a Set â itâs an IdentitySet. So, indeed, there is already a precedent for asSet returning a set object that is not an instance of Set. I think that the test is bad, and should be changed. But this raises the larger question: if you want to know whether or not a collection has set-like behaviour, what is the right way of finding out? (aCollection isKindOf: Set) reads OK, but is actually wrong, because itâs testing the implementation, and not the behaviour. A predicate on all collections (isSet would be the obvious name) would seem to be indicated. And thatâs what the test should be using. (You might ask why CharacterSet and WideCharacterSet are not subclasses of Set. This answer is that subclassing Set implies inheriting a hash table, and the raison dâÃªtre for CharacterSet is that it does not use a hash table.)

Oct. 23, 2017

Re: [Pharo-users] Smalltalk Argument

by horrido

To quote from The Wisdom of the Crowd <https://hackernoon.com/the-wisdom-of-the-crowd-c7aff954bd5f> : The crowd is indeed wise. This wisdom shows up in the latest StackOverflow survey <https://insights.stackoverflow.com/survey/2017#technology-most-loved-dreade…> , as well. Under âMost Loved Languages,â Smalltalk shows up in clear second place (after Rust and before TypeScript, Swift, Go, Python, Elixir, and C#). This shows that people whoâve used Smalltalk love the language and are loyal to it. It also shows, by inference, that the programming community is not aware of how good Smalltalk is. Most in the community wallow in ignorance over it. /If they were to try Smalltalk programming, the language would very likely become popular./ itlists(a)schrievkrom.de wrote > I do not want to spoil the party (perhaps I've done this already) - but > has anyone done a serious inspection of this number: 67%. > > They have interviewed 64000 persons and 67% of the people should "love" > Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the > user already using Smalltalk "love" that. > > By the way - the most loved platform is Linux (69%) ... > > > Marten > > Am 20.10.2017 um 09:19 schrieb Paulo R. Dellani: > >> >> The second most loved language by 67% of developers surveyed cannot >> simply >> be ruled out because of unfounded concerns. (Thanks again for the > > > -- > Marten Feldtmann -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 23, 2017

Restoring an Alto

by Ben Coman

An interesting side story... A Digibarn Xerox Alto arrives for restoration https://www.youtube.com/watch?v=JSPlr4AZsKQ cheers -ben

Oct. 23, 2017