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

Re: [Pharo-users] Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk)

by Ben Coman

On Sat, Oct 7, 2017 at 7:05 PM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Ben Coman wrote: > >> Nice article. I like the way you've structured it and pushed the >> "updated" angle. >> >> I feel a bit too strong a claim is laid on Pharo producing the CogVM. >> Much of the Cog + Spur + 64bit VM work was originally done for Squeak >> with Pharo riding the coat-tails of that work. Lately Pharo community >> has been involved in improving VM with hotspot optimisation with Sista >> and moving towards making Pharo embeddable.. (@Clement, is "hotspot >> > > Hi, this made me curious. I always had the problem with Amber (and, all > the rest of Smalltalks in similar vein) that it is hard to use to one-off > scripting, as it presumes existence of the not really small class library > (objects, classes, collections, etc.). This disadvantaged it IMO in the > field of "can I just embed it here and script it with a few lines?" > scenarios. > > Did you (the Pharo community that is "moving towards making Pharo > embeddable") find some way to work this around? Embeddable here is no so much for one-off scripting, but more becoming an integrated part of an application driven by an event loop of a game engine rather than the existing VM event loop. I'd expect much of the class library to be available here, so your question is orthogonal. I've seen discussion of projects for Pharo work from the command line, but I don't know their status. cheers -ben

Oct. 7, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

Yes I agree with this Pharo is a live coding BASED enviroment. For Pharo live coding is not just an easy to use feature it based its entire mentality around the idea of live coding. Even though Smalltalk borrowed live coding and image format from Lisp we are more "pure" in that regard even compared to Lisp. But one thing to note here is that live coding is not really that useful when used always. At least for me I rely a lot on it for debugging and experimenting. But when I work based on a plan , or code just works I do not care so much about it. So my workflow in the end is semi-live coding because I dont feel I need live coding 24/7 to be super productive. Of course that creates some barriers in the end when tools are not made to work 24/7 on a live coding context. To that extend Pharo is definetly superior and a true live coding enviroment. You are suprised that you can do live coding in C++ but I was trully shocked. My saga to do live coding in C++ started as a joke, something to use to mock C++ ugliness and weakness. But oh boy it did slap it back to my face. The process is again simple, you wrap eveything inside a main loop,and call in this loop functions (C has no objects obvious) or methods if you use C++ from DLLs. Those DLLs obviously contain 99.9% of your code. Because a DLL can be reloaded it allows you not to stop executing and replace code on the fly. The main loop is wrapped inside an exception to make sure the an error will never crash your application, C/C++ exceptions are more powerful than Pharo live coding in that regard because in Pharo if you do anything bad with UFFI and crash it , it will crash for sure. If you keep the DLL small and you use tons of small dlls your compile times will be almost instantenous. You can also with very view lines detect date signature change in source file and trigger background compilation. Again few lines of code. The last mountain is live state, in this case the executable pass a single pointer and instead of the executable handling the memory its actually the dlls that handle it but the executable because it cannot crash or exit will keep the live state running. You can also use memory mapped file to store live state as they perform pure memory dumps. All in all you will end up with 100 lines of code that can be wrapped into a library and reused in the next project with zero setup. Its an one time pain. Will I would recommend C++ over Pharo for live coding .... helll no.... C++ obviously misses a hugely important live coding ingredient which is reflection. We do live coding because we want to interact with those objects ask questions about what is going on and why our code does not work as intended However Python has no such limitation following a very similar design to Smalltalk and being much more powerful language than C++. Python follow very closely the Smalltalk paradigm even though there is not a single mention of Smalltalk , anywhere in the Python community or of live coding. Live coding in C++ has become a huge deal in game development mainly because game development tend to want to change things on the fly and games are so big with extremely long compile times. Unreal has made a huge deal over its ability to hot reload C++ code in its editor , though I do not like its approach so much. Bottom line is yes its easy and simple to do live coding in other languages, not recommended so much in C++ because of its static compiled nature and lack of reflection but for dynamic language like Python it can come pretty close and I speak from experience. At least I have not found something in Python that made me wish I was live coding in Pharo so far, but then yes I still think its better to have a full blown live coding. Also from my limited understanding I have figured out that pretty much every language out there allows for reloading code which is pretty much a very large requirement for live coding. So yes you can live code to an extend, lesser in languages like C++ , more so in language like Python, Ruby etc. Can you get the Pharo experience ? In a dynamic language with the creation of a live coding library you could get pretty close but never exactly the same. Pharo still is the undisputed king of live coding. Why live coding is not a huge thing in coding in general, I am willing to bet it has more to do with coder mentality than language limitation. When you are used to "dead code" workflow it difficult to switch. I struggle a lot to get use to the live coding workflow of Pharo because I had to rewire my brain. But in the end you cannot avoid live coding, there will be always scenarios you would want to change things on the fly, reload code, store live state etc. In the end it more a coder flaw than it is a language flaw. I know we love to blame languages for our mistakes. But in our back of our head we all know we debate over languages that we barely use only 0.000001% of their true potential. We are too lazy and sometimes we need someone to slam our face to the truth to actually see it. And by we I dont mean the Pharo community but human nature by itself. That's exactly what Pharo did for me that motivated me exploring live coding in other languages. If it was not for Pharo I would still be doing the old slow method of correct, compile, restart and repeat till you hate yourself. On Sat, Oct 7, 2017 at 1:57 PM horrido <horrido.hobbies(a)gmail.com> wrote: > > My point is that indeed you can do with EASE live coding in a numerous > languages, at least to my experience. I have tried only Python and C/C++. > > Until I came upon this thread, I never knew you could do live coding in > Python and C/C++. And I was a professional C/C++ programmer for over 15 > years! > > It is certainly a well-kept secret. I have found very little information on > the web about doing live coding in these languages (in fact, none). This > leads me to believe that the vast majority of Python and C/C++ developers > don't know about, or don't do, live coding. > > Whether it's "easy" is rather subjective. I suspect it's not as easy nor as > convenient as in Pharo. If it were, then live coding ought to be much more > prevalent in the Python and C/C++ communities. After all, what developer > doesn't want to improve their productivity or increase their velocity of > development? > > The key differentiator here, I think, is that live coding is baked into > Pharo/Smalltalk, thus making it natural to use. It is not natural for > Python > and C/C++ programmers. It would be difficult to convince the IT industry to > adopt live coding en masse. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 7, 2017

