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

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

by webwarrior

Calm your tits, dude. No need to use Caps Lock that much :-) I made no value judgements in my post, letting readers decide for themselves. Nor did I attribute any claims to you. Except "live coding in Python is easy", which you did say in some earlier posts. > My post were not made to pick a fight but rather to inform and demolish > the wrong assumptions that other languages CANNOT DO live coding. Well, many of them kinda can. But you see, when live coding is an afterthought, problems appear here and there, and some of them are unsolvable. Up to the point that it's easier to do traditional development process and not bother with live coding at all. It's almost like saying that you can do point-free style functional programming in Python. Of course you can (to some extent). There is even a library for that (https://pypi.python.org/pypi/pointfree/) I there much sense in it? I don't think so. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 10, 2017

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

by Dimitris Chloupis

And not to worry I wonât bother with discussing such issues again itâs clear the community is unwilling to deal with such discussions. I have no problem with that , itâs a free world. On Tue, 10 Oct 2017 at 03:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I never claimed that Python , which refers to CPython to the vast majority > of python coders, is offering live coding out of the box. The fact that you > have to reload modules manually would make such claims ridiculous. > > From the very first post I was crystal clear that there is a need for > creating a library that handles live coding for you and gave general > instructions of what this library will have to do. > > My claim is that Python and other languages CAN do live coding. > > I NEVER claimed also that Python is a live coding environment which it > stores in an image format. In short Python IS NOT Pharo. Period. > > Can python reload modules ? Yes > Can python trigger the debugger in case of error ? Yes > Can python replace methods and variables during execution ? Yes > Can python recompile individual methods and classes and replace their > previous instances ? Yes > Can python make you coffee ? Nope > Etc etc > > Depending how deep you want to go live coding wise your live coding > library will enlarge. > > From my experience around 100 lines of code are enough to offer most of > Pharoâs basic live coding functionality. Such task that needs to happen > only once and then simply reused in each project that wants to utilize live > coding , for my standards it is easy. It wonât be easy for a beginner > python coder cause he may not even know what OOP is. So obviously I am > referring to experienced coders. It wonât be easy if you want to fully > replicate Pharoâs live coding capabilities , because you will Definetly go > way beyond 100 lines. > > > I stated this before and I will state this again Pharo IS HANDS DOWN THE > BEST LIVE CODING ENVIRONMENT I have ever used. > > My point is that other languages CAN do what Pharo does. Even though they > are NOT live coding environments. They just have the features to be live > coding environments. > > Jython has had a lot of problems using CPython libraries, live coding is > the least of its problems. This is the reason CPython has almost the > monopoly of python coding. > > I just donât like it when other languages are illustrated as garbage and > Pharo as the holy grail. They all have their pros and cons. > > Canât help with Jython , I used it on the premise that I may need Java > libraries, I ended up finding what I wanted in CPython and have not touched > it since. > > My post were not made to pick a fight but rather to inform and demolish > the wrong assumptions that other languages CANNOT DO live coding. > > > If we are to compare them the least we can do is do it in a fair and > sincere way. > On Mon, 9 Oct 2017 at 20:06, webwarrior <reg(a)webwarrior.ws> wrote: > >> kilon.alios wrote >> > 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. >> >> It's funny that one of main reasons why I discovered and started using >> Pharo >> was failure to get live coding working for Python (Jython in particular). >> >> And now time after time kilon.alios states that live coding in Python is >> "easy" and no big deal. >> >> I will tell you, Pharoers, about code reloading in Python, and let you >> decide for yourselves how it compares to Pharo. >> >> >> Out of the box in Python you can execute some Python code and reload >> modules >> with reload() function. >> >> What reload() does is it reads code from file (in Python each source file >> corresponds to module), executes it, and replaces reference to [that >> module] >> in current module. >> From that moment, any code in current module, when referencing reloaded >> module, will point to new version of it. >> >> All implicitly imported names will (like from foo import bar, from foo >> import *, etc.) will point to old version. Also all other modules except >> current will not be affected. >> >> There are, however, third-party libraries, that take care of it. >> >> But that's not all. All instances and subclasses of old classes will point >> to old versions of classes. >> To counter that, instead of replacing old module you could replace its >> contents by newer variables/functions and patch classes by replacing their >> contents. >> Some third-party libraries do that. >> >> That's still not all. If you store references to >> functions/methods/classes, >> that references will point to old versions. >> reimport library takes care of that, but it uses implementation-specific >> feature of CPython's GC, which lets you get all references to some object. >> Unfortunately, it doesn't work in Jython, and probably in other >> alternative >> Python implementations. >> >> But wait, what if you rename a class or function, or change its base >> class(-es)? >> You're out of luck. Theoretically you could handle such change if recent >> code change consists of a single rename, but that's it. >> >> I may have missed some other edge cases and haven't talked about tools >> support, but I hope you get the idea. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >>

Oct. 10, 2017

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

by Dimitris Chloupis

I never claimed that Python , which refers to CPython to the vast majority of python coders, is offering live coding out of the box. The fact that you have to reload modules manually would make such claims ridiculous. >From the very first post I was crystal clear that there is a need for creating a library that handles live coding for you and gave general instructions of what this library will have to do. My claim is that Python and other languages CAN do live coding. I NEVER claimed also that Python is a live coding environment which it stores in an image format. In short Python IS NOT Pharo. Period. Can python reload modules ? Yes Can python trigger the debugger in case of error ? Yes Can python replace methods and variables during execution ? Yes Can python recompile individual methods and classes and replace their previous instances ? Yes Can python make you coffee ? Nope Etc etc Depending how deep you want to go live coding wise your live coding library will enlarge. >From my experience around 100 lines of code are enough to offer most of Pharoâs basic live coding functionality. Such task that needs to happen only once and then simply reused in each project that wants to utilize live coding , for my standards it is easy. It wonât be easy for a beginner python coder cause he may not even know what OOP is. So obviously I am referring to experienced coders. It wonât be easy if you want to fully replicate Pharoâs live coding capabilities , because you will Definetly go way beyond 100 lines. I stated this before and I will state this again Pharo IS HANDS DOWN THE BEST LIVE CODING ENVIRONMENT I have ever used. My point is that other languages CAN do what Pharo does. Even though they are NOT live coding environments. They just have the features to be live coding environments. Jython has had a lot of problems using CPython libraries, live coding is the least of its problems. This is the reason CPython has almost the monopoly of python coding. I just donât like it when other languages are illustrated as garbage and Pharo as the holy grail. They all have their pros and cons. Canât help with Jython , I used it on the premise that I may need Java libraries, I ended up finding what I wanted in CPython and have not touched it since. My post were not made to pick a fight but rather to inform and demolish the wrong assumptions that other languages CANNOT DO live coding. If we are to compare them the least we can do is do it in a fair and sincere way. On Mon, 9 Oct 2017 at 20:06, webwarrior <reg(a)webwarrior.ws> wrote: > kilon.alios wrote > > 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. > > It's funny that one of main reasons why I discovered and started using > Pharo > was failure to get live coding working for Python (Jython in particular). > > And now time after time kilon.alios states that live coding in Python is > "easy" and no big deal. > > I will tell you, Pharoers, about code reloading in Python, and let you > decide for yourselves how it compares to Pharo. > > > Out of the box in Python you can execute some Python code and reload > modules > with reload() function. > > What reload() does is it reads code from file (in Python each source file > corresponds to module), executes it, and replaces reference to [that > module] > in current module. > From that moment, any code in current module, when referencing reloaded > module, will point to new version of it. > > All implicitly imported names will (like from foo import bar, from foo > import *, etc.) will point to old version. Also all other modules except > current will not be affected. > > There are, however, third-party libraries, that take care of it. > > But that's not all. All instances and subclasses of old classes will point > to old versions of classes. > To counter that, instead of replacing old module you could replace its > contents by newer variables/functions and patch classes by replacing their > contents. > Some third-party libraries do that. > > That's still not all. If you store references to functions/methods/classes, > that references will point to old versions. > reimport library takes care of that, but it uses implementation-specific > feature of CPython's GC, which lets you get all references to some object. > Unfortunately, it doesn't work in Jython, and probably in other alternative > Python implementations. > > But wait, what if you rename a class or function, or change its base > class(-es)? > You're out of luck. Theoretically you could handle such change if recent > code change consists of a single rename, but that's it. > > I may have missed some other edge cases and haven't talked about tools > support, but I hope you get the idea. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 10, 2017

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

by webwarrior

kilon.alios wrote > 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. It's funny that one of main reasons why I discovered and started using Pharo was failure to get live coding working for Python (Jython in particular). And now time after time kilon.alios states that live coding in Python is "easy" and no big deal. I will tell you, Pharoers, about code reloading in Python, and let you decide for yourselves how it compares to Pharo. Out of the box in Python you can execute some Python code and reload modules with reload() function. What reload() does is it reads code from file (in Python each source file corresponds to module), executes it, and replaces reference to [that module] in current module. >From that moment, any code in current module, when referencing reloaded module, will point to new version of it. All implicitly imported names will (like from foo import bar, from foo import *, etc.) will point to old version. Also all other modules except current will not be affected. There are, however, third-party libraries, that take care of it. But that's not all. All instances and subclasses of old classes will point to old versions of classes. To counter that, instead of replacing old module you could replace its contents by newer variables/functions and patch classes by replacing their contents. Some third-party libraries do that. That's still not all. If you store references to functions/methods/classes, that references will point to old versions. reimport library takes care of that, but it uses implementation-specific feature of CPython's GC, which lets you get all references to some object. Unfortunately, it doesn't work in Jython, and probably in other alternative Python implementations. But wait, what if you rename a class or function, or change its base class(-es)? You're out of luck. Theoretically you could handle such change if recent code change consists of a single rename, but that's it. I may have missed some other edge cases and haven't talked about tools support, but I hope you get the idea. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 9, 2017

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

by Peter UhnÃ¡k

> > why a step backwards? > Pharo images are not *data* in the sense is intended for XDG_DATA_HOME. > In practice, an image is more like a document Pharo can readâ¦ data files > are configurations, etc. an app needs to work properly in the local > environment. > Pharo images instead, are modifiable/editable/whatever euphemism you wantâ¦ > thatâs why we considered more like VMWare considers their Virtual > Machines, then they belong to some place in the home directory that is of > easy access. > I guess I hate when applications are throwing their garbage into my $HOME (this also goes for VirtualBox, Eclipse, and everyone else). If I am not accessing the files directly, but they are pretty much always managed by some other applications, then for me they are polluting $HOME. (And yes, I sometimes do launch to image by hand, or manipulate VirtualBox by hand, but that doesn't change the fact that it is not the primary way to work with it.) But no worries, I rest my case and I patch it for myself. (So no need to add configuration for this either.) Peter

Oct. 9, 2017

Re: [Pharo-users] Problem with input to XML Parser - 'Invalid UTF8 encoding'

by Peter Kenny

Correction - I am misrepresenting Sven. What he said was that Zinc would not look inside the HTML <head> node to find out about coding. It would of course use information in the HTTP headers, if any. Peter Kenny wrote > Henry > > Thanks for the explanations. It's a bit clearer now. I'm still not sure > about how ZnUrl>>retrieveContents manages to decode correctly in this > case; > I'm sure I recall Sven saying it didn't (and in his view shouldn't) look > at > the HTTP declarations in the header. There is also the mystery of how the > string reader in the XML-Parser package (XMLURI>>get) does the same trick, > when it is presumably what XMLHTMLParser>>parseURL: uses and fails. > > However, all these are second order problems. It all begins because the > Corriere web site does strange things with encoding, including using a > UTF8 > character in a page coded with 8859-1, as Paul pointed out. In any case, > reading the page as a string and then parsing it solves my problem, so I > shall stick to that as a standard procedure. Most importantly, I don't > think > there is any indication of a problem in the XML package for Monty to worry > about. > > Thanks again > > Peter > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 9, 2017

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

by horrido

Hey, guys, I'm mentioned in this O'Reilly newsletter <http://post.oreilly.com/form/oreilly/viewhtml/9z1zgj2l150hp80ah3enjvhjhqcnr…> !!! All because of the Pharo article. I wonder, is my campaign /actually/ succeeding? If so, I can die happy. ;-) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 9, 2017

Re: [Pharo-users] Problem with input to XML Parser - 'Invalid UTF8 encoding'

by Peter Kenny

Henry Thanks for the explanations. It's a bit clearer now. I'm still not sure about how ZnUrl>>retrieveContents manages to decode correctly in this case; I'm sure I recall Sven saying it didn't (and in his view shouldn't) look at the HTTP declarations in the header. There is also the mystery of how the string reader in the XML-Parser package (XMLURI>>get) does the same trick, when it is presumably what XMLHTMLParser>>parseURL: uses and fails. However, all these are second order problems. It all begins because the Corriere web site does strange things with encoding, including using a UTF8 character in a page coded with 8859-1, as Paul pointed out. In any case, reading the page as a string and then parsing it solves my problem, so I shall stick to that as a standard procedure. Most importantly, I don't think there is any indication of a problem in the XML package for Monty to worry about. Thanks again Peter -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 9, 2017

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

by Christophe Demarey

> Le 6 oct. 2017 Ã 22:43, Gabriel Cotelli <g.cotelli(a)gmail.com> a Ã©crit : > > 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. I fear I cannot do much for this problem. I tried on ubuntu and fedora to run but I have no way to run this exe directly. I have no menu Â« Run in terminal Â» . I was only able to create a launcher file (pharo.desktop). Then, by double-clicking on this launcher file, I was able to run the launcher and a pharo 6.1 image without error. Maybe the best would be to use a launcher file (exemple as attachment). Regards, Christophe

Oct. 9, 2017

Re: [Pharo-users] Problem with input to XML Parser - 'Invalid UTF8 encoding'

by Henrik Sperre Johansen

In a class named XMLHTMLParser, you may expect that logic to be expanded a bit beyond the basic XML spec though. But since there are multiple potentially correct definitions, there will always be failure cases. Not to mention, in addition to XML/HTTP, HTML4/5 also define (different) meta tags for specifying encoding (+ have different default encodings), so really, the number of potentially correct encodings is even higher. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 9, 2017