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

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

by Dimitris Chloupis

I donât care about Python vs Pharo debate. I love both I use both. My ultimate goal is to unite the two under a single Uber powerful live coding environment part of my project Atlas. With direct mapping between Pharo and Python objects and no compromises. A workflow that will be seamless that you wonât know if you use Python or Pharo libraries as the Atlas environment will allow you to work with both languages in a symbiotic relationship. That was a dream of mine that I did not dear to reveal now slowly and steadily becomes reality. I am extending the live coding environment of python and later will tackle the subject of a python image format. Already Atlas can use python libraries from Pharo but thatâs about it , but after this revelation I can move to stage 2 of full synchronization between Python and Pharo. Even now Atlas allows you to use Pharo syntax to fully access Python libraries. But integration is skin deep and is what is going to improve the next years. So it seems something good came out of this very long discussion. Atlas is going for a big update. This thread has been a huge inspiration for me. Super excited :) On Sat, 14 Oct 2017 at 03:40, Andrew Glynn <aglynn42(a)gmail.com> wrote: > The first language I played with, I was nearly 5, was a live environment, > Forth. I used it on an old PDP my mother had bought that was being > surplused at the company she worked at. I used Forth until I was in my > early teens, it was far superior to the BASIC that most other kids I knew > who knew any programming used. It wasn't Smalltalk, but in many of the > areas it was used (production automation is one major area), the language > that most often replaced it *was* Smalltalk. > > The biggest difference, for me, as I wrote in the article the other day, > is the ability to build-on rather than build-with, which in turn is based > on the environment being written in itself. Ruby *looks* very much like > Smalltalk, but it *works* like Java; Python works *more* like Smalltalk, > and it's a much better live environment than Java or Ruby, because more of > it is written in itself, but too much of Python is written in C, and that > causes problems. If the code that interprets/compiles your code follows the > same rules, the machine code it generates will usually also follow the same > rules, and those rules/restrictions are, for the most part, designed to > make code more reliable. > > As well, RVM has proven Smalltalk (specifically Squeak / Pharo, though > admittedly an older version) can scale to 1024 cores nearly linearly. > > Python has a decent developer base but it's almost all OSS and almost all > on Linux. Very few applications in Python are in areas where reliability is > absolutely necessary, or even all that important. Like Smalltalk, it's a > general purpose language in a niche, but the niches are very different. For > years, decades really, any good version of Smalltalk cost an arm and a leg > (some of them both of each), and as a result it tended to be used only > where things really *had* to work. > > Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak was/is > good, but the LaF was never professional enough for it to be taken as > seriously as it deserves, it just looks too much like a toy although in > reality it's very powerful). Having the capability to build-on a reliable, > attractive and enjoyable base without signing over my great-grand-child's > first born is fantastic, and a great achievement for those who accomplished > it. > > Kendrick is an example of what can be done if you build-*on*: it was > built on Moose, which is built on Glamorous, which is built on Morphic, > which itself is based on a couple of decades work olving the basic problems > inherent to UI's and MVC-type UI's in particular. Kendrick itself was > written in a very short time when you compare it with other epidemiology > programs, *if* you only count the time spent on Kendrick itself. It's an > inherently complex problem area, and it's a life or death problem area. > That an application capable of working reliably enough to be trusted in > that area was built in a short time, because it was built-on a couple of > decades of OSS work, is a huge compliment to those who were involved. > > Unfortunately for me, I wasn't, âº. But at least I can take advantage of it > existence now. > > Andrew > > > > > > > > > > -----Original Message----- > > *Date*: Fri, 06 Oct 2017 21:18:28 +0000 > *Subject*: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk > *To*: 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*: Dimitris Chloupis <kilon.alios(a)gmail.com > <Dimitris%20Chloupis%20%3ckilon.alios(a)gmail.com%3e>> > 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. 14, 2017

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

by Andrew Glynn

