Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Sean P. DeNigris]

Stephane Ducasse-3 wrote
> you are mixing and other concerns

True, they are not the same issue. I guess the connection for me is that
they are both examples of overloading a single mechanism to accomplish at
best orthogonal and often conflicting goals. Right now we're using dumb
strings to define: 1) method visibility (e.g. "private") 2) extension
package 3) categorization. It seems way overdue for a real model. Thus I was
surprised that there seemed to be resistance to change.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Denis Kudriashov]

2018-04-12 20:46 GMT+02:00 Stephane Ducasse :

> Eliot
>
> We do not want to go the road of overrides. We want to keep our
> engineer task forces.
>

We will need support this anyway. It's very similar to loading methods
extending undefined class (you already have prototype, right?).
Imagine that you load project which overrides your package which already
includes many changes. It should be safe to commit package. Overridden
methods should not be removed.
And to support it we will need model for package overrides which will bring
features which Eliot describes.


>
> Stef
>
> On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda 
> wrote:
> > Hi Sean,
> >
> > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris  >
> > wrote:
> >>
> >> Stephane Ducasse-3 wrote
> >> > You see. You pushed this idea and at then end we will have to handle
> the
> >> > mess.
> >> > I do not see why we cannot simply support *.
> >>
> >> I'm surprised by this resistance. The *Xyz was always an ugly hack, part
> >> of
> >> Squeak's overloading the same mechanism for both system categorization
> and
> >> packaging, and exposing and limiting protocols as "just dumb strings",
> all
> >> of which IMHO makes the system much less understandable (no real
> "private"
> >> tagging, extension methods can't show up in proper protocol, etc). We're
> >> not
> >> in a feature freeze, so what is the problem with tackling part of this
> >> mess
> >> now? Sure, maybe the UI support can be improved, but let's focus on some
> >> concrete suggestions.
> >>
> >> Denis and I just happened to be talking about this larger issue the
> other
> >> day. Here are a few snippets I dug up during that conversations of some
> of
> >> my many posts about this over the years…
> >>
> >> > we have overloaded system categories to package code for SCM. System
> >> > categories should be tags (preferably multiple allowed)
> >> > which offer a logical view of the system. Packages, the POV we show
> now,
> >> > are orthogonal and much less useful for users.
> >> (edited)
> >> and another:
> >> > I feel more and more that the standard "Package" pane is only useful
> >> > for... packaging, and when one takes off the dependency management hat
> >> > and
> >> > puts the user hat on (i.e. most of the time), what you really want
> there
> >> > is a logical view of the system. So I see three use cases:
> >> - Logical view of the system - I guess this was the original intention
> of
> >> Categories, but has been hijacked by Monticello
> >> - By project - which, as you just showed, we have now, yay!
> >> - By package - the least useful, but primary (up til now), view
> >> (edited)
> >> and regarding Nautilus' tree package pane (when it first arrived):
> >> I noticed that right now, separate packages within the same project are
> >> not
> >> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they
> will
> >> be siblings in the tree, instead of both under MyProject. It seems like
> it
> >> would be more useful to have
> >> - MyProject
> >>   - Core
> >>   - Platform
> >> in the tree
> >
> >
> > If you and Denis are "going radical" and going to do the right thing then
> > please also give thought to overrides and unloading.  Allowing a package
> to
> > override a set of methods on load is a useful facility, fraught with
> > difficulties (being able to browse the overridden versions being the main
> > one).  Having things organized so that the overridden versions are saved,
> > don't get lost when source is rewritten, etc, etc (made much easier by
> > keeping source in methods), but most importantly, get restored in the
> right
> > order when packages are unloaded.  I believe it's as simple as
> associating
> > the methods that are overridden with the packages to which they belong,
> and
> > maintaining a load order (so that if PkgA B & C implement C>>foo, and are
> > loaded in the order A, B, C, then we can compute easily that unloading C
> > restores PkgB's C>>foo, and that unloading B does not affect C>>foo).
> >
> >>
> >>
> >> > it seems that the tree is primarily about chunking information into
> >> > manageable pieces.
> >>
> >> A primary difficulty here is that packages are often divided for reasons
> >> that have nothing to do with the domain model, e.g. the ubiquitous
> >> MyPackage-Platform, which is an artifact of Metacello that is not all
> that
> >> relevant to a user wanting to understand the system.
> >>
> >> From the naive user perspective, if I'm exploring from the top level of
> >> the
> >> system, I want to see things like:
> >> - CodeImport
> >> - Collections
> >> - Compiler
> >>
> >> From this perspective, the 14 entries for Collections, multiplied by a
> few
> >> dozen top-level categories make the list unwieldy and only marginally
> less
> >> daunting than the flattened list we used to have (see
> >> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_
> Plus_or_Minus_Two )
> >>
> 

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Eliot Miranda]

Hi Stephane,

On Thu, Apr 12, 2018 at 11:46 AM, Stephane Ducasse 
wrote:

> Eliot
>
> We do not want to go the road of overrides. We want to keep our
> engineer task forces.
>

There are overrides anyway.  In general overrides are unavoidable in some
circumstances.  The issue is not whether they exist, it's whether they work
reliably.  Right now they don't; they rely on changes file technology that
is extremely fragile.  Sean and Denis' move to reimplement extensions is an
opportunity to implement overrides correctly.


>
> Stef
>
> On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda 
> wrote:
> > Hi Sean,
> >
> > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris  >
> > wrote:
> >>
> >> Stephane Ducasse-3 wrote
> >> > You see. You pushed this idea and at then end we will have to handle
> the
> >> > mess.
> >> > I do not see why we cannot simply support *.
> >>
> >> I'm surprised by this resistance. The *Xyz was always an ugly hack, part
> >> of
> >> Squeak's overloading the same mechanism for both system categorization
> and
> >> packaging, and exposing and limiting protocols as "just dumb strings",
> all
> >> of which IMHO makes the system much less understandable (no real
> "private"
> >> tagging, extension methods can't show up in proper protocol, etc). We're
> >> not
> >> in a feature freeze, so what is the problem with tackling part of this
> >> mess
> >> now? Sure, maybe the UI support can be improved, but let's focus on some
> >> concrete suggestions.
> >>
> >> Denis and I just happened to be talking about this larger issue the
> other
> >> day. Here are a few snippets I dug up during that conversations of some
> of
> >> my many posts about this over the years…
> >>
> >> > we have overloaded system categories to package code for SCM. System
> >> > categories should be tags (preferably multiple allowed)
> >> > which offer a logical view of the system. Packages, the POV we show
> now,
> >> > are orthogonal and much less useful for users.
> >> (edited)
> >> and another:
> >> > I feel more and more that the standard "Package" pane is only useful
> >> > for... packaging, and when one takes off the dependency management hat
> >> > and
> >> > puts the user hat on (i.e. most of the time), what you really want
> there
> >> > is a logical view of the system. So I see three use cases:
> >> - Logical view of the system - I guess this was the original intention
> of
> >> Categories, but has been hijacked by Monticello
> >> - By project - which, as you just showed, we have now, yay!
> >> - By package - the least useful, but primary (up til now), view
> >> (edited)
> >> and regarding Nautilus' tree package pane (when it first arrived):
> >> I noticed that right now, separate packages within the same project are
> >> not
> >> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they
> will
> >> be siblings in the tree, instead of both under MyProject. It seems like
> it
> >> would be more useful to have
> >> - MyProject
> >>   - Core
> >>   - Platform
> >> in the tree
> >
> >
> > If you and Denis are "going radical" and going to do the right thing then
> > please also give thought to overrides and unloading.  Allowing a package
> to
> > override a set of methods on load is a useful facility, fraught with
> > difficulties (being able to browse the overridden versions being the main
> > one).  Having things organized so that the overridden versions are saved,
> > don't get lost when source is rewritten, etc, etc (made much easier by
> > keeping source in methods), but most importantly, get restored in the
> right
> > order when packages are unloaded.  I believe it's as simple as
> associating
> > the methods that are overridden with the packages to which they belong,
> and
> > maintaining a load order (so that if PkgA B & C implement C>>foo, and are
> > loaded in the order A, B, C, then we can compute easily that unloading C
> > restores PkgB's C>>foo, and that unloading B does not affect C>>foo).
> >
> >>
> >>
> >> > it seems that the tree is primarily about chunking information into
> >> > manageable pieces.
> >>
> >> A primary difficulty here is that packages are often divided for reasons
> >> that have nothing to do with the domain model, e.g. the ubiquitous
> >> MyPackage-Platform, which is an artifact of Metacello that is not all
> that
> >> relevant to a user wanting to understand the system.
> >>
> >> From the naive user perspective, if I'm exploring from the top level of
> >> the
> >> system, I want to see things like:
> >> - CodeImport
> >> - Collections
> >> - Compiler
> >>
> >> From this perspective, the 14 entries for Collections, multiplied by a
> few
> >> dozen top-level categories make the list unwieldy and only marginally
> less
> >> daunting than the flattened list we used to have (see
> >> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_
> Plus_or_Minus_Two )
> >>
> >>
> >>
> >> -
> >> Cheers,
> >> Sean
> 

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Stephane Ducasse]

