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

Re: [Pharo-users] Fwd: startup error in windows 10

by Hilaire

Hi Benoit, It is DrGeo 18.06 https://launchpad.net/drgeo/trunk/18.06/+download/DrGeo.app-18.06a.zip Thanks to try out. Hilaire Le 30/01/2019 Ã 00:16, Benoit St-Jean via Pharo-users a Ã©critÂ : > Hilaire, do you have an URL so I can download the exact same thing > that users has?Â I'm also on Windows 10. > > I'll try to run in dev mode and see what happens! -- Dr. Geo http://drgeo.eu

Jan. 30, 2019

Re: [Pharo-users] [Glass] [squeak-dev] Falsehoods programmers believe about Smalltalk

by HernÃ¡n Morales Durand

Thank you for your notes Richard, it's really interesting to see not so well-known projects. I would love to have more people sharing their wisdom and knocking down more myths. Cheers, HernÃ¡n El dom., 27 ene. 2019 a las 1:17, Richard O'Keefe via Glass (< glass(a)lists.gemtalksystems.com>) escribiÃ³: > I have my own Smalltalk system implemented as a batch compiler via C. > This was originally just going to be a baseline for a student wanting > to work on JIT, but he went elsewhere and I found the system surprisingly > useful. I also wanted something that hewed closely to the ANSI Smalltalk > standard, but could diverge in other matters (like not having dynamic code > modification). > > - All Smalltalk bytecode sets are stack-based VM. (?) > > My system has no bytecodes. Smalltalk=>C=>native code. > > - Bytecodes are always fixed-size. (?) > > False back in the Blue Book. Why does it matter anyway? > > - Most of the time spent by a VM is in the instruction interpreter. > (actually it's in the GC right?) > > There is no interpreter in my system, and many modern systems use a JIT. > That or they generate Javascript or JVM instructions or .NET or something, > and then _that_ gets turned into native code. > > - You cannot serialize objects containing blocks. (IIRC one can use > MessageSends) > > True in my system but that's because blocks contain pointers to native > code and may > contain pointers into the C stack. I have plans to work around this, but > it has not been > a priority. Something I don't ever plan to deal with is objects > containing references to > external objects (memory-mapped segments, file descriptors, sockets, ...) > and it is not > at all clear to me what the semantics should be. > > BinaryObjectStorage in VisualWorks has no trouble with blocks. > > I meant to try this in Pharo 7.0. The image I just installed via the > launcher has > no DataStream, ReferenceStream, or SmartRefStream, but the class comment > for MCDataStream begins > "This is the save-to-disk facility. > A DataStream can store one or more objects in a persistent form. > > To handle objects with sharing and cycles, you must use a ReferenceStream > instead of a DataStream. (Or SmartRefStream.) ReferenceStream is > typically > faster and produces smaller files because it doesn't repeatedly write the > same Symbols." > > This was also the case back to Pharo 2.0. What *is* the persistence > scheme in Pharo these days? > > - Image cannot be bootstrapped. (This is possible in ST/X and now in Pharo > I think). > > There are no images in my system. > > - All Smalltalks includes UI classes. (GemStone doesn't have AFAIK). > > It depends on what you mean by "include". Gnu Smalltalk *has* UI classes > but they > are not loaded by default. > > - All implementations uses direct pointers, (GST?) > > True in my case, but that's because I'm lazy and using the Boehm collector. > > - All implementations uses green threads. (VAST? MT?) > > False in my case. A Process is a POSIX (red) thread and no green threads > exist. > This meant having to keep the interface fairly lean, but honestly wasn't > that hard, > since the Boehm collector handled the hard stuff. > > > On Tue, 22 Jan 2019 at 13:27, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> >> Done. >> >> I have some possible myths, but I'd like to confirm or reject: >> >> - All Smalltalk bytecode sets are stack-based VM. (?) >> - Bytecodes are always fixed-size. (?) >> - Most of the time spent by a VM is in the instruction interpreter. >> (actually it's in the GC right?) >> - You cannot serialize objects containing blocks. (IIRC one can use >> MessageSends) >> - Image cannot be bootstrapped. (This is possible in ST/X and now in >> Pharo I think). >> - All Smalltalks includes UI classes. (GemStone doesn't have AFAIK). >> - All implementations uses direct pointers, (GST?) >> - All implementations uses green threads. (VAST? MT?) >> >> I'm sure people in this list will have a lot more myths heard from >> Conferences, Forums, Videos, Talks, etc. Like the guy who said Smalltalk >> was dead. So if you did something which could be ignored publicly, please >> don't hesitate to reply or ping me to get added as collaborator. >> >> Cheers, >> >> HernÃ¡n >> >> >> >> El dom., 20 ene. 2019 a las 22:41, Eliot Miranda (< >> eliot.miranda(a)gmail.com>) escribiÃ³: >> >>> Hi HernÃ¡n, >>> >>> On Sun, Jan 20, 2019 at 2:31 PM HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com> wrote: >>> >>>> Hi there, >>>> >>>> I just created a GitHub repo to collect myths around Smalltalk-based >>>> technologies: Pharo, Squeak, VW, VAST, Smalltalk/X, GNU/ST, etc. in the >>>> spirit of the Falsehoods lists [1-4]. >>>> >>>> This is just a draft now but please feel free to add falsehoods based >>>> on your own experiences. Examples are greatly appreciated. >>>> >>> >>> You want pull requests? If not, would you give me write permission? >>> I'd love to add to the "Smalltalk is obsolete" section... >>> >>> >>>> >>>> https://github.com/hernanmd/falsehoods_smalltalk >>>> >>>> Cheers, >>>> >>>> HernÃ¡n >>>> >>>> [1] >>>> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-ab… >>>> [2] >>>> https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/false… >>>> [3] >>>> https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md >>>> [4] >>>> https://meta-package-manager.readthedocs.io/en/develop/falsehoods.html >>>> >>>> >>>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >> _______________________________________________ > Glass mailing list > Glass(a)lists.gemtalksystems.com > http://lists.gemtalksystems.com/mailman/listinfo/glass >

Jan. 30, 2019

Re: [Pharo-users] Fwd: startup error in windows 10

by Benoit St-Jean

Hilaire, do you have an URL so I can download the exact same thing that users has?Â I'm also on Windows 10. I'll try to run in dev mode and see what happens! On 2019-01-29 14:27, Hilaire wrote: > I asked the user to send me the PharoDebug.log to have a more accurate > feedback: > > http://forum.drgeo.eu/file/n4025537/PharoDebug.log > > Of course I should make him to test with a newer VM to see if the > problem is gone, but it is a bitÂ more complicate. > > Are the video info necessary? The image world starts just fine. > > Hilaire > > Le 28/01/2019 Ã 23:34, Ben Coman a Ã©critÂ : >> To provide the best chance for someone to help, can you provide: >> * base Image version >> * vm version >> * systeminfo.exe (stripped of personally identifying data) >> Â Â * with dates added to hotfixes from >> (https://www.tenforums.com/tutorials/5472-view-windows-update-history-window…) >> * video info from (wmic path win32_VideoController get /all >> /format:htable >> c:\temp\graphics.html) -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Jan. 29, 2019

SmaCC parsing "rest until"

by Manuel Leuenberger

Hi, I am currently struggling with understanding why my SmaCC parser refuses to parse a rather simple language. Grammar and example are below. The language consists of multiple leak reports, separated by two newlines. Each leak report has a type and object and byte size on the first line. Then comes a stack of indented frames with addresses, and method and source location if available. Somehow my parser always fails because it trying to scan the whole string as <method>. I am struggling with this since hours but not making any progress. How do I need to rewrite the grammar so that the scanner produces the right tokens for the parser? I understand that the <method> token use in Source is problematic, because it needs to match until the last word. But I cannot find a way to write it in another way or tweak the parser attributes to figure out the right tokenization. Anybody has some hints? I would greatly appreciate it. Cheers, Manuel Example: LeReParser parse: 'Indirect leak of 8 byte(s) in 1 object(s) allocated from: #0 0x106be248c in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5d48c) #1 0x12193989d in moz_xmalloc mozalloc.cpp:83 #2 0x11fc8200d in std::__1::vector<unsigned int, std::__1::allocator<unsigned int> >::__append(unsigned long) mozalloc.h:194 #3 0x11fc80d5a in mozilla::gfx::GradientStopsSkia::GradientStopsSkia(std::__1::vector<mozilla::gfx::GradientStop, std::__1::allocator<mozilla::gfx::GradientStop> > const&, unsigned int, mozilla::gfx::ExtendMode) vector:2041 #4 0x11fc6f1dc in mozilla::gfx::DrawTargetSkia::CreateGradientStops(mozilla::gfx::GradientStop*, unsigned int, mozilla::gfx::ExtendMode) const DrawTargetSkia.cpp:62 #5 0x122236b1e in create_gradient_stops(mozilla::gfx::DrawTarget*, float*, unsigned int, mozilla::gfx::ExtendMode) pattern.cpp:98 #6 0x122236323 in moz2d_pattern_linear_gradient_create_flat pattern.cpp:40 #7 0x1069cf901 in primitiveCalloutWithArgs (Pharo:x86_64+0x1003a5901) #8 0x10669e222 in primitiveExternalCall gcc3x-cointerp.c:76887 #9 0x106694aed in executeNewMethod gcc3x-cointerp.c:22341 #10 0x10669a403 in ceSendsupertonumArgs gcc3x-cointerp.c:16540 #11 0x11043c134 (<unknown module>) #12 0x10662d712 in interpret gcc3x-cointerp.c:2754 #13 0x1068b2ada in -[sqSqueakMainApplication runSqueak] sqSqueakMainApplication.m:201 #14 0x7fffc93786fc in __NSFirePerformWithOrder (Foundation:x86_64+0xd76fc) #15 0x7fffc78cfc56 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ (CoreFoundation:x86_64h+0xa6c56) #16 0x7fffc78cfbc6 in __CFRunLoopDoObservers (CoreFoundation:x86_64h+0xa6bc6) #17 0x7fffc78b05f8 in __CFRunLoopRun (CoreFoundation:x86_64h+0x875f8) #18 0x7fffc78b0033 in CFRunLoopRunSpecific (CoreFoundation:x86_64h+0x87033) #19 0x7fffc6e10ebb in RunCurrentEventLoopInMode (HIToolbox:x86_64+0x30ebb) #20 0x7fffc6e10bf8 in ReceiveNextEventCommon (HIToolbox:x86_64+0x30bf8) #21 0x7fffc6e10b25 in _BlockUntilNextEventMatchingListInModeWithFilter (HIToolbox:x86_64+0x30b25) #22 0x7fffc53a5a53 in _DPSNextEvent (AppKit:x86_64+0x46a53) #23 0x7fffc5b217ed in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (AppKit:x86_64+0x7c27ed) #24 0x7fffc539a3da in -[NSApplication run] (AppKit:x86_64+0x3b3da) #25 0x7fffc5364e0d in NSApplicationMain (AppKit:x86_64+0x5e0d) #26 0x7fffdd0a2234 in start (libdyld.dylib:x86_64+0x5234) '. Grammar: %prefix LeRe; %suffix Node; %root Report; <newline> : \r \n? | \n ; <number> : \d+ ; <index> : \# \d+ ; <address> : 0 x [0-9a-f]+ ; <method> : [^\r\n]+ ; <file> : \S+ ; Report : Leaks 'leaks' { leaks } ; Leaks : Leak 'leak' { { leak } } | Leaks 'leaks' Leak 'leak' { leaks , { leak } } ; Leak : LeakType 'type' <number> 'bytes' " byte(s) in " <number> 'objects' " object(s) allocated from:" <newline> Stack 'stack' <newline> { { type . bytes value . objects value . stack } } ; LeakType : "Indirect leak of " { #indirect } | "Direct leak of " { #direct } ; Stack : Frames 'frames' { frames } ; Frames : Frame 'frame' { { frame } } | Frames 'frames' Frame 'frame' { frames , { frame } } ; Frame : " " <index> " " <address> " " Source 'source' <newline> { source } ; Source : " (<unknown module>)" { #unknown } | "in " <method> 'method' " " <file> 'file' { { method value . file value } } ;

Jan. 29, 2019

Re: [Pharo-users] PetitParser question

by Tudor Girba

Hi, > On Jan 29, 2019, at 7:04 PM, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Tudor Girba <tudor(a)tudorgirba.com> writes: > >> But, does it solve your problem? > > Not yet. Not sure it will. Would this not work: p := (#digit asPParser separatedBy: ($+ asPParser / $- asPParser) trim) ==> [:tokens | | result | result := tokens. 2 to: tokens size - 1 by: 2 do: [ :index | (tokens at: index) = (tokens at: 2) ifFalse: [result := PP2Failure message: 'expected ', (tokens at: 2) asString, ' but got ', (tokens at: index) asString ]]. result ]. p end parse: '1+3+2 - 6' "a PP2Failure: 'expected + but got -â" p end parse: '1+3+2 + 6' "#($1 $+ $3 $+ $2 $+ $6)â ? Please note that I used PetitParser2 for this one because it also addresses the failure message issue you raised below. However, the logic would work in PP1 as well. Cheers, Doru >>> More generally, there seems to be a bug in how PetitParser handles >>> PPFailure return values. The actually reported error is always different >>> from what is passed to PPFailure. I love software ;-) >> >> What do you mean? > > If I return > > PPFailure message: 'whatever' at: 0 > > from my parser, then it does fail but it reports a different error. > > After some more experiments, it looks like this is perhaps not a bug, > but a feature that makes returning failures not so useful after all. I > suspect that PetitParser simply backtracks after my failure and tries a > different rule that then fails as well. > > A simple example: > > | p | > p := #digit asParser plus flatten > ==> [ :value | value asSet size = 1 ifTrue: [ value ] ifFalse: [ PPFailure message: 'not equal' at: 0 ]]. > p parse: '22233' > > The reported failure is "digit expected at 5". > > On the other hand, if there is no path for backtracking, the reported > failure is the expected one: > > | p | > p := (#digit asParser, #digit asParser) flatten > ==> [ :value | value first = value second ifTrue: [ value ] ifFalse: [ PPFailure message: 'not equal' at: 0 ]]. > p parse: '23' > > Konrad. -- www.feenk.com "Quality cannot be an afterthought."

Jan. 29, 2019

Re: [Pharo-users] Fwd: startup error in windows 10

by Hilaire

I asked the user to send me the PharoDebug.log to have a more accurate feedback: http://forum.drgeo.eu/file/n4025537/PharoDebug.log Of course I should make him to test with a newer VM to see if the problem is gone, but it is a bitÂ more complicate. Are the video info necessary? The image world starts just fine. Hilaire Le 28/01/2019 Ã 23:34, Ben Coman a Ã©critÂ : > To provide the best chance for someone to help, can you provide: > * base Image version > * vm version > * systeminfo.exe (stripped of personally identifying data) > Â Â * with dates added to hotfixes from > (https://www.tenforums.com/tutorials/5472-view-windows-update-history-window…) > * video info from (wmic path win32_VideoController get /all > /format:htable >> c:\temp\graphics.html) -- Dr. Geo http://drgeo.eu

Jan. 29, 2019

Re: [Pharo-users] PetitParser question

by Konrad Hinsen

Tudor Girba <tudor(a)tudorgirba.com> writes: > But, does it solve your problem? Not yet. Not sure it will. >> More generally, there seems to be a bug in how PetitParser handles >> PPFailure return values. The actually reported error is always different >> from what is passed to PPFailure. I love software ;-) > > What do you mean? If I return PPFailure message: 'whatever' at: 0 from my parser, then it does fail but it reports a different error. After some more experiments, it looks like this is perhaps not a bug, but a feature that makes returning failures not so useful after all. I suspect that PetitParser simply backtracks after my failure and tries a different rule that then fails as well. A simple example: | p | p := #digit asParser plus flatten ==> [ :value | value asSet size = 1 ifTrue: [ value ] ifFalse: [ PPFailure message: 'not equal' at: 0 ]]. p parse: '22233' The reported failure is "digit expected at 5". On the other hand, if there is no path for backtracking, the reported failure is the expected one: | p | p := (#digit asParser, #digit asParser) flatten ==> [ :value | value first = value second ifTrue: [ value ] ifFalse: [ PPFailure message: 'not equal' at: 0 ]]. p parse: '23' Konrad.

Jan. 29, 2019

Re: [Pharo-users] PetitParser question

by Tudor Girba

Hi, > On Jan 29, 2019, at 6:31 PM, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Hi Doru, > > Thanks for pointing out the use case in XML, which gave me an > opportunity to play around with this with almost no > effort. Unfortunately there seems to be a bug in how PPXmlParser > constructs the PPFailure message > (freshly reported: > https://github.com/moosetechnology/PetitParser/issues/38) Yes, I saw it. I mostly pointed you to the example. We originally built PPXmlParser as an example, and not so much as a production parser. But, does it solve your problem? > More generally, there seems to be a bug in how PetitParser handles > PPFailure return values. The actually reported error is always different > from what is passed to PPFailure. I love software ;-) What do you mean? Cheers, Doru > Konrad. -- www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Jan. 29, 2019

Re: [Pharo-users] PetitParser question

by Konrad Hinsen

Hi Doru, Thanks for pointing out the use case in XML, which gave me an opportunity to play around with this with almost no effort. Unfortunately there seems to be a bug in how PPXmlParser constructs the PPFailure message (freshly reported: https://github.com/moosetechnology/PetitParser/issues/38) More generally, there seems to be a bug in how PetitParser handles PPFailure return values. The actually reported error is always different from what is passed to PPFailure. I love software ;-) Konrad.

Jan. 29, 2019

Re: [Pharo-users] Class name with diacritic character and Pharo

by Sven Van Caekenberghe

https://github.com/pharo-project/pharo/issues/2395 > On 27 Jan 2019, at 17:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Dominique, > >> On 27 Jan 2019, at 11:40, Dominique Dartois <dom(a)dartois.org> wrote: >> >> Hello all. >> If a use french diacritic character in a class name, the code runs but I canât fileout the package nor save it with Monticello. >> For example, the C cedilla in the class name drive me to an âZnInvalidUTF8:Illegal byte for utf-8 encoding' when filing out. >> >> Is it a bug or a feature? >> Thank you >> >> <image.png>--- >> Dominique Dartois > > Thanks for reporting this. This is most definitely a bug, I can confirm its occurrence. > > I'm CC pharo-dev as this is quite important. This will be a long mail. > > > This is one manifestation of a problem that has been present for quite a while. > > I'll start by describing what I did, what went well and where/how this fails, some generic points, and two conceptual solutions (that need further verification). > > Like you, I created a new subclass: > > Object subclass: #ClasseFranÃ§aise > instanceVariableNames: '' > classVariableNames: '' > package: '_UnpackagedPackage' > > With comment: > > I am ClasseFranÃ§aise. > > Try: > > ClasseFranÃ§aise new Ã©lÃ¨ve. > ClasseFranÃ§aise new euro. > > And two methods (in the 'test' protocol): > > Ã©lÃ¨ve > ^ 'Ã©lÃ¨ve' > > euro > ^ 'â¬' > > I added the euro sign (because that is encoded in UTF-8 with 3 bytes, not 2 like Ã§). > Like you said, the system can cope with such class and method names and seems to function fine. > > Looking at the .changes file, the correct source code was appended: > > ----SNAPSHOT----2019-01-26T23:36:18.548555+01:00 work.image priorSource: 339848! > > Object subclass: #ClasseFranÃ§aise > instanceVariableNames: '' > classVariableNames: '' > package: '_UnpackagedPackage'! > !ClasseFranÃ§aise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:25' prior: 0! > I am ClasseFranÃ§aise.! > !ClasseFranÃ§aise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 12:26'! > Ã©lÃ¨ve > ^ 'Ã©lÃ¨ve'! ! > !ClasseFranÃ§aise commentStamp: 'SvenVanCaekenberghe 1/27/2019 12:27' prior: 33898360! > I am ClasseFranÃ§aise. > > Try: > > ClasseFranÃ§aise new Ã©lÃ¨ve. > ClasseFranÃ§aise new euro. > ! > !ClasseFranÃ§aise methodsFor: 'test' stamp: 'SvenVanCaekenberghe 1/27/2019 12:27'! > euro > ^ 'â¬'! ! > > > Doing a file out (or otherwise saving the source code) fails. The reason is an incorrect manipulation of this source file while looking for what is called the method preamble, in SourcFileArray>>#getPreambleFrom:at: position > > An programmatic way to invoke the same error is by doing > > (ClasseFranÃ§aise>>#Ã©lÃ¨ve) timeStamp. > (ClasseFranÃ§aise>>#Ã©lÃ¨ve) author. > > Both fail with the same error. > > > The source code of methods is (currently) stored in a .sources or .changes file. CompiledMethods know their source pointer, an offset in one of these files. Right before the place where the source starts is a preamble that contains some meta information (including the author and timestamp). To access that preamble, the source code pointer is moved backwards to the beginning of the preamble (which begins and ends with a !). > > > The current approach fails in the presence of non-ASCII characters. More specifically because of a mixup between the concept of byte position and character position when using UTF-8, a variable length encoding (both the .changes and the .sources are UTF-8 encoded). > > For example, consider > > 'Ã partir de 10 â¬' size. "16" > 'Ã partir de 10 â¬' utf8Encoded size. "19" > > So although the string contains 16 characters, it is encoded as 19 bytes, Ã using 2 bytes and â¬ using 3 bytes. In general, moving backwards or forwards in UTF-8 encoded bytes cannot be done without understanding UTF-8 itself. > > ZnUTF8Encoder can do both (moving forward is #nextFromStream: while moving backwards is #backOnStream:). However, ZnUTF8Encoder is also strict: it will signal an error when forced to operate in between encoded characters, which is what happens here. > > It is thus not possible to move to arbitrary bytes positions and assume/hope to always arrive on the correct character boundaries and it is also wrong to take the difference between two byte positions as the count of characters present (since their encoding is of variable length). > > SourcFileArray>>#getPreambleFrom:at: is doing both of these wrong (but gets away with it in 99.99% of all cases since very few people name their classes like that). > > There are two solutions: operate mostly on the byte level or operate correctly on the character level. Here are two conceptual solutions (you must execute either solution 1 or 2, not both), with two different inputs. > > > src := '!ClasseFranÃ§aise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 1/27/2019 12:27''! > euro > ^ ''â¬''! !'. > > "startPosition := 83" > > str := ZnCharacterReadStream on: (src utf8Encoded readStream). > str position: 83. "at start of euro, the methods source string" > str upToEnd. > > str position: (83 - 3). "before ! before euro" > > "find the previous ! before position" > position := str position. > binary := str wrappedStream. > encoder := str encoder. > > "solution 1" > [ position >= 0 and: [ binary position: position. binary next ~= 33 ] ] whileTrue: [ position := position - 1 ]. > position. > encoder decodeBytes: (binary next: 80 - position). > > "solution 2" > count := 0. > [ str position >= 0 and: [ str next ~= $! ] ] whileTrue: [ > encoder backOnStream: binary; backOnStream: binary. count := count + 1 ]. > str position. > str next: count. > > > Same code, different input (and starting position): > > > src := '!ABC!ClasseFranÃ§aise methodsFor: ''test'' stamp: ''SvenVanCaekenberghe 1/27/2019 12:27''! > euro > ^ ''â¬''! !'. > > "startPosition := 87" > > str := ZnCharacterReadStream on: (src utf8Encoded readStream). > str position: 87. "at start of euro, the methods source string" > str upToEnd. > > str position: (87 - 3). "before ! before euro" > > "find the previous ! before position" > position := str position. > binary := str wrappedStream. > encoder := str encoder. > > "solution 1" > [ position >= 0 and: [ binary position: position. binary next ~= 33 ] ] whileTrue: [ position := position - 1 ]. > position. > encoder decodeBytes: (binary next: 80 - position). > > "solution 2" > count := 0. > [ str position >= 0 and: [ str next ~= $! ] ] whileTrue: [ > encoder backOnStream: binary; backOnStream: binary. count := count + 1 ]. > str position. > str next: count. > > > Solution 1 (at the byte level) works because $! (ASCII code 33) is also encoded as such in UTF-8 and this byte pattern cannot be part of a 2, 3 or 4 byte UTF-8 encoded character. The final byte segment must then be given to the proper encoder to turn it into characters. > > Solution 2 (at the character level) works because it essentially counts characters while moving backwards correctly (it moves back 2 steps each time because #next moves 1 step forward, while #peek would not help). > > Note that in Solution 1 the moving position is held in an external variable, while in Solution 2 it is held inside the stream. > > > Implementing either solution requires more internal access of the streams (#wrappedStream), so SourcFileArray>>#getPreambleFrom:at: should at least be moved to SourceFile, IMHO. > > Obviously this is a sensitive/critical area to touch. > > We will also need a regression unit test. > > On a higher design level, I think that CompiledMethod>>#timeStamp and CompiledMethod>>#author should be cached at the instance level (a unix timestamp and a symbol would cost very little). > > Sven > > > > > >

Jan. 29, 2019