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

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