Eliot

We do not want to go the road of overrides. We want to keep our
engineer task forces.

Stef

On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda  wrote:
> Hi Sean,
>
> On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris 
> wrote:
>>
>> Stephane Ducasse-3 wrote
>> > You see. You pushed this idea and at then end we will have to handle the
>> > mess.
>> > I do not see why we cannot simply support *.
>>
>> I'm surprised by this resistance. The *Xyz was always an ugly hack, part
>> of
>> Squeak's overloading the same mechanism for both system categorization and
>> packaging, and exposing and limiting protocols as "just dumb strings", all
>> of which IMHO makes the system much less understandable (no real "private"
>> tagging, extension methods can't show up in proper protocol, etc). We're
>> not
>> in a feature freeze, so what is the problem with tackling part of this
>> mess
>> now? Sure, maybe the UI support can be improved, but let's focus on some
>> concrete suggestions.
>>
>> Denis and I just happened to be talking about this larger issue the other
>> day. Here are a few snippets I dug up during that conversations of some of
>> my many posts about this over the years…
>>
>> > we have overloaded system categories to package code for SCM. System
>> > categories should be tags (preferably multiple allowed)
>> > which offer a logical view of the system. Packages, the POV we show now,
>> > are orthogonal and much less useful for users.
>> (edited)
>> and another:
>> > I feel more and more that the standard "Package" pane is only useful
>> > for... packaging, and when one takes off the dependency management hat
>> > and
>> > puts the user hat on (i.e. most of the time), what you really want there
>> > is a logical view of the system. So I see three use cases:
>> - Logical view of the system - I guess this was the original intention of
>> Categories, but has been hijacked by Monticello
>> - By project - which, as you just showed, we have now, yay!
>> - By package - the least useful, but primary (up til now), view
>> (edited)
>> and regarding Nautilus' tree package pane (when it first arrived):
>> I noticed that right now, separate packages within the same project are
>> not
>> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
>> be siblings in the tree, instead of both under MyProject. It seems like it
>> would be more useful to have
>> - MyProject
>>   - Core
>>   - Platform
>> in the tree
>
>
> If you and Denis are "going radical" and going to do the right thing then
> please also give thought to overrides and unloading.  Allowing a package to
> override a set of methods on load is a useful facility, fraught with
> difficulties (being able to browse the overridden versions being the main
> one).  Having things organized so that the overridden versions are saved,
> don't get lost when source is rewritten, etc, etc (made much easier by
> keeping source in methods), but most importantly, get restored in the right
> order when packages are unloaded.  I believe it's as simple as associating
> the methods that are overridden with the packages to which they belong, and
> maintaining a load order (so that if PkgA B & C implement C>>foo, and are
> loaded in the order A, B, C, then we can compute easily that unloading C
> restores PkgB's C>>foo, and that unloading B does not affect C>>foo).
>
>>
>>
>> > it seems that the tree is primarily about chunking information into
>> > manageable pieces.
>>
>> A primary difficulty here is that packages are often divided for reasons
>> that have nothing to do with the domain model, e.g. the ubiquitous
>> MyPackage-Platform, which is an artifact of Metacello that is not all that
>> relevant to a user wanting to understand the system.
>>
>> From the naive user perspective, if I'm exploring from the top level of
>> the
>> system, I want to see things like:
>> - CodeImport
>> - Collections
>> - Compiler
>>
>> From this perspective, the 14 entries for Collections, multiplied by a few
>> dozen top-level categories make the list unwieldy and only marginally less
>> daunting than the flattened list we used to have (see
>> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Stephane Ducasse]

Sean

you are mixing and other concerns. The tools could show all the
collections as projects.
Packages are unit of loading. So small modular packages are good.

Stef


On Thu, Apr 12, 2018 at 6:49 PM, Sean P. DeNigris  wrote:
> Stephane Ducasse-3 wrote
>> You see. You pushed this idea and at then end we will have to handle the
>> mess.
>> I do not see why we cannot simply support *.
>
> I'm surprised by this resistance. The *Xyz was always an ugly hack, part of
> Squeak's overloading the same mechanism for both system categorization and
> packaging, and exposing and limiting protocols as "just dumb strings", all
> of which IMHO makes the system much less understandable (no real "private"
> tagging, extension methods can't show up in proper protocol, etc). We're not
> in a feature freeze, so what is the problem with tackling part of this mess
> now? Sure, maybe the UI support can be improved, but let's focus on some
> concrete suggestions.
>
> Denis and I just happened to be talking about this larger issue the other
> day. Here are a few snippets I dug up during that conversations of some of
> my many posts about this over the years…
>
>> we have overloaded system categories to package code for SCM. System
>> categories should be tags (preferably multiple allowed)
>> which offer a logical view of the system. Packages, the POV we show now,
>> are orthogonal and much less useful for users.
> (edited)
> and another:
>> I feel more and more that the standard "Package" pane is only useful
>> for... packaging, and when one takes off the dependency management hat and
>> puts the user hat on (i.e. most of the time), what you really want there
>> is a logical view of the system. So I see three use cases:
> - Logical view of the system - I guess this was the original intention of
> Categories, but has been hijacked by Monticello
> - By project - which, as you just showed, we have now, yay!
> - By package - the least useful, but primary (up til now), view
> (edited)
> and regarding Nautilus' tree package pane (when it first arrived):
> I noticed that right now, separate packages within the same project are not
> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
> be siblings in the tree, instead of both under MyProject. It seems like it
> would be more useful to have
> - MyProject
>   - Core
>   - Platform
> in the tree
>
>> it seems that the tree is primarily about chunking information into
>> manageable pieces.
>
> A primary difficulty here is that packages are often divided for reasons
> that have nothing to do with the domain model, e.g. the ubiquitous
> MyPackage-Platform, which is an artifact of Metacello that is not all that
> relevant to a user wanting to understand the system.
>
> From the naive user perspective, if I'm exploring from the top level of the
> system, I want to see things like:
> - CodeImport
> - Collections
> - Compiler
>
> From this perspective, the 14 entries for Collections, multiplied by a few
> dozen top-level categories make the list unwieldy and only marginally less
> daunting than the flattened list we used to have (see
> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

[Bernardo Ezequiel Contreras]

Iceberg 0.7 : new UI
https://www.youtube.com/watch?v=A9H8jsSnBKM=539s

On Thu, Apr 12, 2018 at 6:42 AM, Stephane Ducasse 
wrote:

> I will not make it but I really want. Let us know where will be the videos.
>
> Stef
>
> On Thu, Apr 12, 2018 at 9:09 AM, Marcus Denker 
> wrote:
> > This is today
> >
> > 5:00 PM - 7:00 PM (UTC+02:00)
> >
> > There is a calendar entry to download at: https://association.pharo.org/
> event-2797068
> >
> >> On 10 Apr 2018, at 16:34, Marcus Denker  wrote:
> >>
> >> Hi,
> >>
> >> There next TechTalk will be April 12: GIT with Iceberg
> >>
> >>   https://association.pharo.org/event-2797068
> >>
> >>
> >> A regular chat about Pharo. Happens on Discord.
> >>
> >> The Tech talks are open to both members and non-members!
> >>
> >> Topic:  GIT with Iceberg. Demo of improved UI
> >>
> >> We will send an information to all subscribers some hours before the
> talk starts.
> >>
> >>
> >
> >
>
>


-- 
Bernardo E.C.

Sent from a cheap desktop computer in South America.

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Eliot Miranda]

Hi Sean,

On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris 
wrote:

> Stephane Ducasse-3 wrote
> > You see. You pushed this idea and at then end we will have to handle the
> > mess.
> > I do not see why we cannot simply support *.
>
> I'm surprised by this resistance. The *Xyz was always an ugly hack, part of
> Squeak's overloading the same mechanism for both system categorization and
> packaging, and exposing and limiting protocols as "just dumb strings", all
> of which IMHO makes the system much less understandable (no real "private"
> tagging, extension methods can't show up in proper protocol, etc). We're
> not
> in a feature freeze, so what is the problem with tackling part of this mess
> now? Sure, maybe the UI support can be improved, but let's focus on some
> concrete suggestions.
>
> Denis and I just happened to be talking about this larger issue the other
> day. Here are a few snippets I dug up during that conversations of some of
> my many posts about this over the years…
>
> > we have overloaded system categories to package code for SCM. System
> > categories should be tags (preferably multiple allowed)
> > which offer a logical view of the system. Packages, the POV we show now,
> > are orthogonal and much less useful for users.
> (edited)
> and another:
> > I feel more and more that the standard "Package" pane is only useful
> > for... packaging, and when one takes off the dependency management hat
> and
> > puts the user hat on (i.e. most of the time), what you really want there
> > is a logical view of the system. So I see three use cases:
> - Logical view of the system - I guess this was the original intention of
> Categories, but has been hijacked by Monticello
> - By project - which, as you just showed, we have now, yay!
> - By package - the least useful, but primary (up til now), view
> (edited)
> and regarding Nautilus' tree package pane (when it first arrived):
> I noticed that right now, separate packages within the same project are not
> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
> be siblings in the tree, instead of both under MyProject. It seems like it
> would be more useful to have
> - MyProject
>   - Core
>   - Platform
> in the tree
>

If you and Denis are "going radical" and going to do the right thing then
please also give thought to overrides and unloading.  Allowing a package to
override a set of methods on load is a useful facility, fraught with
difficulties (being able to browse the overridden versions being the main
one).  Having things organized so that the overridden versions are saved,
don't get lost when source is rewritten, etc, etc (made much easier by
keeping source in methods), but most importantly, get restored in the right
order when packages are unloaded.  I believe it's as simple as associating
the methods that are overridden with the packages to which they belong, and
maintaining a load order (so that if PkgA B & C implement C>>foo, and are
loaded in the order A, B, C, then we can compute easily that unloading C
restores PkgB's C>>foo, and that unloading B does not affect C>>foo).


>
> > it seems that the tree is primarily about chunking information into
> > manageable pieces.
>
> A primary difficulty here is that packages are often divided for reasons
> that have nothing to do with the domain model, e.g. the ubiquitous
> MyPackage-Platform, which is an artifact of Metacello that is not all that
> relevant to a user wanting to understand the system.
>
> From the naive user perspective, if I'm exploring from the top level of the
> system, I want to see things like:
> - CodeImport
> - Collections
> - Compiler
>
> From this perspective, the 14 entries for Collections, multiplied by a few
> dozen top-level categories make the list unwieldy and only marginally less
> daunting than the flattened list we used to have (see
> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>


-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Sean P. DeNigris]

Stephane Ducasse-3 wrote
> You see. You pushed this idea and at then end we will have to handle the
> mess.
> I do not see why we cannot simply support *.

I'm surprised by this resistance. The *Xyz was always an ugly hack, part of
Squeak's overloading the same mechanism for both system categorization and
packaging, and exposing and limiting protocols as "just dumb strings", all
of which IMHO makes the system much less understandable (no real "private"
tagging, extension methods can't show up in proper protocol, etc). We're not
in a feature freeze, so what is the problem with tackling part of this mess
now? Sure, maybe the UI support can be improved, but let's focus on some
concrete suggestions.

Denis and I just happened to be talking about this larger issue the other
day. Here are a few snippets I dug up during that conversations of some of
my many posts about this over the years…

> we have overloaded system categories to package code for SCM. System
> categories should be tags (preferably multiple allowed) 
> which offer a logical view of the system. Packages, the POV we show now,
> are orthogonal and much less useful for users.
(edited)
and another:
> I feel more and more that the standard "Package" pane is only useful
> for... packaging, and when one takes off the dependency management hat and
> puts the user hat on (i.e. most of the time), what you really want there
> is a logical view of the system. So I see three use cases: 
- Logical view of the system - I guess this was the original intention of
Categories, but has been hijacked by Monticello 
- By project - which, as you just showed, we have now, yay! 
- By package - the least useful, but primary (up til now), view
(edited)
and regarding Nautilus' tree package pane (when it first arrived):
I noticed that right now, separate packages within the same project are not
collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
be siblings in the tree, instead of both under MyProject. It seems like it
would be more useful to have 
- MyProject 
  - Core 
  - Platform 
in the tree

> it seems that the tree is primarily about chunking information into
> manageable pieces. 

A primary difficulty here is that packages are often divided for reasons
that have nothing to do with the domain model, e.g. the ubiquitous
MyPackage-Platform, which is an artifact of Metacello that is not all that
relevant to a user wanting to understand the system. 

>From the naive user perspective, if I'm exploring from the top level of the
system, I want to see things like: 
- CodeImport 
- Collections 
- Compiler 

>From this perspective, the 14 entries for Collections, multiplied by a few
dozen top-level categories make the list unwieldy and only marginally less
daunting than the flattened list we used to have (see
http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Pharo Launcher on Windows > Failing

[p...@highoctane.be]

https://github.com/pharo-project/pharo-launcher/issues/88 filled in.

Thx for the help!

Phil







On Thu, Apr 12, 2018 at 5:18 PM,  wrote:

> Hi Phil,
>
>
>
> I can help you to fix this issue. Can you tell me the list of the files in
> the folder that is designed by the error?
>
> And in the parent folder, there should be a zip file with the same name,
> can you check if Pharo.exe is here and if the file list is the same?
>
> It will be nice if you can serialize the stack and send it to me / post it
> in a new github issue: https://github.com/pharo-
> project/pharo-launcher/issues .
>
>
>
> Thanks,
>
>
>
> Vincent
>
>
>
> *From:* Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] *On Behalf
> Of *p...@highoctane.be
> *Sent:* Thursday, April 12, 2018 7:58
> *To:* Discusses Development of Pharo 
> *Subject:* [Pharo-dev] Pharo Launcher on Windows > Failing
>
>
>
> I wanted to try Pharo Laucher before the tech talk
>
>
>
> But I get this when asking for an image
>
>
>
>
>
> I do not even know what is going on and I am an "experienced user".
>
>
>
> The impression this gives to a newcomer is utterly disastrous.
>
>
>
> We are really on a bad path on this.
>
>
>
> I'd like to get through this with some Launcher expert and fix this for
> good.
>
>
>
> Phil
>
>
>

Re: [Pharo-dev] Pharo Launcher on Windows > Failing

[Vincent.Blondeau]

Hi Phil,

I can help you to fix this issue. Can you tell me the list of the files in the 
folder that is designed by the error?
And in the parent folder, there should be a zip file with the same name, can 
you check if Pharo.exe is here and if the file list is the same?
It will be nice if you can serialize the stack and send it to me / post it in a 
new github issue: https://github.com/pharo-project/pharo-launcher/issues .

Thanks,

Vincent

From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of 
p...@highoctane.be
Sent: Thursday, April 12, 2018 7:58
To: Discusses Development of Pharo 
Subject: [Pharo-dev] Pharo Launcher on Windows > Failing

I wanted to try Pharo Laucher before the tech talk

But I get this when asking for an image

[cid:image002.png@01D3D236.9CDB6FD0]

I do not even know what is going on and I am an "experienced user".

The impression this gives to a newcomer is utterly disastrous.

We are really on a bad path on this.

I'd like to get through this with some Launcher expert and fix this for good.

Phil

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Alistair Grant]

On 11 April 2018 at 20:47, Sven Van Caekenberghe  wrote:
>
> But there is something wrong with what is returned by Stdio stdin
>

I've opened 
https://pharo.fogbugz.com/f/cases/21692/StdioStream-incorrectly-delegates-atEnd-and-position-to-file

PR in progress.

Cheers,
Alistair

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Alistair Grant]

On 12 April 2018 at 10:48, Alistair Grant  wrote:
>
> So I'm going to respectfully disagree and say that I think to raise a
> MNU instead of returning nil is wrong, and that changing the Zinc
> streams isn't such a big deal.

Sorry Sven, this sounds like I'm suggesting that your planning to
leave the MNU in there, which would be rather rude of me, but isn't
what I meant at all.

But I do think Zinc streams should handle #next returning nil before
#atEnd answers true.

Cheers,
Alistair

[Pharo-dev] TechTalk on Iceberg will start in 30min (link inside)

[Esteban Lorenzano]

here: 

https://www.youtube.com/estebanlorenzano/live 


see you there,
Esteban

[Pharo-dev] [Pharo 7.0-dev] Build #762: 21684-Integrate-Iceberg-0.7.1

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #762 was: SUCCESS.

The Pull Request #1188 was integrated: "21684-Integrate-Iceberg-0.7.1"
Pull request url: https://github.com/pharo-project/pharo/pull/1188

Issue Url: https://pharo.fogbugz.com/f/cases/21684
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/762/

[Pharo-dev] [Pharo 7.0-dev] Build #761: 21684-Integrate-Iceberg-0.7.1

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #761 was: FAILURE.

The Pull Request #1188 was integrated: "21684-Integrate-Iceberg-0.7.1"
Pull request url: https://github.com/pharo-project/pharo/pull/1188

Issue Url: https://pharo.fogbugz.com/f/cases/21684
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/761/

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Denis Kudriashov]

2018-04-12 12:49 GMT+02:00 Stephane Ducasse :

> I do not see why we should remove star protocols.


Think about future module system which you already started to work with
others.
I don't think you plan to support string convention there.

I just want RIGHT simple things:

aMethod package: aPackage.

or

aPackage addMethod: aMethod.


Instead of


aMethod protocol: '*', aPackage name


Which is the only way to create extension in current system.


> It will break many things.
>

As soon as package management will do this part in the right way we will
just need to fix code exporters and importers.
But fixing package system is not easy task. Extension protocols and
packages are bound implicitly using events.


> Why can't we focus on important next steps.
>

I would say it is required step to achieve module system.


>
> On Thu, Apr 12, 2018 at 12:10 PM, Denis Kudriashov 
> wrote:
> > But it shows notification why it does not supported and what to use
> instead.
> > (it was not available in old versions)
> >
> > Idea to move away from star convention. Calypso gives you explicit tools
> to
> > add method to the package. Most simple is checkbox "extension" in the
> status
> > bar of method editor.
> > For now star convention will stay internal implementation detail of
> > RPackage. In future it should be completely removed (you know how
> RPackage
> > is ugly because of that). Only old text code formats will use star
> > protocols.
> >
> > So Calypso is a step to remove this "star habit" from users.
> >
> > 2018-04-12 11:42 GMT+02:00 Stephane Ducasse :
> >>
> >> in calypso.
> >> * was simple and nice.
> >> Now if I create a protocol with a star it got eaten and no protocol
> >> will be created.
> >>
> >> Stef
> >>
> >
>
>

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Stephane Ducasse]

