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

Re: [Pharo-project] Tab widget improvements

by Gary Chambers

Hi Laurent. Sounds like a cool idea and is possible. You'd likely need to modify SystemWindow somewhat to deal with being within a tab (remove grips, forward label changes to the tab, handle activation (TopWindow stuff might be tricky) etc.). You'd also want an option (perhaps a button in the tab label) to break the window out again. For some of this you could get some ideas from StandardWindow with respect to fullscreen, #noteNewOwner: Regards, Gary ----- Original Message ----- From: laurent laffont To: Pharo-project(a)lists.gforge.inria.fr Sent: Wednesday, June 08, 2011 5:20 PM Subject: Re: [Pharo-project] Tab widget improvements Hi Gary, I wanted to try what follows while coding TWM, maybe with your magic super powers its easy :) Create a SystemWindow subclass: #TabbedWindow (or better name). In this window's menu there's the list of all other SystemWindows. When you click on it, the window goes as tab. So I can group several windows in a tabbed container. Like the group windows feature of KDE. See http://blip.tv/sebastian-kgler/window-managing-features-in-kde-plasma-4-4-3… at 1'50. Is it hard ? Idea how to do this ? Laurent. On Wed, Jun 8, 2011 at 4:57 PM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: For another example, just a quickly hacked together (i.e. quick and dirty) multi workspace thing attached. MultiWorkspaceWindow new open Use the window menu to add workspaces, otherwise works like a workspace for the selected tab. Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, June 08, 2011 3:26 PM Subject: Re: [Pharo-project] Tab widget improvements Lol Regards, Gary ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, June 08, 2011 3:19 PM Subject: Re: [Pharo-project] Tab widget improvements You know my soft spot :) Doru On 8 Jun 2011, at 16:04, Gary Chambers wrote: I expect Doru will want it in 1.3 for Moose ;-) Regards, Gary ----- Original Message ----- From: "Marcus Denker" <marcus.denker(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, June 08, 2011 3:00 PM Subject: Re: [Pharo-project] Tab widget improvements On Jun 8, 2011, at 3:55 PM, Gary Chambers wrote: Attached, some improvements to the TabGroupMorph etc. having had feedback from Doru. Provides scrolling buttons when insufficient room for all tabs and displays only tabs for which there is room! (excepting at least one). Can optionally set wrapScrolling on the TabSelectorMorph to allow wraparound scrolling via the buttons. Do we put that in 1.3 or 1.4? http://code.google.com/p/pharo/issues/list?thanks=4376 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- www.tudorgirba.com "Live like you mean it."

June 9, 2011

[Pharo-project] OCompletion is broken in 1.3

by Mariano Martinez Peck

I doesn't work at all. If someone can give a hand... -- Mariano http://marianopeck.wordpress.com

June 9, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Martin Dias

Hi > Has anyone done any serious work with Paul Baumann's SRP? > > > > http://sourceforge.net/projects/srp/ > > And also with MessagePack (http://msgpack.org/) a highly space/time > efficient binary serialization protocol. There is an implementation on > SqueakSource at http://www.squeaksource.com/MessagePack and a > high-level object-serialization protocol on top of that at > http://www.squeaksource.com/STOMP. > > I have never used SRP or MessagePack, both seems great. An important difference of Fuel is that it is not focused in cross-dialect or cross-language object exchange.

June 9, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Mariano Martinez Peck

On Thu, Jun 9, 2011 at 9:18 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi Eliot, > > I am glad to receive your feedback. I definitely agree with that, your > changes have been added on last version. > > The reason for that cached information was mainly to support a Mariano's > project requirement: he needs to frequently do lots of small serializations. > Exactly. I was the guilty. In fact, at the beginning this was exactly as you suggested now. And I ask Martin to change it heheheh. > But in any case, that cache should be managed externally of Fuel. > > Yes, I can do that. > In my computer, this bench: > [ FLGlobalMapper newWith: nil ] bench. > > went from '402,000 per second' to '35.8 per second'. But in the common use > case of a serializer it is really imperceptible. > > Thank you very much. > Martin > > > > On Wed, Jun 8, 2011 at 5:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> On Wed, Jun 8, 2011 at 11:59 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> Hi Mariano and Martin, >>> >>> some feedback. The ClassPoolBindings cache >>> in FLClassPoolAssociationMapper feels like a mistake to me. I would just >>> compute this map at the start of serialization. It'll take hardly any time. >>> Whereas there's lots of scope for this information, if cached, to become >>> stale over time. >>> >>> Find attached. If you're happy with this then before or after remember >>> to evaluate >>> SystemChangeNotifier uniqueInstance noMoreNotificationsFor: >>> FLClassPoolAssociationMapper >>> >> >> and the same goes for FLGlobalMapper. Also remember SystemChangeNotifier >> uniqueInstance noMoreNotificationsFor: FLGlobalMapper >> >> >>> >>> best >>> Eliot >>> >> >> > -- Mariano http://marianopeck.wordpress.com

