- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Performance Tip: Using buffered streams

by Sven Van Caekenberghe

On 03 Dec 2012, at 12:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > If that is so (and it seems to be the case), then that is an important bug, wouldn't you agree ? http://code.google.com/p/pharo/issues/detail?id=7092 -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 3, 2012

[Pharo-project] [update 2.0] #20426

by Marcus Denker

20426 ----- Issue 7091: TestRunner needs to register itself in ToolSet http://code.google.com/p/pharo/issues/detail?id=7091 Issue 7019: Move MIMEType from Network to FileSystem http://code.google.com/p/pharo/issues/detail?id=7019 Diff information: http://ss3.gemstone.com/ss/Pharo20/SUnit-UI-MarcusDenker.51.diff http://ss3.gemstone.com/ss/Pharo20/Network-MIME-MarcusDenker.52.diff http://ss3.gemstone.com/ss/Pharo20/FileSystem-Core-MarcusDenker.63.diff

Dec. 3, 2012

Re: [Pharo-project] [squeak-dev] New Cog VMs available

by Eliot Miranda

Hi Blake, On Mon, Dec 3, 2012 at 7:10 AM, Blake McBride <blake(a)mcbride.name> wrote: > Greetings, > > I tried to integrate Squeak to a C based application more than six years > ago. The project failed because we were not able to have our application > call Squeak, then have Squeak call the application, and then the > application call Squeak again recursively. An analysis of the Squeak VM > revealed a kernel design consisting of a lot of global variables - quite > unnecessarily. The unnecessary use of global variables over a localized > structure for example unnecessarily prevented the use of Squeak as an > extension language (unless you had no recursion). I spent several days > trying to re-structure the Squeak kernel but I kept running into problems > and just ran out of time. > > As a side note, that company I was with ended up making a lot of > investment in Scheme because we were easily able to integrate that language > with our application. Now, not only is Scheme used heavily within that > company but many of their clients use it too to customize their application. > > This brings me to my question, is COG reentrant? > Yes it is. It supports call-outs and call-ins. But currently there is no support for Cog to be packaged as a DLL. You have to start by calling C from Squeak. > If not, as the author of COG, I would think it relatively easy to > restructure it to be so. Such a design capability can make a huge > difference to COG's acceptance to many. It may even be the reason to > switch to COG. > Yes indeed. The issue is of course funding to spend the time to make the necessary changes. > Just sharing some thoughts. Thanks. > > Blake McBride > > On Sun, Dec 2, 2012 at 7:55 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628. >> >> These fix a bug with pc mapping that could cause the Vm to crash on >> simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| >> 1=1]). They also cause the instantiation primitives to pop all their >> arguments rather than assume their argument count is 0 or 1. More change >> info available in the directory. >> -- >> best, >> Eliot >> >> >> >> >> > > > > -- best, Eliot

Dec. 3, 2012

Re: [Pharo-project] Performance Tip: Using buffered streams

by Nicolas Cellier

