November 2017 - Pharo-users

Re: [Pharo-users] extending STON

by Sven Van Caekenberghe

Henry, > On 14 Nov 2017, at 15:02, henry <henry(a)callistohouse.club> wrote: > > Hello, I am trying to extend STON to allow for substitutions as data is written out or read in. On the write side I got it working as #nextPut: is recursively called, so that is the perfect place to substitute before an object is written. I have tested and my changes work well, where I have an arbitrary object as a subObject and it gets substituted out for my Descriptor object. OK good. > I am having difficult on the read side identifying where a substitution lookup should occur after decoding the object on the input stream. I want to inflate the Descritpor object, with its data, and call for a possible substitution. As it is a Descriptor, it should get substituted with the right bits on the read side. I chose to try and do this in the method #setReference:to: and put the substitute into the objects list. This did not work. Where is a good place to look within STON to do a read-side post-substitution? In STONReader>>#parseObject | targetClass reference object | [ reference := self newReference. targetClass := self parseClass. object := targetClass fromSton: self. self setReference: reference to: object ] ... I would try just re-assigning object with your custom substitute. Like this MySTONReader>>#parseObject | targetClass reference object | [ reference := self newReference. targetClass := self parseClass. object := targetClass fromSton: self. object := object resolveSubstitution. self setReference: reference to: object ] ... The references are used if the same (#==) object is used twice, then you get something like STON fromString: '[Point[1,2],@2]'. which is an 2 element Array where the exact same object is in both positions (structure sharing). This works with circular references too (but be careful because the inspector might loop). HTH, Sven > Thank you. > > - HH > >

Nov. 14, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Tim Mackinnon

Richard - I better understand what you are saying now. If you change the method and save it (hence restarting on the stack) I would expect it to turn green if I press resume. That is the TDD flow I expect, and one which sunit and coding in the debugger was predicated on. However, there is the potential that some memory object that cached a result and is now running a second time could be the cause of a pass and so it is remotely possible that this is a false passâ¦. (And this I think is the crux of your argument - if any memory object is affected, theoretically you should rerun the whole transaction from a virgin state - which is effectively rerun the test from the beginning). So I guess we are discussing that we donât have fully transactional memory executions? However I would argue that its way more common that you edit a method and fix a text and have 0 side effects than mucking around in memory or having something that rerunning locally messes up memory as well. So its much more useful to get the confirmation of green and move on. YES you could have a subtle error, and when you re-run it may later go red - but I would favour the 99% case as its a annoying if you are doing TDD. Tim > On 10 Nov 2017, at 19:45, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > I hear you and I understand your pain. > > However, if you corrected the problem, not by a code change, but by playing in the object's inspector or otherwise causing its internal state to change, and then resumed from the debugger, would you still claim the method was successful and should be coloured green? > > The only thing we can claim is that there were or were not further errors in the test. Colour it red if there were, but you cannot honestly colour it green. The code doesn't actually work. > > > On Fri, Nov 10, 2017 at 11:29 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > My specific usecase is from a pragmatic TDD perspective - failing test, in the debugger you fix the test and press proceed - expecting green. Getting red, and then immediately running again to get red takes away from our story of love coding and loving your debugger - and even Cassie me to mistrust the tools. > > I get the idea that you can jiffy in the debugger and cause a false pass - but I feel you are penalised for doing it right at the moment. > > Of course these tests will get run again, but I like the idea that if I did it right, it should recognise this, not incur an extra click and moment of doubt. > > A button to rerun the whole lot, or automatically rerun, or just run it would work for me. > > Tim > > Sent from my iPhone > > On 10 Nov 2017, at 17:56, Richard Sargent <richard.sargent(a)gemtalksystems.com <mailto:richard.sargent@gemtalksystems.com>> wrote: > >> That would be fine. >> The point is that, without running the test in its entirety, from start to finish, without interruption, error, or failure, one cannot claim success. >> >> On Fri, Nov 10, 2017 at 9:34 AM, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >> Richard Sargent wrote >> > The only reliable conclusion one can make from such an interrupted run is >> > whether it failed again. So, it would be possible to determine that the >> > test should be coloured red, but it is impossible to *reliably* claim that >> > the test should be coloured green. >> >> What if we ran the test again as if from the browser/runner before setting >> the icon? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> >> >> >