Re: [Pharo-users] [Ann] PharoLauncher v1.0.1 released!

by Ben Coman

On Sat, Oct 7, 2017 at 3:38 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Just starting pharolauncher on windows still does not work (if you put it > into the default "program" folder). > On start, it tries to create a local direcitory "pharo-local" and does not > have the permission to do so. > You need to start it with admin-rights. > Why are we making it harder for Windows users in corporate environments by requiring them to have admin-rights they often won't have, while in Linux PharoLancher is installed into user folders? Also there is the UAC Virtualization fiasco that complicates installing upgrades. http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-January/091… Could we *please* install Windows PharoLauncher into user folders? What reason is there not to? cheers -ben > >> On Fri, Oct 6, 2017 at 5:35 PM, Christophe Demarey < >> christophe.demarey(a)inria.fr> wrote: >> >>> Hi Gabriel, >>> >>> Le 6 oct. 2017 Ã 15:48, Gabriel Cotelli <g.cotelli(a)gmail.com> a Ã©crit : >>> >>> I've tried it on Linux, and after the download has finished it cannot >>> launch a Pharo 6.1 image. Find attached the PharoDebug.log >>> >>> Seems it's searching for the sources file in a wrong location. >>> *Pharo cannot locate the sources file named >>> /home/gcotelli/Pharo/pharo-launcher/bin/lib/pharo/5.0-201707201942/PharoV60.sources.* >>> >>> I have wondered for a while if sources files should searched for up the directory hierarchy looking for a "/sources" folder to minimize the number of copies needed. cheers -ben

Oct. 7, 2017

Re: [Pharo-users] FileReference#entries caching?

by Peter UhnÃ¡k

