- Pharo-dev - lists.pharo.org

[Pharo-project] [COTDC] 68 - MultiNewParagraph

by laurent laffont

Today: MultiNewParagraph Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

May 24, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 67#2 - MultiDisplayScanner

by laurent laffont

On Mon, May 23, 2011 at 10:51 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > I'm a class related to the computation of characters counting for text > flow. > > I'm probably wrong but this is what I think I remember from what I guessed > :) > COTDC new guessCommentOf: MultiDisplayScanner. :) Laurent. > Stef > > > On May 23, 2011, at 9:40 PM, laurent laffont wrote: > > > Today: MultiDisplayScanner > > > > > > Comment Of The Day Contest - One Day One Comment > > Rules: > > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > > #2: If you cannot comment it, deprecate it. > > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > > > Laurent > > > > >

May 24, 2011

Re: [Pharo-project] Tiling windows

by laurent laffont

On Tue, May 24, 2011 at 9:48 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Ok we need a 1.3 version because now we get excited. > Here's a first shot (not integrated to TaskBarMorph though) which works in 1.3: Gofer it squeaksource: 'TilingWindowManager'; package: 'TWM'; load. TWMBar new open. The real manager is TilingWM. Try: (TilingWM forWorld: World) tileVisibleWindows. (TilingWM forWorld: World) tileBrowsers. (TilingWM forWorld: World) tileWorkspaces. Laurent. > Stef > > On May 24, 2011, at 8:51 AM, laurent laffont wrote: > > > > > > > 2011/5/24 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > > Laurent and corious :) > > > > I add some TasklistMorph behavior. With the open list (cmd-rigth or > cmd-left): > > * cmd-up: maximize all windows > > * cmd-down: minimize all windows > > * cmd-b: apply SystemBrowser windows's filter > > * cmd-w: apply Worspace windows's filter > > * cmd-a: remove windows's filter > > > > ** The cmd-b work in 1.2.1, in 1.3 you have to change > TasklistMorph>>keyStroke: because I use OBSystemBrowser class by way of > example and therefore does not perform properly filtered. > > > > > > I did not understand until I enable the setting "Keep task list open" :) > > > > I've started a TilingWindowManager project (I will upload it this evening > on SS) so we can put all our stuff + tests without polluting TaskBar & > Tasklist too much. > > > > Indeed, after 3 days I can't live without the tiling buttons :) > > > > Laurent. > > > > > > > > 2011/5/23 laurent laffont <laurent.laffont(a)gmail.com> > > 2011/5/23 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > > Laurent, I attached a package I've added some improvements to your work, > I have found useful. Of course I am not knowledgeable about morph, just > added some and perhaps can serve as inspiration. > > > > Thanks GastÃ³n, I like the idea. It will be a good step forward in having > better window management. Now we should rewrite this clean + tests (may be > adding the notion of widgets like in KDE / Gnome). > > > > As windows fill all the space, would be good to have a button to open the > world menu. > > > > I would love having the possibility of splitting the World + back and > forward configuration like Emacs winner mode, keyboard driven. > > > > Since several days I use http://most-advantageous.com/optimal-layout/ on > OSX and there's some great ideas too. > > > > Laurent. > > > > > > > > 2011/5/23 laurent laffont <laurent.laffont(a)gmail.com> > > On 1.2: > > > > Gofer it > > squeaksource: 'LaurentLSandbox'; > > version: 'Polymorph-Widgets-LaurentLaffont.388'; > > load. > > > > > > Then open or move a window so the TaskBar is updated and you have a new > "magic" button on bottom left. > > > > (note this is hacky actually, I will write a nicer version this week if > people like it). > > > > Laurent. > > > > On Mon, May 23, 2011 at 9:06 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > send a cs that we can play with it :) > > > > On May 22, 2011, at 8:25 PM, laurent laffont wrote: > > > > > Hi, > > > > > > what do you think of adding this in Pharo ? > > > > > > |taskbar tileWindowsBlock| > > > > > > tileWindowsBlock := [ > > > |windows numberOfColumns numberOfRows windowWidth windowHeight| > > > windows := (World submorphs select: [:m| m isSystemWindow and: [m > isNotMinimized]]) asOrderedCollection. > > > numberOfColumns := windows size sqrtFloor. > > > numberOfRows := (windows size / numberOfColumns) rounded. > > > windowWidth := World width // numberOfColumns.. > > > windowHeight := World height - taskbar height // numberOfRows. > > > > > > Matrix > > > rows: numberOfRows > > > columns: numberOfColumns > > > tabulate: [:row :column| |window| > > > windows ifNotEmpty: [ > > > window := windows remove: windows first. > > > window > > > bounds: ( > > > ((column - 1 * windowWidth) @ (row - 1 * > windowHeight)) > > > extent: (windowWidth) @ windowHeight) > > > ] > > > ] > > > ]. > > > > > > > > > taskbar := (World submorphs detect: [:m| m isTaskbar]). > > > > > > taskbar > > > addMorph: (IconicButton new > > > target: tileWindowsBlock; > > > actionSelector: #value; > > > labelGraphic: taskbar theme smallWindowIcon; > > > color: Color transparent; > > > yourself). > > > > > > > > > Laurent Laffont - @lolgzs > > > > > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > > > Blog: http://magaloma.blogspot.com/ > > > Developer group: http://cara74.seasidehosting.st > > > > > > > > > > > > > > > > > > > >

May 24, 2011

Re: [Pharo-project] Questions of understanding

by Mariano Martinez Peck

On Tue, May 24, 2011 at 5:37 PM, Friedrich Dominicus < frido(a)q-software-solutions.de> wrote: > Ok I spend my time today on building a new virtual machine. And my > assumptions in my last mail were wrong. The code is not hand-written > but is generated. Now I understand that. But now I see that while > building the virtual machine the stuff probabably is taken form the > PharoV10.sources file from which it seems SerialPlugin.c is build. > > Sorry, I didn't read the email until now, the subject was not very good ;) > Now in PharoV10.sources there is are not the patches to use ports by > Name as needed in Linux. So now my question is. After I've build a new > virtual machine how can I modify one of the plugins to update them. > > For the plugins, there are two parts: the VMMaker part (usually a plugin is a subclass of InterpreterPlugin) and the C part. Some plugins are directly included in the VMMaker package/repostitory and some others are in different places (usually when they are not "core" plugins). The VMMaker part of SerialPlugin, is in VMMaker package, so if you followed my instructions, when you downloaded VMMAker, you should have downloaded the class SerialPlugin which is in the 'VMMaker-Plugins' category. Now, if you need to modify something to the "platform code", hand written C code, then such plugins can be found in Git or in the SVN. In git, they are in https://gitorious.org/cogvm/ For your case it should be: https://gitorious.org/cogvm/blessed/blobs/master/platforms/unix/plugins/Ser… > So the sources file contains things like openPort but not > openPortByName. So what do I have to do to get into the patches such > that the new SerialPlugin.c can be generated? > > Ah yes I used the pages at > > http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us… > > now you can read: http://marianopeck.wordpress.com/2011/04/05/first-stop-vms-scm-and-related-… :) > for learning that.... > > Regards > Friedrich > > -- Mariano http://marianopeck.wordpress.com

May 24, 2011

Re: [Pharo-project] Questions of understanding

by Marcus Denker

On May 24, 2011, at 5:37 PM, Friedrich Dominicus wrote: > Ok I spend my time today on building a new virtual machine. And my > assumptions in my last mail were wrong. The code is not hand-written > but is generated. Now I understand that. But now I see that while > building the virtual machine the stuff probabably is taken form the > PharoV10.sources file from which it seems SerialPlugin.c is build. > PharoV10.sources should not contain any VM Related sources... the VMMaker package has the source for the VM. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 24, 2011

Re: [Pharo-project] Questions of understanding

by Friedrich Dominicus

Ok I spend my time today on building a new virtual machine. And my assumptions in my last mail were wrong. The code is not hand-written but is generated. Now I understand that. But now I see that while building the virtual machine the stuff probabably is taken form the PharoV10.sources file from which it seems SerialPlugin.c is build. Now in PharoV10.sources there is are not the patches to use ports by Name as needed in Linux. So now my question is. After I've build a new virtual machine how can I modify one of the plugins to update them. So the sources file contains things like openPort but not openPortByName. So what do I have to do to get into the patches such that the new SerialPlugin.c can be generated? Ah yes I used the pages at http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us… for learning that.... Regards Friedrich

May 24, 2011

[Pharo-project] Discussion about pharo with James robertson.

by StÃ©phane Ducasse

http://www.jarober.com/blog/blogView?showComments=true&printTitle=IM_29:_Ph… Stef

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Igor Stasenko

On 24 May 2011 15:20, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > On 05/24/2011 02:57 PM, Igor Stasenko wrote: >> >> On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision(a)gmail.com> >> Â wrote: >>> >>> "But if the dependents are stored in some global dictionary from model to >>> sequence of dependents then the >>> reference from the global dictionary keeps both the model and the >>> dependents >>> alive." >>> >>> When I hear "global dictionary" I think of a namespace. Perhaps >>> namespaces >>> could add efficiency to the GC. >>> >> I don't see how this could improve anything. >> During full GC, it has to mark all reachable objects, because those >> which won't be marked will be reclaimed. >> >> So, how presence of namespaces could make GC faster? > > If you know up-front that the namespace doesn't disappear, you could > separate those objects from the rest of the objects (in a separate heap) and > avoid marking/sweeping altogether. Basically a multi-heap generational GC; > with namespaces rather than just generations based on age. > Pointers going from one heap to another would have to go over a handle > table, as is usual... > Yes. Object spaces with gates between them. But this is orthogonal to Ephemerons. -- Best regards, Igor Stasenko AKA sig.

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Alexandre Bergel

Good point Toon. This is what HotSpot does actually. Alexandre On 24 May 2011, at 09:20, Toon Verwaest wrote: > On 05/24/2011 02:57 PM, Igor Stasenko wrote: >> On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision(a)gmail.com> wrote: >>> "But if the dependents are stored in some global dictionary from model to >>> sequence of dependents then the >>> reference from the global dictionary keeps both the model and the dependents >>> alive." >>> >>> When I hear "global dictionary" I think of a namespace. Perhaps namespaces >>> could add efficiency to the GC. >>> >> I don't see how this could improve anything. >> During full GC, it has to mark all reachable objects, because those >> which won't be marked will be reclaimed. >> >> So, how presence of namespaces could make GC faster? > If you know up-front that the namespace doesn't disappear, you could separate those objects from the rest of the objects (in a separate heap) and avoid marking/sweeping altogether. Basically a multi-heap generational GC; with namespaces rather than just generations based on age. > Pointers going from one heap to another would have to go over a handle table, as is usual... > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Igor Stasenko

On 24 May 2011 16:15, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 24.05.2011 15:30, Chris Cunnington wrote: > > On 24 May 2011 14:46, Chris Cunnington <smalltalktelevision at gmail.com> > wrote: >> "But if the dependents are stored in some global dictionary from model to >> sequence of dependents then the >> reference from the global dictionary keeps both the model and the >> dependents >> alive." > > >> So, how presence of namespaces could make GC faster? > > Well I'm hardly presuming to know, but if you have one dictionary acting as > a global namespace. As far as I understood ephemerons, the > problem is you have a single dictionary/namespace. Both the model and the > view connect to an object. The model lets it go. The view > doesn't. So this is an object you want to collect, because the model has let > it go. This means you have a phantom reference that tricks > the GC. That seems to me to be what ephemerons solve. I'm looking solely at > the MVC Eliot mentioned, because shorn of context the > description didn't mean anything to me. > > "An ephemeron holds onto some object via its key field in a quasi-weak > manner such that the garbage collector will only consider the key live if it > can be reached from the roots and not reachable by the ephemeron's other > inst vars." <- This is the key property of ephemerons. > > In the case of weak Announcement actionBlock subscription: > The block references it's enclosing methodContext. > The methodContext receiver instvar references the object whose method > created the block. > > Thus, if you keep a traditional WeakAssociation object -> block, (which you > will if object is the subscriber) you will always have a strong reference to > object from the value. > If this were an ephemeral association, the references to key stored in value > are not traversed by the gc, and thus object is not marked in > use/subsequently GC'd. > So, lets start a contest for best Ephemeron class comment, describing its essential difference from usual weak references! Because currently , Ephemeron is not documented at all :) >From my side, i will add a description of implementation detail. In short: an Ephemerons actually work on top of already existing finalization scheme which i introduced before. Ephemerons fit nicely in this scheme , which enables a code reuse. > Cheers, > Henry -- Best regards, Igor Stasenko AKA sig.

May 24, 2011