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

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

by Sven Van Caekenberghe

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] How exactly is "share repositories between images" supposed to work without tripping each other up?

by Tim Mackinnon

While, Iâm still interested in how share repositories works (and debunk some of my myths about it ) - digging into this users issue (isnât Fuel wonderful) - it would seem that this image wasnât created with share repositories on. It looking down a very complicated stack (Metacello is very complicated) - it seems like a âlocalGopherâ object has an IceMetacelloRepositoryAdaptor in it that has this non-existent path? It seems like it gets this path from reading packages - but heck if I know how it ended up with something that wasnât on the users file system (although they did have an image like that at some point previous). Anyway - if it jumps out at someone - Iâd be interested, but otherwise will let it go for now. Tim > On 6 Mar 2019, at 09:26, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - as many windows users have struggled with the long file path problem (some of which can be caused by orphaned files not even referenced in your baseline - but that were checked in) - many users have started using the "share repositories between imagesâ and point it to a nice short file path (at least we have a workaround). > > This got us running on Exercism - and unblocked our testers. > > However - I was suprised when I asked one of our users to update his image to pull in some new code that fixed an issue for him (Itâs the first time I've encountered a conflict and had to use onConflict - and Iâm not sure why there is a conflict - but thats a side point). > > Metacello new > baseline: 'Exercism'; > repository: 'github://exercism/pharo-smalltalk:master/dev/src <github://exercism/pharo-smalltalk:master/dev/src>'; > onConflict: [ :ex | ex allow ]; > load. > > > So doing the above on OSX loads the update into my older image, and everything was fine. However on Windows - one of my testers tried the same thing and got a strange error: > âNotFound: failed to resolve path âC:\pharo\images\Exercism test\pharo-localâ¦.â (See photo below). > > The weird bit is that we arenât sure where the âExercism testâ bit comes from because his image isnât "Exercism testâ - however I suspect that this is one of the other images he created when we were testing 64 bit and he was loading into that. > > So my question is - how is this shared repository supposed to work? It seems to me that different images are storing non-sharable information in the repository such that sharing canât possibly work? As my baseline and setup are really simple - Iâm suprised by this - there is literally 4 packages and one external dependency on OSProcess (which is an mcz I think). So why does this fail? Iâve always avoided the shared repository as when I initially tried it, I recall all kinds of weird behaviour - but as the windows folks canât seem to avoid it - can someone explain what it does and what we need to look out for? > > Tim > <PastedGraphic-2.png>

March 6, 2019

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

by Tim Mackinnon

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. 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 Richard O'Keefe

Doubtless the original poster expected aBag asDictionary to answer a dictionary mapping the (distinct) elements of the bag to their counts. Mathematically, a bag can usefully be seen as a partial function from a set U to the positive integers, and a dictionary with U keys and positive integer values is precisely that. It's really not unreasonable to expect that, considering that there *is* a method that does just what the OP wanted: #valuesAndCounts. It's rather dangerous to expose private state like that, but it is not a private method. I would expect asDictionary ^contents copy On Thu, 7 Mar 2019 at 02:54, 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] Noob Question - slicing

by K K Subbu

> On Wed, 6 Mar 2019 at 12:00, Craig Johnson <craig(a)hivemind.net > <mailto:craig@hivemind.net>> wrote: > What is the simplest way to copy characters between positions 4 and > 8 from a string in Pharo?____ '1234567890' copyFrom: 5 to: 8 "5678" Page 207 in Updated Pharo by Example book explains more on substrings. HTH .. Subbu

March 6, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Sven Van Caekenberghe

