- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] edit values in GTInspector

by Marcus Denker

> On 09 Nov 2014, at 07:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 08 Nov 2014, at 21:11, stepharo <stepharo(a)free.fr> wrote: >> >> What would be nice is to have the bifrost infrastructure and add a metaobject to an inspected object and removing when the inspector get closed. >> It would be quite nice and fully dynamic. >> > > Yes, in the longer term we should is like thatâ¦ of course we need to be a bit careful as this would mean that we change (on some level) > as soon as we inspect. But if we make the underlying framework really good (working with e.g. objects being passed to primitives), > it would be great. > Ah.. and we need not full object centric reflection for this: -> the inspector need to refresh if a variable changes -> this means we need to hook into all assignment to an ivar -> which is just a #before reflectivity link on a Slot, the same that breakpoints use. (reflective change needs more care (#instVarAt: and friends) So this should be working very very soonâ¦ Marcus

Nov. 9, 2014

Re: [Pharo-dev] edit values in GTInspector

by Marcus Denker

> On 08 Nov 2014, at 21:11, stepharo <stepharo(a)free.fr> wrote: > > What would be nice is to have the bifrost infrastructure and add a metaobject to an inspected object and removing when the inspector get closed. > It would be quite nice and fully dynamic. > Yes, in the longer term we should is like thatâ¦ of course we need to be a bit careful as this would mean that we change (on some level) as soon as we inspect. But if we make the underlying framework really good (working with e.g. objects being passed to primitives), it would be great. >From the planning -> Finish Reflecticity -> add proxies to the system -> combine the two -> then add a higher level layer (in the style of bifrost) So this will be funâ¦ but will take a while. Marcus

Nov. 9, 2014

Re: [Pharo-dev] edit values in GTInspector

by Tudor Girba

This would be indeed fantastic. Cheers, Doru On Sat, Nov 8, 2014 at 9:11 PM, stepharo <stepharo(a)free.fr> wrote: > What would be nice is to have the bifrost infrastructure and add a > metaobject to an inspected object and removing when the inspector get > closed. > It would be quite nice and fully dynamic. > > On 8/11/14 08:28, Tudor Girba wrote: > > What Alex was saying is that he only trusts an inspector that he just > opened. This is clearly not ideal. > > Is there a way to get reliably notified when an object changes its state? > > Cheers, > Doru > > > > On Sat, Nov 8, 2014 at 7:37 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> >> > On 07 Nov 2014, at 19:24, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> > >> > This is strange, I do not remember to have use this when I was using >> the old inspector. I usually trust what the inspector tells me only having >> open one. >> > >> >> But thatâs the point: if the value changes, the inspector shows the old >> one. So you can *not* trust it. >> (and all the cool demos do not work anymore: adding an ivar to a class >> and the inspector on the object shows >> it, inspecting the world and showing how the mouse course position >> changesâ¦) >> >> Marcus >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 8, 2014

Re: [Pharo-dev] edit values in GTInspector

by stepharo

What would be nice is to have the bifrost infrastructure and add a metaobject to an inspected object and removing when the inspector get closed. It would be quite nice and fully dynamic. On 8/11/14 08:28, Tudor Girba wrote: > What Alex was saying is that he only trusts an inspector that he just > opened. This is clearly not ideal. > > Is there a way to get reliably notified when an object changes its state? > > Cheers, > Doru > > > > On Sat, Nov 8, 2014 at 7:37 AM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > > On 07 Nov 2014, at 19:24, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > > > This is strange, I do not remember to have use this when I was using the old inspector. I > usually trust what the inspector tells me only having open one. > > > > But thatâs the point: if the value changes, the inspector shows > the old one. So you can *not* trust it. > (and all the cool demos do not work anymore: adding an ivar to a > class and the inspector on the object shows > it, inspecting the world and showing how the mouse course position > changesâ¦) > > Marcus > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Nov. 8, 2014

Re: [Pharo-dev] NAtiveBoost error

by Sven Van Caekenberghe

> On 08 Nov 2014, at 12:33, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > About RabbitMQ and others, I did quite some investigations and already use some > (working with MSMQ in dotnet at work). > I could spend months here but would not like to. > > My last question (in fact my real interrogation) here is especially to you, as the Zn developer, > about a server implementation in pharo: > not a true generic enterprise class server, > a very small and simple dedicated server to start with, > like Teapot is with respects to a big http enterprise class server. > I don't really mind not following existing MQ protocols and RFCs (*), it would be dedicated. > (*): except for the reusing part that of course has to be taken into account, > for example websockets. > > Does it sounds realistic to you or totally undoable, and why ? > Did you made experiments in that direction ? > What would be your opinion, and do you have thoughts to share about that ? > > Thanks in advance Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor. I don't know what you are looking for, I would just do some prototyping and see what happens. > Regards, > Alain > > Le 08/11/2014 11:25, Sven Van Caekenberghe a Ã©crit : >> >>> On 08 Nov 2014, at 11:21, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >>> >>> Perfectly correct, I agree, >>> and do you have an opinion or pointers about building a streaming server in pharo ? >>> queuing send/receives (nextPut:, next) from producers and consumers ? >> >> Please start by reading https://github.com/svenvc/docs/blob/master/neo/stamp.md >> Don't forget to read a bit about RabbitMQ itself too. >> You can load the code and look at the tests. >> >>> Le 08/11/2014 11:09, Sven Van Caekenberghe a Ã©crit :> >>>>> On 08 Nov 2014, at 10:56, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >>>>> >>>>> Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM >>>>> (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack >>>>> what I am looking for is streaming (on top of a queuing server I presume). >>>> >>>> RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers. >>>> >>>> Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view. >>>> >>> >>> >>> >> >> >> > > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Ben Coman