The first language I played with, I was nearly 5, was a live environment, Forth.Â Â I used it on an old PDP my mother had bought that was being surplused at the company she worked at.Â Â I used Forth until I was in my early teens, it was far superior to the BASIC that most other kids I knew who knew any programming used.Â Â It wasn't Smalltalk, but in many of the areas it was used (production automation is one major area), the language that most often replaced it was Smalltalk.Â Â The biggest difference, for me, as I wrote in the article the other day, is the ability to build-on rather than build-with, which in turn is based on the environment being written in itself. Ruby looks very much like Smalltalk, but it works like Java; Python works more like Smalltalk, and it's a much better live environment than Java or Ruby, because more of it is written in itself, but too much of Python is written in C, and that causes problems. If the code that interprets/compiles your code follows the same rules, the machine code it generates will usually also follow the same rules, and those rules/restrictions are, for the most part, designed to make code more reliable.Â As well, RVM has proven Smalltalk (specifically Squeak / Pharo, though admittedly an older version) can scale to 1024 cores nearly linearly.Â Â Python has a decent developer base but it's almost all OSS and almost all on Linux. Very few applications in Python are in areas where reliability is absolutely necessary, or even all that important. Â Like Smalltalk, it's a general purpose language in a niche, but the niches are very different. For years, decades really, any good version of Smalltalk cost an arm and a leg (some of them both of each), and as a result it tended to be used only where things really had to work. Â Pharo is a great OSS Smalltalk, IMHO by the best to date (Squeak was/is good, but the LaF was never professional enough for it to be taken as seriously as it deserves, it just looks too much like a toy although in reality it's very powerful). Having the capability to build-on a reliable, attractive and enjoyable base without signing over my great- grand-child's first born is fantastic, and a great achievement for those who accomplished it. Kendrick is an example of what can be done if you build-on:Â Â it was built on Moose, which is built on Glamorous, which is built on Morphic, which itself is based on a couple of decades work olving the basic problems inherent to UI's and MVC-type UI's in particular.Â Â Kendrick itself was written in a very short time when you compare it with other epidemiology programs, if you only count the time spent on Kendrick itself.Â Â It's an inherently complex problem area, and it's a life or death problem area. That an application capable of working reliably enough to be trusted in that area was built in a short time, because it was built-on a couple of decades of OSS work, is a huge compliment to those who were involved.Â Â Unfortunately for me, I wasn't, âº.Â Â But at least I can take advantage of it existence now. Andrew -----Original Message----- Date: Fri, 06 Oct 2017 21:18:28 +0000Subject: Re: [Pharo-users] Behold Pharo: The Modern SmalltalkTo: Any question about pharo is welcome <pha ro-users(a)lists.pharo.org>Reply-to: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>From: Dimitris Chloupis <kilon.alios@gmail .com>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- > 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. 14, 2017

Bloc Example Errors & question

by Ricardo Pacheco

I was reviewing the Bloc examples because I'm looking for a way to connect several blocks like this: <http://forum.world.st/file/t370703/muestra.png> . The idea is that if I move the block, the link with other blocks is kept. I could not find any similar example. Any hint would be appreciated. Also, while reviewing the examples in the latest Pharo 6, some crashed and a couple even let Pharo unresponsive: BlBasicExamples >> example3D (crash) BlBasicExamples >> exampleWithImage BlBenchmark >> example_821nestedEl_in1000x1000_mouseMove50ms (crash) BlMobilePhone >> open Thanks Ricardo -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 13, 2017

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

by Nicolai Hess

2017-10-13 22:04 GMT+02:00 Andrew Glynn <aglynn42(a)gmail.com>: > I understand why it occurs, both the private and the final keyword > affect the reference rather than the object. However, to quote someone > else "That the value of a private field can be changed without a public > setter implies that encapsulation is weak at best, and shouldn't be > counted on to protect key values, even in combination with the final > keyword." Even that comment, though, brings in the notion of a 'value' > that's not an object. > and who did you quote ? > > My point initially was not about the code, but about the Java API doc > that also claims attempting to change the *value* will result in a compile > error. Although keywords affect references, the documentation states > that it affects 'the value', which is at best ambiguous. > I can not see what is wrong here. You are problably confused by - the value of a *variable* - and the value an *object* represents (its object state) the first can not be changed for a final variables the last can only be preserved, if the object is immutable. > There are also numerous issues around type erasure > ... this seems a bit off topic > I'd rather have *no* API documentation than documentation of the sort > represented by the Java API doc. > I think a java api doc like documentation would help. For newcomers, that not yet know ( or know how to find) the in-image help. And even so we can easily browse our code with comments and class comments, an API-doc could provide the help from a different view (group by collaboration rather then by class hierarchy or packages), give an "overall" view or provide additional code examples. > Not that I think it's all > intentional, though perhaps the primitives and scalars that are in fact > objects > How are java primitives "in fact" objects ? They are "in fact" primitives. This is different from smalltakl where some *objects* like Smallinteger are implemented as primitives (or immediates) but still objects on the (smalltalk) code level. > and collections may have been to muffle wailing from C/C++ > programmers that the lack of primitives and scalars would kill > performance. I suspect it's more often a result of unsuccessfully > mode-switching, though, between the rules of the language you're > implementing and those of the language you're implementing *in*, but that > only makes the case for languages implemented in themselves stronger. > > Andrew > > > -----Original Message----- > > Date: Fri, 13 Oct 2017 18:39:59 +0200 > Subject: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk > 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: Nicolai Hess <nicolaihess(a)gmail.com> > > > Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" <aglynn42(a)gmail.com>: > I can't remember ever using API docs in any language, dynamic or not. > They give you the method signatures, but if you have, say, methodX(int, > int, String), how are you supposed to guess what ints and what String > the method actually needs, > > > Isn't this exactly what an apidoc is for? Additional documentation to > describe the methods and arguments purpose. > > Maybe you have just seen poorly documented libraries? > > > One of my favourite language fails can be reproduced by doing this: > > Declare a field private final in Java, initializing it either in the > declaration or the constructor, and provide only a getter. Use the getter > from another class and change the value of the local variable. Then use the > getter again, but assign the value to a new local variable, and check the > value. > > > > Maybe you should re-read about javas final keyword. > It is not to meant making something immutable , > you can just not reassign a new value. > > Java final != c++ const > > > >

Oct. 13, 2017

Re: [Pharo-users] FYI about Pharo MOOC

by Dimitris Chloupis

I have to confess I am a fan of the french accent english too , it has a nice musicality in it +1 for subtitles. I love accents, the more the better :D On Fri, Oct 13, 2017 at 9:28 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > In fact the files have two tracks. > > > On Fri, Oct 13, 2017 at 8:13 PM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > >> Oh good, glad the French version is still there. I was starting to go >> through it a couple of weeks ago and plan to continue starting this >> weekend. Although my mother tongue is English, at one point I was >> fluently bilingual (both Quebecois and actual French), and it's a >> chance to get some of it back while picking up information I've likely >> missed >> on less obvious features. >> >> I can understand French well enough, but the more I hear it spoken >> the better. Reading/writing don't get rusty as easily. >> >> Of course speaking it would be even better, but I don't get many >> chances to do so in Toronto âº. >> >> Andrew >> >> -----Original Message----- >> >> Date: Fri, 13 Oct 2017 18:06:17 +0200 >> Subject: Re: [Pharo-users] FYI about Pharo MOOC >> 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: Stephane Ducasse <stepharo.self(a)gmail.com> >> The production company told us that it was super strange without our >> voices. >> Now you can also have the french + subtitles. >> >> On Fri, Oct 13, >> 2017 at 2:42 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> I played C019SD- >> W1-S1-EN-V1.mp4 >> and as well as the english voice, in the >> background I >> can still hear your >> original french voice. >> I'm curious the >> rea >> soning for >> this. >> >> cheers -ben >> >> >> On Fri, Oct 13, 2017 at 3:59 AM, Stephane Ducasse <step >> haro.self(a)gmail.com> >> wrote: >> >> I'm about to release the en versions. >> you can >> find them unofficially on http://www.stephaneducasse.eu/MOOC/ >> >> Stef >> >> On >> Tue, Oct 10, 2017 at 10:10 PM, Gour <gour(a)atmarama.com> wrote: >> >> On Tue, >> 10 Oct 2017 21:31:55 +0200 >> Stephane Ducasse >> <stepharo.self(a)gmail.com> >> wrote: >> >> Hello Stef, >> >> I will ask one guy thursday and let you know. >> >> >> Thanks a >> lot! >> >> We will release Mooc with english voices (not mine else english >> nati >> ves would get an heart attack - I have what they call a sexy >> french >> accents ;) >> >> >> I did watch few of your Pharo-related presentations and, >> although not >> native, >> happily survived. :-) >> >> Moreover, I'd say that your >> English is charming! At least, one is sure >> that the >> real human is >> speaking and not some "robot" put on auto-pilot, so if the >> new >> Mooc is >> going to be the same as the current/old one, I'd prefer to >> download >> the >> current files and watched them along with *.srt subtitles? >> >> Iow. my point >> is that the accent is just one part of the talk/teaching, >> but the >> energy >> behind it is much more imporant - this is, my conviction, based >> on my >> own >> teaching experiences. >> >> >> Sincerely, >> Gour >> >> -- >> From anger, complete delusion >> arises, and from delusion >> bewilderment of memory. When memory is >> bewildered, >> intelligence is lost, and when intelligence is lost >> one falls >> down again into the material pool. >> >> >> >> >> >> >> >

Oct. 13, 2017

Re: [Pharo-users] Is possible to keep some code closed in Pharo?

by Dimitris Chloupis

If you make a morph maximise and pin it down, it will cover the entire pharo windows and wont be movable and will make it impossible for the user to interact with the IDE even via shorcuts. If I am wrong on shortcuts I hope someone correct me but last time I checked that was the case. Command line wise, command line api is very elegant, very simple to add and remove arguments. Those will block the user from controlling Pharo. Soruce code visibility: 1) What stef said, delte sources 2) If you use monticello the traditional way ,it saves in mcz files which are jus zip files with source code files inside. Created every time you save to a local or remote repo 3) Delete any fileouts, those produce st files too, smalltalk source code files 4) if you use filetree that uses source files too but generally you would pick a directory outside pharo 5) changes files also contain source code you modified or added 6) We hava new recovery tool, I forget the name, has its own file format I dont rememebr if it uses text files like changes, it might, check that out too. Generally anywhere you spot a file with st extension its a source code file, delete it or move it away. We may use an image format but we generate a ton of source code files for various reason as you can see. On Fri, Oct 13, 2017 at 8:27 PM Ricardo Pacheco < ricardo.pacheco.roldan(a)gmail.com> wrote: > Wow, that sounds great. Thanks a lot!! > > Ricardo > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 13, 2017

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

