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

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

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

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?

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;
or the merge done purely "internally" before touching git, and just present
the resultant "index" to libgit;
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.

cheers -ben

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

[Thierry Goubier]

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 developper 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?


Thierry



cheers -ben




...

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

[Ben Coman]

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.
cheers -ben

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

[Ben Coman]

On 12 April 2018 at 01:47, Thierry Goubier 
wrote:

> Hi Ben,
>
> Le 11/04/2018 à 16:37, Ben Coman a écrit :
>
>>
>>
>> On 11 April 2018 at 05:05, Esteban Lorenzano > > wrote:
>>
>> Hi,
>>
>> I’ve been wondering how to better fix the problem of having windows
>> and linux/macOS people contributing and the fact that files are
>> written in their native system format (crlf windows, lf for the rest
>> of the world).
>>
>>
>>
>> I digged a bit and I found a couple a link that helped me (after
>> trying to understand the doc):
>> https://stackoverflow.com/questions/170961/whats-the-best-
>> crlf-carriage-return-line-feed-handling-strategy-with-git
>> > crlf-carriage-return-line-feed-handling-strategy-with-git>
>>
>> and it seems adding a .gitattributes file with this content:
>>
>> # Auto detect text files and perform LF normalization
>> *text=auto
>>
>>
>> I see a few posts around that recommend reading
>> http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
>> which about the above line says... "This is certainly better than
>> requiring everyone to be on the same global setting for core.autocrlf, but
>> it means that you really trust Git to do binary detection properly. In my
>> opinion it is better to explicitly specify your text files that you want
>> normalized."
>>
>> and https://tinyurl.com/ya9xsprx  says "We had a repo with * text=auto,
>> and Git guessed wrong for an image file that it was a text file, causing it
>> to corrupt it as it replaced CR + LF bytes with LF bytes in the object
>> database."
>>
>> I'm unsure.  Without it the system is subject to different users'
>> different global settings
>> and I'd guess that may be a more frequent problem than Git guessing
>> wrong. The latter
>> can be fixed by a user adding an extra  .gitattributes  entry explicitly
>> specifying the file was binary,
>> whereas the former seems to introduce a confounding factor.
>> So probably a good line to have.
>>
>> *.sttext merge=union eol=lf
>>
>> could fix the problem?
>> can someone confirm this?
>>
>>
>> "eol=lf"   looks appropriate...
>> https://www.scivision.co/git-line-endings-windows-cygwin-wsl/
>>
>> Most editors on Windows transparently handle LF line endings.
>> https://en.wikipedia.org/wiki/Comparison_of_text_editors#Newline_support
>>
>>
>> " merge=union" I am not familiar with, but I read at...
>> https://git-scm.com/docs/gitattributes
>> "union = Run 3-way file level merge for text files, but take lines from
>> both versions, instead of leaving conflict markers.
>> This tends to leave the added lines in the resulting file in random**
>> order and the user should verify the result.
>> Do not use this if you do not understand the implications."
>>
>> What are the implications of lines being merged in a random order?
>>
>>
>> btw, has doing a callback from libgitto a custom merge driver in Pharo
>> been considered?
>> https://libgit2.github.com/libgit2/#HEAD/group/callback/git_
>> merge_driver_apply_fn
>>
>
> There is a merge driver for parts of the filetree format implemented with
> Pharo, it could be done on a more general basis if the Tonel format exhibit
> more conflicts than usual.
>
> But (and this is a big "but"), mixed Pharo / other things repositories
> with very large files to merge could make things very hard on a
> smalltalk-implemented merge algorithm.
>

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.

cheers -ben



> In most (all?) my professional work, this is the case. I have among my
> projects a mix FPGA design (verilog + vhdl) + C (drivers, runtime) +
> Smalltalk, and the smalltalk part is small.
>
> btw2, I found (https://githubengineering.com/move-fast/) interesting...
>> saying... "Despite being a C library, libgit2 contains many powerful
>> abstractions to accomplish complex tasks that Git simply cannot do. One of
>> these features are indexes that exist solely in memory and allow work-tree
>> related operations to be performed without an actual working directory.
>> [...]  With the in-memory index, libgit2 is capable of merging two trees in
>> a repository without having to check out any of their files on disk."
>>
>
> Yes, I considered that for GitFileTree. The current version uses
> fast-import and archive (resp. to write and read) and in truth could work
> on a bare repository, without working tree.
>
> Oh, by the way: it also solves the #lf issue, because you do everything
> the unix way, even on windows: GitFileTree now never touches a file of the
> host system.


>
> Thierry
>
>
>
>>
>> On 11 April 2018 at 05:55, Esteban Lorenzano> esteba...@gmail.com>>wr

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

[Eliot Miranda]

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 ;-)


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

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

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

[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] Why String do not implement #displayString?

[Aliaksei Syrel]

I had to read more carefully :) Yes, it should be true, but now it is
false, which is a problem.

Cheers,
Alex

On 11 April 2018 at 22:02, 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] Why String do not implement #displayString?

[Stephane Ducasse]

?


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] Why String do not implement #displayString?

[Aliaksei Syrel]

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] Why String do not implement #displayString?

[Stephane Ducasse]

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] Contribute a Fix and Reviewing changes

[Esteban Lorenzano]

tomorrow I will present it to the world ;)
and in theory it will be released, but today the CI was dead :( 

Esteban

> On 11 Apr 2018, at 21:29, Stephane Ducasse  wrote:
> 
> Hi nicolai
> 
> Keep pushing :) I succeeded to make it work and now I'm eager to use the new 
> UI 
> and refactored version. 
> 
> Stef
> 
> On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess  > wrote:
> Hi,
> 
> I tried to create a pull request with IceBerg.
> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.
> 
> But I must have done something wrong.
> This is my pull request:
> https://github.com/pharo-project/pharo/pull/1189 
> 
> But although I just changes one line in one method.
> The gitub pull request side shows 
> Commit 1 Files changed 40!
> But I did not change 40 files
> 
> 
> And I still have problems viewing pull requests from within pharo:
> 
> 
> 
> 
> 
> 
> I thought this would work meanwhil.
> 
> 
> Thanks in advance
> 
> nicolai
> 
> 

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

[Stephane Ducasse]

I did not know about the NeoConsole. Nice because I wanted to build a
little REPL for my minilanguage implementation.

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

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

[Stephane Ducasse]

On Wed, Apr 11, 2018 at 5:33 PM, Sven Van Caekenberghe  wrote:
> I think we have to reset this whole discussion.
>
>   FileStream stdin
>
> and
>
>   Stdio stdin
>
> are completely different !

Could you explain the difference because I'm dead tired and got confused :)

>
> We'll have to check that first, before talking about the issues raised in 
> this thread.
>
> And BTW these terminal streams are a real pain to test ;-)
>
>> On 11 Apr 2018, at 17:20, Sven Van Caekenberghe  wrote:
>>
>>
>>
>>> On 11 Apr 2018, at 17:16, Denis Kudriashov  wrote:
>>>
>>>
>>> 2018-04-11 17:02 GMT+02:00 Sven Van Caekenberghe :
>>>
>>>
 On 11 Apr 2018, at 16:36, Sven Van Caekenberghe  wrote:

 I can make your example, using the Zn variants, work with the following 
 change:

 StdioStream>>#atEnd
 ^ peekBuffer isNil or: [ (peekBuffer := self next) isNil ]
>>>
>>> Argh, make that
>>>
>>> atEnd
>>>  ^ peekBuffer isNil and: [ (peekBuffer := self next) isNil ]
>>>
>>> But discussion exactly about "self next isNil": how to avoid it.
>>
>> I know, but like this it could/might become an implementation detail.
>>
>> The more things that I try, the more that I feel that stdin is so special 
>> that it does not fit in the rest of the stream zoo.
>>
>>> but I am still testing, this is probably not the final answer/solution.
>>>
 Which is a literal implementation of your statement that you can only know 
 that you are atEnd by reading (and thus waiting/blocking) and checking for 
 nil, which seems logical to me, given the fact that you *are* waiting for 
 user input.

 BTW, at least on macOS you have to enter ctrl-D (^D) on a separate line, I 
 am not sure how relevant that is, but that is probably another argument 
 that stdin is special (being line-buffered by the OS, EOF needing to be on 
 a separate line).

 And FWIW, I have been writing networking code in Pharo for years, and I 
 have never had issues with unclear semantics of these primitives (#atEnd, 
 #next, #peek) on network streams, either the classic SocketStream or the 
 Zdc* streams (TLS or not). That is why I think we have to be careful.

 That being said, it is important to continue this discussion, I find it 
 very interesting. I am trying to write some test code using stdin myself, 
 to better understand the topic.

> On 11 Apr 2018, at 16:06, Alistair Grant  wrote:
>
> On 11 April 2018 at 15:11, Sven Van Caekenberghe  wrote:
>>
>>
>>> On 11 Apr 2018, at 11:12, Sven Van Caekenberghe  wrote:
>>>
>>> How does one modify #atEnd to block ? I suppose you are talking about 
>>> StdioStream>>#atEnd ?
>>>
>>> ^ self peek isNil
>>>
>>> ?
>>
>> Still the same question, how do you implement a blocking #atEnd for 
>> stdin ?
>>
>> I have seen your stdio.cs which is indeed needed as the current 
>> StdioStream>>#atEnd is bogus for sure.
>>
>> But that is still a non-blocking one, right ?
>>
>> Since there is a peekBuffer in StdioStream, why can't that be used ?
>
> I think you've created a chicken-and-egg problem with this question,
> but ignoring that for now:
>
>
> StdioStream>>peek
> "Answer what would be returned if the message next were sent to the
> receiver. If the receiver is at the end, answer nil.  "
>
>  self atEnd ifTrue: [^ nil ].
>
>  peekBuffer ifNotNil: [ ^ peekBuffer ].
>
>  ^ peekBuffer := self next.
>
>
>
> So when we first start the program, i.e. the user hasn't entered any
> input yet, and #peek is called:
>
> 1. #atEnd returns false because Ctrl-D (or similar) hasn't been
> entered (assuming it is non-blocking).
> 2. peekBuffer is nil because we haven't previously called #peek.
> 3. The system now blocks on "self next".
>
>
> Just a reminder: for terminal input the end-of-file isn't reached
> until the user explicitly enters the end of file key (Ctrl-D).
>
> So, if there is no buffered input (either none has been entered yet,
> or all input has been consumed)
>
> #atEnd (after the patch) calls #primAtEnd:.
>
> At the moment, #primAtEnd: ends up calling the libc function feof(),
> which is non-blocking and answers the end-of-file flag for the FILE*.
> Since the user hasn't entered Ctrl-D, that's false.
>
> If we want to control iteration over the stream and ensure that we
> don't need to do a "stream next == nil" check, then #primAtEnd: is
> going to have to peek for the next character, and that means waiting
> for the user to enter that character.
>
> In c that is typically done using:
>
> atEnd = ungetc(fgetc(fp), fp);
>
> and fgetc() will block until the user enters something.
>
>> I have run your example testAtEnd.st now, and it works/fails as 
>> advertised.
>
>>

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

[Stephane Ducasse]

On Wed, Apr 11, 2018 at 12:04 PM, Denis Kudriashov  wrote:
> Hi Alistair.
>
> I don't think anybody is annoyed by you. You are doing really good job. And
> nice thing that you are super patient to continue :)


+10