Alain Rastoul wrote: > trying to be more concrete (and still not sure of pragma > syntax and capabilities) I wonder if with methods in the image like: > > OSMorphicEventHandler>>accept: aMouseEvent > <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> > > OSXWindowEvenHandlert>>accept: aMouseEvent > <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> > > OSMarsWindowEvent>>accept: aMouseEvent > <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> > > SignalHandler>>accept: aSignalEvent > <pragma: precondition parameter:aSignalEvent isKindOf: SignalEvent> > > > browsing OSWindowMorphicEventHandler>>handleEvent: > OSWindowMorphicEventHandler>>handleEvent: > morphicEvent := anEvent accept: self. > or > morphicEvent := anEvent accept: aVariableEvent. > > current class beeing a subclass of OSMorphicEvent (type of self), > and aVariableEvent type beeing known (NEC/NEOController/model ?) > it couldn't be possible to find or filter relevant methods for both, > excluding SignalHandler (filtering on accept: methods with good pragma > signature) ? > > Regards, > Alain > > > Thanks for the concrete examples. So you may be right. If you can demonstrate it working reliably, it would be easy enough to rename #acceptXxx: methods back to #accept:. cheers -ben

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Alain Rastoul

Le 08/11/2014 15:41, Thierry Goubier a Ã©crit : > > > Yes, but do you imagine how complex it would be to tag everything like > that? Compared to the simple naming convention suggested by Ben? > > Thierry > Well, I don't know how much would have to be tagged. Not sure everything would have to, only ancestors in my mind, thus excluding a lot of irrelevant subclasses. I'll have to refine that, but not now, I have to leave for the week end. May be I'm wrong and my idea is bad here... From a user (as a programmer) perspective, I would prefer your idea of following naming than to rename each accept method, I prefer to have simple accept: method than a bunch of acceptOSEventHandler: , acceptXxx: etc... just for simplicity. and eventually use NEController (I think it is this class?) to guess for types at some places. Personnally, I don't like much the visitXxx: naming of methods. (just a programmer's opinion). Another thing: for browsing, the old implementor browser with subpanes was useful because you could easily select the right implementor. Regards, Alain

Nov. 8, 2014

OSWindow roadmap

by Ben Coman

stepharo wrote in "[Pharo-dev] Visit/accept method naming philosophy": > ben pay attention that OSWindow needs a real polish phase. > We logged some items to be fixed in the pharo roadmaps on github in > Events.md Thanks for the reference. Actually it answers some questions I had. I had started to review Case 14404 [1] "extend MorphicEventHandler with #mouseOver and replace all uses of MouseOverEventHandler" and thought it might be useful to add some tests of the existing mouseover, which sent me investigating InputEventFetcher. [1] https://pharo.fogbugz.com/default.asp?14404 I had some seed ideas to introduce a class to replace the eventBuffer Array in InputEventFetcher>>eventLoop, but then (besides performance considerations) wondered what was being disposed of when OSWindow was done. I think maybe I could help with: 1. move the logic of the InputEventFetcher to the OSVMWindowDriver (represents the old system within the OSWindow frameworks). -- but I don't see OSVMWindowDriver in build 40360. 2. OSWindowMorphicEventHandler>>dispatchMorphicEvent: anEvent should rewritten with a more efficient. we should remove the use of defer: 3. Adding some tests to document existing sequencing of #handlesMouseOver:, #handlesDoubleClick: etc... 4. General testing. So how can I get started? * I see a mention a while back of needing a custom VM. Is this still the case? Which VM should I use? * I see CI job https://ci.inria.fr/pharo-contribution/job/OSWindow/ started a week ago but currently disabled. * I see two repositories. Which to use? http://smalltalkhub.com/#!/~Pharo/OSWindow http://smalltalkhub.com/#!/~ronsaldo/OSWindow/commits * How to coordinate? cheers -ben

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Thierry Goubier

2014-11-08 15:02 GMT+01:00 Alain Rastoul <alf.mmm.cat(a)gmail.com>: > Le 08/11/2014 14:37, Ben Coman a Ã©crit : > > Alain Rastoul wrote: >> >>> Le 08/11/2014 13:19, Ben Coman a Ã©crit : >>> >>>> Thierry Goubier wrote: >>>> >>>>> Hi Ben, >>>>> >>>>> 2014-11-08 7:28 GMT+01:00 Ben Coman >>>>> <btc(a)openinworld.com >>>>> <mailto:btc@openinworld.com>>: >>>>> >>>>> >>>>> This is a general query and something I've wondered several times >>>>> before in different situations, but I use OSWindow as an example >>>>> since that is what I happen to be looking at this time. >>>>> >>>>> For curiosity I was having a poke around OSWindow and seeing >>>>> OSWindowMorphicEventHandler>>__handleEvent: >>>>> morphicEvent := anEvent accept: self. >>>>> >>>>> I wanted to view the code that could invoke, so I used <cmd-M> on >>>>> #accept: to get the implementors, which lists 116 items, many of >>>>> which are unrelated. Now its not toooo hard to "guess" which >>>>> implementations are related, but it would be nicer to guess less. >>>>> Would it be a reasonable philosophy to distinguish each package's >>>>> #accept: method by appending the expect object type, like this... ? >>>>> >>>>> >>>>> OSWindowMorphicEventHandler>>__handleEvent: >>>>> morphicEvent := anEvent acceptOSEventHandler: self. >>>>> >>>>> IRVisitor>>visitNode: elem >>>>> ^ elem acceptIRVisitor: self >>>>> >>>>> ParseNodeVisitor>>__visitBlockNode: aBlockNode >>>>> aBlockNode statements do: >>>>> [:statement | statement acceptParseNode: self] >>>>> >>>>> >>>>> Or does such a convention constrain too much how you can extend a >>>>> visitor pattern? >>>>> >>>>> >>>>> It has a nice "a type is documentation for the programmer" effect, so >>>>> I'd say it could work. It would be interesting to see what it looks >>>>> like on an external package of a certain size and with users. >>>>> >>>>> At the same time, your issue is also with the fact that filtering the >>>>> relevant #accept: implementors could be easier, and this is a GUI >>>>> issue for which we already have propositions (or we can think of some). >>>>> >>>>> Thierry >>>>> >>>>> >>>> If you are thinking of scoped-browsing, then I think my particular case >>>> just now, that would have been a little constraining. I wasn't really >>>> on a task working with OSWindow. I was just bouncing around the system >>>> with curiousity. Needing to scope the browser before doing <cmd-M> >>>> would add some steps (i.e. friction) over just having methods named >>>> #acceptDomainSpecific: . >>>> >>>> And I am thinking of another hypothetical case where a third party >>>> extends a visitor pattern in a separate package, so if the browser scope >>>> was limited to a particular package, then the visitor in the other >>>> package would be excluded. But if its done on methodName, a third party >>>> extension is implicitly included. >>>> >>> hence the use of pragma: a basic contract on the interface of the method >>> that may be useful to the browser to find relevant implementations in >>> all packages. >>> >> >> It seems that it is what you are looking for: find all implementations of >>> accept: anOSWindowOrSubclass ? >>> >> >> I am still not clear on how a pragma could be used here. First I >> presume you mean to put pragmas in the implementations of #accept, and >> not in all the callers of #accept. (??) >> > yes that's it > >> >> Subsequently, what information in the caller... >> OSWindowMorphicEventHandler>>handleEvent: >> morphicEvent := anEvent accept: self. >> ...when selecting 'accept:' and pressing <cmd-M>, >> could be combined with the pragmas to provide a filtered list with only >> the implementations of #accept related to this domain? >> > implementor browser would have to maintain some dictionary of > classes/methods/pragmas implementations of certain kinds, > by searching at run-time in the image (at least the first time) > > knowing that the edited class is a OSMorphicEvent subclass (for example) > and finding in it's list/dictionary one or several > accept: method implementations that has the > <pragma: pre-contract: 'self isKindOf: OSMorphicEvent'> > on a parameter > couldn't the browser preselect one and/or filter them? > (pragma syntax fictious and wrong here of course) > Yes, but do you imagine how complex it would be to tag everything like that? Compared to the simple naming convention suggested by Ben? Thierry > > just an idea, tell me if I'm wrong > >> >> cheers -ben >> >> >>> >>>> cheers -ben >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > >

Nov. 8, 2014

Re: [Pharo-dev] Visit/accept method naming philosophy

by Alain Rastoul

trying to be more concrete (and still not sure of pragma syntax and capabilities) I wonder if with methods in the image like: OSMorphicEventHandler>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> OSXWindowEvenHandlert>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> OSMarsWindowEvent>>accept: aMouseEvent <pragma: precondition parameter:aMouseEvent isKindOf: OSMorphicEvent> SignalHandler>>accept: aSignalEvent <pragma: precondition parameter:aSignalEvent isKindOf: SignalEvent> browsing OSWindowMorphicEventHandler>>handleEvent: OSWindowMorphicEventHandler>>handleEvent: morphicEvent := anEvent accept: self. or morphicEvent := anEvent accept: aVariableEvent. current class beeing a subclass of OSMorphicEvent (type of self), and aVariableEvent type beeing known (NEC/NEOController/model ?) it couldn't be possible to find or filter relevant methods for both, excluding SignalHandler (filtering on accept: methods with good pragma signature) ? Regards, Alain

Nov. 8, 2014