> On 6 Mar 2019, at 15:15, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Surely a Symbol should never be #= to anything that is not > a Symbol? At least in VW, GST, Dolphin, and VAST, > #a = 'a' > 'a' = #a > both answer false, and I'd be rather upset if a symbol > ever compared equal to a string. The ANSI Smalltalk standard > says in several places that "Symbol objects are identity > objects", which is defined as "An object defined such that > a=b implies a==b". > > So the definition I am expecting to see is > > Symbol>> > = other > ^self == other > > Anything else is inconsistent with the standard and common > practice. Symbol hash and = are supposed to be fast all the > or what's the point? Because it is very convenient. It has also been like this in Pharo (and Squeak) for a long time. With the correct implementation, #= and #~= are just as fast when both arguments are Symbols. (We need a little fix there, as recently uncovered). We do not feel bound to the ANSI standard (we won't break it just for fun, it is a guide, but it can't stop us evolving). There are many points of view in the world, yours might be different than mine. > On Sat, 2 Mar 2019 at 09:02, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ah, it is an optimisation: if the first #== fails, but the argument is also a Symbol, then that means the are different for sure, so false is returned early, instead of failing in super's #= after that. > > And with ByteSymbol and WideSymbol, although they are exclusive (can never be equal), they can be different and if they are both Symbols, then you can return early (not just when their classes differ). > > > On 1 Mar 2019, at 18:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Why ? Please explain ... > > > >> On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: > >> > >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: > >>> > >>> > >>>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > >>>> > >>>> > >>>> From: Petr Fischer <petr.fischer(a)me.com> > >>>> Subject: Symbol equality method #= - weird condition in the Pharo sourcecode > >>>> Date: 1 March 2019 at 17:08:03 GMT+1 > >>>> To: pharo-users(a)lists.pharo.org > >>>> > >>>> > >>>> Hello, this is Symbol equality method in Pharo: > >>>> > >>>> 1: = aSymbol > >>>> 2: "Compare the receiver and aSymbol." > >>>> 3: self == aSymbol ifTrue: [^ true]. > >>>> 4: self class == aSymbol class ifTrue: [^ false]. > >>>> 5: "Use String comparison otherwise" > >>>> 6: ^ super = aSymbol > >>>> > >>>> Look at line 4 - what does it mean? That's wrong, isn't it? > >>>> > >>>> Typically, every symbol comparisons end up in line 3, but if you do some work with forward proxies for example, condition on line 3 is "false" and then weird things on line 4 happens. > >>>> > >>>> If line 4 and further are correct, can someone explain a little? > >>>> > >>>> Thanks! pf > >>> > >>> Yes, that looks weird. Line 4 should probably be removed, unless I am missing something. > >> > >> It is wrong in a Spur image, because we now have subclasses of Symbol. > >> But removing line 4 is not the right solution. See Nicolas' implementation > >> in Squeak: > >> > >> Symbol>>= aSymbol > >> "Compare the receiver and aSymbol." > >> self == aSymbol ifTrue: [^ true]. > >> aSymbol isSymbol ifTrue: [^ false]. > >> "Use String comparison otherwise" > >> ^ super = aSymbol > >> > >> Dave > >> > >>> > >>> Symbols are by definition always #== so in that sense, #= should not even be implemented (as #= on Object is defined as #==), but since its direct super class String already overwrote #=, it has to follow. > >>> > >>> The super call in line 6 is what allows Symbols and String to be compared. > >>> > >>> I would say line 4 is a kind of sanity check, but probably not needed. > > > >

March 6, 2019

Re: [Pharo-users] offers (deb and rpm packages included)

by Michael Zeder