On Sat, Oct 7, 2017 at 1:02 PM, Steven R. Baker <steven(a)stevenrbaker.com> wrote: > Is it cached or something? How do I guarantee that I'm *definitely* > getting the current state of the directory on disk? This looks extremely strange, I've never seen that inspecting files/directories would be somehow "out of sync" with the disk, because it is always asking the disk. Should I not even be using FileReference for this? > If you are loading png icons into Pharo, you can consider using https://github.com/peteruhnak/IconFactory/ instead (shameless self promotion :) ) Peter

Oct. 7, 2017

Futures, in Scale (was: Re: Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk))

by Herby VojÄÃk

Hi, I have looked at Scale b/c of different question, and I see it uses futures. I'd like to ask if those futures are one-off, or is there any consensus on how futures should look like in Pharo. The reason I ask is b/c Amber already has something like that - Promises, which do not use the native JS API directly (though it is inspired), but do have an API of their own; and since those concepts seems to be similar (or maybe are the same, just called differently), if the API used shouldn't be sort-of standardized / used the same way in all occasions. Herby P.S.: Including state-of-the-art Promises.st from Amber master branch to get a picture: Smalltalk createPackage: 'Kernel-Promises'! Object subclass: #Promise instanceVariableNames: '' package: 'Kernel-Promises'! !Promise class methodsFor: 'composites'! all: aCollection "Returns a Promise resolved with results of sub-promises." <inlineJS: 'return Promise.all($recv(aCollection)._asArray())'> ! any: aCollection "Returns a Promise resolved with first result of sub-promises." <inlineJS: 'return Promise.race($recv(aCollection)._asArray())'> ! ! !Promise class methodsFor: 'instance creation'! forBlock: aBlock "Returns a Promise that is resolved with the value of aBlock, and rejected if error happens while evaluating aBlock." ^ self new then: aBlock ! new "Returns a dumb Promise resolved with nil." <inlineJS: 'return Promise.resolve()'> ! new: aBlock "Returns a Promise that is eventually resolved or rejected. Pass a block that is called with one argument, model. You should call model value: ... to resolve the promise and model signal: ... to reject the promise. If error happens during run of the block, promise is rejected with that error as well." <inlineJS: 'return new Promise(function (resolve, reject) { var model = {value: resolve, signal: reject}; aBlock._value_(model); })'> ! signal: anObject "Returns a Promise rejected with anObject." <inlineJS: 'return $recv(anObject)._in_(function (x) {return Promise.reject(x)})'> ! value: anObject "Returns a Promise resolved with anObject." <inlineJS: 'return $recv(anObject)._in_(function (x) {return Promise.resolve(x)})'> ! ! Trait named: #TThenable package: 'Kernel-Promises'! !TThenable methodsFor: 'promises'! catch: aBlock <inlineJS: 'return self.then(null, function (err) {return $core.seamless(function () { return aBlock._value_(err); })})'> ! on: aClass do: aBlock <inlineJS: 'return self.then(null, function (err) {return $core.seamless(function () { if (err._isKindOf_(aClass)) return aBlock._value_(err); else throw err; })})'> ! on: aClass do: aBlock catch: anotherBlock ^ (self on: aClass do: aBlock) catch: anotherBlock ! then: aBlockOrArray "Accepts a block or array of blocks. Each of blocks in the array or the singleton one is used in .then call to a promise, to accept a result and transform it to the result for the next one. In case a block has more than one argument and result is an array, first n-1 elements of the array are put into additional arguments beyond the first. The first argument always contains the result as-is." <inlineJS: ' var array = Array.isArray(aBlockOrArray) ? aBlockOrArray : [aBlockOrArray]; return array.reduce(function (soFar, aBlock) { return soFar.then(typeof aBlock === "function" && aBlock.length > 1 ? function (result) {return $core.seamless(function () { if (Array.isArray(result)) { return aBlock._valueWithPossibleArguments_([result].concat(result.slice(0, aBlock.length-1))); } else { return aBlock._value_(result); } })} : function (result) {return $core.seamless(function () { return aBlock._value_(result); })} ); }, self)'> ! then: aBlockOrArray catch: anotherBlock ^ (self then: aBlockOrArray) catch: anotherBlock ! then: aBlockOrArray on: aClass do: aBlock ^ (self then: aBlockOrArray) on: aClass do: aBlock ! then: aBlockOrArray on: aClass do: aBlock catch: anotherBlock ^ ((self then: aBlockOrArray) on: aClass do: aBlock) catch: anotherBlock ! ! Promise setTraitComposition: {TThenable} asTraitComposition! ! ! phil(a)highoctane.be wrote: > https://github.com/guillep/Scale <https://github.com/guillep/Scale> is > quite cool for quick scripts on *nix. > > Now for embeddable, yes it would help. Bootstrapping will be helpful but > the current main issue is the VM interpret loop that is in the current VMs. > > It is not an intrinsic problem. Telepharo is also a great step to enable > that to exist. > > Phil > > On Oct 7, 2017 13:05, "Herby VojÄÃk" <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>> wrote: > > Ben Coman wrote: > > Nice article. I like the way you've structured it and pushed the > "updated" angle. > > I feel a bit too strong a claim is laid on Pharo producing the > CogVM. > Much of the Cog + Spur + 64bit VM work was originally done for > Squeak > with Pharo riding the coat-tails of that work. Lately Pharo > community > has been involved in improving VM with hotspot optimisation with > Sista > and moving towards making Pharo embeddable.. (@Clement, is "hotspot > > > Hi, this made me curious. I always had the problem with Amber (and, > all the rest of Smalltalks in similar vein) that it is hard to use > to one-off scripting, as it presumes existence of the not really > small class library (objects, classes, collections, etc.). This > disadvantaged it IMO in the field of "can I just embed it here and > script it with a few lines?" scenarios. > > Did you (the Pharo community that is "moving towards making Pharo > embeddable") find some way to work this around? > > cheers -ben > > > Herby > > >

