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

FileReference#entries caching?

by Steven R. Baker

Heya folks, I'm loading some PNG icons from disk, and I'm noticing some weirdness with FileReference#entries. When I inspect: '/home/srbaker/Projects/FocusFrog/icons' asFileReference entries it gives me an Array of size one, containing the refernce to the only file there. Then I delete the file, the same thing gives an array of size zero. But then when I fill the directory with a bunch of icons (240, to be exact), and inspect that line again I get zero. Eventually it gets the right answer. Is it cached or something? How do I guarantee that I'm *definitely* getting the current state of the directory on disk? Should I not even be using FileReference for this? Thanks! -Steven

Oct. 7, 2017

What does RMoD stand for?

by horrido

It is bizarre. Nowhere on the web can I find any reference to what INRIA's *RMoD* acronym stands for. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 7, 2017

Fun with UI Avatars

by Sven Van Caekenberghe

I came across https://ui-avatars.com, a web service that creates avatar images based on some parameters. >From Pharo, the shortest invocation would be something like ZnEasy getPng: 'https://ui-avatars.com/api?name=Albert+Einstein&size=128&background=0D8ABC&…'. Making use of the full builder interface of ZnClient that would look more like ZnClient new https; host: 'ui-avatars.com'; addPath: #api; queryAt: #name put: 'Albert Einstein'; queryAt: #size put: 128; queryAt: #color put: 'FFF'; queryAt: #background put: '0D8ABC'; queryAt: #rounded put: true; accept: ZnMimeType imagePng; enforceHttpSuccess: true; enforceAcceptContentType: true; contentReader: [ :entity | ImageReadWriter formFromStream: entity readStream ]; beOneShot; get. Anyway, it is cool to have an environment that makes this kind of experimentation so much fun. It is probably easy to implement this avatar image generation directly in Pharo ... Sven

Oct. 7, 2017

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

by horrido

> 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] Deploying on Linux with LibC version < 2.15

by Dimitris Chloupis

Why use a special Pharo VM when you can use LibC via UFFI from inside the image ? UFFI even offers partial wrapper to LibC. We prefer afterall to move things outside the VM and inside the image as much as we can to offers us a greater deal of flexibility. On Sat, Oct 7, 2017 at 12:45 PM Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 05/10/2017 Ã 15:46, Holger Freyther a Ã©crit : > > > > Hi! > > > > > > 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 > > > > > > Hi, > > Maybe the instructions for CentOS and RHEL could be added to the linux > download page of pharo.org? > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Oct. 7, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Noury Gmail

Hi, I have developed few years ago a trait-based solution to make it easy to deal with equality. By default, instances of the same class with equal IVs are equal + have the same hash code. You can customize the list of IVs to compare, which is handy in case of IVs that store cache values. All you have to do is to use the TEquality in your class. The code + tests are here http://smalltalkhub.com/#!/~CAR/ReusableBricks/packages/Equals This is part of the "ReusableBricks" repo that gather packages we're using it in different projects in my team. And it works fine. I'd love to have this integrated in Pharo. Note : I no longer receive mailing-lists emails, because I can't handle all the traffic. We can continue the conversation on Discord Noury > > > On 06 Oct 2017, at 18:31, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Contact noury because I do not remember. > But having a little builder is also nice. > > On Fri, Oct 6, 2017 at 4:15 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >> Stephane >> >> "Vitor why don't you take it as a small project to propose a solution for >> Pharo." >> >> I will try :) I like the idea of using a Trait. >> >> >> Em 6 de out de 2017 05:01, "Stephane Ducasse" <stepharo.self(a)gmail.com> >> escreveu: >> >> Here is what I extracted from older emails >> >> From David Allouche in Pharo-dev to see if >> The ==hash== method is used in Pharo to separate objects in >> bucket-based data structures. >> >> >> !! Property >> >> It must have one required property which is required data integrity: >> >> !!!! A. >> Objects that are equal according to ==\=== must have equal hashes. >> >> >> It should have two desirable properties that are required to support >> the algorithmic assumptions of bucket-based data structures: >> >> !!!! B. >> Objects that are not equal should have different hashes. Ideally, the >> probability of hash collision should by 1/N where N is the size of >> hash value space. >> >> !!!! C. The hash values should spread as much as possible over their >> value space. For example: ProtoObject>>#identityHash. >> >> >> >> >> How these two desirable properties can be implemented depends on the >> actual distribution of the values used to compute the hash. >> >> An object can safely use XOR hashing if its instance variables are all >> different objects that already provide a hash method with these two >> properties. >> >> @@todo check following sentence because the use of singleton is obscure >> >> For example, an object whose behaviour is defined by several of >> singleton delegates of different classes that do not override >> Object>>#hash. >> >> But if the instance variables are not guaranteed to have those >> properties, it is necessary to more thoroughly "mix the bits". For >> example the method ==hash== of ==SequenceableCollection== illustrates >> this point. >> >> >> [[[ >> SequenceableCollection >> hash >> | hash | >> hash := self species hash. >> 1 to: self size do: [:i | hash := (hash + (self at: i) hash) hashMultiply]. >> ^ hash >> ]]] >> >> >> The mixing of the bits is done by the combination of addition and >> ==hashMultiply==. The value of ==species hash== does not need to be >> processed by ==hashMultiply==, because it is probably computed by the >> method =identityHash== of ==ProtoObject==, and that already provides >> property C. >> >> !!! When we should not use XOR >> >> ==LayoutFrame== is a particularly good example of a data structure >> that should not use XOR hashing. Its instance variables provide none >> of the required properties: >> >> - ==SmallInteger>>hash== is just ==^self==. >> - In addition, common ==LayoutFrame== instances tend to use pairs of >> identical values in their instance variables. Like ==0@0 corner: >> 1@1==, or ==Margin fromNumber: 10==. >> >> A good hash function for LayoutFrame needs to: >> >> - Get hashes for each instance variable that provides properties A and B. >> - Combine them in a way that is order-sensitive (to maintain property >> B) and that does some extra mixing (to provide property C). >> >> Now, we can assume that common values for the instance variables will >> be instances of ==SmallInteger==, ==Float==, or ==Fraction==. >> >> You can see in ==Fraction>>hash==, that a comment mentions the >> assumption that the fraction is already reduced, that is what makes it >> acceptable to use bitXor. >> >> The hash of ==SmallInteger== does provide properties A and B, but not >> property C. The hash of ==Float== is harder to understand, but tests >> show that it provides distinct values for 0.5, 0.25 and 0.125. So it >> hopefully provides B for the range of values of interest to >> ==LayoutFrame==. >> >> Another class that has similar hashing constraints to ==LayoutFrame== >> is ==Point==. Its ==hash== method is: >> >> [[[ >> Point >> hash >> "Hash is reimplemented because = is implemented." >> ^(x hash hashMultiply + y hash) hashMultiply >> ]]] >> >> It does not include species in the computation, which is less than >> ideal because it favours collisions with objects of different species >> that have a similar content and a the same hash algorithm. >> >> Finally, it is probably not necessary or useful to use the accessors >> to get to the instance variables. >> >> So a good implementation for LayoutFrame is >> >> [[[ >> LayoutFrame >> hash >> | hash | >> hash := self species hash >> hash := (hash + leftFraction hash) hashMultiply >> hash := (hash + leftOffset hash) hashMultiply >> hash := (hash + topFraction hash) hashMultiply >> hash := (hash + topOffset hash) hashMultiply >> hash := (hash + rightFraction hash) hashMultiply >> hash := (hash + rightOffset hash) hashMultiply >> hash := (hash + bottomFraction hash) hashMultiply >> hash := (hash + bottomOffset hash) hashMultiply >> ^ hash >> ]]] >> >> On Fri, Oct 6, 2017 at 9:59 AM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> Noury also proposed a trait to avoid to systematically have to implement >>> hash. >>> Vitor why don't you take it as a small project to propose a solution for >>> Pharo. >>> >>> On Thu, Oct 5, 2017 at 6:34 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>>> Yes, canEqual implementation also make #= be commutative. >>>> >>>> On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>> wrote: >>>>> >>>>> >>>>> 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>>>> >>>>>> >>>>>> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >>>>>>> >>>>>>> I am sorry, not species, but #isKindOf istead of #= to compare >>>>>>> classes. >>>>>> >>>>>> >>>>>> It is bad idea. #= should be transitive. >>>>> >>>>> >>>>> Oh, I used wrong word, shame on me :). I tried to say commutative. >>>>> >>>>>> >>>>>> How you will generate it with isKindOf: logic? You need to know common >>>>>> parent. >>>>>> >>>>>> Also I not remember cases where I was needed two instances of different >>>>>> classes to be equal. >>>>>> And I can imaging the problems which it will lead to. >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov >>>>>>> <dionisiydk(a)gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>> Two questions/comments about the generated code: >>>>>>>>> 1. #= >>>>>>>>> ... >>>>>>>>> self class = anObject class "should compare #species >>>>>>>>> instead?" >>>>>>>>> ifFalse: [ ^ false ]. >>>>>>>>> ... >>>>>>>>> Typically, I've seen #species instead of #class in the guard >>>>>>>>> statement. >>>>>>>>> Should we change it to that? >>>>>>>> >>>>>>>> >>>>>>>> I doubt that it is important for domain classes. Because I never saw >>>>>>>> the user of #species which is not a kind of Collection. And for >>>>>>>> collections >>>>>>>> this refactoring is not valid anyway. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2. #hash >>>>>>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>>>>>> Is this implementation always safe? It's what I usually hand roll >>>>>>>>> based on >>>>>>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>>>>>> hashing, so >>>>>>>>> I've always wondered if I was missing somethingâ¦ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- >>>>>>>>> Cheers, >>>>>>>>> Sean >>>>>>>>> -- >>>>>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >>

Oct. 7, 2017

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

by Christophe Demarey

Hi Nicolai, > Le 7 oct. 2017 Ã 09:38, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : > > 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. A Pharo image needs write permission in the image folder to store image sessions (epicea) as well as other image data (package cache, play-cache, changes file, etc.) Maybe we should disable Epicea and it could work in a read only environment? For now, either you can start it with admin rights or you install Pharo Launcher in a user folder. Regards, Christophe

Oct. 7, 2017

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

by Cyril Ferlicot D.

Le 05/10/2017 Ã 15:46, Holger Freyther a Ã©critÂ : > > Hi! > > > 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 > > Hi, Maybe the instructions for CentOS and RHEL could be added to the linux download page of pharo.org? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Oct. 7, 2017

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

by Denis Kudriashov

Hi Peter. You should stub instance instead of class: s := Something new. s stub askFor... 7 Ð¾ÐºÑ. 2017 Ð³. 9:18 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Peter UhnÃ¡k" <i.uhnak(a)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 > >

Oct. 7, 2017

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

by Dimitris Chloupis

The dicussion is about Pharo's live coding and OOP compared to other languages. IF you look at all my threads you will see I ALWAYS mention Python , Blender , Unreal for relevant topics. I do not remember hi jackig a thread with random remarks just for the shake of mentioning those things. Plus 99% of the times I mention Python is about Atlas , my library for using Python libraries from inside Pharo. Atlas is a "trojan horse" for Pharo to invade Python projects. Also I have been very clear that I consider C++ an abomination syntax wise and Python weaker than Smalltalk, language wise.Mainly because of Smalltalk's minimal syntax and of course offering live coding outside the box with no special setup from the coder. 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++. Is it as easy or as flexible as Pharo ? I do not know because live coding as you know is about workflow and we dont code all the same way. For example I was never comfortable with coding solely from inside Pharo debugger as some of you are doing. I am more a Class Browser guy and I rarely use Workspace/Playground/REPL as well. My questions were sincere even though I was sarcastic because I always want to learn more about live coding and things I do not know about OOP. My sarcasm was an effort to be funny not to be rude. I am also certain that many experienced coders coming from other language will ask the same questions as well. What Pharo can give me OO wise that I cannot get in my X language ? What exactly is live coding for Pharo ? Is doing X things in that Y language live coding or is it something else ? What's the real purpose of message passing ? How it benefits me compared to just using method calls ? I am suprised that there has not been an article about live coding workflows. I think it could greatly benefit Pharo to demostrate its uniqueness. People prefer to be shown that something is better than being told. Most people also not bother at all coming to the mailing list and ask questions, they will ignore things they dont understand and carry on. So its not important to say that Pharo special but why Pharo is special and after 5 year I feel will still struggle in this area, not because of the fault of the community but because live coding and OOP can be an extremely wide field that you can easily get lost into. We have also to be fair with othe programming languages, respect them, to the degree they deserve our respect and not exaggerate our claims because that harms Pharo reputation. On Sat, Oct 7, 2017 at 11:50 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Your contribution to Pharo are much appreciated. And indeed you did not > directly say anything negative. > > But you have to agree that you often discuss about Python, C++, Blender, > ... in mailing lists that are not for that purpose. You are absolutely free > to do whatever you want and to give your opinions freely, but this is not > the right place. > > > On 7 Oct 2017, at 10:42, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > I agree, ignore that crazy dude that he is all talk and non sense > excluding the fact the original article uses a graphic he made with love > for Pharo and with over 5 years of active contribution to Pharo > documentation and libraries. OR the fact that he said nothing negative > about Pharo in this thread. > > > > Or the fact that he said that is enternal greatful for Pharo introducing > him to the art and fun of live coding. What's more negative than that , > right ? > > > > On Sat, Oct 7, 2017 at 11:14 AM Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > > Hi sven > > > > Do the same than me, trash this thread and let us focus on making Pharo > better. > > This is far better productive and energy positive. > > > > Stef > > > > On Sat, Oct 7, 2017 at 12:16 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > Yes, you are right: Pharo/Smalltalk is more or less the same as > Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding. > > > > > > Come on. > > > > > >> On 6 Oct 2017, at 23:18, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > >> > > >> Wise not to mention Ruby and Python and Pick the worst of the worst > in OOP. Because frankly the competition for Pharo against those two > behemoths can be quite brutal in the flexibility and power of OOP. > > >> > > >> And no , these language can do live coding with ease. I know because > I currently code live coding style with Python for an app I am making. Sure > it wont provide you with a live system out of the box, but put in 10 lines > of code and you already ready to go with hardcore live coding. At least > Python , Ruby being practically a rip off of Smalltalk language may need > even less. > > >> > > >> iPython which by the way is by far the most popular Python tool is > the real deal, a full blow live coding enviroment. > > >> > > >> To my suprise its not even hard to do live coding with C/C++ > including using image format. To my shock live coding is actually supported > by both the OS and the hardware. Hardware has its own exception system , OS > has an image flie format called "memory mapped files" used for DLLs and a > lot of essential functionality. > > >> > > >> For some weird reason however its well hidden and not that much > utilised by coders. They really love long compile times, dont ask me why. > > >> > > >> But yeah C++ even though it has come a long way with its template > system, its still the king of ugly. That sytax, oh the horrors of that > syntax..... yiaks !!! > > >> > > >> I am so enternal greatful that Pharo introduced me to live coding and > opened my eyes to universe of fun and productivity. I cannot imagine coding > an other way ever again. > > >> > > >> I really hope that we take this further though. > > >> > > >> On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com> > wrote: > > >> Behold Pharo: The Modern Smalltalk > > >> < > https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c… > > > > >> > > >> If you would like to suggest some edits, I'm all ears. Anything to > improve > > >> the impact of the article. > > >> > > >> Thanks. > > >> > > >> > > >> > > >> -- > > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > >> > > > > > > > > > > >

Oct. 7, 2017

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

by Sven Van Caekenberghe