cool @Offray, I added pacman format now, but I have no means to verify, if it installs correctly on Arch/Manjaro/other distros which use the pacman package management. If somebody can verify..? And, I yet have to come up with a way to ensure, that package updates dont break compatibility (vm is in /usr/share, while every user has her own image in home folder). Does by chance anybody here has contact to a linux distro maintainer? With Stef's okay, I will write to all major linux distro teams, if they like to include PharoLauncher into their repos (if they can't include it in the main repo, I will try to get it into Linux "App Stores" via flatpak/snap/etc, though the "real" distro repos would be better). Michael Am Mi, 6. MÃ¤r, 2019 um 10:02 VORMITTAGS schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > Nice, thank you! > (We are working on some packaging for linux, but somehow we are not > yet there :( ) > > Esteban > >> On 3 Mar 2019, at 17:52, Michael Zeder <post(a)michael-j-zeder.de> >> wrote: >> >> Hi! >> I would like to make two offers: >> First, I know, deciding to be provocative can hurt. I did it int the >> hope that the released energy will be transformed in something good >> by the community, so apology for having been loud and insistent. >> >> Second, I felt oblidged to give at least a little thing back (since >> I use Pharo mostly in spare time). So, hey Linuxers! Whenever I set >> up a new system, I integrate Pharo Launcher into the desktop >> environment. I thought, I just built Debian .deb and RPM packages, >> for convient installation, on multiuser desktops. >> https://gitlab.com/mjz/pharo-linux-packages >> Maybe you like it. What does it do? installs shell shortcut ( $ >> pharo ) and application menu item (Gnome, KDE etc), which when >> called, copy Launcher image and resources into hidden user dir ( >> /home/USER/.pharolauncher ), if needed, and start Pharo Launcher. >> Packaged as DEB and RPM for i386 and x86_64. Please always verify >> binary integrity. >> >> M >> >

March 6, 2019

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

by Richard O'Keefe

Surely a Symbol should never be #= to anything that is not a Symbol? At least in VW, GST, Dolphin, and VAST, #a = 'a' 'a' = #a both answer false, and I'd be rather upset if a symbol ever compared equal to a string. The ANSI Smalltalk standard says in several places that "Symbol objects are identity objects", which is defined as "An object defined such that a=b implies a==b". So the definition I am expecting to see is Symbol>> = other ^self == other Anything else is inconsistent with the standard and common practice. Symbol hash and = are supposed to be fast all the or what's the point? On Sat, 2 Mar 2019 at 09:02, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ah, it is an optimisation: if the first #== fails, but the argument is > also a Symbol, then that means the are different for sure, so false is > returned early, instead of failing in super's #= after that. > > And with ByteSymbol and WideSymbol, although they are exclusive (can never > be equal), they can be different and if they are both Symbols, then you can > return early (not just when their classes differ). > > > On 1 Mar 2019, at 18:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Why ? Please explain ... > > > >> On 1 Mar 2019, at 18:02, David T. Lewis <lewis(a)mail.msen.com> wrote: > >> > >> On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote: > >>> > >>> > >>>> On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > >>>> > >>>> > >>>> From: Petr Fischer <petr.fischer(a)me.com> > >>>> Subject: Symbol equality method #= - weird condition in the Pharo > sourcecode > >>>> Date: 1 March 2019 at 17:08:03 GMT+1 > >>>> To: pharo-users(a)lists.pharo.org > >>>> > >>>> > >>>> Hello, this is Symbol equality method in Pharo: > >>>> > >>>> 1: = aSymbol > >>>> 2: "Compare the receiver and aSymbol." > >>>> 3: self == aSymbol ifTrue: [^ true]. > >>>> 4: self class == aSymbol class ifTrue: [^ false]. > >>>> 5: "Use String comparison otherwise" > >>>> 6: ^ super = aSymbol > >>>> > >>>> Look at line 4 - what does it mean? That's wrong, isn't it? > >>>> > >>>> Typically, every symbol comparisons end up in line 3, but if you do > some work with forward proxies for example, condition on line 3 is "false" > and then weird things on line 4 happens. > >>>> > >>>> If line 4 and further are correct, can someone explain a little? > >>>> > >>>> Thanks! pf > >>> > >>> Yes, that looks weird. Line 4 should probably be removed, unless I am > missing something. > >> > >> It is wrong in a Spur image, because we now have subclasses of Symbol. > >> But removing line 4 is not the right solution. See Nicolas' > implementation > >> in Squeak: > >> > >> Symbol>>= aSymbol > >> "Compare the receiver and aSymbol." > >> self == aSymbol ifTrue: [^ true]. > >> aSymbol isSymbol ifTrue: [^ false]. > >> "Use String comparison otherwise" > >> ^ super = aSymbol > >> > >> Dave > >> > >>> > >>> Symbols are by definition always #== so in that sense, #= should not > even be implemented (as #= on Object is defined as #==), but since its > direct super class String already overwrote #=, it has to follow. > >>> > >>> The super call in line 6 is what allows Symbols and String to be > compared. > >>> > >>> I would say line 4 is a kind of sanity check, but probably not needed. > > > > >

March 6, 2019

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

by Sven Van Caekenberghe

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] Noob Question - slicing

by Sven Van Caekenberghe

