December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Adapting the launcher to Spur VM

by Guillermo Polito

Hmm, usually an image file has a header that describes some meta data about the image: version, some VM options, size of the imageâ¦ If you load: Gofer it squeaksource3: 'ImageWriter'; package: âImageWriter-Core'; load. Youâll get HzCogImageFormat that describes the header. Check the method writeImageHeaderOn: byteStream forWriter: aWriter > On 17 dic 2015, at 12:44 p.m., Damien Cassou <damien.cassou(a)inria.fr> wrote: > > Hi, > > from a Pharo image, can I detect if another image needs the Spur VM or > not? > > Best > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

Dec. 17, 2015

Adapting the launcher to Spur VM

by Damien Cassou

Hi, from a Pharo image, can I detect if another image needs the Spur VM or not? Best -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Dec. 17, 2015

Monkey restored: Spur migration "mostly" finished!

by Esteban Lorenzano

Hi, Soâ¦ monkey is running again! Which means you can restart send your bug reports (and bug fixes)â¦ we are back to business! Now, time to fix the remaining problemsâ¦ but you all can help! cheers, Esteban

Dec. 17, 2015

Re: [Pharo-dev] [squeak-dev] Re: [Cuis] Sorting Unicode strings (Re: [Unicode] collation sequences (Re: Unicode Support))

by Todd Blanchard

Sounds very sensible. And from other messages it sounds like the Squeak camp already did it...so why do we not steal/borrow it? > On Dec 15, 2015, at 17:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Does this make sense?

Dec. 17, 2015

Raspberry Pi Scratch with GPIO

by Ben Coman

I was just looking to show a friend at work programming for kids on the Raspberry Pi, away from my usual Smalltalk activities at home, and was surprised to find an article mentioning Scratch with GPIO and our very own Tim & Eliot, which I thought I'd share https://www.raspberrypi.org/blog/a-new-version-of-scratch-for-raspberry-pi-… cheers -ben

Dec. 17, 2015

Re: [Pharo-dev] Fuel materialization on spur

by Robert Withers

