November 2017 - Pharo-users

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

by Pavel Krivanek

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

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

by Guillermo Polito

Class side #initialize is executed only when a class is loaded for the first time. Posteriors "updates" to the class, or even to the initialize method do not re-execute #initialize. Now, about the FFI particular requirements, I'd let Esteban answer :) On Tue, Nov 14, 2017 at 3:08 AM, Ben Coman <btc(a)openinworld.com> wrote: > 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 > > > -- 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Guillermo Polito

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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Denis Kudriashov

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

Nov. 14, 2017

Re: [Pharo-users] FileReference>>#moveTo: across filesystems

by Alistair Grant

On 13 November 2017 at 19:11, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Claudio, > > On 13 November 2017 at 18:49, Claudio Corrodi <corrodi(a)inf.unibe.ch> wrote: >> Hi all, >> >> Manuel Leuenberger and I ran into an issue with the FileReference>>#moveTo: >> method last week. On my system, I have "/" and "/home" in two different >> partitions/file systems. If I do something like the following, Pharo >> complains with a PrimitiveFailed signal: >> >> '/tmp/aFile.txt' asFileReference moveTo: '/home/claudio/aFile.txt' >> asFileReference >> >> I do not know how this is implemented exactly, but assume that the "rename" >> syscall is used (on Linux systems, that is), which does not work across file >> systems. The issue does not arise if I moveTo: inside the same filesystem. >> >> Is this expected behaviour? It is not obvious (to me) that >> FileReference>>#moveTo: requires source and target to be on the same >> filesystem. It would therefore make more sense to me if there were a >> fallback that copies and deletes if two filesystems are involved (much like >> "mv" behaves). >> >> What do you think? >> >> Cheers, >> Claudio > > This issue was fixed some time ago. I'm having trouble finding the > fogbugz issue, but it is definitely fixed in Pharo 7. For future reference: https://pharo.fogbugz.com/f/cases/20172 > Would you > please let me know which build of Pharo you are using, and take a look > at FileSystem>>move:to: and compare it to (minus the formatting > changes :-)): > > move: sourcePath to: destination > "Move the file /directory referenced as sourcePath to the destination > referred as destPath. > If there is no file at sourcePath, raise FileDoesNotExist. > If destPath is a file, raise FileExists. > If destPath is a directory, move the sourcePath in to the directory" > > | fullDestination | > > destination isFile ifTrue: [ FileExists signalWith: destination ]. > destination isDirectory > ifTrue: [ fullDestination := destination / sourcePath basename ] > ifFalse: [ fullDestination := destination ]. > self = destination fileSystem ifTrue: > [ > "Ideally we would test whether the source and destination are on the > same filesystem from the OSs perspective. > Since we can't do that, just try rename, and if that fails, copy and delete." > [ self rename: sourcePath to: fullDestination resolve path ] > on: Error > do: [ :error | self copyAndDelete: sourcePath to: fullDestination ]. > ] ifFalse: > [ self copyAndDelete: sourcePath to: fullDestination ]. > ^fullDestination > > > Cheers, > Alistair

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Pavel Krivanek

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? > In bootstrap we already use the package 'Zinc-Character-Encoding-Core'. It is standalone so there is no dependency issue. -- Pavel > > 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 > >>> > >> > >> > >

Nov. 14, 2017

Re: [Pharo-users] Embedded PDF viewer?

by K K Subbu

On Monday 13 November 2017 05:29 PM, Ben Coman wrote: > Yes, I've certainly considered it.Â Pragmatically, in my electrical > career I deal with a lot of single page A3 PDF scans of schematic > drawings, so pre-converting to a bitmap format outside of Pharo wouldn't > lose much. PDF deals with vector graphics, so bitmap conversion will be lossy. You could import them as SVG instead use the existing classes for handling SVG and XML. HTH .. Subbu

Nov. 14, 2017

FFIExternalEnumeration int versus long

by Ben Coman

I have a C definition... unsigned long FPDF_GetLastError(); whose return values are... #define FPDF_ERR_SUCCESS 0 // No error. #define FPDF_ERR_UNKNOWN 1 // Unknown error. #define FPDF_ERR_FILE 2 // File not found or could not be opened. #define FPDF_ERR_FORMAT 3 // File not in PDF format or corrupted. #define FPDF_ERR_PASSWORD 4 // Password required or incorrect password. #define FPDF_ERR_SECURITY 5 // Unsupported security scheme. #define FPDF_ERR_PAGE 6 // Page not found or content error. I was thinking of turning those #define's into an FFIExternalEnumeration, but I was wondering if I'll hit some undefined behaviour with the underlying representation being a "long" rather than an "int" ? I do see here that C enumerations can be a range of types including "long" * https://stackoverflow.com/questions/7093360/c-sharp-enum-of-long-values but I'm not sure how it works in the Pharo context to know what the size underlying representation. cheers -ben

Nov. 14, 2017

when a subclass is loaded, is super-class-side>>initialize executed?

by Ben Coman

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

Re: [Pharo-users] Stream API

by Norbert Hartl

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

Nov. 13, 2017