>
> What I try to understand is why blocking atEnd is bad?
> Here is code from VMMaker:
>
> [stdin atEnd] whileFalse:
> [| nextChunk |
> stdout nextPutAll: 'squeak> '; flush.
> nextChunk := stdin nextChunkNoTag.
> [nextChunk notEmpty and: [nextChunk first isSeparator]] whileTrue:
> [nextChunk := nextChunk allButFirst].
> Transcript cr; nextPutAll: nextChunk; cr; flush.
> [stdout print: (Compiler evaluate: nextChunk); cr; flush]
> on: Error
> do: [:ex| self logError: ex description inContext: ex signalerContext to:
> stderr]].
> quitOnEof ifTrue:
> [SourceFiles at: 2 put: nil.
> Smalltalk snapshot: false andQuit: true]
>
>
> I am not see why it breaks with blocking #atEnd. Can you explain?
>
> 2018-04-11 11:41 GMT+02:00 Alistair Grant :
>>
>> Hi Sven,
>>
>> Oh dear.  I feel as though I'm not getting my concerns across at all
>> well, and I'm pushing hard enough that all I'm going to do is make
>> people annoyed.  So let me try to restate the issue one last time
>> before answering your questions directly.
>>
>> Pharo & Squeak have unwritten rules about stream usage that I suspect
>> have just emerged over time without being designed.
>>
>> If you want to be able to iterate over any stream, and in particular
>> stdin from a terminal (which, as far as I know, is the outlier that
>> causes all the problems) you have to follow these rules:
>>
>> 1.  If the stream is character / byte oriented you have to check for
>> EOF using "stream next == nil".  #atEnd can be used, but you'll still
>> have to do the nil check.
>>
>> 2.  All other streams have to check for EOF (end of stream) using
>> #atEnd.  "stream next == nil" can be used, but you'll still need to
>> test #atEnd to determine whether nil is a value returned by the
>> stream.
>>
>> If you write code that you want to be able to consume characters,
>> bytes or any other object, you'll have to test both "stream next ==
>> nil" and #atEnd.
>>
>> The rules are the result of the original blue book design being that
>> #atEnd should be used, and then character input from a terminal being
>> added later, but always returning an EOF character (nil) before #atEnd
>> answers correctly.
>>
>> At the moment, ZnCharacterEncoder uses #atEnd on character / byte
>> streams, so fails for stdin on a terminal.
>>
>> Back to your questions:
>>
>> On 11 April 2018 at 11:12, Sven Van Caekenberghe  wrote:
>> >
>> >
>> >> On 11 Apr 2018, at 10:29, Alistair Grant  wrote:
>> >>
>> >> Hi Denis,
>> >>
>> >> On 11 April 2018 at 10:02, Denis Kudriashov 
>> >> wrote:
>> >>>
>> >>> 2018-04-11 8:32 GMT+02:00 Alistair Grant :
>> 
>> >>> Where is it being said that #next and/or #atEnd should be blocking
>> >>> or
>> >>> non-blocking ?
>> >>
>> >> There is existing code that assumes that #atEnd is non-blocking and
>> >> that #next is allowed block.  I believe that we should keep those
>> >> conditions.
>> >
>> > I fail to see where that is written down, either way. Can you point
>> > me
>> > to comments stating that, I would really like to know ?
>> 
>>  I'm not aware of it being written down, just that ever existing
>>  implementation I'm aware of behaves this way.
>> 
>>  On the other hand, making #atEnd blocking breaks Eliot's REPL sample
>>  (in Squeak).
>> >>>
>> >>>
>> >>> Could you write here this example, please?
>> >>
>> >> The code is loaded in squeak using:
>> >>
>> >>
>> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkreaderimage.sh
>> >>
>> >> for 32 bit images.  It loads:
>> >>
>> >>
>> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/LoadReader.st
>> >>
>> >> which loads package CogTools-Listener in
>> >> http://source.squeak.org/VMMaker
>> >>
>> >> An image that automatically runs the code and nothing else is created
>> >> in:
>> >>
>> >>
>> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/StartReader.st
>> >>
>> >>
>> >> If you want to run it interactively you can load CogTools-Listener and
>> >> do something like:
>> >>
>> >> StdioListener new
>> >>quitOnEof: false;
>> >>run
>> >
>> > What does #quitOnEof: do ? Can the StdioListener code be browsed/viewed
>> > online somewhere ?
>>
>> I just referenced this as an example of making #atEnd (really
>> FilePlugin>>primitiveFileAtEnd) blocking causing problems.  I wasn't
>> expecting people to go and look at the code or use it as a test.
>>
>> If you really want to look at it (from Pharo):
>>
>> 1. Add http://source.squeak.org/VMMaker as a repository.
>> 2. Browse the CogTools-Listener package
>>
>>
>> >> If you modify #atEnd to block it will result in the "squeak>" input
>> >> prompt being printed in the terminal after the input has been entered.
>> >
>> > How does

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

[Stephane Ducasse]

Hi nicolai

Keep pushing :) I succeeded to make it work and now I'm eager to use the
new UI
and refactored version.

Stef

On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess 
wrote:

> Hi,
>
> I tried to create a pull request with IceBerg.
> I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video.
>
> But I must have done something wrong.
> This is my pull request:
> https://github.com/pharo-project/pharo/pull/1189
> But although I just changes one line in one method.
> The gitub pull request side shows
> Commit 1 Files changed 40!
> But I did not change 40 files
>
>
> And I still have problems viewing pull requests from within pharo:
>
>
>
>
>
>
> I thought this would work meanwhil.
>
>
> Thanks in advance
>
> nicolai
>
>

Re: [Pharo-dev] call for help: answer on HN :)

[Stephane Ducasse]

Thanks Damien for the spoil :) I like when I can view that fast a video :)
I prefer coding.

On Tue, Apr 10, 2018 at 11:21 PM, Damien Pollet  wrote:
> There's a talk on the state of Clojure which I think resonates a lot with
> what we're experiencing in Pharo:
> https://www.youtube.com/watch?v=1YCkOo5Y4Oo
> Spoiler: he concludes it's better to contribute and discuss issues than to
> be all sad and bitter :-)
>
> On 10 April 2018 at 17:37, Sean P. DeNigris  wrote:
>>
>> philippeback wrote
>> > Who would have envisioned the Pharo of today in the beginning?
>> > I am thankful for Pharo, trolls be damned.
>>
>> Absolutely agree!!
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
>
>
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] [Pharo7] halt inside and outside tests

[Stephane Ducasse]

Thanks

On Tue, Apr 10, 2018 at 11:23 AM, Marcus Denker  wrote:
>
>
> On 5 Apr 2018, at 09:10, Marcus Denker  wrote:
>
>
>
> On 3 Apr 2018, at 21:56, Christophe Demarey 
> wrote:
>
> Nice addition!
> I should say that names are not really intention revealing.
> What about haltIfTestExecutionEnvironment and
> haltIfDefaultExecutionEnvironment ?
>
> To long and too implementation centered.
>
> I would even shorten it to haltIfTest and haltIfNotTest.
>
>
> https://github.com/pharo-project/pharo/pull/1187/files
>
> I simplified them further and added test (will be in the next build)
>
> Marcus

Re: [Pharo-dev] Did magritte change? Magritte-Morph-SeasnDeNigris.95 is not found

[Stephane Ducasse]

My roadmap is the following:
- release Pillar 70 alpha (we made really nice progress)
- work and release the tinyblog book
- then work on magritte
I will ping you when I arrive at this point.


On Mon, Apr 9, 2018 at 3:33 PM, Serge Stinckwich  wrote:

>
>
> On Mon, Apr 9, 2018 at 2:07 PM, Sean P. DeNigris 
> wrote:
>
>> Stephane Ducasse-3 wrote
>> > I will create one
>>
>> There is https://github.com/magritte-metamodel/magritte which I forked
>> from.
>> I wonder if we can make that canonical. It would be easy for me to sync my
>> changes back and from the README, it appears that most other Smalltalk
>> load
>> Magritte from elsewhere. Regarding Sqeak, there are the mcz repos, and
>> IFAICT Squeak has not shown much interest in git, so we're probably safe
>> there. Either way, please coordinate with me because the StHub repo is
>> wy behind my fork…
>>
>>
>
> ​Yes I guess, this is better to reuse existing org on github.
> Sean or me can invite people.
>
> ​Regards,​
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (SU/IRD/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."http://www.doesnotunderstand.org/
>

[Pharo-dev] What about removing forks in Monticello browser

[Stephane Ducasse]

Hi

I have the impression that the forks around the monticello browser
are introducing more mess than they solve.
Would not be good to remove such behavior?

Stef

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

[Sven Van Caekenberghe]

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

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

[Thierry Goubier]

Hi Ben,

Le 11/04/2018 à 16:37, Ben Coman a écrit :



On 11 April 2018 at 05:05, Esteban Lorenzano > wrote:


Hi,

I’ve been wondering how to better fix the problem of having windows
and linux/macOS people contributing and the fact that files are
written in their native system format (crlf windows, lf for the rest
of the world). 





I digged a bit and I found a couple a link that helped me (after
trying to understand the doc):

https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git



and it seems adding a .gitattributes file with this content:

# Auto detect text files and perform LF normalization
*text=auto


I see a few posts around that recommend reading 
http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
which about the above line says... "This is certainly better than 
requiring everyone to be on the same global setting for core.autocrlf, 
but it means that you really trust Git to do binary detection properly. 
In my opinion it is better to explicitly specify your text files that 
you want normalized."


and https://tinyurl.com/ya9xsprx  says "We had a repo with * text=auto, 
and Git guessed wrong for an image file that it was a text file, causing 
it to corrupt it as it replaced CR + LF bytes with LF bytes in the 
object database."


I'm unsure.  Without it the system is subject to different users' 
different global settings
and I'd guess that may be a more frequent problem than Git guessing 
wrong. The latter
can be fixed by a user adding an extra  .gitattributes  entry explicitly 
specifying the file was binary,

whereas the former seems to introduce a confounding factor.
So probably a good line to have.

*.sttext merge=union eol=lf

could fix the problem?
can someone confirm this?


"eol=lf"   looks appropriate...
https://www.scivision.co/git-line-endings-windows-cygwin-wsl/

Most editors on Windows transparently handle LF line endings.
https://en.wikipedia.org/wiki/Comparison_of_text_editors#Newline_support


" merge=union" I am not familiar with, but I read at... 
https://git-scm.com/docs/gitattributes
"union = Run 3-way file level merge for text files, but take lines from 
both versions, instead of leaving conflict markers.
This tends to leave the added lines in the resulting file in random** 
order and the user should verify the result.

Do not use this if you do not understand the implications."

What are the implications of lines being merged in a random order?


btw, has doing a callback from libgitto a custom merge driver in Pharo 
been considered?

https://libgit2.github.com/libgit2/#HEAD/group/callback/git_merge_driver_apply_fn


There is a merge driver for parts of the filetree format implemented 
with Pharo, it could be done on a more general basis if the Tonel format 
exhibit more conflicts than usual.


But (and this is a big "but"), mixed Pharo / other things repositories 
with very large files to merge could make things very hard on a 
smalltalk-implemented merge algorithm.


In most (all?) my professionnal work, this is the case. I have among my 
projects a mix FPGA design (verilog + vhdl) + C (drivers, runtime) + 
Smalltalk, and the smalltalk part is small.



btw2, I found (https://githubengineering.com/move-fast/) interesting...
saying... "Despite being a C library, libgit2 contains many powerful 
abstractions to accomplish complex tasks that Git simply cannot do. One 
of these features are indexes that exist solely in memory and allow 
work-tree related operations to be performed without an actual working 
directory. [...]  With the in-memory index, libgit2 is capable of 
merging two trees in a repository without having to check out any of 
their files on disk."


Yes, I considered that for GitFileTree. The current version uses 
fast-import and archive (resp. to write and read) and in truth could 
work on a bare repository, without working tree.


Oh, by the way: it also solves the #lf issue, because you do everything 
the unix way, even on windows: GitFileTree now never touches a file of 
the host system.


Thierry




On 11 April 2018 at 05:55, Esteban Lorenzano>wrote:


or a .iceberg file?

Esteban

ps: yep, we need it… we will have it, why not start now?


Do you mean Iceberg would clone a repo, and from its included  .iceberg  
file

a matching  .gitattributes  file would be created?
That seems like double handling.
Why not have the user edit the  .gitattributes  file directly from Iceberg?
Iceberg might provide some appropriate templates.


cheers -ben

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

[Nicolas Cellier]

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

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

[Sven Van Caekenberghe]

Hmm, but why does the following work then ?

$ ./pharo --headless Pharo.image eval '(FileStream stdin next: 3)'
123
'123'

The binary case is an error though, for sure.

And Zn character decoding works on binary streams, while the buffering streams 
read in blocks.

And it always comes back to 'stdin is handled specially', is that so in C, 
generally speaking ?

I am still digging though. I will send you some code later on.

> On 11 Apr 2018, at 19:08, Alistair Grant  wrote:
> 
> 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
> 

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

[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

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

[Sven Van Caekenberghe]

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.

> On 11 Apr 2018, at 18:26, Alistair Grant  wrote:
> 
> Hi Sven,
> 
> On 11 April 2018 at 17:33, Sven Van Caekenberghe  wrote:
>> I think we have to reset this whole discussion.
>> 
>>  FileStream stdin
>> 
>> and
>> 
>>  Stdio stdin
>> 
>> are completely different !
>> 
>> We'll have to check that first, before talking about the issues raised in 
>> this thread.
> 
> Are you sure you're comparing (roughly) equal things?
> 
> I would compare:
> 
> FileStream stdin
> 
> (very roughly) to:
> 
> ZnCharacterReadStream on:
>(ZnBufferedReadStream on:
>Stdio stdin).
> 
> Actually it is still not a fair comparison because MultiByteFileStream
> attempts to be writable as well.  If you could notionally do:
> 
> FileStream stdin
>  readOnly;
>  binary;
>  unbuffered;
>  yourself.
> 
> you could compare FileStream and Stdio :-)
> 
> One important similarity:  At the bottom they both use the same set of
> primitives to communicate with the OS stdio streams (FilePlugin).
> 
> HTH,
> Alistair
> 
> 
> 
>> And BTW these terminal streams are a real pain to test ;-)

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

[Alistair Grant]

Hi Sven,

On 11 April 2018 at 17:33, Sven Van Caekenberghe  wrote:
> I think we have to reset this whole discussion.
>
>   FileStream stdin
>
> and
>
>   Stdio stdin
>
> are completely different !
>
> We'll have to check that first, before talking about the issues raised in 
> this thread.

Are you sure you're comparing (roughly) equal things?

I would compare:

FileStream stdin

(very roughly) to:

ZnCharacterReadStream on:
(ZnBufferedReadStream on:
Stdio stdin).

Actually it is still not a fair comparison because MultiByteFileStream
attempts to be writable as well.  If you could notionally do:

FileStream stdin
  readOnly;
  binary;
  unbuffered;
  yourself.

you could compare FileStream and Stdio :-)

One important similarity:  At the bottom they both use the same set of
primitives to communicate with the OS stdio streams (FilePlugin).

HTH,
Alistair



> And BTW these terminal streams are a real pain to test ;-)

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

[Alistair Grant]

Hi Denis,

