For students of software engineering, I offer this as an example of one of the most common and costly types of error that you will encounter in real life. A small error may be introduced early in the development process, possibly slipping through the cracks through lack of review (as was the case in this example). The change is motivated by good intentions, but some aspect of the overall system design is overlooked. Once the mistake has been made, it becomes increasingly difficult to change as time goes by, and increasingly costly to support as new people need to understand the issue and work around its consequences. Over the life of the software, the accumulated costs of effort to understand and address the problem (typically budgeted separately under "software maintenance") far exceed the costs associated with the original change (typically budgeted as "development"). In addition to cost of maintenance, this kind of error can also defeat the intentions of the original developer. In the example we have here, the original change was motivated by an interest in making the system cleaner and easier to understand. But nearly a decade later, we see workarounds such as the #translatedPrimitives method below that are far worse than the original problem that someone was trying to solve. For the historical background on this particular exammple, see the earlier post by Henrik Sperre Johansen in this thread. Dave p.s. I am not a software engineer :-) On Tue, Apr 04, 2017 at 06:45:27PM +0200, Esteban Lorenzano wrote:
On 4 Apr 2017, at 18:01, Ben Coman <btc@openInWorld.com> wrote:
On Tue, Apr 4, 2017 at 10:12 PM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
2017-04-04 15:47 GMT+02:00 Esteban Lorenzano <estebanlm@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=primitiv... <https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=pr...>.
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