Yes, the lack of FileStream buffering was (re)-discovered and corrected when I have experimented with my own SqueaXTream experiments http://www.squeaksource.com/XTream/ before porting the original Xtreams to Squeak http://www.squeaksource.com/Xtreams/ Then Levente soon came up with an excellent patch for buffering Squeak FIleStream and this was later ported to Pharo. What I also re-discovered is that not only buffering the raw file counts, but also buffering the decoding. Indded, an uncarefull implementation would read file by chunk but decode byte after byte... While a buffered one would decode large chunks of ASCII (if any) in a single copy primitive. This was reported near the end of this post: http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.general/151341 For Xtreams, I don't remember exactly where I put some experiments, but pre-allocating a WideString instead of a String can also make a noticeable difference in presence of WideCharacter... Nicolas 2012/12/3 Sven Van Caekenberghe <sven(a)stfx.eu>: > On 03 Dec 2012, at 12:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> There are ZnCharacterReadStream and ZnCharacterWriteStream that add decoding/encoding to binary streams. They could indeed be used as an alternative. But that was not my point. > > I reran the examples using a binary file stream to disable the decoding and then using ZnCharacterReadStream to handle the decoding: > > [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | > (NeoJSONReader on: stream) next ] ] timeToRun. 3502 > > [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | > ZnBufferedReadStream on: fstream do: [ :stream | > (NeoJSONReader on: stream) next ] ] ] timeToRun. 1214 > > [ StandardFileStream fileNamed: '/tmp/numbers.json' do: [ :stream | > (NeoJSONReader on: stream) next ] ] timeToRun 2869 > > [ StandardFileStream fileNamed: '/tmp/numbers.json' do: [ :fstream | > ZnBufferedReadStream on: fstream do: [ :stream | > (NeoJSONReader on: stream) next ] ] ] timeToRun 1280 > > > [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | > (NeoJSONReader on: (ZnCharacterReadStream on: stream binary)) next ] ] timeToRun. 1655 > > [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | > (NeoJSONReader on: (ZnCharacterReadStream on: stream binary encoding: 'latin1')) next ] ] timeToRun. 1574 > > [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | > ZnBufferedReadStream on: (ZnCharacterReadStream on: fstream binary) do: [ :stream | > (NeoJSONReader on: stream) next ] ] ] timeToRun. 1753 > > [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | > ZnBufferedReadStream on: (ZnCharacterReadStream on: fstream binary encoding: 'latin1') do: [ :stream | > (NeoJSONReader on: stream) next ] ] ] timeToRun. 1655 > > This shows several things (for this particular test case): > > - ZnCharacterReadStream is at least as good as the builtin decoding streams (here twice as good) > - UTF-8 (ZnUTF8Encoder) and Latin1 (ZnNullEncoder) decoding are close together (because the input is ASCII) > - ZnBufferedReadStream does not help when the stream is pretty good (ZnCharacterReadStream actually uses a 1 character buffer to support peek, which is important to speed up this use case) - this is to be expected: it adds a layer, but its fetch next buffer logic still loops using #next, decoding possibly Unicode characters > - the super fast runs (the 2nd and the 4th) are actually cheating because they skip decoding - thanks for that observation ! > > Sven > > PS: While doing these explorations, I actually updated ZnUTF8Encoder quite a bit, both when handling ASCII, which is the majority of characters in most cases, as well as in the general case; see the latest version. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Dec. 3, 2012

[Pharo-project] [update 2.0] #20425

by Marcus Denker

20425 ----- Issue 7089: Intermediate Fix to avoid OutOfBounds in ProgressMorphs http://code.google.com/p/pharo/issues/detail?id=7089 Issue 7087: remove unused TestRunnerBrowser http://code.google.com/p/pharo/issues/detail?id=7087 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.995.diff http://ss3.gemstone.com/ss/Pharo20/System-Applications-MarcusDenker.44.diff http://ss3.gemstone.com/ss/Pharo20/SUnit-UI-MarcusDenker.49.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1295.diff

Dec. 3, 2012

[Pharo-project] Smalltalks Videos

by Marcus Denker

There are now a lot of Videos online from Smalltalks, both last month and 2011. *A lot* of Pharo related videos! Playlist 2012: https://www.youtube.com/playlist?list=PLCGAAdUizzH31VumrhrK2HHepHu3DBpY0 Playlist 2011: https://www.youtube.com/playlist?list=PLE90823AFF9C8177B Marcus

Dec. 3, 2012

Re: [Pharo-project] Performance Tip: Using buffered streams

by Sven Van Caekenberghe

On 03 Dec 2012, at 12:43, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > There are ZnCharacterReadStream and ZnCharacterWriteStream that add decoding/encoding to binary streams. They could indeed be used as an alternative. But that was not my point. I reran the examples using a binary file stream to disable the decoding and then using ZnCharacterReadStream to handle the decoding: [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | (NeoJSONReader on: stream) next ] ] timeToRun. 3502 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | (NeoJSONReader on: stream) next ] ] ] timeToRun. 1214 [ StandardFileStream fileNamed: '/tmp/numbers.json' do: [ :stream | (NeoJSONReader on: stream) next ] ] timeToRun 2869 [ StandardFileStream fileNamed: '/tmp/numbers.json' do: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | (NeoJSONReader on: stream) next ] ] ] timeToRun 1280 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | (NeoJSONReader on: (ZnCharacterReadStream on: stream binary)) next ] ] timeToRun. 1655 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | (NeoJSONReader on: (ZnCharacterReadStream on: stream binary encoding: 'latin1')) next ] ] timeToRun. 1574 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: (ZnCharacterReadStream on: fstream binary) do: [ :stream | (NeoJSONReader on: stream) next ] ] ] timeToRun. 1753 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: (ZnCharacterReadStream on: fstream binary encoding: 'latin1') do: [ :stream | (NeoJSONReader on: stream) next ] ] ] timeToRun. 1655 This shows several things (for this particular test case): - ZnCharacterReadStream is at least as good as the builtin decoding streams (here twice as good) - UTF-8 (ZnUTF8Encoder) and Latin1 (ZnNullEncoder) decoding are close together (because the input is ASCII) - ZnBufferedReadStream does not help when the stream is pretty good (ZnCharacterReadStream actually uses a 1 character buffer to support peek, which is important to speed up this use case) - this is to be expected: it adds a layer, but its fetch next buffer logic still loops using #next, decoding possibly Unicode characters - the super fast runs (the 2nd and the 4th) are actually cheating because they skip decoding - thanks for that observation ! Sven PS: While doing these explorations, I actually updated ZnUTF8Encoder quite a bit, both when handling ASCII, which is the majority of characters in most cases, as well as in the general case; see the latest version. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 3, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 496 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Dec. 3, 2012

