[Vm-dev] [Pharo-dev] ftp repositories broken

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 4 16:59:43 UTC 2017


Hi Esteban,


> On Apr 4, 2017, at 9:45 AM, Esteban Lorenzano <estebanlm at gmail.com> wrote:
> 
> 
>> On 4 Apr 2017, at 18:01, Ben Coman <btc at openInWorld.com> wrote:
>> 
>> 
>> 
>> On Tue, Apr 4, 2017 at 10:12 PM, Denis Kudriashov <dionisiydk at gmail.com> wrote:
>> >
>> >
>> > 2017-04-04 15:47 GMT+02:00 Esteban Lorenzano <estebanlm at 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=primitiveFindSubstring&type=.
> 
> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170404/60213a7b/attachment-0001.html>


More information about the Vm-dev mailing list