by Dimitris Chloupis

Well oh Well, Python is stupid.... Very, very stupid To my suprise live coding in Python its actually easier to what I expected and almost the same, from user perspective to that of pharo.Minus the IDE conveiniece of course. But a pain in the hat to find the proper way to do it. I was reloading modules, was thining of implementing become to python , which basically means replacing references to old instance object with references to new objects , then I thought that it would be more efficient to just reference the new methods to the instances and after a TON of testing I realized this is dead simple and for some reason python hides it very well. All the above were completely unecessary. Insance methods are referencing functions in the class object. Apparently functions in a class are taken as class methods and functions with self as first argument are considered instance methods. Which means I just copy paste the code of the method to the debugger, and assign it back to the existing live class and all instances are updated automagically. No need for become, no need to update instances manually no need to even reload the module. Similarly you can delete methods and add methods on the fly always live. Renaming a method is basically deleting and assigning . Renaming the class is the same. As is for class and instance variables. So anything can change on the fly. Names are there for your pleasure, in the end all that matters are the references.Its objects all the way down. The equivelant of a python instance method defiition and live updae , the python way, on Pharo would be MyClass instanceMethodName:= myMessage firstArg:self arg2: foo1 arg3: foo2.... |locals| code stuff and you python "call it" or message it MyClass insanceMethodName arg2:foo1 arg3: foo2 , no need to use self when calling it. Self is automatically passed because from the definition python knows this is suppose to be an insance method. or you could put a block after the assigment , because the name of the message is assigned by the assignment anyway, for class method you ommit the first argument of self. Calling is the same. This replaces a method or adds it if does not exist. All instances of that live class are immediately poitining to the new method. So the class is basically a collection of references. So all I have to do now is to wrap the copy paste and assignment in a single shortcut or button and I am ready to fly to live coding land. Days wasted chasing my tail but at least I learned a lot about python objects which are basically dictionaries objects (for variables) plus function objects (for class and instance methods) wrap inside an object, or rather referenced, called a class. Storing the live state , similar to fuel, is supported by the pickle library. Why on earth python made it so hard something so simple to understand ? no idea .I dont even need to make a live coding enviroment library as I assumed, its already there, hiding under the cover too scared to come out. Now I know why none or almost none does live coding in Python.