Your contribution to Pharo are much appreciated. And indeed you did not directly say anything negative. But you have to agree that you often discuss about Python, C++, Blender, ... in mailing lists that are not for that purpose. You are absolutely free to do whatever you want and to give your opinions freely, but this is not the right place. > On 7 Oct 2017, at 10:42, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > I agree, ignore that crazy dude that he is all talk and non sense excluding the fact the original article uses a graphic he made with love for Pharo and with over 5 years of active contribution to Pharo documentation and libraries. OR the fact that he said nothing negative about Pharo in this thread. > > Or the fact that he said that is enternal greatful for Pharo introducing him to the art and fun of live coding. What's more negative than that , right ? > > On Sat, Oct 7, 2017 at 11:14 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi sven > > Do the same than me, trash this thread and let us focus on making Pharo better. > This is far better productive and energy positive. > > Stef > > On Sat, Oct 7, 2017 at 12:16 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Yes, you are right: Pharo/Smalltalk is more or less the same as Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding. > > > > Come on. > > > >> On 6 Oct 2017, at 23:18, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > >> > >> Wise not to mention Ruby and Python and Pick the worst of the worst in OOP. Because frankly the competition for Pharo against those two behemoths can be quite brutal in the flexibility and power of OOP. > >> > >> And no , these language can do live coding with ease. I know because I currently code live coding style with Python for an app I am making. Sure it wont provide you with a live system out of the box, but put in 10 lines of code and you already ready to go with hardcore live coding. At least Python , Ruby being practically a rip off of Smalltalk language may need even less. > >> > >> iPython which by the way is by far the most popular Python tool is the real deal, a full blow live coding enviroment. > >> > >> To my suprise its not even hard to do live coding with C/C++ including using image format. To my shock live coding is actually supported by both the OS and the hardware. Hardware has its own exception system , OS has an image flie format called "memory mapped files" used for DLLs and a lot of essential functionality. > >> > >> For some weird reason however its well hidden and not that much utilised by coders. They really love long compile times, dont ask me why. > >> > >> But yeah C++ even though it has come a long way with its template system, its still the king of ugly. That sytax, oh the horrors of that syntax..... yiaks !!! > >> > >> I am so enternal greatful that Pharo introduced me to live coding and opened my eyes to universe of fun and productivity. I cannot imagine coding an other way ever again. > >> > >> I really hope that we take this further though. > >> > >> On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com> wrote: > >> Behold Pharo: The Modern Smalltalk > >> <https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c…> > >> > >> If you would like to suggest some edits, I'm all ears. Anything to improve > >> the impact of the article. > >> > >> Thanks. > >> > >> > >> > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> > > > > >

Oct. 7, 2017

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

by Dimitris Chloupis

I agree, ignore that crazy dude that he is all talk and non sense excluding the fact the original article uses a graphic he made with love for Pharo and with over 5 years of active contribution to Pharo documentation and libraries. OR the fact that he said nothing negative about Pharo in this thread. Or the fact that he said that is enternal greatful for Pharo introducing him to the art and fun of live coding. What's more negative than that , right ? On Sat, Oct 7, 2017 at 11:14 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi sven > > Do the same than me, trash this thread and let us focus on making Pharo > better. > This is far better productive and energy positive. > > Stef > > On Sat, Oct 7, 2017 at 12:16 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Yes, you are right: Pharo/Smalltalk is more or less the same as > Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding. > > > > Come on. > > > >> On 6 Oct 2017, at 23:18, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> > >> Wise not to mention Ruby and Python and Pick the worst of the worst in > OOP. Because frankly the competition for Pharo against those two behemoths > can be quite brutal in the flexibility and power of OOP. > >> > >> And no , these language can do live coding with ease. I know because I > currently code live coding style with Python for an app I am making. Sure > it wont provide you with a live system out of the box, but put in 10 lines > of code and you already ready to go with hardcore live coding. At least > Python , Ruby being practically a rip off of Smalltalk language may need > even less. > >> > >> iPython which by the way is by far the most popular Python tool is the > real deal, a full blow live coding enviroment. > >> > >> To my suprise its not even hard to do live coding with C/C++ including > using image format. To my shock live coding is actually supported by both > the OS and the hardware. Hardware has its own exception system , OS has an > image flie format called "memory mapped files" used for DLLs and a lot of > essential functionality. > >> > >> For some weird reason however its well hidden and not that much > utilised by coders. They really love long compile times, dont ask me why. > >> > >> But yeah C++ even though it has come a long way with its template > system, its still the king of ugly. That sytax, oh the horrors of that > syntax..... yiaks !!! > >> > >> I am so enternal greatful that Pharo introduced me to live coding and > opened my eyes to universe of fun and productivity. I cannot imagine coding > an other way ever again. > >> > >> I really hope that we take this further though. > >> > >> On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com> > wrote: > >> Behold Pharo: The Modern Smalltalk > >> < > https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c… > > > >> > >> If you would like to suggest some edits, I'm all ears. Anything to > improve > >> the impact of the article. > >> > >> Thanks. > >> > >> > >> > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> > > > > > >

Oct. 7, 2017

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

by Sven Van Caekenberghe

> On 7 Oct 2017, at 10:15, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >> To be honest, I didn't know you could do live coding in Python, Ruby, C/C++. >> I had only ever heard of "hot swapping" in Java. > > Me neither :) > Do not worry and let us continue to work on making Pharo better. > I did not know that a.out and core.dmp where live programming :) With gdb and assembler you can do live coding & OOP too ;-) > Stef > >> At any rate, I'd be surprised if live coding in these languages was as easy >> and convenient as in Pharo/Smalltalk. > > Me too but they are catching up so let us continue to make Pharo super cool. >

Oct. 7, 2017

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

by Stephane Ducasse

> To be honest, I didn't know you could do live coding in Python, Ruby, C/C++. > I had only ever heard of "hot swapping" in Java. Me neither :) Do not worry and let us continue to work on making Pharo better. I did not know that a.out and core.dmp where live programming :) Stef > At any rate, I'd be surprised if live coding in these languages was as easy > and convenient as in Pharo/Smalltalk. Me too but they are catching up so let us continue to make Pharo super cool.

Oct. 7, 2017

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

by Stephane Ducasse

Hi sven Do the same than me, trash this thread and let us focus on making Pharo better. This is far better productive and energy positive. Stef On Sat, Oct 7, 2017 at 12:16 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, you are right: Pharo/Smalltalk is more or less the same as Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding. > > Come on. > >> On 6 Oct 2017, at 23:18, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> Wise not to mention Ruby and Python and Pick the worst of the worst in OOP. Because frankly the competition for Pharo against those two behemoths can be quite brutal in the flexibility and power of OOP. >> >> And no , these language can do live coding with ease. I know because I currently code live coding style with Python for an app I am making. Sure it wont provide you with a live system out of the box, but put in 10 lines of code and you already ready to go with hardcore live coding. At least Python , Ruby being practically a rip off of Smalltalk language may need even less. >> >> iPython which by the way is by far the most popular Python tool is the real deal, a full blow live coding enviroment. >> >> To my suprise its not even hard to do live coding with C/C++ including using image format. To my shock live coding is actually supported by both the OS and the hardware. Hardware has its own exception system , OS has an image flie format called "memory mapped files" used for DLLs and a lot of essential functionality. >> >> For some weird reason however its well hidden and not that much utilised by coders. They really love long compile times, dont ask me why. >> >> But yeah C++ even though it has come a long way with its template system, its still the king of ugly. That sytax, oh the horrors of that syntax..... yiaks !!! >> >> I am so enternal greatful that Pharo introduced me to live coding and opened my eyes to universe of fun and productivity. I cannot imagine coding an other way ever again. >> >> I really hope that we take this further though. >> >> On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com> wrote: >> Behold Pharo: The Modern Smalltalk >> <https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c…> >> >> If you would like to suggest some edits, I'm all ears. Anything to improve >> the impact of the article. >> >> Thanks. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

Oct. 7, 2017

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

by Stephane Ducasse

+ 1000 :) On Sat, Oct 7, 2017 at 9:44 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2017-10-07 9:38 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> 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. > > > > Starting images for different vms works great. > No more need to manually fight with downloading vms or source files :) > Great! > >> >> >> 2017-10-06 22:43 GMT+02:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: >>> >>> I've tried running it from the terminal and it works!. >>> >>> If I double-click it from the file manager and choose "Run in Terminal" >>> it gives the previously commented error. >>> >>> >>> >>> 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. >>>> >>>> >>>> Strange indeed! >>>> Iâm not able to reproduce it on my ubuntu vm. >>>> >>>> Itâs surprising that sources file is search in the folder of the VM >>>> shipped with the launcher. Images are run with VM downloaded in the VM store >>>> ($HOME/Pharo/vms) and sources file is search in the vm directory. >>>> Could you tell me if you run the launcher from a terminal? Could you >>>> send me your environment variables to see if I can find something relevant >>>> there? >>> >>> >> >

Oct. 7, 2017

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

by Nicolai Hess

2017-10-07 9:38 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > 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. > Starting images for different vms works great. No more need to manually fight with downloading vms or source files :) Great! > > 2017-10-06 22:43 GMT+02:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: > >> I've tried running it from the terminal and it works!. >> >> If I double-click it from the file manager and choose "Run in Terminal" >> it gives the previously commented error. >> >> >> >> 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.* >>> >>> >>> Strange indeed! >>> Iâm not able to reproduce it on my ubuntu vm. >>> >>> Itâs surprising that sources file is search in the folder of the VM >>> shipped with the launcher. Images are run with VM downloaded in the VM >>> store ($HOME/Pharo/vms) and sources file is search in the vm directory. >>> Could you tell me if you run the launcher from a terminal? Could you >>> send me your environment variables to see if I can find something relevant >>> there? >>> >> >> >

Oct. 7, 2017

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

by Nicolai Hess

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. 2017-10-06 22:43 GMT+02:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: > I've tried running it from the terminal and it works!. > > If I double-click it from the file manager and choose "Run in Terminal" it > gives the previously commented error. > > > > 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.* >> >> >> Strange indeed! >> Iâm not able to reproduce it on my ubuntu vm. >> >> Itâs surprising that sources file is search in the folder of the VM >> shipped with the launcher. Images are run with VM downloaded in the VM >> store ($HOME/Pharo/vms) and sources file is search in the vm directory. >> Could you tell me if you run the launcher from a terminal? Could you send >> me your environment variables to see if I can find something relevant there? >> > >

Oct. 7, 2017

using mocketry to mock subcall

by Peter UhnÃ¡k

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

Oct. 7, 2017

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

by Dimitris Chloupis

Again very generic statements , and I see you refer to tools and libraries instead of OOP. We talking here Pharo vs Python on the language level because Python obviously does not come with an IDE. But then Pharo does not come with literate programming tools or libraries as well. I rather not go down the rabbit hole of third party libraries because obviously I cannot participate in a discussion about libraries and areas of coding, I know nothing about. Plus Python has countless of libraries which makes a very longer discussion even if I was familiar with them and Pharo has much less but still quite a lot of libraries as well. On Sat, 7 Oct 2017 at 04:46, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Hi, > > > On 06/10/17 20:41, Dimitris Chloupis wrote: > > I am no expert in OOP but I cannot say I have found a thing that Pharo > > can do that Python canât or is more difficult. Python obviously is > > very heavily inspired by Smalltalk . > > I can find one: creating an environment for reproducible research and > literate computing (interactive documentation). It can be done on both, > but is harder and a lot more complicated in Python that in Pharo, as > experience have shown [1] > > [1] > > http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… > > Cheers, > > Offray > >

Oct. 7, 2017

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

by Dimitris Chloupis

Care to explain what difficulty you experienced in live coding with Python. Or what Pharo can do that Python canât live code wise ? Maybe I will learn something. On Sat, 7 Oct 2017 at 04:36, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Well IPython is not near to Pharo in terms of flexibility and live coding, > and I have been a user of it. For example, recently we made a whole book 13 > Mb PDF book in a single Grafoscopio file of just ~600k, with a pretty good > layout and final design (more details in other recent thread and in [1]). > JupyterLab[2] is going in the direction of becoming a more complete IDE, > but there are still a lot of stuff that is better done in Pharo, like unit > testing, that in JupyterLab. In fact Brian Granger has told that the "I" is > for interactive, not for integrated [3]. Of course, after over a decade of > hard work and several millions of dollars, Jupyter is doing pretty well on > the interactive notebooks front, but Pharo's edge in live coding and > moldability, plus a superb small, agile and friendly community allowed a > beginner to prototype valuable propositions about reproducible research and > computer storytelling, without such background. > [1] http://mutabit.com/repos.fossil/mapeda/ > [2] http://jupyterlab.github.io/ > [3] https://www.youtube.com/watch?v=Ejh0ftSjk6g > > So, I have experienced live coding in IPython/Jupyter and > Pharo/Grafoscopio and still I think that Pharo has value proposals hard to > find on any behemoths. Live coding there is getting good, but Pharo is even > better, and that plus moldability make Pharo unbeatable, when you're > changing/exploring a running system. > > Cheers, > > Offray > > > On 06/10/17 16:18, Dimitris Chloupis wrote: > > Wise not to mention Ruby and Python and Pick the worst of the worst in > OOP. Because frankly the competition for Pharo against those two behemoths > can be quite brutal in the flexibility and power of OOP. > > And no , these language can do live coding with ease. I know because I > currently code live coding style with Python for an app I am making. Sure > it wont provide you with a live system out of the box, but put in 10 lines > of code and you already ready to go with hardcore live coding. At least > Python , Ruby being practically a rip off of Smalltalk language may need > even less. > > iPython which by the way is by far the most popular Python tool is the > real deal, a full blow live coding enviroment. > > To my suprise its not even hard to do live coding with C/C++ including > using image format. To my shock live coding is actually supported by both > the OS and the hardware. Hardware has its own exception system , OS has an > image flie format called "memory mapped files" used for DLLs and a lot of > essential functionality. > > For some weird reason however its well hidden and not that much utilised > by coders. They really love long compile times, dont ask me why. > > But yeah C++ even though it has come a long way with its template system, > its still the king of ugly. That sytax, oh the horrors of that syntax..... > yiaks !!! > > I am so enternal greatful that Pharo introduced me to live coding and > opened my eyes to universe of fun and productivity. I cannot imagine coding > an other way ever again. > > I really hope that we take this further though. > > On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com> wrote: > >> Behold Pharo: The Modern Smalltalk >> < >> https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c… >> > >> >> If you would like to suggest some edits, I'm all ears. Anything to improve >> the impact of the article. >> >> Thanks. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >

Oct. 7, 2017

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

by Dimitris Chloupis

Well any code you execute right now is to a degree live code. DLL are dynamically loaded libraries which means you reload code real time. DLLs are everywhere and of course even Pharo heavily relies on them. Yes in Python live coding is as easy , I already explained in previous post. On Sat, 7 Oct 2017 at 01:51, horrido <horrido.hobbies(a)gmail.com> wrote: > To be honest, I didn't know you could do live coding in Python, Ruby, > C/C++. > I had only ever heard of "hot swapping" in Java. > > At any rate, I'd be surprised if live coding in these languages was as easy > and convenient as in Pharo/Smalltalk. > > > > Sven Van Caekenberghe-2 wrote > > Yes, you are right: Pharo/Smalltalk is more or less the same as > > Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live > > coding. > > > > Come on. > > > >> On 6 Oct 2017, at 23:18, Dimitris Chloupis < > > > kilon.alios@ > > > > wrote: > >> > >> Wise not to mention Ruby and Python and Pick the worst of the worst in > >> OOP. Because frankly the competition for Pharo against those two > >> behemoths can be quite brutal in the flexibility and power of OOP. > >> > >> And no , these language can do live coding with ease. I know because I > >> currently code live coding style with Python for an app I am making. > Sure > >> it wont provide you with a live system out of the box, but put in 10 > >> lines of code and you already ready to go with hardcore live coding. At > >> least Python , Ruby being practically a rip off of Smalltalk language > may > >> need even less. > >> > >> iPython which by the way is by far the most popular Python tool is the > >> real deal, a full blow live coding enviroment. > >> > >> To my suprise its not even hard to do live coding with C/C++ including > >> using image format. To my shock live coding is actually supported by > both > >> the OS and the hardware. Hardware has its own exception system , OS has > >> an image flie format called "memory mapped files" used for DLLs and a > lot > >> of essential functionality. > >> > >> For some weird reason however its well hidden and not that much utilised > >> by coders. They really love long compile times, dont ask me why. > >> > >> But yeah C++ even though it has come a long way with its template > system, > >> its still the king of ugly. That sytax, oh the horrors of that > >> syntax..... yiaks !!! > >> > >> I am so enternal greatful that Pharo introduced me to live coding and > >> opened my eyes to universe of fun and productivity. I cannot imagine > >> coding an other way ever again. > >> > >> I really hope that we take this further though. > >> > >> On Wed, Oct 4, 2017 at 1:31 PM horrido < > > > horrido.hobbies@ > > > > wrote: > >> Behold Pharo: The Modern Smalltalk > >> < > https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c… > ; > >> > >> If you would like to suggest some edits, I'm all ears. Anything to > >> improve > >> the impact of the article. > >> > >> Thanks. > >> > >> > >> > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 7, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 06/10/17 20:41, Dimitris Chloupis wrote: > I am no expert in OOP but I cannot say I have found a thing that Pharo > can do that Python canât or is more difficult. Python obviously is > very heavily inspired by Smalltalk . I can find one: creating an environment for reproducible research and literate computing (interactive documentation). It can be done on both,Â but is harder and a lot more complicated in Python that in Pharo, as experience have shown [1] [1] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-ini… Cheers, Offray