Nov. 14, 2017

Re: [Pharo-users] QCMagritte on Github

by Tim Mackinnon

Iâll agree that YAML is not an ideal syntax - but I have to also add that I wasnât that impressed with Travis either, and reading between the lines its the combo of both that might be catching you out. Even with a few glitches, Iâve been impressed with GitLab although the team I worked with recently found that CircleCI was more to their liking. In both cases you have much more control about what is going on. It may be that you need something a bit more heavy duty - and it might be worth checking out some of the alternatives. Tim > On 10 Nov 2017, at 18:20, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > For your information. > We got some problem with travis (what a bad idea to have a syntax like > yaml - our industry is looping , even xml is better). > we spent more than 30 min trying with Guille and Andrew to use bash in > a script section (while this is working in some guille project) > it does not in other just because yaml does not know who to find the > end of a line.... > > Terrible! > > Stef > > On Wed, Nov 8, 2017 at 8:15 AM, stephan <stephan(a)stack.nl> wrote: >> On 27-10-17 12:39, laurent laffont wrote: >>> >>> Hi, >>> >>> my team starts to use QCMagritte. For our needs we have imported >>> SmalltalkHub repository to Github here: >>> https://github.com/Afibre/QCMagritte >>> >>> I don't know if you (Diego, Stephan, Tobias) plan to use Github >>> instead of SmalltalkHub. At least Github allows branches & pull >>> request. >> >> >> Definitely, and I'm still struggling a bit with Iceberg. I would definitely >> favor a setup where the whole open source part is build on each commit using >> travis and images are put on (e.g.) bitbucket. >> The current jenkins builds are waiting for Diego to finish some changes, and >> he is a bit distracted with plans for a new house. >> >> Tobias told me he's also interested, so I assume he'll provide a modified >> baseline for other platforms. >> >> At a certain point we might want to fold all of QCMagritte back into >> Magritte, but that is a discussion for later I think. >> >> Stephan >> >> >

Nov. 14, 2017

Re: [Pharo-users] when a subclass is loaded, is super-class-side>>initialize executed?

by Ben Coman

Thx. Thats exactly what I was looking for. The key part being "self isInitializer" where... isInitializer ^ selector = #initialize and: [classIsMeta] Now I also see "self isExternalStructureFieldDefinition" "Postloading of FFI fields. This code will be called when loading FFI structures that are not by default in the image." Could something similar be done like "self isEnumDecl" ? It would be a minor improvement to not have write up in blog posts that MyFFIExternalEnumeration needs a class-side #initialize simply to do "self initializeEnumeration" when having #enumDecl is a strong convention and indicator that intialization is required. Or is that starting to load up with too many implicit initializations? Alternatively, what consideration has been given to pragmas for class initialization? For example this seems more self contained and explicit.... MyFFIExternalEnumeration class >> enumDecl <classInitialization: #initializeEnumeration> ^ #( EnumA 1 EnumB 2) cheers -ben On 14 November 2017 at 16:40, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > the #initialize message is sent only to the classes that implement this > method. In *.st files it is an explicit call, Monticello does it slightly > smarter way, see MCMethodDefinition>>#postloadOver: > > Cheers, > -- Pavel > > 2017-11-14 3:08 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> Because I'm lazy to experiment this instant (not wanting to get >> distracted from my current track), and also its probably a useful remainder >> for others I'll just ask... >> >> When MyClass is loaded, #initialize is sent to it. Typically the >> class-side>>initialize should not call "super initialize" to avoid >> re-initializing the superclaass, but what if MyClass doesn't implement >> #initialize? Does the message fall through to the superclass, or is >> #initialize only sent if MyClass implements it? >> >> Concrete example... >> FFIExternalEnumeration subclass MyEnumeration needs to be sent >> #initializeEnumeration when it is loaded. We have... >> >> FFIExternalEnustmeration>>#initialize >> self initializeEnumeration >> >> so is MyEnumeration *required* to implement its own >> MyEnumeration>>#initialize, or can it rely FFIExternalEnustmeration>>#initialize. >> I believe it is the former, but just wanted to confirm my understanding. >> >> cheers -ben >> >> >> >

