November 2017 - Pharo-users

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

by Sven Van Caekenberghe

> On 14 Nov 2017, at 09: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: Note: the actual source code has to be different. I sometimes put a 'last changed' date tag in a comment to force execution. > 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] FFIExternalEnumeration int versus long

by Esteban Lorenzano

right now FFIExternalEnumeration support int32 and uint32 types, but I think is not hard to create a FFIExternalLongEnumeration or whatever is need. FFIExternalEnumeration >> initializeEnumeration, however, could be better refactored, I admit ;) > On 13 Nov 2017, at 23:41, Ben Coman <btc(a)openInWorld.com> wrote: > > 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 <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

Re: [Pharo-users] Iterating through two collections in parallel

by Denis Kudriashov

Hi Try this one: #(1 2 3) with: 'abc' do: [ :aNumber :aLetter | do something first with 1 and $a, then with 2 and $b, and finally with 3 and $c ] 2017-11-14 10:10 GMT+01:00 Prof. Andrew P. Black <black(a)cs.pdx.edu>: > What method will execute a two-parameter block with corresponding pairs of > elements from two separate Ordered Collections. > > something like this example: > > #(1 2 3) and: 'abc' do: [ :aNumber :aLetter | do > something first with 1 and $a, > > then with 2 and $b, > > and finally with 3 and $c ] > > I searched for âcorrespondingâ and âpairsâ and failed to find what Iâm > looking for. I tried âzipâ. Itâs hard to search for this with an example. > > Andrew > > > > > >

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Prof. Andrew P. Black

> 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

Nov. 14, 2017

Re: [Pharo-users] RBRuleIfNotNilDo usage

by Henrik Sperre Johansen

Stephane Ducasse-3 wrote > I wonder if we packaged somewhere the removed deprecated method. > We should do that but since we do it manually I guess that this is ad-hoc. > > Stef > > On Sun, Nov 12, 2017 at 2:45 PM, Alistair Grant < > akgrant0710@ > > wrote: >> Hi Stef, >> >> On 12 November 2017 at 14:34, Stephane Ducasse < > stepharo.self@ > > wrote: >>> Hi alistair >>> >>> >>> If you run your program the code will be automatically transformed (I >>> cannot check the deprecation definitino right now) >>> >>> Else have a look at tests of the ParseTreeRewriter. >>> >>> Stef >>> >>> On Sun, Nov 12, 2017 at 2:12 PM, Alistair Grant < > akgrant0710@ > > wrote: >>>> Hi Everyone, >>>> >>>> I'm loading some code in to Pharo 7 that tries to use #ifNotNilDo:. >>>> >>>> There's already a transformation to re-write it to the correct >>>> #ifNotNil: - RBRuleIfNotNilDo. >>>> >>>> How can I apply the transformation to all existing methods in the >>>> image that call #ifNotNilDo:? >>>> >>>> Thanks, >>>> Alistair >> >> Thanks! >> >> #ifNotNilDo: was deprecated in Pharo 6, and the method was removed >> completely in Pharo 7. >> >> The easiest thing to do is to port #ifNotNilDo: forward to Pharo 7 so >> that the methods are automatically re-written. >> >> And then get the offending libraries to be updated. But that's another >> story. >> >> Thanks again, >> Alistair >> It would also be possible to force the issue, and instead of keeping the definitions in image + rewrite on use, add the rules to a CompilerPlugin, either loaded by default when importing code, or as a "rewrite deprecated sends on import" toggle in the settings somewhere. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 14, 2017

Iterating through two collections in parallel

by Prof. Andrew P. Black

What method will execute a two-parameter block with corresponding pairs of elements from two separate Ordered Collections. something like this example: #(1 2 3) and: 'abc' do: [ :aNumber :aLetter | do something first with 1 and $a, then with 2 and $b, and finally with 3 and $c ] I searched for âcorrespondingâ and âpairsâ and failed to find what Iâm looking for. I tried âzipâ. Itâs hard to search for this with an example. Andrew

Nov. 14, 2017

Re: [Pharo-users] Stream API

by Pavel Krivanek

2017-11-14 9:53 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I look at the code, So Zinc provides only binary/character streams. Right? > > About contribution: it is in external repository of Sven. Can we > contribute with normal process, create pull request into Pharo repo? > yes, time to time we make sync with Zinc upstream. -- Pavel > > 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 >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > >

Nov. 14, 2017

Re: [Pharo-users] Open Debugger, Save and Quit

by Guillermo Polito

Hi Sean, You can always try: exception freeze. freeze will copy the stack so it is usable in a posterior debug session even if the original contexts died. exception debug. Opens a debugger :) On Mon, Nov 13, 2017 at 5:20 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tim Mackinnon wrote > > you can override this and Fuel out the debug context to a file > > Thanks, Tim! I do know about that, but I was thinking/hoping that maybe > there was a way to keep the debug context alive without fueling outâ¦ > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- 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

I look at the code, So Zinc provides only binary/character streams. Right? 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 > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Nov. 14, 2017

Re: [Pharo-users] Embedded PDF viewer?

by Christian Haider

In the end, you need to have bitmaps for the screen. Rendering is the projection of vectors onto pixels. But you don't want to lose the vectors, because you need them for interactions (mouse, keyboard focus). I think that it is extremely sexy to have an interactive viewer for PDF! Writing a renderer is a lot of work, although the newer Windows and Apple APIs make it a lot easier nowadays. Still, you need to have an answer to color composition and irregular clipping paths (the hardest problems I think of. But there may be more). And it must be fast enough for interactive applications... I was hoping to use some existing renderer. I imagine that Bens approach can work well. Although I didnât do anything towards rendering myself, I am thinking of using PDF.js in an embedded browser. PDF.js is used by many browsers and seems to be good enough by now. And it would be not too bad to fiddle with JavaScript to connect it with the model in Smalltalk, I guess. The problem is the browser embedding. Is this feasible in Pharo? Happy hacking, Christian > -----UrsprÃ¼ngliche Nachricht----- > Von: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] Im Auftrag > von K K Subbu > Gesendet: Dienstag, 14. November 2017 06:43 > An: Ben Coman <btc(a)openinworld.com> > Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Betreff: Re: [Pharo-users] Embedded PDF viewer? > > 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