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

Re: [Pharo-dev] NAtiveBoost error

by Sven Van Caekenberghe

> 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] NAtiveBoost error

by Alain Rastoul

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 ? 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] NAtiveBoost error

by Sven Van Caekenberghe

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

Thank you for the pointer, I will look at it. I like the naming convention of Smalltalk, no discussion here :) I thought pragmas where queryables from smalltalk (hence from an implementor browser), but I may be wrong? And to me typing, *when needed*, is a contract on the type of the argument, my point of view, am I wrong ? Alain 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). > > Philosophically, all work done in Smalltalk is a proof that types > declarations may not be that usefull. > > 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] NAtiveBoost error

by Alain Rastoul

Hi Phil, 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). Regards, Alain Le 08/11/2014 10:43, phil(a)highoctane.be a Ã©crit : > I have been using Pharo successfully with RabbitMQ. > > Phil > > Le 8 nov. 2014 10:16, "Alain Rastoul" > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> a Ã©crit : > > Very interesting pointers, thank you Sven. > Pure Pharo sounds really good to me, I lost my appetite for > debugging multithreaded C or C++ > (am I aging ?) and I need some kind of MOM functionality for my > project, that was the > starting point of my ZeroMQ rants. was ramblings here not rants (sorry for my bad english) > In fact, I am looking for a "SOM" (streaming) server as a part of my > musing project > which is about clustering and parallel processing with pharo: > essentially next, nextput: functionalities to PUSH/PULL pools > (may be PUB/SUB REQ/RECV or others?) with some controlling, > signaling and monitoring. > I have the feeling that based on your excellent work in zinc, it should > not be that difficult to built it on top, but may be you know a > project of that kind > I could reuse ? > Do you know about some kind of MOM server in Pharo ? > Or a STOMP or alike server I could vampirize ? > > Thank you > > Alain > > Le 08/11/2014 09:09, Sven Van Caekenberghe a Ã©crit : > > > On 08 Nov 2014, at 00:23, Alain Rastoul > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> wrote: > > BTW, I have the websocket B plan for that (first tests make me > think it could be a better plan for my needs). > It will be a different animal, but interesting too. > > > About Zinc Web Sockets: > > https://github.com/svenvc/__docs/blob/master/zinc/zinc-__websockets-paper.md > <https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md> > > But there is also 'STAMP', a STOMP implementation, which is a > generic message queue client: > > https://github.com/svenvc/__docs/blob/master/neo/stamp.md > <https://github.com/svenvc/docs/blob/master/neo/stamp.md> > > Both are pure Pharo. > > Sven > > > >

Nov. 8, 2014

Re: [Pharo-dev] NAtiveBoost error

by phil＠highoctane.be

I have been using Pharo successfully with RabbitMQ. Phil Le 8 nov. 2014 10:16, "Alain Rastoul" <alf.mmm.cat(a)gmail.com> a Ã©crit : > Very interesting pointers, thank you Sven. > Pure Pharo sounds really good to me, I lost my appetite for debugging > multithreaded C or C++ > (am I aging ?) and I need some kind of MOM functionality for my project, > that was the > starting point of my ZeroMQ rants. > In fact, I am looking for a "SOM" (streaming) server as a part of my > musing project > which is about clustering and parallel processing with pharo: > essentially next, nextput: functionalities to PUSH/PULL pools > (may be PUB/SUB REQ/RECV or others?) with some controlling, signaling and > monitoring. > I have the feeling that based on your excellent work in zinc, it should > not be that difficult to built it on top, but may be you know a project of > that kind > I could reuse ? > Do you know about some kind of MOM server in Pharo ? > Or a STOMP or alike server I could vampirize ? > > Thank you > > Alain > > Le 08/11/2014 09:09, Sven Van Caekenberghe a Ã©crit : > >> >> On 08 Nov 2014, at 00:23, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >>> >>> BTW, I have the websocket B plan for that (first tests make me >>> think it could be a better plan for my needs). >>> It will be a different animal, but interesting too. >>> >> >> About Zinc Web Sockets: >> >> https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md >> >> But there is also 'STAMP', a STOMP implementation, which is a generic >> message queue client: >> >> https://github.com/svenvc/docs/blob/master/neo/stamp.md >> >> Both are pure Pharo. >> >> Sven >> >> > > >

Nov. 8, 2014

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

by Thierry Goubier

Hi Alain, 2014-11-08 10:28 GMT+01:00 Alain Rastoul <alf.mmm.cat(a)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). Philosophically, all work done in Smalltalk is a proof that types declarations may not be that usefull. 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 Alain Rastoul

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

Very interesting pointers, thank you Sven. Pure Pharo sounds really good to me, I lost my appetite for debugging multithreaded C or C++ (am I aging ?) and I need some kind of MOM functionality for my project, that was the starting point of my ZeroMQ rants. In fact, I am looking for a "SOM" (streaming) server as a part of my musing project which is about clustering and parallel processing with pharo: essentially next, nextput: functionalities to PUSH/PULL pools (may be PUB/SUB REQ/RECV or others?) with some controlling, signaling and monitoring. I have the feeling that based on your excellent work in zinc, it should not be that difficult to built it on top, but may be you know a project of that kind I could reuse ? Do you know about some kind of MOM server in Pharo ? Or a STOMP or alike server I could vampirize ? Thank you Alain Le 08/11/2014 09:09, Sven Van Caekenberghe a Ã©crit : > >> On 08 Nov 2014, at 00:23, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >> >> BTW, I have the websocket B plan for that (first tests make me >> think it could be a better plan for my needs). >> It will be a different animal, but interesting too. > > About Zinc Web Sockets: > > https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md > > But there is also 'STAMP', a STOMP implementation, which is a generic message queue client: > > https://github.com/svenvc/docs/blob/master/neo/stamp.md > > Both are pure Pharo. > > Sven >

Nov. 8, 2014

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

by Esteban Lorenzano

as soon as Igor put the configuration in the inbox and mark the issue as âfix review neededâ :) 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