Oct. 7, 2017

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

by Dimitris Chloupis

Well live coding is a simple process of reloading code. In Pharo the VM recompiles a method and replace itâs old instance with a new one while code executes. Python you basically reload the module. Because Python does not compile per method but per module which means executing code lively. This happens because when you import a module in Python, Python does nothing special than executing the source code. Not before compilation but during execution. Hence live coding, the Python VM replaces objects lively. Python can also compile any size of code including individual methods. That happens with one line of code importlib.reload(mymodule) The next challenge in live coding is capture the error and not allowing the app to exit, that is 2 lines of code and is a python exception. Python exceptions are heavily used in Python to capture errors. Debugging is up to the debugger that Python provides as a library with conditional breakpoints and fully integrated . You can of course ask at any point for any kind of context, global , local, arguments , instance and class variables. The debugger also comes with its own REPL. Again everything is an object. OOP wise , in Python everything is an object including procedure. Procedures like blocks in Pharo are objects with one method. Procedures are anonymous but if the name really bothers you you can use lamba functions. Python has bigger syntax than Pharo but anything can be implemented as an object. Global variables are objects, imported modules are objects etc. Reflection wise , Python is a fully reflective an object can ask itself or others about its live state, methods, bytecode and source code. Meta programming wiseython allows for fully manipulation of objects down to bytecode level. Python has no need for traits because it allows the live replacement of its methods with procedures or methods from other objects. Finally like Pharo , Python comes with a very powerful AST library capable of fully manipulating the syntax . HyLang is a Lisp made in Python that compiles to Python bytecode and can use any Python library. The one thing Python cannot do at least out of the box is privacy. In Pharo everything is private , methods hide behind messages , variables behind methods. In Python everything is public and privacy is annotated in naming only using double underscores. Python also has properties which are methods that override variable assignment , similarly how we use getter and sender methods for object variables in Pharo. What Python recently got has been optional static types but I am not sure if they are real static types , because I am not a fan of static typing anyway. I am no expert in OOP but I cannot say I have found a thing that Pharo can do that Python canât or is more difficult. Python obviously is very heavily inspired by Smalltalk . The very brief look I gave Ruby looked to me that it is even closer to Smalltalk. On Sat, 7 Oct 2017 at 01:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, you are right: Pharo/Smalltalk is more or less the same as > Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding. > > Come on. > > > On 6 Oct 2017, at 23:18, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > Wise not to mention Ruby and Python and Pick the worst of the worst in > OOP. Because frankly the competition for Pharo against those two behemoths > can be quite brutal in the flexibility and power of OOP. > > > > And no , these language can do live coding with ease. I know because I > currently code live coding style with Python for an app I am making. Sure > it wont provide you with a live system out of the box, but put in 10 lines > of code and you already ready to go with hardcore live coding. At least > Python , Ruby being practically a rip off of Smalltalk language may need > even less. > > > > iPython which by the way is by far the most popular Python tool is the > real deal, a full blow live coding enviroment. > > > > To my suprise its not even hard to do live coding with C/C++ including > using image format. To my shock live coding is actually supported by both > the OS and the hardware. Hardware has its own exception system , OS has an > image flie format called "memory mapped files" used for DLLs and a lot of > essential functionality. > > > > For some weird reason however its well hidden and not that much utilised > by coders. They really love long compile times, dont ask me why. > > > > But yeah C++ even though it has come a long way with its template > system, its still the king of ugly. That sytax, oh the horrors of that > syntax..... yiaks !!! > > > > I am so enternal greatful that Pharo introduced me to live coding and > opened my eyes to universe of fun and productivity. I cannot imagine coding > an other way ever again. > > > > I really hope that we take this further though. > > > > On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com> > wrote: > > Behold Pharo: The Modern Smalltalk > > < > https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c… > > > > > > If you would like to suggest some edits, I'm all ears. Anything to > improve > > the impact of the article. > > > > Thanks. > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > >

Oct. 7, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

Well IPython is not near to Pharo in terms of flexibility and live coding, and I have been a user of it. For example, recently we made a whole book 13 Mb PDF book in a single Grafoscopio file of just ~600k, with a pretty good layout and final design (more details in other recent thread and in [1]). JupyterLab[2] is going in the direction of becoming a more complete IDE, but there are still a lot of stuff that is better done in Pharo, like unit testing, that in JupyterLab. In fact Brian Granger has told that the "I" is for interactive, not for integrated [3]. Of course, after over a decade of hard work and several millions of dollars, Jupyter is doing pretty well on the interactive notebooks front, but Pharo's edge in live coding and moldability, plus a superb small, agile and friendly community allowed a beginner to prototype valuable propositions about reproducible research and computer storytelling, without such background. [1] http://mutabit.com/repos.fossil/mapeda/ [2] http://jupyterlab.github.io/ [3] https://www.youtube.com/watch?v=Ejh0ftSjk6g So, I have experienced live coding in IPython/Jupyter and Pharo/Grafoscopio and still I think that Pharo has value proposals hard to find on any behemoths. Live coding there is getting good, but Pharo is even better, and that plus moldability make Pharo unbeatable, when you're changing/exploring a running system. Cheers, Offray On 06/10/17 16:18, Dimitris Chloupis wrote: > Wise not to mention Ruby and Python and Pick the worst of the worst in > OOP. Because frankly the competition for Pharo against those two > behemoths can be quite brutal in the flexibility and power of OOP.Â > > And no , these language can do live coding with ease. I know because I > currently code live coding style with Python for an app I am making. > Sure it wont provide you with a live system out of the box, but put in > 10 lines of code and you already ready to go with hardcore live > coding. At least Python , Ruby being practically a rip off of > Smalltalk language may need even less.Â > > iPython which by the way is by far the most popular Python tool is the > real deal, a full blow live coding enviroment.Â > > To my suprise its not even hard to do live coding with C/C++ including > using image format. To my shock live coding is actually supported by > both the OS and the hardware. Hardware has its own exception system , > OS has an image flie format called "memory mapped files" used for DLLs > and a lot of essential functionality.Â > > For some weird reason however its well hidden and not that much > utilised by coders. They really love long compile times, dont ask me why.Â > > But yeah C++ even though it has come a long way with its template > system, its still the king of ugly. That sytax, oh the horrors of that > syntax..... yiaks !!! > > I am so enternal greatful that Pharo introduced me to live coding and > opened my eyes to universe of fun and productivity. I cannot imagine > coding an other way ever again.Â > > I really hope that we take this further though.Â > > On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com > <mailto:horrido.hobbies@gmail.com>> wrote: > > Behold Pharo: The Modern Smalltalk > <https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c…> > > If you would like to suggest some edits, I'm all ears. Anything to > improve > the impact of the article. > > Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Oct. 7, 2017

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

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > But the point remains, given an image and all our tools, why go to the > web. It seems like the value would be more as a PR tool than a development tool. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 7, 2017

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

by horrido

To be honest, I didn't know you could do live coding in Python, Ruby, C/C++. I had only ever heard of "hot swapping" in Java. At any rate, I'd be surprised if live coding in these languages was as easy and convenient as in Pharo/Smalltalk. Sven Van Caekenberghe-2 wrote > Yes, you are right: Pharo/Smalltalk is more or less the same as > Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live > coding. > > Come on. > >> On 6 Oct 2017, at 23:18, Dimitris Chloupis < > kilon.alios@ > > wrote: >> >> Wise not to mention Ruby and Python and Pick the worst of the worst in >> OOP. Because frankly the competition for Pharo against those two >> behemoths can be quite brutal in the flexibility and power of OOP. >> >> And no , these language can do live coding with ease. I know because I >> currently code live coding style with Python for an app I am making. Sure >> it wont provide you with a live system out of the box, but put in 10 >> lines of code and you already ready to go with hardcore live coding. At >> least Python , Ruby being practically a rip off of Smalltalk language may >> need even less. >> >> iPython which by the way is by far the most popular Python tool is the >> real deal, a full blow live coding enviroment. >> >> To my suprise its not even hard to do live coding with C/C++ including >> using image format. To my shock live coding is actually supported by both >> the OS and the hardware. Hardware has its own exception system , OS has >> an image flie format called "memory mapped files" used for DLLs and a lot >> of essential functionality. >> >> For some weird reason however its well hidden and not that much utilised >> by coders. They really love long compile times, dont ask me why. >> >> But yeah C++ even though it has come a long way with its template system, >> its still the king of ugly. That sytax, oh the horrors of that >> syntax..... yiaks !!! >> >> I am so enternal greatful that Pharo introduced me to live coding and >> opened my eyes to universe of fun and productivity. I cannot imagine >> coding an other way ever again. >> >> I really hope that we take this further though. >> >> On Wed, Oct 4, 2017 at 1:31 PM horrido < > horrido.hobbies@ > > wrote: >> Behold Pharo: The Modern Smalltalk >> <https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c46053> >> >> If you would like to suggest some edits, I'm all ears. Anything to >> improve >> the impact of the article. >> >> Thanks. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

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

by Sven Van Caekenberghe

Yes, you are right: Pharo/Smalltalk is more or less the same as Ruby/Python/C/C++ in terms of power & flexibility of OOP and in live coding. Come on. > On 6 Oct 2017, at 23:18, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Wise not to mention Ruby and Python and Pick the worst of the worst in OOP. Because frankly the competition for Pharo against those two behemoths can be quite brutal in the flexibility and power of OOP. > > And no , these language can do live coding with ease. I know because I currently code live coding style with Python for an app I am making. Sure it wont provide you with a live system out of the box, but put in 10 lines of code and you already ready to go with hardcore live coding. At least Python , Ruby being practically a rip off of Smalltalk language may need even less. > > iPython which by the way is by far the most popular Python tool is the real deal, a full blow live coding enviroment. > > To my suprise its not even hard to do live coding with C/C++ including using image format. To my shock live coding is actually supported by both the OS and the hardware. Hardware has its own exception system , OS has an image flie format called "memory mapped files" used for DLLs and a lot of essential functionality. > > For some weird reason however its well hidden and not that much utilised by coders. They really love long compile times, dont ask me why. > > But yeah C++ even though it has come a long way with its template system, its still the king of ugly. That sytax, oh the horrors of that syntax..... yiaks !!! > > I am so enternal greatful that Pharo introduced me to live coding and opened my eyes to universe of fun and productivity. I cannot imagine coding an other way ever again. > > I really hope that we take this further though. > > On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com> wrote: > Behold Pharo: The Modern Smalltalk > <https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c…> > > If you would like to suggest some edits, I'm all ears. Anything to improve > the impact of the article. > > Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Oct. 6, 2017

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

by Dimitris Chloupis

Wise not to mention Ruby and Python and Pick the worst of the worst in OOP. Because frankly the competition for Pharo against those two behemoths can be quite brutal in the flexibility and power of OOP. And no , these language can do live coding with ease. I know because I currently code live coding style with Python for an app I am making. Sure it wont provide you with a live system out of the box, but put in 10 lines of code and you already ready to go with hardcore live coding. At least Python , Ruby being practically a rip off of Smalltalk language may need even less. iPython which by the way is by far the most popular Python tool is the real deal, a full blow live coding enviroment. To my suprise its not even hard to do live coding with C/C++ including using image format. To my shock live coding is actually supported by both the OS and the hardware. Hardware has its own exception system , OS has an image flie format called "memory mapped files" used for DLLs and a lot of essential functionality. For some weird reason however its well hidden and not that much utilised by coders. They really love long compile times, dont ask me why. But yeah C++ even though it has come a long way with its template system, its still the king of ugly. That sytax, oh the horrors of that syntax..... yiaks !!! I am so enternal greatful that Pharo introduced me to live coding and opened my eyes to universe of fun and productivity. I cannot imagine coding an other way ever again. I really hope that we take this further though. On Wed, Oct 4, 2017 at 1:31 PM horrido <horrido.hobbies(a)gmail.com> wrote: > Behold Pharo: The Modern Smalltalk > < > https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c… > > > > If you would like to suggest some edits, I'm all ears. Anything to improve > the impact of the article. > > Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 6, 2017

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

by Gabriel Cotelli

I've tried running it from the terminal and it works!. If I double-click it from the file manager and choose "Run in Terminal" it gives the previously commented error. 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.* > > > Strange indeed! > Iâm not able to reproduce it on my ubuntu vm. > > Itâs surprising that sources file is search in the folder of the VM > shipped with the launcher. Images are run with VM downloaded in the VM > store ($HOME/Pharo/vms) and sources file is search in the vm directory. > Could you tell me if you run the launcher from a terminal? Could you send > me your environment variables to see if I can find something relevant there? >

Oct. 6, 2017

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

by Christophe Demarey

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. Strange indeed! Iâm not able to reproduce it on my ubuntu vm. Itâs surprising that sources file is search in the folder of the VM shipped with the launcher. Images are run with VM downloaded in the VM store ($HOME/Pharo/vms) and sources file is search in the vm directory. Could you tell me if you run the launcher from a terminal? Could you send me your environment variables to see if I can find something relevant there?

Oct. 6, 2017

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

by Richard Sargent

Yes. We have tools that are *designed* for reading code and understanding it. But, let's have a ton of dead bits instead. On Oct 6, 2017, 15:35, at 15:35, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >To get dead objects while we have them live :) > >On Fri, Oct 6, 2017 at 8:48 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >wrote: >> >> >>> On 6 Oct 2017, at 19:57, Sean P. DeNigris <sean(a)clipperadams.com> >wrote: >>> >>> Maybe this [1] or this [2] (the two might be the same thing) >>> >>> 1. http://forum.world.st/Online-Pharo-Documentation-tp3468690.html >>> 2. http://forum.world.st/webdoc-tt3654967.html >> >> >http://files.pharo.org/doc/4.0/#classList=package/Kernel.html&packageList=p… >> >> This is only up to Pharo 4. >> >> But the point remains, given an image and all our tools, why go to >the web. >> >> >> >>

Oct. 6, 2017

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

by Stephane Ducasse

To get dead objects while we have them live :) On Fri, Oct 6, 2017 at 8:48 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 6 Oct 2017, at 19:57, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Maybe this [1] or this [2] (the two might be the same thing) >> >> 1. http://forum.world.st/Online-Pharo-Documentation-tp3468690.html >> 2. http://forum.world.st/webdoc-tt3654967.html > > http://files.pharo.org/doc/4.0/#classList=package/Kernel.html&packageList=p… > > This is only up to Pharo 4. > > But the point remains, given an image and all our tools, why go to the web. > > > >

Oct. 6, 2017

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

by Peter UhnÃ¡k

