December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Vim Keys?

by Sean P. DeNigris

Goubier Thierry wrote > the removal of the global, class-linked maps (it was rejected)... > This is the only step missing for your vim shortcuts to work. Yes!!! That's exactly what was holding me up... From http://forum.world.st/Keymapping-Class-vs-Instance-Targets-tp4639863p464022… : Sean P. DeNigris wrote > > Guillermo Polito wrote >> - static shortcuts (per class) >> - dynamic category shortcuts ( you build a category and attach it to an >> instance) > The thing is that these two conflict. If I add a category to a class in > the "static shortcuts" (which I consider to be "default shortcuts" - I > think that's more useful), and then I want to remove that category for an > instance, I can't. > > What I want is: each instance gets its own copy of all its maps. If the > morph instance doesn't have any per-instance customizations, this can > point to the class defaults to save space (but I think this would be > premature optimization). However, as soon as the instance differs at all > from the class defaults, it /must/ have it's own local copy of all the > maps. I don't want to have to override each shortcut of a category > attached to the class. I want to detach the category /for just this > instance/. -- View this message in context: http://forum.world.st/Re-Vim-Keys-tp4657381p4657920.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 3, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 497 - Still Failing!

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

Dec. 3, 2012

Re: [Pharo-project] using a long running native thread - NativeBoost or Plugin?

by Eliot Miranda

On Sun, Dec 2, 2012 at 2:59 PM, drush66 <davorin.rusevljan(a)gmail.com> wrote: > Would it be possible to start native thread inside pharo? This thread would > run (for quite a long time) some event loop (like the libev), and post some > info to the SharedQueue. Smalltalk code would in turn be reading stuff from > this queue. You could say it would be pumping events from libev to > SharedQueue instance for Smalltalk code to consume. > > Is this doable? With NativeBoost or Plugin? > > I have also found some info on threaded VM, but if I understand it > correctly > it seems more oriented to provide a thread to execute FFI call on it. > I wouldn't say that. The threading scheme is David Simmons' architecture, used in his AOS and S# VMs and similar to that used in the python VM, but more efficient. It allows multiple threads to share the VM, but only allows one to run Smalltalk at any one time. It is designed to allow Smalltalk to interact freely with any number of native threads. Cal-backs can come in from any thread. SMalltalk processes can be associated with specific threads, allowing one to control which thread a call-out is made on. ----- > http://www.cloud208.com/ > -- > View this message in context: > http://forum.world.st/using-a-long-running-native-thread-NativeBoost-or-Plu… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- best, Eliot

Dec. 3, 2012

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

by Sven Van Caekenberghe

On 03 Dec 2012, at 19:24, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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... Many people seem to be rediscovering the same problems, not a good sign ;-) I think that in particular MultiByteFileStream>>#peek is not efficient. Yeah, there seems to be a WideString construction issue as well, I haven't looked into it yet. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 3, 2012

Re: [Pharo-project] DynamicVariable>>value:during:

by Sven Van Caekenberghe

http://code.google.com/p/pharo/issues/detail?id=7093 -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 02 Dec 2012, at 22:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Yes, I think so too, but maybe there was some reason for not doing it ? > > On 02 Dec 2012, at 20:52, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Hey guys, >> >> would not make much much more sense if we return the result of evaluating the block when we use dynamic variables? >> >> Here is the patch I'm using these days: >> >> DynamicVariable>>value: anObject during: aBlock >> >> | p oldValue result | >> p := Processor activeProcess. >> oldValue := (p psValueAt: index) ifNil: [self default]. >> [ >> p psValueAt: index put: anObject. >> result := aBlock value. >> ] ensure: [ >> p psValueAt: index put: oldValue >> ]. >> >> ^ result

Dec. 3, 2012

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