- Pharo-users - lists.pharo.org

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

Re: [Pharo-users] Noob Question - slicing

by Tim Mackinnon

Nice reply Richard - do you ever post any of these in a blog - the one below would be a great one to point to from Exercism... > On 6 Mar 2019, at 12: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 <mailto:craig@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

Why can't a Bag answer as a dictionary?

by Tim Mackinnon

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] A "with" construct like Pascal - easy to do, but is it terrible?

by Richard O'Keefe

The Pascal 'with' statement is among the most hated features of Pascal and was not copied in successor languages like Ada or Modula-2. It was typically replaced by record constructors, such as Book1 := Book[title : 'C Programming'; author : 'Nuha Ali '; subject : 'C Programming Tutorial'; book_id : 6495407]; which happens to be Pascal (ISO10206). In self classes do: [:class | | metaclass | metaclass := class metaclass. metaclass xxxx. mataclass yyyy. ] "metaclass" is a a block temporary, not an instance variable, and self classes do: [:each | (each metaclass) xxxx; yyyy]. suffices. We observe that [:x1 ... :xn | ...] value: e1 ... value: en is nothing other than a LET expression wearing a funny hat and should be inlined by a compiler -- mine does -- and that e1 in: [:x1 | ...] is just a "flipped" version of [:x1 | ...] value: e1, so there's no reason why a compiler shouldn't inline that. We also observe that e0 m1; ... ; mn can -- at least in my experience -- be most simply implemented as [:t | t m1. ... t mn] value: e0 followed by the usual inlining of that. So we might expect that some day self classes do: [:each | each metaclass in: [:t | t xxxx. t yyyy]] would generate the *same* code as the cascaded version. Right now, do whichever is clearer. On Tue, 5 Mar 2019 at 02:07, Tim Mackinnon <tim(a)testit.works> wrote: > Iâve noticed that as weâve progressed there has been a move to more > concise and fluid code - e.g. I quite like the new String streaming stuff > > e.g. > > ^ String > streamContents: [ :stream | > stream nextPut: â¦. ] > > > So I was wondering why we donât have a construct like Pascals with to > avoid Book1.title, Book1.author etc. > > (* book 1 specification *)With Book1 dobegin > title := 'C Programming'; > author := 'Nuha Ali '; > subject := 'C Programming Tutorial'; > book_id := 6495407;end; > > > I often find it a bit tedious with code like the following which then > needs an instvar... > > self classes do: [ :class | > | metaclass | > metaclass := class metaclass. > metaclass xxxx. > mataclass yyyy. > ] > > > Iâm wondering why we donât have #with:do: > > class with: class metaclass do: [:metaclass | > metaclass xxx. > ] > > > But when such things arenât there - there is usually a good reason and Iâm > curious â¦ this said, there are all kinds of other such tricks (which I > rarely use that I keep coming across). > > Tim > >

March 6, 2019

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 7.0.2 released!

by Norbert Hartl

yeah, bright future we come! Norbert > Am 06.03.2019 um 13:01 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > >> On 6 Mar 2019, at 12:38, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> How wonderful is that? How much effort it was compared to the old process? > > zero. > Bah, I needed to restart the CI because of the freetype random welcome problem. > > Esteban > >> >> Norbert >> >> >>> Am 06.03.2019 um 11:32 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>> >>> Hi, >>> >>> I just made a bugfix release of Pharo: >>> >>> v7.0.2 <https://github.com/pharo-project/pharo/releases/tag/v7.0.2> >>> <513630.jpeg> <https://github.com/estebanlm> estebanlm <https://github.com/estebanlm> released this 22 hours ago >>> >>> Bugfix release >>> >>> #2303 <https://github.com/pharo-project/pharo/issues/2303> Deprecation fixes in TEasilyThemed >>> #2120 <https://github.com/pharo-project/pharo/pull/2120> Object-centric MetaLink integration >>> #2376 <https://github.com/pharo-project/pharo/pull/2376> Ensure subMenu is opened (backport) >>> #2428 <https://github.com/pharo-project/pharo/pull/2428> Add scrollSelectionIntoView >>> #2700 <https://github.com/pharo-project/pharo/pull/2700> Tonel test is failing (backport) >>> >>> Enjoy :) >>> >>> Esteban >> >

March 6, 2019

Re: [Pharo-users] Noob Question - slicing

by Richard O'Keefe

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