- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Ben Coman

On Wed, Apr 5, 2017 at 2:16 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Pavel, > > On Tue, Apr 4, 2017 at 1:15 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > >> >> >> 2017-04-03 15:00 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> Hello, >>> >>> This are the things I believe still needs to be solved to be able to >>> release Pharo 6.0: >>> >>> VM: >>> === >>> - win32, cairo fonts problem (I submitted a new VM to test, I think this >>> is fixed :P) >>> - make all tests pass (there are still some failing tests when compiling >>> a new VM)/. >>> - libgit2: Still not there, Jan and Ben were trying and sent some >>> suggestions but I still didnât had the time to test it. >>> >>> Image: >>> ===== >>> >>> - iceberg still needs to go inside the image, Iâm running to release >>> version 0.4 (maybe this week?) and then we can integrate. >>> - I'm still convinced there is a leak. I need to check this in detail. >>> And of course some help on thisâ¦ Pavel?â¦ would be cool :) >>> >> >> I have found one memory leak related to subscription type mixing: >> https://pharo.fogbugz.com/f/cases/19911 >> >> Then I had here a really huge image with 1.2 GB with all known memory >> leaks solved. It was leaking because of Undeclared, after cleaning of them >> (Undeclared removeUnreferencedKeys) it shrinked to 59 MB. >> >> In this particular case it was caused by code like this: >> >> initialize >> super initialize. >> noBindingBlock := [ objectSpace nilObject ] >> >> because noBindingBlock was undeclared, it created a reference from >> globals (Undeclared) to a particular context with all mess it referenced. >> >> Not sure if we should make some action like clean Undeclared before every >> snapshot. But the case like this is quite obscure and the information that >> people should beware it should be enough. >> > > Cleaning Undeclared arbitrarily is a very bad idea. Undeclared is where > we can find and eliminate Undeclared variables. Just eliminating them from > Undeclared does not solve the problem. The variables are still referenced > in coded. But when one removes them from Undeclared they become harder to > find. > > Instead the right solution is > a) to have tests in the standard test suite that check that Undeclared is > empty. If Undeclared is not empty the test should fail. > b) in any packaging or release process that produces a clean image there > should be a check for Undeclared being empty, and the build should fail if > it is not empty. > c) Smalltalk programmers should understand how undeclared variables work > in Smalltalk: > > Variables are declared either in some global pool such as Smalltalk, > TextConstants or a class pool (the dictionary holding class variables), or > as instance variables of a class, or as arguments and temporary variables > of a method. These are the only variables in the language. When the > compiler sees a variable name it searches for it, first amongst arguments > and temporaries, second amongst instance variables, third amongst class > variables, fourth amongst the class's imported pools, fifth in globals > (Smalltalk) and finally in Undeclared. If the variable is not found in any > of these places then a binding is created in Undeclared and that is used to > implement the variable. So undeclared variables are compiled as globals in > Undeclared. > > Whenever a variable is declared in a global pool (Smalltalk, a shared pool > or a class pool) the compiler checks for a binding in Undeclared and uses > that if it exists. Adding a class declares the class's binding in > Smalltalk. So uses of variables before they are declared get fixed up on > declaration without having to recompile the entire system. This is how the > system manages circularities amongst classes. A reference to a class that > has yet to be installed will be compiled as a reference to a binding in > Undeclared. When the class is installed it is set as the value of the > Undeclared binding, and the binding is moved from Undeclared to Smalltalk. > > When an instance variable is defined in a class that changes the shape of > the class's instances and so the class's methods are recompiled and that > will bind any undeclared references to the instance variable correctly. > > So an entry in Undeclared is > a) an indication that somewhere there is a missing declaration > b) a place where one can look for references to the undeclared binding > (references in the dictionary inspector, and I hope the Glamour inspector, > that opens when one inspects Undeclared) > c) a simple mechanism for allowing circular references amongst classes > > So under no circumstances remove bindings from Undeclared unless there are > no references from code to those bindings. There is a method that does > this: > Undeclared removeUnusedBindings > > HTH > Very informative. Thanks for that insight. Maybe should capture it for Deep Into Pharo (but I'm off to bed right now) cheers -ben > > >> Cheers, >> -- Pavel >> >> >>> List is a lot smaller now :) >>> If everything goes well, we can target to release next week. >>> >>> Next: >>> - Test the new process and tape some videos explaining how we will >>> contribute with a bootstrapped process using github :) >>> >>> cheers! >>> Esteban >>> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

