April 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Calypso zero class refs for TComparable

by Ben Coman

> Hi, >> >> In Nautilus the Traits are not "referenced", they are used. So you have >> "Find usage" instead of "Find reference". >> >> Maybe this option is missing on Calypso? (I suppose since I still use >> Pharo 6.1 because all my projects are around Seaside which does not load in >> P7) >> >> >>> Is this expected behaviour? (in 70793) >>> >>> cheers -ben >>> >> > 2018-04-22 11:59 GMT+02:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > >> >> On dim. 22 avr. 2018 at 03:54, Ben Coman <btc(a)openinworld.com> wrote: >> >>> I expected TComparable to be used somewhere in the Image? >>> >>> So I was surprised that with Calypso, >>> right-clicking on TComparable and choosing "Class refs" >>> brought up zero results. >>> >> > On 22 April 2018 at 18:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > When you select trait new hierarchy mode appears: trait users. > I see it now, but clicking it for TComparable does't show anything. Is that right? Can you advise a Trait that shows some results as an example? cheers -ben

April 22, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Torsten Bergmann

Hi Stef, do not worry - I'm fully relaxed. It is you - who suggested to kill the catalog - without having or proposing a suitable alternative yet. If you want to route the thread to talking about "idiots" and "assholes" you go offtopic and I guess I have nothing more to contribute to the discussion. If it was not clear from my writing: I only expressed my wish that we should better improve it instead of killing it. That's all. Because anytime we have a better idea we get more disruptive in what we provide ... and this leads to the unfortunate situation: - that we replace our own stuff with newer ones again and again (which can but must not be good as things get more diverse and complicated over time) - that users have to know how things historically have been progressed to find its way through Pharo (including the terms and tools we use) I would not see this as a rant - but rather a true effect we can spot on many places in our ecosystem already. Long story short: I would vote for the "fix" if the sole other option is to "remove". Bye T. > Gesendet: Samstag, 21. April 2018 um 15:31 Uhr > Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Do we kill the catalog? > > Torsten > > Sometimes you should relax. Because if you remember I pushed the > catalog (in fact I love it and we need a much more powerful one) > and I even improved it. I made it better to automatically add MC repositories. > Of course Thierry is exagerating. > > Now we should fix or remove it. Simple no? > > Now you can rant in your corner thinking that I'm asshole. > This is ok for me. > > Stef > > On Sat, Apr 21, 2018 at 3:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Even there is no learning from the past - it's deja vu all over again... > > > > > >> Gesendet: Freitag, 20. April 2018 um 08:53 Uhr > >> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> Betreff: Re: [Pharo-dev] Do we kill the catalog? > >> > >> Hi torsten > >> > >> the wise shows the moon, the idiot sees his finger. > >> > >> Stef > >> > >> > >> On Thu, Apr 19, 2018 at 10:38 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> > Now today you had loading trouble with Smacc from Catalog ... and now directly want to > >> > kill catalog. Wow! > >> > > >> > Sometimes I have the impression that our community tries to reinvent itself each day > >> > doing it differently (but not only better) instead of extending, improving and supporting > >> > what we have have done before. Which sometimes is good ... but not always. > >> > > >> > Thx > >> > T. > >> > > >> >> Gesendet: Donnerstag, 19. April 2018 um 08:42 Uhr > >> >> Von: "Stephane Ducasse" <stepharo.self(a)gmail.com> > >> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> >> Betreff: [Pharo-dev] Do we kill the catalog? > >> >> > >> >> Hi guys > >> >> > >> >> What do we do with it? > >> >> What alternatives? > >> >> > >> >> Stef > >> >> > >> >> > >> > > >> > >> > > > >

April 22, 2018

Re: [Pharo-dev] Calypso zero class refs for TComparable

by Denis Kudriashov