+1.0.1 :-) > Pharo Launcher files (images, VMs) are now considered as user Documents (easier to find). Consequently, they are now stored in the standard documents folder, i.e. > *$HOME/Pharo* This seems like a step backwards. The expected location is $XDG_DATA_HOME/Pharo . Is it possible to change or configure this? Peter On Fri, Oct 6, 2017 at 7:47 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote > > Tx Christophe > > +100. Launcher has become indispensable! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 6, 2017

[ANN] OSSubprocess Bugfix and enhancements release

by Mariano Martinez Peck

Dear all, I have just released a new bugfix and enhancements release v0.2.5 for OSSubprocess as you can see in [1]. This new release is thanks to the awesome work of Guillermo Polito [2]. He found a problem (and a fix) that would hung/block the Pharo image in a wait state. This problem has been forever and I have faced it myself. It would only happen when using #waitForExit and under certain scenario. Because of that, I recommend everyone to move to this release. Aside from that serious bug, he has also done quite some improvements in the tests and in the Travis setup. Once this PR [3] has been merged and SmalltalkCI updated, our Travis build [4] should show all green builds for Linux/OSX and Pharo 5.0 and 6.1. I have also copied the configuration into Pharo 5.0 and 6.0 catalog so as of tomorrow, it should be there. Cheers, [1] https://github.com/marianopeck/OSSubprocess/releases/tag/v0.2.5 [2] https://github.com/marianopeck/OSSubprocess/pull/25 [3] https://github.com/hpi-swa/smalltalkCI/pull/320 [4] https://travis-ci.org/marianopeck/OSSubprocess -- Mariano http://marianopeck.wordpress.com

Oct. 6, 2017

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

by Sven Van Caekenberghe

> On 6 Oct 2017, at 19:57, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Maybe this [1] or this [2] (the two might be the same thing) > > 1. http://forum.world.st/Online-Pharo-Documentation-tp3468690.html > 2. http://forum.world.st/webdoc-tt3654967.html http://files.pharo.org/doc/4.0/#classList=package/Kernel.html&packageList=p… This is only up to Pharo 4. But the point remains, given an image and all our tools, why go to the web.

Oct. 6, 2017

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

by Sean P. DeNigris

Maybe this [1] or this [2] (the two might be the same thing) 1. http://forum.world.st/Online-Pharo-Documentation-tp3468690.html 2. http://forum.world.st/webdoc-tt3654967.html ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

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

by Sean P. DeNigris

Stephane Ducasse-3 wrote > Tx Christophe +100. Launcher has become indispensable! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

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

by Hilaire

I think Laurent wrote something to export classes and documentation as html form to let user browse it. I have not idea where it is though. Hilaire Le 06/10/2017 Ã 14:54, horrido a Ã©critÂ : > *Then show me a link of the free, maintained reference documentation for the > classes that form âthe core libraryâ, like this one for Python > (https://docs.python.org/3/library/index.html)* -- Dr. Geo http://drgeo.eu

Oct. 6, 2017

Re: [Pharo-users] Organisation and workflows

by Stephane Ducasse

Super. Just do it :) and we will here to help you helping Pharo On Mon, Oct 2, 2017 at 5:40 PM, Steven R. Baker <steven(a)stevenrbaker.com> wrote: > > > On 02/10/17 15:28, Esteban Lorenzano wrote: >>> On 2 Oct 2017, at 15:12, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> I discussed with esteban sooner this summer and we really want to have a process >>> where people can deploy applications and not just code. >>> Now we are not yet there. >>> >>> Stef >>> >>> On Sun, Oct 1, 2017 at 9:03 PM, Steven R. Baker <steven(a)stevenrbaker.com> wrote: >>>> Heya folks, >>>> >>>> [Please jump on any of my statements that sound crazy: use of Spec, >>>> other assumptions, etc.] >>>> >>>> I'm starting an application in Pharo, using Spec. Basically, a GTD >>>> application in the spirit of nirvanahq, omnifocus, things, nozbe. The >>>> code is working just fine, but I'm left with a lot of questions about >>>> how to organize it. >>>> >>>> First, is there some trick to managing images? Are people using >>>> one-per-project, or one-per-computer? All of the above? Anyone using >>>> PharoLauncher these days? Other tools? >> pharo users tend to prefer one-per-project approach :) >> most people uses (or should use) pharo launcher. In fact, we want to make it the default download, is just that to get it right is complicated :) >> >> butâ¦ pharo launcher is to developers. A final app would require other stuff to be accomplished (like closing development tools, etc.). >> >>>> I'm assuming that the current state of the art is Iceberg; where can I >>>> find a "This is how you should organize your project using Iceberg" >>>> document, blog, book, tutorial, video, or otherwise. >> beware: Iceberg is a cvs (like Monticello or git or svnâ¦): it is use to store code, not to organise your project. >> To organise your project you have Metacello. >> >>>> Once the application is done, I assume I'll want to ship it in a minimal >>>> Pharo image. Is there documentation or prior art on this? >> this is what is hard :) >> I imagine with the headless VMs we are about to finish it will be easier (to just initiate a window with your app, instead initiate a window with the full world as now). >> but we still require some work. >> >>>> Finally, is there a way to run and capture keybindings globally? I have >>>> one part of my application (a quick-entry window) which I want summoned >>>> from a global (OS-wide) hotkey. Has this been done before? Or is it not >>>> easy to break the fourth wall, so to speak, and register a global >>>> keybinding from inside the VM? >> there is a keybindings framework inside pharo, but since you have a lot of development tools, it becomes hard to use (again, something that can be solved in the near future, with same approach as before, but not yet). >> now, to get the keybindings of the system you will need to install that *in* the system. >> >> for mac, for example, you can doit using the ObjC bridge (which does not works in 64bit images... Iâm working on a UFFI replacement, butâ¦ guess what? not yet :P) >> and I guess using UFFI you can get that to work on windows and linux? Iâm really donât know. >> >> all you ask is *doable*â¦ but not all your requirements are *easily* doable right now, which is want I want to fix :) > I don't mind contributing code and time on these things, as they present > real barriers to me. I'm looking for ways to get involved in the > community again. :) > > -Steven > >> Esteban >> >>>> Thanks! >>>> >>>> -Steven >>>> >>>> >>>> >> > >

Oct. 6, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Stephane Ducasse

Contact noury because I do not remember. But having a little builder is also nice. On Fri, Oct 6, 2017 at 4:15 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Stephane > > "Vitor why don't you take it as a small project to propose a solution for > Pharo." > > I will try :) I like the idea of using a Trait. > > > Em 6 de out de 2017 05:01, "Stephane Ducasse" <stepharo.self(a)gmail.com> > escreveu: > > Here is what I extracted from older emails > > From David Allouche in Pharo-dev to see if > The ==hash== method is used in Pharo to separate objects in > bucket-based data structures. > > > !! Property > > It must have one required property which is required data integrity: > > !!!! A. > Objects that are equal according to ==\=== must have equal hashes. > > > It should have two desirable properties that are required to support > the algorithmic assumptions of bucket-based data structures: > > !!!! B. > Objects that are not equal should have different hashes. Ideally, the > probability of hash collision should by 1/N where N is the size of > hash value space. > > !!!! C. The hash values should spread as much as possible over their > value space. For example: ProtoObject>>#identityHash. > > > > > How these two desirable properties can be implemented depends on the > actual distribution of the values used to compute the hash. > > An object can safely use XOR hashing if its instance variables are all > different objects that already provide a hash method with these two > properties. > > @@todo check following sentence because the use of singleton is obscure > > For example, an object whose behaviour is defined by several of > singleton delegates of different classes that do not override > Object>>#hash. > > But if the instance variables are not guaranteed to have those > properties, it is necessary to more thoroughly "mix the bits". For > example the method ==hash== of ==SequenceableCollection== illustrates > this point. > > > [[[ > SequenceableCollection >> hash > | hash | > hash := self species hash. > 1 to: self size do: [:i | hash := (hash + (self at: i) hash) hashMultiply]. > ^ hash > ]]] > > > The mixing of the bits is done by the combination of addition and > ==hashMultiply==. The value of ==species hash== does not need to be > processed by ==hashMultiply==, because it is probably computed by the > method =identityHash== of ==ProtoObject==, and that already provides > property C. > > !!! When we should not use XOR > > ==LayoutFrame== is a particularly good example of a data structure > that should not use XOR hashing. Its instance variables provide none > of the required properties: > > - ==SmallInteger>>hash== is just ==^self==. > - In addition, common ==LayoutFrame== instances tend to use pairs of > identical values in their instance variables. Like ==0@0 corner: > 1@1==, or ==Margin fromNumber: 10==. > > A good hash function for LayoutFrame needs to: > > - Get hashes for each instance variable that provides properties A and B. > - Combine them in a way that is order-sensitive (to maintain property > B) and that does some extra mixing (to provide property C). > > Now, we can assume that common values for the instance variables will > be instances of ==SmallInteger==, ==Float==, or ==Fraction==. > > You can see in ==Fraction>>hash==, that a comment mentions the > assumption that the fraction is already reduced, that is what makes it > acceptable to use bitXor. > > The hash of ==SmallInteger== does provide properties A and B, but not > property C. The hash of ==Float== is harder to understand, but tests > show that it provides distinct values for 0.5, 0.25 and 0.125. So it > hopefully provides B for the range of values of interest to > ==LayoutFrame==. > > Another class that has similar hashing constraints to ==LayoutFrame== > is ==Point==. Its ==hash== method is: > > [[[ > Point >> hash > "Hash is reimplemented because = is implemented." > ^(x hash hashMultiply + y hash) hashMultiply > ]]] > > It does not include species in the computation, which is less than > ideal because it favours collisions with objects of different species > that have a similar content and a the same hash algorithm. > > Finally, it is probably not necessary or useful to use the accessors > to get to the instance variables. > > So a good implementation for LayoutFrame is > > [[[ > LayoutFrame >> hash > | hash | > hash := self species hash > hash := (hash + leftFraction hash) hashMultiply > hash := (hash + leftOffset hash) hashMultiply > hash := (hash + topFraction hash) hashMultiply > hash := (hash + topOffset hash) hashMultiply > hash := (hash + rightFraction hash) hashMultiply > hash := (hash + rightOffset hash) hashMultiply > hash := (hash + bottomFraction hash) hashMultiply > hash := (hash + bottomOffset hash) hashMultiply > ^ hash > ]]] > > On Fri, Oct 6, 2017 at 9:59 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Noury also proposed a trait to avoid to systematically have to implement >> hash. >> Vitor why don't you take it as a small project to propose a solution for >> Pharo. >> >> On Thu, Oct 5, 2017 at 6:34 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >>> Yes, canEqual implementation also make #= be commutative. >>> >>> On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>>> >>>> >>>> 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>>> >>>>> >>>>> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >>>>>> >>>>>> I am sorry, not species, but #isKindOf istead of #= to compare >>>>>> classes. >>>>> >>>>> >>>>> It is bad idea. #= should be transitive. >>>> >>>> >>>> Oh, I used wrong word, shame on me :). I tried to say commutative. >>>> >>>>> >>>>> How you will generate it with isKindOf: logic? You need to know common >>>>> parent. >>>>> >>>>> Also I not remember cases where I was needed two instances of different >>>>> classes to be equal. >>>>> And I can imaging the problems which it will lead to. >>>>> >>>>>> >>>>>> >>>>>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov >>>>>> <dionisiydk(a)gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>>>> >>>>>>>> >>>>>>>> Two questions/comments about the generated code: >>>>>>>> 1. #= >>>>>>>> ... >>>>>>>> self class = anObject class "should compare #species >>>>>>>> instead?" >>>>>>>> ifFalse: [ ^ false ]. >>>>>>>> ... >>>>>>>> Typically, I've seen #species instead of #class in the guard >>>>>>>> statement. >>>>>>>> Should we change it to that? >>>>>>> >>>>>>> >>>>>>> I doubt that it is important for domain classes. Because I never saw >>>>>>> the user of #species which is not a kind of Collection. And for >>>>>>> collections >>>>>>> this refactoring is not valid anyway. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2. #hash >>>>>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>>>>> Is this implementation always safe? It's what I usually hand roll >>>>>>>> based on >>>>>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>>>>> hashing, so >>>>>>>> I've always wondered if I was missing somethingâ¦ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- >>>>>>>> Cheers, >>>>>>>> Sean >>>>>>>> -- >>>>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > >

Oct. 6, 2017

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

by Stephane Ducasse

This is fun because I was thinking that we should add to the main page a videos of the counter coding in the debugger and GTInspector. We have the mooc videos showing ProfStef so we have nearly everything we need and now they are available (should upload them with english voice). Stef On Fri, Oct 6, 2017 at 5:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > I saw this comment, and wonder if we might have an intro video (or cartoon) > of how to run the ProfStef tutorial in the first few minutes of opening your > first image. > >> They need to work on the presentation. How do you get started ? How does >> the code look like ? etc. Not just "download this program and buy this book" > reply > > yes, time, resources, someoneHasToDoIt all apply. > just a random thought, > cheers -ben > > On Fri, Oct 6, 2017 at 9:47 PM, horrido <horrido.hobbies(a)gmail.com> wrote: >> >> Thanks. I gave your answer verbatim. I also added the following paragraph: >> >> The problem I find with todayâs developers is that they are rather >> closed-minded. They are rigid and inflexible, and not willing to adapt to >> new and different ways of doing things. In my generation (circa >> 1980â1990), >> people didnât have a problem with trying different technologies. Thatâs >> why >> I had no issue with learning Smalltalk 10 years ago, after I had retired >> from a 20-year-long career in C systems programming and FORTRAN scientific >> programming. >> >> >> >> Sven Van Caekenberghe-2 wrote >> >> On 6 Oct 2017, at 14:54, horrido < >> >> > horrido.hobbies@ >> >> > > wrote: >> >> >> >> I received this comment from someone who complained: >> >> >> >> *What about the lack of documentation? From time to time Iâve checked >> >> some >> >> SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of >> >> these, only GNU-SmallTalk appears to have a free, official programming >> >> guide >> >> and core library reference that any serious programmer expects from a >> >> language. >> >> >> >> https://www.gnu.org/software/smalltalk/manual-base/html_node/* >> >> >> >> I pointed to Pharo's documentation but then he came back with: >> >> >> >> *Then show me a link of the free, maintained reference documentation >> >> for >> >> the >> >> classes that form âthe core libraryâ, like this one for Python >> >> (https://docs.python.org/3/library/index.html)* >> >> >> >> It's true, most Smalltalks do not have a core library reference, not >> >> even >> >> VisualWorks! So what is the proper response to this complaint? >> > >> > The first answer is that Pharo/Smalltalk is unique in that a running >> > system/IDE contains _all_ source code, _all_ documentation (class, >> > method, >> > help, tutorial), _all_ unit tests and _all_ runnable examples in a very >> > easy, accessible way. It takes some getting used to, but this is >> > actually >> > better and much more powerful than any alternative. >> > >> > The second answer is that there are lots of books and articles that take >> > the classic/structured book/paper approach. There is >> > http://books.pharo.org, http://themoosebook.org, >> > http://book.seaside.st/book, http://medium.com/concerning-pharo and many >> > more. >> > >> >> Thanks. >> >> >> >> >> >> >> >> -- >> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >

Oct. 6, 2017

Re: [Pharo-users] Creating a new method

by Stephane Ducasse

