Re: [Pharo-users] Territorial loading problems & alternative ways of loading data for making a choropleth map

[Hernán Morales Durand]

2017-10-24 1:21 GMT-03:00 Hernán Morales Durand :
> Hola Offray,
>
> I tried loading in Windows 8.1 and it loads fine using:
>
> Metacello new
> smalltalkhubUser: 'hernan' project: 'Territorial';
> configuration: 'Territorial';
> version: #bleedingEdge;
> load.
>
> Then load TerritorialData-AMCharts-HernanMoralesDurand.2 from the repository.
>

TerritorialData-AMCharts-HernanMoralesDurand.3

or the latest version you find :)

> I published some "fixes" related to Spec and Roassal. (I have to
> review them because I'm porting other packages to Pharo 6.1, but it
> should work for displaying maps).
>
> The following expression displays a window with Colombia departments:
>
> TerritorialAMChartsMapsProvider viewHighResCountry: 'Colombia'
>
> For a choropleth with a heatmap or centroids have a look at how I did
> it in PhyloclassTalk in SmalltalkHub, again I should update it to work
> in Pharo 6.1.
>
> Cheers,
>
> Hernán
>
>
>
> 2017-10-23 22:59 GMT-03:00 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
>>
>>
>>

Re: [Pharo-users] Territorial loading problems & alternative ways of loading data for making a choropleth map

[Hernán Morales Durand]

2017-10-24 0:01 GMT-03:00 Offray Vladimir Luna Cárdenas
:
> Hi,
>
> Answering myself: I was able to fix this problem by downloading the
> "territorial_files" zip folder from the source repo and unzipping it to
> the image folder. After that Metacello bleeding edge (not Monticello, my
> mistake) installation worked properly. So, it seems that proper
> downloading and unzipping of supporting files is not working. I have
> found this also for the GADM files as reported in [1].
>

Tomorrow I will check in Linux.

> By the way, I have created a Grafoscopio notebook to take some
> interactive notes on my learning of Territorial [2][3]. My first
> impressions are that this is a pretty potent package, but still needs a
> more fluid installation and the supporting files are huge, and I wonder
> if there is any way to query/download the data on demand.
>

Thank you for the feedback Offray.

This is an issue I should profile because some data sets are huge, and
then think about how to provide maybe a customized installation or
download spcific resource on demand.

Cheers,

Hernán

> [1] https://github.com/hernanmd/Territorial/issues/2.
> [2]
> http://mutabit.com/repos.fossil/grafoscopio/finfo?name=Docs/En/Books/Territorial/territorial.ston
> [3]
> http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Territorial/territorial.ston
>
> Thanks and keep the good work,
>
> Offray
>
> On 23/10/17 20:59, Offray Vladimir Luna Cárdenas wrote:
>> 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
>>
>>
>>
>>
>
>
>

Re: [Pharo-users] Territorial loading problems & alternative ways of loading data for making a choropleth map

[Offray Vladimir Luna Cárdenas]

Hi,

Answering myself: I was able to fix this problem by downloading the
"territorial_files" zip folder from the source repo and unzipping it to
the image folder. After that Metacello bleeding edge (not Monticello, my
mistake) installation worked properly. So, it seems that proper
downloading and unzipping of supporting files is not working. I have
found this also for the GADM files as reported in [1].

By the way, I have created a Grafoscopio notebook to take some
interactive notes on my learning of Territorial [2][3]. My first
impressions are that this is a pretty potent package, but still needs a
more fluid installation and the supporting files are huge, and I wonder
if there is any way to query/download the data on demand.

[1] https://github.com/hernanmd/Territorial/issues/2.
[2]
http://mutabit.com/repos.fossil/grafoscopio/finfo?name=Docs/En/Books/Territorial/territorial.ston
[3]
http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Territorial/territorial.ston

Thanks and keep the good work,

Offray

On 23/10/17 20:59, Offray Vladimir Luna Cárdenas wrote:
> 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
>
>
>
>

Re: [Pharo-users] Territorial loading problems & alternative ways of loading data for making a choropleth map

[Hernán Morales Durand]

I am revieweing this right now.

Lot of work in the bioinformatics department!

Hernán


2017-10-23 22:59 GMT-03:00 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
>
>
>

[Pharo-users] Territorial loading problems & alternative ways of loading data for making a choropleth map