On 11 April 2018 at 17:16, Denis Kudriashov  wrote:
>
> 2018-04-11 17:02 GMT+02:00 Sven Van Caekenberghe :
>>
>>
>>
>> > On 11 Apr 2018, at 16:36, Sven Van Caekenberghe  wrote:
>> >
>> > I can make your example, using the Zn variants, work with the following
>> > change:
>> >
>> > StdioStream>>#atEnd
>> >  ^ peekBuffer isNil or: [ (peekBuffer := self next) isNil ]
>>
>> Argh, make that
>>
>> atEnd
>>   ^ peekBuffer isNil and: [ (peekBuffer := self next) isNil ]
>
>
> But discussion exactly about "self next isNil": how to avoid it.

Apologies in advance for being pedantic, but...

Do you really mean this (that the discussion is about how to avoid
testing "self next isNil")?

My argument has been that without making #atEnd blocking it is not
possible to avoid the test (and we don't want to make #atEnd
blocking).  All the existing stream code that deals with character /
byte streams does this test (see my "unwritten rules" from a previous
reply).  We don't want to make #atEnd blocking, so we need to keep the
test (and my personal opinion is that changing the Zinc streams to
adopt this approach does not add any significant architectural
complexity).

Assuming we reach agreement on the above, we do need to make the
"unwritten rules" written. If we reach a different agreement we should
document that.


Cheers,
Alistair

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

[Sven Van Caekenberghe]

I think we have to reset this whole discussion.

  FileStream stdin 

and

  Stdio stdin

are completely different !

We'll have to check that first, before talking about the issues raised in this 
thread.

And BTW these terminal streams are a real pain to test ;-)

> On 11 Apr 2018, at 17:20, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 11 Apr 2018, at 17:16, Denis Kudriashov  wrote:
>> 
>> 
>> 2018-04-11 17:02 GMT+02:00 Sven Van Caekenberghe :
>> 
>> 
>>> On 11 Apr 2018, at 16:36, Sven Van Caekenberghe  wrote:
>>> 
>>> I can make your example, using the Zn variants, work with the following 
>>> change:
>>> 
>>> StdioStream>>#atEnd
>>> ^ peekBuffer isNil or: [ (peekBuffer := self next) isNil ]
>> 
>> Argh, make that
>> 
>> atEnd
>>  ^ peekBuffer isNil and: [ (peekBuffer := self next) isNil ]
>> 
>> But discussion exactly about "self next isNil": how to avoid it.
> 
> I know, but like this it could/might become an implementation detail.
> 
> The more things that I try, the more that I feel that stdin is so special 
> that it does not fit in the rest of the stream zoo.
> 
>> but I am still testing, this is probably not the final answer/solution.
>> 
>>> Which is a literal implementation of your statement that you can only know 
>>> that you are atEnd by reading (and thus waiting/blocking) and checking for 
>>> nil, which seems logical to me, given the fact that you *are* waiting for 
>>> user input.
>>> 
>>> BTW, at least on macOS you have to enter ctrl-D (^D) on a separate line, I 
>>> am not sure how relevant that is, but that is probably another argument 
>>> that stdin is special (being line-buffered by the OS, EOF needing to be on 
>>> a separate line).
>>> 
>>> And FWIW, I have been writing networking code in Pharo for years, and I 
>>> have never had issues with unclear semantics of these primitives (#atEnd, 
>>> #next, #peek) on network streams, either the classic SocketStream or the 
>>> Zdc* streams (TLS or not). That is why I think we have to be careful.
>>> 
>>> That being said, it is important to continue this discussion, I find it 
>>> very interesting. I am trying to write some test code using stdin myself, 
>>> to better understand the topic.
>>> 
 On 11 Apr 2018, at 16:06, Alistair Grant  wrote:
 
 On 11 April 2018 at 15:11, Sven Van Caekenberghe  wrote:
> 
> 
>> On 11 Apr 2018, at 11:12, Sven Van Caekenberghe  wrote:
>> 
>> How does one modify #atEnd to block ? I suppose you are talking about 
>> StdioStream>>#atEnd ?
>> 
>> ^ self peek isNil
>> 
>> ?
> 
> Still the same question, how do you implement a blocking #atEnd for stdin 
> ?
> 
> I have seen your stdio.cs which is indeed needed as the current 
> StdioStream>>#atEnd is bogus for sure.
> 
> But that is still a non-blocking one, right ?
> 
> Since there is a peekBuffer in StdioStream, why can't that be used ?
 
 I think you've created a chicken-and-egg problem with this question,
 but ignoring that for now:
 
 
 StdioStream>>peek
 "Answer what would be returned if the message next were sent to the
 receiver. If the receiver is at the end, answer nil.  "
 
  self atEnd ifTrue: [^ nil ].
 
  peekBuffer ifNotNil: [ ^ peekBuffer ].
 
  ^ peekBuffer := self next.
 
 
 
 So when we first start the program, i.e. the user hasn't entered any
 input yet, and #peek is called:
 
 1. #atEnd returns false because Ctrl-D (or similar) hasn't been
 entered (assuming it is non-blocking).
 2. peekBuffer is nil because we haven't previously called #peek.
 3. The system now blocks on "self next".
 
 
 Just a reminder: for terminal input the end-of-file isn't reached
 until the user explicitly enters the end of file key (Ctrl-D).
 
 So, if there is no buffered input (either none has been entered yet,
 or all input has been consumed)
 
 #atEnd (after the patch) calls #primAtEnd:.
 
 At the moment, #primAtEnd: ends up calling the libc function feof(),
 which is non-blocking and answers the end-of-file flag for the FILE*.
 Since the user hasn't entered Ctrl-D, that's false.
 
 If we want to control iteration over the stream and ensure that we
 don't need to do a "stream next == nil" check, then #primAtEnd: is
 going to have to peek for the next character, and that means waiting
 for the user to enter that character.
 
 In c that is typically done using:
 
 atEnd = ungetc(fgetc(fp), fp);
 
 and fgetc() will block until the user enters something.
 
> I have run your example testAtEnd.st now, and it works/fails as 
> advertised.
 
 :-)
 
 
 Cheers,
 Alistair

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

[Sven Van Caekenberghe]

> On 11 Apr 2018, at 17:16, Denis Kudriashov  wrote:
> 
> 
> 2018-04-11 17:02 GMT+02:00 Sven Van Caekenberghe :
> 
> 
> > On 11 Apr 2018, at 16:36, Sven Van Caekenberghe  wrote:
> >
> > I can make your example, using the Zn variants, work with the following 
> > change:
> >
> > StdioStream>>#atEnd
> >  ^ peekBuffer isNil or: [ (peekBuffer := self next) isNil ]
> 
> Argh, make that
> 
> atEnd
>   ^ peekBuffer isNil and: [ (peekBuffer := self next) isNil ]
> 
> But discussion exactly about "self next isNil": how to avoid it.

I know, but like this it could/might become an implementation detail.

The more things that I try, the more that I feel that stdin is so special that 
it does not fit in the rest of the stream zoo.

> but I am still testing, this is probably not the final answer/solution.
> 
> > Which is a literal implementation of your statement that you can only know 
> > that you are atEnd by reading (and thus waiting/blocking) and checking for 
> > nil, which seems logical to me, given the fact that you *are* waiting for 
> > user input.
> >
> > BTW, at least on macOS you have to enter ctrl-D (^D) on a separate line, I 
> > am not sure how relevant that is, but that is probably another argument 
> > that stdin is special (being line-buffered by the OS, EOF needing to be on 
> > a separate line).
> >
> > And FWIW, I have been writing networking code in Pharo for years, and I 
> > have never had issues with unclear semantics of these primitives (#atEnd, 
> > #next, #peek) on network streams, either the classic SocketStream or the 
> > Zdc* streams (TLS or not). That is why I think we have to be careful.
> >
> > That being said, it is important to continue this discussion, I find it 
> > very interesting. I am trying to write some test code using stdin myself, 
> > to better understand the topic.
> >
> >> On 11 Apr 2018, at 16:06, Alistair Grant  wrote:
> >>
> >> On 11 April 2018 at 15:11, Sven Van Caekenberghe  wrote:
> >>>
> >>>
>  On 11 Apr 2018, at 11:12, Sven Van Caekenberghe  wrote:
> 
>  How does one modify #atEnd to block ? I suppose you are talking about 
>  StdioStream>>#atEnd ?
> 
>  ^ self peek isNil
> 
>  ?
> >>>
> >>> Still the same question, how do you implement a blocking #atEnd for stdin 
> >>> ?
> >>>
> >>> I have seen your stdio.cs which is indeed needed as the current 
> >>> StdioStream>>#atEnd is bogus for sure.
> >>>
> >>> But that is still a non-blocking one, right ?
> >>>
> >>> Since there is a peekBuffer in StdioStream, why can't that be used ?
> >>
> >> I think you've created a chicken-and-egg problem with this question,
> >> but ignoring that for now:
> >>
> >>
> >> StdioStream>>peek
> >> "Answer what would be returned if the message next were sent to the
> >> receiver. If the receiver is at the end, answer nil.  "
> >>
> >>   self atEnd ifTrue: [^ nil ].
> >>
> >>   peekBuffer ifNotNil: [ ^ peekBuffer ].
> >>
> >>   ^ peekBuffer := self next.
> >>
> >>
> >>
> >> So when we first start the program, i.e. the user hasn't entered any
> >> input yet, and #peek is called:
> >>
> >> 1. #atEnd returns false because Ctrl-D (or similar) hasn't been
> >> entered (assuming it is non-blocking).
> >> 2. peekBuffer is nil because we haven't previously called #peek.
> >> 3. The system now blocks on "self next".
> >>
> >>
> >> Just a reminder: for terminal input the end-of-file isn't reached
> >> until the user explicitly enters the end of file key (Ctrl-D).
> >>
> >> So, if there is no buffered input (either none has been entered yet,
> >> or all input has been consumed)
> >>
> >> #atEnd (after the patch) calls #primAtEnd:.
> >>
> >> At the moment, #primAtEnd: ends up calling the libc function feof(),
> >> which is non-blocking and answers the end-of-file flag for the FILE*.
> >> Since the user hasn't entered Ctrl-D, that's false.
> >>
> >> If we want to control iteration over the stream and ensure that we
> >> don't need to do a "stream next == nil" check, then #primAtEnd: is
> >> going to have to peek for the next character, and that means waiting
> >> for the user to enter that character.
> >>
> >> In c that is typically done using:
> >>
> >> atEnd = ungetc(fgetc(fp), fp);
> >>
> >> and fgetc() will block until the user enters something.
> >>
> >>> I have run your example testAtEnd.st now, and it works/fails as 
> >>> advertised.
> >>
> >> :-)
> >>
> >>
> >> Cheers,
> >> Alistair
> >

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

[Denis Kudriashov]

2018-04-11 17:02 GMT+02:00 Sven Van Caekenberghe :

>
>
> > On 11 Apr 2018, at 16:36, Sven Van Caekenberghe  wrote:
> >
> > I can make your example, using the Zn variants, work with the following
> change:
> >
> > StdioStream>>#atEnd
> >  ^ peekBuffer isNil or: [ (peekBuffer := self next) isNil ]
>
> Argh, make that
>
> atEnd
>   ^ peekBuffer isNil and: [ (peekBuffer := self next) isNil ]
>

But discussion exactly about "self next isNil": how to avoid it.


>
> but I am still testing, this is probably not the final answer/solution.
>
> > Which is a literal implementation of your statement that you can only
> know that you are atEnd by reading (and thus waiting/blocking) and checking
> for nil, which seems logical to me, given the fact that you *are* waiting
> for user input.
> >
> > BTW, at least on macOS you have to enter ctrl-D (^D) on a separate line,
> I am not sure how relevant that is, but that is probably another argument
> that stdin is special (being line-buffered by the OS, EOF needing to be on
> a separate line).
> >
> > And FWIW, I have been writing networking code in Pharo for years, and I
> have never had issues with unclear semantics of these primitives (#atEnd,
> #next, #peek) on network streams, either the classic SocketStream or the
> Zdc* streams (TLS or not). That is why I think we have to be careful.
> >
> > That being said, it is important to continue this discussion, I find it
> very interesting. I am trying to write some test code using stdin myself,
> to better understand the topic.
> >
> >> On 11 Apr 2018, at 16:06, Alistair Grant  wrote:
> >>
> >> On 11 April 2018 at 15:11, Sven Van Caekenberghe  wrote:
> >>>
> >>>
>  On 11 Apr 2018, at 11:12, Sven Van Caekenberghe  wrote:
> 
>  How does one modify #atEnd to block ? I suppose you are talking about
> StdioStream>>#atEnd ?
> 
>  ^ self peek isNil
> 
>  ?
> >>>
> >>> Still the same question, how do you implement a blocking #atEnd for
> stdin ?
> >>>
> >>> I have seen your stdio.cs which is indeed needed as the current
> StdioStream>>#atEnd is bogus for sure.
> >>>
> >>> But that is still a non-blocking one, right ?
> >>>
> >>> Since there is a peekBuffer in StdioStream, why can't that be used ?
> >>
> >> I think you've created a chicken-and-egg problem with this question,
> >> but ignoring that for now:
> >>
> >>
> >> StdioStream>>peek
> >> "Answer what would be returned if the message next were sent to the
> >> receiver. If the receiver is at the end, answer nil.  "
> >>
> >>   self atEnd ifTrue: [^ nil ].
> >>
> >>   peekBuffer ifNotNil: [ ^ peekBuffer ].
> >>
> >>   ^ peekBuffer := self next.
> >>
> >>
> >>
> >> So when we first start the program, i.e. the user hasn't entered any
> >> input yet, and #peek is called:
> >>
> >> 1. #atEnd returns false because Ctrl-D (or similar) hasn't been
> >> entered (assuming it is non-blocking).
> >> 2. peekBuffer is nil because we haven't previously called #peek.
> >> 3. The system now blocks on "self next".
> >>
> >>
> >> Just a reminder: for terminal input the end-of-file isn't reached
> >> until the user explicitly enters the end of file key (Ctrl-D).
> >>
> >> So, if there is no buffered input (either none has been entered yet,
> >> or all input has been consumed)
> >>
> >> #atEnd (after the patch) calls #primAtEnd:.
> >>
> >> At the moment, #primAtEnd: ends up calling the libc function feof(),
> >> which is non-blocking and answers the end-of-file flag for the FILE*.
> >> Since the user hasn't entered Ctrl-D, that's false.
> >>
> >> If we want to control iteration over the stream and ensure that we
> >> don't need to do a "stream next == nil" check, then #primAtEnd: is
> >> going to have to peek for the next character, and that means waiting
> >> for the user to enter that character.
> >>
> >> In c that is typically done using:
> >>
> >> atEnd = ungetc(fgetc(fp), fp);
> >>
> >> and fgetc() will block until the user enters something.
> >>
> >>> I have run your example testAtEnd.st now, and it works/fails as
> advertised.
> >>
> >> :-)
> >>
> >>
> >> Cheers,
> >> Alistair
> >
>
>
>

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

