August 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Tracing Method Calls

by Peter UhnÃ¡k

If you want some projects using metalinks for inspiration: https://github.com/peteruhnak/metalinks-toolkit https://github.com/peteruhnak/live-instance-viewer (the second one also has a link to PDF explaining it in more detail) Also here an example http://blog.yuriy.tymch.uk/2016/02/vigorous-caching-in-pharo-or-how-i-used.… Peter On Wed, Aug 1, 2018 at 2:21 PM, Arturo Zambrano <arturo.zambrano(a)gmail.com> wrote: > Hi Steven > > On Fri, Jul 27, 2018 at 3:53 PM Steven Costiou <steven.costiou(a)kloum.io> > wrote: > >> Hi, >> >> it may not be actively maintained but Phantom has recently been ported to >> Pharo 6/6.1 https://github.com/InesSosa95/PHANtom >> > > that's a good news :) > >> >> >> You could also use Reflectivity (look for MetaLink class), which should >> not be hard to understand if you are familiar with aspects (although that >> is not aspects). >> >> >> >> For example, if you wanted to trace the receivers and parameters of a >> method named #mWithArg1:withArg2:withArg3: in class C, you could do : >> >> |link| >> >> link := MetaLink new. >> >> link control: #before. >> >> link arguments: #(#receiver #arguments). >> >> link metaObject: YourMetaObject. >> >> link selector: #yourMethodWithArg1:andArg:. >> >> (C lookupSelector: #mWithArg1:withArg2:withArg3:) ast link: link >> >> >> >> YourMetaObject is here an object which will receive the >> yourMethodWithArg1:andArg: with as arguments the receiver of the method >> #mWithArg1:withArg2:withArg3: and its arguments as an array. >> >> It could be a block with 2 arguments, or any other object that you would >> use to implement your trace behavior. You have a number of reifications >> available that you can pass as arguments from the context, look for >> subclasses of RFReification. >> > > I was not aware of MetaLink. Thank you! > > > > >> Steven. >> >> >> >> >> >> Le 2018-07-27 17:25, Arturo Zambrano a Ã©crit : >> >> Hi all, >> I have a piece of undocumented software that I need understand ... >> One thing I would like to do is to have a complete trace of method calls >> (receivers, parameters) for certain scenarios. >> As an "aspects"guy, my first idea was to use Phantom, but it seems not >> active anymore. >> >> Could someone please point me to some tools that I could use for this? >> (using Pharo 6, 6.1 or 7) >> >> Thanks in advance >> >> Cheers >> Arturo >> >> >> >> >> >> >> >

Aug. 1, 2018

Re: [Pharo-users] a basic hash question

by Henrik Sperre Johansen

