November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Should Nautilus use Rubric?

by stepharo

> as soon as Igor put the configuration in the inbox and mark the issue as âfix review neededâ :) so should I do it? Stef > > Esteban > >> On 08 Nov 2014, at 09:14, stepharo <stepharo(a)free.fr> wrote: >> >> When do we get it because we will work on it while other people are on vacation.... ie monday and tuesday with igor and alain. >> >> >> On 7/11/14 14:52, Esteban Lorenzano wrote: >>> Actually, Iâm (finally) about to integrate it (an alpha version). >>> it will be in the image next week :P >>> >>> Esteban >>> >>>> On 07 Nov 2014, at 14:32, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> I think we should submit TxModel to the vaporware awards 2014 :) >>>> >>>> Norbert >>>> >>>>> Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> >>>>> I would say yes. >>>>> we would like to have rubric everywhere we need a real editor :) >>>>> (while waiting for the new TxModel, this is the âless pain pathâ, IMO) >>>>> >>>>> Esteban >>>>> >>>>>> On 07 Nov 2014, at 14:07, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? >>>>>> >>>>>> Thank you a lot! >>>>>> Juraj >>> >> > >

Nov. 8, 2014

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

by Ben Coman

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. (??) 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? cheers -ben > >> >> cheers -ben >> >> >> > > > >

Nov. 8, 2014

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

by Alain Rastoul

Le 08/11/2014 10:39, Thierry Goubier a Ã©crit : > Hi Alain, > > 2014-11-08 10:28 GMT+01:00 Alain Rastoul <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>>: > > Hi, > Sorry if my question sounds stupid and just denotes misunderstanding > here > but couldn't this kind of "typing" information (or contract ?) be > given by pragmas ? > > > If you want it to be done that way, you need to look into gradual > typing; it is a proper solution (see J. Siek research work), which has > Smalltalk/Pharo implementations. > > Pragmas are no better than a naming convention, they add a layer of > language on top of Smalltalk, and they don't help with the search for > implementors issue (i.e. they are not visible at the point of call). yes, the point here was to just to search them in an implementor browser if I understood. contracts checking at run time would certainly imply much more work, the bird's eye way could be to dynamically create and compile subclasses that implement the checks and modify/recompile classes that use them ... not trivial at all and may be risky > > Philosophically, all work done in Smalltalk is a proof that types > declarations may not be that usefull. thinking to that, sure, one can allways do without, at work, I sometimes I have to practice the explain me what you need, I'll explain you how to do without method, and don't like to do it much when not really justified... I don't like typing because I feel it is too related to implementation, but some kind of basic contract checking (parameters and returns) of a method are useful in other languages. However, I still prefer smalltalk for its elegance and simplicity, the hardest thing to achieve in software, introducing typing would somewhat break this simplicity > > Thierry > > > Regards, > Alain > > Le 08/11/2014 07:28, Ben Coman a Ã©crit : > > > 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? > > cheers -ben > > > > > > > > >

Nov. 8, 2014

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

by Nicolai Hess

2014-11-08 13:19 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Thierry Goubier wrote: > >> Hi Ben, >> >> 2014-11-08 7:28 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto: >> btc(a)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. > > cheers -ben > > > +1 for better naming. accept is too generic. Anyway, I don't understand why the pattern should dictate function names. Sure, it may help to understand the design, but you can describe this in the class comment. Events are "processed" or "handled", not visited.

Nov. 8, 2014

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

by Alain Rastoul

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 ? > > cheers -ben > > >

Nov. 8, 2014

Re: [Pharo-dev] inria survey

by Ben Coman

Marcus Denker wrote: >> I've completed it, but some ambiguities I encountered... >> >> What is "Vulgarization of scienceâ > > French people think it is the english translation of the french word "vulgarisation scientifique" > http://fr.wikipedia.org/wiki/Vulgarisation > > It seems to be in the english dictionary as âto make popularâ: > http://dictionary.reverso.net/english-definition/vulgarisation English grabs a lot of words from a lot of places. From my preferred dictionary... http://www.merriam-webster.com/dictionary/vulgarisation I note that it says "foreign term - origin french", so I guess that is why french finds it a good "technical" match. However that usage is not in common use. For me, it evokes strong association with negative connotations... http://www.merriam-webster.com/dictionary/vulgar and while the french interpretation gets a look-in with item 3a, I've never seen the term used like that. Now google translate for... http://fr.wikipedia.org/wiki/Vulgarisation says [1] "Popularization - The extension is a form of educational knowledge dissemination seeks to know (and possibly its limitations and uncertainties) to reach a non-expert audience." ...which sounds like what they mean. [1] http://tinyurl.com/m555d8x Maybe something to feed back to the general INRIA population :) HTH, cheers -ben > > (coming from latin I guess lots of languages have it with kind-of-the same meaning.) > For my german ear it sound horrible, as âvulgÃ¤râ has picked up *very* negative > connotations. > > You really do not want to be thatâ¦ or make your research that: > http://www.dict.cc/deutsch-englisch/vulgÃ¤r.html > > > Marcus > > > > >

Nov. 8, 2014

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

by Ben Coman

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. cheers -ben

Nov. 8, 2014

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

by Alain Rastoul

Le 08/11/2014 12:39, Ben Coman a Ã©crit : > Alain Rastoul wrote: >> Hi, >> Sorry if my question sounds stupid and just denotes misunderstanding here >> but couldn't this kind of "typing" information (or contract ?) be >> given by pragmas ? > > I'm not so much concerned about "typing" in itself , but more about > convenience in what I'll tentatively call "searchability" and > "observability". If a pragma in the method definition defines the type > of its parameter, then in the caller I am still looking at a single > method name (#accept:) shared amongst several domains - and <cmd-M> > still brings up a mixed list from those domains. My thought was that may be here a pragma (or just guessing about parameter name) could help the implementor browser preselect the accept: method you are looking for in the list, among others (implies modifications to implementor browser of course) btw pragma and contracts may be overkill, guessing could do it Then again, maybe I > just described one purpose "typing"? But I'm note sure what using a > pragma would add, particularly since I can't see past how would you link > invocation and implementation. Using #acceptSomeClass: seems the > simplest thing that would work. > > cheers -ben > >> >> Regards, >> Alain >> >> Le 08/11/2014 07:28, Ben Coman a Ã©crit : >>> >>> 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? >>> >>> cheers -ben >>> >>> >>> >>> >>> >> >> >> >> > > > >

Nov. 8, 2014

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

by Ben Coman

Alain Rastoul wrote: > Hi, > Sorry if my question sounds stupid and just denotes misunderstanding here > but couldn't this kind of "typing" information (or contract ?) be given > by pragmas ? I'm not so much concerned about "typing" in itself , but more about convenience in what I'll tentatively call "searchability" and "observability". If a pragma in the method definition defines the type of its parameter, then in the caller I am still looking at a single method name (#accept:) shared amongst several domains - and <cmd-M> still brings up a mixed list from those domains. Then again, maybe I just described one purpose "typing"? But I'm note sure what using a pragma would add, particularly since I can't see past how would you link invocation and implementation. Using #acceptSomeClass: seems the simplest thing that would work. cheers -ben > > Regards, > Alain > > Le 08/11/2014 07:28, Ben Coman a Ã©crit : >> >> 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? >> >> cheers -ben >> >> >> >> >> > > > >

Nov. 8, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

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 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