In Calypso, select the checkbox next to the virtual category 'instance side', which will show all inherited methods (below Object) in the same browser, scroll to copy. #drop:take: sounds totally obscure to me, way worse than #copyFrom:to: first: or last: And what is your point with the Unicode rant ? What you are pointing at is called Normalization. It is not part of the standard image because the necessary databases and fonts are big. But is can be done in Pharo just fine. https://medium.com/concerning-pharo/an-implementation-of-unicode-normalizat… What is it with people complaining that they did not find something where they expected it ? Every language/environment/library/framework has a learning curve. The current class/method categorisations are what they are (historically and by design), there is more to life than string processing, many operations do make sense in other contexts too, that is a powerful thing. > On 6 Mar 2019, at 13:48, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > As someone else already pointed out, the standard way to copy > part of any array-like sequence is > aSequence copyFrom: firstIncludedIndex to: lastIncludedIndex > > How could you have found this by yourself? > > From the background, either > Click-select Tools-select Playground > or hold Ctrl down while typing OW (for Open Workspace). > In the new Playground/workspace, type > String > then Ctrl-B. You now have a five-pane browser open on > String. > > About half way down the third panel on the top you will see > converting > copying > displaying > Click on copying. > > Guess what? You WON'T see anything that looks relevant! > Maybe it's in an ancestral class. So look at the buttons > under the top row of panes: > All packages Scoped view | Flat Hier | Inst side Class side | ... > Hier looks promising. Click it. > > Now in the second pane you will see > ProtoObject > Object > Collection > SequenceableCollection > ArrayedCollection > String > ... > Select the parent class, ArrayedCollection. > Nope, nothing promising there either! > Select the grandparent class, SequenceableCollection. > And now the 'copying' method category has quite a few > potentially interesting methods, including #copyFrom:to:. > > There are four other related methods that I would argue > are in the wrong category: > allButFirst > allButFirst: count > allButLast > allButLast: count > are in the 'accessing' category. > > If you want something a bit more flexible, > you could add > drop: d take: t > "Discard the first |d| elements of the receiver if d >= 0. > Discard the last |d| elements of the receiver if d <= 0. > Return the first |t| elements of the result if t >= 0. > Return the last |t| elements of the result if t <= 0. > The result is the same kind of collection as the receiver." > |lb ub n| > n := self size. > d abs >= n ifTrue: [^self copyEmpty]. > d < 0 > ifTrue: [lb := 1. ub := n + d] > ifFalse: [lb := d+1. ub := n]. > ub - lb + 1 <= t abs ifFalse: [ > t < 0 > ifTrue: [lb := ub + t + 1] > ifFalse: [ub := lb + t - 1]]. > ^self copyFrom: lb to: ub > > Now I would like to suggest that you not use anything like this > *directly*. Go back to the Playground, and evaluate > > String with: (Character codePoint: 256) <Ctrl-P> > > The answer is 'Ä'. Pharo supports Unicode. Now try > > String with: $A with: (Character codePoint: 16r0304) > > In Pharo, the result looks like A followed by a separate > macron, but when it's pasted into HTML it displays > correctly as 'AÌ'. Pharo doesn't *quite* support Unicode. > If it did, the two strings with different lengths and no > codepoint in common would display exactly the same. > > The Unicode standard finds it necessary to distinguish > between characters, glyphs, graphemes, grapheme clusters, > codepoints, and a couple of other things. A Smalltalk > String is a sequence of *codepoints*, not a sequence of > "characters". There is no upper bound on the number of > codepoints that may be needed to encode one "character" > as the end user sees it, and from there on it gets > *complicated*. > > For over 20 years, it hasn't really made sense to think > of a string as a simply indexed sequence of characters. > Integer indices are a useful implementation-level detail > for remembering bounds from some "higher level" matching > technique, but are much less useful than you might expect. > > > > > > > > On Wed, 6 Mar 2019 at 12:00, Craig Johnson <craig(a)hivemind.net> wrote: > Hi All, > > > > I was trying to figure an elegant way to slice strings (Python style), and came up empty. > > > > What is the simplest way to copy characters between positions 4 and 8 from a string in Pharo? > > > > Craig >

March 6, 2019