April 4, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0 (updated to April 03)

by Eliot Miranda

Hi Pavel, On Tue, Apr 4, 2017 at 1:15 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > 2017-04-03 15:00 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> Hello, >> >> This are the things I believe still needs to be solved to be able to >> release Pharo 6.0: >> >> VM: >> === >> - win32, cairo fonts problem (I submitted a new VM to test, I think this >> is fixed :P) >> - make all tests pass (there are still some failing tests when compiling >> a new VM)/. >> - libgit2: Still not there, Jan and Ben were trying and sent some >> suggestions but I still didnât had the time to test it. >> >> Image: >> ===== >> >> - iceberg still needs to go inside the image, Iâm running to release >> version 0.4 (maybe this week?) and then we can integrate. >> - I'm still convinced there is a leak. I need to check this in detail. >> And of course some help on thisâ¦ Pavel?â¦ would be cool :) >> > > I have found one memory leak related to subscription type mixing: > https://pharo.fogbugz.com/f/cases/19911 > > Then I had here a really huge image with 1.2 GB with all known memory > leaks solved. It was leaking because of Undeclared, after cleaning of them > (Undeclared removeUnreferencedKeys) it shrinked to 59 MB. > > In this particular case it was caused by code like this: > > initialize > super initialize. > noBindingBlock := [ objectSpace nilObject ] > > because noBindingBlock was undeclared, it created a reference from globals > (Undeclared) to a particular context with all mess it referenced. > > Not sure if we should make some action like clean Undeclared before every > snapshot. But the case like this is quite obscure and the information that > people should beware it should be enough. > Cleaning Undeclared arbitrarily is a very bad idea. Undeclared is where we can find and eliminate Undeclared variables. Just eliminating them from Undeclared does not solve the problem. The variables are still referenced in coded. But when one removes them from Undeclared they become harder to find. Instead the right solution is a) to have tests in the standard test suite that check that Undeclared is empty. If Undeclared is not empty the test should fail. b) in any packaging or release process that produces a clean image there should be a check for Undeclared being empty, and the build should fail if it is not empty. c) Smalltalk programmers should understand how undeclared variables work in Smalltalk: Variables are declared either in some global pool such as Smalltalk, TextConstants or a class pool (the dictionary holding class variables), or as instance variables of a class, or as arguments and temporary variables of a method. These are the only variables in the language. When the compiler sees a variable name it searches for it, first amongst arguments and temporaries, second amongst instance variables, third amongst class variables, fourth amongst the class's imported pools, fifth in globals (Smalltalk) and finally in Undeclared. If the variable is not found in any of these places then a binding is created in Undeclared and that is used to implement the variable. So undeclared variables are compiled as globals in Undeclared. Whenever a variable is declared in a global pool (Smalltalk, a shared pool or a class pool) the compiler checks for a binding in Undeclared and uses that if it exists. Adding a class declares the class's binding in Smalltalk. So uses of variables before they are declared get fixed up on declaration without having to recompile the entire system. This is how the system manages circularities amongst classes. A reference to a class that has yet to be installed will be compiled as a reference to a binding in Undeclared. When the class is installed it is set as the value of the Undeclared binding, and the binding is moved from Undeclared to Smalltalk. When an instance variable is defined in a class that changes the shape of the class's instances and so the class's methods are recompiled and that will bind any undeclared references to the instance variable correctly. So an entry in Undeclared is a) an indication that somewhere there is a missing declaration b) a place where one can look for references to the undeclared binding (references in the dictionary inspector, and I hope the Glamour inspector, that opens when one inspects Undeclared) c) a simple mechanism for allowing circular references amongst classes So under no circumstances remove bindings from Undeclared unless there are no references from code to those bindings. There is a method that does this: Undeclared removeUnusedBindings HTH > Cheers, > -- Pavel > > >> List is a lot smaller now :) >> If everything goes well, we can target to release next week. >> >> Next: >> - Test the new process and tape some videos explaining how we will >> contribute with a bootstrapped process using github :) >> >> cheers! >> Esteban >> > > -- _,,,^..^,,,_ best, Eliot

