June 2014 - Pharo-dev - lists.pharo.org

Versioner

by Diego Lont

I am afraid this mail is going to be too long, but I feel it needs to be written. I will start with the conclusion, so you can skip the mail if you feel it does not interest you. Please keep the discussion on the Moose list, as there the discussion was started. I am very happy that versioner is being built. We need more and better software configuration tools, and versioner will make our life easier. That being said, I am getting a bit nervous about how versioner is released. It should aim to improve the way people can work, and not to create a single workflow for all people working on pharo projects. I hope my fears are unfounded. Software configuration management (SCM) is in my opinion an undervalued topic within the software world. One cannot find very many good books on them, and I am afraid this lack of knowledge shows in the way people go around with their SCM. So I would like to write down some observations of the SCM processes in Pharo that I believe we should keep in mind. The main target of SCM is to keep the impact of changes as minimal as possible. Good SCM allows all people working on a certain project, to make their changes, without causing trouble for other project members and people using this project. Open source projects are (in SCM terms) rather complex, as they involve a lot of people, including some people we do not know. 1. One of the best things of Metacello is that it does not require you to follow a certain workflow. It is very flexible and supports a large range of possible workflows. Within the Pharo community we have at least 3 different workflows: A. For Pharo core, we have a pharo inbox, where suggested fixes for reported bugs are put. These fixes are reviewed and, if accepted, integrated into Pharo. This ensures that the changes in Pharo hold (most of the time) to quite some quality standards. B. For the âcross-platformâ projects (Grease, Seaside, Magritte, etc.) all suggested fixes are put in the main repository on smalltalkhub. The fixes are, after review and tests, released by putting them in a âreleasedâ version of the configuration. Since not all fixes should be in all versions, and sometimes only concern a certain platform, the process for Pharo core would not work: releasing fixes are more complex because of the cross-platform issues. C. For the âmooseâ projects all suggested fixes are put in the main repository and are accepted by default. Since most projects evolve very fast, quality assurance is done afterwards, by submitting bug fixes. I can say a lot about why I believe these workflows are appropriate for their different projects, but the point I am trying to make here, is that these workflows have come to existence because of the different demands on them. And to stress my point about the flexibility (thank you Dale): When there was a problem with the workflow in the cross platform projects, I could find a solution (using releases) that Metacello supported. 2. Unfortunately Metacello does not have a good UI. And for large configurations like Seaside, it is a lot of work to keep them maintained. I dream of a tool that acts as a UI for Metacello: this tool is flexible as Metacello, while making the simple things real easy (hitting a button and done). Does versioner aim to do this? 3. I always get very nervous when someone says: They do it like this, and that works very well for them. So we should do that too. I do not believe that is always a good idea. The conclusion should be a question: Can we use that too? And now I cannot find the mail about the java SCM practice, but I do not think we can apply it to all our processes ... 4. Modularity is very important. Also for performing good SCM. And yes, we lack sufficient modularity in Moose. It should be better. I.e. because of the lack of modularity, it is sometimes hard to distinguish between where the change needs to be put in. So there is no clear group to point out who should accept the changes. So this is also an SCM problem. Cleaning up the configuration will help here very much. Thank you Steff for the good work here. And maybe you also have a point that the people working on Moose should have more focus on keeping things modular, because it makes the system better maintainable in a lot of ways. 5. Forking things will only make SCM worse, as it adds a complexity. So I very much hope we can come to an agreement how the process works, without resorting to drastic measures. Regards, Diego

June 30, 2014

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo

by Nicolai Hess