Ok let us move away. Now I would like to know all the old ways and clean them.

Stef

On Thu, Apr 12, 2018 at 1:37 PM, Denis Kudriashov  wrote:
>
>
> 2018-04-12 12:31 GMT+02:00 Peter Uhnák :
>>>
>>> In future it should be completely removed (you know how RPackage is ugly
>>> because of that). Only old text code formats will use star protocols.
>>>
>>>
>>> So Calypso is a step to remove this "star habit" from users.
>>
>>
>> What is the correct way to generate such methods then?
>> I use Something compile: 'method' classified: '*OtherPackage' ... but if
>> the star convention is removed?
>
>
> It should be simple package parameter like:
>
> Something compile: 'method' inPackage: #'OtherPackage' asPackage
>
>
>>
>>
>> Thanks,
>> Peter
>
>

Re: [Pharo-dev] How to remove the extra protocol in Calypso

[Stephane Ducasse]

Hi guys

I went to discuss with denis. And we will have some settings.
And also better names for some menus.
And also some fixes because some behavior was confusing and I got confused.

Stef

On Thu, Apr 12, 2018 at 12:54 PM, Stephane Ducasse
 wrote:
> I want that the tools let me to get focused on my task.
> And now I cannot disable.
>
> I do not want to live in a place with neon ads all over the place, I
> want a calm place where I can pick
> the tools I need when I need them and that they are not impose on me.
>
> BTW I will not adapt the mooc so students will use Pharo 50. Why
> because I'm fedup to be the idiot
> in this community upgrading books, slides and videos.
>
> Yes you can think that "oh we we cannot invent new stuff then we
> should better stop"
> - first I would like to see the people that think that to write more
> than a page on doc.
> - second paying attention to not impose new stuff for the shake on it
> would be better
>
> Stef
>
> On Thu, Apr 12, 2018 at 12:50 PM, Stephane Ducasse
>  wrote:
>> I want to remove
>>  critiques
>>  overridden
>>  overrides
>>
>> THEY GET IN MY WAY.
>> Sorry to have to shout but I have the impression that I'm not heard.
>>
>> Ideally we could have a menu item to show extras things. RIght now
>> each time I browse my class I stop
>> because I have to interpret these new infroamtion and I'm not
>> interested in them.
>>
>> Stef
>>
>>
>> On Thu, Apr 12, 2018 at 12:46 PM, Stephane Ducasse
>>  wrote:
>>> Hi
>>>
>>> There are too much information by default I'm overhelmed.
>>> I would like to remove the following protocols
>>>
>>> critiques

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Denis Kudriashov]