Oct. 7, 2017

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

by phil＠highoctane.be

I would rather qualify Ubuntu as hell when deploying large setups of machines that have to be kept in working order for a long while. We should give top notch support for RHEL if we want to be relevant in spaces like Hadoop for example as the reference platform is RHEL/CentOS. Phil On Oct 6, 2017 16:20, "Andrew Glynn" <aglynn42(a)gmail.com> wrote: > There's a reason it's referred to by numerous developers as R-HELL. > > Andrew Glynn > > -----Original Message----- > > *Date*: Thu, 5 Oct 2017 21:46:20 +0800 > *Subject*: Re: [Pharo-users] Deploying on Linux with LibC version < 2.15 > *To*: bruce.oneel(a)pckswarms.ch, Any question about pharo is welcome < > pharo-users(a)lists.pharo.org > <Any%20question%20about%20pharo%20is%20welcome%20%3cpharo-users(a)lists.pharo.org%3e> > > > Reply-to: Any question about pharo is welcome <pharo-users(a)lists.pharo.org > > > *From*: Holger Freyther <holger(a)freyther.de > <Holger%20Freyther%20%3cholger(a)freyther.de%3e>> > > > On 5. Oct 2017, at 18:08, Bruce O'Neel <bruce.oneel(a)pckswarms.ch> wrote: > > Hi, > > > > Hi! > > > > > Well, our redhat 6.9 systems have 2.12, so, that qualifies. > > And yes, we still have RedHat 6, and 6.9 was released only 6 months ago! It will finish extended support in a mind-blowing 7 more years in 2024. > > Redhat 5, still supported for another 3 years till 2020 has glibc 2.5. > > > > > for a brief moment you really scared me. I thought you referred to RedHat Linux 6 which was released in 1999 but you are referring to Red Hat Enterprise Linux (RHEL). > > As it turns out we have "latest" (as soon as a commit is made to pharo-vm.git) and hand curated "stable" (hand created source tarballs, rebuilt from a git commit of opensmalltalk-vm) for RHEL6 and CentOS 6. > > CentOS 6.x: > > # Add the repo > $ yum-config-manager --add-repo http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… > > OR (for stable): > http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… > > # Install 32bit packages (with X11 dependency for *-ui or not) > > $ yum install pharo6-32-ui.i686 or pharo6-32.i386 > > # Install 64bit packages > > $ yum install pharo6-64-ui.x86_64 pharo6-64.x86_64 > > > > > > >