2014-06-29 22:31 GMT+02:00 Johan Brichau <johan(a)inceptive.be>: > > On 27 Jun 2014, at 14:00, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > It seems to depend on the Nautilus window state. If you've just opened > it, then nothing seems to be amiss. If you start to select things in it, > you start to see time spent in updateClassView, but why? > > I just found that the instances are being kept by the > MorphTreeListManager#selectedMorphs instvar. So, that observation is > correct: you need to have a package selected. > > What seems to happen is that on every package load, the Nautilus package > tree is updated (which means a PackageTreePackageNodeModel is created for > each package in the image via #asNautilusNodeWithModel:). > This update does not clear the selectedMorphs list and just this single > reference seem to keep the entire package tree model and its Morphs in > memory. > > There were 496 morphs in the selectedMorphs list and when I cleaned that, > all trailing Morphs and PackageNodeModelNodes (and all the other garbage) > could be gc'ed. > > On to investigating the growth of the selectedMorphs variable... > > Johan > Yes, we had quite some bugs with this package tree update in the past. What I don't understand is, why is the whole tree removed and rebuild, maybe this is a common strategy in Morphic, update a list ore tree will always rebuild the whole morph structure? But it happens even if the structure is the same and just this little package/dirty package icon is updated. Another issue is this "selected package/package selection". The tree (and for example the category list and/or method list" as well), stores the selection on multiple ways, in the model (PackageTreeNautilus), the UI (PackageTreeNautilusUi) and the treelist morph. Once as a SelectedTreeNode, a Package from Nautilus Model and once as a PackgeTreeSelection/PackageTreeTagSelection. I find it pretty confusing. BTW, I still can not reproduce this memory leak behavior. I tried this: [ Gofer new smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; package: 'ConfigurationOfRoassal2'; load. (Smalltalk at: #ConfigurationOfRoassal2) load ] timeToRun. with and without an open SystemBrowser. But the load time and memory consumption is the same. Nicolai

June 30, 2014

Re: [Pharo-dev] ctrl+a is seen as ctrl+home windows

by Nicolai Hess

2014-06-29 16:34 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi > > hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to make > ctrl+home and ctrl+end working. Like you I was very surprised by such > keyboard events crappy state. > > So, having ctrl+end and ctrl+d working at the same time is not possible? > > > 2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess(a)web.de>: > > 2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >> There is a problem in the whole keyboard events: they treat keys as >>> characters and vice versa. And that's not always true: >>> - the backspace key is a key, but currently the image interprets it as >>> a character because we only use keypress events in general. >>> - the shift key is a key, and since current image does not use keyup >>> nor keydown, we cannot know if JUST a shift is pressed normally. >>> >>> >>> On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> >>>> I don't know anything about event handling, but I once had a look at >>>> Character constants, and found this: >>>> >>>> Character class>>#home >>>> ^ self value: 1 >>>> >>>> How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH >>>> (Start of header), sometimes typed as CTRL-A. And there are other strange >>>> constants like that there. >>>> >>>> On 25 Jun 2014, at 08:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> > Hi, >>>> > >>>> > I am on Windows, using Pharo 3.0, and I am trying to get the >>>> keybindings to work in Rubric using Windows convention (so, Ctrl instead of >>>> Cmd as a modifier), >>>> > >>>> > It worked reasonably well, but the problem is that somehow Ctrl+a is >>>> mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect >>>> the same behavior in the regular PluggableTextMorph. >>>> > >>>> > Does anyone have an idea of where the problem comes from? >>>> > >>>> > Doru >>>> > >>>> > >>>> > >>>> > -- >>>> > www.tudorgirba.com >>>> > >>>> > "Every thing has its own flow" >>>> >>>> >>>> >>> >> >> ctrl+a has the same strange behavior as ctrl+d >> ctrl+a -> ctrl+home >> ctrl+d -> ctrl+end >> >> look at KeyboardEvent>>#hasSpecialCTRLKeyValue >> I am not exactly sure why it is handled that way. >> Replace the method with >> >> hasSpecialCTRLKeyValue >> ^ self controlKeyPressed and: [ keyValue <= 26 ] >> >> now, ctr+a and ctr+d working as expected. >> But I don't know about the side-effects. >> >> >> nicolai >> >> >

June 30, 2014

Re: [Pharo-dev] TaskIT Revealed

by Santiago Bragagnolo