I really would love to and I will probably do so to take my mind of the refactoring I am engaged in as I broke my SecureSession code. Note this basically includes a small outside header describing the contents of a FEC encoded msg. There will be an inside header coming later. I am not yet ASN1 encoding it. The picture I used to have, if you can imagine it is a 9 layer OSI stack, where layer 8 is the marketplace of running or invokable applications and the 9th, the meta, describes the work. One job where we did this we pushed event structure definitions and writer and reader interfaces for event flows. So all of this definition is stuffed into the meta, accessible anywhere in the distributed app. Furthermore, we injected decoders into the presentation layer and injected running readers and writers into the control layer (part of layer 8... 8 1/2) I hope this gives you a bit of a better picture what I am speaking about. When my world stabilizes I will try to get back to you soon, but I cannot promise you I will remember - my apologies for that. regards, robert On 12/16/2015 05:22 PM, phil(a)highoctane.be wrote: > Can you make a more detailed vision (with a picture) about this? > > As I have a cluster running and am paid to do some stuff with all you > list, I can use some time exploring those avenues. > > Phil > > On Wed, Dec 16, 2015 at 7:07 PM, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > Excuse me: > > With interfaces I think groovy. > With object serialization I think avro. > With header encoding I think ASN1DER with dynamic extension, we need > variable encoding of statistical objects. > With packages I think gradle. > > this would be powerful, > robert > > On 12/16/2015 01:00 PM, Robert Withers wrote: > > I'd like to add that this is a real challenge to existing players in > BigData, all of who offer solutions in this exact space. Whoever > controls it's specification, controls it's cloud market. > > My back of the envelope proposal (my apologies for my > abrasiveness with > this approach) is such: > > We develop a dynamic cloud meta & control solution: replicated, > eventually consistent and so on. We define the serialization, > interfaces > and package identification to this meta as open-source standards. > > With interfaces I think Avro. > > With serialization I think ASN1DER encoding, plus non-fixed dynamic > structure extension. > > With package identification I think Gradle. Do we have a groovy > compiler? > > I thought I would round out my thinking as I believe this to be an > important opportunity. Given that the new internet is going to be > governed by always running, maximally interactive execution > sites, it > will naturally move to Smalltalk, so I do not think there is > anything > for anyone to be concerned about. > > Patience and not reacting emotionally to misinformation in the > marketplace will show true colors. Business is warfare. We have the > advantage. > > peace, > robert > > > On 12/16/2015 12:38 PM, Robert Withers wrote: > > Allow me to speak a little on my ideas of a distributed meta > layer and > control layer in cloud deployments with Squeak/Pharo, > hopefully in > bounds. > > A distributed system must have an metadata repsoitory > describing the > traffic and activity. If you look at deployment, code that > works with > a type and version of data must be present. With packaging > and dynamic > loading, chunks of code registered to a data type/version in > the meta > demand loads a achunk to do directed work in a particular > deployed > image. BigData event flows and data analysis like to get > replicated > and relocated, in realtime. Supporting this in the meta > definitional > layer and the 1/2 control layer starts to do dynamic, > late-binding in > the network. This is the advantage Squeak/Pharo image-based > environments bring to the business table. > > Thank you and apologies, > robert > > On 12/16/2015 09:57 AM, H. Hirzel wrote: > > Is there a Pharo implementation? > https://avro.apache.org/docs/1.2.0/ > > On 12/16/15, Robert Withers <robert.w.withers(a)gmail.com > <mailto:robert.w.withers@gmail.com>> wrote: > > Please consider Avro. > > robert > > On 12/16/2015 08:58 AM, H. Hirzel wrote: > > If you want to move data to Java then you > probably go for JSON or a > particuar XML format. > > On 12/16/15, H. Hirzel <hannes.hirzel(a)gmail.com > <mailto:hannes.hirzel@gmail.com>> wrote: > > No, it is a Smalltalk format. > > On 12/16/15, Denis Kudriashov > <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>> wrote: > > 2015-12-16 14:41 GMT+01:00 H. Hirzel > <hannes.hirzel(a)gmail.com > <mailto:hannes.hirzel@gmail.com>>: > > It probably should be noted here as > well that > > http://pharo.gemtalksystems.com/book/PharoTools/SIXX/ > > Just to know does java implementation > exists? > > -- > . .. .. ^,^ best, robert > > > > > > -- > . .. .. ^,^ best, robert > > -- . .. .. ^,^ best, robert

Dec. 17, 2015

Re: [Pharo-dev] AsmJit

by phil＠highoctane.be