Oct. 7, 2017

Re: [Pharo-users] Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk)

by phil＠highoctane.be

https://github.com/guillep/Scale is quite cool for quick scripts on *nix. Now for embeddable, yes it would help. Bootstrapping will be helpful but the current main issue is the VM interpret loop that is in the current VMs. It is not an intrinsic problem. Telepharo is also a great step to enable that to exist. Phil On Oct 7, 2017 13:05, "Herby VojÄÃk" <herby(a)mailbox.sk> wrote: Ben Coman wrote: > Nice article. I like the way you've structured it and pushed the > "updated" angle. > > I feel a bit too strong a claim is laid on Pharo producing the CogVM. > Much of the Cog + Spur + 64bit VM work was originally done for Squeak > with Pharo riding the coat-tails of that work. Lately Pharo community > has been involved in improving VM with hotspot optimisation with Sista > and moving towards making Pharo embeddable.. (@Clement, is "hotspot > Hi, this made me curious. I always had the problem with Amber (and, all the rest of Smalltalks in similar vein) that it is hard to use to one-off scripting, as it presumes existence of the not really small class library (objects, classes, collections, etc.). This disadvantaged it IMO in the field of "can I just embed it here and script it with a few lines?" scenarios. Did you (the Pharo community that is "moving towards making Pharo embeddable") find some way to work this around? cheers -ben > Herby

Oct. 7, 2017

Re: [Pharo-users] What does RMoD stand for?

by Sven Van Caekenberghe

> On 7 Oct 2017, at 13:06, Rene Paul Mages (ramix) <pharo(a)rmages.com> wrote: > > > > Le 07/10/2017 Ã 12:59, horrido a Ã©crit : >> It is bizarre. Nowhere on the web can I find any reference to what INRIA's >> *RMoD* acronym stands for. > > Please try this request : > > https://tinyurl.com/INRIA-Rmod But it is strange that their main page does not say (AFAICS). It is something like Research into Modular Systems, but I am just guessing ;-) > -- > Amicalement. > Rene Paul Mages ( GnuPG_key 1024D/2CC455D9 ) > http://www.linux-azur.org/ramix > http://blog.pharo.fr > http://nosoftwarepatents.wikidot.com > > >

Oct. 7, 2017

Re: [Pharo-users] What does RMoD stand for?

by Rene Paul Mages (ramix)

Le 07/10/2017 Ã 12:59, horrido a Ã©critÂ : > It is bizarre. Nowhere on the web can I find any reference to what INRIA's > *RMoD* acronym stands for. Please try this request : https://tinyurl.com/INRIA-Rmod -- Amicalement. Rene Paul Mages ( GnuPG_key 1024D/2CC455D9 ) http://www.linux-azur.org/ramix http://blog.pharo.fr http://nosoftwarepatents.wikidot.com

Oct. 7, 2017

Embeddable Smalltalk (was: Re: Behold Pharo: The Modern Smalltalk)

by Herby VojÄÃk

Ben Coman wrote: > Nice article. I like the way you've structured it and pushed the > "updated" angle. > > I feel a bit too strong a claim is laid on Pharo producing the CogVM. > Much of the Cog + Spur + 64bit VM work was originally done for Squeak > with Pharo riding the coat-tails of that work. Lately Pharo community > has been involved in improving VM with hotspot optimisation with Sista > and moving towards making Pharo embeddable.. (@Clement, is "hotspot Hi, this made me curious. I always had the problem with Amber (and, all the rest of Smalltalks in similar vein) that it is hard to use to one-off scripting, as it presumes existence of the not really small class library (objects, classes, collections, etc.). This disadvantaged it IMO in the field of "can I just embed it here and script it with a few lines?" scenarios. Did you (the Pharo community that is "moving towards making Pharo embeddable") find some way to work this around? > cheers -ben Herby

Oct. 7, 2017