April 4, 2017

Re: [Pharo-dev] ftp repositories broken

by Eliot Miranda

On Tue, Apr 4, 2017 at 10:00 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-04-04 18:45 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> > I think you are wrong because I check it carefully in Squeak and I >> found it on github https://github.com/OpenSmallta >> lk/opensmalltalk-vm/search?utf8=â&q=primitiveFindSubstring&type=. >> >> >> still is not there, because is not the same primitive :) >> > > Does it also means that latest VM is built differently then stable? > (primitive works on stable pharo). I just thought that we already moved to > opensmalltalk build process. > Not yet. We are close. Last week I got angry with Esteban because I thought that the joe was stalled because Pharo didn't want to move to opensmalltalk-vm, but I over reacted. One of the issues preventing the move was indeed this primitive and the fact that someone, without thinking to talk to anyone working with the VM, renamed the primitive, and then someone put it on the wrong class. Esteban and I have spent some hours trying to work around such issues. I wish people would be more considerate. If issues like this can be resolved we are very close to using the opensmalltalk-vm process for stable Pharo VMs. Esteban wants (and has built) a test build that tries to produce sources and generate Vs and runs tests every time VMMaker is committed. On the Squeak side we only try and build VMs when opensmalltalk-vm is committed in git. I don't want to stand in Esteban's way. I *do* want stable VMs to be built from the opensmalltalk-vm tree. _,,,^..^,,,_ best, Eliot

April 4, 2017

Re: [Pharo-dev] ftp repositories broken

by Eliot Miranda

Hi Denis, On Tue, Apr 4, 2017 at 9:53 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-04-04 18:45 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> still is not there, because is not the same primitive :) >> look, this is the way where it is generated: >> >> translatedPrimitives >> "an assorted list of various primitives" >> (ByteString compiledMethodAt: #findSubstringViaPrimitive:in:startingAt:matchTable: >> ifAbsent: []) ifNotNil: >> [^#("Pharo uses findSubstringViaPrimitive:in:startingAt:matchTable:" >> (Bitmap compress:toByteArray:) >> (Bitmap decompress:fromByteArray:at:) >> (Bitmap encodeBytesOf:in:at:) >> (Bitmap encodeInt:in:at:) >> (ByteString compare:with:collated:) >> (ByteString translate:from:to:table:) >> (ByteString findFirstInString:inSet:startingAt:) >> (ByteString indexOfAscii:inString:startingAt:) >> (String findSubstringViaPrimitive:in:startingAt:matchTable:) >> (ByteArray hashBytes:startingWith:) >> (SampledSound convert8bitSignedFrom:to16Bit:))]. >> ^#( >> (Bitmap compress:toByteArray:) >> (Bitmap decompress:fromByteArray:at:) >> (Bitmap encodeBytesOf:in:at:) >> (Bitmap encodeInt:in:at:) >> (ByteString compare:with:collated:) >> (ByteString translate:from:to:table:) >> (ByteString findFirstInString:inSet:startingAt:) >> (ByteString indexOfAscii:inString:startingAt:) >> (ByteString findSubstring:in:startingAt:matchTable:) >> (ByteArray hashBytes:startingWith:) >> (SampledSound convert8bitSignedFrom:to16Bit:) >> ) >> >> means that Pharo uses #indSubstringViaPrimitive:in:startingAt:matchTable: >> while squeak uses #findSubstring:in:startingAt:matchTable:. >> > > Ok maybe I not understand anything :) But to clarify lets look at image > side methods. > in Squeak: > > ByteString>>findSubstring: key in: body startingAt: start matchTable: > matchTable > <primitive: 'primitiveFindSubstring' module: 'MiscPrimitivePlugin'> > > > in Pharo: > > String>>findSubstringViaPrimitive: key in: body startingAt: start > matchTable: matchTable > <primitive: 'primitiveFindSubstring' module: 'MiscPrimitivePlugin'> > > > So to me they both uses same VM primitive primitiveFindSubstring. Does > they are really different inside VM? > No they're not different; they're the same. But the primitive works only with ByteString, so it should not be on String where it will try and work on WideString and return completely incorrect results. -- _,,,^..^,,,_ best, Eliot

April 4, 2017

Re: [Pharo-dev] ftp repositories broken

by Esteban Lorenzano

> On 4 Apr 2017, at 19:00, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-04-04 18:45 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> > I think you are wrong because I check it carefully in Squeak and I found it on github https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=â&q=primiti… <https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=p…>. > > still is not there, because is not the same primitive :) > > Does it also means that latest VM is built differently then stable? (primitive works on stable pharo). I just thought that we already moved to opensmalltalk build process. stable works because the bug ByteString>>#findâ¦ instead of String>>#findâ¦ was introduced later.