Hi, I get you. What I mean is to use AsmJIT "way of writing assembly" *DSL*, not the actual part generating the machine code. The DSL would translate into inlined asm code in a C file, that in turn is indeed compiled into and object file, linked into a DLL, and the reloaded as a module, and invoked back through FFI. Hope it is clearer. Phil On Wed, Dec 16, 2015 at 9:01 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Phil, > > On Wed, Dec 16, 2015 at 10:14 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> Eliot, >> >> The C code generator has been externalized, so it is not dependent on >> VMMaker. >> >> http://www.smalltalkhub.com/#!/~PavelKrivanek/CCodeGenerator >> >> As far as we can have an ASM DSL that would be working along with that >> generator, there is no reason why we couldn't have assembly code part >> emitted by that CCodeGenerator as inlined asm bits ( >> https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html) >> >> e.g. https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm >> > > Yes, but you have to invoke gcc to translate the C and extended asm into > assembler, and an assembler to translate that output into machine code, > except that the assembler produces object files, not raw machine code. > > >> >> So, AsmJit syntax would extend CCodeGenerator and output C and inlined >> asm that would then be compiled and invoked with FFI ( >> https://clementbera.wordpress.com/2013/06/19/optimizing-pharo-to-c-speed-wi… >> ) >> >> This may not be the use case for writing FFI but that is a use case for >> writing and invoking ASMx86 in Smalltalk (or whatever else, based on the >> AsmJIT syntax for a given architecture + backend for CCodeGenerator). >> >> What do you think? >> > > I don't think it solves the problem. AsmJIT is a source to machine-code > translator but Slang is a source to source translator. So I don't see how > it solves the key problem, which is to generate the machine code for FFI > call argument marshalling according to the rules of the underlying > platform's ABI. Maybe I'm being dense, but it doesn't seem to me to be > relevant. > > Right now, the Cog JIT contains an assembler and translates byte coded > methods into sequences of assembler instructions and these into machine > code embedded in CogMethod objects in the VM. AsmJIT contains an assembler > which translates assembler instructions to machine code and embeds those > machine code sequences in the trailer of compiled methods and then contains > a hack to get the Cog JIT to call that machine code. None of these > assembler to machine code steps are provided (at least not conveniently) by > your proposed tool chain above. There is obvious duplication in having Cog > contain an assembler and AsmJIT contain an assembler. But Cog also > contains an escape sequence of byte codes we are using to generate > efficient, unsafe code. This can be used to generate the marshalling code > we need, and do it in a cross-platform manner, avoiding the duplication > inherent in AsmJIT above Cog, and avoiding the hacks necessary to get Cog > to be able to use the code embedded in method trailers (such as making the > entire heap executable, and hacking Cog to call these escape sequences). > I'm making myself parse here articulating what I think is an elegant, > general and powerful architecture. But people find it boring. I don't > understand. I think I'm going to shut up :-/ > > > Phil >> >> On Wed, Dec 16, 2015 at 6:06 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >>> Hi Phillippe, >>> >>> On Wed, Dec 16, 2015 at 2:14 AM, philippe.back(a)highoctane.be < >>> philippe.back(a)gmail.com> wrote: >>> >>>> Couldn't we reuse the AsmJIT DSL and generate some C code with Asm >>>> directives through Slang? >>>> >>> >>> C is too high-level for the intended purposes (e.g. performing FFI >>> calls) and Slang is not at all genial purpose or suitable for being used at >>> run-time. Its tightly coupled to the VMaker. >>> >>> And call that C code through FFI? >>>> >>> >>> Since the main use case for this system is to implement the marshalling >>> code for FFI calls this doesn't work. >>> >>>> Seems cleaner and more debuggable. >>>> And could be moved to x64. >>>> >>>> Phil >>>> >>>> On Dec 16, 2015 6:49 AM, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: >>>> > >>>> > >>>> > >>>> > 2015-12-15 20:22 GMT+01:00 Jan Vrany <jan.vrany(a)fit.cvut.cz>: >>>> >> >>>> >> Hi Esteban, Eliot, Clemont >>>> >> >>>> >> thanks very much for elaborate answer. I'm aware of all what you said >>>> >> (well, most :-), but my actual needs are very low and primitive. >>>> >> >>>> >> All I need now is something that allows me to turn x86_64 assembly >>>> >> into a machine code using a sane Smalltalk API, which I can later >>>> copy >>>> >> to VM code space. Nothing more, nothing less :-) I do not fancy >>>> >> spending time writing yet-another-x86-assembler hence my interest in >>>> >> asmjit. >>>> > >>>> > >>>> > As far as I know AsmJIT has stable support for x86 but not x86_64 >>>> >> >>>> >> >>>> >> Thanks! Jan >>>> >> >>>> >> >>>> >> >>>> >> On Tue, 2015-12-15 at 18:34 +0100, ClÃ©ment Bera wrote: >>>> >> > We're getting away from Jan initial question here ... >>>> >> > >>>> >> > I think the point here is that Cog has: >>>> >> > - 2 stable back ends: ARMv5 and x86 >>>> >> > - 2 backends stable in the simulator with production planned for ~ >>>> >> > April: x64 and MIPS >>>> >> > and Tim is willing to do the ARMv8 backend. >>>> >> > >>>> >> > All the 4, and soon 5, cog back ends are maintained: >>>> >> > - x86 and x64 maintained by Eliot >>>> >> > - MIPS maintained by Ryan >>>> >> > - ARMv5 and soon ARMv8 maintained by Tim >>>> >> > >>>> >> > Each backend requires months of work. >>>> >> > >>>> >> > Do you want to maintain 10 backends instead of 5 ? Do want to spend >>>> >> > time to implement 5 backends or 10 ? >>>> >> > >>>> >> > I don't. Only the x86 backend is duplicated right now in AsmJIT. >>>> >> > >>>> >> > So one idea is to reuse Cog's backends from the image instead of >>>> >> > AsmJIT. To do so, we can use encodings available in the sista >>>> >> > extended instruction set to tell Cog what machine code to >>>> generate. A >>>> >> > project named uFFI aims, among other things, at doing this, by >>>> >> > providing a unified interface between the Cog backends and AsmJIT. >>>> >> > >>>> >> > >>>> >> > 2015-12-15 16:43 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com >>>> >: >>>> >> > > Hi Jan, >>>> >> > > >>>> >> > > > On Dec 15, 2015, at 3:06 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> >>>> >> > > wrote: >>>> >> > > > >>>> >> > > > Hi guys, >>>> >> > > > >>>> >> > > > two queations: >>>> >> > > > >>>> >> > > > (i) Is AsmJit going to be developed any more or it's abandoned >>>> >> > > > as well as native boost? >>>> >> > > >>>> >> > > AsmJIT is effectively being abandoned but NativeBoost is not. >>>> >> > > >>>> >> > > The key limitation of AsmJIT is that it was not designed to be >>>> >> > > cross platform; it is effectively an x86 assembler. As such it's >>>> >> > > use gets in the way of ARM and x86_64 (I am currently getting >>>> the C >>>> >> > > version of 64-bit Cog Spur working on x86_64, given that it is >>>> >> > > working in the simulator). >>>> >> > > >>>> >> > > Another limitation is that it doesn't play that well with the >>>> VM's >>>> >> > > JIT. Igor and I never managed to work on integrating it better. >>>> >> > > The VM's job is managing code and Igor's approach was to hack; >>>> >> > > eliminating execution protection in the entire heap, instead of >>>> >> > > extending the support that either the Alien plugin's callback >>>> >> > > support or the JIT's executable method zone provides. Making the >>>> >> > > entire heap executable is /not/ a sensible approach. >>>> >> > > >>>> >> > > But there is a better way! A key component of the Sista adaptive >>>> >> > > optimizer/speculative inlined that ClÃ©ment is currently >>>> stabilizing >>>> >> > > (!!) is a set of bytecodes that encode unsafe operations like >>>> >> > > at:put: without bounds, type or store checks. For example, the >>>> >> > > normal at:put: is about a hundred instructions, checks for >>>> >> > > smallinteger indices, differentiates between byte, 32-but long >>>> and >>>> >> > > pointer objects and does a store check. But one of the Sista >>>> codes >>>> >> > > for at:put: generates about two instructions, one to adjust the >>>> >> > > index, the other to do the store. Distaste job is to analyze >>>> code >>>> >> > > and inline methods using these unsafe bytecodes where they are >>>> >> > > proven to be safe, hence increasing performance. >>>> >> > > >>>> >> > > Unlike AsmJIT, Sista's unsafe bytecodes are cross platform, and, >>>> >> > > being executed by the VM, can work on an interpreter VM or be >>>> >> > > converted to machine code by the JIT. >>>> >> > > >>>> >> > > So our plan is to extend these bytecodes with ones that support >>>> >> > > marshaling arguments for NativeBoost calls. Ronie Salgado has >>>> >> > > already extended his lowcode scheme to define these instructions >>>> >> > > and sometime soon (hopefully 2016) we shall rewrite NativeBoost >>>> to >>>> >> > > target these bytecodes. >>>> >> > > >>>> >> > > HTH >>>> >> > > >>>> >> > > > (ii)Where can I find latest AsmJit? I'm properly confused: >>>> >> > > > >>>> >> > > > * Is is the one in latest Pharo 4.0 (5.0) image? >>>> >> > > > * Is it the one here: >>>> http://smalltalkhub.com/#!/~Pharo/AsmJi >>>> >> > > t ? >>>> >> > > > (the one in the image seem to be based on completely >>>> >> > > disjunct >>>> >> > > > set of .mcz than those in the repo above). >>>> >> > > > >>>> >> > > > Best, Jan >>>> >> > > >>>> >> > > _,,,^..^,,,_ (phone) >>>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >> > _,,,^..^,,,_ > flummoxed, Eliot >

