March 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

by Richard Sargent

On Wed, Mar 6, 2019 at 10:25 AM Tim Mackinnon <tim(a)testit.works> wrote: > I still am tempted to make asDictionary work - because the the moment you > get a #key , DNU error - which is definitely not right. > This argument gives me the willies. Sorry. I can see an argument that a sequenceable collection can implement a meaningful #asDictionary, using #keysAndValuesDo:. The key is the index of each element, so it makes sense. But, #asDictionary for a non-sequenceable collection doesn't make sense (other than for Dictionary and its variants, obviously). What would the keys be from a Set, for example? Bag>>#asDictionary makes sense if (and in my opinion, only if) you define it to rely on the internal implementation. #valuesAndCounts make sense because it doesn't rely on internal implementation details to define it, although it typically is implemented to use those internal implementation details. I think expressing it as a conversion is a poor choice. Asking it for a different representation is good. [And as an aside, given that the API expresses #occurrencesOf:, #valuesAndCounts might have been better named #valuesAndOccurrences (and perhaps "With" rather than "And").] > So should Bag asDictionary give you a reasonable dictionary, or should it > throw a proper exception - something like: > > DomainError signal: â#asDictionary not supported, use #valueAndCountsâ > > Is that better - or do we accept that it inherits it from Collection and > so can do something useful? > > Tim > > On 6 Mar 2019, at 18:11, phil(a)highoctane.be wrote: > > And when asking the object: > > #(1 2 4 5 6 7 2 1 4 3) asBag isDictionary > > we get false. So, not, not a dictionary. > > I still have been using #valuesAndCounts to get the dictionary out of a > bag on several occasions. > > And is useful indeed. > > #(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2 > > and > > #(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2 > > seem pretty much the same. > > But in this age of streams/reactive streams and lazy evaluations, what do > we have in Pharo on that front? > > Phil > > > > > > On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> I was just explaining how it is now, what I think the rationale is behind >> it. >> >> I understand #asDictionary as working on a collection of >> pairs/associations (because it basically goes to #withAll:). >> >> A bag is just a collection that is optimised for many duplicates, the >> fact that you have values and counts is more an implementation detail than >> an intrinsic property. >> >> The conversion that you want, and that already exists in #valuesAndCounts >> is one interpretation of what a bag is, not the only one. A bag is foremost >> a collection of things. >> >> I am not immediately convinced that #valuesAndCounts should be the >> default #asDictionary interpretation. >> >> What about the inverse for example ? >> >> { #foo->2. #bar->3 } asDictionary asBag. >> >> But this is certainly an interesting discussion. >> >> > On 6 Mar 2019, at 16:23, Tim Mackinnon <tim(a)testit.works> wrote: >> > >> > As Richard said - as a bag is relationship between keys and >> frequencies, I would expect it to be able to convert to a dictionary. >> > >> > It displays in an inspector just like a Dictionary - which is why I >> figured I could convert to pass it back to the exercise that was written >> with Dictionaries in mind. >> > >> > <PastedGraphic-3.png> >> > >> > >> > The code to fix it is quite simple, but on these kinds of things - I >> thought it worth checking before submitting a PR. >> > >> > Tim >> > >> > >> >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> Why would that work ? What would you expect the output to be ? >> >> >> >> Try: >> >> >> >> #(1 2 3) asDictionary >> >> >> >> it fails in exactly the same way. You need key/value pairs >> (Associations). >> >> >> >> These do work >> >> >> >> Bag new add: #foo->100; asDictionary. >> >> >> >> Bag new addAll: 'ABABABAAAA'; valuesAndCounts. >> >> >> >>> On 6 Mar 2019, at 14:25, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> >> >>> I was surprised to find that a Bag canât convert to a dictionary - >> e.g. >> >>> >> >>> Bag new >> >>> addAll: 'aabbbbcdddâ; >> >>> asDictionary >> >>> >> >>> Gives an error - Dnu #key >> >>> >> >>> >> >>> It looks to me like Bag is inheriting a bad version of >> #associationsDo: and instead could simply forward it to #doWithOccurences: >> instead? >> >>> >> >>> I know Bag is not used that much - but it comes up a lot in >> programming exercises. >> >>> >> >>> Tim >> >> >> >> >> > >> >> >> >> >

March 6, 2019

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

by Sven Van Caekenberghe