2018-04-12 12:31 GMT+02:00 Peter Uhnák :

> In future it should be completely removed (you know how RPackage is ugly
>> because of that). Only old text code formats will use star protocols.
>
>
>> So Calypso is a step to remove this "star habit" from users.
>>
>
> What is the correct way to generate such methods then?
> I use Something compile: 'method' classified: '*OtherPackage' ... but if
> the star convention is removed?
>

It should be simple package parameter like:

Something compile: 'method' inPackage: #'OtherPackage' asPackage



>
> Thanks,
> Peter
>

Re: [Pharo-dev] How to remove the extra protocol in Calypso

[Stephane Ducasse]

I want that the tools let me to get focused on my task.
And now I cannot disable.

I do not want to live in a place with neon ads all over the place, I
want a calm place where I can pick
the tools I need when I need them and that they are not impose on me.

BTW I will not adapt the mooc so students will use Pharo 50. Why
because I'm fedup to be the idiot
in this community upgrading books, slides and videos.

Yes you can think that "oh we we cannot invent new stuff then we
should better stop"
- first I would like to see the people that think that to write more
than a page on doc.
- second paying attention to not impose new stuff for the shake on it
would be better

Stef

On Thu, Apr 12, 2018 at 12:50 PM, Stephane Ducasse
 wrote:
> I want to remove
>  critiques
>  overridden
>  overrides
>
> THEY GET IN MY WAY.
> Sorry to have to shout but I have the impression that I'm not heard.
>
> Ideally we could have a menu item to show extras things. RIght now
> each time I browse my class I stop
> because I have to interpret these new infroamtion and I'm not
> interested in them.
>
> Stef
>
>
> On Thu, Apr 12, 2018 at 12:46 PM, Stephane Ducasse
>  wrote:
>> Hi
>>
>> There are too much information by default I'm overhelmed.
>> I would like to remove the following protocols
>>
>> critiques

Re: [Pharo-dev] How to remove the extra protocol in Calypso

[Stephane Ducasse]

I want to remove
 critiques
 overridden
 overrides

THEY GET IN MY WAY.
Sorry to have to shout but I have the impression that I'm not heard.

Ideally we could have a menu item to show extras things. RIght now
each time I browse my class I stop
because I have to interpret these new infroamtion and I'm not
interested in them.

Stef


On Thu, Apr 12, 2018 at 12:46 PM, Stephane Ducasse
 wrote:
> Hi
>
> There are too much information by default I'm overhelmed.
> I would like to remove the following protocols
>
> critiques

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Stephane Ducasse]

I do not see why we should remove star protocols. It will break many things.
Why can't we focus on important next steps.

On Thu, Apr 12, 2018 at 12:10 PM, Denis Kudriashov  wrote:
> But it shows notification why it does not supported and what to use instead.
> (it was not available in old versions)
>
> Idea to move away from star convention. Calypso gives you explicit tools to
> add method to the package. Most simple is checkbox "extension" in the status
> bar of method editor.
> For now star convention will stay internal implementation detail of
> RPackage. In future it should be completely removed (you know how RPackage
> is ugly because of that). Only old text code formats will use star
> protocols.
>
> So Calypso is a step to remove this "star habit" from users.
>
> 2018-04-12 11:42 GMT+02:00 Stephane Ducasse :
>>
>> in calypso.
>> * was simple and nice.
>> Now if I create a protocol with a star it got eaten and no protocol
>> will be created.
>>
>> Stef
>>
>

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Stephane Ducasse]

You see. You pushed this idea and at then end we will have to handle the mess.
I do not see why we cannot simply support *.
Seriously why eveybody on earth has to inforce their own view.
Now to declare an extension (it took me at least 10 min) we have to
create a protocol then to click on it then to select an existing
package!
Why it cannot stay and be simple

On Thu, Apr 12, 2018 at 12:10 PM, Denis Kudriashov  wrote:
> But it shows notification why it does not supported and what to use instead.
> (it was not available in old versions)
>
> Idea to move away from star convention. Calypso gives you explicit tools to
> add method to the package. Most simple is checkbox "extension" in the status
> bar of method editor.
> For now star convention will stay internal implementation detail of
> RPackage. In future it should be completely removed (you know how RPackage
> is ugly because of that). Only old text code formats will use star
> protocols.
>
> So Calypso is a step to remove this "star habit" from users.
>
> 2018-04-12 11:42 GMT+02:00 Stephane Ducasse :
>>
>> in calypso.
>> * was simple and nice.
>> Now if I create a protocol with a star it got eaten and no protocol
>> will be created.
>>
>> Stef
>>
>