yeah, the name of the extension for executing in a second image is forkit. instead of [ 2+2 ] shootIt, do [ 2+2 ]forkIt, The difference in between both is the runner. Meanwhile shootIt is like this: shootIt ^ TKTOneShotRunner new run: self forkIt is forkIt ^ FKTOneShotAtThirdInstanceRunner new run: self We are changing this for the next version, but it will be similar, but more dynamic (we will take more advantage of our reification of process) 2014-06-30 0:05 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Impressive! > > Can I specify the semantic behind #shootIt ? I mean, now you are spawning > processes right? Can I instead open a new image to have the work done? > > Alexandre > > On Jun 22, 2014, at 6:39 PM, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > > > > > Hi all, im glad to announce TaskIT. You may already knew about, after > all it's not confidential ;) and it has documentation on-going since some > months ago. > > > > Task IT is package that provides a cool way to deal with processes. Even > when this version is stable, it still in design and we want to make it > consistent and powerfull. > > > > It counts with a chapter in pharo enterprise book and some cool tests. > > > > We have moved the main distribution repo to CAR > > > > http://smalltalkhub.com/#!/~CAR/TaskIT/ > > > > > > The main easy things to do with this revision are: > > > > " closures " > > val := [ 2+2 ] shootIt. > > val isKindOf: TKTFuture. > > val onSuccess: [: rslt | rslt == 4 ] "async" > > val value == 4. " sync " > > > > rslt := [ 2+2 ] shootIt asResult. > > rslt == 4 "sync on demand" > > > > " objects " > > > > val := 2 paralellize + 2. > > val == 4 "sync on demand" > > > > > > " staying in tune " > > > > val := [ "some task" ] shootIt asStickyReference. > > > > val := nil. > > " sticky means that if this future is taken by the GC, it will kill the > process" > > > > > > > > " looping " > > > > > > val := server paralellize looping serveOnce: anyParameter > asStickyReference. > > > > "this will execute in a new process, in a loop, server serveOnce: > anyParameter." > > > > You can stop it by doing > > val:= nil. > > > > "or using a disgusting magic variable, for that check the samples :). > But do not rely on that kind of things, because it will not be supported " > > > > > > > > For more advanced and cool usages, check the Doc. > > > > > > FAQ: > > > > 1- Yes, the "sync" on demand is implemented with a proxy and a become. > > 2- Yes, we are changing the API of the processes that persist in time. > > > > CREDITS > > All CAR team in general was great inspiration, particularly, Guille > Polito full operational commiter and of course is always a good idea to > discuss with him, Nick Papoylias, is also great to discuss with him. Luc, > Noury, Jannik: several ideas are discussed with them as well, and they > always gave me support. > > > > and from RMOD Esteban Lorenzano, also discussing and proposing. > > > > Thanks all :). > > > > > > OTHERS: > > If you want to go to the darkside (dark because is not documented yet, > but in the case of PoolIT, that it has some doc ) you can also add to your > combo: > > ActIT: a simple Actor extention for taskit. > > ForkIT: an extention that runs blocks in background image (it adds a > nice button to the test runner, letting you run all your tests in a > background image and installing the results after the execution) > > PoolIT: it adds a pool of workers, it consumes tasks and ensure you a > limited amount of threads. > > PlanIT: a basic and not yet full developed algebra for composing > processes. > > > > > > > > I encourage you to use it, it is being used in PhaROS since a lot of > time. And please any bug and enhancements, you can contact us. Since we are > working on the next version is a good time to define what features are > really needed. > > > > > > Salut. > > > > > > Santiago. . > > > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

June 30, 2014

Re: [Pharo-dev] Sharing/Versioning Data

by Alexandre Bergel

Hi Sean! I guess you can use the very same technique to store pictures in the image. Mime64 is your friend :-) I can look for code snippets if you needâ¦ Let me know Cheers, Alexandre On Jun 28, 2014, at 11:22 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > How do we do this now with MC? Are there options other than "encode in string > returned by method" like I've seen done for image data? > > My use case is that I have a very static domain, and so doesn't require user > changes. I think the easiest way to distribute it would be to edit the data > on a dev image, and then somehow save the data in a way that can be > committed with MC so that loading via MetaC config loads the latest version > of the data. What would be the best way to do that? > > Thanks. > > p.s. on a related note, I'm also interested in distributing static files > with the code e.g. maybe a PDF readme > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 30, 2014