Nov. 14, 2017

extending STON

by henry

Hello, I am trying to extend STON to allow for substitutions as data is written out or read in. On the write side I got it working as #nextPut: is recursively called, so that is the perfect place to substitute before an object is written. I have tested and my changes work well, where I have an arbitrary object as a subObject and it gets substituted out for my Descriptor object. I am having difficult on the read side identifying where a substitution lookup should occur after decoding the object on the input stream. I want to inflate the Descritpor object, with its data, and call for a possible substitution. As it is a Descriptor, it should get substituted with the right bits on the read side. I chose to try and do this in the method #setReference:to: and put the substitute into the objects list. This did not work. Where is a good place to look within STON to do a read-side post-substitution? Thank you. - HH

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Denis Kudriashov

2017-11-14 14:25 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > Yes, Zn streams focus on classic binary(byte) / character streams. > > > > Streaming over arbitrary data is very cool and well covered by the old > ones. > > > > While I really like traditional streams I can not agree here. Sometimes > it reminds me poor java collections which force writing loops all the time. > > For example the most common task in my experience was writing contents > of read stream into write stream. And the only possibility now is loop. > > From this point of view XStreams really pushes streams to the level of > smalltalk collections. > > Yes, I agree, Xtreams is much better (but steep learning curve). > > I just wanted to point out that my contributions in Zn streams focus and > better/simpler byte/character IO. > Yes, and it is really nice. Interesting how many users we have in system for general streams? (created on arbitrary collections). >From first look the main users are #printOn: methods. But they use string based, so they are not general. What others we have? > > Improvement on the classic streams are, of course, welcome. > > > > About contribution: it is in external repository of Sven. Can we > contribute with normal process, create pull request into Pharo repo? > > > > > > 2017-11-14 9:36 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com > >: > > > To a package next to block? > > > > > > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov < > dionisiydk(a)gmail.com> wrote: > > > What about contributing to zinc streams? Imaging that I will create > block based streams, collecting:/selecting streams like in XSteam. Where I > should put them? > > > > > > > > > 2017-11-13 23:51 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > > > > > > > > > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse < > stepharo.self(a)gmail.com>: > > > > > > > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe < > sven(a)stfx.eu> wrote: > > > >> The idea is to have much simpler streams which can be composed to > get more sophisticated behaviour. > > > >> > > > >> The most primitive streams should be binary read or write streams, > like a raw file or network connection. > > > >> > > > >> To add a character encoding/decoding you wrap them in a > ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, > cleaner ZnCharacterEncoders). > > > > > > > > Yes really nice :) > > > > > > > > And Guille started to use them and we are slowly rewriting all the > > > > stream internal users to use Zn and after we will be free. > > > > > > > > > > > No, you will depend on zinc classes. How is that supposed to work in > bootstrap? > > > > > > Norbert > > > >> If you want buffering, you wrap a ZnBufferedReadStream or > ZnBufferedWriteStream around them. > > > >> > > > >> And there are some other examples in the system too. > > > >> > > > >> Have a look at BinaryFileStream and ZdcSocketStream. > > > >> > > > >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream > must die, because they try to be everything at once and are impossible to > change. > > > > > > > > > > > > YES YES YES and celebrate. I could never understand anything. My > brain > > > > is too limited for these kind of games :) > > > > > > > > > > > > > > > >> The contract of a stream should be much, much simpler than it is > today. > > > > > > > > Fully agree. > > > > > > > >> > > > >> For writing that means > > > >> > > > >> #nextPut: > > > >> #nextPutAll: > > > >> #next:putAll: > > > >> #next:putAll:startingAt: > > > >> > > > >> the 3 last ones can be written in terms of of the first one, but > the last one is key because it can be the most efficient. > > > >> And maybe also > > > >> > > > >> #flush > > > >> #close > > > >> > > > >> Some helpers for character writing are > > > >> > > > >> #space > > > >> #tab > > > >> #cr > > > >> #crlf > > > >> #lf > > > >> > > > >> Maybe #newline > > > > > > > > :) > > > > > > > > > > > >> > > > >> #<< is a handy method too. > > > >> > > > >> For reading that means > > > >> > > > >> #atEnd > > > >> #next > > > >> #next: > > > >> #next:into: > > > >> #next:into:startingAt: > > > >> #nextInto: > > > >> #peek > > > >> #skip: > > > >> #upToEnd > > > >> #upTo: > > > >> #readInto:startingAt:count: > > > >> > > > >> Again, they can all be written in terms of #next, but > #readInto:startingAt:count: is the core, efficient one. > > > >> Note that #peek allows a one character lookahead, which should be > sufficient for almost all parsing needs. > > > >> > > > >> #close is also a necessary operation, #peekFor: a handy one, > #nextLine is popular too. > > > >> > > > >> There is a discussion about positioning (#position , #position: and > related) but these cannot be supported _in general_ by the kind of streams > described above. > > > >> > > > >> If you absolutely need these, read #upToEnd and use a regular > ReadStream (over a fixed collection). > > > >> > > > >> The collection based classic Streams should always remain in the > system, they are too handy. But have you seen for example, #nextInt32 on > PositionableStream ? Good luck with that when the the underlying collection > is anything other than bytes. > > > >> > > > >> All this being said, there is no one, single correct answer. > > > >> > > > >> But if we all try to simplify what we expect of streams (use a more > limited API), we'll be more nimble to make implementation changes later on. > > > >> > > > >> Sven > > > >> > > > >>> On 13 Nov 2017, at 19:58, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > > > >>> > > > >>> Hi Evan > > > >>> > > > >>> I think that we will use the ZnStreams. > > > >>> If we use Xtreams we will transform their API because some messages > > > >>> are not really good. > > > >>> Stef > > > >>> > > > >>>> On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu(a)gmail.com> > wrote: > > > >>>> I've heard mention once or twice on this list and in some release > notes of > > > >>>> what sounded like possible coming changes to the stream API. > Could anyone > > > >>>> point me to any concrete details about that? I haven't been able > to dig > > > >>>> anything up myself by searching. I'm about to write something > that I'd like > > > >>>> to be polymorphic with the stream API, but if that's about to > change, I'd > > > >>>> like to plan ahead. > > > >>>> > > > >>>> Thanks, > > > >>>> Evan > > > >>> > > > >> > > > >> > > > > > > > > > > > > > > > > > > -- > > > > > > Guille Polito > > > Research Engineer > > > > > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > > CRIStAL - UMR 9189 > > > French National Center for Scientific Research - http://www.cnrs.fr > > > > > > Web: http://guillep.github.io > > > Phone: +33 06 52 70 66 13 > > > > > > > > > > > >

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Sven Van Caekenberghe