Hi Dirk have a look at - one one coding the counter http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W1/C019-W1S-Videos-Redo-C… (we should have the english versions now) C019-W1-Videos-Redo-CodingCounterInDebugger-FR-V2-HD_720p_4Mbs.m4v you can find the subtitles around the same folder. Stef On Fri, Oct 6, 2017 at 4:16 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Fri, Oct 6, 2017 at 6:15 PM, Dirk Olmes <dirk(a)xanthippe.ping.de> wrote: >> >> Hi, >> >> I may be asking an absolute noob question but I was unable to find any >> useful hints on google ... >> >> I often find myself writing methods that do not yet exist when >> implementing other methods, e.g. when I'm writing the implementation of >> methodA I'm calling out to methodB. >> >> What's the easiest way to create the new method? I know I can jump >> aroung through hoops with a separate browser but that feels cumbersome. >> >> I understand that the editor/runtime/whatever cannot know 100% of the >> time where to put the new method but at least for messages to self it >> should be smart enough to offer some kind of help. >> >> -dirk >> > > A common Pharo workflow is known as "programming from within the debugger." > Run your #methodA code as soon as possible, and when the debugger pops up > because someObject hasn't yet implemented #methodB, the debugger helps you > create #methodB in the right place. > > Some examples... > * https://www.youtube.com/watch?v=ymITEeAOtEA > * > http://www.virtuouscode.com/2015/05/11/in-which-i-make-you-hate-ruby-in-7-m… > > Give it a go and stick with it for a while, and you'll understand why > Smalltalk invented Test Driven Development (and it may change they way you > think about programming.) > > cheers -ben

Oct. 6, 2017

Re: [Pharo-users] ZnClient in Pharo 6.1 not working for Https on Windows

by Cyril Ferlicot D.

Le 06/10/2017 Ã 13:02, kmo a Ã©critÂ : > I was trying to Soup on Windows 7 and found I could not access https sites > > On windows 7 and 10 the following code fails: > > ZnEasy get:'https://genius.com/Alice-nuvole-lyrics'. > > This works fine in Pharo 5 on Windows. Also works fine with Pharo 6.1 (32 > bit) on Linux. > > The problem is Pharo 6.1 on Windows. > > The error is: > > "SSL/TLS plugin initialization failed (VM plugin missing ? OS libraries > missing ?)" > > I know that his has been seen on Linux in the past - see > http://forum.world.st/SSL-TLS-plugin-initailization-failed-VM-plugin-missin… > > I'm running the latest vm and 6.1 image. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > I just saw that Windows Defender consider this plugin as a Trojan and delete it. Name of the menace: Trojan:Win32/Azden.A!cl Should this be reported on Pharo's issue tracker or on opensmalltalk one? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Oct. 6, 2017

Re: [Pharo-users] Seaside Magritte tutorial

by Stephane Ducasse

Now there is a much better one :) To be announced soooooonnnnn But you can have it as beta reader. https://github.com/SquareBracketAssociates/Booklet-Magritte check the bintray link in the readme Any typos, bugs, errors are welcome Stef On Fri, Oct 6, 2017 at 4:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 6 Oct 2017, at 16:54, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >> >> Hello! >> >> Is there any tutorial focused on Seaside and Magritte that creates an example app using Magritte in a job trivial way? >> >> I mean, something that mix or segregate descriptions from some object to generate pages on Seaside, that show a way to personalize more the generated page, if that is possible. >> >> Thanks in advance! > > Did you see > > http://book.seaside.st/book/advanced/magritte > > maybe a bit old, I don't know > >

Oct. 6, 2017

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

by Stephane Ducasse

Tx Christophe We should add a new page on Pharo.org about the launcher. On Fri, Oct 6, 2017 at 1:26 PM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Hi all, > > I just released a new version of the PharoLauncher 1.0.1. > Here are major improvements since last version: > > Pharo launcher is now distributed with a Pharo 60 image with a 32-bits > threaded VM (to avoid hangs when using OSProcess). > Add a VM management utility able to find (and download) the appropriate VM > for a given image. So, the launcher is NOT shipped anymore with an extra VM. > It will fetch required VM when needed. > Pharo Launcher files (images, VMs) are now considered as user Documents > (easier to find). Consequently, they are now stored in the standard > documents folder, i.e. > > $HOME/Documents/Pharo on OS X, > $HOME/My Documents/Pharo on windows, > $HOME/Pharo on Linux (some linux distributions provide a document folder but > some others not, so we put it in the HOME directory in all cases). > In this folder, you will find your images and virtual machines needed to run > images. > > Use of ProcessWrapper to run images on Windows. > Adds download of sources file for Pharo images > 60. > Left panel is now used for official images and Jenkins jobs templates and > right panel is used for local images. > New mooc entry with the image ready to start the Pharo Mooc. > New deprecated category to find old official Pharo images. > Use system unzip when possible (Pharo unzip does not manage file permissions > nor symbolic links). > > You can get platform bundles from files.pharo.org: > > Os X: http://files.pharo.org/platform/launcher/Pharo_1.0.1.dmg > Windows: http://files.pharo.org/platform/launcher/pharo_installer-1.0.1.exe > Linux: http://files.pharo.org/platform/launcher/Pharo-linux-1.0.1.zip > > > Enjoy, > Christophe. > > For those wanted more info on how the adequate VM is computed, here is the > process: > > determine the image format version > find (and optionnaly fetch) a compatible VM (a VM able to run this image > format) and run the image to get its Pharo version number > find (and optionnaly fetch) the appropriate VM for this specific Pharo image > version. Sources files are also downloaded with the VM when applicable. > run the image with the appropriate VM > >

Oct. 6, 2017

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

by Ben Coman

I saw this comment, and wonder if we might have an intro video (or cartoon) of how to run the ProfStef tutorial in the first few minutes of opening your first image. > They need to work on the presentation. How do you get started ? How does the code look like ? etc. Not just "download this program and buy this book" reply yes, time, resources, someoneHasToDoIt all apply. just a random thought, cheers -ben On Fri, Oct 6, 2017 at 9:47 PM, horrido <horrido.hobbies(a)gmail.com> wrote: > Thanks. I gave your answer verbatim. I also added the following paragraph: > > The problem I find with todayâs developers is that they are rather > closed-minded. They are rigid and inflexible, and not willing to adapt to > new and different ways of doing things. In my generation (circa 1980â1990), > people didnât have a problem with trying different technologies. Thatâs why > I had no issue with learning Smalltalk 10 years ago, after I had retired > from a 20-year-long career in C systems programming and FORTRAN scientific > programming. > > > > Sven Van Caekenberghe-2 wrote > >> On 6 Oct 2017, at 14:54, horrido < > > > horrido.hobbies@ > > > > wrote: > >> > >> I received this comment from someone who complained: > >> > >> *What about the lack of documentation? From time to time Iâve checked > >> some > >> SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of > >> these, only GNU-SmallTalk appears to have a free, official programming > >> guide > >> and core library reference that any serious programmer expects from a > >> language. > >> > >> https://www.gnu.org/software/smalltalk/manual-base/html_node/* > >> > >> I pointed to Pharo's documentation but then he came back with: > >> > >> *Then show me a link of the free, maintained reference documentation for > >> the > >> classes that form âthe core libraryâ, like this one for Python > >> (https://docs.python.org/3/library/index.html)* > >> > >> It's true, most Smalltalks do not have a core library reference, not > even > >> VisualWorks! So what is the proper response to this complaint? > > > > The first answer is that Pharo/Smalltalk is unique in that a running > > system/IDE contains _all_ source code, _all_ documentation (class, > method, > > help, tutorial), _all_ unit tests and _all_ runnable examples in a very > > easy, accessible way. It takes some getting used to, but this is actually > > better and much more powerful than any alternative. > > > > The second answer is that there are lots of books and articles that take > > the classic/structured book/paper approach. There is > > http://books.pharo.org, http://themoosebook.org, > > http://book.seaside.st/book, http://medium.com/concerning-pharo and many > > more. > > > >> Thanks. > >> > >> > >> > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 6, 2017

Re: [Pharo-users] ZnClient in Pharo 6.1 not working for Https on Windows

by kmo

Thanks. I re-extracted SqueakSSL.dll from the zip file and now it works! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

Re: [Pharo-users] Update of ConfigurationOfGlorp

by Herby VojÄÃk

Sven Van Caekenberghe wrote: > >> On 4 Oct 2017, at 17:20, stephan<stephan(a)stack.nl> wrote: >> >> I've added a Pharo 7 version, copied the configurations from DBXTalk/Glorp to DBXTalk/Configurations and the metarepos, and >> replaced the #'Pharo6.0.x' style names by #'Pharo6.x' style. >> Please let me know if that creates problems >> >> Stephan > > I tested with the latest ConfigurationOfGlorp-StephanEggermont.61 in Pharo 7 and that seems OK (not super clean, but OK). > > Thx. > > Any chance of incorporating fixes 127 / 129? Herby

Oct. 6, 2017

Re: [Pharo-users] Update of ConfigurationOfGlorp

by Sven Van Caekenberghe

> On 4 Oct 2017, at 17:20, stephan <stephan(a)stack.nl> wrote: > > I've added a Pharo 7 version, copied the configurations from DBXTalk/Glorp to DBXTalk/Configurations and the metarepos, and > replaced the #'Pharo6.0.x' style names by #'Pharo6.x' style. > Please let me know if that creates problems > > Stephan I tested with the latest ConfigurationOfGlorp-StephanEggermont.61 in Pharo 7 and that seems OK (not super clean, but OK). Thx.

Oct. 6, 2017

Re: [Pharo-users] ZnClient in Pharo 6.1 not working for Https on Windows

by Herby VojÄÃk

kmo wrote: > I was trying to Soup on Windows 7 and found I could not access https sites > > On windows 7 and 10 the following code fails: > > ZnEasy get:'https://genius.com/Alice-nuvole-lyrics'. > > This works fine in Pharo 5 on Windows. Also works fine with Pharo 6.1 (32 > bit) on Linux. > > The problem is Pharo 6.1 on Windows. > > The error is: > > "SSL/TLS plugin initialization failed (VM plugin missing ? OS libraries > missing ?)" I had it as well. The reason seems to be really strange, but the root cause was the zip wasn't unzipped correctly, probably due to Windows Defender hijacking it, and SqueakSSL.dll was missing. Check thouroughly if you actually have all files present in .zip actually unzipped in pharo folder. Herby > I know that his has been seen on Linux in the past - see > http://forum.world.st/SSL-TLS-plugin-initailization-failed-VM-plugin-missin… > > I'm running the latest vm and 6.1 image. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Oct. 6, 2017

Re: [Pharo-users] Seaside Magritte tutorial

by Sven Van Caekenberghe

> On 6 Oct 2017, at 16:54, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > > Hello! > > Is there any tutorial focused on Seaside and Magritte that creates an example app using Magritte in a job trivial way? > > I mean, something that mix or segregate descriptions from some object to generate pages on Seaside, that show a way to personalize more the generated page, if that is possible. > > Thanks in advance! Did you see http://book.seaside.st/book/advanced/magritte maybe a bit old, I don't know

Oct. 6, 2017

Seaside Magritte tutorial

by Vitor Medina Cruz

Hello! Is there any tutorial focused on Seaside and Magritte that creates an example app using Magritte in a job trivial way? I mean, something that mix or segregate descriptions from some object to generate pages on Seaside, that show a way to personalize more the generated page, if that is possible. Thanks in advance!

Oct. 6, 2017

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

by Andrew Glynn

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 <phar o-users(a)lists.pharo.org> Reply-to: Any question about pharo is welcome <pharo-users(a)lists.pharo. org> From: Holger Freyther <holger(a)freyther.de> > 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/repositori es/devel:/languages:/pharo:/latest/CentOS_6/devel:languages:pharo:lates t.repo OR (for stable): http://download.opensuse.org/repositories/devel:/languages:/pharo:/late st/CentOS_6/devel:languages:pharo:stable.repo # 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. 6, 2017

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

by Andrew Glynn

RedHat < 7.0 still uses libc 2.12 as far as I'm aware. Pharo 5 has a downloadable version that works on that OS.Â Â OEL with the UEK has an updated libc. Andrew Glynn openmastery.org -----Original Message----- Date: Thu, 5 Oct 2017 11:43:07 +0200 Subject: Re: [Pharo-users] Deploying on Linux with LibC version < 2.15 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Reply-to: Any question about pharo is welcome <pharo-users(a)lists.pharo. org> From: Cyril Ferlicot <cyril.ferlicot(a)gmail.com> On Thu, Oct 5, 2017 at 11:30 AM, Holger Freyther <holger(a)freyther.de> wrote: > > Which OS has such old versions of LibC? Which LSB standard does it > support? > Hi, This is RedHat. I don't have the right to give more info than the fact it is a RedHat with a LibC version < 2.15. I don't know for the LSB support. I can ask but I will probably not know before the end of next week.

Oct. 6, 2017

Re: [Pharo-users] Creating a new method

by Ben Coman

On Fri, Oct 6, 2017 at 6:15 PM, Dirk Olmes <dirk(a)xanthippe.ping.de> wrote: > Hi, > > I may be asking an absolute noob question but I was unable to find any > useful hints on google ... > > I often find myself writing methods that do not yet exist when > implementing other methods, e.g. when I'm writing the implementation of > methodA I'm calling out to methodB. > > What's the easiest way to create the new method? I know I can jump > aroung through hoops with a separate browser but that feels cumbersome. > > I understand that the editor/runtime/whatever cannot know 100% of the > time where to put the new method but at least for messages to self it > should be smart enough to offer some kind of help. > > -dirk > > A common Pharo workflow is known as "programming from within the debugger." Run your #methodA code as soon as possible, and when the debugger pops up because someObject hasn't yet implemented #methodB, the debugger helps you create #methodB in the right place. Some examples... * https://www.youtube.com/watch?v=ymITEeAOtEA * http://www.virtuouscode.com/2015/05/11/in-which-i-make-you-hate-ruby-in-7-m… Give it a go and stick with it for a while, and you'll understand why Smalltalk invented Test Driven Development (and it may change they way you think about programming.) cheers -ben

Oct. 6, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Vitor Medina Cruz