[Pharo-dev] How to remove the extra protocol in Calypso

[Stephane Ducasse]

Hi

There are too much information by default I'm overhelmed.
I would like to remove the following protocols

critiques

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Peter Uhnák]

>
> In future it should be completely removed (you know how RPackage is ugly
> because of that). Only old text code formats will use star protocols.


> So Calypso is a step to remove this "star habit" from users.
>

What is the correct way to generate such methods then?
I use Something compile: 'method' classified: '*OtherPackage' ... but if
the star convention is removed?

Thanks,
Peter

Re: [Pharo-dev] Why can't we use * in protocol for package extension?

[Denis Kudriashov]

But it shows notification why it does not supported and what to use
instead. (it was not available in old versions)

Idea to move away from star convention. Calypso gives you explicit tools to
add method to the package. Most simple is checkbox "extension" in the
status bar of method editor.
For now star convention will stay internal implementation detail of
RPackage. In future it should be completely removed (you know how RPackage
is ugly because of that). Only old text code formats will use star
protocols.

So Calypso is a step to remove this "star habit" from users.

2018-04-12 11:42 GMT+02:00 Stephane Ducasse :

> in calypso.
> * was simple and nice.
> Now if I create a protocol with a star it got eaten and no protocol
> will be created.
>
> Stef
>
>

Re: [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

[Stephane Ducasse]

I will not make it but I really want. Let us know where will be the videos.

Stef

On Thu, Apr 12, 2018 at 9:09 AM, Marcus Denker  wrote:
> This is today
>
> 5:00 PM - 7:00 PM (UTC+02:00)
>
> There is a calendar entry to download at: 
> https://association.pharo.org/event-2797068
>
>> On 10 Apr 2018, at 16:34, Marcus Denker  wrote:
>>
>> Hi,
>>
>> There next TechTalk will be April 12: GIT with Iceberg
>>
>>   https://association.pharo.org/event-2797068
>>
>>
>> A regular chat about Pharo. Happens on Discord.
>>
>> The Tech talks are open to both members and non-members!
>>
>> Topic:  GIT with Iceberg. Demo of improved UI
>>
>> We will send an information to all subscribers some hours before the talk 
>> starts.
>>
>>
>
>

[Pharo-dev] Why can't we use * in protocol for package extension?

[Stephane Ducasse]

in calypso.
* was simple and nice.
Now if I create a protocol with a star it got eaten and no protocol
will be created.

Stef

Re: [Pharo-dev] Why String do not implement #displayString?

[Stephane Ducasse]

Thanks denis!
No problem syrel I was also dead tired :)

On Thu, Apr 12, 2018 at 10:19 AM, Denis Kudriashov  wrote:
> Ok. I opened the issue 21689
>
> 2018-04-11 22:06 GMT+02:00 Stephane Ducasse :
>>
>> The point is a list of strings should be displayed as
>>
>> a
>> b
>> c
>>
>> and not
>>
>> 'a'
>> 'b'
>> 'c'
>>
>> It shows that often people confuse asString and printString BTW.
>>
>> On Wed, Apr 11, 2018 at 10:05 PM, Stephane Ducasse
>>  wrote:
>> > ?
>> >
>> >
>> > On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel 
>> > wrote:
>> >> Hi,
>> >>
>> >> I am sorry for interrupting this conversation... but
>> >>
>> >> | s |
>> >> s := 'Hello, ''Funny'' World'.
>> >> s displayString = s "false" and not true!
>> >>
>> >> Cheers,
>> >> Alex
>> >>
>> >> On 11 April 2018 at 21:53, Stephane Ducasse 
>> >> wrote:
>> >>>
>> >>> Yes I think that
>> >>>
>> >>> | s |
>> >>> s := 'Hello, ''Funny'' World'.
>> >>> s displayString = s. "true"
>> >>> s printString = s. "false"
>> >>>
>> >>> is ok and widgets should use displayString.
>> >>>
>> >>> Stef
>> >>>
>> >>>
>> >>> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo
>> >>>  wrote:
>> >>> > Isn't #displayString implemented in terms of #displayOn: the same
>> >>> > way
>> >>> > #printString is implemented in terms of "printOn:"?
>> >>> >
>> >>> > And in the case of String #displayString should return the receiver
>> >>> > (it
>> >>> > is, self), so the following should be true.
>> >>> >
>> >>> > | s |
>> >>> > s := 'Hello, ''Funny'' World'.
>> >>> > s displayString = s. "true"
>> >>> > s printString = s. "false"
>> >>> >
>> >>> > Regards,
>> >>> >
>> >>> >
>> >>> > On 10/04/2018 12:21, Denis Kudriashov wrote:
>> >>> >> Hi.
>> >>> >>
>> >>> >> According to the comment of #displayString it should be used as
>> >>> >> default
>> >>> >> textual representation of objects in the UI:
>> >>> >>
>> >>> >> "While printString is about to give a detailled information
>> >>> >> about
>> >>> >> an
>> >>> >> object, displayString is a message that should return a short
>> >>> >> string-based representation to be used by list and related UI
>> >>> >> frameworks. By default, simply return printString."
>> >>> >> "asString should not be implemented in Object, and kept for
>> >>> >> conversion between strings, symbols, text and characters."
>> >>> >>
>> >>> >> But String itself does not respect this message:
>> >>> >>
>> >>> >> 'some string' displayString " ==> '''someString''' "
>> >>> >>
>> >>> >>
>> >>> >> Is it bug? Or is there any reason for this?
>> >>> >>
>> >>> >> Best regards,
>> >>> >> Denis
>> >>> >
>> >>> > --
>> >>> > Esteban A. Maringolo
>> >>> >
>> >>>
>> >>
>>
>

Re: [Pharo-dev] [Newsletter] Content Needed

[Stephane Ducasse]

You can mention Chrysal: a library to manage configuration
http://github.com/Ducasse/Chrysal

Stef

On Thu, Apr 12, 2018 at 9:28 AM, Marcus Denker  wrote:
> Hi,
>
> The Pharo Monthly Newsletter is working quite well.
> https://newsletter.pharo.org
>
> We now reached a level where it is not just 3 things, but much much more..
> of course this comes with a downside:
> - Sometimes topics that would be worth a small article are just posted as a
> one-liners
> - I forget / overlook things for sure (so much happening!)
>
> If you want your (or some other project or topic) to be in the newsletter —>
> send me a mail, in the best of all cases
> with a fully written text that you want to have posted.
>
> This includes:
> - new libraries and projects
> - dates
> - high level description of existing projects
> - videos
> - Blog posts
> - books
> - lectures
> - Success Stories of all kinds (nice to present your Company!)
> - Research (e.g. published papers or project descriptions)
> - Expanded versions of news posted as one-liners before
> - ….
>
> There is a explicit jobs section, too.
>
> Marcus

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Alistair Grant]

Hi Sven,

On Thu, Apr 12, 2018 at 09:23:21AM +0200, Sven Van Caekenberghe wrote:
>
>
> > On 12 Apr 2018, at 08:33, Alistair Grant  wrote:
> >
> > ...
> >
> > In your example you've carefully exited by some other means than
> > signalling end-of-file (Ctrl-D).
> >
> > I don't think we can reasonably say "if you write code with Zinc
> > streams, ensure that none of your users ever press Ctrl-D, they must
> > always type 'quit' (or whatever)".
>
> I left that open as an exercise for the reader - I knew you would try that ;-)

Glad that I didn't disappoint. :-)