I am still not convinced. > On 6 Mar 2019, at 19:24, Tim Mackinnon <tim(a)testit.works> wrote: > > I still am tempted to make asDictionary work - because the the moment you get a #key , DNU error - which is definitely not right. The error might not be super clear, but it is not wrong, the elements of your collection do not respond to #key, a necessity to create a dictionary from a collection of associations/pairs. Also, if you modify #asDictionary like that, then <some bag> as: #Dictionary will still fail. This is all not so simple as it seems. > So should Bag asDictionary give you a reasonable dictionary, or should it throw a proper exception - something like: > > DomainError signal: â#asDictionary not supported, use #valueAndCountsâ > > Is that better - or do we accept that it inherits it from Collection and so can do something useful? > > Tim > >> On 6 Mar 2019, at 18:11, phil(a)highoctane.be wrote: >> >> And when asking the object: >> >> #(1 2 4 5 6 7 2 1 4 3) asBag isDictionary >> >> we get false. So, not, not a dictionary. >> >> I still have been using #valuesAndCounts to get the dictionary out of a bag on several occasions. >> >> And is useful indeed. >> >> #(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2 >> >> and >> >> #(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2 >> >> seem pretty much the same. >> >> But in this age of streams/reactive streams and lazy evaluations, what do we have in Pharo on that front? >> >> Phil >> >> >> >> >> >> On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> I was just explaining how it is now, what I think the rationale is behind it. >> >> I understand #asDictionary as working on a collection of pairs/associations (because it basically goes to #withAll:). >> >> A bag is just a collection that is optimised for many duplicates, the fact that you have values and counts is more an implementation detail than an intrinsic property. >> >> The conversion that you want, and that already exists in #valuesAndCounts is one interpretation of what a bag is, not the only one. A bag is foremost a collection of things. >> >> I am not immediately convinced that #valuesAndCounts should be the default #asDictionary interpretation. >> >> What about the inverse for example ? >> >> { #foo->2. #bar->3 } asDictionary asBag. >> >> But this is certainly an interesting discussion. >> >> > On 6 Mar 2019, at 16:23, Tim Mackinnon <tim(a)testit.works> wrote: >> > >> > As Richard said - as a bag is relationship between keys and frequencies, I would expect it to be able to convert to a dictionary. >> > >> > It displays in an inspector just like a Dictionary - which is why I figured I could convert to pass it back to the exercise that was written with Dictionaries in mind. >> > >> > <PastedGraphic-3.png> >> > >> > >> > The code to fix it is quite simple, but on these kinds of things - I thought it worth checking before submitting a PR. >> > >> > Tim >> > >> > >> >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> Why would that work ? What would you expect the output to be ? >> >> >> >> Try: >> >> >> >> #(1 2 3) asDictionary >> >> >> >> it fails in exactly the same way. You need key/value pairs (Associations). >> >> >> >> These do work >> >> >> >> Bag new add: #foo->100; asDictionary. >> >> >> >> Bag new addAll: 'ABABABAAAA'; valuesAndCounts. >> >> >> >>> On 6 Mar 2019, at 14:25, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> >> >>> I was surprised to find that a Bag canât convert to a dictionary - e.g. >> >>> >> >>> Bag new >> >>> addAll: 'aabbbbcdddâ; >> >>> asDictionary >> >>> >> >>> Gives an error - Dnu #key >> >>> >> >>> >> >>> It looks to me like Bag is inheriting a bad version of #associationsDo: and instead could simply forward it to #doWithOccurences: instead? >> >>> >> >>> I know Bag is not used that much - but it comes up a lot in programming exercises. >> >>> >> >>> Tim >> >> >> >> >> > >> >> >> >

March 6, 2019

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

by Tim Mackinnon