[Sven Van Caekenberghe]

> On 11 Apr 2018, at 16:36, Sven Van Caekenberghe  wrote:
> 
> I can make your example, using the Zn variants, work with the following 
> change:
> 
> StdioStream>>#atEnd
>  ^ peekBuffer isNil or: [ (peekBuffer := self next) isNil ]

Argh, make that

atEnd
  ^ peekBuffer isNil and: [ (peekBuffer := self next) isNil ]

but I am still testing, this is probably not the final answer/solution.

> Which is a literal implementation of your statement that you can only know 
> that you are atEnd by reading (and thus waiting/blocking) and checking for 
> nil, which seems logical to me, given the fact that you *are* waiting for 
> user input.
> 
> BTW, at least on macOS you have to enter ctrl-D (^D) on a separate line, I am 
> not sure how relevant that is, but that is probably another argument that 
> stdin is special (being line-buffered by the OS, EOF needing to be on a 
> separate line).
> 
> And FWIW, I have been writing networking code in Pharo for years, and I have 
> never had issues with unclear semantics of these primitives (#atEnd, #next, 
> #peek) on network streams, either the classic SocketStream or the Zdc* 
> streams (TLS or not). That is why I think we have to be careful.
> 
> That being said, it is important to continue this discussion, I find it very 
> interesting. I am trying to write some test code using stdin myself, to 
> better understand the topic.
> 
>> On 11 Apr 2018, at 16:06, Alistair Grant  wrote:
>> 
>> On 11 April 2018 at 15:11, Sven Van Caekenberghe  wrote:
>>> 
>>> 
 On 11 Apr 2018, at 11:12, Sven Van Caekenberghe  wrote:
 
 How does one modify #atEnd to block ? I suppose you are talking about 
 StdioStream>>#atEnd ?
 
 ^ self peek isNil
 
 ?
>>> 
>>> Still the same question, how do you implement a blocking #atEnd for stdin ?
>>> 
>>> I have seen your stdio.cs which is indeed needed as the current 
>>> StdioStream>>#atEnd is bogus for sure.
>>> 
>>> But that is still a non-blocking one, right ?
>>> 
>>> Since there is a peekBuffer in StdioStream, why can't that be used ?
>> 
>> I think you've created a chicken-and-egg problem with this question,
>> but ignoring that for now:
>> 
>> 
>> StdioStream>>peek
>> "Answer what would be returned if the message next were sent to the
>> receiver. If the receiver is at the end, answer nil.  "
>> 
>>   self atEnd ifTrue: [^ nil ].
>> 
>>   peekBuffer ifNotNil: [ ^ peekBuffer ].
>> 
>>   ^ peekBuffer := self next.
>> 
>> 
>> 
>> So when we first start the program, i.e. the user hasn't entered any
>> input yet, and #peek is called:
>> 
>> 1. #atEnd returns false because Ctrl-D (or similar) hasn't been
>> entered (assuming it is non-blocking).
>> 2. peekBuffer is nil because we haven't previously called #peek.
>> 3. The system now blocks on "self next".
>> 
>> 
>> Just a reminder: for terminal input the end-of-file isn't reached
>> until the user explicitly enters the end of file key (Ctrl-D).
>> 
>> So, if there is no buffered input (either none has been entered yet,
>> or all input has been consumed)
>> 
>> #atEnd (after the patch) calls #primAtEnd:.
>> 
>> At the moment, #primAtEnd: ends up calling the libc function feof(),
>> which is non-blocking and answers the end-of-file flag for the FILE*.
>> Since the user hasn't entered Ctrl-D, that's false.
>> 
>> If we want to control iteration over the stream and ensure that we
>> don't need to do a "stream next == nil" check, then #primAtEnd: is
>> going to have to peek for the next character, and that means waiting
>> for the user to enter that character.
>> 
>> In c that is typically done using:
>> 
>> atEnd = ungetc(fgetc(fp), fp);
>> 
>> and fgetc() will block until the user enters something.
>> 
>>> I have run your example testAtEnd.st now, and it works/fails as advertised.
>> 
>> :-)
>> 
>> 
>> Cheers,
>> Alistair
> 

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

[Ben Coman]

On 11 April 2018 at 05:05, Esteban Lorenzano  wrote:

> Hi,
>
> I’ve been wondering how to better fix the problem of having windows and
> linux/macOS people contributing and the fact that files are written in
> their native system format (crlf windows, lf for the rest of the world).
>




>
> I digged a bit and I found a couple a link that helped me (after trying to
> understand the doc): https://stackoverflow.com/questions/170961/whats-
> the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
>
> and it seems adding a .gitattributes file with this content:
>
> # Auto detect text files and perform LF normalization
> * text=auto
>

I see a few posts around that recommend reading
http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
which about the above line says... "This is certainly better than requiring
everyone to be on the same global setting for core.autocrlf, but it means
that you really trust Git to do binary detection properly. In my opinion it
is better to explicitly specify your text files that you want normalized."

and  https://tinyurl.com/ya9xsprx  says "We had a repo with * text=auto,
and Git guessed wrong for an image file that it was a text file, causing it
to corrupt it as it replaced CR + LF bytes with LF bytes in the object
database."

I'm unsure.  Without it the system is subject to different users' different
global settings
and I'd guess that may be a more frequent problem than Git guessing
wrong. The latter
can be fixed by a user adding an extra  .gitattributes  entry explicitly
specifying the file was binary,
whereas the former seems to introduce a confounding factor.
So probably a good line to have.



> *.st text merge=union eol=lf
>
> could fix the problem?
> can someone confirm this?
>

"eol=lf"   looks appropriate...
https://www.scivision.co/git-line-endings-windows-cygwin-wsl/

Most editors on Windows transparently handle LF line endings.
https://en.wikipedia.org/wiki/Comparison_of_text_editors#Newline_support


" merge=union" I am not familiar with, but I read at...
https://git-scm.com/docs/gitattributes
"union = Run 3-way file level merge for text files, but take lines from
both versions, instead of leaving conflict markers.
This tends to leave the added lines in the resulting file in random** order
and the user should verify the result.
Do not use this if you do not understand the implications."

What are the implications of lines being merged in a random order?


btw, has doing a callback from libgit to a custom merge driver in Pharo
been considered?
https://libgit2.github.com/libgit2/#HEAD/group/callback/git_merge_driver_apply_fn

btw2, I found (https://githubengineering.com/move-fast/) interesting...
saying... "Despite being a C library, libgit2 contains many powerful
abstractions to accomplish complex tasks that Git simply cannot do. One of
these features are indexes that exist solely in memory and allow work-tree
related operations to be performed without an actual working directory.
[...]  With the in-memory index, libgit2 is capable of merging two trees in
a repository without having to check out any of their files on disk."



On 11 April 2018 at 05:55, Esteban Lorenzano  wrote:

> or a .iceberg file?
>
> Esteban
>
> ps: yep, we need it… we will have it, why not start now?
>

Do you mean Iceberg would clone a repo, and from its included  .iceberg
file
a matching  .gitattributes  file would be created?
That seems like double handling.
Why not have the user edit the  .gitattributes  file directly from Iceberg?
Iceberg might provide some appropriate templates.


cheers -ben

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

[Sven Van Caekenberghe]

I can make your example, using the Zn variants, work with the following change:

StdioStream>>#atEnd
  ^ peekBuffer isNil or: [ (peekBuffer := self next) isNil ]

Which is a literal implementation of your statement that you can only know that 
you are atEnd by reading (and thus waiting/blocking) and checking for nil, 
which seems logical to me, given the fact that you *are* waiting for user input.

BTW, at least on macOS you have to enter ctrl-D (^D) on a separate line, I am 
not sure how relevant that is, but that is probably another argument that stdin 
is special (being line-buffered by the OS, EOF needing to be on a separate 
line).

And FWIW, I have been writing networking code in Pharo for years, and I have 
never had issues with unclear semantics of these primitives (#atEnd, #next, 
#peek) on network streams, either the classic SocketStream or the Zdc* streams 
(TLS or not). That is why I think we have to be careful.

That being said, it is important to continue this discussion, I find it very 
interesting. I am trying to write some test code using stdin myself, to better 
understand the topic.

> On 11 Apr 2018, at 16:06, Alistair Grant  wrote:
> 
> On 11 April 2018 at 15:11, Sven Van Caekenberghe  wrote:
>> 
>> 
>>> On 11 Apr 2018, at 11:12, Sven Van Caekenberghe  wrote:
>>> 
>>> How does one modify #atEnd to block ? I suppose you are talking about 
>>> StdioStream>>#atEnd ?
>>> 
>>> ^ self peek isNil
>>> 
>>> ?
>> 
>> Still the same question, how do you implement a blocking #atEnd for stdin ?
>> 
>> I have seen your stdio.cs which is indeed needed as the current 
>> StdioStream>>#atEnd is bogus for sure.
>> 
>> But that is still a non-blocking one, right ?
>> 
>> Since there is a peekBuffer in StdioStream, why can't that be used ?
> 
> I think you've created a chicken-and-egg problem with this question,
> but ignoring that for now:
> 
> 
> StdioStream>>peek
> "Answer what would be returned if the message next were sent to the
> receiver. If the receiver is at the end, answer nil.  "
> 
>self atEnd ifTrue: [^ nil ].
> 
>peekBuffer ifNotNil: [ ^ peekBuffer ].
> 
>^ peekBuffer := self next.
> 
> 
> 
> So when we first start the program, i.e. the user hasn't entered any
> input yet, and #peek is called:
> 
> 1. #atEnd returns false because Ctrl-D (or similar) hasn't been
> entered (assuming it is non-blocking).
> 2. peekBuffer is nil because we haven't previously called #peek.
> 3. The system now blocks on "self next".
> 
> 
> Just a reminder: for terminal input the end-of-file isn't reached
> until the user explicitly enters the end of file key (Ctrl-D).
> 
> So, if there is no buffered input (either none has been entered yet,
> or all input has been consumed)
> 
> #atEnd (after the patch) calls #primAtEnd:.
> 
> At the moment, #primAtEnd: ends up calling the libc function feof(),
> which is non-blocking and answers the end-of-file flag for the FILE*.
> Since the user hasn't entered Ctrl-D, that's false.
> 
> If we want to control iteration over the stream and ensure that we
> don't need to do a "stream next == nil" check, then #primAtEnd: is
> going to have to peek for the next character, and that means waiting
> for the user to enter that character.
> 
> In c that is typically done using:
> 
> atEnd = ungetc(fgetc(fp), fp);
> 
> and fgetc() will block until the user enters something.
> 
>> I have run your example testAtEnd.st now, and it works/fails as advertised.
> 
> :-)
> 
> 
> Cheers,
> Alistair

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

[Alistair Grant]

On 11 April 2018 at 15:11, Sven Van Caekenberghe  wrote:
>
>
>> On 11 Apr 2018, at 11:12, Sven Van Caekenberghe  wrote:
>>
>> How does one modify #atEnd to block ? I suppose you are talking about 
>> StdioStream>>#atEnd ?
>>
>> ^ self peek isNil
>>
>> ?
>
> Still the same question, how do you implement a blocking #atEnd for stdin ?
>
> I have seen your stdio.cs which is indeed needed as the current 
> StdioStream>>#atEnd is bogus for sure.
>
> But that is still a non-blocking one, right ?
>
> Since there is a peekBuffer in StdioStream, why can't that be used ?

I think you've created a chicken-and-egg problem with this question,
but ignoring that for now:


StdioStream>>peek
"Answer what would be returned if the message next were sent to the
receiver. If the receiver is at the end, answer nil.  "

self atEnd ifTrue: [^ nil ].

peekBuffer ifNotNil: [ ^ peekBuffer ].

^ peekBuffer := self next.



So when we first start the program, i.e. the user hasn't entered any
input yet, and #peek is called:

1. #atEnd returns false because Ctrl-D (or similar) hasn't been
entered (assuming it is non-blocking).
2. peekBuffer is nil because we haven't previously called #peek.
3. The system now blocks on "self next".


Just a reminder: for terminal input the end-of-file isn't reached
until the user explicitly enters the end of file key (Ctrl-D).

So, if there is no buffered input (either none has been entered yet,
or all input has been consumed)

#atEnd (after the patch) calls #primAtEnd:.

At the moment, #primAtEnd: ends up calling the libc function feof(),
which is non-blocking and answers the end-of-file flag for the FILE*.
Since the user hasn't entered Ctrl-D, that's false.

If we want to control iteration over the stream and ensure that we
don't need to do a "stream next == nil" check, then #primAtEnd: is
going to have to peek for the next character, and that means waiting
for the user to enter that character.

In c that is typically done using:

atEnd = ungetc(fgetc(fp), fp);

and fgetc() will block until the user enters something.

> I have run your example testAtEnd.st now, and it works/fails as advertised.

:-)