April 4, 2017

Re: [Pharo-dev] ftp repositories broken

by Denis Kudriashov

2017-04-04 18:45 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > I think you are wrong because I check it carefully in Squeak and I found > it on github https://github.com/OpenSmalltalk/opensmalltalk- > vm/search?utf8=â&q=primitiveFindSubstring&type=. > > > still is not there, because is not the same primitive :) > Does it also means that latest VM is built differently then stable? (primitive works on stable pharo). I just thought that we already moved to opensmalltalk build process.

April 4, 2017

Re: [Pharo-dev] ftp repositories broken

by Eliot Miranda

Hi Esteban, > On Apr 4, 2017, at 9:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 4 Apr 2017, at 18:01, Ben Coman <btc(a)openInWorld.com> wrote: >> >> >> >> On Tue, Apr 4, 2017 at 10:12 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > >> > >> > 2017-04-04 15:47 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> >> no it doesn't: squeak does not have that primitive, thatâs why it does not fails :) >> > >> > >> > I think you are wrong because I check it carefully in Squeak and I found it on github https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=â&q=primiti…. > > still is not there, because is not the same primitive :) > look, this is the way where it is generated: > > translatedPrimitives > "an assorted list of various primitives" > (ByteString compiledMethodAt: #findSubstringViaPrimitive:in:startingAt:matchTable: ifAbsent: []) ifNotNil: > [^#("Pharo uses findSubstringViaPrimitive:in:startingAt:matchTable:" > (Bitmap compress:toByteArray:) > (Bitmap decompress:fromByteArray:at:) > (Bitmap encodeBytesOf:in:at:) > (Bitmap encodeInt:in:at:) > (ByteString compare:with:collated:) > (ByteString translate:from:to:table:) > (ByteString findFirstInString:inSet:startingAt:) > (ByteString indexOfAscii:inString:startingAt:) > (String findSubstringViaPrimitive:in:startingAt:matchTable:) > (ByteArray hashBytes:startingWith:) > (SampledSound convert8bitSignedFrom:to16Bit:))]. > ^#( > (Bitmap compress:toByteArray:) > (Bitmap decompress:fromByteArray:at:) > (Bitmap encodeBytesOf:in:at:) > (Bitmap encodeInt:in:at:) > (ByteString compare:with:collated:) > (ByteString translate:from:to:table:) > (ByteString findFirstInString:inSet:startingAt:) > (ByteString indexOfAscii:inString:startingAt:) > (ByteString findSubstring:in:startingAt:matchTable:) > (ByteArray hashBytes:startingWith:) > (SampledSound convert8bitSignedFrom:to16Bit:) > ) > > means that Pharo uses #indSubstringViaPrimitive:in:startingAt:matchTable: while squeak uses #findSubstring:in:startingAt:matchTable:. > Now, there is a bug there (because source is in String and not in ByteString), and I can fix that by asking correctly, but: > > 1) this means that sources for pharo and squeak will be different and pharo needs to be generated in pharo. This is contrary to what we are trying to do with the VM: we want all sources to be the same, and differences should come from compilation flags and/or the presence of certain plugins (this is because is a lot easier to debug the VM like that). > 2) I wonderâ¦ why we are using this primitive an squeak is not? maybe we need to deprecate the use? > >> I believe Esteban's point Its not so much whether the VM has it >> (since they are essentially the same VM + extra C-libs for Pharo) >> but whether the Squeak Image is using it. >> >> Squeak does use primitiveFindSubstring, but a difference is attached to ByteString rather than String. >> That was added to Squeak 2015.05.01. Squeak String seems to have never used the primitive (since 2005). > > this is the important thing, I thinkâ¦ soâ¦ why canât we use that instead the other one? > whatâs the difference? You have identified the problem. The bug is that Pharo broke this by renaming and repositioning the primitive to findSubstringViaPrimitive:in:startingAt:matchTable:. If it had stayed where it was things would still be working. So my suggestions are a) restore Pharo to using by the primitive correctly in the exactly the same configuration as Squeak b) no one in the Pharo community changes the definition or position of a primitive without consulting a vm person (and Esteban is a vm person as is ClÃ©ment and arguably Guille). c) we measure the performance of the primitive and the equivalent non-primitive code in StackInterpreter, Cog and Sista configurations (using Spur, the current object representation) for a range of strings and see how much benefit we're getter by from the primitive; maybe we can nuke it. But yes, it is a bad bug to position this primitive in String; it works only for ByteString. > > cheers! > Esteban > > >> >> A diff shows some differences in implementation.. >> https://www.diffchecker.com/CmBJZjB6 >> which anyway wouldn't account for John's observations. >> >> cheers -ben >