I still am tempted to make asDictionary work - because the the moment you get a #key , DNU error - which is definitely not right. So should Bag asDictionary give you a reasonable dictionary, or should it throw a proper exception - something like: DomainError signal: â#asDictionary not supported, use #valueAndCountsâ Is that better - or do we accept that it inherits it from Collection and so can do something useful? Tim > On 6 Mar 2019, at 18:11, phil(a)highoctane.be wrote: > > And when asking the object: > > #(1 2 4 5 6 7 2 1 4 3) asBag isDictionary > > we get false. So, not, not a dictionary. > > I still have been using #valuesAndCounts to get the dictionary out of a bag on several occasions. > > And is useful indeed. > > #(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2 > > and > > #(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2 > > seem pretty much the same. > > But in this age of streams/reactive streams and lazy evaluations, what do we have in Pharo on that front? > > Phil > > > > > > On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > I was just explaining how it is now, what I think the rationale is behind it. > > I understand #asDictionary as working on a collection of pairs/associations (because it basically goes to #withAll:). > > A bag is just a collection that is optimised for many duplicates, the fact that you have values and counts is more an implementation detail than an intrinsic property. > > The conversion that you want, and that already exists in #valuesAndCounts is one interpretation of what a bag is, not the only one. A bag is foremost a collection of things. > > I am not immediately convinced that #valuesAndCounts should be the default #asDictionary interpretation. > > What about the inverse for example ? > > { #foo->2. #bar->3 } asDictionary asBag. > > But this is certainly an interesting discussion. > > > On 6 Mar 2019, at 16:23, Tim Mackinnon <tim(a)testit.works> wrote: > > > > As Richard said - as a bag is relationship between keys and frequencies, I would expect it to be able to convert to a dictionary. > > > > It displays in an inspector just like a Dictionary - which is why I figured I could convert to pass it back to the exercise that was written with Dictionaries in mind. > > > > <PastedGraphic-3.png> > > > > > > The code to fix it is quite simple, but on these kinds of things - I thought it worth checking before submitting a PR. > > > > Tim > > > > > >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >> > >> Why would that work ? What would you expect the output to be ? > >> > >> Try: > >> > >> #(1 2 3) asDictionary > >> > >> it fails in exactly the same way. You need key/value pairs (Associations). > >> > >> These do work > >> > >> Bag new add: #foo->100; asDictionary. > >> > >> Bag new addAll: 'ABABABAAAA'; valuesAndCounts. > >> > >>> On 6 Mar 2019, at 14:25, Tim Mackinnon <tim(a)testit.works> wrote: > >>> > >>> I was surprised to find that a Bag canât convert to a dictionary - e.g. > >>> > >>> Bag new > >>> addAll: 'aabbbbcdddâ; > >>> asDictionary > >>> > >>> Gives an error - Dnu #key > >>> > >>> > >>> It looks to me like Bag is inheriting a bad version of #associationsDo: and instead could simply forward it to #doWithOccurences: instead? > >>> > >>> I know Bag is not used that much - but it comes up a lot in programming exercises. > >>> > >>> Tim > >> > >> > > > > >

March 6, 2019

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

by Esteban Maringolo

I couldn't find a "simple enough" solution to deal with that, so I moved to emulated Linux [1]. I don't know if the long file path is a limitation of Windows itself or libgit2. Because if it's the former, then I'll try this setting in Windows 10 and let you know if it works: https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-o… Regards! Esteban A. Maringolo El miÃ©., 6 mar. 2019 a las 13:19, Sean P. DeNigris (<sean(a)clipperadams.com>) escribiÃ³: > > Tim Mackinnon wrote > > how is this shared repository supposed to work? > > While I initially liked the space efficiency of the shared approach, I > eventually gave up because it created too many (often obscure) problems. It > just doesn't seem to be a good match for git, although you can get away with > it in the simplest cases (read-only, no branch switching). It sounds like > you may not have the luxury of avoiding it so hopefully someone can provide > more constructive help. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

March 6, 2019

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

by phil＠highoctane.be

And then the Pharo launcher folder suddenly appears as a 20GB folder... Same league as a Maven .m2, albeit with a messier structure, full of copies all over the place. Is Cargo going to help us there? Phil On Wed, Mar 6, 2019 at 5:18 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tim Mackinnon wrote > > how is this shared repository supposed to work? > > While I initially liked the space efficiency of the shared approach, I > eventually gave up because it created too many (often obscure) problems. It > just doesn't seem to be a good match for git, although you can get away > with > it in the simplest cases (read-only, no branch switching). It sounds like > you may not have the luxury of avoiding it so hopefully someone can provide > more constructive help. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > >

March 6, 2019

Re: [Pharo-users] Why can't a Bag answer as a dictionary?

by phil＠highoctane.be