> On 14 Nov 2017, at 14:18, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-11-14 14:00 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 14 Nov 2017, at 09:53, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > I look at the code, So Zinc provides only binary/character streams. Right? > > Yes, Zn streams focus on classic binary(byte) / character streams. > > Streaming over arbitrary data is very cool and well covered by the old ones. > > While I really like traditional streams I can not agree here. Sometimes it reminds me poor java collections which force writing loops all the time. > For example the most common task in my experience was writing contents of read stream into write stream. And the only possibility now is loop. > From this point of view XStreams really pushes streams to the level of smalltalk collections. Yes, I agree, Xtreams is much better (but steep learning curve). I just wanted to point out that my contributions in Zn streams focus and better/simpler byte/character IO. Improvement on the classic streams are, of course, welcome. > > About contribution: it is in external repository of Sven. Can we contribute with normal process, create pull request into Pharo repo? > > > > 2017-11-14 9:36 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > To a package next to block? > > > > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > What about contributing to zinc streams? Imaging that I will create block based streams, collecting:/selecting streams like in XSteam. Where I should put them? > > > > > > 2017-11-13 23:51 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > > > > > > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > > > > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> The idea is to have much simpler streams which can be composed to get more sophisticated behaviour. > > >> > > >> The most primitive streams should be binary read or write streams, like a raw file or network connection. > > >> > > >> To add a character encoding/decoding you wrap them in a ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, cleaner ZnCharacterEncoders). > > > > > > Yes really nice :) > > > > > > And Guille started to use them and we are slowly rewriting all the > > > stream internal users to use Zn and after we will be free. > > > > > > > > No, you will depend on zinc classes. How is that supposed to work in bootstrap? > > > > Norbert > > >> If you want buffering, you wrap a ZnBufferedReadStream or ZnBufferedWriteStream around them. > > >> > > >> And there are some other examples in the system too. > > >> > > >> Have a look at BinaryFileStream and ZdcSocketStream. > > >> > > >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must die, because they try to be everything at once and are impossible to change. > > > > > > > > > YES YES YES and celebrate. I could never understand anything. My brain > > > is too limited for these kind of games :) > > > > > > > > > > > >> The contract of a stream should be much, much simpler than it is today. > > > > > > Fully agree. > > > > > >> > > >> For writing that means > > >> > > >> #nextPut: > > >> #nextPutAll: > > >> #next:putAll: > > >> #next:putAll:startingAt: > > >> > > >> the 3 last ones can be written in terms of of the first one, but the last one is key because it can be the most efficient. > > >> And maybe also > > >> > > >> #flush > > >> #close > > >> > > >> Some helpers for character writing are > > >> > > >> #space > > >> #tab > > >> #cr > > >> #crlf > > >> #lf > > >> > > >> Maybe #newline > > > > > > :) > > > > > > > > >> > > >> #<< is a handy method too. > > >> > > >> For reading that means > > >> > > >> #atEnd > > >> #next > > >> #next: > > >> #next:into: > > >> #next:into:startingAt: > > >> #nextInto: > > >> #peek > > >> #skip: > > >> #upToEnd > > >> #upTo: > > >> #readInto:startingAt:count: > > >> > > >> Again, they can all be written in terms of #next, but #readInto:startingAt:count: is the core, efficient one. > > >> Note that #peek allows a one character lookahead, which should be sufficient for almost all parsing needs. > > >> > > >> #close is also a necessary operation, #peekFor: a handy one, #nextLine is popular too. > > >> > > >> There is a discussion about positioning (#position , #position: and related) but these cannot be supported _in general_ by the kind of streams described above. > > >> > > >> If you absolutely need these, read #upToEnd and use a regular ReadStream (over a fixed collection). > > >> > > >> The collection based classic Streams should always remain in the system, they are too handy. But have you seen for example, #nextInt32 on PositionableStream ? Good luck with that when the the underlying collection is anything other than bytes. > > >> > > >> All this being said, there is no one, single correct answer. > > >> > > >> But if we all try to simplify what we expect of streams (use a more limited API), we'll be more nimble to make implementation changes later on. > > >> > > >> Sven > > >> > > >>> On 13 Nov 2017, at 19:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > >>> > > >>> Hi Evan > > >>> > > >>> I think that we will use the ZnStreams. > > >>> If we use Xtreams we will transform their API because some messages > > >>> are not really good. > > >>> Stef > > >>> > > >>>> On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu(a)gmail.com> wrote: > > >>>> I've heard mention once or twice on this list and in some release notes of > > >>>> what sounded like possible coming changes to the stream API. Could anyone > > >>>> point me to any concrete details about that? I haven't been able to dig > > >>>> anything up myself by searching. I'm about to write something that I'd like > > >>>> to be polymorphic with the stream API, but if that's about to change, I'd > > >>>> like to plan ahead. > > >>>> > > >>>> Thanks, > > >>>> Evan > > >>> > > >> > > >> > > > > > > > > > > > > -- > > > > Guille Polito > > Research Engineer > > > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13 > > > > >

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Denis Kudriashov