Oct. 13, 2017

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

by Andrew Glynn

I understand why it occurs, both the private and the final keyword affect the reference rather than the object. However, to quote someone else "That the value of a private field can be changed without a public setter implies that encapsulation is weak at best, and shouldn't be counted on to protect key values, even in combination with the final keyword."Â Â Even that comment, though, brings in the notion of a 'value' that's not an object. My point initially was not about the code, but about the Java API doc that also claims attempting to change the value will result in a compile error. Although keywords affect references, the documentation states that it affects 'the value', which is at best ambiguous. There's inevitably a conflation of passing by value and passing by reference in Java by former C/C++ programmers, since it looks like PBV to a C/C++ programmer while always in fact being PBR.Â Â When copying syntax inverting the meaning of the syntax is counterproductive.Â There are also numerous issues around type erasure (mainly that it works for collections, even simple collections such as vectors, but not for arrays) and the resulting need for Java to allow invalid type casts in certain cases even though they can result in uncaught runtime exceptions. Since the fact that they are invalid is explicit in the API doc, that they are allowed because there's no other way to do it is problematic. Using lambdas or the streaming API within Java EE is another undocumented problem, or set of problems ( it was good fortune for me personally - when some software using the streaming API in an EE container consistently failed and the developer had no idea why, the company gave me the project I implemented it in Pharo, âº ). Â Oracle did at one point have a note on the Java EE 7 download page to the effect that Java EE 7 shouldn't be used with Java SE 8, but that was 'disappeared' when Java SE 7 was no longer supported and Java EE 7 was still the latest version.Â Â Since Java EE 8 is not even on the horizon, while SE 9 is due 'any minute now', I have to wonder if EE is simply dead.Â Â The requests from IBM, SAP and others to take over EE imply they at least suspect the same. I'd rather have no API documentation than documentation of the sort represented by the Java API doc.Â Â Not that I think it's all intentional, though perhaps the primitives and scalars that are in fact objects and collections may have been to muffle wailingÂ from C/C++ programmers that the lack of primitives and scalars would kill performance.Â Â I suspect it's more often a result of unsuccessfully mode-switching, though, between the rules of the language you're implementing and those of the language you're implementing in, but that only makes the case for languages implemented in themselves stronger. Andrew -----Original Message----- Date: Fri, 13 Oct 2017 18:39:59 +0200 Subject: Re: [Pharo-users] Behold Pharo: The Modern Smalltalk 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: Nicolai Hess <nicolaihess(a)gmail.com> Am 13.10.2017 5:50 PM schrieb "Andrew Glynn" <aglynn42(a)gmail.com>: I can't remember ever using API docs in any language, dynamic or not.Â They give you the method signatures, but if you have, say, methodX(int, int, String), how are you supposed to guess what ints and what String the method actually needs, Isn't this exactly what an apidoc is for? Additional documentation to describe the methods andÂ Â arguments purpose.Â Maybe you have just seen poorly documented libraries? One of my favourite language fails can be reproduced by doing this:Â Declare a field private final in Java, initializing it either in the declaration or the constructor, and provide only a getter. Use the getter from another class and change the value of the local variable. Then use the getter again, but assign the value to a new local variable, and check the value. Â Maybe you should re-read about javasÂ final keyword. It is not to meant making something immutable , you can just not reassign a new value. Java final != c++ const