Re: [Pharo-dev] Sharing/Versioning Data

by Sean P. DeNigris

HernÃ¡n Morales Durand wrote > I've used Dropbox to > download resource files to a directory. Thanks I'll check it out ----- Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528p4765646.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 30, 2014

Re: [Pharo-dev] Sharing/Versioning Data

by Sean P. DeNigris

Guillermo Polito wrote > With Martin we started on friday to sketch a kind of resource manager Sounds exciting. Can't wait to play with it! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Sharing-Versioning-Data-tp4765528p4765645.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 30, 2014

Re: [Pharo-dev] Pharo and Amber relationship

by Sean P. DeNigris

Stephan Eggermont wrote > That is like saying you can install Pharo by double-clicking a Pharo > image. A bit overdramatic ;-) Stephan Eggermont wrote > That misses a few steps Yes, I was not really trying to prove anything. I just wanted to give a heads up that the process had gotten significantly easier. I painlessly installed on Mac via this method, in sharp contrast to earlier instructions. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-and-Amber-relationship-tp4764889p4765644.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 30, 2014

reviews?

by Alexandre Bergel

Hi! Maybe one of Deep into Pharoâs reader can write a review on: http://www.amazon.com/Deep-into-Pharo-Alexandre-Bergel/dp/3952334162 This will help everybody by promoting our favorite language... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 30, 2014

Re: [Pharo-dev] Some assembly on a Sunday night as well!

by Henrik Sperre Johansen