Stephane "Vitor why don't you take it as a small project to propose a solution for Pharo." I will try :) I like the idea of using a Trait. Em 6 de out de 2017 05:01, "Stephane Ducasse" <stepharo.self(a)gmail.com> escreveu: Here is what I extracted from older emails >From David Allouche in Pharo-dev to see if The ==hash== method is used in Pharo to separate objects in bucket-based data structures. !! Property It must have one required property which is required data integrity: !!!! A. Objects that are equal according to ==\=== must have equal hashes. It should have two desirable properties that are required to support the algorithmic assumptions of bucket-based data structures: !!!! B. Objects that are not equal should have different hashes. Ideally, the probability of hash collision should by 1/N where N is the size of hash value space. !!!! C. The hash values should spread as much as possible over their value space. For example: ProtoObject>>#identityHash. How these two desirable properties can be implemented depends on the actual distribution of the values used to compute the hash. An object can safely use XOR hashing if its instance variables are all different objects that already provide a hash method with these two properties. @@todo check following sentence because the use of singleton is obscure For example, an object whose behaviour is defined by several of singleton delegates of different classes that do not override Object>>#hash. But if the instance variables are not guaranteed to have those properties, it is necessary to more thoroughly "mix the bits". For example the method ==hash== of ==SequenceableCollection== illustrates this point. [[[ SequenceableCollection >> hash | hash | hash := self species hash. 1 to: self size do: [:i | hash := (hash + (self at: i) hash) hashMultiply]. ^ hash ]]] The mixing of the bits is done by the combination of addition and ==hashMultiply==. The value of ==species hash== does not need to be processed by ==hashMultiply==, because it is probably computed by the method =identityHash== of ==ProtoObject==, and that already provides property C. !!! When we should not use XOR ==LayoutFrame== is a particularly good example of a data structure that should not use XOR hashing. Its instance variables provide none of the required properties: - ==SmallInteger>>hash== is just ==^self==. - In addition, common ==LayoutFrame== instances tend to use pairs of identical values in their instance variables. Like ==0@0 corner: 1@1==, or ==Margin fromNumber: 10==. A good hash function for LayoutFrame needs to: - Get hashes for each instance variable that provides properties A and B. - Combine them in a way that is order-sensitive (to maintain property B) and that does some extra mixing (to provide property C). Now, we can assume that common values for the instance variables will be instances of ==SmallInteger==, ==Float==, or ==Fraction==. You can see in ==Fraction>>hash==, that a comment mentions the assumption that the fraction is already reduced, that is what makes it acceptable to use bitXor. The hash of ==SmallInteger== does provide properties A and B, but not property C. The hash of ==Float== is harder to understand, but tests show that it provides distinct values for 0.5, 0.25 and 0.125. So it hopefully provides B for the range of values of interest to ==LayoutFrame==. Another class that has similar hashing constraints to ==LayoutFrame== is ==Point==. Its ==hash== method is: [[[ Point >> hash "Hash is reimplemented because = is implemented." ^(x hash hashMultiply + y hash) hashMultiply ]]] It does not include species in the computation, which is less than ideal because it favours collisions with objects of different species that have a similar content and a the same hash algorithm. Finally, it is probably not necessary or useful to use the accessors to get to the instance variables. So a good implementation for LayoutFrame is [[[ LayoutFrame >> hash | hash | hash := self species hash hash := (hash + leftFraction hash) hashMultiply hash := (hash + leftOffset hash) hashMultiply hash := (hash + topFraction hash) hashMultiply hash := (hash + topOffset hash) hashMultiply hash := (hash + rightFraction hash) hashMultiply hash := (hash + rightOffset hash) hashMultiply hash := (hash + bottomFraction hash) hashMultiply hash := (hash + bottomOffset hash) hashMultiply ^ hash ]]] On Fri, Oct 6, 2017 at 9:59 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Noury also proposed a trait to avoid to systematically have to implement hash. > Vitor why don't you take it as a small project to propose a solution for Pharo. > > On Thu, Oct 5, 2017 at 6:34 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >> Yes, canEqual implementation also make #= be commutative. >> >> On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >>> >>> >>> 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>> >>>> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >>>>> >>>>> I am sorry, not species, but #isKindOf istead of #= to compare classes. >>>> >>>> >>>> It is bad idea. #= should be transitive. >>> >>> >>> Oh, I used wrong word, shame on me :). I tried to say commutative. >>> >>>> >>>> How you will generate it with isKindOf: logic? You need to know common >>>> parent. >>>> >>>> Also I not remember cases where I was needed two instances of different >>>> classes to be equal. >>>> And I can imaging the problems which it will lead to. >>>> >>>>> >>>>> >>>>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov < dionisiydk(a)gmail.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>>> >>>>>>> >>>>>>> Two questions/comments about the generated code: >>>>>>> 1. #= >>>>>>> ... >>>>>>> self class = anObject class "should compare #species instead?" >>>>>>> ifFalse: [ ^ false ]. >>>>>>> ... >>>>>>> Typically, I've seen #species instead of #class in the guard >>>>>>> statement. >>>>>>> Should we change it to that? >>>>>> >>>>>> >>>>>> I doubt that it is important for domain classes. Because I never saw >>>>>> the user of #species which is not a kind of Collection. And for collections >>>>>> this refactoring is not valid anyway. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2. #hash >>>>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>>>> Is this implementation always safe? It's what I usually hand roll >>>>>>> based on >>>>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>>>> hashing, so >>>>>>> I've always wondered if I was missing somethingâ¦ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Cheers, >>>>>>> Sean >>>>>>> -- >>>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>>> >>>>>> >>>>> >>>> >>> >>

Oct. 6, 2017

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

by Gabriel Cotelli

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.* Let me know if you need more info. Regards, Gabriel On Fri, Oct 6, 2017 at 8:26 AM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi all, > > I just released a new version of the *PharoLauncher 1.0.1*. > Here are major improvements since last version: > > - Pharo launcher is now distributed with a Pharo 60 image with a > 32-bits threaded VM (to avoid hangs when using OSProcess). > - Add a *VM management* utility able to find (and download) the > appropriate VM for a given image. So, the launcher is NOT shipped anymore > with an extra VM. It will fetch required VM when needed. > - *Pharo Launcher files (images, VMs)* are now considered as user > Documents (easier to find). Consequently, they are *now stored in the > standard documents folder*, i.e. > - *$HOME/Documents/Pharo* on OS X, > - *$HOME/My Documents/Pharo* on windows, > - *$HOME/Pharo* on Linux (some linux distributions provide a > document folder but some others not, so we put it in the HOME directory in > all cases). > - In this folder, you will find your images and virtual machines > needed to run images. > - Use of ProcessWrapper to run images on Windows. > - Adds download of sources file for Pharo images > 60. > - Left panel is now used for official images and Jenkins jobs > templates and right panel is used for local images. > - New mooc entry with the image ready to start the Pharo Mooc. > - New deprecated category to find old official Pharo images. > - Use system unzip when possible (Pharo unzip does not manage file > permissions nor symbolic links). > > You can get platform bundles from files.pharo.org: > > - Os X: http://files.pharo.org/platform/launcher/Pharo_1.0.1.dmg > - Windows: http://files.pharo.org/platform/launcher/pharo_ > installer-1.0.1.exe > - Linux: http://files.pharo.org/platform/launcher/Pharo-linux-1.0.1.zip > > > Enjoy, > Christophe. > > For those wanted more info on how the adequate VM is computed, here is the > process: > > 1. determine the image format version > 2. find (and optionnaly fetch) a compatible VM (a VM able to run this > image format) and run the image to get its Pharo version number > 3. find (and optionnaly fetch) the appropriate VM for this specific > Pharo image version. Sources files are also downloaded with the VM when > applicable. > 4. run the image with the appropriate VM > > >

Oct. 6, 2017

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

by horrido

Thanks. I gave your answer verbatim. I also added the following paragraph: The problem I find with todayâs developers is that they are rather closed-minded. They are rigid and inflexible, and not willing to adapt to new and different ways of doing things. In my generation (circa 1980â1990), people didnât have a problem with trying different technologies. Thatâs why I had no issue with learning Smalltalk 10 years ago, after I had retired from a 20-year-long career in C systems programming and FORTRAN scientific programming. Sven Van Caekenberghe-2 wrote >> On 6 Oct 2017, at 14:54, horrido < > horrido.hobbies@ > > wrote: >> >> I received this comment from someone who complained: >> >> *What about the lack of documentation? From time to time Iâve checked >> some >> SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of >> these, only GNU-SmallTalk appears to have a free, official programming >> guide >> and core library reference that any serious programmer expects from a >> language. >> >> https://www.gnu.org/software/smalltalk/manual-base/html_node/* >> >> I pointed to Pharo's documentation but then he came back with: >> >> *Then show me a link of the free, maintained reference documentation for >> the >> classes that form âthe core libraryâ, like this one for Python >> (https://docs.python.org/3/library/index.html)* >> >> It's true, most Smalltalks do not have a core library reference, not even >> VisualWorks! So what is the proper response to this complaint? > > The first answer is that Pharo/Smalltalk is unique in that a running > system/IDE contains _all_ source code, _all_ documentation (class, method, > help, tutorial), _all_ unit tests and _all_ runnable examples in a very > easy, accessible way. It takes some getting used to, but this is actually > better and much more powerful than any alternative. > > The second answer is that there are lots of books and articles that take > the classic/structured book/paper approach. There is > http://books.pharo.org, http://themoosebook.org, > http://book.seaside.st/book, http://medium.com/concerning-pharo and many > more. > >> Thanks. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

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

by kmo

This is great. Absolutely love it. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

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

by Sven Van Caekenberghe

> On 6 Oct 2017, at 14:54, horrido <horrido.hobbies(a)gmail.com> wrote: > > I received this comment from someone who complained: > > *What about the lack of documentation? From time to time Iâve checked some > SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of > these, only GNU-SmallTalk appears to have a free, official programming guide > and core library reference that any serious programmer expects from a > language. > > https://www.gnu.org/software/smalltalk/manual-base/html_node/* > > I pointed to Pharo's documentation but then he came back with: > > *Then show me a link of the free, maintained reference documentation for the > classes that form âthe core libraryâ, like this one for Python > (https://docs.python.org/3/library/index.html)* > > It's true, most Smalltalks do not have a core library reference, not even > VisualWorks! So what is the proper response to this complaint? The first answer is that Pharo/Smalltalk is unique in that a running system/IDE contains _all_ source code, _all_ documentation (class, method, help, tutorial), _all_ unit tests and _all_ runnable examples in a very easy, accessible way. It takes some getting used to, but this is actually better and much more powerful than any alternative. The second answer is that there are lots of books and articles that take the classic/structured book/paper approach. There is http://books.pharo.org, http://themoosebook.org, http://book.seaside.st/book, http://medium.com/concerning-pharo and many more. > Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Oct. 6, 2017

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

by Richard Sargent

"It's Smalltalk. Read the code, Luke."? On Oct 6, 2017 08:55, "horrido" <horrido.hobbies(a)gmail.com> wrote: > I received this comment from someone who complained: > > *What about the lack of documentation? From time to time Iâve checked some > SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of > these, only GNU-SmallTalk appears to have a free, official programming > guide > and core library reference that any serious programmer expects from a > language. > > https://www.gnu.org/software/smalltalk/manual-base/html_node/* > > I pointed to Pharo's documentation but then he came back with: > > *Then show me a link of the free, maintained reference documentation for > the > classes that form âthe core libraryâ, like this one for Python > (https://docs.python.org/3/library/index.html)* > > It's true, most Smalltalks do not have a core library reference, not even > VisualWorks! So what is the proper response to this complaint? > > Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 6, 2017

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

by horrido

I received this comment from someone who complained: *What about the lack of documentation? From time to time Iâve checked some SmallTalk implementations like Squeak, GNU-Smalltalk and now Pharo. Of these, only GNU-SmallTalk appears to have a free, official programming guide and core library reference that any serious programmer expects from a language. https://www.gnu.org/software/smalltalk/manual-base/html_node/* I pointed to Pharo's documentation but then he came back with: *Then show me a link of the free, maintained reference documentation for the classes that form âthe core libraryâ, like this one for Python (https://docs.python.org/3/library/index.html)* It's true, most Smalltalks do not have a core library reference, not even VisualWorks! So what is the proper response to this complaint? Thanks. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

[Ann] PharoLauncher v1.0.1 released!

by Christophe Demarey

Hi all, I just released a new version of the PharoLauncher 1.0.1. Here are major improvements since last version: Pharo launcher is now distributed with a Pharo 60 image with a 32-bits threaded VM (to avoid hangs when using OSProcess). Add a VM management utility able to find (and download) the appropriate VM for a given image. So, the launcher is NOT shipped anymore with an extra VM. It will fetch required VM when needed. Pharo Launcher files (images, VMs) are now considered as user Documents (easier to find). Consequently, they are now stored in the standard documents folder, i.e. $HOME/Documents/Pharo on OS X, $HOME/My Documents/Pharo on windows, $HOME/Pharo on Linux (some linux distributions provide a document folder but some others not, so we put it in the HOME directory in all cases). In this folder, you will find your images and virtual machines needed to run images. Use of ProcessWrapper to run images on Windows. Adds download of sources file for Pharo images > 60. Left panel is now used for official images and Jenkins jobs templates and right panel is used for local images. New mooc entry with the image ready to start the Pharo Mooc. New deprecated category to find old official Pharo images. Use system unzip when possible (Pharo unzip does not manage file permissions nor symbolic links). You can get platform bundles from files.pharo.org: Os X: http://files.pharo.org/platform/launcher/Pharo_1.0.1.dmg Windows: http://files.pharo.org/platform/launcher/pharo_installer-1.0.1.exe Linux: http://files.pharo.org/platform/launcher/Pharo-linux-1.0.1.zip Enjoy, Christophe. For those wanted more info on how the adequate VM is computed, here is the process: determine the image format version find (and optionnaly fetch) a compatible VM (a VM able to run this image format) and run the image to get its Pharo version number find (and optionnaly fetch) the appropriate VM for this specific Pharo image version. Sources files are also downloaded with the VM when applicable. run the image with the appropriate VM

Oct. 6, 2017

ZnClient in Pharo 6.1 not working for Https on Windows

by kmo

I was trying to Soup on Windows 7 and found I could not access https sites On windows 7 and 10 the following code fails: ZnEasy get:'https://genius.com/Alice-nuvole-lyrics'. This works fine in Pharo 5 on Windows. Also works fine with Pharo 6.1 (32 bit) on Linux. The problem is Pharo 6.1 on Windows. The error is: "SSL/TLS plugin initialization failed (VM plugin missing ? OS libraries missing ?)" I know that his has been seen on Linux in the past - see http://forum.world.st/SSL-TLS-plugin-initailization-failed-VM-plugin-missin… I'm running the latest vm and 6.1 image. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

Re: [Pharo-users] SVG Icons

by Sven Van Caekenberghe

That is a very cool example ! Some nit picking (just trying to help make examples/snippets even more sexy). The shortest expression to get to the contents of a URL, using only unary selectors is 'https://s.cdpn.io/3/kiwi.svg' asUrl retrieveContents. XMLDomParser's API also has the option #parseURL: so the following would also work XMLDomParser parseURL: 'https://s.cdpn.io/3/kiwi.svg'. I believe that call actually has some additional functionality too. > On 5 Oct 2017, at 15:24, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > this is not really tested, but you can try to do the following > > (installation) > a) install XMLParser from catalog > b) in monticello browser open Pharo/Athens and load latest version of Athens-SVG package > > (usage) > Then you import SVG XML using Converter and paint it on a surface, which you convert to Form. > > ``` > contents := (ZnEasy get: 'https://s.cdpn.io/3/kiwi.svg') contents. > > xmlDoc := XMLDOMParser parse: contents. > > svg := AthensSVGConverter new importXMLDocument: xmlDoc. > svg transform: 'scale(0.5)'. > > extent := 500 @ 500. > > surface := AthensCairoSurface extent: extent. > surface drawDuring: [ :aCanvas | svg renderOn: aCanvas ]. > surface asForm. > ``` > > <image.png> > > Peter > > On Thu, Oct 5, 2017 at 1:50 PM, Steven R. Baker <steven(a)stevenrbaker.com> wrote: > Heya folks! > > I need to load SVG images (for icons) in my application. I've searched > my 6.1 image for SVG, but haven't found anything. > > Is there a library for loading SVGs? I'd really like to get them > directly into instances of Form if possible, but I'm flexible. :) > > Thanks! > > -Steven > > > >

Oct. 6, 2017

Re: [Pharo-users] Creating a new method

by Peter UhnÃ¡k