And when asking the object: #(1 2 4 5 6 7 2 1 4 3) asBag isDictionary we get false. So, not, not a dictionary. I still have been using #valuesAndCounts to get the dictionary out of a bag on several occasions. And is useful indeed. #(1 2 4 5 6 7 2 1 4 3) asBag occurrencesOf: 2 and #(1 2 4 5 6 7 2 1 4 3) asBag valuesAndCounts at: 2 seem pretty much the same. But in this age of streams/reactive streams and lazy evaluations, what do we have in Pharo on that front? Phil On Wed, Mar 6, 2019 at 4:49 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I was just explaining how it is now, what I think the rationale is behind > it. > > I understand #asDictionary as working on a collection of > pairs/associations (because it basically goes to #withAll:). > > A bag is just a collection that is optimised for many duplicates, the fact > that you have values and counts is more an implementation detail than an > intrinsic property. > > The conversion that you want, and that already exists in #valuesAndCounts > is one interpretation of what a bag is, not the only one. A bag is foremost > a collection of things. > > I am not immediately convinced that #valuesAndCounts should be the default > #asDictionary interpretation. > > What about the inverse for example ? > > { #foo->2. #bar->3 } asDictionary asBag. > > But this is certainly an interesting discussion. > > > On 6 Mar 2019, at 16:23, Tim Mackinnon <tim(a)testit.works> wrote: > > > > As Richard said - as a bag is relationship between keys and frequencies, > I would expect it to be able to convert to a dictionary. > > > > It displays in an inspector just like a Dictionary - which is why I > figured I could convert to pass it back to the exercise that was written > with Dictionaries in mind. > > > > <PastedGraphic-3.png> > > > > > > The code to fix it is quite simple, but on these kinds of things - I > thought it worth checking before submitting a PR. > > > > Tim > > > > > >> On 6 Mar 2019, at 13:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Why would that work ? What would you expect the output to be ? > >> > >> Try: > >> > >> #(1 2 3) asDictionary > >> > >> it fails in exactly the same way. You need key/value pairs > (Associations). > >> > >> These do work > >> > >> Bag new add: #foo->100; asDictionary. > >> > >> Bag new addAll: 'ABABABAAAA'; valuesAndCounts. > >> > >>> On 6 Mar 2019, at 14:25, Tim Mackinnon <tim(a)testit.works> wrote: > >>> > >>> I was surprised to find that a Bag canât convert to a dictionary - e.g. > >>> > >>> Bag new > >>> addAll: 'aabbbbcdddâ; > >>> asDictionary > >>> > >>> Gives an error - Dnu #key > >>> > >>> > >>> It looks to me like Bag is inheriting a bad version of > #associationsDo: and instead could simply forward it to #doWithOccurences: > instead? > >>> > >>> I know Bag is not used that much - but it comes up a lot in > programming exercises. > >>> > >>> Tim > >> > >> > > > > > >

March 6, 2019

Re: [Pharo-users] IMAP in Pharo

by Tim Mackinnon

> On 6 Mar 2019, at 16:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > cedreek wrote >> Still havent get my head around this FORK/PR cycle but I will for sure one >> day :) > > It took me quite a while to grok. Fork = 'personal remote clone' and: [ PR = > 'UI support for discussing, testing, and accepting commits' ] It took me even longer to realise that when you load your master branch - you still need to pull changes from the original unforked repository (into your local repository) and then push them back up to your fork, AND then branch to make a change. For ages I was was getting unrelated diff changes even though I thought I had started on âmasterâ. Iâm hoping there will be a talk about all of this at Pharo Days. When you get it right its awesome - but when you take a mis-step its quite confusing until you realise what the pieces mean. (And Iâm sure I still have the model wrong, but its fun learning more each day) Tim

March 6, 2019

Re: [Pharo-users] How exactly is "share repositories between images" supposed to work without tripping each other up?

by Sean P. DeNigris

Tim Mackinnon wrote > how is this shared repository supposed to work? While I initially liked the space efficiency of the shared approach, I eventually gave up because it created too many (often obscure) problems. It just doesn't seem to be a good match for git, although you can get away with it in the simplest cases (read-only, no branch switching). It sounds like you may not have the luxury of avoiding it so hopefully someone can provide more constructive help. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 6, 2019

Re: [Pharo-users] Serializing classes with Fuel

by Konrad Hinsen

Hi Mariano, > Yes, that's the "default" behavior. To fully serialize classes you need > FuelMetalevel packages. This brings a new visitors and mappers to allow you > to fully serialize methods, classes, contexts, etc. Thanks for the pointer - I will explore FuelMetalevel. Konrad.

March 6, 2019

Re: [Pharo-users] IMAP in Pharo

by Sean P. DeNigris

cedreek wrote > Still havent get my head around this FORK/PR cycle but I will for sure one > day :) It took me quite a while to grok. Fork = 'personal remote clone' and: [ PR = 'UI support for discussing, testing, and accepting commits' ] ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 6, 2019