2017-11-14 14:00 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 14 Nov 2017, at 09:53, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > I look at the code, So Zinc provides only binary/character streams. > Right? > > Yes, Zn streams focus on classic binary(byte) / character streams. > > Streaming over arbitrary data is very cool and well covered by the old > ones. > While I really like traditional streams I can not agree here. Sometimes it reminds me poor java collections which force writing loops all the time. For example the most common task in my experience was writing contents of read stream into write stream. And the only possibility now is loop. >From this point of view XStreams really pushes streams to the level of smalltalk collections. > > > About contribution: it is in external repository of Sven. Can we > contribute with normal process, create pull request into Pharo repo? > > > > 2017-11-14 9:36 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > To a package next to block? > > > > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > What about contributing to zinc streams? Imaging that I will create > block based streams, collecting:/selecting streams like in XSteam. Where I > should put them? > > > > > > 2017-11-13 23:51 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > > > > > > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse < > stepharo.self(a)gmail.com>: > > > > > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > >> The idea is to have much simpler streams which can be composed to get > more sophisticated behaviour. > > >> > > >> The most primitive streams should be binary read or write streams, > like a raw file or network connection. > > >> > > >> To add a character encoding/decoding you wrap them in a > ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, > cleaner ZnCharacterEncoders). > > > > > > Yes really nice :) > > > > > > And Guille started to use them and we are slowly rewriting all the > > > stream internal users to use Zn and after we will be free. > > > > > > > > No, you will depend on zinc classes. How is that supposed to work in > bootstrap? > > > > Norbert > > >> If you want buffering, you wrap a ZnBufferedReadStream or > ZnBufferedWriteStream around them. > > >> > > >> And there are some other examples in the system too. > > >> > > >> Have a look at BinaryFileStream and ZdcSocketStream. > > >> > > >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must > die, because they try to be everything at once and are impossible to change. > > > > > > > > > YES YES YES and celebrate. I could never understand anything. My brain > > > is too limited for these kind of games :) > > > > > > > > > > > >> The contract of a stream should be much, much simpler than it is > today. > > > > > > Fully agree. > > > > > >> > > >> For writing that means > > >> > > >> #nextPut: > > >> #nextPutAll: > > >> #next:putAll: > > >> #next:putAll:startingAt: > > >> > > >> the 3 last ones can be written in terms of of the first one, but the > last one is key because it can be the most efficient. > > >> And maybe also > > >> > > >> #flush > > >> #close > > >> > > >> Some helpers for character writing are > > >> > > >> #space > > >> #tab > > >> #cr > > >> #crlf > > >> #lf > > >> > > >> Maybe #newline > > > > > > :) > > > > > > > > >> > > >> #<< is a handy method too. > > >> > > >> For reading that means > > >> > > >> #atEnd > > >> #next > > >> #next: > > >> #next:into: > > >> #next:into:startingAt: > > >> #nextInto: > > >> #peek > > >> #skip: > > >> #upToEnd > > >> #upTo: > > >> #readInto:startingAt:count: > > >> > > >> Again, they can all be written in terms of #next, but > #readInto:startingAt:count: is the core, efficient one. > > >> Note that #peek allows a one character lookahead, which should be > sufficient for almost all parsing needs. > > >> > > >> #close is also a necessary operation, #peekFor: a handy one, > #nextLine is popular too. > > >> > > >> There is a discussion about positioning (#position , #position: and > related) but these cannot be supported _in general_ by the kind of streams > described above. > > >> > > >> If you absolutely need these, read #upToEnd and use a regular > ReadStream (over a fixed collection). > > >> > > >> The collection based classic Streams should always remain in the > system, they are too handy. But have you seen for example, #nextInt32 on > PositionableStream ? Good luck with that when the the underlying collection > is anything other than bytes. > > >> > > >> All this being said, there is no one, single correct answer. > > >> > > >> But if we all try to simplify what we expect of streams (use a more > limited API), we'll be more nimble to make implementation changes later on. > > >> > > >> Sven > > >> > > >>> On 13 Nov 2017, at 19:58, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > >>> > > >>> Hi Evan > > >>> > > >>> I think that we will use the ZnStreams. > > >>> If we use Xtreams we will transform their API because some messages > > >>> are not really good. > > >>> Stef > > >>> > > >>>> On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu(a)gmail.com> > wrote: > > >>>> I've heard mention once or twice on this list and in some release > notes of > > >>>> what sounded like possible coming changes to the stream API. Could > anyone > > >>>> point me to any concrete details about that? I haven't been able to > dig > > >>>> anything up myself by searching. I'm about to write something that > I'd like > > >>>> to be polymorphic with the stream API, but if that's about to > change, I'd > > >>>> like to plan ahead. > > >>>> > > >>>> Thanks, > > >>>> Evan > > >>> > > >> > > >> > > > > > > > > > > > > -- > > > > Guille Polito > > Research Engineer > > > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13 > > > > >

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Sven Van Caekenberghe