> The code was originally written for network streams and there it
> catches ConnectionClosed which is the network stream equivalent of EOF
> (more or less).
>
> I think we need something like an EndOfStream exception which should
> be thrown in that case, instead of returning nil.
>
> Returning nil from ZnCharacterReadStream or ZnCharacterEncoder when
> the stream is EOF is wrong IMHO. The stream being EOF is an
> exceptional situation (even though it is relatively common) and there
> is always #atEnd that works well in 99% of the cases.
>
> AFAIK that is also the design decision taking by Xtreams (where I
> believe the Incomplete exception replaces #atEnd).

OK, this brings us full-circle.

Earlier in the thread we wrote:


On Tue, Apr 10, 2018 at 11:54:39PM +0200, Sven Van Caekenberghe wrote:
> Alistair,
>
> I am replying in-between, please don't take my remarks as being
> negative, I just like to straighten things out as clear as possible.
>
> > On 10 Apr 2018, at 22:14, Alistair Grant  wrote:
> >
> > At this point I think there are three options:
> >
> > 1. Modify Zinc to check the return value of #next instead of using #atEnd.
> >
> > This is what all existing character / byte oriented streams in Squeak
> > and Pharo do.  At that point the Zinc streams can be used on all file
> > / stdio input and output.
>
> I agree that such code exists in many places, but there is lots of
> stream reading that does not check for nils.
>
> > 2. Modify all streams to signal EOF in some other way, i.e. a sentinel
> > or notification / exception.
> >
> > This is what we were discussing below.  But it is a decent chunk of
> > work with significant impact on the existing code base.
>
> Agreed. This would be a future extension.


I agree that raising an exception is a nicer solution (although for
anyone who disagrees I'll also admit that there is a subjective element to
that assessment).

But the existing behaviour of returning nil on EOF has been around for a
long time and works reasonably well, and as we agreed here, changing that
behaviour will have a significant impact on the existing code base.

None of this excludes Zinc streams adopting exceptions at any time in
the future.

So I'm going to respectfully disagree and say that I think to raise a
MNU instead of returning nil is wrong, and that changing the Zinc
streams isn't such a big deal.

Cheers,
Alistair

Re: [Pharo-dev] Why String do not implement #displayString?

[Denis Kudriashov]

Ok. I opened the issue 21689


2018-04-11 22:06 GMT+02:00 Stephane Ducasse :

> The point is a list of strings should be displayed as
>
> a
> b
> c
>
> and not
>
> 'a'
> 'b'
> 'c'
>
> It shows that often people confuse asString and printString BTW.
>
> On Wed, Apr 11, 2018 at 10:05 PM, Stephane Ducasse
>  wrote:
> > ?
> >
> >
> > On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel 
> wrote:
> >> Hi,
> >>
> >> I am sorry for interrupting this conversation... but
> >>
> >> | s |
> >> s := 'Hello, ''Funny'' World'.
> >> s displayString = s "false" and not true!
> >>
> >> Cheers,
> >> Alex
> >>
> >> On 11 April 2018 at 21:53, Stephane Ducasse 
> wrote:
> >>>
> >>> Yes I think that
> >>>
> >>> | s |
> >>> s := 'Hello, ''Funny'' World'.
> >>> s displayString = s. "true"
> >>> s printString = s. "false"
> >>>
> >>> is ok and widgets should use displayString.
> >>>
> >>> Stef
> >>>
> >>>
> >>> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo
> >>>  wrote:
> >>> > Isn't #displayString implemented in terms of #displayOn: the same way
> >>> > #printString is implemented in terms of "printOn:"?
> >>> >
> >>> > And in the case of String #displayString should return the receiver
> (it
> >>> > is, self), so the following should be true.
> >>> >
> >>> > | s |
> >>> > s := 'Hello, ''Funny'' World'.
> >>> > s displayString = s. "true"
> >>> > s printString = s. "false"
> >>> >
> >>> > Regards,
> >>> >
> >>> >
> >>> > On 10/04/2018 12:21, Denis Kudriashov wrote:
> >>> >> Hi.
> >>> >>
> >>> >> According to the comment of #displayString it should be used as
> default
> >>> >> textual representation of objects in the UI:
> >>> >>
> >>> >> "While printString is about to give a detailled information
> about
> >>> >> an
> >>> >> object, displayString is a message that should return a short
> >>> >> string-based representation to be used by list and related UI
> >>> >> frameworks. By default, simply return printString."
> >>> >> "asString should not be implemented in Object, and kept for
> >>> >> conversion between strings, symbols, text and characters."
> >>> >>
> >>> >> But String itself does not respect this message:
> >>> >>
> >>> >> 'some string' displayString " ==> '''someString''' "
> >>> >>
> >>> >>
> >>> >> Is it bug? Or is there any reason for this?
> >>> >>
> >>> >> Best regards,
> >>> >> Denis
> >>> >
> >>> > --
> >>> > Esteban A. Maringolo
> >>> >
> >>>
> >>
>
>

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Sven Van Caekenberghe]

> On 12 Apr 2018, at 03:15, Eliot Miranda  wrote:
> 
> Hi Sven,
> 
> On Wed, Apr 11, 2018 at 1:25 PM, Sven Van Caekenberghe  wrote:
> 
> 
> > On 11 Apr 2018, at 21:44, Stephane Ducasse  wrote:
> >
> > I did not know about the NeoConsole. Nice because I wanted to build a
> > little REPL for my minilanguage implementation.
> 
> You are of course welcome to look at it.
> But it is Pharo specific.
> I use it to be able to hook/look into running headless server images.
> For this it is super handy.
> 
> Cool usage!  Could you tell me whether you type Smalltalk expressions into 
> this to examine your running server?  The answer will be used in a related 
> discussion on a mailing list not too distant from this one ;-)

Yes of course, that it the whole purpose, to type in expressions and to 
manipulate objects in a running image. I recently added options to look at code 
and change/add methods. All very primitive, but when in trouble, it works well.

> > Stef
> >
> > On Wed, Apr 11, 2018 at 8:47 PM, Sven Van Caekenberghe  wrote:
> >> Alistair,
> >>
> >>> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe  wrote:
> >>>
> >>> I will send you some code later on.
> >>
> >> Today I arranged for my NeoConsole code (that normally works over a 
> >> network connection) to work over stdio. Although I am not yet happy with 
> >> every aspect of the implementation, it does work (using unaltered Zn 
> >> streams and code). The foll
> >>
> >> $ cat /etc/issue
> >> Ubuntu 16.04.4 LTS
> >> $ mkdir pharo7
> >> $ cd pharo7/
> >> $ curl get.pharo.org/70+vm | bash
> >>  % Total% Received % Xferd  Average Speed   TimeTime Time  
> >> Current
> >> Dload  Upload   Total   SpentLeft  
> >> Speed
> >> 100  3036  100  30360 0  36799  0 --:--:-- --:--:-- --:--:-- 
> >> 37024
> >> Downloading the latest 70 Image:
> >>http://files.pharo.org/get-files/70/pharo.zip
> >> Pharo.image
> >> Downloading the latest pharoVM:
> >>http://files.pharo.org/get-files/70/pharo-linux-stable.zip
> >> pharo-vm/pharo
> >> Creating starter scripts pharo and pharo-ui
> >> On a 64-bit system? You must enable and install the 32-bit libraries
> >>   Please see http://pharo.org/gnu-linux-installation for detailed 
> >> instructions
> >> $ ./pharo Pharo.image config http://mc.stfx.eu/Neo 
> >> ConfigurationOfNeoConsole --install=bleedingEdge
> >> 'Installing ConfigurationOfNeoConsole bleedingEdge'
> >>
> >> Loading 1-baseline of ConfigurationOfNeoConsole...
> >> Fetched -> Neo-Console-Core-SvenVanCaekenberghe.24 --- 
> >> http://mc.stfx.eu/Neo --- http://mc.stfx.eu/Neo
> >> Loaded -> Neo-Console-Core-SvenVanCaekenberghe.24 --- 
> >> http://mc.stfx.eu/Neo --- cache
> >> ...finished 1-baseline
> >> $ ./pharo Pharo.image eval NeoConsoleStdio run
> >> Neo Console 
> >> Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a (32 
> >> Bit)
> >> pharo> 1+2
> >>
> >> 3
> >> pharo> 42 factorial
> >>
> >> 14050061177528798985431426062445115699363840
> >> pharo> Stdio stdin
> >>
> >> StdioStream: #stdin
> >> pharo> ==
> >> self: StdioStream: #stdin
> >> class: StdioStream
> >> file: a File
> >> handle: #[148 213 25 107 160 197 105 247 0 0 0 0 0 0 0 0 0 1 255 1]
> >> forWrite: false
> >> peekBuffer: nil
> >> pharo> show StdioStream>>#atEnd
> >> StdioStream>>#atEnd
> >> atEnd
> >>
> >>^ file atEnd
> >> pharo> get process.list
> >> Morphic UI Process
> >> Delay Scheduling Process
> >> Low Space Watcher
> >> Input Event Fetcher Process
> >> Idle Process
> >> WeakArray Finalization Process
> >> CommandLine handler process
> >> pharo> quit
> >> Bye!
> >> a NeoConsoleStdio
> >>
> >> I know there are many approaches to a REPL, I don't claim mine is best, it 
> >> is just the one that I have been using for years.
> >>
> >> In the above, I do not depend on EOF - just to be clear. The point being 
> >> that there is no immediate fundamental problem.
> >>
> >> But there is something wrong with what is returned by Stdio stdin
> >>
> >> Sven
> >>
> >>
> >>
> >
> 
> 
> 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Sven Van Caekenberghe]

