- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] TaskIT Revealed

by Alexandre Bergel

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 29, 2014

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

by GOUBIER Thierry

My guess would then be: when updating the list of packages, the selected morph isn't removed from selectedMorphs, however the tree view is rebuilt [*] by recreating all models and all morphs inside, with reselection of the current package (which sees a newly created morph selected and added to selectedMorphs). [*] Yes, on average, what is done when a tree is updated is : destroy all morphs inside the tree view, and all models as well, and recreates everything. Now, why on AltBrowser tree view I haven't seen the issue: single selection versus multiple selection? Or because I have some code to do partial tree updates? We're lacking a nice tree object model for GUI use. I'll try to write a test case tracking this. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Johan Brichau [johan(a)inceptive.be] EnvoyÃ© : dimanche 29 juin 2014 22:31 Ã : Pharo Development List Objet : Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo 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

June 29, 2014

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

by Johan Brichau

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

June 29, 2014

Re: [Pharo-dev] TaskIT Revealed

by Santiago Bragagnolo

jajajajaja, thank you very much Doru. It seems I am not very user friendly.

June 29, 2014

Re: [Pharo-dev] Pharo and Amber relationship

by Stephan Eggermont

Sean wrote: >Have you checked it out lately? The current procedure seems very streamlined... > ># Install the CLI tools (only needs to be done once per computer) >sudo npm install -g amber-cli Are you serious? That is like saying you can install Pharo by double-clicking a Pharo image. That misses a few steps. And there are several ways to install prerequisites, some of which don't work at all, others cannot be upgraded. Stephan

June 29, 2014

Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422

by GOUBIER Thierry

Yes, the original emal has stepharo as the sender :) Ok, I try to scan but I don't seem to reproduce. And my netbook is really slow, so scanning the memory for all instances takes forever :( Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Johan Brichau [johan(a)inceptive.be] EnvoyÃ© : dimanche 29 juin 2014 16:21 Ã : Pharo Development List Objet : Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 On 29 Jun 2014, at 15:24, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? It was me ;-) (fogbugz sends email as Stef?) Exactly, this is where I am looking at. I have tried to find who is referencing all those instances but I have not discovered it yet. > I'd look into the package tree structure and updates. I started to look at the single PackageTreeNautilusUI instance I have open which should be the root that is keeping all these instance in the image. But I am wandering through unknown code here... Johan

June 29, 2014

[pharo-project/pharo-core] 6f640f: 40053

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f640fdec986a3bb97799de1ed6a0e1e3568e6e5 https://github.com/pharo-project/pharo-core/commit/6f640fdec986a3bb97799de1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-29 (Sun, 29 Jun 2014) Changed paths: M MonticelloGUI.package/MCCodeTool.class/instance/menus/browseVersions.st R Morphic-Base.package/CurveMorph.class/README.md R Morphic-Base.package/CurveMorph.class/class/instance creation/arrowPrototype.st R Morphic-Base.package/CurveMorph.class/definition.st R Morphic-Base.package/CurveMorph.class/instance/initialization/initialize.st R Morphic-Base.package/CurveMorph.class/instance/testing/isCurvier.st R Morphic-Base.package/PolygonMorph.class/class/settings/curvierByDefault.st R Morphic-Base.package/PolygonMorph.class/class/settings/curvierByDefault_.st M Morphic-Base.package/PolygonMorph.class/definition.st M Morphic-Base.package/PolygonMorph.class/instance/initialization/initialize.st M Morphic-Base.package/PolygonMorph.class/instance/smoothing/coefficientsForMoreThanThreePoints.st M Morphic-Base.package/PolygonMorph.class/instance/smoothing/slopes_.st R Morphic-Base.package/PolygonMorph.class/instance/testing/isCurvier.st M Polymorph-Tools-Diff.package/PSMCPatchMorph.class/instance/actions/browseVersions.st M Refactoring-Critics.package/RBSmalllintChecker.class/instance/private/checkClass_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script53.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40053.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsFindImplementors.class/instance/as yet unclassified/execute.st R SmartSuggestions.package/extension/AbstractTool/instance/browseImplementorsOf_name_autoSelect_.st M Spec-Debugger.package/SpecDebuggerStack.class/instance/actions browsing/browseVersions.st M Spec-Tools.package/ChangeSorterApplication.class/instance/menu - message/browseVersions.st M Spec-Tools.package/NewVersionBrowser.class/class/protocol/browseVersionsForClass_selector_.st M Spec-Tools.package/NewVersionBrowser.class/instance/menu/browseImplementors.st M Tool-Finder.package/DialogItemsChooserUI.class/definition.st M Tool-Finder.package/FinderMethodNode.class/instance/private/browse.st M Tool-Finder.package/FinderMethodNode.class/instance/private/browseImplementors.st M Tool-Finder.package/FinderUI.class/instance/buttons behavior/versionsButtonAction.st M Tool-Finder.package/FinderUI.class/instance/private/implementors.st R Tool-Finder.package/FinderUI.class/instance/private/versions.st M Tool-Finder.package/MethodFinder.class/instance/search/handleExceptionalSelectors.st M Tools.package/FileContentsBrowser.class/instance/other/browseVersions.st M Tools.package/extension/SystemNavigation/instance/browseAllImplementorsOf_.st R Tools.package/extension/SystemNavigation/instance/browseImplementorsOf_name_autoSelect_.st Log Message: ----------- 40053 13275 RBSmalllintChecker checks classes not defined in environment https://pharo.fogbugz.com/f/cases/13275 12551 Unused class CurveMorph https://pharo.fogbugz.com/f/cases/12551 13432 Small tool cleanup: VersionBrowser api, Implementors of https://pharo.fogbugz.com/f/cases/13432 http://files.pharo.org/image/40/40053.zip

June 29, 2014