February 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

by Sven Van Caekenberghe

> On 4 Feb 2017, at 19:09, stepharong <stepharong(a)free.fr> wrote: > > >>> 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> Hi Nicolai, >>> >>> The FileSystem API is a bit inconsistent, yes. >>> >>> This is how you can use it: >>> >>> (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | >>> out binary. >>> (ZnCharacterWriteStream on: out encoding: #utf8) << 'Ã©lÃ¨ve' ]. >>> >>> (FileLocator temp / 'foo.txt') readStreamDo: [ :in | >>> in binary. >>> ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. >>> >>> (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | >>> (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. >>> >>> There is no #binaryWriteStreamDo: >>> >>> The API around File is more correct, IMHO. >>> >>> Does this help ? >>> >>> Yes, thanks for the fast response. >>> >>> What exactly is your question ? >>> >>> I am looking at the issues with FileList, there are some parts that don't work anymore (see FileList>>#contents, it calls some unimplemted methods), and it uses TextConverter and somoe parts of the older File api. >>> It looks like most other (newer) parts are using ZnCharacterReadstream for encoding, but I couldn't find a way to use it together with FileReferences (most parts of the FileList already operate with the newer FileSystem API. >> >> OK. >> >> From my standpoint and understanding, I would always use binary streams with explicit Zn converters, this combination is much easier to understand and better implemented with more features. >> >> If you encounter any problem or have any questions, I will gladly try to help you. > > Sven > > I really think that we should clean and improve on this side. > What would be a roadmap? > > - Improve filesystem API to call Zn > - Deprecated other users? (what are they?) > - what would be the next steps? > > Stef Guilermo's new File class with its simple binary streams can be perfectly combined (stacked) with Zn character encoding streams. A first step would be to make FileSystem return/produce those stacked streams. I even believe there is a prototype integrating this. I believe you are one (the ?) author of Nile, so you know very well how complex stream users are - that is the challenge. Authors of parsers or protocols that depend on streams should write to minimal API's, only using what they really need. Sven

Feb. 4, 2017

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

by Thierry Goubier

Le 04/02/2017 Ã 19:09, stepharong a Ã©crit : > >>> 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> Hi Nicolai, >>> >>> The FileSystem API is a bit inconsistent, yes. >>> >>> This is how you can use it: >>> >>> (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | >>> out binary. >>> (ZnCharacterWriteStream on: out encoding: #utf8) << 'Ã©lÃ¨ve' ]. >>> >>> (FileLocator temp / 'foo.txt') readStreamDo: [ :in | >>> in binary. >>> ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. >>> >>> (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | >>> (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. >>> >>> There is no #binaryWriteStreamDo: >>> >>> The API around File is more correct, IMHO. >>> >>> Does this help ? >>> >>> Yes, thanks for the fast response. >>> >>> What exactly is your question ? >>> >>> I am looking at the issues with FileList, there are some parts that >>> don't work anymore (see FileList>>#contents, it calls some >>> unimplemted methods), and it uses TextConverter and somoe parts of >>> the older File api. >>> It looks like most other (newer) parts are using >>> ZnCharacterReadstream for encoding, but I couldn't find a way to use >>> it together with FileReferences (most parts of the FileList already >>> operate with the newer FileSystem API. >> >> OK. >> >> From my standpoint and understanding, I would always use binary >> streams with explicit Zn converters, this combination is much easier >> to understand and better implemented with more features. >> >> If you encounter any problem or have any questions, I will gladly try >> to help you. > > Sven > > I really think that we should clean and improve on this side. > What would be a roadmap? > > - Improve filesystem API to call Zn > - Deprecated other users? (what are they?) > - what would be the next steps? Have one mode that autoselect another encoding (TZ aware of course) if UTF-8 fails... I'm having that one regularly with a mix of utf-8 / latin1 files, i.e. C files with french accentuated comments in them. Thierry > Stef > >

Feb. 4, 2017

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

by stepharong

>> 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Hi Nicolai, >> >> The FileSystem API is a bit inconsistent, yes. >> >> This is how you can use it: >> >> (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | >> out binary. >> (ZnCharacterWriteStream on: out encoding: #utf8) << 'Ã©lÃ¨ve' ]. >> >> (FileLocator temp / 'foo.txt') readStreamDo: [ :in | >> in binary. >> ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. >> >> (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | >> (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. >> >> There is no #binaryWriteStreamDo: >> >> The API around File is more correct, IMHO. >> >> Does this help ? >> >> Yes, thanks for the fast response. >> >> What exactly is your question ? >> >> I am looking at the issues with FileList, there are some parts that >> don't work anymore (see FileList>>#contents, it calls some unimplemted >> methods), and it uses TextConverter and somoe parts of the older File >> api. >> It looks like most other (newer) parts are using ZnCharacterReadstream >> for encoding, but I couldn't find a way to use it together with >> FileReferences (most parts of the FileList already operate with the >> newer FileSystem API. > > OK. > > From my standpoint and understanding, I would always use binary streams > with explicit Zn converters, this combination is much easier to > understand and better implemented with more features. > > If you encounter any problem or have any questions, I will gladly try to > help you. Sven I really think that we should clean and improve on this side. What would be a roadmap? - Improve filesystem API to call Zn - Deprecated other users? (what are they?) - what would be the next steps? Stef

Feb. 4, 2017

Re: [Pharo-dev] Pharo 6 update catalog entries

by Sven Van Caekenberghe

> On 4 Feb 2017, at 16:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > kilon.alios wrote >> Time to make sure they work as expected. > > And tag them #'Pharo6.0' once it's released. In the process of loading > ChronosManager from the Catalog in Pharo 5, I got a warning that it was not > marked as safe (sorry I forgot to tell you!). It ended up loading and > working AFAICT. Euh, no, the configs must be copied into MetaRepoForPharo60, this is the way they are 'blessed', AFAIU. > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-6-update-catalog-entries-tp4932354p4932978.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 4, 2017

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

by Ben Coman

> On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> Just curious what the magic numbers here relate to... >> and can they be factored out to a meaningful method name? >> >> Context>>gtInspectorVariableValuePairs >> "This is a helper method that returns a collection of >> variable_name -> value >> for the current object. >> Subclasses can override it to specialize what appears in the variables >> presentation" >> | bindings | >> bindings := OrderedCollection new. >> 1 to: (self basicSize min: 21) do: [ :index | >> bindings add: (index "asString""asTwoCharacterString" -> (self basicAt: >> index)) ]. >> ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index | "self >> haltIf: [ index = 99 ]." >> bindings add: (index "asString" -> (self basicAt: index)) ]. >> bindings >> addAll: ((self class allSlots >> collect: [ :slot | slot name -> (slot read: self) ]) sort >> asOrderedCollection). >> ^ bindings >> >> >> cheers -ben > > On Fri, Feb 3, 2017 at 11:20 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Yes these numbers should be refactored > For collections only the first and the last 21 elements are displayed in the > Raw view. Don't remember why 21. > > Cheers, > Andrei > Ahhh. Nice to know. Here I was thinking it was based on some intrinsic restriction on the number of variables or something. I'm a fan of overusing redundant variables for documenting purposes... Object>>gtInspectorVariableValuePairs | indexableDisplayLimit bottom topLimit bottomLimit bindings | indexableDisplayLimit := 21. top := 1. bottom := self basicSize. topLimit := bottom min: indexableDisplayLimit. bottomLimit := (bottom - indexableDisplayLimit) max: indexableDisplayLimit. bindings := OrderedCollection new. "Return top and bottom of indexable elements" top to: topLimit do: [ :index | bindings add: (index -> (self basicAt: index)) ]. bottomLimit + 1 to: bottom do: [ :index | bindings add: (index -> (self basicAt: index)) ]. "Return named variables" bindings addAll: ((self class allSlots collect: [ :slot | slot name -> (slot read: self) ]) sort asOrderedCollection). ^ bindings If this looks reasonable I'll do up a slice. Perhaps defining "top" is overkill - but it does read nice below that. btw, in general I understand that some smart optimising compilers will substitute 1 for "top" directly since its assigned a literal and not reassigned before its use. I notice from the bytecode this doesn't happen here. Is there some intrinsic difficulty in our domain stopping this to happen, or its just not been a priority. I guess while stepping through the debugger "top" a user might set a new value for "top" and reverting the substitution of "1" for "top" needs the sort of facility that Sista will provide?? On Sat, Feb 4, 2017 at 12:08 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > There is very little meaning behind the number. > > The previous inspector showed the first 100 and the last 10 elements. 100 > is anyway too large for a quick inspection, so we picked another number. I > wanted 42 but that was still large, so we are now at 21. Well 21 top and bottom gives you 42, and I know life, the universe and everything depends on that number - so this seems reasonable. On Sat, Feb 4, 2017 at 12:39 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > They could be extracted to class vars for example TWENTY_ONE := 21. Later > if performance is still not good enough they may be changed for example to > TWENTY_ONE := 15. > (joke) > You mean something like this... https://xkcd.com/221/ cheers -ben

Feb. 4, 2017

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

by Sean P. DeNigris

Aliaksei Syrel wrote > Later if performance is still not good enough they may be changed for > example to > TWENTY_ONE := 15. Ha ha ha! ----- Cheers, Sean -- View this message in context: http://forum.world.st/magic-numbers-in-gtInspectorVariableValuePairs-tp4932… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 4, 2017

Re: [Pharo-dev] Pharo 6 update catalog entries

by Sean P. DeNigris

kilon.alios wrote > Time to make sure they work as expected. And tag them #'Pharo6.0' once it's released. In the process of loading ChronosManager from the Catalog in Pharo 5, I got a warning that it was not marked as safe (sorry I forgot to tell you!). It ended up loading and working AFAICT. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-6-update-catalog-entries-tp4932354p4932978.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 4, 2017

Re: [Pharo-dev] GTDebugger variables table

by stepharong

On Thu, 02 Feb 2017 17:16:49 +0100, John Brant <brant(a)refactoryworkers.com> wrote: > On 02/02/2017 04:22 AM, Denis Kudriashov wrote: > >> Now I think I realized main reason of my confusion. Temps and receiver >> vars are not just in single table but they are also sorted by name all >> together. > > I'm not a fan of this either. While I can filter by the type of variable > to limit the list, the next time I step the debugger, the whole list > resets. The list filter and selection should be kept across steps in the > debugger (if possible). > > Some might argue that you should have fewer variables so the list would > be easier to use in the debugger. However, if you are using the > debugger, likely you are still in the "make it work" phase and haven't > performed the factoring from the "make it right" phase. + 1 and under stress > I think my preference would be to have several tabs for the variables. > In addition to the one tab that we have now that shows all variables, I > can think of tabs for locals, inst vars, interesting variables, watched > variables/expressions, and stack variables. Locals would show just the > method/block arguments and any temps defined in the method. Inst vars > would show the object's inst vars (and maybe class vars, however these > would only appear after the inst vars). > > Interesting variables would show locals and inst vars used by the > method. The locals would be limited to the ones that are still active at > the current location in the method. For example, if you are in a block, > it would only show variables used in the block. Also, if you are > before(/after) the first(/final) use of the variable, it wouldn't show > in the interesting list. Interesting variables should also do some > analysis to see what accessor methods are used and show their > corresponding variables. I like that > > Watched variables/expressions would be user controlled. The user could > add/remove variables or expressions. These variables/expressions would > remain across different methods. If a variable didn't exist in the other > method, "Invalid" could be displayed. > > Finally, stack variables would display the whole stack and not just the > top item. I like the ability to see the stack top, but it really doesn't > work if you want to see the first argument of a two argument message > send. For example, if you debug "Array with: OrderedCollection new with: > Set new", stepping over the "OrderedCollection new" immediately pushes > the "Set" class on the stack so you can't see the "OrderedCollection > new" object. I like that now when we have too many tabs it often happens that only two are useful. > > > BTW, the current variable list sometimes shows 'error obtaining field > value' for temporaries when stepping through a method. I'm not sure why > it occurs, but it should always be able to display the temp variables. > > > John Brant > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 4, 2017

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

by Sven Van Caekenberghe

> On 4 Feb 2017, at 13:01, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Nicolai, > > The FileSystem API is a bit inconsistent, yes. > > This is how you can use it: > > (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | > out binary. > (ZnCharacterWriteStream on: out encoding: #utf8) << 'Ã©lÃ¨ve' ]. > > (FileLocator temp / 'foo.txt') readStreamDo: [ :in | > in binary. > ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | > (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > There is no #binaryWriteStreamDo: > > The API around File is more correct, IMHO. > > Does this help ? > > Yes, thanks for the fast response. > > What exactly is your question ? > > I am looking at the issues with FileList, there are some parts that don't work anymore (see FileList>>#contents, it calls some unimplemted methods), and it uses TextConverter and somoe parts of the older File api. > It looks like most other (newer) parts are using ZnCharacterReadstream for encoding, but I couldn't find a way to use it together with FileReferences (most parts of the FileList already operate with the newer FileSystem API. OK. >From my standpoint and understanding, I would always use binary streams with explicit Zn converters, this combination is much easier to understand and better implemented with more features. If you encounter any problem or have any questions, I will gladly try to help you. > Sven > > > On 4 Feb 2017, at 12:09, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > Hi > > How can I specify the character encoding when opening a readStream on a FileRerefence. > > > > I found this, that works: > > > > | readStream fileContent | > > readStream := (File named: aFileName) openForRead. > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > fileContent upToEnd asString. > > > > But if I try to do the same with a readStream from a FileReference > > > > | readStream fileContent | > > readStream := aFileName asFileReference readStream. > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > fileContent upToEnd asString. > > > > I get an error SmallInteger DNU #asciiValue, > > > > this is because, in the first method, we create a binary filestream, and if we > > use readStream from a FileReference, the stream is a MultibyteFileStream. > > > > How can I us ZnEncoder for a readstream from a FileReference? > > > > (and is it on purpose that both readStream method (openForRead/readStream) > > return different kinds of binary streams?) > > > > > > nicolai

Feb. 4, 2017

Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)

by Nicolai Hess

2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Nicolai, > > The FileSystem API is a bit inconsistent, yes. > > This is how you can use it: > > (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | > out binary. > (ZnCharacterWriteStream on: out encoding: #utf8) << 'Ã©lÃ¨ve' ]. > > (FileLocator temp / 'foo.txt') readStreamDo: [ :in | > in binary. > ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | > (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > There is no #binaryWriteStreamDo: > > The API around File is more correct, IMHO. > > Does this help ? > Yes, thanks for the fast response. > What exactly is your question ? > I am looking at the issues with FileList, there are some parts that don't work anymore (see FileList>>#contents, it calls some unimplemted methods), and it uses TextConverter and somoe parts of the older File api. It looks like most other (newer) parts are using ZnCharacterReadstream for encoding, but I couldn't find a way to use it together with FileReferences (most parts of the FileList already operate with the newer FileSystem API. > > Sven > > > On 4 Feb 2017, at 12:09, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > Hi > > How can I specify the character encoding when opening a readStream on a > FileRerefence. > > > > I found this, that works: > > > > | readStream fileContent | > > readStream := (File named: aFileName) openForRead. > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > fileContent upToEnd asString. > > > > But if I try to do the same with a readStream from a FileReference > > > > | readStream fileContent | > > readStream := aFileName asFileReference readStream. > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > fileContent upToEnd asString. > > > > I get an error SmallInteger DNU #asciiValue, > > > > this is because, in the first method, we create a binary filestream, and > if we > > use readStream from a FileReference, the stream is a MultibyteFileStream. > > > > How can I us ZnEncoder for a readstream from a FileReference? > > > > (and is it on purpose that both readStream method > (openForRead/readStream) > > return different kinds of binary streams?) > > > > > > nicolai > > >

Feb. 4, 2017