Hi. When you select trait new hierarchy mode appears: trait users. 2018-04-22 11:59 GMT+02:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > > On dim. 22 avr. 2018 at 03:54, Ben Coman <btc(a)openinworld.com> wrote: > >> I expected TComparable to be used somewhere in the Image? >> >> So I was surprised that with Calypso, >> right-clicking on TComparable and choosing "Class refs" >> brought up zero results. >> > > Hi, > > In Nautilus the Traits are not "referenced", they are used. So you have > "Find usage" instead of "Find reference". > > Maybe this option is missing on Calypso? (I suppose since I still use > Pharo 6.1 because all my projects are around Seaside which does not load in > P7) > > >> Is this expected behaviour? (in 70793) >> >> cheers -ben >> > -- > Cyril Ferlicot > https://ferlicot.fr >

April 22, 2018

Re: [Pharo-dev] Calypso zero class refs for TComparable

by Cyril Ferlicot

On dim. 22 avr. 2018 at 03:54, Ben Coman <btc(a)openinworld.com> wrote: > I expected TComparable to be used somewhere in the Image? > > So I was surprised that with Calypso, > right-clicking on TComparable and choosing "Class refs" > brought up zero results. > Hi, In Nautilus the Traits are not "referenced", they are used. So you have "Find usage" instead of "Find reference". Maybe this option is missing on Calypso? (I suppose since I still use Pharo 6.1 because all my projects are around Seaside which does not load in P7) > Is this expected behaviour? (in 70793) > > cheers -ben > -- Cyril Ferlicot https://ferlicot.fr

April 22, 2018

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Sven Van Caekenberghe

> On 22 Apr 2018, at 10:22, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I am so looking forward to playing with this (as a user). > > For various reasons, we are still in Pharo 6.1, but encoding/decoding was always a troublesome issue in Pharo. Well it should not be, not even in older Pharo versions, as long as you use everything correctly. But the latest changes are a bold step forward. > Thanks a lot! > > Cheers, > Doru > > >> On Apr 20, 2018, at 5:24 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> After the File and Stream changes in Pharo 7, a binary read, resp. write stream from/to a file is actually a ZnBuffered(Read|Write)Stream on a BinaryFileStream. You access these using #binary(Read|Write)Stream[Do:] sent to a FileReference. >> >> As minimal streams the API of ZnBuffered(Read|Write)Stream was different from what existed before. >> >> Specifically, a number of Integer decoding/encoding methods were missing. It is probably best to add those (an alternative would be a subclass). >> >> When I looked at what was available, I thought I could improve upon the current situation. In fact, I think all existing ones can be written in terms of just one key method, one for reading and one for writing. The existing methods than become simple aliases, all while offering more functionality. >> >> (Incidentally this would be an ideal use of a Trait, can we use them again/still ?) >> >> The key method is #nextIntegerOfSize: numberOfBytes signed: signed bigEndian: bigEndian [put: value] and can be found in the latest version of Zinc-CharacterEncoding-Core with a comprehensive set of unit tests. >> >> For example, >> >> int32 >> ^ self nextIntegerOfSize: 4 signed: true bigEndian: true >> >> nextWord >> ^ self nextIntegerOfSize: 2 signed: false bigEndian: true >> >> or non-aliases ones like >> >> binaryStream nextIntegerOfSize: 3 signed: true bigEndian: false >> >> I think I nailed it, but I would love a second pair of eyes to check what I did. >> >> The same functionality could be added to ByteArray in a slight variation (with offsets), where similar integer encoding/decoding methods exist. >> >> Sven > > -- > www.tudorgirba.com > www.feenk.com > > "From an abstract enough point of view, any two things are similar." > > > > >

April 22, 2018

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Tudor Girba