Oct. 13, 2017

Re: [Pharo-users] Zinc release?

by Sven Van Caekenberghe

Herby, > On 13 Oct 2017, at 14:37, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Sven Van Caekenberghe wrote: >> >>> On 12 Oct 2017, at 15:58, Herby VojÄÃk<herby(a)mailbox.sk> wrote: >>> >>> There are a few fixes out there for Zinc, not to mention convenience like ZnEntity class>> json:. Don't you consider releasing the new version (as I tried to update it by hand, it is not that easy, it has more components, to load HTTP I had to update Character-Encoding as well, so probably better if bumped as a group)? >>> >>> Herby >> >> That's what configurations are for, to track the latest development release in a consistent way. You just do >> >> ConfigurationOfZincHTTPComponents project bleedingEdge load. >> >> Provided you loaded a recent configuration. > > I'm nort sure I want the bleeding edge loaded, albeit for recent configuration, for the production code (thought not mission criticial about lives or millions of $$$). Also I don't know if configurations are updated after each change out there (it must be done by hand I presume). So I was asking if there isn't a time to release another stable one. > > If not, and I still want not the true bleeding edge, but a "it works for me" snapshot in time, to load specific version of ConfigurationOf... and the issue ... project bleedingEdge load? Will it load only those version that were bleedingEdge at that time? > >> See the class comment of ConfigurationOfZincHTTPComponents for more info. >> >> Sven There are only two branches/versions: the latest development branch (bleedingEdge, 'head', just all the latest versions of all packages) and specific released versions (that get an id that you can refer to). Doing a release is a manual process that comes down to fixing the bleedingEdge at a moment when I feel it is stable enough. There are no versions in between releases that you can refer to. AFAIK this is how most Pharo projects work, it is how I work in all my projects. Sven