> On 14 Nov 2017, at 10:20, Prof. Andrew P. Black <black(a)cs.pdx.edu> wrote: > > >> On 13 Nov 2017, at 20:27 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> There is a discussion about positioning (#position , #position: and related) but these cannot be supported _in general_ by the kind of streams described above. > > I agree with that. But I think that general streams can, and should support: > > # saveState âanswers an opaque cookieâ > # restoreState: aCookieObtainedFromTheSameStream > > This enables pone to read ahead, and then reset the state to the way that it was. The implementation of the cookie will depend on the implementation of the stream. In the simplest case it may be an integer position (sufficient for an in-core stream); in the more general case it may include a copy of the streamâs buffer, and the cookie obtained by saving the state of any wrapped stream. > > Andrew Yes and no: #saveState / #restoreState: need a possibly unlimited memory/buffer, similar to #position / #position: They cannot be offered in general (a socket stream is infinite, has no begin/end, in most cases). But I do think that a wrapper stream could add such feature, we only have to implement one and agree on the API (and the buffer size should probably be limited in size). I am curious though, why do you need it ? I mean, I got away (and try hard) to only use 1-element peeking and managed to implement STON, NeoJSON, NeoCSV, Stomp, PostgresSQL, Redis, and other protocols. A syntax that really requires multi element peeking is not so common. Sven

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Sven Van Caekenberghe

> On 14 Nov 2017, at 09:53, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I look at the code, So Zinc provides only binary/character streams. Right? Yes, Zn streams focus on classic binary(byte) / character streams. Streaming over arbitrary data is very cool and well covered by the old ones. > About contribution: it is in external repository of Sven. Can we contribute with normal process, create pull request into Pharo repo? > > 2017-11-14 9:36 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > To a package next to block? > > On Tue, Nov 14, 2017 at 9:16 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > What about contributing to zinc streams? Imaging that I will create block based streams, collecting:/selecting streams like in XSteam. Where I should put them? > > > 2017-11-13 23:51 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > > > > Am 13.11.2017 um 21:08 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > > >> On Mon, Nov 13, 2017 at 8:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> The idea is to have much simpler streams which can be composed to get more sophisticated behaviour. > >> > >> The most primitive streams should be binary read or write streams, like a raw file or network connection. > >> > >> To add a character encoding/decoding you wrap them in a ZnCharacterReadStream or ZnCharacterWriteStream (these use the newer, cleaner ZnCharacterEncoders). > > > > Yes really nice :) > > > > And Guille started to use them and we are slowly rewriting all the > > stream internal users to use Zn and after we will be free. > > > > > No, you will depend on zinc classes. How is that supposed to work in bootstrap? > > Norbert > >> If you want buffering, you wrap a ZnBufferedReadStream or ZnBufferedWriteStream around them. > >> > >> And there are some other examples in the system too. > >> > >> Have a look at BinaryFileStream and ZdcSocketStream. > >> > >> Simply put, MultiByteFileStream and MultiByteBinaryOrTextStream must die, because they try to be everything at once and are impossible to change. > > > > > > YES YES YES and celebrate. I could never understand anything. My brain > > is too limited for these kind of games :) > > > > > > > >> The contract of a stream should be much, much simpler than it is today. > > > > Fully agree. > > > >> > >> For writing that means > >> > >> #nextPut: > >> #nextPutAll: > >> #next:putAll: > >> #next:putAll:startingAt: > >> > >> the 3 last ones can be written in terms of of the first one, but the last one is key because it can be the most efficient. > >> And maybe also > >> > >> #flush > >> #close > >> > >> Some helpers for character writing are > >> > >> #space > >> #tab > >> #cr > >> #crlf > >> #lf > >> > >> Maybe #newline > > > > :) > > > > > >> > >> #<< is a handy method too. > >> > >> For reading that means > >> > >> #atEnd > >> #next > >> #next: > >> #next:into: > >> #next:into:startingAt: > >> #nextInto: > >> #peek > >> #skip: > >> #upToEnd > >> #upTo: > >> #readInto:startingAt:count: > >> > >> Again, they can all be written in terms of #next, but #readInto:startingAt:count: is the core, efficient one. > >> Note that #peek allows a one character lookahead, which should be sufficient for almost all parsing needs. > >> > >> #close is also a necessary operation, #peekFor: a handy one, #nextLine is popular too. > >> > >> There is a discussion about positioning (#position , #position: and related) but these cannot be supported _in general_ by the kind of streams described above. > >> > >> If you absolutely need these, read #upToEnd and use a regular ReadStream (over a fixed collection). > >> > >> The collection based classic Streams should always remain in the system, they are too handy. But have you seen for example, #nextInt32 on PositionableStream ? Good luck with that when the the underlying collection is anything other than bytes. > >> > >> All this being said, there is no one, single correct answer. > >> > >> But if we all try to simplify what we expect of streams (use a more limited API), we'll be more nimble to make implementation changes later on. > >> > >> Sven > >> > >>> On 13 Nov 2017, at 19:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >>> > >>> Hi Evan > >>> > >>> I think that we will use the ZnStreams. > >>> If we use Xtreams we will transform their API because some messages > >>> are not really good. > >>> Stef > >>> > >>>> On Mon, Nov 13, 2017 at 7:54 PM, Evan Donahue <emdonahu(a)gmail.com> wrote: > >>>> I've heard mention once or twice on this list and in some release notes of > >>>> what sounded like possible coming changes to the stream API. Could anyone > >>>> point me to any concrete details about that? I haven't been able to dig > >>>> anything up myself by searching. I'm about to write something that I'd like > >>>> to be polymorphic with the stream API, but if that's about to change, I'd > >>>> like to plan ahead. > >>>> > >>>> Thanks, > >>>> Evan > >>> > >> > >> > > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13 >

Nov. 14, 2017