- Pharo-dev - lists.pharo.org

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

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > the configs must be copied into MetaRepoForPharo60, this is the way they > are 'blessed', AFAIU. Ah, interesting! I wonder if this represents a bug then, because ChronosManager is in the metarepos for both Pharo 5 and 6, but in Pharo 5 loads the config from the meta-repo-for-6, not 5... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-6-update-catalog-entries-tp4932354p4933019.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 4, 2017

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

by Sven Van Caekenberghe

> On 4 Feb 2017, at 21:14, stepharong <stepharong(a)free.fr> wrote: > > I will talk about guille about his file implementation and we can see what we can do. Yes, that is step 1, here is the issue I was talking about: https://pharo.fogbugz.com/f/cases/18414/Change-usages-of-StandardFileStream… > On Sat, 04 Feb 2017 20:28:07 +0100, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-02-04 19:09 GMT+01:00 stepharong <stepharong(a)free.fr>: > 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? > > Yes, we need remove completely old files code. > Funny that file stream which we use (MultiByteFileStream) is in package 'Files-Deprecated'. > > > Funny thing now is deprecated package tag > > > > -- > 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 stepharong

I will talk about guille about his file implementation and we can see what we can do. On Sat, 04 Feb 2017 20:28:07 +0100, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-02-04 19:09 GMT+01:00 stepharong <stepharong(a)free.fr>: >> 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? > > Yes, we need remove completely old files code. > Funny that file stream which we use (MultiByteFileStream) is in package > 'Files-Deprecated'. > > > Funny thing now is deprecated package tag -- 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 stepharong

> > 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 my point is that if we want to make progress from this front we should slowly improve once we have in place the new version then we can plan for migrating yes it can be tedious and boring but we can do it if we have a plan. Stef

Feb. 4, 2017

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

by Denis Kudriashov

2017-02-04 19:09 GMT+01:00 stepharong <stepharong(a)free.fr>: > 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? Yes, we need remove completely old files code. Funny that file stream which we use (MultiByteFileStream) is in package 'Files-Deprecated'. Funny thing now is deprecated package tag

Feb. 4, 2017

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