Richard O'Keefe wrote > @James Foster: 100%. There are no exceptions. > > > On 1 August 2018 at 02:05, James Foster < > Smalltalk@ > > wrote: > >> To what extent is it required by ANSI that objects be of the same class? >> Does Pharo treat a String and a Symbol as equivalent if they have the >> same >> characters? >> >> James >> Let's not throw the baby out with the bathwater... Changing SequenceableCollection to do class comparison is a change people can get behind without much effort; especially when there's a bug that has to be resolved somehow, and it's the better overall change anyways. Forcing Strings != Symbols is a harder sell (although personally, I'd love to see it). Forcing WideStrings != ByteStrings is never going to happen; but perhaps that can be said to be compliant due to the phrasing "Unless specifically refined", and neither being defined in the standard. Interval/Array (and String/Symbol) don't have the same excuse. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Aug. 1, 2018

Re: [Pharo-users] Tracing Method Calls

by Arturo Zambrano

Hi Steven On Fri, Jul 27, 2018 at 3:53 PM Steven Costiou <steven.costiou(a)kloum.io> wrote: > Hi, > > it may not be actively maintained but Phantom has recently been ported to > Pharo 6/6.1 https://github.com/InesSosa95/PHANtom > that's a good news :) > > > You could also use Reflectivity (look for MetaLink class), which should > not be hard to understand if you are familiar with aspects (although that > is not aspects). > > > > For example, if you wanted to trace the receivers and parameters of a > method named #mWithArg1:withArg2:withArg3: in class C, you could do : > > |link| > > link := MetaLink new. > > link control: #before. > > link arguments: #(#receiver #arguments). > > link metaObject: YourMetaObject. > > link selector: #yourMethodWithArg1:andArg:. > > (C lookupSelector: #mWithArg1:withArg2:withArg3:) ast link: link > > > > YourMetaObject is here an object which will receive the > yourMethodWithArg1:andArg: with as arguments the receiver of the method > #mWithArg1:withArg2:withArg3: and its arguments as an array. > > It could be a block with 2 arguments, or any other object that you would > use to implement your trace behavior. You have a number of reifications > available that you can pass as arguments from the context, look for > subclasses of RFReification. > I was not aware of MetaLink. Thank you! > Steven. > > > > > > Le 2018-07-27 17:25, Arturo Zambrano a Ã©crit : > > Hi all, > I have a piece of undocumented software that I need understand ... > One thing I would like to do is to have a complete trace of method calls > (receivers, parameters) for certain scenarios. > As an "aspects"guy, my first idea was to use Phantom, but it seems not > active anymore. > > Could someone please point me to some tools that I could use for this? > (using Pharo 6, 6.1 or 7) > > Thanks in advance > > Cheers > Arturo > > > > > > >

Aug. 1, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Guillermo Polito

On Wed, Aug 1, 2018 at 11:19 AM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Tue, Jul 31, 2018 at 6:41 PM Damien Pollet < > damien.pollet+pharo(a)gmail.com> wrote: > >> On Tue, 31 Jul 2018 at 18:28, Damien Pollet < >> damien.pollet+pharo(a)gmail.com> wrote: >> >>> Hi Svenâ¦ a couple questions: >>> >> >> For context, I'm considering options in Clap, for providing accessors to >> Stdio that: >> - are convenient in most cases >> - discourage users from explicitly referencing the Stdio global (so that >> one can inject other streams instead if needed) >> > > Yes. And to me it's ok if Clap defines his own good usages of streams. > Clap's usage of stream is not a typical file access. > > >> For instance, it seems to make sense to provide stdout already wrapped >> with ZnNewLineWriterStream, >> > > Also, ZnNewLineWriterStream needs only to be used when interacting with > the external word. > The rationale of keeping it separate is twofold: > - Zn* streams are meant to be reusable with other kind of streams that > are not files (such as streams in memory) where the newline conventions > do not need to be *always* enforced because the image has internally its > own convention (crs). > - Zn* streams are meant to be reusable with other kind of streams that are > not files (such as sockets) where maybe we want *also* to enforce line > ending convention. > And I'll just add that this also makes it simple to "skip" line end convention transformations. > > >> but that precludes users from buffering. >> > > Yeap. This makes me remember I tried a buffered file stream on > /dev/urandom and the buffering introduced some funny effects :) > > >> >> >> - is there a preferred order of composition between the encoding and >>> buffering streams ? If yes, it the same for read and write stream, or >>> reversed ? >>> E.g. if Stdio binaryStdin was implemented, Stdio stdin should be >>> decoded, but buffering it as well would be a problem for interactive >>> applications. >>> >>> - what's your opinion on convenience composition messages, e.g. >>> aBinaryStream buffered decoded: 'utf-8' ? >>> >>> >>> >>> On Tue, 24 Jul 2018 at 10:13, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> >>>> >>>> >>>> > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> > >>>> > Stdio stdout and friends just return a binary stream, hence they need >>>> wrapping for encoding. >>>> > >>>> > Maybe >>>> > >>>> > Stdio stdoutAsText >>>> > >>>> > might be an idea, but this is so uncommon that I am not sure this is >>>> a good idea. >>>> >>>> Given all remarks and comments (thanks BTW), I now think that >>>> >>>> - textual stdio streams are the more common case >>>> - binary stdio streams are the primitive ones that are seldom used >>>> - another encoding than UTF-8 seems uncommon >>>> - these are streams that exist and need no real opening/closing >>>> >>>> So, >>>> >>>> Stdio stdout >>>> >>>> should return return a character write stream with UTF-8 encoding while >>>> >>>> Stdio binaryStdout >>>> >>>> should be the lower level binary one. >>>> This would be more in line with the other streams. >>>> A non-UTF-8 encoding can be used as per Pavel's example. >>>> >>> > > -- > > > > 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 > -- 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

Aug. 1, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Guillermo Polito