Cheers,
Alistair

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

[David T. Lewis]

OS pipes are a similar case. On Pharo, you can run CommandShellTestCase to
provide some test coverage for this.

Dave

On Wed, Apr 11, 2018 at 03:13:35PM +0200, Denis Kudriashov wrote:
> Thanks for explanation.
> 
> I think it would be same scenario for socket stream where #atEnd is not
> blocking. So I agree that it is expected behaviour.
> 
> The example is general enough to expect it to be working for any given pair
> of in and out streams. So our streams should support this.
> 
> 
> 2018-04-11 14:56 GMT+02:00 Alistair Grant :
> 
> > Hi Sven & Dennis,
> >
> > On 11 April 2018 at 12:04, Denis Kudriashov  wrote:
> > > Hi Alistair.
> > >
> > > I don't think anybody is annoyed by you. You are doing really good job.
> > And
> > > nice thing that you are super patient to continue :)
> > >
> >
> > On 11 April 2018 at 12:13, Sven Van Caekenberghe  wrote:
> > >
> > > Yes, Alistair, you are a top notch open source contributor !
> > >
> > > For me, this discussion is about the difference between looking from low
> > level details/issues/changes up, vs, from a higher level down.
> >
> > Thanks for your kind words.
> >
> >
> >
> > > What I try to understand is why blocking atEnd is bad?
> > > Here is code from VMMaker:
> > >
> > > [stdin atEnd] whileFalse:
> > > [| nextChunk |
> > > stdout nextPutAll: 'squeak> '; flush.
> > > nextChunk := stdin nextChunkNoTag.
> > > [nextChunk notEmpty and: [nextChunk first isSeparator]] whileTrue:
> > > [nextChunk := nextChunk allButFirst].
> > > Transcript cr; nextPutAll: nextChunk; cr; flush.
> > > [stdout print: (Compiler evaluate: nextChunk); cr; flush]
> > > on: Error
> > > do: [:ex| self logError: ex description inContext: ex signalerContext to:
> > > stderr]].
> > > quitOnEof ifTrue:
> > > [SourceFiles at: 2 put: nil.
> > > Smalltalk snapshot: false andQuit: true]
> > >
> > >
> > > I am not see why it breaks with blocking #atEnd. Can you explain?
> >
> >
> > First consider the case where #atEnd doesn't block and we just want to
> > evaluate 4+3:
> >
> > 1. #atEnd will return false
> > 2. the loop will print the prompt
> > 3. wait for input (stdin nextChunkNoTag)
> > 4. print the result
> > 5. goto 1.
> >
> > So the screen will look like:
> >
> > squeak> 4+3!
> > 7
> > squeak> [cursor here]
> >
> > Which is what we expect (prompt, input, result, prompt).
> >
> > If #atEnd is blocking the VM will hang at step 1 until the user enters
> > something in the terminal.  In Ubuntu at least terminal input appears to
> > be line buffered, so for the example above the terminal will look like:
> >
> > 4+3!
> > squeak> 7
> > [cursor here]
> >
> > We don't get the prompt when the program is started, the result is
> > printed after the prompt, and then there's just a cursor sitting at the
> > start of the next line.
> >
> > Obviously the program could be re-written to have the correct output
> > with #atEnd blocking.  But I'm arguing that this program is
> > representative of many others, and we don't want to break backward
> > compatibility in this case.
> >
> > Cheers,
> > Alistair
> >
> >
> >
> >
> >
> >
> >
> >
> > > 2018-04-11 11:41 GMT+02:00 Alistair Grant :
> > >>
> > >> Hi Sven,
> > >>
> > >> Oh dear.  I feel as though I'm not getting my concerns across at all
> > >> well, and I'm pushing hard enough that all I'm going to do is make
> > >> people annoyed.  So let me try to restate the issue one last time
> > >> before answering your questions directly.
> > >>
> > >> Pharo & Squeak have unwritten rules about stream usage that I suspect
> > >> have just emerged over time without being designed.
> > >>
> > >> If you want to be able to iterate over any stream, and in particular
> > >> stdin from a terminal (which, as far as I know, is the outlier that
> > >> causes all the problems) you have to follow these rules:
> > >>
> > >> 1.  If the stream is character / byte oriented you have to check for
> > >> EOF using "stream next == nil".  #atEnd can be used, but you'll still
> > >> have to do the nil check.
> > >>
> > >> 2.  All other streams have to check for EOF (end of stream) using
> > >> #atEnd.  "stream next == nil" can be used, but you'll still need to
> > >> test #atEnd to determine whether nil is a value returned by the
> > >> stream.
> > >>
> > >> If you write code that you want to be able to consume characters,
> > >> bytes or any other object, you'll have to test both "stream next ==
> > >> nil" and #atEnd.
> > >>
> > >> The rules are the result of the original blue book design being that
> > >> #atEnd should be used, and then character input from a terminal being
> > >> added later, but always returning an EOF character (nil) before #atEnd
> > >> answers correctly.
> > >>
> > >> At the moment, ZnCharacterEncoder uses #atEnd on character / byte
> > >> streams, so fails for stdin on a terminal.
> > >>
> > >> Back to your questions:
> > >>
> > >> On 11 April 2018 at 11:12, Sven Van Caekenberghe  wrote:
> > >> >
> > >> >
> > >> >> On 11 Apr 2018, at 10:29, Alistair Grant 
> > wrote

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

[Nicolas Cellier]

Hi Alistair,
I must take my part too: I suggested that we could use a pair of
getc/ungetc to know if we are atEnd(OfData), but this obviously works well
with AsyncFileIO only, else it blocks.
For files, this generally isn't a problem (but maybe for network mounted
partitions), the latency is bearable, but for sockets and pipes, that is
not the right thing.

2018-04-11 14:56 GMT+02:00 Alistair Grant :

> Hi Sven & Dennis,
>
> On 11 April 2018 at 12:04, Denis Kudriashov  wrote:
> > Hi Alistair.
> >
> > I don't think anybody is annoyed by you. You are doing really good job.
> And
> > nice thing that you are super patient to continue :)
> >
>
> On 11 April 2018 at 12:13, Sven Van Caekenberghe  wrote:
> >
> > Yes, Alistair, you are a top notch open source contributor !
> >
> > For me, this discussion is about the difference between looking from low
> level details/issues/changes up, vs, from a higher level down.
>
> Thanks for your kind words.
>
>
>
> > What I try to understand is why blocking atEnd is bad?
> > Here is code from VMMaker:
> >
> > [stdin atEnd] whileFalse:
> > [| nextChunk |
> > stdout nextPutAll: 'squeak> '; flush.
> > nextChunk := stdin nextChunkNoTag.
> > [nextChunk notEmpty and: [nextChunk first isSeparator]] whileTrue:
> > [nextChunk := nextChunk allButFirst].
> > Transcript cr; nextPutAll: nextChunk; cr; flush.
> > [stdout print: (Compiler evaluate: nextChunk); cr; flush]
> > on: Error
> > do: [:ex| self logError: ex description inContext: ex signalerContext to:
> > stderr]].
> > quitOnEof ifTrue:
> > [SourceFiles at: 2 put: nil.
> > Smalltalk snapshot: false andQuit: true]
> >
> >
> > I am not see why it breaks with blocking #atEnd. Can you explain?
>
>
> First consider the case where #atEnd doesn't block and we just want to
> evaluate 4+3:
>
> 1. #atEnd will return false
> 2. the loop will print the prompt
> 3. wait for input (stdin nextChunkNoTag)
> 4. print the result
> 5. goto 1.
>
> So the screen will look like:
>
> squeak> 4+3!
> 7
> squeak> [cursor here]
>
> Which is what we expect (prompt, input, result, prompt).
>
> If #atEnd is blocking the VM will hang at step 1 until the user enters
> something in the terminal.  In Ubuntu at least terminal input appears to
> be line buffered, so for the example above the terminal will look like:
>
> 4+3!
> squeak> 7
> [cursor here]
>
> We don't get the prompt when the program is started, the result is
> printed after the prompt, and then there's just a cursor sitting at the
> start of the next line.
>
> Obviously the program could be re-written to have the correct output
> with #atEnd blocking.  But I'm arguing that this program is
> representative of many others, and we don't want to break backward
> compatibility in this case.
>
> Cheers,
> Alistair
>
>
>
>
>
>
>
>
> > 2018-04-11 11:41 GMT+02:00 Alistair Grant :
> >>
> >> Hi Sven,
> >>
> >> Oh dear.  I feel as though I'm not getting my concerns across at all
> >> well, and I'm pushing hard enough that all I'm going to do is make
> >> people annoyed.  So let me try to restate the issue one last time
> >> before answering your questions directly.
> >>
> >> Pharo & Squeak have unwritten rules about stream usage that I suspect
> >> have just emerged over time without being designed.
> >>
> >> If you want to be able to iterate over any stream, and in particular
> >> stdin from a terminal (which, as far as I know, is the outlier that
> >> causes all the problems) you have to follow these rules:
> >>
> >> 1.  If the stream is character / byte oriented you have to check for
> >> EOF using "stream next == nil".  #atEnd can be used, but you'll still
> >> have to do the nil check.
> >>
> >> 2.  All other streams have to check for EOF (end of stream) using
> >> #atEnd.  "stream next == nil" can be used, but you'll still need to
> >> test #atEnd to determine whether nil is a value returned by the
> >> stream.
> >>
> >> If you write code that you want to be able to consume characters,
> >> bytes or any other object, you'll have to test both "stream next ==
> >> nil" and #atEnd.
> >>
> >> The rules are the result of the original blue book design being that
> >> #atEnd should be used, and then character input from a terminal being
> >> added later, but always returning an EOF character (nil) before #atEnd
> >> answers correctly.
> >>
> >> At the moment, ZnCharacterEncoder uses #atEnd on character / byte
> >> streams, so fails for stdin on a terminal.
> >>
> >> Back to your questions:
> >>
> >> On 11 April 2018 at 11:12, Sven Van Caekenberghe  wrote:
> >> >
> >> >
> >> >> On 11 Apr 2018, at 10:29, Alistair Grant 
> wrote:
> >> >>
> >> >> Hi Denis,
> >> >>
> >> >> On 11 April 2018 at 10:02, Denis Kudriashov 
> >> >> wrote:
> >> >>>
> >> >>> 2018-04-11 8:32 GMT+02:00 Alistair Grant :
> >> 
> >> >>> Where is it being said that #next and/or #atEnd should be
> blocking
> >> >>> or
> >> >>> non-blocking ?
> >> >>
> >> >> There is existing code that assumes that #atEnd is non-blocking
> and
>

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

[Denis Kudriashov]

Thanks for explanation.

I think it would be same scenario for socket stream where #atEnd is not
blocking. So I agree that it is expected behaviour.

The example is general enough to expect it to be working for any given pair
of in and out streams. So our streams should support this.


2018-04-11 14:56 GMT+02:00 Alistair Grant :