April 4, 2017

Re: [Pharo-dev] ftp repositories broken

by Denis Kudriashov

2017-04-04 18:01 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > I believe Esteban's point Its not so much whether the VM has it > (since they are essentially the same VM + extra C-libs for Pharo) > but whether the Squeak Image is using it. > > Squeak does use primitiveFindSubstring, but a difference is attached to > ByteString rather than String. > That was added to Squeak 2015.05.01. Squeak String seems to have never > used the primitive (since 2005). You can make experiment. Replace fallback code with "self primitiveFailed" and call this method from comment examples. It works in SqueakVM. And it fails with latest PharoVM. Actually just remove this method from ByteString. And many debuggers will approve that method is used

April 4, 2017

Re: [Pharo-dev] ftp repositories broken

by Denis Kudriashov

2017-04-04 18:45 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > still is not there, because is not the same primitive :) > look, this is the way where it is generated: > > translatedPrimitives > "an assorted list of various primitives" > (ByteString compiledMethodAt: #findSubstringViaPrimitive:in:startingAt:matchTable: > ifAbsent: []) ifNotNil: > [^#("Pharo uses findSubstringViaPrimitive:in:startingAt:matchTable:" > (Bitmap compress:toByteArray:) > (Bitmap decompress:fromByteArray:at:) > (Bitmap encodeBytesOf:in:at:) > (Bitmap encodeInt:in:at:) > (ByteString compare:with:collated:) > (ByteString translate:from:to:table:) > (ByteString findFirstInString:inSet:startingAt:) > (ByteString indexOfAscii:inString:startingAt:) > (String findSubstringViaPrimitive:in:startingAt:matchTable:) > (ByteArray hashBytes:startingWith:) > (SampledSound convert8bitSignedFrom:to16Bit:))]. > ^#( > (Bitmap compress:toByteArray:) > (Bitmap decompress:fromByteArray:at:) > (Bitmap encodeBytesOf:in:at:) > (Bitmap encodeInt:in:at:) > (ByteString compare:with:collated:) > (ByteString translate:from:to:table:) > (ByteString findFirstInString:inSet:startingAt:) > (ByteString indexOfAscii:inString:startingAt:) > (ByteString findSubstring:in:startingAt:matchTable:) > (ByteArray hashBytes:startingWith:) > (SampledSound convert8bitSignedFrom:to16Bit:) > ) > > means that Pharo uses #indSubstringViaPrimitive:in:startingAt:matchTable: > while squeak uses #findSubstring:in:startingAt:matchTable:. > Ok maybe I not understand anything :) But to clarify lets look at image side methods. in Squeak: ByteString>>findSubstring: key in: body startingAt: start matchTable: matchTable <primitive: 'primitiveFindSubstring' module: 'MiscPrimitivePlugin'> in Pharo: String>>findSubstringViaPrimitive: key in: body startingAt: start matchTable: matchTable <primitive: 'primitiveFindSubstring' module: 'MiscPrimitivePlugin'> So to me they both uses same VM primitive primitiveFindSubstring. Does they are really different inside VM?

April 4, 2017

Re: [Pharo-dev] ftp repositories broken

by Esteban Lorenzano

> On 4 Apr 2017, at 18:01, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Tue, Apr 4, 2017 at 10:12 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > > > > > 2017-04-04 15:47 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > >> > >> no it doesn't: squeak does not have that primitive, thatâs why it does not fails :) > > > > > > I think you are wrong because I check it carefully in Squeak and I found it on github https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=â&q=primiti… <https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=p…>. still is not there, because is not the same primitive :) look, this is the way where it is generated: translatedPrimitives "an assorted list of various primitives" (ByteString compiledMethodAt: #findSubstringViaPrimitive:in:startingAt:matchTable: ifAbsent: []) ifNotNil: [^#("Pharo uses findSubstringViaPrimitive:in:startingAt:matchTable:" (Bitmap compress:toByteArray:) (Bitmap decompress:fromByteArray:at:) (Bitmap encodeBytesOf:in:at:) (Bitmap encodeInt:in:at:) (ByteString compare:with:collated:) (ByteString translate:from:to:table:) (ByteString findFirstInString:inSet:startingAt:) (ByteString indexOfAscii:inString:startingAt:) (String findSubstringViaPrimitive:in:startingAt:matchTable:) (ByteArray hashBytes:startingWith:) (SampledSound convert8bitSignedFrom:to16Bit:))]. ^#( (Bitmap compress:toByteArray:) (Bitmap decompress:fromByteArray:at:) (Bitmap encodeBytesOf:in:at:) (Bitmap encodeInt:in:at:) (ByteString compare:with:collated:) (ByteString translate:from:to:table:) (ByteString findFirstInString:inSet:startingAt:) (ByteString indexOfAscii:inString:startingAt:) (ByteString findSubstring:in:startingAt:matchTable:) (ByteArray hashBytes:startingWith:) (SampledSound convert8bitSignedFrom:to16Bit:) ) means that Pharo uses #indSubstringViaPrimitive:in:startingAt:matchTable: while squeak uses #findSubstring:in:startingAt:matchTable:. Now, there is a bug there (because source is in String and not in ByteString), and I can fix that by asking correctly, but: 1) this means that sources for pharo and squeak will be different and pharo needs to be generated in pharo. This is contrary to what we are trying to do with the VM: we want all sources to be the same, and differences should come from compilation flags and/or the presence of certain plugins (this is because is a lot easier to debug the VM like that). 2) I wonderâ¦ why we are using this primitive an squeak is not? maybe we need to deprecate the use? > I believe Esteban's point Its not so much whether the VM has it > (since they are essentially the same VM + extra C-libs for Pharo) > but whether the Squeak Image is using it. > > Squeak does use primitiveFindSubstring, but a difference is attached to ByteString rather than String. > That was added to Squeak 2015.05.01. Squeak String seems to have never used the primitive (since 2005). this is the important thing, I thinkâ¦ soâ¦ why canât we use that instead the other one? whatâs the difference? cheers! Esteban > > A diff shows some differences in implementation.. > https://www.diffchecker.com/CmBJZjB6 <https://www.diffchecker.com/CmBJZjB6> > which anyway wouldn't account for John's observations. > > cheers -ben

April 4, 2017