On Tue, Jul 31, 2018 at 6:41 PM Damien Pollet <damien.pollet+pharo(a)gmail.com> wrote: > On Tue, 31 Jul 2018 at 18:28, Damien Pollet <damien.pollet+pharo(a)gmail.com> > wrote: > >> Hi Svenâ¦ a couple questions: >> > > For context, I'm considering options in Clap, for providing accessors to > Stdio that: > - are convenient in most cases > - discourage users from explicitly referencing the Stdio global (so that > one can inject other streams instead if needed) > Yes. And to me it's ok if Clap defines his own good usages of streams. Clap's usage of stream is not a typical file access. > For instance, it seems to make sense to provide stdout already wrapped > with ZnNewLineWriterStream, > Also, ZnNewLineWriterStream needs only to be used when interacting with the external word. The rationale of keeping it separate is twofold: - Zn* streams are meant to be reusable with other kind of streams that are not files (such as streams in memory) where the newline conventions do not need to be *always* enforced because the image has internally its own convention (crs). - Zn* streams are meant to be reusable with other kind of streams that are not files (such as sockets) where maybe we want *also* to enforce line ending convention. > but that precludes users from buffering. > Yeap. This makes me remember I tried a buffered file stream on /dev/urandom and the buffering introduced some funny effects :) > > > - is there a preferred order of composition between the encoding and >> buffering streams ? If yes, it the same for read and write stream, or >> reversed ? >> E.g. if Stdio binaryStdin was implemented, Stdio stdin should be decoded, >> but buffering it as well would be a problem for interactive applications. >> >> - what's your opinion on convenience composition messages, e.g. >> aBinaryStream buffered decoded: 'utf-8' ? >> >> >> >> On Tue, 24 Jul 2018 at 10:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> >>> > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > Stdio stdout and friends just return a binary stream, hence they need >>> wrapping for encoding. >>> > >>> > Maybe >>> > >>> > Stdio stdoutAsText >>> > >>> > might be an idea, but this is so uncommon that I am not sure this is a >>> good idea. >>> >>> Given all remarks and comments (thanks BTW), I now think that >>> >>> - textual stdio streams are the more common case >>> - binary stdio streams are the primitive ones that are seldom used >>> - another encoding than UTF-8 seems uncommon >>> - these are streams that exist and need no real opening/closing >>> >>> So, >>> >>> Stdio stdout >>> >>> should return return a character write stream with UTF-8 encoding while >>> >>> Stdio binaryStdout >>> >>> should be the lower level binary one. >>> This would be more in line with the other streams. >>> A non-UTF-8 encoding can be used as per Pavel's example. >>> >> -- 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

Aug. 1, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Guillermo Polito

On Tue, Jul 31, 2018 at 6:29 PM Damien Pollet <damien.pollet+pharo(a)gmail.com> wrote: > Hi Svenâ¦ a couple questions: > > - is there a preferred order of composition between the encoding and > buffering streams ? If yes, it the same for read and write stream, or > reversed ? > E.g. if Stdio binaryStdin was implemented, Stdio stdin should be decoded, > but buffering it as well would be a problem for interactive applications. > Well, I'd say that we could check if performance-wise there is a difference... I don't think there will be much of a difference, but, who knows ^^. > > - what's your opinion on convenience composition messages, e.g. > aBinaryStream buffered decoded: 'utf-8' ? > Check what we did in FileReference & co. Opening a File reference returns by default a utf8 buffered stream (in that order). And we have convenience methods to specify other encodings and to get directly the binary stream (which will be buffered). The idea is that FileSystem (among others like managing memory file systems) provides a high level API with convenience methods to avoid putting the burden of the composition in the user. The File package stays small and flexible providing direct access to the physical file system. Following this same idea, to me Clap should define several convenient ways to access standard input/output. Like that, other Stdio users can define their own too. Also, maybe Clap can provide the same API as FileSystem (#writeStreamEncoded:do:, #readStreamEncoded:do: & co) just for coherence? > > > > On Tue, 24 Jul 2018 at 10:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> >> > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > Stdio stdout and friends just return a binary stream, hence they need >> wrapping for encoding. >> > >> > Maybe >> > >> > Stdio stdoutAsText >> > >> > might be an idea, but this is so uncommon that I am not sure this is a >> good idea. >> >> Given all remarks and comments (thanks BTW), I now think that >> >> - textual stdio streams are the more common case >> - binary stdio streams are the primitive ones that are seldom used >> - another encoding than UTF-8 seems uncommon >> - these are streams that exist and need no real opening/closing >> >> So, >> >> Stdio stdout >> >> should return return a character write stream with UTF-8 encoding while >> >> Stdio binaryStdout >> >> should be the lower level binary one. >> This would be more in line with the other streams. >> A non-UTF-8 encoding can be used as per Pavel's example. >> > -- 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

Aug. 1, 2018

Re: [Pharo-users] a basic hash question

by James Foster