> Hi Sven & Dennis,
>
> On 11 April 2018 at 12:04, Denis Kudriashov  wrote:
> > Hi Alistair.
> >
> > I don't think anybody is annoyed by you. You are doing really good job.
> And
> > nice thing that you are super patient to continue :)
> >
>
> On 11 April 2018 at 12:13, Sven Van Caekenberghe  wrote:
> >
> > Yes, Alistair, you are a top notch open source contributor !
> >
> > For me, this discussion is about the difference between looking from low
> level details/issues/changes up, vs, from a higher level down.
>
> Thanks for your kind words.
>
>
>
> > What I try to understand is why blocking atEnd is bad?
> > Here is code from VMMaker:
> >
> > [stdin atEnd] whileFalse:
> > [| nextChunk |
> > stdout nextPutAll: 'squeak> '; flush.
> > nextChunk := stdin nextChunkNoTag.
> > [nextChunk notEmpty and: [nextChunk first isSeparator]] whileTrue:
> > [nextChunk := nextChunk allButFirst].
> > Transcript cr; nextPutAll: nextChunk; cr; flush.
> > [stdout print: (Compiler evaluate: nextChunk); cr; flush]
> > on: Error
> > do: [:ex| self logError: ex description inContext: ex signalerContext to:
> > stderr]].
> > quitOnEof ifTrue:
> > [SourceFiles at: 2 put: nil.
> > Smalltalk snapshot: false andQuit: true]
> >
> >
> > I am not see why it breaks with blocking #atEnd. Can you explain?
>
>
> First consider the case where #atEnd doesn't block and we just want to
> evaluate 4+3:
>
> 1. #atEnd will return false
> 2. the loop will print the prompt
> 3. wait for input (stdin nextChunkNoTag)
> 4. print the result
> 5. goto 1.
>
> So the screen will look like:
>
> squeak> 4+3!
> 7
> squeak> [cursor here]
>
> Which is what we expect (prompt, input, result, prompt).
>
> If #atEnd is blocking the VM will hang at step 1 until the user enters
> something in the terminal.  In Ubuntu at least terminal input appears to
> be line buffered, so for the example above the terminal will look like:
>
> 4+3!
> squeak> 7
> [cursor here]
>
> We don't get the prompt when the program is started, the result is
> printed after the prompt, and then there's just a cursor sitting at the
> start of the next line.
>
> Obviously the program could be re-written to have the correct output
> with #atEnd blocking.  But I'm arguing that this program is
> representative of many others, and we don't want to break backward
> compatibility in this case.
>
> Cheers,
> Alistair
>
>
>
>
>
>
>
>
> > 2018-04-11 11:41 GMT+02:00 Alistair Grant :
> >>
> >> Hi Sven,
> >>
> >> Oh dear.  I feel as though I'm not getting my concerns across at all
> >> well, and I'm pushing hard enough that all I'm going to do is make
> >> people annoyed.  So let me try to restate the issue one last time
> >> before answering your questions directly.
> >>
> >> Pharo & Squeak have unwritten rules about stream usage that I suspect
> >> have just emerged over time without being designed.
> >>
> >> If you want to be able to iterate over any stream, and in particular
> >> stdin from a terminal (which, as far as I know, is the outlier that
> >> causes all the problems) you have to follow these rules:
> >>
> >> 1.  If the stream is character / byte oriented you have to check for
> >> EOF using "stream next == nil".  #atEnd can be used, but you'll still
> >> have to do the nil check.
> >>
> >> 2.  All other streams have to check for EOF (end of stream) using
> >> #atEnd.  "stream next == nil" can be used, but you'll still need to
> >> test #atEnd to determine whether nil is a value returned by the
> >> stream.
> >>
> >> If you write code that you want to be able to consume characters,
> >> bytes or any other object, you'll have to test both "stream next ==
> >> nil" and #atEnd.
> >>
> >> The rules are the result of the original blue book design being that
> >> #atEnd should be used, and then character input from a terminal being
> >> added later, but always returning an EOF character (nil) before #atEnd
> >> answers correctly.
> >>
> >> At the moment, ZnCharacterEncoder uses #atEnd on character / byte
> >> streams, so fails for stdin on a terminal.
> >>
> >> Back to your questions:
> >>
> >> On 11 April 2018 at 11:12, Sven Van Caekenberghe  wrote:
> >> >
> >> >
> >> >> On 11 Apr 2018, at 10:29, Alistair Grant 
> wrote:
> >> >>
> >> >> Hi Denis,
> >> >>
> >> >> On 11 April 2018 at 10:02, Denis Kudriashov 
> >> >> wrote:
> >> >>>
> >> >>> 2018-04-11 8:32 GMT+02:00 Alistair Grant :
> >> 
> >> >>> Where is it being said that #next and/or #atEnd should be
> blocking
> >> >>> or
> >> >>> non-blocking ?
> >> >>
> >> >> There is existing code that assumes that #atEnd is non-blocking
> and
> >> >> that #next is allowed block.  I believe that we should keep th

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

[Sven Van Caekenberghe]

> On 11 Apr 2018, at 11:12, Sven Van Caekenberghe  wrote:
> 
> How does one modify #atEnd to block ? I suppose you are talking about 
> StdioStream>>#atEnd ?
> 
> ^ self peek isNil
> 
> ?

Still the same question, how do you implement a blocking #atEnd for stdin ?

I have seen your stdio.cs which is indeed needed as the current 
StdioStream>>#atEnd is bogus for sure.

But that is still a non-blocking one, right ?

Since there is a peekBuffer in StdioStream, why can't that be used ?

I have run your example testAtEnd.st now, and it works/fails as advertised.

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

[Alistair Grant]

Hi Sven & Dennis,

On 11 April 2018 at 12:04, Denis Kudriashov  wrote:
> Hi Alistair.
>
> I don't think anybody is annoyed by you. You are doing really good job. And
> nice thing that you are super patient to continue :)
>

On 11 April 2018 at 12:13, Sven Van Caekenberghe  wrote:
>
> Yes, Alistair, you are a top notch open source contributor !
>
> For me, this discussion is about the difference between looking from low 
> level details/issues/changes up, vs, from a higher level down.

Thanks for your kind words.



> What I try to understand is why blocking atEnd is bad?
> Here is code from VMMaker:
>
> [stdin atEnd] whileFalse:
> [| nextChunk |
> stdout nextPutAll: 'squeak> '; flush.
> nextChunk := stdin nextChunkNoTag.
> [nextChunk notEmpty and: [nextChunk first isSeparator]] whileTrue:
> [nextChunk := nextChunk allButFirst].
> Transcript cr; nextPutAll: nextChunk; cr; flush.
> [stdout print: (Compiler evaluate: nextChunk); cr; flush]
> on: Error
> do: [:ex| self logError: ex description inContext: ex signalerContext to:
> stderr]].
> quitOnEof ifTrue:
> [SourceFiles at: 2 put: nil.
> Smalltalk snapshot: false andQuit: true]
>
>
> I am not see why it breaks with blocking #atEnd. Can you explain?


First consider the case where #atEnd doesn't block and we just want to
evaluate 4+3:

1. #atEnd will return false
2. the loop will print the prompt
3. wait for input (stdin nextChunkNoTag)
4. print the result
5. goto 1.

So the screen will look like:

squeak> 4+3!
7
squeak> [cursor here]

Which is what we expect (prompt, input, result, prompt).

If #atEnd is blocking the VM will hang at step 1 until the user enters
something in the terminal.  In Ubuntu at least terminal input appears to
be line buffered, so for the example above the terminal will look like:

4+3!
squeak> 7
[cursor here]

We don't get the prompt when the program is started, the result is
printed after the prompt, and then there's just a cursor sitting at the
start of the next line.

Obviously the program could be re-written to have the correct output
with #atEnd blocking.  But I'm arguing that this program is
representative of many others, and we don't want to break backward
compatibility in this case.

Cheers,
Alistair








> 2018-04-11 11:41 GMT+02:00 Alistair Grant :
>>
>> Hi Sven,
>>
>> Oh dear.  I feel as though I'm not getting my concerns across at all
>> well, and I'm pushing hard enough that all I'm going to do is make
>> people annoyed.  So let me try to restate the issue one last time
>> before answering your questions directly.
>>
>> Pharo & Squeak have unwritten rules about stream usage that I suspect
>> have just emerged over time without being designed.
>>
>> If you want to be able to iterate over any stream, and in particular
>> stdin from a terminal (which, as far as I know, is the outlier that
>> causes all the problems) you have to follow these rules:
>>
>> 1.  If the stream is character / byte oriented you have to check for
>> EOF using "stream next == nil".  #atEnd can be used, but you'll still
>> have to do the nil check.
>>
>> 2.  All other streams have to check for EOF (end of stream) using
>> #atEnd.  "stream next == nil" can be used, but you'll still need to
>> test #atEnd to determine whether nil is a value returned by the
>> stream.
>>
>> If you write code that you want to be able to consume characters,
>> bytes or any other object, you'll have to test both "stream next ==
>> nil" and #atEnd.
>>
>> The rules are the result of the original blue book design being that
>> #atEnd should be used, and then character input from a terminal being
>> added later, but always returning an EOF character (nil) before #atEnd
>> answers correctly.
>>
>> At the moment, ZnCharacterEncoder uses #atEnd on character / byte
>> streams, so fails for stdin on a terminal.
>>
>> Back to your questions:
>>
>> On 11 April 2018 at 11:12, Sven Van Caekenberghe  wrote:
>> >
>> >
>> >> On 11 Apr 2018, at 10:29, Alistair Grant  wrote:
>> >>
>> >> Hi Denis,
>> >>
>> >> On 11 April 2018 at 10:02, Denis Kudriashov 
>> >> wrote:
>> >>>
>> >>> 2018-04-11 8:32 GMT+02:00 Alistair Grant :
>> 
>> >>> Where is it being said that #next and/or #atEnd should be blocking
>> >>> or
>> >>> non-blocking ?
>> >>
>> >> There is existing code that assumes that #atEnd is non-blocking and
>> >> that #next is allowed block.  I believe that we should keep those
>> >> conditions.
>> >
>> > I fail to see where that is written down, either way. Can you point
>> > me
>> > to comments stating that, I would really like to know ?
>> 
>>  I'm not aware of it being written down, just that ever existing
>>  implementation I'm aware of behaves this way.
>> 
>>  On the other hand, making #atEnd blocking breaks Eliot's REPL sample
>>  (in Squeak).
>> >>>
>> >>>
>> >>> Could you write here this example, please?
>> >>
>> >> The code is loaded in squeak using:
>> >>
>> >>
>> >> https://github.com/OpenSmalltalk/opensm

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

[Sven Van Caekenberghe]

> On 11 Apr 2018, at 12:04, Denis Kudriashov  wrote:
> 
> I don't think anybody is annoyed by you. You are doing really good job. And 
> nice thing that you are super patient to continue :)

Yes, Alistair, you are a top notch open source contributor !

For me, this discussion is about the difference between looking from low level 
details/issues/changes up, vs, from a higher level down.

[Pharo-dev] [Pharo 7.0-dev] Build #760: 21687-make-a-deprecated-Key-as-subclass-of-KeyboardKey

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #760 was: FAILURE.

The Pull Request #1190 was integrated: 
"21687-make-a-deprecated-Key-as-subclass-of-KeyboardKey"
Pull request url: https://github.com/pharo-project/pharo/pull/1190

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

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

[Denis Kudriashov]

Hi Alistair.

I don't think anybody is annoyed by you. You are doing really good job. And
nice thing that you are super patient to continue :)

What I try to understand is why blocking atEnd is bad?
Here is code from VMMaker:

[stdin atEnd] whileFalse:
[| nextChunk |
stdout nextPutAll: 'squeak> '; flush.
nextChunk := stdin nextChunkNoTag.
[nextChunk notEmpty and: [nextChunk first isSeparator]] whileTrue:
[nextChunk := nextChunk allButFirst].
Transcript cr; nextPutAll: nextChunk; cr; flush.
[stdout print: (Compiler evaluate: nextChunk); cr; flush]
on: Error
do: [:ex| self logError: ex description inContext: ex signalerContext to:
stderr]].
quitOnEof ifTrue:
[SourceFiles at: 2 put: nil.
Smalltalk snapshot: false andQuit: true]


I am not see why it breaks with blocking #atEnd. Can you explain?

2018-04-11 11:41 GMT+02:00 Alistair Grant :

> Hi Sven,
>
> Oh dear.  I feel as though I'm not getting my concerns across at all
> well, and I'm pushing hard enough that all I'm going to do is make
> people annoyed.  So let me try to restate the issue one last time
> before answering your questions directly.
>
> Pharo & Squeak have unwritten rules about stream usage that I suspect
> have just emerged over time without being designed.
>
> If you want to be able to iterate over any stream, and in particular
> stdin from a terminal (which, as far as I know, is the outlier that
> causes all the problems) you have to follow these rules:
>
> 1.  If the stream is character / byte oriented you have to check for
> EOF using "stream next == nil".  #atEnd can be used, but you'll still
> have to do the nil check.
>
> 2.  All other streams have to check for EOF (end of stream) using
> #atEnd.  "stream next == nil" can be used, but you'll still need to
> test #atEnd to determine whether nil is a value returned by the
> stream.
>
> If you write code that you want to be able to consume characters,
> bytes or any other object, you'll have to test both "stream next ==
> nil" and #atEnd.
>
> The rules are the result of the original blue book design being that
> #atEnd should be used, and then character input from a terminal being
> added later, but always returning an EOF character (nil) before #atEnd
> answers correctly.
>
> At the moment, ZnCharacterEncoder uses #atEnd on character / byte
> streams, so fails for stdin on a terminal.
>
> Back to your questions:
>
> On 11 April 2018 at 11:12, Sven Van Caekenberghe  wrote:
> >
> >
> >> On 11 Apr 2018, at 10:29, Alistair Grant  wrote:
> >>
> >> Hi Denis,
> >>
> >> On 11 April 2018 at 10:02, Denis Kudriashov 
> wrote:
> >>>
> >>> 2018-04-11 8:32 GMT+02:00 Alistair Grant :
> 
> >>> Where is it being said that #next and/or #atEnd should be blocking
> or
> >>> non-blocking ?
> >>
> >> There is existing code that assumes that #atEnd is non-blocking and
> >> that #next is allowed block.  I believe that we should keep those
> >> conditions.
> >
> > I fail to see where that is written down, either way. Can you point
> me
> > to comments stating that, I would really like to know ?
> 
>  I'm not aware of it being written down, just that ever existing
>  implementation I'm aware of behaves this way.
> 
>  On the other hand, making #atEnd blocking breaks Eliot's REPL sample
>  (in Squeak).
> >>>
> >>>
> >>> Could you write here this example, please?
> >>
> >> The code is loaded in squeak using:
> >>
> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/
> buildspurtrunkreaderimage.sh
> >>
> >> for 32 bit images.  It loads:
> >>
> >> https://github.com/OpenSmalltalk/opensmalltalk-
> vm/blob/Cog/image/LoadReader.st
> >>
> >> which loads package CogTools-Listener in http://source.squeak.org/
> VMMaker
> >>
> >> An image that automatically runs the code and nothing else is created
> in:
> >>
> >> https://github.com/OpenSmalltalk/opensmalltalk-
> vm/blob/Cog/image/StartReader.st
> >>
> >>
> >> If you want to run it interactively you can load CogTools-Listener and
> >> do something like:
> >>
> >> StdioListener new
> >>quitOnEof: false;
> >>run
> >
> > What does #quitOnEof: do ? Can the StdioListener code be browsed/viewed
> online somewhere ?
>
> I just referenced this as an example of making #atEnd (really
> FilePlugin>>primitiveFileAtEnd) blocking causing problems.  I wasn't
> expecting people to go and look at the code or use it as a test.
>
> If you really want to look at it (from Pharo):
>
> 1. Add http://source.squeak.org/VMMaker as a repository.
> 2. Browse the CogTools-Listener package
>
>
> >> If you modify #atEnd to block it will result in the "squeak>" input
> >> prompt being printed in the terminal after the input has been entered.
> >
> > How does one modify #atEnd to block ? I suppose you are talking about
> StdioStream>>#atEnd ?
>
> I meant the primitive, i.e. FilePlugin>>primitiveFileAtEnd /
> FilePluginPrims>>atEnd:.
>
>
> >  ^ self peek isNil
> >
> > ?
> >
> > PS: I liked your runnable example better,

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