Re: [Pharo-project] Vim Keys?

by Goubier Thierry

Le 03/12/2012 15:23, Camillo Bruni a Ã©crit : > > On 2012-12-03, at 10:02, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Le 03/12/2012 13:31, Camillo Bruni a Ã©crit : >>>> Well, it's allmost there. The only thing that I didn't manage to push was the removal of the global, class-linked maps (it was rejected)... This is the only step missing for your vim shortcuts to work. >>> >>> Maybe I can revive the discussion here, sadly it died on the tracker :/. >> >>> I would really love to see your changes in the image! >>> However it slightly (changes/breaks depending on the viewer :P) some focus-cycling in certain tools. >> >> There is two different issues : >> >> vim-like shortcuts and focus. >> >> First, vim-like (and emacs, and whatever); this requires cutting off matching of the default shortcuts (since those often conflicts). These defaults being non configurable, Sean (for vim) and I (for my dynamically loaded / matched to current menu shortcuts), had to disconnect from matching the default class-based keymaps by on-the-fly patching of a target Morph KMDispatcher :() Hugly hack, this one. > > I think that should be fine. I remember I did something similar once with Keymapping (in the early days). Doru needed the very same for Moose, so we tried to make it work. I ended up with creating a subclass of KMDispatcher or so, which has a local key-mapping. So there are more or less elegant solutions to this problem (making it work is the main priority :P) Yes, but, still, the code to find the right KMDispatcher to replace is ugly, especially for PluggableTextMorph (since you have not one, but two KMDispatcher to replace). Once done, it works perfectly. You just keep that knowledge somewhere to be able to recreate it (PluggableTextMorph... Hum... Two KMDispatcher to find and replace; MorphTreeMorph... one KMDispatcher instance to replace :) ). >> Second, keyboard focus navigation. First, what I did is the following : correct a bug or two in the Morphic based focus navigation code. And, second, move the focus navigation shortcuts to Keymapping. Nothing else. > > yeah this is how it is supposed to be, no special trickery needed otherwise. neat! > >> However, this exposed one fact about Morphic: that the way to add submorphs is LIGT (Last In Goes to Top i.e: in front of the previous submorphs). This is great for a drawing editor, and bad for an UI design tool, such as Spec. So Spec loads in an apparent reverse order (at least relative to the focus order), and this is what you see. > > right > >>> Is there a way to come up with a more or less compatible things as the focus list? >>> Aka a nice and simple interface on top of your changes to achieve the same thing? >> >> Yes. Just have Spec use on:do: (or load the right keymap) for focus change, instead of using eventHandler. I do believe this change is just around the corner... >> >> Once this is done, any focus order you set in Spec will apply first when focus tabbing. >> >> However, you may then see design faults : if you forget one element in your focus ordering in Spec, you will never manage to focus it by the keyboard. Whereas the Morphic one will always tab through all elements whatever way you build the GUI. > > right > >> IMO, the best would be Spec being able to order submorphs correctly and to then rely on the Morphic focus code. But there must be a good reason for Spec not doing it. I just don't know why? I tried changing a bit Spec for that (changing the default ordering where I could see it, then changing a few Specs here and there to make sure the GUI would build and tab right) and couldn't find anything wrong with it, but I just checked on a few GUI samples. > > I think the only thing with major focus issues was the refactoring-changes browser. > - do a class-rename with the refactoring menu > - try to tab through the changes in the list And what is happening then? Do you tab out the list? >> (This is also because the focus switch code in Morphic is a lot shorter than the Spec one, and I tend to believe the shorter the better (and no duplication). But that's just me:)). > > I think I don't know enough of the internal details, but I saw the 2 sides of the discussion: > - Ben said that it won't work without an explicit focus-order list There is maybe something about Spec component-based approach and composing focus navigation there. The next focus code in Spec is fairly complex when you look at it from the composition angle. Another issue is : do you need to have Spec handling the focus navigation for Spec to work well on multi targets (Morphic, Amber, HTML5, etc...) ? This would be a very important question for me if this multi-toolkit aspect is one of the design goal for Spec. > - I loaded your code, and roughly all tools still worked :) (minor issues with the changes browser for instance) And, since then, you were bypassing Spec focus order allmost everywhere :) > Conclusion: > - Your approach seems to make sense as an approximation of the common case, which is important. > - But we need custom control in certain cases. Yes. This is possible in both (either with the Morphic one or the Spec focus order) by setting the focus yourself when you want it. Just call takeKeyboardFocus on the Morph you want. You just have to take care that you don't throw the focus code in an endless loop by shortcutting the order (that was the bug in Morphic : it would loop forever because of a send navigation key to an owner Morph somewhere :( ). >>> We desperately need this refactoring, and if we don't use it, just because of the focus list, I think it will take another year until they make it into the image :( >> >> I thought it was integrated. I'll check. It is integrated; what I guess is missing is the Spec override. > > http://code.google.com/p/pharo/issues/detail?id=6736 > http://code.google.com/p/pharo/issues/detail?id=6657 > > > thanks for looking into it! It's a pleasure to work in Pharo, you know that feeling :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Dec. 3, 2012

Re: [Pharo-project] Vim Keys?

by Camillo Bruni

On 2012-12-03, at 10:02, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 03/12/2012 13:31, Camillo Bruni a Ã©crit : >>> Well, it's allmost there. The only thing that I didn't manage to push was the removal of the global, class-linked maps (it was rejected)... This is the only step missing for your vim shortcuts to work. >> >> Maybe I can revive the discussion here, sadly it died on the tracker :/. > >> I would really love to see your changes in the image! >> However it slightly (changes/breaks depending on the viewer :P) some focus-cycling in certain tools. > > There is two different issues : > > vim-like shortcuts and focus. > > First, vim-like (and emacs, and whatever); this requires cutting off matching of the default shortcuts (since those often conflicts). These defaults being non configurable, Sean (for vim) and I (for my dynamically loaded / matched to current menu shortcuts), had to disconnect from matching the default class-based keymaps by on-the-fly patching of a target Morph KMDispatcher :() Hugly hack, this one. I think that should be fine. I remember I did something similar once with Keymapping (in the early days). Doru needed the very same for Moose, so we tried to make it work. I ended up with creating a subclass of KMDispatcher or so, which has a local key-mapping. So there are more or less elegant solutions to this problem (making it work is the main priority :P) > Second, keyboard focus navigation. First, what I did is the following : correct a bug or two in the Morphic based focus navigation code. And, second, move the focus navigation shortcuts to Keymapping. Nothing else. yeah this is how it is supposed to be, no special trickery needed otherwise. neat! > However, this exposed one fact about Morphic: that the way to add submorphs is LIGT (Last In Goes to Top i.e: in front of the previous submorphs). This is great for a drawing editor, and bad for an UI design tool, such as Spec. So Spec loads in an apparent reverse order (at least relative to the focus order), and this is what you see. right >> Is there a way to come up with a more or less compatible things as the focus list? >> Aka a nice and simple interface on top of your changes to achieve the same thing? > > Yes. Just have Spec use on:do: (or load the right keymap) for focus change, instead of using eventHandler. I do believe this change is just around the corner... > > Once this is done, any focus order you set in Spec will apply first when focus tabbing. > > However, you may then see design faults : if you forget one element in your focus ordering in Spec, you will never manage to focus it by the keyboard. Whereas the Morphic one will always tab through all elements whatever way you build the GUI. right > IMO, the best would be Spec being able to order submorphs correctly and to then rely on the Morphic focus code. But there must be a good reason for Spec not doing it. I just don't know why? I tried changing a bit Spec for that (changing the default ordering where I could see it, then changing a few Specs here and there to make sure the GUI would build and tab right) and couldn't find anything wrong with it, but I just checked on a few GUI samples. I think the only thing with major focus issues was the refactoring-changes browser. - do a class-rename with the refactoring menu - try to tab through the changes in the list > (This is also because the focus switch code in Morphic is a lot shorter than the Spec one, and I tend to believe the shorter the better (and no duplication). But that's just me:)). I think I don't know enough of the internal details, but I saw the 2 sides of the discussion: - Ben said that it won't work without an explicit focus-order list - I loaded your code, and roughly all tools still worked :) (minor issues with the changes browser for instance) Conclusion: - Your approach seems to make sense as an approximation of the common case, which is important. - But we need custom control in certain cases. >> We desperately need this refactoring, and if we don't use it, just because of the focus list, I think it will take another year until they make it into the image :( > > I thought it was integrated. I'll check. It is integrated; what I guess is missing is the Spec override. http://code.google.com/p/pharo/issues/detail?id=6736 http://code.google.com/p/pharo/issues/detail?id=6657 thanks for looking into it!

Dec. 3, 2012