Thanks. That is helpful. James > On Jul 31, 2018, at 10:28 PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Can I give a reference? Well, I did: the ANSI Smalltalk standard. > Specifically, section 5.7.8.2, the refinement for <sequenceReadableCollection> > > Numbers are governed by section 5.6.7.1, which requires numbers that are > compared for equality to be converted to a common representation, which > in this case requires (sigh) integers to be converted to floats. With > that definition it is possible to find integers x z and a float y such > that x = y and y = z are true but x = z is false, which is a very bad > thing. My Smalltalk tries to be ANSI conformant, but some things are > just too broken to live with, and that's one of them. (The rule should > always be to convert in a way that loses no information.) > > It may well seem strange to you, but "equivalence" (#=) in Smalltalk > is not coupled to "ordering" (the Magnitude methods) and never has been. > For example, #= compares the characters of strings, which are equal iff > they have the same codepoint. But #< and the other magnitude methods > use an "implementation-defined" collation order, which could, for example, > ignore alphabetic case. So it would be entirely consistent with the > standard and historic practice to have 'A' <= 'a' and 'a' <= 'A' but > 'A' ~= 'a'. This is not merely a theoretical possibility; I just tried > it in GNU Smalltalk. > > There was a serious historic bug in many Smalltalks where > 'a' = #a was true (using string comparison) but > #a = 'a' was false (using identity). This may well be > why the standard insists on the classes (not the species) > being the same, to ensure that <string> = <symbol> is > consistent with <symbol> = <string>. > > On 1 August 2018 at 16:47, James Foster <Smalltalk(a)jgfoster.net <mailto:Smalltalk@jgfoster.net>> wrote: > @Richard OâKeefe: Iâm trying to find the place in the ANSI Standard you are citing. All Iâve found so far is at 5.3.1.1 <http://5.3.1.1/>: > > The meaning of "equivalent" cannot be precisely defined but the intent is that two objects are > considered equivalent if they can be used interchangeably. Conforming protocols may choose to > more precisely define the meaning of "equivalentâ. > > Can you provide a reference for your assertion that objects must be of the same class in order to be equivalent? > > How about other comparisons between objects of different classes? Is 1.9 < 2? Is 2.1 > 2? How about 2.0 = 2? Is #a < âbâ? is #b > âaâ? How about #a = âaâ? It seems strange to suggest that an object can be less than or greater than, but not equal to! > > James > >> On Jul 31, 2018, at 9:24 PM, Richard O'Keefe <raoknz(a)gmail.com <mailto:raoknz@gmail.com>> wrote: >> @James Foster: 100%. There are no exceptions >> >> On 1 August 2018 at 02:05, James Foster <Smalltalk(a)jgfoster.net <mailto:Smalltalk@jgfoster.net>> wrote: >> To what extent is it required by ANSI that objects be of the same class? >

Aug. 1, 2018

Re: [Pharo-users] a basic hash question

by Richard O'Keefe

Can I give a reference? Well, I did: the ANSI Smalltalk standard. Specifically, section 5.7.8.2, the refinement for <sequenceReadableCollection> Numbers are governed by section 5.6.7.1, which requires numbers that are compared for equality to be converted to a common representation, which in this case requires (sigh) integers to be converted to floats. With that definition it is possible to find integers x z and a float y such that x = y and y = z are true but x = z is false, which is a very bad thing. My Smalltalk tries to be ANSI conformant, but some things are just too broken to live with, and that's one of them. (The rule should always be to convert in a way that loses no information.) It may well seem strange to you, but "equivalence" (#=) in Smalltalk is not coupled to "ordering" (the Magnitude methods) and never has been. For example, #= compares the characters of strings, which are equal iff they have the same codepoint. But #< and the other magnitude methods use an "implementation-defined" collation order, which could, for example, ignore alphabetic case. So it would be entirely consistent with the standard and historic practice to have 'A' <= 'a' and 'a' <= 'A' but 'A' ~= 'a'. This is not merely a theoretical possibility; I just tried it in GNU Smalltalk. There was a serious historic bug in many Smalltalks where 'a' = #a was true (using string comparison) but #a = 'a' was false (using identity). This may well be why the standard insists on the classes (not the species) being the same, to ensure that <string> = <symbol> is consistent with <symbol> = <string>. On 1 August 2018 at 16:47, James Foster <Smalltalk(a)jgfoster.net> wrote: > @Richard OâKeefe: Iâm trying to find the place in the ANSI Standard you > are citing. All Iâve found so far is at 5.3.1.1: > > The meaning of "equivalent" cannot be precisely defined but the intent is > that two objects are > considered equivalent if they can be used interchangeably. Conforming > protocols may choose to > more precisely define the meaning of "equivalentâ. > > Can you provide a reference for your assertion that objects must be of the > same class in order to be equivalent? > > How about other comparisons between objects of different classes? Is 1.9 < > 2? Is 2.1 > 2? How about 2.0 = 2? Is #a < âbâ? is #b > âaâ? How about #a = > âaâ? It seems strange to suggest that an object can be less than or greater > than, but not equal to! > > James > > On Jul 31, 2018, at 9:24 PM, Richard O'Keefe <raoknz(a)gmail.com> wrote: > @James Foster: 100%. There are no exceptions > > On 1 August 2018 at 02:05, James Foster <Smalltalk(a)jgfoster.net> wrote: > >> To what extent is it required by ANSI that objects be of the same class? >> >