[Alistair Grant]

Hi Sven,

Oh dear.  I feel as though I'm not getting my concerns across at all
well, and I'm pushing hard enough that all I'm going to do is make
people annoyed.  So let me try to restate the issue one last time
before answering your questions directly.

Pharo & Squeak have unwritten rules about stream usage that I suspect
have just emerged over time without being designed.

If you want to be able to iterate over any stream, and in particular
stdin from a terminal (which, as far as I know, is the outlier that
causes all the problems) you have to follow these rules:

1.  If the stream is character / byte oriented you have to check for
EOF using "stream next == nil".  #atEnd can be used, but you'll still
have to do the nil check.

2.  All other streams have to check for EOF (end of stream) using
#atEnd.  "stream next == nil" can be used, but you'll still need to
test #atEnd to determine whether nil is a value returned by the
stream.

If you write code that you want to be able to consume characters,
bytes or any other object, you'll have to test both "stream next ==
nil" and #atEnd.

The rules are the result of the original blue book design being that
#atEnd should be used, and then character input from a terminal being
added later, but always returning an EOF character (nil) before #atEnd
answers correctly.

At the moment, ZnCharacterEncoder uses #atEnd on character / byte
streams, so fails for stdin on a terminal.

Back to your questions:

On 11 April 2018 at 11:12, Sven Van Caekenberghe  wrote:
>
>
>> On 11 Apr 2018, at 10:29, Alistair Grant  wrote:
>>
>> Hi Denis,
>>
>> On 11 April 2018 at 10:02, Denis Kudriashov  wrote:
>>>
>>> 2018-04-11 8:32 GMT+02:00 Alistair Grant :

>>> Where is it being said that #next and/or #atEnd should be blocking or
>>> non-blocking ?
>>
>> There is existing code that assumes that #atEnd is non-blocking and
>> that #next is allowed block.  I believe that we should keep those
>> conditions.
>
> I fail to see where that is written down, either way. Can you point me
> to comments stating that, I would really like to know ?

 I'm not aware of it being written down, just that ever existing
 implementation I'm aware of behaves this way.

 On the other hand, making #atEnd blocking breaks Eliot's REPL sample
 (in Squeak).
>>>
>>>
>>> Could you write here this example, please?
>>
>> The code is loaded in squeak using:
>>
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkreaderimage.sh
>>
>> for 32 bit images.  It loads:
>>
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/LoadReader.st
>>
>> which loads package CogTools-Listener in http://source.squeak.org/VMMaker
>>
>> An image that automatically runs the code and nothing else is created in:
>>
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/StartReader.st
>>
>>
>> If you want to run it interactively you can load CogTools-Listener and
>> do something like:
>>
>> StdioListener new
>>quitOnEof: false;
>>run
>
> What does #quitOnEof: do ? Can the StdioListener code be browsed/viewed 
> online somewhere ?

I just referenced this as an example of making #atEnd (really
FilePlugin>>primitiveFileAtEnd) blocking causing problems.  I wasn't
expecting people to go and look at the code or use it as a test.

If you really want to look at it (from Pharo):

1. Add http://source.squeak.org/VMMaker as a repository.
2. Browse the CogTools-Listener package


>> If you modify #atEnd to block it will result in the "squeak>" input
>> prompt being printed in the terminal after the input has been entered.
>
> How does one modify #atEnd to block ? I suppose you are talking about 
> StdioStream>>#atEnd ?

I meant the primitive, i.e. FilePlugin>>primitiveFileAtEnd /
FilePluginPrims>>atEnd:.


>  ^ self peek isNil
>
> ?
>
> PS: I liked your runnable example better, I will try it later on. Thx!

Right.  My code is meant to be minimal and trigger the problem I'm
actually focused on - that ZnCharacterEncoder doesn't work with stdin
from a terminal.

Sven has expressed a hesitation to change the internal operation of
the Zinc streams from using #atEnd to "stream peek == nil" and this
whole discussion is really about us trying to resolve our different
perspective of the best path forward.  I respect Sven and his work so
I'm trying to justify the change (but I'm not expressing it at all
well, obviously).

Cheers,
Alistair



>> The code can be loaded in to Pharo and basically works, but the output
>> tends to be hidden behind the next input prompt because it uses #cr
>> instead of #lf.  You can easily modify StdioListener>>initialize to
>> set the line end convention in stdout.
>>
>> NOTE: It is not intended to be a release quality implementation of a
>> evaluation loop.  The whole purpose as I understand it is for it to be
>> as simple as possible to assist in tracking down issues using the VM
>> simulator.  It runs minimal cod

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

[Sven Van Caekenberghe]

> On 11 Apr 2018, at 10:29, Alistair Grant  wrote:
> 
> Hi Denis,
> 
> On 11 April 2018 at 10:02, Denis Kudriashov  wrote:
>> 
>> 2018-04-11 8:32 GMT+02:00 Alistair Grant :
>>> 
>> Where is it being said that #next and/or #atEnd should be blocking or
>> non-blocking ?
> 
> There is existing code that assumes that #atEnd is non-blocking and
> that #next is allowed block.  I believe that we should keep those
> conditions.
 
 I fail to see where that is written down, either way. Can you point me
 to comments stating that, I would really like to know ?
>>> 
>>> I'm not aware of it being written down, just that ever existing
>>> implementation I'm aware of behaves this way.
>>> 
>>> On the other hand, making #atEnd blocking breaks Eliot's REPL sample
>>> (in Squeak).
>> 
>> 
>> Could you write here this example, please?
> 
> The code is loaded in squeak using:
> 
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkreaderimage.sh
> 
> for 32 bit images.  It loads:
> 
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/LoadReader.st
> 
> which loads package CogTools-Listener in http://source.squeak.org/VMMaker
> 
> An image that automatically runs the code and nothing else is created in:
> 
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/StartReader.st
> 
> 
> If you want to run it interactively you can load CogTools-Listener and
> do something like:
> 
> StdioListener new
>quitOnEof: false;
>run

What does #quitOnEof: do ? Can the StdioListener code be browsed/viewed online 
somewhere ?

> If you modify #atEnd to block it will result in the "squeak>" input
> prompt being printed in the terminal after the input has been entered.

How does one modify #atEnd to block ? I suppose you are talking about 
StdioStream>>#atEnd ?

 ^ self peek isNil

?

PS: I liked your runnable example better, I will try it later on. Thx!

> The code can be loaded in to Pharo and basically works, but the output
> tends to be hidden behind the next input prompt because it uses #cr
> instead of #lf.  You can easily modify StdioListener>>initialize to
> set the line end convention in stdout.
> 
> NOTE: It is not intended to be a release quality implementation of a
> evaluation loop.  The whole purpose as I understand it is for it to be
> as simple as possible to assist in tracking down issues using the VM
> simulator.  It runs minimal code to get to the point of waiting for
> user input and then allows an expression that causes problems to be
> entered and traced using the simulator.
> 
> Cheers,
> Alistair
> 
> 
> 
>> How is this related to how EOF is signalled ?
> 
> Because, combined with terminal EOF not being known until the user
> explicitly flags it (with Ctrl-D) it means that #atEnd can't be used
> for iterating over input from stdin connected to a terminal.
 
 This seems to me like an exception that only holds for one particular
 stream in one particular scenario (interactive stdin). I might be wrong.
 