> On 12 Apr 2018, at 04:07, Ben Coman  wrote:
> 
> 
> 
> On 12 April 2018 at 04:25, Sven Van Caekenberghe  wrote:
> 
> 
> > On 11 Apr 2018, at 21:44, Stephane Ducasse  wrote:
> >
> > I did not know about the NeoConsole. Nice because I wanted to build a
> > little REPL for my minilanguage implementation.
> 
> You are of course welcome to look at it.
> But it is Pharo specific.
> I use it to be able to hook/look into running headless server images.
> For this it is super handy.
> 
> A description of how to set that up would make a nice blog post.

It is part of, and partially documented in 
https://github.com/svenvc/pharo-server-tools

But maybe I'll write something about it, yes.

> cheers -ben 

[Pharo-dev] [Newsletter] Content Needed

[Marcus Denker]

Hi,

The Pharo Monthly Newsletter is working quite well. 
https://newsletter.pharo.org 

We now reached a level where it is not just 3 things, but much much more..  of 
course this comes with a downside:
- Sometimes topics that would be worth a small article are just posted 
as a one-liners
- I forget / overlook things for sure (so much happening!)

If you want your (or some other project or topic) to be in the newsletter —> 
send me a mail, in the best of all cases
with a fully written text that you want to have posted.

This includes:
- new libraries and projects
- dates
- high level description of existing projects
- videos
- Blog posts
- books
- lectures
- Success Stories of all kinds (nice to present your Company!)
- Research (e.g. published papers or project descriptions)
- Expanded versions of news posted as one-liners before
- ….

There is a explicit jobs section, too. 

Marcus

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Sven Van Caekenberghe]

> On 12 Apr 2018, at 08:33, Alistair Grant  wrote:
> 
> Hi Sven,
> 
> On 11 April 2018 at 20:47, Sven Van Caekenberghe  wrote:
>> Alistair,
>> 
>>> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe  wrote:
>>> 
>>> I will send you some code later on.
>> 
>> Today I arranged for my NeoConsole code (that normally works over a network 
>> connection) to work over stdio. Although I am not yet happy with every 
>> aspect of the implementation, it does work (using unaltered Zn streams and 
>> code). The foll
>> 
>> $ cat /etc/issue
>> Ubuntu 16.04.4 LTS
>> $ mkdir pharo7
>> $ cd pharo7/
>> $ curl get.pharo.org/70+vm | bash
>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>> Current
>> Dload  Upload   Total   SpentLeft  Speed
>> 100  3036  100  30360 0  36799  0 --:--:-- --:--:-- --:--:-- 
>> 37024
>> Downloading the latest 70 Image:
>>http://files.pharo.org/get-files/70/pharo.zip
>> Pharo.image
>> Downloading the latest pharoVM:
>>http://files.pharo.org/get-files/70/pharo-linux-stable.zip
>> pharo-vm/pharo
>> Creating starter scripts pharo and pharo-ui
>> On a 64-bit system? You must enable and install the 32-bit libraries
>>   Please see http://pharo.org/gnu-linux-installation for detailed 
>> instructions
>> $ ./pharo Pharo.image config http://mc.stfx.eu/Neo ConfigurationOfNeoConsole 
>> --install=bleedingEdge
>> 'Installing ConfigurationOfNeoConsole bleedingEdge'
>> 
>> Loading 1-baseline of ConfigurationOfNeoConsole...
>> Fetched -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo 
>> --- http://mc.stfx.eu/Neo
>> Loaded -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo 
>> --- cache
>> ...finished 1-baseline
>> $ ./pharo Pharo.image eval NeoConsoleStdio run
>> Neo Console 
>> Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a (32 
>> Bit)
>> pharo> 1+2
>> 
>> 3
>> pharo> 42 factorial
>> 
>> 14050061177528798985431426062445115699363840
>> pharo> Stdio stdin
>> 
>> StdioStream: #stdin
>> pharo> ==
>> self: StdioStream: #stdin
>> class: StdioStream
>> file: a File
>> handle: #[148 213 25 107 160 197 105 247 0 0 0 0 0 0 0 0 0 1 255 1]
>> forWrite: false
>> peekBuffer: nil
>> pharo> show StdioStream>>#atEnd
>> StdioStream>>#atEnd
>> atEnd
>> 
>>^ file atEnd
>> pharo> get process.list
>> Morphic UI Process
>> Delay Scheduling Process
>> Low Space Watcher
>> Input Event Fetcher Process
>> Idle Process
>> WeakArray Finalization Process
>> CommandLine handler process
>> pharo> quit
>> Bye!
>> a NeoConsoleStdio
>> 
>> I know there are many approaches to a REPL, I don't claim mine is best, it 
>> is just the one that I have been using for years.
>> 
>> In the above, I do not depend on EOF - just to be clear. The point being 
>> that there is no immediate fundamental problem.
> 
> 
> Cool.  I've wanted to try NeoConsole for a while (I've got a Raspberry
> Pi monitoring temperatures and wanted to use it to work on the Pi) but
> hadn't made the time.
> 
> But... :-)
> 
> 
> $ vm/pharo Pharo7.0-64bit-d2734dc.image eval NeoConsoleStdio run
> Neo Console 
> Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a
> (64 Bit)
> pharo> 4+3
> 
> 7
> pharo> [Ctrl-D]
> MessageNotUnderstood: receiver of "<" is nil
> UndefinedObject(Object)>>doesNotUnderstand: #<
> ZnUTF8Encoder>>nextCodePointFromStream:
> ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
> ZnCharacterReadStream>>nextElement
> ZnCharacterReadStream(ZnEncodedReadStream)>>next
> [ :out |
> | eol char |
> eol := false.
> [ eol ]
> whileFalse: [ char := readStream next.
> (char isNil or: [ char == lf ])
> ifTrue: [ eol := true ]
> ifFalse: [ char == cr
> ifTrue: [ eol := true.
> readStream peekFor: lf ]
> ifFalse: [ out nextPut: char ] ] ] ] in ZnFastLineReader>>nextLine in
> Block: [ :out | ...
> ZnFastLineReader>>streamContents:
> ZnFastLineReader>>nextLine
> [ lineReader nextLine trimBoth ] in NeoConsoleStdio>>readInputFrom: in
> Block: [ lineReader nextLine trimBoth ]
> BlockClosure>>on:do:
> NeoConsoleStdio>>readInputFrom:
> NeoConsoleStdio>>executeRequestResponseLoop
> NeoConsoleStdio>>run
> NeoConsoleStdio class>>run
> UndefinedObject>>DoIt
> 
> 
> In your example you've carefully exited by some other means than
> signalling end-of-file (Ctrl-D).
> 
> I don't think we can reasonably say "if you write code with Zinc
> streams, ensure that none of your users ever press Ctrl-D, they must
> always type 'quit' (or whatever)".

I left that open as an exercise for the reader - I knew you would try that ;-)

The code was originally written for network streams and there it catches 
ConnectionClosed which is the network stream equivalent of EOF (more or less).

I think we need something like an EndOfStream exception which should be thrown 
in that case, instead of returning nil.

Returning nil from ZnCharacterReadStream or ZnCharacterEncoder when the 

Re: [Pharo-dev] [TechTalk] April 12: GIT with Iceberg

[Marcus Denker]

This is today 

5:00 PM - 7:00 PM (UTC+02:00)

There is a calendar entry to download at: 
https://association.pharo.org/event-2797068

> On 10 Apr 2018, at 16:34, Marcus Denker  wrote:
> 
> Hi,
> 
> There next TechTalk will be April 12: GIT with Iceberg
> 
>   https://association.pharo.org/event-2797068
> 
> 
> A regular chat about Pharo. Happens on Discord.
> 
> The Tech talks are open to both members and non-members! 
> 
> Topic:  GIT with Iceberg. Demo of improved UI
> 
> We will send an information to all subscribers some hours before the talk 
> starts.
> 
> 

Re: [Pharo-dev] help wanted: normalising LF on tonel for Pharo project

[Thierry Goubier]

2018-04-12 7:51 GMT+02:00 Ben Coman :
>
>
> On 12 April 2018 at 12:39, Thierry Goubier 
> wrote:
>>
>> Le 12/04/2018 à 03:54, Ben Coman a écrit :
>>>
>>>
>>> I was thinking that a smalltalk-implemented merge algorithm would only be
>>> used for the Smalltal/Tonel code,
>>> not for any other files.  And maybe, when a merge is invoked from
>>> Iceberg, the callback to the merge-driver
>>> might present conflicts in a GUI to be resolved, but I guess such would
>>> require a threaded-VM.
>>
>>
>> Two things then.
>>
>> - What happens if the C developer does a merge in a multi-language project
>> containing tonel files?
>>
>> - What is the difference with setting and provides a merge driver in Git,
>> which has the ability to work even without libcgit?
>
>
> I don't quite understand the question.  By "setting" do you mean in
> .gitattributes?