Dec. 16, 2015

Re: [Pharo-dev] Fuel materialization on spur

by phil＠highoctane.be

Can you make a more detailed vision (with a picture) about this? As I have a cluster running and am paid to do some stuff with all you list, I can use some time exploring those avenues. Phil On Wed, Dec 16, 2015 at 7:07 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > Excuse me: > > With interfaces I think groovy. > With object serialization I think avro. > With header encoding I think ASN1DER with dynamic extension, we need > variable encoding of statistical objects. > With packages I think gradle. > > this would be powerful, > robert > > On 12/16/2015 01:00 PM, Robert Withers wrote: > >> I'd like to add that this is a real challenge to existing players in >> BigData, all of who offer solutions in this exact space. Whoever >> controls it's specification, controls it's cloud market. >> >> My back of the envelope proposal (my apologies for my abrasiveness with >> this approach) is such: >> >> We develop a dynamic cloud meta & control solution: replicated, >> eventually consistent and so on. We define the serialization, interfaces >> and package identification to this meta as open-source standards. >> >> With interfaces I think Avro. >> >> With serialization I think ASN1DER encoding, plus non-fixed dynamic >> structure extension. >> >> With package identification I think Gradle. Do we have a groovy compiler? >> >> I thought I would round out my thinking as I believe this to be an >> important opportunity. Given that the new internet is going to be >> governed by always running, maximally interactive execution sites, it >> will naturally move to Smalltalk, so I do not think there is anything >> for anyone to be concerned about. >> >> Patience and not reacting emotionally to misinformation in the >> marketplace will show true colors. Business is warfare. We have the >> advantage. >> >> peace, >> robert >> >> >> On 12/16/2015 12:38 PM, Robert Withers wrote: >> >>> Allow me to speak a little on my ideas of a distributed meta layer and >>> control layer in cloud deployments with Squeak/Pharo, hopefully in >>> bounds. >>> >>> A distributed system must have an metadata repsoitory describing the >>> traffic and activity. If you look at deployment, code that works with >>> a type and version of data must be present. With packaging and dynamic >>> loading, chunks of code registered to a data type/version in the meta >>> demand loads a achunk to do directed work in a particular deployed >>> image. BigData event flows and data analysis like to get replicated >>> and relocated, in realtime. Supporting this in the meta definitional >>> layer and the 1/2 control layer starts to do dynamic, late-binding in >>> the network. This is the advantage Squeak/Pharo image-based >>> environments bring to the business table. >>> >>> Thank you and apologies, >>> robert >>> >>> On 12/16/2015 09:57 AM, H. Hirzel wrote: >>> >>>> Is there a Pharo implementation? https://avro.apache.org/docs/1.2.0/ >>>> >>>> On 12/16/15, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>>> >>>>> Please consider Avro. >>>>> >>>>> robert >>>>> >>>>> On 12/16/2015 08:58 AM, H. Hirzel wrote: >>>>> >>>>>> If you want to move data to Java then you probably go for JSON or a >>>>>> particuar XML format. >>>>>> >>>>>> On 12/16/15, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>>>> >>>>>>> No, it is a Smalltalk format. >>>>>>> >>>>>>> On 12/16/15, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>>>>>> >>>>>>>> 2015-12-16 14:41 GMT+01:00 H. Hirzel <hannes.hirzel(a)gmail.com>: >>>>>>>> >>>>>>>> It probably should be noted here as well that >>>>>>>>> >>>>>>>>> http://pharo.gemtalksystems.com/book/PharoTools/SIXX/ >>>>>>>>> >>>>>>>>> Just to know does java implementation exists? >>>>>>>> >>>>>>>> -- >>>>> . .. .. ^,^ best, robert >>>>> >>>>> >>>>> >>> >> > -- > . .. .. ^,^ best, robert > >