Oct. 13, 2017

Re: [Pharo-users] FYI about Pharo MOOC

by Stephane Ducasse

In fact the files have two tracks. On Fri, Oct 13, 2017 at 8:13 PM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Oh good, glad the French version is still there. I was starting to go > through it a couple of weeks ago and plan to continue starting this > weekend. Although my mother tongue is English, at one point I was > fluently bilingual (both Quebecois and actual French), and it's a > chance to get some of it back while picking up information I've likely > missed > on less obvious features. > > I can understand French well enough, but the more I hear it spoken > the better. Reading/writing don't get rusty as easily. > > Of course speaking it would be even better, but I don't get many > chances to do so in Toronto âº. > > Andrew > > -----Original Message----- > > Date: Fri, 13 Oct 2017 18:06:17 +0200 > Subject: Re: [Pharo-users] FYI about Pharo MOOC > 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: Stephane Ducasse <stepharo.self(a)gmail.com> > The production company told us that it was super strange without our > voices. > Now you can also have the french + subtitles. > > On Fri, Oct 13, > 2017 at 2:42 PM, Ben Coman <btc(a)openinworld.com> wrote: > > I played C019SD- > W1-S1-EN-V1.mp4 > and as well as the english voice, in the > background I > can still hear your > original french voice. > I'm curious the > rea > soning for > this. > > cheers -ben > > > On Fri, Oct 13, 2017 at 3:59 AM, Stephane Ducasse <step > haro.self(a)gmail.com> > wrote: > > I'm about to release the en versions. > you can > find them unofficially on http://www.stephaneducasse.eu/MOOC/ > > Stef > > On > Tue, Oct 10, 2017 at 10:10 PM, Gour <gour(a)atmarama.com> wrote: > > On Tue, > 10 Oct 2017 21:31:55 +0200 > Stephane Ducasse > <stepharo.self(a)gmail.com> > wrote: > > Hello Stef, > > I will ask one guy thursday and let you know. > > > Thanks a > lot! > > We will release Mooc with english voices (not mine else english > nati > ves would get an heart attack - I have what they call a sexy > french > accents ;) > > > I did watch few of your Pharo-related presentations and, > although not > native, > happily survived. :-) > > Moreover, I'd say that your > English is charming! At least, one is sure > that the > real human is > speaking and not some "robot" put on auto-pilot, so if the > new > Mooc is > going to be the same as the current/old one, I'd prefer to > download > the > current files and watched them along with *.srt subtitles? > > Iow. my point > is that the accent is just one part of the talk/teaching, > but the > energy > behind it is much more imporant - this is, my conviction, based > on my > own > teaching experiences. > > > Sincerely, > Gour > > -- > From anger, complete delusion > arises, and from delusion > bewilderment of memory. When memory is > bewildered, > intelligence is lost, and when intelligence is lost > one falls > down again into the material pool. > > > > > > >

Oct. 13, 2017