>> It seems to me that there are quite a few classes of streams that are
>> 'special' in the sense that #next could be blocking and/or #atEnd could 
>> be
>> unclear - socket/network streams, serial streams, maybe stdio 
>> (interactive
>> or not). Without a message like #isDataAvailable you cannot handle those
>> without blocking.
> 
> Right.  I think this is a distraction (I was trying to explain some
> details, but it's causing more confusion instead of helping).
> 
> The important point is that #atEnd doesn't work for iterating over
> streams with terminal input
 
 Maybe you should also point to the actual code that fails. I mean you
 showed a partial stack trace, but not how you got there, precisely. How 
 does
 the application reading from an interactive stdin do to get into trouble ?
>>> 
>>> Included below.
>>> 
>>> 
>> Reading from stdin seems like a very rare case for a Smalltalk system
>> (not that it should not be possible).
> 
> There's been quite a bit of discussion and several projects recently
> related to using pharo for scripting, so it may become more common.
> E.g.
> 
> 
> https://www.quora.com/Can-Smalltalk-be-a-batch-file-scripting-language/answer/Philippe-Back-1?share=c19bfc95
> https://github.com/rajula96reddy/pharo-cli
 
 Still, it is not common at all.
 
>> I have a feeling that too much functionality is being pushed into too
>> small an API.
> 
> This is just about how should Zinc streams be iterating over the
> underlying streams.  You didn't like checking the result of #next for
> nil since it isn't general, correctly pointing out that nil is a valid
> value for non-byte oriented streams.  But #atEnd doesn't work for
> stdin from a terminal.
> 
> 
> At this point I think there are three options:
>

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

[Alistair Grant]

Hi Denis,

On 11 April 2018 at 10:02, Denis Kudriashov  wrote:
>
> 2018-04-11 8:32 GMT+02:00 Alistair Grant :
>>
>> >>> Where is it being said that #next and/or #atEnd should be blocking or
>> >>> non-blocking ?
>> >>
>> >> There is existing code that assumes that #atEnd is non-blocking and
>> >> that #next is allowed block.  I believe that we should keep those
>> >> conditions.
>> >
>> > I fail to see where that is written down, either way. Can you point me
>> > to comments stating that, I would really like to know ?
>>
>> I'm not aware of it being written down, just that ever existing
>> implementation I'm aware of behaves this way.
>>
>> On the other hand, making #atEnd blocking breaks Eliot's REPL sample
>> (in Squeak).
>
>
> Could you write here this example, please?

The code is loaded in squeak using:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkreaderimage.sh

for 32 bit images.  It loads:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/LoadReader.st

which loads package CogTools-Listener in http://source.squeak.org/VMMaker

An image that automatically runs the code and nothing else is created in:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/StartReader.st


If you want to run it interactively you can load CogTools-Listener and
do something like:

StdioListener new
quitOnEof: false;
run

If you modify #atEnd to block it will result in the "squeak>" input
prompt being printed in the terminal after the input has been entered.

The code can be loaded in to Pharo and basically works, but the output
tends to be hidden behind the next input prompt because it uses #cr
instead of #lf.  You can easily modify StdioListener>>initialize to
set the line end convention in stdout.

NOTE: It is not intended to be a release quality implementation of a
evaluation loop.  The whole purpose as I understand it is for it to be
as simple as possible to assist in tracking down issues using the VM
simulator.  It runs minimal code to get to the point of waiting for
user input and then allows an expression that causes problems to be
entered and traced using the simulator.

Cheers,
Alistair



>> >>> How is this related to how EOF is signalled ?
>> >>
>> >> Because, combined with terminal EOF not being known until the user
>> >> explicitly flags it (with Ctrl-D) it means that #atEnd can't be used
>> >> for iterating over input from stdin connected to a terminal.
>> >
>> > This seems to me like an exception that only holds for one particular
>> > stream in one particular scenario (interactive stdin). I might be wrong.
>> >
>> >>> It seems to me that there are quite a few classes of streams that are
>> >>> 'special' in the sense that #next could be blocking and/or #atEnd could 
>> >>> be
>> >>> unclear - socket/network streams, serial streams, maybe stdio 
>> >>> (interactive
>> >>> or not). Without a message like #isDataAvailable you cannot handle those
>> >>> without blocking.
>> >>
>> >> Right.  I think this is a distraction (I was trying to explain some
>> >> details, but it's causing more confusion instead of helping).
>> >>
>> >> The important point is that #atEnd doesn't work for iterating over
>> >> streams with terminal input
>> >
>> > Maybe you should also point to the actual code that fails. I mean you
>> > showed a partial stack trace, but not how you got there, precisely. How 
>> > does
>> > the application reading from an interactive stdin do to get into trouble ?
>>
>> Included below.
>>
>>
>> >>> Reading from stdin seems like a very rare case for a Smalltalk system
>> >>> (not that it should not be possible).
>> >>
>> >> There's been quite a bit of discussion and several projects recently
>> >> related to using pharo for scripting, so it may become more common.
>> >> E.g.
>> >>
>> >>
>> >> https://www.quora.com/Can-Smalltalk-be-a-batch-file-scripting-language/answer/Philippe-Back-1?share=c19bfc95
>> >> https://github.com/rajula96reddy/pharo-cli
>> >
>> > Still, it is not common at all.
>> >
>> >>> I have a feeling that too much functionality is being pushed into too
>> >>> small an API.
>> >>
>> >> This is just about how should Zinc streams be iterating over the
>> >> underlying streams.  You didn't like checking the result of #next for
>> >> nil since it isn't general, correctly pointing out that nil is a valid
>> >> value for non-byte oriented streams.  But #atEnd doesn't work for
>> >> stdin from a terminal.
>> >>
>> >>
>> >> 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.
>>
>> Right.  Streams can be categorised in many ways, b

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

[Denis Kudriashov]

2018-04-11 8:32 GMT+02:00 Alistair Grant :

> >>> Where is it being said that #next and/or #atEnd should be blocking or
> non-blocking ?
> >>
> >> There is existing code that assumes that #atEnd is non-blocking and
> >> that #next is allowed block.  I believe that we should keep those
> >> conditions.
> >
> > I fail to see where that is written down, either way. Can you point me
> to comments stating that, I would really like to know ?
>
> I'm not aware of it being written down, just that ever existing
> implementation I'm aware of behaves this way.
>
> On the other hand, making #atEnd blocking breaks Eliot's REPL sample
> (in Squeak).
>

Could you write here this example, please?


>
>
>
> >>> How is this related to how EOF is signalled ?
> >>
> >> Because, combined with terminal EOF not being known until the user
> >> explicitly flags it (with Ctrl-D) it means that #atEnd can't be used
> >> for iterating over input from stdin connected to a terminal.
> >
> > This seems to me like an exception that only holds for one particular
> stream in one particular scenario (interactive stdin). I might be wrong.
> >
> >>> It seems to me that there are quite a few classes of streams that are
> 'special' in the sense that #next could be blocking and/or #atEnd could be
> unclear - socket/network streams, serial streams, maybe stdio (interactive
> or not). Without a message like #isDataAvailable you cannot handle those
> without blocking.
> >>
> >> Right.  I think this is a distraction (I was trying to explain some
> >> details, but it's causing more confusion instead of helping).
> >>
> >> The important point is that #atEnd doesn't work for iterating over
> >> streams with terminal input
> >
> > Maybe you should also point to the actual code that fails. I mean you
> showed a partial stack trace, but not how you got there, precisely. How
> does the application reading from an interactive stdin do to get into
> trouble ?
>
> Included below.
>
>
> >>> Reading from stdin seems like a very rare case for a Smalltalk system
> (not that it should not be possible).
> >>
> >> There's been quite a bit of discussion and several projects recently
> >> related to using pharo for scripting, so it may become more common.
> >> E.g.
> >>
> >> https://www.quora.com/Can-Smalltalk-be-a-batch-file-
> scripting-language/answer/Philippe-Back-1?share=c19bfc95
> >> https://github.com/rajula96reddy/pharo-cli
> >
> > Still, it is not common at all.
> >
> >>> I have a feeling that too much functionality is being pushed into too
> small an API.
> >>
> >> This is just about how should Zinc streams be iterating over the
> >> underlying streams.  You didn't like checking the result of #next for
> >> nil since it isn't general, correctly pointing out that nil is a valid
> >> value for non-byte oriented streams.  But #atEnd doesn't work for
> >> stdin from a terminal.
> >>
> >>
> >> 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.
>
> Right.  Streams can be categorised in many ways, but for this
> discussion I think streams are broken in to two types:
>
> 1) Byte / Character oriented
> 2) All others
>
> For historical reasons, byte / character oriented streams need to
> check for EOF by using "stream next == nil" and all other streams
> should use #atEnd.
>
> This avoids the "nil being part of the domain" issue that was
> discussed earlier in the thread.
>
>
> >> 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.
> >
> >> 3. Require anyone who wants to read from stdin to code around Zinc's
> >> inability to handle terminal input.
> >>
> >> I'd prefer to avoid this option if possible.
> >
> > See higher for a more concrete usage example request.
>
>
> testAtEnd.st
> --
> | ch stream string stdin |
>
> 'stdio.cs' asFileReference fileIn.
> "stdin := FileStream stdin."
> stdin := ZnCharacterReadStream on:
> (ZnBufferedReadStream on:
> Stdio stdin).
> stream := (String new: 100) writeStream.
> ch := stdin next.
> [ ch == nil ] whileFalse: [
> stream nextPut: ch.
> ch := stdin next. ].
> string := stream contents.
> FileStream stdout
> nextPutAll: string; lf;
> nextPutAll: 'Characters read: ';
> nextPutAll: string size asString;
> lf.
> Smalltalk snapshot: false andQuit: true.
> --
>
> Execute with:
>
> ./pharo --headless Pharo7.0-64bit-e76f1a2.image testAtEnd.st
>
> and type Ctrl-D gives:
>
>
> 'Err

Re: [Pharo-dev] Images, VMs and 32 vs 64bit

[Nicolas Cellier]

The general principle is that the VM insulate almost every OS specific
feature: the image sees the same virtual machine.
So you can save a 32bits image on an OS, and restart it on another.
The images effectively share the same code base whatever the OS.
There might be a plugin or two which are not present on all platforms
though.
If FFI is used then a few more differences will generally creep in image
side
That means that some OS dependent subclasses will care of implementation
details at image side.
An image carries the implementation for all platforms, but only one is
active at a time.
See senders of os osVersion osName platformName

For Squeak, the image code base is the same for 32 and 64bits and I presume
it's also the case for Pharo.
But you cannot save on 32 bits and restart on 64bits et vice et versa.
There are again very few implementation details that are present at image
side.
For example SmallInteger maxVal changes, there are also instances of
SmallFloat64 on a 64bits image, but this should be mostly transparent.
See wordSize and senders for discovering a few parts of the image sensitive
to the word size... (on Squeak, FFI/Alien, image segments, ...).

Concerning the underlying OS, , so it's again the same code base, you can
save an image on an OS and restart it on another.
For the VM, as Guile said, there are more changes, because there you will
find a lot more implementation details.
Since the VM is implemented in (mostly) in Smalltalk, if you load VMMaker
then you will see abstract superclass, and 32/64 bits specializations for
some part of the VM.

2018-04-11 8:51 GMT+02:00 Guillermo Polito :

> VMs share most of the code. At least the basic interpreter, primitives and
> garbage collector.
> But there are some platform specificities such as how some plugins are
> managed.
> Also there are different JIT backends, one per platform.
> I don't know if a VM comes shipped with all of them or just the one needed.
>
> For more details, better ask the vm-dev mailing list.
>
> On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <
> pharo-dev@lists.pharo.org> wrote:
>
>>
>>
>> -- Forwarded message --
>> From: Benoit St-Jean 
>> To: Pharo Development List , "Peter Uhnák" <
>> i.uh...@gmail.com>
>> Cc:
>> Bcc:
>> Date: Tue, 10 Apr 2018 22:39:16 + (UTC)
>> Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
>> Thanks!
>>
>> I don't really care about the image format, my question was more oriented
>> towards the code itself.  As I don't have a Mac, I was curious as to
>> whether there would be code differences between platforms, VMs and 32 vs
>> 64bit distributions, code-wise!
>>
>>
>> -
>> Benoît St-Jean
>> Yahoo! Messenger: bstjean
>> Twitter: @BenLeChialeux
>> Pinterest: benoitstjean
>> Instagram: Chef_Benito
>> IRC: lamneth
>> Blogue: endormitoire.wordpress.com
>> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>>
>>
>> On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <
>> i.uh...@gmail.com> wrote:
>>
>>
>> > images for different platforms (Mac, Linux, Windows)
>>
>> yes
>> It is the responsibility of the VM to contain the differences. Note that
>> there's some "platform-specific" code, but the image contains the code for
>> all platforms at once.
>> Generally speaking you can code on one platform, copy the image files to
>> another and continue your work (although doing this can cause trouble, as
>> e.g. some file paths may now point to non-existing locations).
>> You can download the images independently of the platform too (e.g. Pharo
>> 6 images: http://files.pharo.org/image/60/ )
>>
>> > VMs (32bit, 64bit)
>>
>> yes?
>> the files are different, but I don't know if there's code difference, or
>> if the images are just built with different memory layouts
>>
>> Peter
>>
>> On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <
>> pharo-dev@lists.pharo.org> wrote:
>>
>>
>>
>> -- Forwarded message --
>> From: Benoit St-Jean 
>> To: Pharo Development List 
>> Cc:
>> Bcc:
>> Date: Tue, 10 Apr 2018 22:13:18 + (UTC)
>> Subject: Images, VMs and 32 vs 64bit
>> I was wondering if images for different platforms (Mac, Linux, Windows)
>> and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do
>> they all have the exact same code base or some classes/methods are in some
>> and not in others or different?
>>
>> -
>> Benoît St-Jean
>> Yahoo! Messenger: bstjean
>> Twitter: @BenLeChialeux
>> Pinterest: benoitstjean
>> Instagram: Chef_Benito
>> IRC: lamneth
>> Blogue: endormitoire.wordpress.com
>> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>>
>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 

Re: [Pharo-dev] Images, VMs and 32 vs 64bit

[p...@highoctane.be]

But once you are using an image on a given platform it may not work on
another one just like that (e.g. FreeType will give trouble).

Phil

On Wed, Apr 11, 2018, 08:52 Guillermo Polito 
wrote:

> VMs share most of the code. At least the basic interpreter, primitives and
> garbage collector.
> But there are some platform specificities such as how some plugins are
> managed.
> Also there are different JIT backends, one per platform.
> I don't know if a VM comes shipped with all of them or just the one needed.
>
> For more details, better ask the vm-dev mailing list.
>
> On Wed, Apr 11, 2018 at 12:39 AM, Benoit St-Jean via Pharo-dev <
> pharo-dev@lists.pharo.org> wrote:
>
>>
>>
>> -- Forwarded message --
>> From: Benoit St-Jean 
>> To: Pharo Development List , "Peter Uhnák" <
>> i.uh...@gmail.com>
>> Cc:
>> Bcc:
>> Date: Tue, 10 Apr 2018 22:39:16 + (UTC)
>> Subject: Re: [Pharo-dev] Images, VMs and 32 vs 64bit
>> Thanks!
>>
>> I don't really care about the image format, my question was more oriented
>> towards the code itself.  As I don't have a Mac, I was curious as to
>> whether there would be code differences between platforms, VMs and 32 vs
>> 64bit distributions, code-wise!
>>
>>
>> -
>> Benoît St-Jean
>> Yahoo! Messenger: bstjean
>> Twitter: @BenLeChialeux
>> Pinterest: benoitstjean
>> Instagram: Chef_Benito
>> IRC: lamneth
>> Blogue: endormitoire.wordpress.com
>> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>>
>>
>> On Tuesday, April 10, 2018, 6:29:33 p.m. EDT, Peter Uhnák <
>> i.uh...@gmail.com> wrote:
>>
>>
>> > images for different platforms (Mac, Linux, Windows)
>>
>> yes
>> It is the responsibility of the VM to contain the differences. Note that
>> there's some "platform-specific" code, but the image contains the code for
>> all platforms at once.
>> Generally speaking you can code on one platform, copy the image files to
>> another and continue your work (although doing this can cause trouble, as
>> e.g. some file paths may now point to non-existing locations).
>> You can download the images independently of the platform too (e.g. Pharo
>> 6 images: http://files.pharo.org/image/60/ )
>>
>> > VMs (32bit, 64bit)
>>
>> yes?
>> the files are different, but I don't know if there's code difference, or
>> if the images are just built with different memory layouts
>>
>> Peter
>>
>> On Wed, Apr 11, 2018 at 12:13 AM, Benoit St-Jean via Pharo-dev <
>> pharo-dev@lists.pharo.org> wrote:
>>
>>
>>
>> -- Forwarded message --
>> From: Benoit St-Jean 
>> To: Pharo Development List 
>> Cc:
>> Bcc:
>> Date: Tue, 10 Apr 2018 22:13:18 + (UTC)
>> Subject: Images, VMs and 32 vs 64bit
>> I was wondering if images for different platforms (Mac, Linux, Windows)
>> and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean do
>> they all have the exact same code base or some classes/methods are in some
>> and not in others or different?
>>
>> -
>> Benoît St-Jean
>> Yahoo! Messenger: bstjean
>> Twitter: @BenLeChialeux
>> Pinterest: benoitstjean
>> Instagram: Chef_Benito
>> IRC: lamneth
>> Blogue: endormitoire.wordpress.com
>> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>>
>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>