April 2018 - Pharo-dev - lists.pharo.org

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

by Peter UhnÃ¡k

Hi, did you commit on Windows? Because Iceberg seems to commit in platform-specific line endings, so I always need to convert it manually... ( https://github.com/PowerShell/Win32-OpenSSH/wiki/Dos2Unix---Text-file-forma… ) Notice also that all the files are from the same directory ... when you commit even a single change, the entire package is filed out. Peter On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess <nicolaihess(a)gmail.com> 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 > >

April 10, 2018

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

by Damien Pollet

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 <sean(a)clipperadams.com> 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

April 10, 2018

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

by Esteban A. Maringolo

Not stricly related, or maybe yes, but years ago in InfOil we started using Dolphin Smalltalk PAX format[1] for packages with Git, and we used that setting to store code in the repo, we didn't have any issues The .gitattributes contained this: *.img binary *.chg binary *.sml binary OurImage.img merge=ours OurImage.chg merge=ours *.pax eol=lf *.cls eol=lf .pax was the "package definition" and "method extensions" (methods not belonging to the package) file. .cls was the 1 file per class+class-side used by this scheme Even we did everything in Windows for some reason I don't remember (+5 yrs ago) LF was better for Gitlab. What I also don't remember is if during the checkout in the Gitlab CI some conversion was used or not. I don't remember a lot of things, but I can ask them if you want. But I can confirm that this "trick" does work. Git for Windows even asks you if you want to automatically convert CRLF to LF during checkin and back to CRLF on checkout. Regards, On 10/04/2018 18: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-ret… > > and it seems adding a .gitattributes file with this content:Â > > # Auto detect text files and perform LF normalization > *text=auto > *.sttext merge=union eol=lf > > could fix the problem? > can someone confirm this? > > (I confess this issue confuses me a lot :P) > > cheers! > Esteban -- Esteban A. Maringolo

April 10, 2018

Contribute a Fix and Reviewing changes

by Nicolai Hess

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

April 10, 2018

help wanted: normalising LF on tonel for Pharo project

by Esteban Lorenzano

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-ret… <https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-ret…> and it seems adding a .gitattributes file with this content: # Auto detect text files and perform LF normalization * text=auto *.st text merge=union eol=lf could fix the problem? can someone confirm this? (I confess this issue confuses me a lot :P) cheers! Esteban

April 10, 2018

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

by Alistair Grant

Hi Sven, On 10 April 2018 at 19:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I have trouble understanding your problem analysis, and how your proposed solution, would solve it. The discussion started with my proposal to modify the Zinc streams to check the return value of #next for nil rather than using #atEnd to iterate over the underlying stream. You correctly pointed out that the intention behind #atEnd is that it can be used to control iterating over streams. > 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. > 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. > 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 > 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/answ… https://github.com/rajula96reddy/pharo-cli > 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. 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. 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. Does that clarify the situation? Thanks, Alistair >> On 10 Apr 2018, at 18:30, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> First a quick update: >> >> After doing some work on primitiveFileAtEnd, #atEnd now answers >> correctly for files that don't report their size correctly, e.g. >> /dev/urandom and /proc/cpuinfo, whether the files are opened directly or >> redirected through stdin. >> >> However determining whether stdin from a terminal has reached the end of >> file can't be done without making #atEnd blocking since we have to wait >> for the user to flag the end of file, e.g. by typing Ctrl-D. And #atEnd >> is assumed to be non-blocking. >> >> So currently using ZnCharacterReadStream with stdin from a terminal will >> result in a stack dump similar to: >> >> MessageNotUnderstood: receiver of "<" is nil >> UndefinedObject(Object)>>doesNotUnderstand: #< >> ZnUTF8Encoder>>nextCodePointFromStream: >> ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream: >> ZnCharacterReadStream>>nextElement >> ZnCharacterReadStream(ZnEncodedReadStream)>>next >> UndefinedObject>>DoIt >> >> >> Going back through the various suggestions that have been made regarding >> using a sentinel object vs. raising a notification / exception, my >> (still to be polished) suggestion is to: >> >> 1. Add an endOfStream instance variable >> 2. When the end of the stream is reached answer the value of the >> instance variable (i.e. the result of sending #value to the variable). >> 3. The initial default value would be a block that raises a Deprecation >> warning and then returns nil. This would allow existing code to >> function for a changeover period. >> 4. At the end of the deprecation period the default value would be >> changed to a unique sentinel object which would answer itself as its >> #value. >> >> At any time users of the stream can set their own sentinel, including a >> block that raises an exception. >> >> >> Cheers, >> Alistair >> >> >> On 4 April 2018 at 19:24, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> Thanks for this discussion. >>> >>> On Wed, Apr 4, 2018 at 1:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Alistair, >>>> >>>> First off, thanks for the discussions and your contributions, I really appreciate them. >>>> >>>> But I want to have a discussion at the high level of the definition and semantics of the stream API in Pharo. >>>> >>>>> On 4 Apr 2018, at 13:20, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>> >>>>> On 4 April 2018 at 12:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> Playing a bit devil's advocate, the idea is that, in general, >>>>>> >>>>>> [ stream atEnd] whileFalse: [ stream next. "..." ]. >>>>>> >>>>>> is no longer allowed ? >>>>> >>>>> It hasn't been allowed "forever" [1]. It's just been misused for >>>>> almost as long. >>>>> >>>>> [1] Time began when stdio stream support was introduced. :-) >>>> >>>> I am still not convinced. Another way to put it would be that the old #atEnd or #upToEnd do not make sense for these streams and some new loop is needed, based on a new test (it exists for socket streams already). >>>> >>>> [ stream isDataAvailable ] whileTrue: [ stream next ] >>>> >>>>>> And you want to replace it with >>>>>> >>>>>> [ stream next ifNil: [ false ] ifNotNil: [ :x | "..." true ] whileTrue. >>>>>> >>>>>> That is a pretty big change, no ? >>>>> >>>>> That's the way quite a bit of code already operates. >>>>> >>>>> As Denis pointed out, it's obviously problematic in the general sense, >>>>> since nil can be embedded in non-byte oriented streams. I suspect >>>>> that in practice not many people write code that reads streams from >>>>> both byte oriented and non-byte oriented streams. >>>> >>>> Maybe yes, maybe no. As Denis' example shows there is a clear definition problem. >>>> >>>> And I do use streams of byte arrays or strings all the time, this is really important. I want my parsers to work on all kinds of streams. >>>> >>>>>> I think/feel like a proper EOF exception would be better, more correct. >>>>>> >>>>>> [ [ stream next. "..." true ] on: EOF do: [ false ] ] whileTrue. >>>>> >>>>> I agree, but the email thread Nicolas pointed to raises some >>>>> performance questions about this approach. It should be >>>>> straightforward to do a basic performance comparison which I'll get >>>>> around to if other objections aren't raised. >>>> >>>> Reading in bigger blocks, using #readInto:startingAt:count: (which is basically Unix's (2) Read sys call), would solve performance problems, I think. >>>> >>>>>> Will we throw away #atEnd then ? Do we need it if we cannot use it ? >>>>> >>>>> Unix file i/o returns EOF if the end of file has been reach OR if an >>>>> error occurs. You should still check #atEnd after reading past the >>>>> end of the file to make sure no error occurred. Another part of the >>>>> primitive change I'm proposing is to return additional information >>>>> about what went wrong in the event of an error. >>>> >>>> I am sorry, but this kind of semantics (the OR) is way too complex at the general image level, it is too specific and based on certain underlying implementation details. >>>> >>>> Sven >>>> >>>>> We could modify the read primitive so that it fails if an error has >>>>> occurred, and then #atEnd wouldn't be required. >>>>> >>>>> Cheers, >>>>> Alistair >>>>> >>>>> >>>>> >>>>>>> On 4 Apr 2018, at 12:41, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Nicolas, >>>>>>> >>>>>>> On 4 April 2018 at 12:36, Nicolas Cellier >>>>>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> 2018-04-04 12:18 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >>>>>>>>> >>>>>>>>> Hi Sven, >>>>>>>>> >>>>>>>>> On Wed, Apr 04, 2018 at 11:32:02AM +0200, Sven Van Caekenberghe wrote: >>>>>>>>>> Somehow, somewhere there was a change to the implementation of the >>>>>>>>>> primitive called by some streams' #atEnd. >>>>>>>>> >>>>>>>>> That's a proposed change by me, but it hasn't been integrated yet. So >>>>>>>>> the discussion below should apply to the current stable vm (from August >>>>>>>>> last year). >>>>>>>>> >>>>>>>>> >>>>>>>>>> IIRC, someone said it is implemented as 'remaining size being zero' >>>>>>>>>> and some virtual unix files like /dev/random are zero sized. >>>>>>>>> >>>>>>>>> Currently, for files other than sdio (stdout, stderr, stdin) it is >>>>>>>>> effectively defined as: >>>>>>>>> >>>>>>>>> atEnd := stream position >= stream size >>>>>>>>> >>>>>>>>> >>>>>>>>> And, as you say, plenty of virtual unix files report size 0. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Now, all kinds of changes are being done image size to work around this. >>>>>>>>> >>>>>>>>> I would phrase this slightly differently :-) >>>>>>>>> >>>>>>>>> Some code does the right thing, while other code doesn't. E.g.: >>>>>>>>> >>>>>>>>> MultiByteFileStream>>upToEnd is good, while >>>>>>>>> FileStream>>contents is incorrect >>>>>>>>> >>>>>>>>> >>>>>>>>>> I am a strong believer in simple, real (i.e. infinite) streams, but I >>>>>>>>>> am not sure we are doing the right thing here. >>>>>>>>>> >>>>>>>>>> Point is, I am not sure #next returning nil is official and universal. >>>>>>>>>> >>>>>>>>>> Consider the comments: >>>>>>>>>> >>>>>>>>>> Stream>>#next >>>>>>>>>> "Answer the next object accessible by the receiver." >>>>>>>>>> >>>>>>>>>> ReadStream>>#next >>>>>>>>>> "Primitive. Answer the next object in the Stream represented by the >>>>>>>>>> receiver. Fail if the collection of this stream is not an Array or a >>>>>>>>>> String. >>>>>>>>>> Fail if the stream is positioned at its end, or if the position is out >>>>>>>>>> of >>>>>>>>>> bounds in the collection. Optional. See Object documentation >>>>>>>>>> whatIsAPrimitive." >>>>>>>>>> >>>>>>>>>> Note how there is no talk about returning nil ! >>>>>>>>>> >>>>>>>>>> I think we should discuss about this first. >>>>>>>>>> >>>>>>>>>> Was the low level change really correct and the right thing to do ? >>>>>>>>> >>>>>>>>> The primitive change proposed doesn't affect this discussion. It will >>>>>>>>> mean that #atEnd returns false (correctly) sometimes, while currently it >>>>>>>>> returns true (incorrectly). The end result is still incorrect, e.g. >>>>>>>>> #contents returns an empty string for /proc/cpuinfo. >>>>>>>>> >>>>>>>>> You're correct about no mention of nil, but we have: >>>>>>>>> >>>>>>>>> FileStream>>next >>>>>>>>> >>>>>>>>> (position >= readLimit and: [self atEnd]) >>>>>>>>> ifTrue: [^nil] >>>>>>>>> ifFalse: [^collection at: (position := position + 1)] >>>>>>>>> >>>>>>>>> >>>>>>>>> which has been around for a long time (I suspect, before Pharo existed). >>>>>>>>> >>>>>>>>> Having said that, I think that raising an exception is a better >>>>>>>>> solution, but it is a much, much bigger change than the one I proposed >>>>>>>>> in https://github.com/pharo-project/pharo/pull/1180. >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Alistair >>>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> yes, if you are after universal behavior englobing Unix streams, the >>>>>>>> Exception might be the best way. >>>>>>>> Because on special stream you can't allways say in advance, you have to try. >>>>>>>> That's the solution adopted by authors of Xtreams. >>>>>>>> But there is a runtime penalty associated to it. >>>>>>>> >>>>>>>> The penalty once was so high that my proposal to generalize EndOfStream >>>>>>>> usage was rejected a few years ago by AndreaRaab. >>>>>>>> http://forum.world.st/EndOfStream-unused-td68806.html >>>>>>> >>>>>>> Thanks for this, I'll definitely take a look. >>>>>>> >>>>>>> Do you have a sense of how Denis' suggestion of using an EndOfStream >>>>>>> object would compare? >>>>>>> >>>>>>> It would keep the same coding style, but avoid the problems with nil. >>>>>>> >>>>>>> Thanks, >>>>>>> Alistair >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I have regularly benched Xtreams, but stopped a few years ago. >>>>>>>> Maybe i can excavate and pass on newer VM. >>>>>>>> >>>>>>>> In the mean time, i had experimented a programmable end of stream behavior >>>>>>>> (via a block, or any other valuable) >>>>>>>> http://www.squeaksource.com/XTream.htm >>>>>>>> so as to reconcile performance and universality, but it was a source of >>>>>>>> complexification at implementation side. >>>>>>>> >>>>>>>> Nicolas >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Note also that a Guille introduced something new, #closed which is >>>>>>>>>> related to the difference between having no more elements (maybe right now, >>>>>>>>>> like an open network stream) and never ever being able to produce more data. >>>>>>>>>> >>>>>>>>>> Sven >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > >

April 10, 2018

Re: [Pharo-dev] Executive Programming

by askoh

Ben: I have been thinking along the same lines. Smalltalk is my PersonalOS. Instead of *.bat or *.sh files, I would use Smalltalk to call OS commands directly in methods to do what I want in the OS while using Smalltalk to do the logic. PersonalOS should be able to run on multiple OS's using the same methods to do the same things. So, an easy interface to OS commands and possibly OS APIs would encourage people to use Smalltalk for controlling everything else. Smalltalk would be the center of control and automation from individuals to corporations and beyond. Hopefully, we can get critical mass with this. Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 10, 2018

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

by Eliot Miranda

Hi Sven, On Tue, Apr 10, 2018 at 7:33 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 10 Apr 2018, at 16:13, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > What is a field based date and time? > > This is more of an implementation choice but it has probably influence on > the API as well. > > Field based date/time/datetime objects are like the naive implementation > where each element that we talk about as humans has its own instance > variable. You would store hours, minutes, seconds, nanosecond separately, > as well as year, month, day. > > This is not as efficient as the current implementations, where time is > typically stored as seconds and nanoseconds, and dates as a single julian > day number. > > Still, these are implementation choices. For example, the split between > seconds and nanoseconds is a bit artificial as well (it is so that both > remain SmallIntegers in 32-bit), while in 64-bit this decision could be > revised. > Note that the VM provides times as either 64-bit LargePositiveInteger microseconds from 1901 (32-bits) or 61-bit positive SmallInteger microseconds from 1901 (64-bits), in either UTC or the current time zone. This gives us the following fit-for-purpose limits: DateAndTime fromSeconds: 1 << 64 - 1 // 1000000 586455-01-18T08:01:49-07:00 DateAndTime fromSeconds: SmallInteger maxVal // 1000000 38435-08-17T21:30:06-07:00 Choosing 64-bit nanoseconds doesn't work nearly as well; we run out of bits in 586 years. I don't buy the performance issue of keeping things as SmallIntegers. There is good 64-bit positive integer support in all the 32-bit VMs (e.g. in the interpreter, inlined #+. #- et al all work on a 64-bit integer range). If Pharo does decide to change the internal representation then I suggest that it uses the same representation as the VM. > > On Tue, Apr 10, 2018 at 1:32 PM, Esteban A. Maringolo > > <emaringolo(a)gmail.com> wrote: > >> > >> What is missing in the current Pharo image is a field based > >> Date/DateTime instead of an offset+duration one as it currently is. > >> > >> Why not use Chronos instead? AFAIR Chronos provides that. > >> > >> An alternative would be to implement a "Calendar" (as in > >> Java.util.Calendar [1]), that can exist in parallel with the existing > >> Date class. > >> > >> Regards, > >> > >> [1] https://developer.android.com/reference/java/util/Calendar.html > >> > >> On 10/04/2018 03:30, Stephane Ducasse wrote: > >>> Hi Paul > >>> > >>> I agree and instead of patching the current system I would start using > >>> TDD to design > >>> a new Date package. > >>> > >>> stef > >>> > >>> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebruic(a)gmail.com> > wrote: > >>>> I think #= is a bad selector for Date and should be avoided when > determining > >>>> whether something happens on a date, or whether two dates are the > same. We > >>>> all know March 24th in London covers a different 24 hours than March > 24th in > >>>> Hawaii but Date>>#= does not. > >>>> > >>>> > >>>> > >>>> I think whats needed are more descriptive selectors like > >>>> > >>>> > >>>> Date>>#isSameOnDateAs: aDateOrDateAndTime > >>>> Date>>#overlapsWithDate: aDate > >>>> DateAndTime>>#occursOnDate: aDate > >>>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey > >>>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey > >>>> > >>>> and change Date>>#= to #shouldNotImplement. > >>>> > >>>> > >>>> FWIW I also don't like #offset: as before you send it you know the > timezone > >>>> and after you may let that knowledge be forgotten. Real offsets can > change > >>>> as laws change. > >>>> > >>>> > >>>> > >>>> I think people are aware of this but if you have need for comparing > dates & > >>>> times then you must use a library that accesses the regularly updated > Olson > >>>> timezone database on your system and classes that respect time > zones. Time > >>>> zones are political, and legal definitions of offsets can change hours > >>>> before the DST transition dates & times. > >>>> > >>>> > >>>> I don't think it matters which default timezone you pick for the > image if > >>>> you're not going to take them into account when doing comparisons. > >>>> > >>>> > >>>> Unfortunately there isn't a way to avoid this complexity until DST > goes > >>>> away. > >>>> > >>>> > >>>> There's certainly flaws to how we currently do it and I think > >>>> TimeZoneDatabase and Chronos make good attempts to fix it. I haven't > looked > >>>> at Chalten but would guess its good too. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Sean P. DeNigris wrote > >>>>> I was bitten by this very annoying bug again. As most of us probably > know > >>>>> due > >>>>> to the steady stream of confused ML posts in the past, the bug in > summary > >>>>> is > >>>>> that we have an incomplete timezone implementation that doesn't > properly > >>>>> take into account historical DST changes. This flares up without > warning > >>>>> especially when DST toggles. I created a wiki page to document the > >>>>> situation: https://github.com/seandenigris/pharo/wiki/Time- > Zone-Fiasco > >>>>> > >>>>> Here's an example blowup: at 11:59pm before DST changes, eval aDate > := > >>>>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self > assert: > >>>>> '1/1/1901' asDate = aDate andâ¦ whammo, an exception! The "different" > >>>>> offsets > >>>>> render equal dates unequal depending on when the objects were > created. > >>>>> > >>>>> The more I think about it, the more I think that we should just > assume UTC > >>>>> for all Date[AndTime]s that don't explicitly specify an offset, > rather > >>>>> than > >>>>> pretend to set an offset which is only sometimes correct. More > advanced > >>>>> users can use one of the available libraries to get full timezone > support. > >>>>> What do you think? > >>>>> > >>>>> > >>>>> > >>>>> ----- > >>>>> Cheers, > >>>>> Sean > >>>>> -- > >>>>> Sent from: http://forum.world.st/Pharo- > Smalltalk-Developers-f1294837.html > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > >>>> > >>> > >> > >> -- > >> Esteban A. Maringolo > >> > > > > > -- _,,,^..^,,,_ best, Eliot

April 10, 2018

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

by Sven Van Caekenberghe

I have trouble understanding your problem analysis, and how your proposed solution, would solve it. Where is it being said that #next and/or #atEnd should be blocking or non-blocking ? How is this related to how EOF is signalled ? 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. Reading from stdin seems like a very rare case for a Smalltalk system (not that it should not be possible). I have a feeling that too much functionality is being pushed into too small an API. > On 10 Apr 2018, at 18:30, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > First a quick update: > > After doing some work on primitiveFileAtEnd, #atEnd now answers > correctly for files that don't report their size correctly, e.g. > /dev/urandom and /proc/cpuinfo, whether the files are opened directly or > redirected through stdin. > > However determining whether stdin from a terminal has reached the end of > file can't be done without making #atEnd blocking since we have to wait > for the user to flag the end of file, e.g. by typing Ctrl-D. And #atEnd > is assumed to be non-blocking. > > So currently using ZnCharacterReadStream with stdin from a terminal will > result in a stack dump similar to: > > MessageNotUnderstood: receiver of "<" is nil > UndefinedObject(Object)>>doesNotUnderstand: #< > ZnUTF8Encoder>>nextCodePointFromStream: > ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream: > ZnCharacterReadStream>>nextElement > ZnCharacterReadStream(ZnEncodedReadStream)>>next > UndefinedObject>>DoIt > > > Going back through the various suggestions that have been made regarding > using a sentinel object vs. raising a notification / exception, my > (still to be polished) suggestion is to: > > 1. Add an endOfStream instance variable > 2. When the end of the stream is reached answer the value of the > instance variable (i.e. the result of sending #value to the variable). > 3. The initial default value would be a block that raises a Deprecation > warning and then returns nil. This would allow existing code to > function for a changeover period. > 4. At the end of the deprecation period the default value would be > changed to a unique sentinel object which would answer itself as its > #value. > > At any time users of the stream can set their own sentinel, including a > block that raises an exception. > > > Cheers, > Alistair > > > On 4 April 2018 at 19:24, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Thanks for this discussion. >> >> On Wed, Apr 4, 2018 at 1:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Alistair, >>> >>> First off, thanks for the discussions and your contributions, I really appreciate them. >>> >>> But I want to have a discussion at the high level of the definition and semantics of the stream API in Pharo. >>> >>>> On 4 Apr 2018, at 13:20, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>> >>>> On 4 April 2018 at 12:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> Playing a bit devil's advocate, the idea is that, in general, >>>>> >>>>> [ stream atEnd] whileFalse: [ stream next. "..." ]. >>>>> >>>>> is no longer allowed ? >>>> >>>> It hasn't been allowed "forever" [1]. It's just been misused for >>>> almost as long. >>>> >>>> [1] Time began when stdio stream support was introduced. :-) >>> >>> I am still not convinced. Another way to put it would be that the old #atEnd or #upToEnd do not make sense for these streams and some new loop is needed, based on a new test (it exists for socket streams already). >>> >>> [ stream isDataAvailable ] whileTrue: [ stream next ] >>> >>>>> And you want to replace it with >>>>> >>>>> [ stream next ifNil: [ false ] ifNotNil: [ :x | "..." true ] whileTrue. >>>>> >>>>> That is a pretty big change, no ? >>>> >>>> That's the way quite a bit of code already operates. >>>> >>>> As Denis pointed out, it's obviously problematic in the general sense, >>>> since nil can be embedded in non-byte oriented streams. I suspect >>>> that in practice not many people write code that reads streams from >>>> both byte oriented and non-byte oriented streams. >>> >>> Maybe yes, maybe no. As Denis' example shows there is a clear definition problem. >>> >>> And I do use streams of byte arrays or strings all the time, this is really important. I want my parsers to work on all kinds of streams. >>> >>>>> I think/feel like a proper EOF exception would be better, more correct. >>>>> >>>>> [ [ stream next. "..." true ] on: EOF do: [ false ] ] whileTrue. >>>> >>>> I agree, but the email thread Nicolas pointed to raises some >>>> performance questions about this approach. It should be >>>> straightforward to do a basic performance comparison which I'll get >>>> around to if other objections aren't raised. >>> >>> Reading in bigger blocks, using #readInto:startingAt:count: (which is basically Unix's (2) Read sys call), would solve performance problems, I think. >>> >>>>> Will we throw away #atEnd then ? Do we need it if we cannot use it ? >>>> >>>> Unix file i/o returns EOF if the end of file has been reach OR if an >>>> error occurs. You should still check #atEnd after reading past the >>>> end of the file to make sure no error occurred. Another part of the >>>> primitive change I'm proposing is to return additional information >>>> about what went wrong in the event of an error. >>> >>> I am sorry, but this kind of semantics (the OR) is way too complex at the general image level, it is too specific and based on certain underlying implementation details. >>> >>> Sven >>> >>>> We could modify the read primitive so that it fails if an error has >>>> occurred, and then #atEnd wouldn't be required. >>>> >>>> Cheers, >>>> Alistair >>>> >>>> >>>> >>>>>> On 4 Apr 2018, at 12:41, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>> >>>>>> Hi Nicolas, >>>>>> >>>>>> On 4 April 2018 at 12:36, Nicolas Cellier >>>>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> 2018-04-04 12:18 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >>>>>>>> >>>>>>>> Hi Sven, >>>>>>>> >>>>>>>> On Wed, Apr 04, 2018 at 11:32:02AM +0200, Sven Van Caekenberghe wrote: >>>>>>>>> Somehow, somewhere there was a change to the implementation of the >>>>>>>>> primitive called by some streams' #atEnd. >>>>>>>> >>>>>>>> That's a proposed change by me, but it hasn't been integrated yet. So >>>>>>>> the discussion below should apply to the current stable vm (from August >>>>>>>> last year). >>>>>>>> >>>>>>>> >>>>>>>>> IIRC, someone said it is implemented as 'remaining size being zero' >>>>>>>>> and some virtual unix files like /dev/random are zero sized. >>>>>>>> >>>>>>>> Currently, for files other than sdio (stdout, stderr, stdin) it is >>>>>>>> effectively defined as: >>>>>>>> >>>>>>>> atEnd := stream position >= stream size >>>>>>>> >>>>>>>> >>>>>>>> And, as you say, plenty of virtual unix files report size 0. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Now, all kinds of changes are being done image size to work around this. >>>>>>>> >>>>>>>> I would phrase this slightly differently :-) >>>>>>>> >>>>>>>> Some code does the right thing, while other code doesn't. E.g.: >>>>>>>> >>>>>>>> MultiByteFileStream>>upToEnd is good, while >>>>>>>> FileStream>>contents is incorrect >>>>>>>> >>>>>>>> >>>>>>>>> I am a strong believer in simple, real (i.e. infinite) streams, but I >>>>>>>>> am not sure we are doing the right thing here. >>>>>>>>> >>>>>>>>> Point is, I am not sure #next returning nil is official and universal. >>>>>>>>> >>>>>>>>> Consider the comments: >>>>>>>>> >>>>>>>>> Stream>>#next >>>>>>>>> "Answer the next object accessible by the receiver." >>>>>>>>> >>>>>>>>> ReadStream>>#next >>>>>>>>> "Primitive. Answer the next object in the Stream represented by the >>>>>>>>> receiver. Fail if the collection of this stream is not an Array or a >>>>>>>>> String. >>>>>>>>> Fail if the stream is positioned at its end, or if the position is out >>>>>>>>> of >>>>>>>>> bounds in the collection. Optional. See Object documentation >>>>>>>>> whatIsAPrimitive." >>>>>>>>> >>>>>>>>> Note how there is no talk about returning nil ! >>>>>>>>> >>>>>>>>> I think we should discuss about this first. >>>>>>>>> >>>>>>>>> Was the low level change really correct and the right thing to do ? >>>>>>>> >>>>>>>> The primitive change proposed doesn't affect this discussion. It will >>>>>>>> mean that #atEnd returns false (correctly) sometimes, while currently it >>>>>>>> returns true (incorrectly). The end result is still incorrect, e.g. >>>>>>>> #contents returns an empty string for /proc/cpuinfo. >>>>>>>> >>>>>>>> You're correct about no mention of nil, but we have: >>>>>>>> >>>>>>>> FileStream>>next >>>>>>>> >>>>>>>> (position >= readLimit and: [self atEnd]) >>>>>>>> ifTrue: [^nil] >>>>>>>> ifFalse: [^collection at: (position := position + 1)] >>>>>>>> >>>>>>>> >>>>>>>> which has been around for a long time (I suspect, before Pharo existed). >>>>>>>> >>>>>>>> Having said that, I think that raising an exception is a better >>>>>>>> solution, but it is a much, much bigger change than the one I proposed >>>>>>>> in https://github.com/pharo-project/pharo/pull/1180. >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alistair >>>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> yes, if you are after universal behavior englobing Unix streams, the >>>>>>> Exception might be the best way. >>>>>>> Because on special stream you can't allways say in advance, you have to try. >>>>>>> That's the solution adopted by authors of Xtreams. >>>>>>> But there is a runtime penalty associated to it. >>>>>>> >>>>>>> The penalty once was so high that my proposal to generalize EndOfStream >>>>>>> usage was rejected a few years ago by AndreaRaab. >>>>>>> http://forum.world.st/EndOfStream-unused-td68806.html >>>>>> >>>>>> Thanks for this, I'll definitely take a look. >>>>>> >>>>>> Do you have a sense of how Denis' suggestion of using an EndOfStream >>>>>> object would compare? >>>>>> >>>>>> It would keep the same coding style, but avoid the problems with nil. >>>>>> >>>>>> Thanks, >>>>>> Alistair >>>>>> >>>>>> >>>>>> >>>>>>> I have regularly benched Xtreams, but stopped a few years ago. >>>>>>> Maybe i can excavate and pass on newer VM. >>>>>>> >>>>>>> In the mean time, i had experimented a programmable end of stream behavior >>>>>>> (via a block, or any other valuable) >>>>>>> http://www.squeaksource.com/XTream.htm >>>>>>> so as to reconcile performance and universality, but it was a source of >>>>>>> complexification at implementation side. >>>>>>> >>>>>>> Nicolas >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Note also that a Guille introduced something new, #closed which is >>>>>>>>> related to the difference between having no more elements (maybe right now, >>>>>>>>> like an open network stream) and never ever being able to produce more data. >>>>>>>>> >>>>>>>>> Sven >>>>> >>>>> >>>> >>> >>> >> >

April 10, 2018

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

by Alistair Grant

First a quick update: After doing some work on primitiveFileAtEnd, #atEnd now answers correctly for files that don't report their size correctly, e.g. /dev/urandom and /proc/cpuinfo, whether the files are opened directly or redirected through stdin. However determining whether stdin from a terminal has reached the end of file can't be done without making #atEnd blocking since we have to wait for the user to flag the end of file, e.g. by typing Ctrl-D. And #atEnd is assumed to be non-blocking. So currently using ZnCharacterReadStream with stdin from a terminal will result in a stack dump similar to: MessageNotUnderstood: receiver of "<" is nil UndefinedObject(Object)>>doesNotUnderstand: #< ZnUTF8Encoder>>nextCodePointFromStream: ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream: ZnCharacterReadStream>>nextElement ZnCharacterReadStream(ZnEncodedReadStream)>>next UndefinedObject>>DoIt Going back through the various suggestions that have been made regarding using a sentinel object vs. raising a notification / exception, my (still to be polished) suggestion is to: 1. Add an endOfStream instance variable 2. When the end of the stream is reached answer the value of the instance variable (i.e. the result of sending #value to the variable). 3. The initial default value would be a block that raises a Deprecation warning and then returns nil. This would allow existing code to function for a changeover period. 4. At the end of the deprecation period the default value would be changed to a unique sentinel object which would answer itself as its #value. At any time users of the stream can set their own sentinel, including a block that raises an exception. Cheers, Alistair On 4 April 2018 at 19:24, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks for this discussion. > > On Wed, Apr 4, 2018 at 1:37 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Alistair, >> >> First off, thanks for the discussions and your contributions, I really appreciate them. >> >> But I want to have a discussion at the high level of the definition and semantics of the stream API in Pharo. >> >>> On 4 Apr 2018, at 13:20, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> On 4 April 2018 at 12:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Playing a bit devil's advocate, the idea is that, in general, >>>> >>>> [ stream atEnd] whileFalse: [ stream next. "..." ]. >>>> >>>> is no longer allowed ? >>> >>> It hasn't been allowed "forever" [1]. It's just been misused for >>> almost as long. >>> >>> [1] Time began when stdio stream support was introduced. :-) >> >> I am still not convinced. Another way to put it would be that the old #atEnd or #upToEnd do not make sense for these streams and some new loop is needed, based on a new test (it exists for socket streams already). >> >> [ stream isDataAvailable ] whileTrue: [ stream next ] >> >>>> And you want to replace it with >>>> >>>> [ stream next ifNil: [ false ] ifNotNil: [ :x | "..." true ] whileTrue. >>>> >>>> That is a pretty big change, no ? >>> >>> That's the way quite a bit of code already operates. >>> >>> As Denis pointed out, it's obviously problematic in the general sense, >>> since nil can be embedded in non-byte oriented streams. I suspect >>> that in practice not many people write code that reads streams from >>> both byte oriented and non-byte oriented streams. >> >> Maybe yes, maybe no. As Denis' example shows there is a clear definition problem. >> >> And I do use streams of byte arrays or strings all the time, this is really important. I want my parsers to work on all kinds of streams. >> >>>> I think/feel like a proper EOF exception would be better, more correct. >>>> >>>> [ [ stream next. "..." true ] on: EOF do: [ false ] ] whileTrue. >>> >>> I agree, but the email thread Nicolas pointed to raises some >>> performance questions about this approach. It should be >>> straightforward to do a basic performance comparison which I'll get >>> around to if other objections aren't raised. >> >> Reading in bigger blocks, using #readInto:startingAt:count: (which is basically Unix's (2) Read sys call), would solve performance problems, I think. >> >>>> Will we throw away #atEnd then ? Do we need it if we cannot use it ? >>> >>> Unix file i/o returns EOF if the end of file has been reach OR if an >>> error occurs. You should still check #atEnd after reading past the >>> end of the file to make sure no error occurred. Another part of the >>> primitive change I'm proposing is to return additional information >>> about what went wrong in the event of an error. >> >> I am sorry, but this kind of semantics (the OR) is way too complex at the general image level, it is too specific and based on certain underlying implementation details. >> >> Sven >> >>> We could modify the read primitive so that it fails if an error has >>> occurred, and then #atEnd wouldn't be required. >>> >>> Cheers, >>> Alistair >>> >>> >>> >>>>> On 4 Apr 2018, at 12:41, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>> >>>>> Hi Nicolas, >>>>> >>>>> On 4 April 2018 at 12:36, Nicolas Cellier >>>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>> 2018-04-04 12:18 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >>>>>>> >>>>>>> Hi Sven, >>>>>>> >>>>>>> On Wed, Apr 04, 2018 at 11:32:02AM +0200, Sven Van Caekenberghe wrote: >>>>>>>> Somehow, somewhere there was a change to the implementation of the >>>>>>>> primitive called by some streams' #atEnd. >>>>>>> >>>>>>> That's a proposed change by me, but it hasn't been integrated yet. So >>>>>>> the discussion below should apply to the current stable vm (from August >>>>>>> last year). >>>>>>> >>>>>>> >>>>>>>> IIRC, someone said it is implemented as 'remaining size being zero' >>>>>>>> and some virtual unix files like /dev/random are zero sized. >>>>>>> >>>>>>> Currently, for files other than sdio (stdout, stderr, stdin) it is >>>>>>> effectively defined as: >>>>>>> >>>>>>> atEnd := stream position >= stream size >>>>>>> >>>>>>> >>>>>>> And, as you say, plenty of virtual unix files report size 0. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Now, all kinds of changes are being done image size to work around this. >>>>>>> >>>>>>> I would phrase this slightly differently :-) >>>>>>> >>>>>>> Some code does the right thing, while other code doesn't. E.g.: >>>>>>> >>>>>>> MultiByteFileStream>>upToEnd is good, while >>>>>>> FileStream>>contents is incorrect >>>>>>> >>>>>>> >>>>>>>> I am a strong believer in simple, real (i.e. infinite) streams, but I >>>>>>>> am not sure we are doing the right thing here. >>>>>>>> >>>>>>>> Point is, I am not sure #next returning nil is official and universal. >>>>>>>> >>>>>>>> Consider the comments: >>>>>>>> >>>>>>>> Stream>>#next >>>>>>>> "Answer the next object accessible by the receiver." >>>>>>>> >>>>>>>> ReadStream>>#next >>>>>>>> "Primitive. Answer the next object in the Stream represented by the >>>>>>>> receiver. Fail if the collection of this stream is not an Array or a >>>>>>>> String. >>>>>>>> Fail if the stream is positioned at its end, or if the position is out >>>>>>>> of >>>>>>>> bounds in the collection. Optional. See Object documentation >>>>>>>> whatIsAPrimitive." >>>>>>>> >>>>>>>> Note how there is no talk about returning nil ! >>>>>>>> >>>>>>>> I think we should discuss about this first. >>>>>>>> >>>>>>>> Was the low level change really correct and the right thing to do ? >>>>>>> >>>>>>> The primitive change proposed doesn't affect this discussion. It will >>>>>>> mean that #atEnd returns false (correctly) sometimes, while currently it >>>>>>> returns true (incorrectly). The end result is still incorrect, e.g. >>>>>>> #contents returns an empty string for /proc/cpuinfo. >>>>>>> >>>>>>> You're correct about no mention of nil, but we have: >>>>>>> >>>>>>> FileStream>>next >>>>>>> >>>>>>> (position >= readLimit and: [self atEnd]) >>>>>>> ifTrue: [^nil] >>>>>>> ifFalse: [^collection at: (position := position + 1)] >>>>>>> >>>>>>> >>>>>>> which has been around for a long time (I suspect, before Pharo existed). >>>>>>> >>>>>>> Having said that, I think that raising an exception is a better >>>>>>> solution, but it is a much, much bigger change than the one I proposed >>>>>>> in https://github.com/pharo-project/pharo/pull/1180. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Alistair >>>>>>> >>>>>> >>>>>> Hi, >>>>>> yes, if you are after universal behavior englobing Unix streams, the >>>>>> Exception might be the best way. >>>>>> Because on special stream you can't allways say in advance, you have to try. >>>>>> That's the solution adopted by authors of Xtreams. >>>>>> But there is a runtime penalty associated to it. >>>>>> >>>>>> The penalty once was so high that my proposal to generalize EndOfStream >>>>>> usage was rejected a few years ago by AndreaRaab. >>>>>> http://forum.world.st/EndOfStream-unused-td68806.html >>>>> >>>>> Thanks for this, I'll definitely take a look. >>>>> >>>>> Do you have a sense of how Denis' suggestion of using an EndOfStream >>>>> object would compare? >>>>> >>>>> It would keep the same coding style, but avoid the problems with nil. >>>>> >>>>> Thanks, >>>>> Alistair >>>>> >>>>> >>>>> >>>>>> I have regularly benched Xtreams, but stopped a few years ago. >>>>>> Maybe i can excavate and pass on newer VM. >>>>>> >>>>>> In the mean time, i had experimented a programmable end of stream behavior >>>>>> (via a block, or any other valuable) >>>>>> http://www.squeaksource.com/XTream.htm >>>>>> so as to reconcile performance and universality, but it was a source of >>>>>> complexification at implementation side. >>>>>> >>>>>> Nicolas >>>>>> >>>>>>> >>>>>>> >>>>>>>> Note also that a Guille introduced something new, #closed which is >>>>>>>> related to the difference between having no more elements (maybe right now, >>>>>>>> like an open network stream) and never ever being able to produce more data. >>>>>>>> >>>>>>>> Sven >>>> >>>> >>> >> >> >

April 10, 2018