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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

> 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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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,

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

> 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

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

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

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

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)

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

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

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

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,

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

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

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

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

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

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

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

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:

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

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] help wanted: normalising LF on tonel for Pharo project

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

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

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

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

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

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

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

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

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

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

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 >

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

> 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

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

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

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

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

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

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

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

? 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hi Sven, On 10 April 2018 at 23:54, Sven Van Caekenberghe wrote: > Alistair, > > I am replying in-between, please don't take my remarks as being negative, I > just like to straighten things out as clear as possible. No problem. >> On 10 Apr 2018, at 22:14, Alistair Grant

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

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

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

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

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

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

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

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