Aug. 1, 2018

Re: [Pharo-users] ZnCharacterWriteStream â is it a WriteStream?

by Sven Van Caekenberghe

> On 1 Aug 2018, at 00:34, Andrew P. Black <apblack(a)pdx.edu> wrote: > > Iâm making a stream to write on a file using > > outputFile := FileLocator home / 'Desktop' / classBeingTranslated name , '.grace'. > outputFile writeStreamDo: [ :s | ... ] > > Is that OK? Yes > When I do the above, in the writeStreamDo: block, s is bound to an instance of ZnCharacterWriteStream. But that class does nt understand many methods from WriteStream. For example, #contents is not understood, and nor is #ensureASpace. > > To put things another way: I wrote tests using a stream created with String streamContents: [ :s | ... ], and everything worked fine. Then, for production use, I switch to a stream created using outputFile writeStreamDo: [ :s | ... ] and everything breaks. > > I know that ZnCharacterWriteStream is fairly new. Am I doing something wrong, or is ZnCharacterWriteStream still under development? > > Andrew The new streams are intentionally simpler, with a lighter API. If they were exactly the same, API wise, there would not be much point in doing them.

Aug. 1, 2018

Re: [Pharo-users] ZnCharacterWriteStream â is it a WriteStream?

by Richard O'Keefe

Without getting into a general debate about the new stream classes, a stream class meant for writing to a file SHOULDN'T have #contents in its interface. (1) For example, if you open a channel for *output* in Unix, you have no reason to expect that you have been granted a right to read it. For example, suppose user=fred group=whizzy owns a file foo.grace with permission bits rw--w---- and you are running a program as user=mary group=whizzy. You can open foo.grace for writing, but you cannot read it. (2) The thing you open might not be a file. It might be, for example, a symbolic link to /dev/null, a symbolic link to /dev/tty, a named pipe, or even (in principle, I don't know if anyone has done it, but with something like FUSE it *could* be done) a socket to a remote machine. In all these cases, *nobody* is storing the contents. (3) If the thing you open *is* a disc file, and you *do* have permission to read it back, what should happen if you have written more to the file than your memory can hold? If you know that the output written to the stream is going to be small enough that holding it in memory won't be a problem, could you use a WriteStream and then write it to the output file in one burst when it's finished? Now, what about #ensureASpace? It can *almost* be done on a buffered stream by looking at the last character in the buffer and adding a space if it isn't one. But what if you called #flush and the buffer is empty? Well, in that case, if you have a "monolithic" design where the stream records the last character at every flush, it's still doable. If you don't have a monolithic design, you have to be able to read the last block before the present one, and we've just seen why that is not in general possible. The one thing you can safely do is to say that if the buffer is empty you will add a space just to be sure, so that the contract for #ensureASpace becomes Ensures that the past contents of the receiver ends with a space. Tries to avoid adding a space when there is already one, but may or may not succeed. On 1 August 2018 at 10:34, Andrew P. Black <apblack(a)pdx.edu> wrote: > Iâm making a stream to write on a file using > > outputFile := FileLocator home / 'Desktop' / classBeingTranslated > name , '.grace'. > outputFile writeStreamDo: [ :s | ... ] > > Is that OK? When I do the above, in the writeStreamDo: block, s is > bound to an instance of ZnCharacterWriteStream. But that class does nt > understand many methods from WriteStream. For example, #contents is not > understood, and nor is #ensureASpace. > > To put things another way: I wrote tests using a stream created with > String streamContents: [ :s | ... ], and everything worked fine. Then, > for production use, I switch to a stream created using outputFile > writeStreamDo: [ :s | ... ] and everything breaks. > > I know that ZnCharacterWriteStream is fairly new. Am I doing something > wrong, or is ZnCharacterWriteStream still under development? > > Andrew > > >

Aug. 1, 2018