Hi, I am so looking forward to playing with this (as a user). For various reasons, we are still in Pharo 6.1, but encoding/decoding was always a troublesome issue in Pharo. Thanks a lot! Cheers, Doru > On Apr 20, 2018, at 5:24 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > After the File and Stream changes in Pharo 7, a binary read, resp. write stream from/to a file is actually a ZnBuffered(Read|Write)Stream on a BinaryFileStream. You access these using #binary(Read|Write)Stream[Do:] sent to a FileReference. > > As minimal streams the API of ZnBuffered(Read|Write)Stream was different from what existed before. > > Specifically, a number of Integer decoding/encoding methods were missing. It is probably best to add those (an alternative would be a subclass). > > When I looked at what was available, I thought I could improve upon the current situation. In fact, I think all existing ones can be written in terms of just one key method, one for reading and one for writing. The existing methods than become simple aliases, all while offering more functionality. > > (Incidentally this would be an ideal use of a Trait, can we use them again/still ?) > > The key method is #nextIntegerOfSize: numberOfBytes signed: signed bigEndian: bigEndian [put: value] and can be found in the latest version of Zinc-CharacterEncoding-Core with a comprehensive set of unit tests. > > For example, > > int32 > ^ self nextIntegerOfSize: 4 signed: true bigEndian: true > > nextWord > ^ self nextIntegerOfSize: 2 signed: false bigEndian: true > > or non-aliases ones like > > binaryStream nextIntegerOfSize: 3 signed: true bigEndian: false > > I think I nailed it, but I would love a second pair of eyes to check what I did. > > The same functionality could be added to ByteArray in a slight variation (with offsets), where similar integer encoding/decoding methods exist. > > Sven -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

April 22, 2018

Calypso zero class refs for TComparable

by Ben Coman

I expected TComparable to be used somewhere in the Image? So I was surprised that with Calypso, right-clicking on TComparable and choosing "Class refs" brought up zero results. Is this expected behaviour? (in 70793) cheers -ben

April 22, 2018

learning about ClassTestCase

by Ben Coman

I bumped into ClassTestCase for the first time, with class comment... "This class is intended for unit tests of individual classes and their metaclasses. It provides methods to determine the coverage of the unit tests. Subclasses are expected to re-implement: #classesToBeTested and #selectorsToBeIgnored. They should also implement to confirm that all methods have been tested. #testCoverage super testCoverage. " A few questions to improve my knowledge of how to use this... a. there are no implementors of #classesToBeTested but several of #classToBeTested. I presume the class comment is wrong? b. there are no implementors of #testCoverage, so I presume I can ignore that? (and I've no example to work from) c. ClassTestCase is subclassed 73 times, but #selectorsToBeIgnored is only implemented 9 times. So this seems not critical? But btw, every of those at least ignores #printOn:. I'm curious why? These are tagged "private", but is that a good reason not to test it? My purpose was to add a new class MagnitudeTest for a new new method to Magnitude in response to the recent #min:max: discussion. cheers -ben

April 22, 2018

Re: [Pharo-dev] what is demote?

by Stephane Ducasse

Excellent! Thanks! :) On Sat, Apr 21, 2018 at 7:57 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > CyrilFerlicot wrote >> It's probably to change a package of the form "MyPackage-Something" to a >> package "MyPackage" with a "Something" tag. > > Yes, breakpoint triggered from Calypso "Demote to package with tag" context > menu. > > Maybe the message name could be improved tooâ¦ #demoteToTagInPackageNamed:? > Also, maybe there should be a guard if `aString = self name`? > > https://github.com/pharo-project/pharo/pull/1240 > > I don't want to be accused of talking without action ;-) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

April 21, 2018

Re: [Pharo-dev] what is demote?

by Sean P. DeNigris

CyrilFerlicot wrote > It's probably to change a package of the form "MyPackage-Something" to a > package "MyPackage" with a "Something" tag. Yes, breakpoint triggered from Calypso "Demote to package with tag" context menu. Maybe the message name could be improved tooâ¦ #demoteToTagInPackageNamed:? Also, maybe there should be a guard if `aString = self name`? https://github.com/pharo-project/pharo/pull/1240 I don't want to be accused of talking without action ;-) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

April 21, 2018