Dec. 16, 2015

Re: [Pharo-dev] Bugs I found during the lectures in Yaounde

by Nicolai Hess

2015-12-16 22:04 GMT+01:00 stepharo <stepharo(a)free.fr>: > Hi > > today and yesterday I'm giving 6 hours of pharo lecture to 100 students > and we have fun. > Here are the bugs I found (I'm working on the latest 50) > > - we cannot bring menu in certain part of the debugger (may inspector) > 16887 <https://pharo.fogbugz.com/f/cases/16887/Debugger-context-menu-broken> Debugger context menu broken > - class definitions are not logged in changes > this should be fixed already 17219 <https://pharo.fogbugz.com/f/cases/17219/Class-Definitions-not-in-Changes-ag…> Class Definitions not in Changes... again again > - when we write self shoulnt: [Dice new faces: 20 ] raise: Error > the debugger does not show the create menu for the method faces: > did this ever worked if the error is catched? > > It would be good to record this. > I have a reeeeeeallllly slow internet connection and only from time to > time. > > > Stef > > > > > >

Dec. 16, 2015

Re: [Pharo-dev] Are Critical Tools Becoming Too Brittle?

by Eliot Miranda

On Wed, Dec 16, 2015 at 2:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Yes, but they were not in the image and as the Spur image was coming > anyway I thought I just wait for it :) > +1 then :) > > Doru > > > > On Dec 16, 2015, at 10:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > > > On Wed, Dec 16, 2015 at 12:03 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > I am waiting for the Spur image because it should already have the > primitives and I will get back to the ProtoObject issue. Could you open an > issue in the meantime? > > > > The mirror primitives should be in the old VM as well. > > > > > > Cheers, > > Doru > > > > > > > On Dec 16, 2015, at 6:31 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > > > > > > Doru, > > > > > > Did you fix the issue involving instances of subclasses of ProtoObject? > > > > > > Esteban A. Maringolo > > > > > > > > > 2015-12-16 2:46 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > > >> Hi, > > >> > > >> Indeed, please help us isolate that case. > > >> > > >> Cheers, > > >> Doru > > >> > > >> > > >>> On Dec 15, 2015, at 11:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > >>> > > >>> I assume you are using the GT inspector. Do you have custom gt > inspector presentations ? Are you sure your #printString is OK ? > > >>> > > >>> There is also a 'Basic Inspect It' menu item ... > > >>> > > >>> Can you isolate it so that we can see it, try it ? > > >>> > > >>>> On 15 Dec 2015, at 23:21, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > >>>> > > >>>> I just tried to inspect a domain object and I froze my image and > had to force > > >>>> quit. How do I debug this? And, more importantly, when an error is > > >>>> encountered in a critical, basic tool like this, should there be > some > > >>>> reasonable bare-bones alternative, like the emergency debugger? Not > being > > >>>> able to inspect an object without crashing seems like a pretty > crippling > > >>>> situation... > > >>>> > > >>>> > > >>>> > > >>>> ----- > > >>>> Cheers, > > >>>> Sean > > >>>> -- > > >>>> View this message in context: > http://forum.world.st/Are-Critical-Tools-Becoming-Too-Brittle-tp4867206.html > > >>>> Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > >>>> > > >>> > > >>> > > >> > > >> -- > > >> www.tudorgirba.com > > >> www.feenk.com > > >> > > >> "From an abstract enough point of view, any two things are similar." > > >> > > >> > > >> > > >> > > >> > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Every thing should have the right to be different." > > > > > > > > > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > -- > www.tudorgirba.com > www.feenk.com > > "Don't give to get. Just give." > > > > > > > > -- _,,,^..^,,,_ best, Eliot

Dec. 16, 2015