Yes.

> The same merge-algorithm could be invoked in two ways.
>
> The first would be "externally" from the shell,
> booting an Image to invoke the merge-algorithm
> with the files-to-process as arguments. This wouldn't need libgit.
> Conflicts could left marked in text files similar to exiting merge,
> or the running Image could present them in a GUI to resolve.
> A tool is required either way.
> I guess one of the existing options does this already?

Yes. The GitFileTree-MergeDriver works like that. It is a headless
image, now buildt out of the Pharo6 minimal image, and it is called by
git for specific file types.

What is missing is the GUI part, like a git merge-tool like meld can do.

> But I had imagined a problem(?) in an already running Image, with Iceberg
> doing a merge through libgit
> being able to invoke the merge driver in the already running Image.
> Now you've made me think it through more, I see some holes.
> Perhaps its okay to have two Images running by using the "external" way
> anyway;

Yes: in that case the merge driver is called in another process
anyway. Also, you want to reduce the overhead (make the pharo-based
merge driver as  fast as possible to start, because git will start it
for each file to merge). The nice thing with that setup is that the
common ancestor search is done by git.

> or the merge done purely "internally" before touching git, and just present
> the resultant "index" to libgit;

That one has the issue of having to deal with non-smalltalk files
(i.e. write a generic merge tool). If you restrict yourself to
smalltalk merges, then that can be fine (i.e. you merge with
Monticello, and the resulting package is stored as a merge in the git
store). But you reverse who is the master... in the later, smalltalk
is the master, and git store smalltalk results; in the merge driver,
git is the master, and smalltalk does what git requires.

But someone can still come from the outside of the repo and do a merge
on the command line; which is also fine.

> and my idea is not needed as a third way.
> Now I find I don't know the depths of the Pharo / libgit interface enough to
> speculate further here.

Yes, it seems that there are multiple ways to interface with it.

Thierry

> cheers -ben

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Alistair Grant]

Hi Sven,

On 11 April 2018 at 20:47, Sven Van Caekenberghe  wrote:
> Alistair,
>
>> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe  wrote:
>>
>> I will send you some code later on.
>
> Today I arranged for my NeoConsole code (that normally works over a network 
> connection) to work over stdio. Although I am not yet happy with every aspect 
> of the implementation, it does work (using unaltered Zn streams and code). 
> The foll
>
> $ cat /etc/issue
> Ubuntu 16.04.4 LTS
> $ mkdir pharo7
> $ cd pharo7/
> $ curl get.pharo.org/70+vm | bash
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 100  3036  100  30360 0  36799  0 --:--:-- --:--:-- --:--:-- 37024
> Downloading the latest 70 Image:
> http://files.pharo.org/get-files/70/pharo.zip
> Pharo.image
> Downloading the latest pharoVM:
> http://files.pharo.org/get-files/70/pharo-linux-stable.zip
> pharo-vm/pharo
> Creating starter scripts pharo and pharo-ui
> On a 64-bit system? You must enable and install the 32-bit libraries
>Please see http://pharo.org/gnu-linux-installation for detailed 
> instructions
> $ ./pharo Pharo.image config http://mc.stfx.eu/Neo ConfigurationOfNeoConsole 
> --install=bleedingEdge
> 'Installing ConfigurationOfNeoConsole bleedingEdge'
>
> Loading 1-baseline of ConfigurationOfNeoConsole...
> Fetched -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo 
> --- http://mc.stfx.eu/Neo
> Loaded -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo 
> --- cache
> ...finished 1-baseline
> $ ./pharo Pharo.image eval NeoConsoleStdio run
> Neo Console 
> Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a (32 
> Bit)
> pharo> 1+2
>
> 3
> pharo> 42 factorial
>
> 14050061177528798985431426062445115699363840
> pharo> Stdio stdin
>
> StdioStream: #stdin
> pharo> ==
> self: StdioStream: #stdin
> class: StdioStream
> file: a File
> handle: #[148 213 25 107 160 197 105 247 0 0 0 0 0 0 0 0 0 1 255 1]
> forWrite: false
> peekBuffer: nil
> pharo> show StdioStream>>#atEnd
> StdioStream>>#atEnd
> atEnd
>
> ^ file atEnd
> pharo> get process.list
> Morphic UI Process
> Delay Scheduling Process
> Low Space Watcher
> Input Event Fetcher Process
> Idle Process
> WeakArray Finalization Process
> CommandLine handler process
> pharo> quit
> Bye!
> a NeoConsoleStdio
>
> I know there are many approaches to a REPL, I don't claim mine is best, it is 
> just the one that I have been using for years.
>
> In the above, I do not depend on EOF - just to be clear. The point being that 
> there is no immediate fundamental problem.


Cool.  I've wanted to try NeoConsole for a while (I've got a Raspberry
Pi monitoring temperatures and wanted to use it to work on the Pi) but
hadn't made the time.

But... :-)


$ vm/pharo Pharo7.0-64bit-d2734dc.image eval NeoConsoleStdio run
Neo Console 
Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a
(64 Bit)
pharo> 4+3

7
pharo> [Ctrl-D]
MessageNotUnderstood: receiver of "<" is nil
UndefinedObject(Object)>>doesNotUnderstand: #<
ZnUTF8Encoder>>nextCodePointFromStream:
ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
ZnCharacterReadStream>>nextElement
ZnCharacterReadStream(ZnEncodedReadStream)>>next
[ :out |
| eol char |
eol := false.
[ eol ]
whileFalse: [ char := readStream next.
(char isNil or: [ char == lf ])
ifTrue: [ eol := true ]
ifFalse: [ char == cr
ifTrue: [ eol := true.
readStream peekFor: lf ]
ifFalse: [ out nextPut: char ] ] ] ] in ZnFastLineReader>>nextLine in
Block: [ :out | ...
ZnFastLineReader>>streamContents:
ZnFastLineReader>>nextLine
[ lineReader nextLine trimBoth ] in NeoConsoleStdio>>readInputFrom: in
Block: [ lineReader nextLine trimBoth ]
BlockClosure>>on:do:
NeoConsoleStdio>>readInputFrom:
NeoConsoleStdio>>executeRequestResponseLoop
NeoConsoleStdio>>run
NeoConsoleStdio class>>run
UndefinedObject>>DoIt


In your example you've carefully exited by some other means than
signalling end-of-file (Ctrl-D).

I don't think we can reasonably say "if you write code with Zinc
streams, ensure that none of your users ever press Ctrl-D, they must
always type 'quit' (or whatever)".



>
> But there is something wrong with what is returned by Stdio stdin

Right, that's the bug I was addressing stdio.cs.  I've got a note to
open an issue and submit a PR.

Cheers,
Alistair

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[K K Subbu]

On Wednesday 11 April 2018 10:38 PM, Alistair Grant wrote:

StandardFileStream>>readInto:startingAt:count: assumes that
primitiveFileRead will always attempt to read count bytes, but it
actually only attempts to read 1.


StandardFileStream>>#basicNext uses

  position < readLimit ifFalse:

and does not check if the primRead returns < 0. Instead it should call 
whileFalse: and check if primRead returns <= 0 to check for EOF or error.


#primRead:... returns an error if the primitive fails and the file is 
closed. It should instead check for EOF or error and then return -1, 
otherwise it should return 0 (Data not ready?). Raise an error only if 
the underlying primitive fails for non-EOF cases.


Regards .. Subbu

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[Alistair Grant]

On 11 April 2018 at 19:42, Nicolas Cellier
 wrote:
>
>
> 2018-04-11 19:08 GMT+02:00 Alistair Grant :
>>
>> Hi Sven,
>>
>> On 11 April 2018 at 18:53, Sven Van Caekenberghe  wrote:
>> > Something is off (and/or I am getting crazy, probably both).
>> >
>> > $ ./pharo --headless Pharo.image eval '(FileStream stdin binary; next:
>> > 3)'
>> > 123
>> > #[49]
>> >
>> > ??
>> >
>> > This should return #[49 50 51] AFAIK.
>>
>> I haven't checked properly, but I can take a guess at this...
>>
>> The file read primitive in FilePlugin tries to read from stdin 1
>> character at a time (presumably to get around the line buffering that
>> is done, but I haven't gone through the history.  At one time I think
>> it modified the terminal settings, but that code is #if'd out).  For
>> all other streams it attempts to read the requested number of
>> characters.
>>
>> StandardFileStream>>readInto:startingAt:count: assumes that
>> primitiveFileRead will always attempt to read count bytes, but it
>> actually only attempts to read 1.
>>
>> Cheers,
>> Alistair
>>
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/150

Thanks!  I'd already looked at this routine and found it strangely
constructed.  Having some background discussion will help a lot.

Cheers,
Alistair