June 9, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by StÃ©phane Ducasse

do you know what is the encoding scheme under message pack? Huffman like? It would be a nice student projects to get one version for Smalltalk Stef On Jun 9, 2011, at 6:51 AM, Lukas Renggli wrote: > On 9 June 2011 03:23, Sean Malloy <smalloy(a)gmail.com> wrote: >>> Last months I and Tristan have been working on Fuel project, an object >>> binary serialization tool. The idea is that objects are much more >>> times loaded than stored, therefore it is worth to spend time while >>> storing in order to have faster loading and user experience. We >>> present an implementation of a pickle format that is based on >>> clustering similar objects. >> >> Having not looked at Fuel at all... >> >> Has anyone done any serious work with Paul Baumann's SRP? >> >> http://sourceforge.net/projects/srp/ > > And also with MessagePack (http://msgpack.org/) a highly space/time > efficient binary serialization protocol. There is an implementation on > SqueakSource at http://www.squeaksource.com/MessagePack and a > high-level object-serialization protocol on top of that at > http://www.squeaksource.com/STOMP. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

June 9, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Martin Dias

On Wed, Jun 8, 2011 at 10:35 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Martin and Mariano, > > a couple of questions. What's the right way to exclude certain objects > from the serialization? Is there a way of excluding certain inst vars from > certain objects? > > Hi, We are close to have this feature, but still is an open issue. The idea is to to support this "statically" via: ClassWithTransients >> fuelTransientInstanceVariables ^ #(myTransientValue1 myTransientValue1) or more dinamically via: FLSerializationSettings newDefault onClass: ClassWithTransients declareTransients: #(myTransientValue1 myTransientValue1). Do you have a better idea? Cheers Martin > best > Eliot >

June 9, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Martin Dias

Hi Eliot, I am glad to receive your feedback. I definitely agree with that, your changes have been added on last version. The reason for that cached information was mainly to support a Mariano's project requirement: he needs to frequently do lots of small serializations. But in any case, that cache should be managed externally of Fuel. In my computer, this bench: [ FLGlobalMapper newWith: nil ] bench. went from '402,000 per second' to '35.8 per second'. But in the common use case of a serializer it is really imperceptible. Thank you very much. Martin On Wed, Jun 8, 2011 at 5:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Wed, Jun 8, 2011 at 11:59 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi Mariano and Martin, >> >> some feedback. The ClassPoolBindings cache >> in FLClassPoolAssociationMapper feels like a mistake to me. I would just >> compute this map at the start of serialization. It'll take hardly any time. >> Whereas there's lots of scope for this information, if cached, to become >> stale over time. >> >> Find attached. If you're happy with this then before or after remember to >> evaluate >> SystemChangeNotifier uniqueInstance noMoreNotificationsFor: >> FLClassPoolAssociationMapper >> > > and the same goes for FLGlobalMapper. Also remember SystemChangeNotifier > uniqueInstance noMoreNotificationsFor: FLGlobalMapper > > >> >> best >> Eliot >> > >

June 9, 2011

[Pharo-project] [update 1.3] #13257

by Marcus Denker

13257 ----- Issue 4376: Tab widget improvements http://code.google.com/p/pharo/issues/detail?id=4376 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 9, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Lukas Renggli

On 9 June 2011 03:23, Sean Malloy <smalloy(a)gmail.com> wrote: >> Last months I and Tristan have been working on Fuel project, an object >> binary serialization tool. The idea is that objects are much more >> times loaded than stored, therefore it is worth to spend time while >> storing in order to have faster loading and user experience. We >> present an implementation of a pickle format that is based on >> clustering similar objects. > > Having not looked at Fuel at all... > > Has anyone done any serious work with Paul Baumann's SRP? > > http://sourceforge.net/projects/srp/ And also with MessagePack (http://msgpack.org/) a highly space/time efficient binary serialization protocol. There is an implementation on SqueakSource at http://www.squeaksource.com/MessagePack and a high-level object-serialization protocol on top of that at http://www.squeaksource.com/STOMP. Lukas -- Lukas Renggli www.lukas-renggli.ch

June 9, 2011

Re: [Pharo-project] Fuel - a fast object deployment tool

by Eliot Miranda

Hi Martin and Mariano, a couple of questions. What's the right way to exclude certain objects from the serialization? Is there a way of excluding certain inst vars from certain objects? best Eliot

June 9, 2011