What I often do is that I write a test and then I just execute the code. When it runs into the non-existent method, the debugger offers a button "create" method. Alternatively I do open a second browser (clicking on "scoped" in the current one or like that (or doubleclicking on a method to get the same method opened in a new browser) Peter On Fri, Oct 6, 2017 at 12:15 PM, Dirk Olmes <dirk(a)xanthippe.ping.de> wrote: > Hi, > > I may be asking an absolute noob question but I was unable to find any > useful hints on google ... > > I often find myself writing methods that do not yet exist when > implementing other methods, e.g. when I'm writing the implementation of > methodA I'm calling out to methodB. > > What's the easiest way to create the new method? I know I can jump > aroung through hoops with a separate browser but that feels cumbersome. > > I understand that the editor/runtime/whatever cannot know 100% of the > time where to put the new method but at least for messages to self it > should be smart enough to offer some kind of help. > > -dirk > >

Oct. 6, 2017

Creating a new method

by Dirk Olmes

Hi, I may be asking an absolute noob question but I was unable to find any useful hints on google ... I often find myself writing methods that do not yet exist when implementing other methods, e.g. when I'm writing the implementation of methodA I'm calling out to methodB. What's the easiest way to create the new method? I know I can jump aroung through hoops with a separate browser but that feels cumbersome. I understand that the editor/runtime/whatever cannot know 100% of the time where to put the new method but at least for messages to self it should be smart enough to offer some kind of help. -dirk

Oct. 6, 2017

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

by horrido

I've incorporated some of the suggestions. Thanks. Here's a very lively discussion at Hacker News: https://news.ycombinator.com/item?id=15399442 The article has sparked a raging debate. Hacker News readers seem to really like the article, as it has garnered 150 points, /more than any other article that I've ever posted!/ (Even my original TechBeacon article <https://techbeacon.com/how-learning-smalltalk-can-make-you-better-developer> -- which launched my campaign! -- only got 115 points.) You should all participate in the discussion and help to dispel the many misconceptions people have about Pharo/Smalltalk. I find a great deal of ignorance out there, and *only you folks* can address it properly. Thanks. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Stephane Ducasse

Here is what I extracted from older emails >From David Allouche in Pharo-dev to see if The ==hash== method is used in Pharo to separate objects in bucket-based data structures. !! Property It must have one required property which is required data integrity: !!!! A. Objects that are equal according to ==\=== must have equal hashes. It should have two desirable properties that are required to support the algorithmic assumptions of bucket-based data structures: !!!! B. Objects that are not equal should have different hashes. Ideally, the probability of hash collision should by 1/N where N is the size of hash value space. !!!! C. The hash values should spread as much as possible over their value space. For example: ProtoObject>>#identityHash. How these two desirable properties can be implemented depends on the actual distribution of the values used to compute the hash. An object can safely use XOR hashing if its instance variables are all different objects that already provide a hash method with these two properties. @@todo check following sentence because the use of singleton is obscure For example, an object whose behaviour is defined by several of singleton delegates of different classes that do not override Object>>#hash. But if the instance variables are not guaranteed to have those properties, it is necessary to more thoroughly "mix the bits". For example the method ==hash== of ==SequenceableCollection== illustrates this point. [[[ SequenceableCollection >> hash | hash | hash := self species hash. 1 to: self size do: [:i | hash := (hash + (self at: i) hash) hashMultiply]. ^ hash ]]] The mixing of the bits is done by the combination of addition and ==hashMultiply==. The value of ==species hash== does not need to be processed by ==hashMultiply==, because it is probably computed by the method =identityHash== of ==ProtoObject==, and that already provides property C. !!! When we should not use XOR ==LayoutFrame== is a particularly good example of a data structure that should not use XOR hashing. Its instance variables provide none of the required properties: - ==SmallInteger>>hash== is just ==^self==. - In addition, common ==LayoutFrame== instances tend to use pairs of identical values in their instance variables. Like ==0@0 corner: 1@1==, or ==Margin fromNumber: 10==. A good hash function for LayoutFrame needs to: - Get hashes for each instance variable that provides properties A and B. - Combine them in a way that is order-sensitive (to maintain property B) and that does some extra mixing (to provide property C). Now, we can assume that common values for the instance variables will be instances of ==SmallInteger==, ==Float==, or ==Fraction==. You can see in ==Fraction>>hash==, that a comment mentions the assumption that the fraction is already reduced, that is what makes it acceptable to use bitXor. The hash of ==SmallInteger== does provide properties A and B, but not property C. The hash of ==Float== is harder to understand, but tests show that it provides distinct values for 0.5, 0.25 and 0.125. So it hopefully provides B for the range of values of interest to ==LayoutFrame==. Another class that has similar hashing constraints to ==LayoutFrame== is ==Point==. Its ==hash== method is: [[[ Point >> hash "Hash is reimplemented because = is implemented." ^(x hash hashMultiply + y hash) hashMultiply ]]] It does not include species in the computation, which is less than ideal because it favours collisions with objects of different species that have a similar content and a the same hash algorithm. Finally, it is probably not necessary or useful to use the accessors to get to the instance variables. So a good implementation for LayoutFrame is [[[ LayoutFrame >> hash | hash | hash := self species hash hash := (hash + leftFraction hash) hashMultiply hash := (hash + leftOffset hash) hashMultiply hash := (hash + topFraction hash) hashMultiply hash := (hash + topOffset hash) hashMultiply hash := (hash + rightFraction hash) hashMultiply hash := (hash + rightOffset hash) hashMultiply hash := (hash + bottomFraction hash) hashMultiply hash := (hash + bottomOffset hash) hashMultiply ^ hash ]]] On Fri, Oct 6, 2017 at 9:59 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Noury also proposed a trait to avoid to systematically have to implement hash. > Vitor why don't you take it as a small project to propose a solution for Pharo. > > On Thu, Oct 5, 2017 at 6:34 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >> Yes, canEqual implementation also make #= be commutative. >> >> On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >>> >>> >>> 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>> >>>> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >>>>> >>>>> I am sorry, not species, but #isKindOf istead of #= to compare classes. >>>> >>>> >>>> It is bad idea. #= should be transitive. >>> >>> >>> Oh, I used wrong word, shame on me :). I tried to say commutative. >>> >>>> >>>> How you will generate it with isKindOf: logic? You need to know common >>>> parent. >>>> >>>> Also I not remember cases where I was needed two instances of different >>>> classes to be equal. >>>> And I can imaging the problems which it will lead to. >>>> >>>>> >>>>> >>>>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>>> >>>>>>> >>>>>>> Two questions/comments about the generated code: >>>>>>> 1. #= >>>>>>> ... >>>>>>> self class = anObject class "should compare #species instead?" >>>>>>> ifFalse: [ ^ false ]. >>>>>>> ... >>>>>>> Typically, I've seen #species instead of #class in the guard >>>>>>> statement. >>>>>>> Should we change it to that? >>>>>> >>>>>> >>>>>> I doubt that it is important for domain classes. Because I never saw >>>>>> the user of #species which is not a kind of Collection. And for collections >>>>>> this refactoring is not valid anyway. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2. #hash >>>>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>>>> Is this implementation always safe? It's what I usually hand roll >>>>>>> based on >>>>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>>>> hashing, so >>>>>>> I've always wondered if I was missing somethingâ¦ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Cheers, >>>>>>> Sean >>>>>>> -- >>>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>>> >>>>>> >>>>> >>>> >>> >>

Oct. 6, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Stephane Ducasse

Noury also proposed a trait to avoid to systematically have to implement hash. Vitor why don't you take it as a small project to propose a solution for Pharo. On Thu, Oct 5, 2017 at 6:34 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Yes, canEqual implementation also make #= be commutative. > > On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> >> >> 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>> >>> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >>>> >>>> I am sorry, not species, but #isKindOf istead of #= to compare classes. >>> >>> >>> It is bad idea. #= should be transitive. >> >> >> Oh, I used wrong word, shame on me :). I tried to say commutative. >> >>> >>> How you will generate it with isKindOf: logic? You need to know common >>> parent. >>> >>> Also I not remember cases where I was needed two instances of different >>> classes to be equal. >>> And I can imaging the problems which it will lead to. >>> >>>> >>>> >>>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>> wrote: >>>>> >>>>> >>>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>> >>>>>> >>>>>> Two questions/comments about the generated code: >>>>>> 1. #= >>>>>> ... >>>>>> self class = anObject class "should compare #species instead?" >>>>>> ifFalse: [ ^ false ]. >>>>>> ... >>>>>> Typically, I've seen #species instead of #class in the guard >>>>>> statement. >>>>>> Should we change it to that? >>>>> >>>>> >>>>> I doubt that it is important for domain classes. Because I never saw >>>>> the user of #species which is not a kind of Collection. And for collections >>>>> this refactoring is not valid anyway. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2. #hash >>>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>>> Is this implementation always safe? It's what I usually hand roll >>>>>> based on >>>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>>> hashing, so >>>>>> I've always wondered if I was missing somethingâ¦ >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Cheers, >>>>>> Sean >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>> >>>>> >>>> >>> >> >

Oct. 6, 2017

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

by Stephane Ducasse

Thanks I think that this is really nice. Thanks for your time. On Fri, Oct 6, 2017 at 2:42 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Cool! Waiting for the updated version with this mailing list feedback on it. > > Cheers, > > Offray > > > On 05/10/17 19:35, horrido wrote: >> Yes, the "updated" angle was the crucial tactic. Thanks. >> >> I just wanted to inform you that in just 48 hours since publication, this >> article has gathered over 11,000 views! This is a new record for me. Fastest >> rising. >> >> I am astounded by the number; I really didn't expect it. It's a very, very >> nice way to end my campaign on a high note. Hopefully, Pharo (and Smalltalk) >> will become more popular. >> >> Cheers. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > >

Oct. 6, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

Cool! Waiting for the updated version with this mailing list feedback on it. Cheers, Offray On 05/10/17 19:35, horrido wrote: > Yes, the "updated" angle was the crucial tactic. Thanks. > > I just wanted to inform you that in just 48 hours since publication, this > article has gathered over 11,000 views! This is a new record for me. Fastest > rising. > > I am astounded by the number; I really didn't expect it. It's a very, very > nice way to end my campaign on a high note. Hopefully, Pharo (and Smalltalk) > will become more popular. > > Cheers. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 6, 2017

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

by horrido

Yes, the "updated" angle was the crucial tactic. Thanks. I just wanted to inform you that in just 48 hours since publication, this article has gathered over 11,000 views! This is a new record for me. Fastest rising. I am astounded by the number; I really didn't expect it. It's a very, very nice way to end my campaign on a high note. Hopefully, Pharo (and Smalltalk) will become more popular. Cheers. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

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

by Cyril Ferlicot D.

Le 05/10/2017 Ã 16:29, Holger Freyther a Ã©critÂ : > I don't have a RHEL subscription but I assumed they are similar but > OBS even produces RHEL packages: > > https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/… > > > Not sure. Even the RHEL documentation mentions --add-repo exists. I assume > you can download the .repo[1] file and put it in the right directory? > > I tested on a CentOS 6.9 and it worked fine. I'll see next week if it works fine on RHEL. Thank you. > holger > > > > > [1] > RHEL6: > https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/… > > CentOS6: > https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/… > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Oct. 5, 2017

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

by phil＠highoctane.be

Any developer can get a free RHEL license and a dev account for accessing docs and what not. This includes CVE fixes etc. CentOS is close but not always the same. e.g. no security fixes are included vs RHEL when updating (even if the flag is accepted). I am going next week to the RedHat forum in Breda. I would like to find how to get Pharo available on RHEL out of the box. Phil On Thu, Oct 5, 2017 at 4:29 PM, Holger Freyther <holger(a)freyther.de> wrote: > > > On 5. Oct 2017, at 22:22, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> > wrote: > > > > > > > Your instructions describes the steps for CentOS 6.x. Are they the > > exact same steps for RHEL6? > > I don't have a RHEL subscription but I assumed they are similar but > OBS even produces RHEL packages: > > https://download.opensuse.org/repositories/devel:/languages: > /pharo:/stable/RHEL_6/ > > > > > Also, I am trying this on a CentOS 6.0 virtual machine and I get this > error : > > > > [centoslive@livecd test]$ yum-config-manager --add-repo > > http://download.opensuse.org/repositories/devel:/languages: > /pharo:/latest/CentOS_6/devel:languages:pharo:latest.repo > > Loaded plugins: fastestmirror, refresh-packagekit > > Usage: "yum-config-manager [options] [section] > > > > Command line error: no such option: --add-repo > > [centoslive@livecd test]$ > > > > > > Is there something else to install before? > > Not sure. Even the RHEL documentation mentions --add-repo exists. I assume > you can download the .repo[1] file and put it in the right directory? > > > holger > > > > > [1] > RHEL6: > https://download.opensuse.org/repositories/devel:/languages: > /pharo:/stable/RHEL_6/devel:languages:pharo:stable.repo > > CentOS6: > https://download.opensuse.org/repositories/devel:/languages: > /pharo:/stable/CentOS_6/devel:languages:pharo:stable.repo > >

Oct. 5, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Vitor Medina Cruz

Yes, canEqual implementation also make #= be commutative. On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >> >>> I am sorry, not species, but #isKindOf istead of #= to compare classes. >>> >> >> It is bad idea. #= should be transitive. >> > > Oh, I used wrong word, shame on me :). I tried to say commutative. > > >> How you will generate it with isKindOf: logic? You need to know common >> parent. >> >> Also I not remember cases where I was needed two instances of different >> classes to be equal. >> And I can imaging the problems which it will lead to. >> >> >>> >>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> >>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>> >>>>> >>>>> Two questions/comments about the generated code: >>>>> 1. #= >>>>> ... >>>>> self class = anObject class "should compare #species instead?" >>>>> ifFalse: [ ^ false ]. >>>>> ... >>>>> Typically, I've seen #species instead of #class in the guard statement. >>>>> Should we change it to that? >>>>> >>>> >>>> I doubt that it is important for domain classes. Because I never saw >>>> the user of #species which is not a kind of Collection. And for collections >>>> this refactoring is not valid anyway. >>>> >>>> >>>>> >>>>> >>>>> 2. #hash >>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>> Is this implementation always safe? It's what I usually hand roll >>>>> based on >>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>> hashing, so >>>>> I've always wondered if I was missing somethingâ¦ >>>>> >>>>> >>>>> >>>>> ----- >>>>> Cheers, >>>>> Sean >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>> >>>>> >>>> >>> >> >

Oct. 5, 2017

Re: [Pharo-users] Brea wiki software

by Offray Vladimir Luna CÃ¡rdenas

Hannes, Happy to help, at least with some ideas. Brea is still an early prototype, but suit my needs without the burden of all the extra stuff Seaside includes, for simple cases as mine, but if glad to know that it works for your use case. Cheers, Offray On 05/10/17 10:49, H. Hirzel wrote: > Hello Offray > > Thank you for making the Brea wiki code available. I have read it and > got some ideas out of it. > > My conclusion was that I do not have the capacity at the moment to > continue working on it. > > So I went for Seaside though the library is large. It has a simple > wiki as well. And with Pier are more elaborate version. > > Seaside is well documented. > > Regards > Hannes > > On 9/6/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> Hi, >> >> >> On 06/09/17 02:12, H. Hirzel wrote: >>> So at the moment I am fine to get it up and running using a FossilRepo. >>> Later on I will work on replacing it with a JSON data store. >> Please let me know if you need any permissions into the repository to >> make JSON data store available in Brea. >> >>> On 9/6/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>> I understand that it makes a lot of sense to reuse the functions >>>> implemented in the FossilRepo. >>>> >>>> Installation of the Fossil version control system seems to be very >>>> simple, just put a single executable file into the pharo folder for >>>> example >>>> >>>> https://fossil-scm.org/index.html/doc/trunk/www/index.wiki >> Yes. Fossil is simpler and self-contained. A lot of friendly and >> powerful user experience without importing the external complexities of >> other developer cultures, like the popular systems (*coff... Git). I use >> the one provided by my package manager, but we have installed Fossil and >> started to use in our workshops and is a lot easier to start being >> productive without the almost always gratuitous extra complexities, >> specially for non tekies. Fossil gives me and easy distributed wiki out >> of the box. >> >>>> On 9/6/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>>> What I wanted to write is that the class FossilRepo is not included. >>>>> >>>>> And that the setup of the Teapot server should not be hidden in lazy >>>>> initialisation method but made explicit with some methods in a method >>>>> category called 'setup' or 'configuration'. >> Please update your ConfigurationOfBrea, which fixes this two issues. >> >>>>>> On 9/6/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> >>>>>> wrote: >>>>>>> Hi, Hannes, >>>>>>> >>>>>>> Sorry it took so long. >>>>>> No problem. It was actually less than 14 days which is not long ..... >>>>>> >>>>>> :-) >> Despite of being just one week after I told you I would look at the >> issue, because the first one I have not access to my computer, is kind >> of a lot considering the good support times in this community (with rare >> exceptions, like when I feedback GT Tools and get no response :-/). >> >> Cheers, >> >> Offray >> >

Oct. 5, 2017

SystemVersion cleanup (or the return of the explicit build number) in latest Pharo 7

by Torsten Bergmann

Hi, as you all know Pharo 7 is built using sources from github and a new bootstrap process. The first Pharo 7 images [1] unfortunately were hard to distinguish - the initial problem was described in [2] Guille tried to address this by adding a build number again [3] but unfortunately he mixed it into the existing suffix of the class SystemVersion. There was also some other trouble afterwards: - the highestUpdate was still not set by the bootstrap process, which made some code unloadable (like Artefact who's config is checking if it is above a certain update number) - with Guilles fix the build number had to be parsed from the suffix string - one was still not able to distinguish 32/64 bit images - the SystemVersion class and the according tests were still ugly So I reviewed all this more deeply and cleaned SystemVersion as well as the tests while trying to stay as compatible as possible. Thanks a lot to Pavel and Esteban who helped me sorting things out, especially in git and the bootstrap process. How does it look now ==================== 1. Our system type is still called "Pharo" ;) SystemVersion current type -> 'Pharo' 2. we still continue with major and minor versioning (leaving out patch versions), so currently work is done for Pharo 7.0 SystemVersion current major -> 7 SystemVersion current minor -> 0 SystemVersion current majorMinorVersion -> 'Pharo7.0' 3. the identification string now has a "+" sign inside to separate the build meta informations following the given rule 10 from http://semver.org So the full image version now looks like this: SystemVersion current imageVersionString -> 'Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (32 Bit)' 4. the suffix is currently "alpha" and may be changed depending on release status SystemVersion current suffix -> 'alpha' 5. the build number is stored as an explicit ivar in SystemVersion now SystemVersion current build -> 168 Note that the build number is explicitly set during the bootstrap process from the outside and increased over time with each new build. It represents the CI build number of #development branch now, see [4] on CI server 6. the github SHA commit hash is accessible too: SystemVersion current commitHash -> '30fc9bbe79922877706ecd842f8aef6822cdcdd9' which corresponds in this case to the last commit in #development branch https://github.com/pharo-project/pharo/commit/30fc9bbe79922877706ecd842f8ae… 7. the version includes now also the 32/64 bit distinction: Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (32 Bit) or Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (64 Bit) Additionally ============ - the version is displayed in SystemReporter and the AboutBox (Screenshot attached), please use this to identify the image easily - the #highestUpdate is calculated dynamically with code in the image (but it is there only for compatibility reasons). SystemVersion current highestUpdate -> "70168" We might easily catch the 999 build mark now and then run into 71000 which might still be Pharo 7.0 instead of 7.1. (which means first two digits of update number will then NOT correspond to major/minor version anymore). So better avoid #highestUpdate as a meaningful number for loading code or other. - also note if you contribute with an own PR (in your own fork on github) the build number is the build number of you PR specific CI build. Once your PR is reviewed and merged it is the regular Pharo image build number again. - you can reuse SystemVersion for you own apps built on top of Pharo: "MyKillerApp-1.0+beta (64 Bit)" can be easily created with: (SystemVersion major: 1 minor: 0 suffix: 'beta') type: 'MyKillerApp'; yourself - if you report a bug on bugs.pharo.org it would be good to note down the full version of the image you used as found in the About box. This allows to better reproduce wrong behavior that only happens in a specific image Thanks T. [1] http://files.pharo.org/image/70/ [2] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-August/1309… [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-August/1310… [4] https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 5, 2017

Re: [Pharo-users] Brea wiki software

by H. Hirzel

Hello Offray Thank you for making the Brea wiki code available. I have read it and got some ideas out of it. My conclusion was that I do not have the capacity at the moment to continue working on it. So I went for Seaside though the library is large. It has a simple wiki as well. And with Pier are more elaborate version. Seaside is well documented. Regards Hannes On 9/6/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi, > > > On 06/09/17 02:12, H. Hirzel wrote: >> So at the moment I am fine to get it up and running using a FossilRepo. >> Later on I will work on replacing it with a JSON data store. > > Please let me know if you need any permissions into the repository to > make JSON data store available in Brea. > >> >> On 9/6/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>> I understand that it makes a lot of sense to reuse the functions >>> implemented in the FossilRepo. >>> >>> Installation of the Fossil version control system seems to be very >>> simple, just put a single executable file into the pharo folder for >>> example >>> >>> https://fossil-scm.org/index.html/doc/trunk/www/index.wiki > > Yes. Fossil is simpler and self-contained. A lot of friendly and > powerful user experience without importing the external complexities of > other developer cultures, like the popular systems (*coff... Git). I use > the one provided by my package manager, but we have installed Fossil and > started to use in our workshops and is a lot easier to start being > productive without the almost always gratuitous extra complexities, > specially for non tekies. Fossil gives me and easy distributed wiki out > of the box. > >>> On 9/6/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>> What I wanted to write is that the class FossilRepo is not included. >>>> >>>> And that the setup of the Teapot server should not be hidden in lazy >>>> initialisation method but made explicit with some methods in a method >>>> category called 'setup' or 'configuration'. > > Please update your ConfigurationOfBrea, which fixes this two issues. > >>>>> On 9/6/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> >>>>> wrote: >>>>>> Hi, Hannes, >>>>>> >>>>>> Sorry it took so long. >>>>> No problem. It was actually less than 14 days which is not long ..... >>>>> >>>>> :-) > > Despite of being just one week after I told you I would look at the > issue, because the first one I have not access to my computer, is kind > of a lot considering the good support times in this community (with rare > exceptions, like when I feedback GT Tools and get no response :-/). > > Cheers, > > Offray >

Oct. 5, 2017

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

by Holger Freyther

> On 5. Oct 2017, at 22:22, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > > Your instructions describes the steps for CentOS 6.x. Are they the > exact same steps for RHEL6? I don't have a RHEL subscription but I assumed they are similar but OBS even produces RHEL packages: https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/… > Also, I am trying this on a CentOS 6.0 virtual machine and I get this error : > > [centoslive@livecd test]$ yum-config-manager --add-repo > http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… > Loaded plugins: fastestmirror, refresh-packagekit > Usage: "yum-config-manager [options] [section] > > Command line error: no such option: --add-repo > [centoslive@livecd test]$ > > > Is there something else to install before? Not sure. Even the RHEL documentation mentions --add-repo exists. I assume you can download the .repo[1] file and put it in the right directory? holger [1] RHEL6: https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/… CentOS6: https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/…

Oct. 5, 2017

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

by Cyril Ferlicot

On 10/5/17, Holger Freyther <holger(a)freyther.de> wrote: > > Hi! > > > 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 > > Thank you. Your instructions describes the steps for CentOS 6.x. Are they the exact same steps for RHEL6? Also, I am trying this on a CentOS 6.0 virtual machine and I get this error : [centoslive@livecd test]$ yum-config-manager --add-repo http://download.opensuse.org/repositories/devel:/languages:/pharo:/latest/C… Loaded plugins: fastestmirror, refresh-packagekit Usage: "yum-config-manager [options] [section] Command line error: no such option: --add-repo [centoslive@livecd test]$ Is there something else to install before? > > > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Oct. 5, 2017

Re: [Pharo-users] Open Sourcing the Data Journalism Handbook with Grafoscopio

by Offray Vladimir Luna CÃ¡rdenas

Thanks Ben, Your words are encouraging as always. Is really worthy to count with people like you, that you care so much for the community and have always time for suggestions and support in several members projects and issues. Cheers, Offray On 05/10/17 08:50, Ben Coman wrote: > Great to hear every time your progress with this.Â That "Handbook > Hack" mentioned on the DJH site looks like a good place to promote > Grafoscopio. > > cheers -ben > > On Thu, Oct 5, 2017 at 10:14 AM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Upps... I copied and pasted parts of my original post in the Open > Knowedge Forum, so it seems that it got scrambled with some extra > information from there here. > > Anyway I hope the message is clear. > > Cheers, > > Offray > > > On 04/10/17 21:09, Offray Vladimir Luna CÃ¡rdenas wrote: >> >> Hi, >> >> Recently, in our local hackerspace <http://hackbo.co/>, we used, >> extended and adapted, Grafoscopio >> <http://mutabit.com/grafoscopio/index.en.html> to recreate the >> first open source version of the Data Journalism Handbook >> <http://datajournalismhandbook.org/>, in Spanish. Quoting from >> the project page: >> >> There are some interesting Free Cultural Works >> <http://freedomdefined.org/Definition> which are not open >> sourced. >> This means that, they are covered under pretty liberal licenses, >> allowing their remix, sale and modification, but the >> infrastructures >> which support the creation, modification and publishing of >> such works, >> donât allow wide participation and deep traceability of their >> history of >> such collective endeavors. >> >> This is our approach about alternative ways for creating such >> works, >> addressing the above problem, using the Data Journalism >> Handbook as an >> example (English <http://datajournalismhandbook.org/>, >> Spanish <http://interactivos.lanacion.com.ar/manual-data/>) >> and /pocket infrastructures/, which are simple, self >> >> contained, and work well on-line and off-line, like Fossil >> <http://fossil-scm.org/> and >> Grafoscopio <http://mutabit.com/grafoscopio/index.en.html>. >> Also we extended and adapted Grafoscopio, during this project, >> to make the tool suit the problem (and not the usual other >> way around). >> >> More information and downloadable files in the project source >> code repository: >> >> http://mutabit.com/repos.fossil/mapeda/ >> <http://mutabit.com/repos.fossil/mapeda/> >> >> This is also an example of the kind of books you can create now >> with/inside Grafoscopio (with Pandoc). >> >> And, of course, the customary screenshots: >> >> photo532578960227822324 >> >> photo5082366090373343168 >> >> Captura de pantalla del manual en Grafoscopio. >> >> >> Cheers, >> >> Offray >> >> > >

Oct. 5, 2017

Re: [Pharo-users] Open Sourcing the Data Journalism Handbook with Grafoscopio

by Ben Coman

Great to hear every time your progress with this. That "Handbook Hack" mentioned on the DJH site looks like a good place to promote Grafoscopio. cheers -ben On Thu, Oct 5, 2017 at 10:14 AM, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Upps... I copied and pasted parts of my original post in the Open Knowedge > Forum, so it seems that it got scrambled with some extra information from > there here. > > Anyway I hope the message is clear. > > Cheers, > > Offray > > On 04/10/17 21:09, Offray Vladimir Luna CÃ¡rdenas wrote: > > Hi, > > Recently, in our local hackerspace <http://hackbo.co/>, we used, extended > and adapted, Grafoscopio <http://mutabit.com/grafoscopio/index.en.html> > to recreate the first open source version of the Data Journalism Handbook > <http://datajournalismhandbook.org/>, in Spanish. Quoting from the > project page: > > There are some interesting Free Cultural Works > <http://freedomdefined.org/Definition> which are not open sourced. > This means that, they are covered under pretty liberal licenses, > allowing their remix, sale and modification, but the infrastructures > which support the creation, modification and publishing of such works, > donât allow wide participation and deep traceability of their history of > such collective endeavors. > > This is our approach about alternative ways for creating such works, > addressing the above problem, using the Data Journalism Handbook as an > example (English <http://datajournalismhandbook.org/>, Spanish > <http://interactivos.lanacion.com.ar/manual-data/>) and *pocket > infrastructures*, which are simple, self > > contained, and work well on-line and off-line, like Fossil > <http://fossil-scm.org/> and > Grafoscopio <http://mutabit.com/grafoscopio/index.en.html>. Also we > extended and adapted Grafoscopio, during this project, > to make the tool suit the problem (and not the usual other way around). > > More information and downloadable files in the project source code > repository: > > http://mutabit.com/repos.fossil/mapeda/ > > This is also an example of the kind of books you can create now > with/inside Grafoscopio (with Pandoc). > > And, of course, the customary screenshots: > > [image: photo532578960227822324] > > [image: photo5082366090373343168] > > [image: Captura de pantalla del manual en Grafoscopio.] > > > Cheers, > > Offray > > > >

Oct. 5, 2017

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

by Holger Freyther

> 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. 5, 2017

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

by Ben Coman

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 optimsation" fair as a short tagline for inter-language comparison?) So maybe say "the Pharo project has been involved in producing: ... * the 64-bit Spur/Cog VM (used also by Squeak, Cuis and Newspeak) * hotspot optimisation with Sista * working towards embedding Pharo as a game scripting language" (not sure on that last one) cheers -ben On Wed, Oct 4, 2017 at 6:30 PM, horrido <horrido.hobbies(a)gmail.com> wrote: > Behold Pharo: The Modern Smalltalk > <https://medium.com/smalltalk-talk/behold-pharo-the-modern- > smalltalk-38e132c46053> > > If you would like to suggest some edits, I'm all ears. Anything to improve > the impact of the article. > > Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 5, 2017

Re: [Pharo-users] 6.1 Stable 64 - Crash when loading repository

by JuliÃ¡n Maestri

Sorry for the delay. $ uname -a Linux PC51 4.4.0-96-generic #119-Ubuntu SMP Tue Sep 12 14:59:54 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.3 LTS Release: 16.04 Codename: xenial On 4 October 2017 at 17:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hello Julian > > Thanks for the report. > on which OS are you? > > Stef > > On Wed, Oct 4, 2017 at 8:33 PM, JuliÃ¡n Maestri <serpi90(a)gmail.com> wrote: > > On a clean image from get.pharo.org/64/ > > Attempting to load the following repository > > > > Metacello new > > baseline: 'WillowBootstrap'; > > repository: 'github://ba-st/Willow-Bootstrap:master/source'; > > load. > > > > Consistently causes a VM crash (crash.dump in attatchment). > > > > This does not happen with the 32 bit image. > > > > Image + VM details > > > >> Image > >> ----- > >> /home/jmaestri/Pharo/workspace/Pharo.image > >> Pharo6.0 > >> Latest update: #60510 > >> Unnamed > >> Virtual Machine > >> --------------- > >> /home/jmaestri/Pharo/workspace/pharo-vm/lib/pharo/ > 5.0-201707201942/pharo > >> CoInterpreter VMMaker.oscog-eem.2254 uuid: > >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > >> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ > >> Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 > >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > >> Unix built on Jul 20 2017 20:40:36 Compiler: 4.6.3 > >> VMMaker versionString VM: 201707201942 > >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul > 20 > >> 12:42:21 2017 -0700 $ Plugins: 201707201942 > >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > >> CoInterpreter VMMaker.oscog-eem.2254 uuid: > >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 > >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: > >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 > > > > > > > > > >

Oct. 5, 2017

Re: [Pharo-users] SVG Icons

by Peter UhnÃ¡k

Hi, this is not really tested, but you can try to do the following (installation) a) install XMLParser from catalog b) in monticello browser open Pharo/Athens and load latest version of Athens-SVG package (usage) Then you import SVG XML using Converter and paint it on a surface, which you convert to Form. ``` contents := (ZnEasy get: 'https://s.cdpn.io/3/kiwi.svg') contents. xmlDoc := XMLDOMParser parse: contents. svg := AthensSVGConverter new importXMLDocument: xmlDoc. svg transform: 'scale(0.5)'. extent := 500 @ 500. surface := AthensCairoSurface extent: extent. surface drawDuring: [ :aCanvas | svg renderOn: aCanvas ]. surface asForm. ``` [image: Inline image 1] Peter On Thu, Oct 5, 2017 at 1:50 PM, Steven R. Baker <steven(a)stevenrbaker.com> wrote: > Heya folks! > > I need to load SVG images (for icons) in my application. I've searched > my 6.1 image for SVG, but haven't found anything. > > Is there a library for loading SVGs? I'd really like to get them > directly into instances of Form if possible, but I'm flexible. :) > > Thanks! > > -Steven > > > >

Oct. 5, 2017

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

by phil＠highoctane.be

CentOS6.9 for one. Phil On Thu, Oct 5, 2017 at 11:30 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > On 4. Oct 2017, at 17:39, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> > wrote: > > > > Hi, > > > > I am migrating some applications from Pharo 4 to Pharo 6. The new > > deployment of those applications needs to work on linux with LibC < > > 2.15. With Pharo 4 there was a special VM[1]. I do not see such VM for > > Pharo 6. > > Which OS has such old versions of LibC? Which LSB standard does it support? > > >

Oct. 5, 2017

SVG Icons

by Steven R. Baker

Heya folks! I need to load SVG images (for icons) in my application. I've searched my 6.1 image for SVG, but haven't found anything. Is there a library for loading SVGs? I'd really like to get them directly into instances of Form if possible, but I'm flexible. :) Thanks! -Steven

Oct. 5, 2017