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

[Christophe Demarey]

> Le 7 oct. 2017 à 14:26, Ben Coman  a écrit :
> 
> On Sat, Oct 7, 2017 at 3:38 PM, Nicolai Hess  > 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?

« Program » folder is the default location where to install apps on Windows.
If a user does not have admin rights, he can simply install it under its home 
directory.

> Also there is the UAC Virtualization fiasco that complicates installing 
> upgrades.
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-January/091645.html
>  
> 
> 
> Could we *please* install Windows PharoLauncher into user folders?

Users can choose to install Pharo Launcher where they wish.
We could choose another default location but not sure it is best option.

To me, the real problem is: why does Pharo apps (and Pharo Launcher) needs to 
write data in the application directory? By example, for Pharo Launcher, we do 
not need to load any code nor to backup sessions.

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

[Christophe Demarey]

Hi Peter,

> Le 6 oct. 2017 à 21:13, Peter Uhnák  a écrit :
> 
> +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?

We decide to consider Pharo Launcher files (virtual machines, images) as user 
documents. That’s why we changed the location of these files on all platforms.
$XDG_DATA_HOME/Pharo is not a document location on linux and there is no 
standard Documents location. That’s why we ended to put Pharo Launcher files in 
a Pharo folder in the HOME directory.
Maybe it is not the best choice. 

If we can find an agreement on the best Pharo Launcher documents location on 
Linux, it can be changed.

You can already configure where you want to store Pharo Launcher images and vms 
(2 different settings).

Christophe

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

[Esteban Lorenzano]

> On 9 Oct 2017, at 10:10, Christophe Demarey  
> wrote:
> 
> Hi Peter,
> 
>> Le 6 oct. 2017 à 21:13, Peter Uhnák > > a écrit :
>> 
>> +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?

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.


> 
> We decide to consider Pharo Launcher files (virtual machines, images) as user 
> documents. That’s why we changed the location of these files on all platforms.
> $XDG_DATA_HOME/Pharo is not a document location on linux and there is no 
> standard Documents location. That’s why we ended to put Pharo Launcher files 
> in a Pharo folder in the HOME directory.

yeah, this.

> Maybe it is not the best choice. 

I like that choice :)

> 
> If we can find an agreement on the best Pharo Launcher documents location on 
> Linux, it can be changed.
> 
> You can already configure where you want to store Pharo Launcher images and 
> vms (2 different settings).

yeah… you can always customise your own working set.

Esteban

> 
> Christophe

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

[Peter Kenny]

Note: This was sent on Sunday at 19.45 but seems to have disappeared on its
way to pharo users. Re-sent just to complete the story.
_
Paul

Good to have found the charset discrepancy - that may have something to do
with it. But I don't think it has to do with the C’è in the body of the
page. I have just parsed another page published today, with the same error,
and again it fails in parsing the  node, so it has not even reached
the body. The  contains a meta which describes the article - a sort of
paraphrase of the article headline - and it fails in the middle of decoding
that. The character at which it fails is again $«, so that is definitely the
cause. Maybe the wrong charset is the explanation of why it messes up that -
but I don't know enough about the different charsets to know. Does
ISO-8859-1 even contain $«?

Peter

Addendum: I have looked a bit further, and the charset problem lies behind
it all. The ISO-8859-1 charset *does* include $«, at decimal 171 or hex AB.
At the point where it fails, the parser is reading the string '«B', which is
hex AB 42 in ISO-8859-1, and the debugger shows that the parser is trying to
decode hex AB 42 as a multibyte UTF8 character. So there are two questions
remaining: (a) why does the parser try to decode it as UTF8? (b) why does
reading the string in before calling the parser get round the problem?




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[Henrik Sperre Johansen]

XML expects a prolog in the document itself defining the encoding, if absent,
the standard specifies utf-8.
So when you use an XML parser to parse an HTML page, it will disregard any
HTTP encodings, interpret the contents as an XML document with missing
prolog, and try to parse as utf8.

When you use ZnUrl getContents however, it respects the HTTP charset header
field, which correctly identifies the contents as 8859-1, and lets you
correctly read it into an internal string.
Subsequently parsing said internal string, the XML parser won't try to do
any conversion, and therefore works.

Cheers,
Henry



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[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

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

[Christophe Demarey]

> Le 6 oct. 2017 à 22:43, Gabriel Cotelli  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



pharo.launcher
Description: Binary data

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

[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

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

[horrido]

Hey, guys, I'm mentioned in this  O'Reilly newsletter

 
!!! 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

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

[Peter Kenny]

Correction - I am misrepresenting Sven. What he said was that Zinc would not
look inside the HTML  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

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

[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

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

[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

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

[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  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
>
>

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

[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 
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  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. The