[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

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

[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@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: abdelghani ALIDRA 
> To: 
> Cc:
> Bcc:
> Date: Mon, 23 Oct 2017 20:53:51 + (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
>
>
>

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

[abdelghani ALIDRA via Pharo-users]

--- Begin Message ---
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

--- End Message ---

Re: [Pharo-users] About Ztimestamp

[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  wrote:
> Hi Stef,
>
>> On 22 Oct 2017, at 17:45, Stephane Ducasse  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
>
>
>

Re: [Pharo-users] UFFI with asynchronous callbacks

[p...@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  wrote:

>
>
> On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada  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
>

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

[Stephane Ducasse]

We could run a bounty. Now here we are full of work.

On Mon, Oct 23, 2017 at 6:59 PM, Volkert
 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  wrote:
>>>
>>> Dear all,
>>>
>>> the world is moving to http/2. Any plans for Zinc HTTP Components to
>>> support this standard?
>>>
>>> BW, Volkert
>>>
>>>
>>>
>>
>
>

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

[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

Re: [Pharo-users] UFFI with asynchronous callbacks

[Ben Coman]

On Mon, Oct 23, 2017 at 11:46 PM, Jan Cada  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

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

[Ben Coman]

>
>
> On Oct 23, 2017, at 05:50, "Prof. Andrew P. Black" 
> 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

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

[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  wrote:
>>
>> Dear all,
>>
>> the world is moving to http/2. Any plans for Zinc HTTP Components to
>> support this standard?
>>
>> BW, Volkert
>>
>>
>>
>

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

[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" 
> An: pharo-users@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
> 
> 

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

[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  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
>
>

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

[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

[Pharo-users] UFFI with asynchronous callbacks

[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

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

[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"  
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.)

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

[Richard Sargent]

That's the GemStone model. It works well for our customers.

On Oct 23, 2017 07:03, "stephan"  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
>
>
>

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

[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

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

[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

[Pharo-users] Multi-core Software Concurrency

[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

Re: [Pharo-users] Smalltalk Argument

[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

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

[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

[Pharo-users] String >> #asSet

[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.)  

Re: [Pharo-users] Smalltalk Argument

[horrido]

To quote from  The Wisdom of the Crowd
  :

The crowd is indeed wise. This wisdom shows up in the  latest StackOverflow
survey

 
, 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./



itli...@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

Re: [Pharo-users] using mocketry to mock subcall

[Denis Kudriashov]

Hi Herby.

2017-10-20 18:49 GMT+02:00 Herby Vojčík :
>
>
> I had this problem. I tried something like (though not exactly w/ this
> code):
>
> Foo stub new will: [ :aMessage |
>   | original |
>   original := MockExpectedOriginalCall new executeFor: aMessage.
>   original stub.
>   ^ original ]
>
> but IIRC it failed on doing #stub inside will: block.
>

So the arguments of block in message #will: are expected to be arguments of
stubbing message (not a full message instance).
We can introduce new kind of expected action to automatically stub any
result of message send:

Foo stub new willStubRealResult.


With help of new subclass of MockExpectedOriginalMethodCall:

MockExpectedMethodResultStub>>executeFor: anOccurredMessage

realMethodResult := super executeFor: anOccurredMessage.

realMethodResult stub.

^realMethodResult.

MockExpectedMessage>>willStubRealResult

self will: MockExpectedMethodResultStub new


And then you will be able specify expectations for all Foo instances:

(Instance of: Foo) stub someMessage willReturn: #const

And you will be able assert any message which was sent to Foo instances:

(Instance of: Foo) should receive someRequiredMessage which should equal:
#expectedValue


I committed this code to the dev branch. But I am wondering that such kind
of behaviour is really needed. Probably it is useful as you ask about it.


>
>> So now you can just use simple mock which will be returned as simple
>> stub from concrete constructor of your class:
>>
>> some := Mock new.
>>
>> some stub askForName: 'new'.
>>
>> Something stub new willReturn: some.
>>
>>
>> I think it looks not not bad and no crazy magic is evolved. And of
>> course you can replace mock with real instance if you want:
>>
>> some := Something new.
>>
>> some stub askForName: 'new'.
>>
>> Something stub new willReturn: some.
>>
>>
>>
>> 2017-10-20 14:21 GMT+02:00 Denis Kudriashov > >:
>>
>> Yes, but in that case you stub messages to the class itself. For
>> your example it means:
>>
>> Something stub askForName willReturn: 'new'.
>>
>> Something askForName should be: 'new'
>>
>>
>>
>> 2017-10-20 13:58 GMT+02:00 Peter Uhnák > >:
>>
>> Thanks Denis, that did the trick.
>>
>> But I thought that I can also mock at the class level (at least
>> it was shown in the docs).
>>
>> Peter
>>
>> On Sat, Oct 7, 2017 at 11:24 AM, Denis Kudriashov
>> mailto:dionisi...@gmail.com>> wrote:
>>
>> Hi Peter.
>>
>> You should stub instance instead of class:
>>   s := Something new.
>>   s stub askFor...
>>
>> 7 окт. 2017 г. 9:18 пользователь "Peter Uhnák"
>> mailto:i.uh...@gmail.com>> написал:
>>
>>
>> Hi,
>>
>> maybe I am missing something fundamental, because this
>> seems like an obvious scenario
>>
>> I have a class Something with two methods
>>
>> Something>>askForName
>> ^ UIManager default request: 'Name'
>>
>> Something>>name
>> ^ self askForName , ' suffix'
>>
>> Now I want to mock out askForName, so I can run it
>> automatically in tests...
>>
>> I've tried just stubbing it...
>>
>> SomethingTest>>testRenameStub
>> Something stub askForName willReturn: 'new'.
>> Something new name should be: 'new suffix'
>>
>> however it still opens the window to ask for the name,
>> so the original method is being called.
>>
>> Right now I have to stub it with metalinks, which
>> doesn't play well with some tools (hapao)
>>
>> SomethingTest>>testRenameMeta
>> | link newName |
>> link := MetaLink new
>> metaObject: [ 'new' ];
>> control: #instead.
>> (Something >> #askForName) ast link: link.
>> [ newName := Something new name ]
>> ensure: [ link uninstall ].
>> self assert: newName equals: 'new suffix'
>>
>> Thanks,
>> Peter
>>
>>
>>
>>
>>
>
>

Re: [Pharo-users] perspective request for those earning a living from Smalltalk

[jtuc...@objektfabrik.de]

Petr,

I've been working as a Consultant for many big corporations (mainly in 
VA Smalltalk) since 1996. The situation you describe is very well known 
to me. But in my opinion there is no technical reason for this. It's a 
managerial problem. Ever since IBM went out to their customers and told 
them to move to Java for the better ini the mid-90ies, managers wanted 
the Smalltalk projects to go away as fast as possible. Nobody asked why 
IBM was still happily using VisualAge Smalltalk internally at that time 
frame


So the Smalltalk projects were declared legacy by Management. 
Replacement projects were started with big efforts and optimism. Some 
went well, some somewhat came to fly in a bit more than double the time 
and much more times the costthan planned, some failed miserably. One 
thing was in common to the replacement projects all over the place: they 
took much longer, turned out to be much mor complicated and took a lot 
more manpower than anybody had ever imagined.


So two important things happened:

1) People were told the old Smalltalk stuff would be gone soon, so if 
you wanted to be a valued and appreciated staff member, you better stay 
away from these projects
2) The people who knew the business and technical side of the existing 
projects were moved to the new projects. Some liked it (because of 1) 
some were frustrated (because they knew / feared the new project was 
going to be a death march)



Over the first 2 years or so, nobody realized how bad the situation 
really was. It was easy to postpone user requirements to the new 
project, accumulate more and more manpower in the new project and still 
keep up green flags everywhere.


...until yellow was the new green and users/stakeholders wanted the new 
features NOW - and not one day when the replacement project would become 
real.


So the remaining manpower in the old project (not the ones with lots of 
experience and knowledge) had to extend the old system, integrate it 
with the new system (thereby implementing all the stuff that IBM once 
told their management would never be possible in Smalltalk) and keep it 
up and ranning year after year. Nobody ever said Thank You or would 
appreciate the work they did. Because that was old stuff anyways and was 
already irrelevant.



Some of these old systems still exist today, serving users every single 
day, while some of the new systems never appeared. No manpower was ever 
added to these projects, and never would anybody ever say: okay, guys, 
you won. They still work on legacy code and try to do their best to 
fulfill user requirements. While on other projects that never see the 
light of day, people get appreciation, are allowed to work with new 
technologies and do cool stuff. Nobody ever asked the Smalltalkers 
whether they could do that as well, because "if you want to do web, you 
need to do Java". IBM said so, you know (and many other consultants as 
well).


So this is why new people try to stay away from these old projects. This 
is why the remaining staff is frustrated and this is why nobody allows 
them to do the cool things that Smalltalk can do as well as the others. 
They are just required to fix bugs, add new features in the old GUIs and 
else keep silent. Some of them were trying to fight this and tried to 
prove Smalltalk's strengths, but back then nobody would listen. One day 
they gave up.



Management still frustrates people every. single. day.


Just my opinion


Joachim




Am 22.10.17 um 18:56 schrieb Petr Fischer:

Here. (But from one point of view, it's a litte misery, 10-20 year old code 
sometimes, a mess, old VAST, absolutely no interest from young colleagues with 
no experience to willingly learn something about Smalltalk etc etc.).

If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, 
which is a dream for me... but, we will see...

pf


At https://news.ycombinator.com/item?id=15523807
the question is asked... "Does anyone on here program in Smalltalk
professionally? Not to get off topic, but I'm curious and would like to
know how it stacks up compared to what they did previously? "

If you've earning a living from programming Smalltalk, please drop a
comment there.

cheers -ben




--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1