Comparing with C would involve setting up a working C compilation environment, I'm too lazy for that... :P Spent some time finding bit op combinations for mask creation, amongst others, a mask which, when AND'ed with the input byte, can be OR'ed into a compound header byte. AND that with 2r00111110 at the end, and voila, you know if the string is valid Latin1 :) The mask in question: createMultiByteHeaderMaskOf: utfByte in: maskReg using: asm "Create a mask in maskReg where all bits are 1 for multibyte headers, and zero for others" "Invalid patterns: 10XXXXXX - Non-header byte of multibyte character 0XXXXXXX - Single byte character Valid: 110XXXXX - Two-byte character header 1110XXXX - Three-byte character header 11110XXX - Four-byte character header" asm "Invalid Valid Invalid" mov: maskReg with: utfByte; "10XXXXXX 11XXXXXX 0XXXXXXX" shr: maskReg with: 1; "010XXXXX 01100000 00XXXXXX" and: maskReg with: utfByte; "000XXXXX 01XXXXXX 00XXXXXX" shl: maskReg with: 1; "00000000 10000000 0XXXXXX0" sar: maskReg with: 7. "00000000 11111111 00000000" In the end, I now have a fallback path for codepoint counting/String class determination which should be easy (barring alignment, and SEGV guards) to vectorize with MMX/SSE/AVX paths :D (For that I guess I'd also need to find the image where I put that nice CPUID class I made long ago, and figure out a jumpless method of doing the actual decoding as well... Oh, and I still have to implement UTF8 encoding, plus at least UTF16 and a callback to use Image-decoders if something more esoteric is desired, I guess those take priority) There's already quite a few methods involved, I guess in the end, these will be put in NBXXXConverter(s), which, in addition to the emit: methods that can be used from NB methods (like ExternalString marshalling), will respond to an encodeString:/decodeBytes: interface. Cheers, Henry p.s. The naughtiest one yet, which, (if it's bug-free), is used to find what value to increase the source reg by when counting characters: createAdvanceOf: utfByte in: advanceReg using: gen "Create an advance in advanceReg, telling us how many characters we can skip" "Input: 10XXXXXX - Non-header byte of multibyte character - advance 1 (should never end up reading this in a valid utf string) 0XXXXXXX - Single byte character - advance 1 110XXXXX - Two-byte character header - advance 2 1110XXXX - Three-byte character header - advance 3 11110XXX - Four-byte character header - advance 4 " "Code with no jumps. This method would not be of any use in vectorized code, since that scans a set stride length at a time, and can't exploit highbyte/lowbyte movs anyways. Why then? Because bsr is cooler than a bunch of jmps:, that's all. This is the last op in loop, so we don't care if utfByte happens to gets clobbered by the bsr" "make sure advanceReg is the high byte of a register, so bsr will count correctly" advanceReg isHighByte ifFalse:[self error: 'Current assembly only accepts a highbyte to hold advance!']. "If only we'd stored this somewhere during character counting..." self createMultiByteHeaderMaskOf: utfByte in: advanceReg using: gen asm; gen asm and: advanceReg with: utfByte; "110XXXXX 1110XXXX 11110XXX 00000000" shl: advanceReg with: 1; "10XXXXX0 110XXXX0 1110XXX0 00000000" xor: advanceReg with: 16rFF; "01XXXXX1 001XXXX1 0001XXX1 11111111" bsr: advanceReg as16 with: advanceReg as16; "00000111 00000110 00000101 00001000" shl: advanceReg as16 with: 8; "Put the bit scan results back in actual advanceReg" sub: advanceReg with: 9; "11111110 11111101 11111100 11111111" xor: advanceReg with:16rFF; "00000001 00000010 00000011 00000000" inc: advanceReg. "00000010 00000011 00000100 00000001" On Fri, Jun 27, 2014 at 7:58 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Don't compare with smalltalk, compare with C! :) > > > On 27 June 2014 19:23, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > >> Impressive numbers and a nice examplz to grasp lots of NB/Asm details. >> Le 27 juin 2014 18:55, "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> >> a Ã©crit : >> >> > >> > Soo, I started dabbling with the thing I talked about before last >> summer, letting String parameters in NB calls have an encoding: option. >> > (Thereâs already a slice in inbox to allow optional values other than >> true/false) >> > >> > Thought Iâd start with decoding; hereâs a small preview of the part >> which does the actual decoding, after needed string class has has been >> determined and instantiated. >> > While itâs a fallback path for when the platform doesnât support SSE or >> other batch operations, itâs still using some neat tricks (imho) I thought >> others might enjoy on a Friday afternoon :) >> > >> > emitStandardDecodeUTF8CharactersFrom: aSource to: aDestination >> withCharSize: aCharSize scratchReg: scratchReg using: aGenerator >> > "Emit decoding using only standard x86 ops" >> > "We have already found what String class is needed for decoding >> aSource, and created an instance of the proper size" >> > "This implementation focuses on minimizing jumps and register >> usage, at the cost of loading from source one byte at a time. >> > "Input: >> > aSource - memory pointer to C-string with UTF8 bytes >> > aDestination - memoryPointer to first var field of >> String instance >> > scratchReg - a register which will be modified while >> decoding >> > >> > aCharSize - The size in bytes of each character in our >> destination string, known at emission time >> > >> > Clobbers: scratchReg >> > aSource and aDestination will end up pointing to end of strings" >> > >> > | asm scratch32 sLowByte sHighByte loop done oneByte twoBytes >> threeBytes | >> > >> > asm := aGenerator asm. >> > loop := asm uniqueLabelName: 'utf8DecodeLoop'. >> > done := asm uniqueLabelName: 'utf8DecodingDone'. >> > scratch32 := scratchReg as32. >> > sLowByte := scratch32 as8. >> > sHighByte := sLowByte asHighByte. >> > >> > asm label: loop. >> > "Unroll the inner loop as many times as we want, or, well, at >> least as many times as the backwards jump will allow us to" >> > 8 timesRepeat:[ >> > oneByte := asm uniqueLabelName: 'utf8OneByteDecode'. >> > twoBytes := asm uniqueLabelName: 'utf8TwoByteDecode'. >> > threeBytes := asm uniqueLabelName: 'utf8ThreeByteDecode'. >> > asm xor: scratch32 with:scratch32. >> > asm or: sLowByte with: aSource ptr8. >> > asm cmp: sLowByte with: 0. >> > asm je: done. >> > asm add: aSource with: 1. >> > asm test: sLowByte with: 2r10000000 asUImm8. >> > asm jz: oneByte. >> > "We have a header, place its data bits as initial high byte >> value" >> > asm shl: scratch32 with: 8. >> > asm xor: sHighByte with: 2r11000000 asUImm8. "Strip 2 byte >> header" >> > asm test: sHighByte with: 2r00100000. >> > asm jz: twoBytes. >> > aCharSize > 1 ifTrue: [ >> > asm xor: sHighByte with: 2r00100000. "Strip 3 byte header" >> > asm test: sHighByte with: 2r000100000. >> > asm jz: threeBytes. >> > "This is a 4-byte character" >> > asm xor: sHighByte with:2r00010000."Strip 4 byte header" >> > "Read one trailing byte, remove the header, and shift the data >> out of low byte" >> > asm or: sLowByte with: aSource ptr8. >> > asm shl: sLowByte with:2. >> > asm shl: scratch32 with: 6. >> > asm add: aSource with: 1. >> > asm label: threeBytes. >> > "Read one trailing byte, remove the header, and shift the data >> out of low byte" >> > asm or: sLowByte with: aSource ptr8. >> > asm shl: sLowByte with:2. >> > asm shl: scratch32 with: 6. >> > asm add: aSource with: 1. >> > ]. >> > asm label: twoBytes. >> > "Read last trailing byte, remove header, and shift the data >> bits into proper place" >> > asm or: sLowByte with: aSource ptr8. >> > asm shl: sLowByte with:2. >> > asm shr: scratch32 with: 2. >> > asm add: aSource with: 1. >> > asm label: oneByte. >> > asm mov: (aDestination ptr size: aCharSize) with: (scratch32 >> as: aCharSize). >> > asm add: aDestination with: aCharSize.]. >> > asm jmp: loop. >> > asm label: done. >> > >> > And the relevant test code for that: >> > >> > testStandardDecodeWide >> > | bytes string | >> > "bytes := (ZnUTF8Encoder new encodeString: 'Cash, like â¬, is >> king'), #[0]." >> > bytes := #[67 97 115 104 44 32 108 105 107 101 32 226 130 172 >> 44 32 105 115 32 107 105 110 103 0]. >> > string := WideString new: bytes size - 1. >> > self testStandardDecode: bytes toWideString: string. >> > ^ string >> > >> > testStandardDecode: utf8Bytes toWideString:aString >> > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> > ^ self nbCallout >> > function: #(void #(char* utf8Bytes, char* aString )) >> > emit: [ :gen :proxy :asm | >> > asm pop: asm EBX; >> > pop: asm ECX. >> > self emitStandardDecodeUTF8CharactersFrom: asm >> EBX to: asm ECX withCharSize: 4 scratchReg: asm EAX using: gen. >> > asm mov: EAX with: gen proxy nilObject ] >> > >> > Which, though itâs currently cheating by pre-knowledn string >> class/size, isnât alot of overhead: >> > ext := NBExternalString new. >> > [ext testStandardDecodeWide] bench '5,030,000 per second.' '5,080,000 >> per second.' '5,190,000 per second.â >> > Compared to an equivalent to testStandardDecodeWide, with emitStandardâ¦ >> removed from the primitive: >> > [ext testEmptyDecode] bench '5,850,000 per second.' '5,800,000 per >> second.' '5,640,000 per second.' >> > >> > â¦ or compared to doing the decoding in image after the call: >> > int := ZnUTF8Encoder new. >> > [int decodeBytes:#[67 97 115 104 44 32 108 105 107 101 32 226 130 172 >> 44 32 105 115 32 107 105 110 103 0]] bench '130,000 per second.' '131,000 >> per second.' '132,000 per second.â >> > >> > Cheers, >> > Henry >> > >> >> > > > -- > Best regards, > Igor Stasenko. >

June 30, 2014