October 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

Nanosg looks interesting too, thank you Kilon, I will look at it closer too. Do you known some working bindings with pharo ? Alain Le 07/10/2014 21:12, kilon alios a Ã©crit : > there is nanomsg which is a rethinking on 0mq and from same developers, > its MIT licensed --> http://nanomsg.org/index.html > > On Tue, Oct 7, 2014 at 9:12 PM, Alain Rastoul > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> wrote: > > Thanks you for your answers. > > 0mq looks great, but released with LGPL licence, and I don't like > that (I don't > understand why there is also a GPL licence file in the distribution > ? - clearly a *noway*), > I prefer a full smalltalk implementation I can debug when things go > wrong. > I think latency and timing problems would be the same, no big > difference in performance. > BTW knowing about this library is cool and may be of some help (who > knows), > thank you Marten for the reference. > > I agree totally with you Sven about performance and standards. > And I also agree with you about reusing someone else's work ... > I don't like to reinvent the wheel, especially a good wheel when > mine would be worst, > I would if I were a wheel specialist - clearly not the case here. > > Much (if not all) of what I found on the web about WebSocket is > about a browser/server connection > and does not talk about use in a server/server connection, hence my > question. > But you answered it, and your answer is ok with my thoughts > (plus using Zn components is a breeze) > > Thanks again > > regards, > > Alain > Le 07/10/2014 18:26, Paul DeBruicker a Ã©crit : > > marten wrote > > There are some good C libraries out there, which are suitable to > connect programs with each other: a good example is 0MQ. > > Marten > > -- > Marten Feldtmann > > > > Hi Marten, > > > Is your 0mq library posted somewhere and MIT licensed? > > Thanks > > Paul > > > > -- > View this message in context: > http://forum.world.st/About-__Zinc-http-components-__tp4783071p4783223.html > <http://forum.world.st/About-Zinc-http-components-tp4783071p4783223.html> > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

About 0mq, to be honest, I missed the external thread part, and that's *very* interesting , for sure. I find the license part quite complicated, but rereading it, you are right, it should not be a problem (though still weird). My goal is not to build a server with a lot of connections, and no message queuing neither, but (for this part) a server with some basic and raw "streaming" functionality and quite few connections for a start - this functionality is not the core of the system, just a part of it, and I'm trying to find building blocks. I think I have to make some compatible api on top of whatever I choose (ZnWebSockets/0mq or nanomsg) to be able to change easily. Do you know some existing good bindings for this library that I could reuse? The one on gemstone/squeaksource3 (from you?) seems to be empty, one on smalltalkhub (panuw) that I was able to load correctly and was maintained until february 2014. Thanks Alain Le 07/10/2014 21:23, itlists(a)schrievkrom.de a Ã©crit : > 0MQ is not message queueing in the normal sense as known from all other > MQ tools/libraries. > > 0MQ is about networking in general ... and their introduction text with > all their examples is one of the best examples documentation I've ever > read in the area of practical networking. Even though one might not use > 0MQ one should read their views about putting network patterns together > to form a distributed network of software nodes (in different languages). > > For Smalltalk 0MQ is a wonderful library: > > -> because of the interactive character of Smalltalk you might run a 0MQ > node and still can inspect the whole traffic. That's a thing other > languages can dream of. > > -> due to the fact, that the whole communcation is done in an external > thread you simply win Smalltalk CPU time (which is always needed). > > > Marten > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by S Krish

Typical issue in the EJB world : Remote Beans / Local Beans , though on inter process it was remote beans with its full stack RMI marshalling / unmarshalling. But can we not exploit shared memory and efficient Event mechanism to make the two process coordinate, that should be lot more efficient than TCP - IP / but if that performance suffices it would be fine.. On Tue, Oct 7, 2014 at 4:40 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Hi, > I played a bit with ZnServer and other zinc components and have > a question I can't answer myself (googling a bit didn't help neither), > and I'm seeking for advice: does it makes sense to use a > ZnServer/ZnWebSocket > as a mechanism to transfer data between two pharo processes - in my case > 8k ByteArray blocks ? > Or is it a total non sense ? is it reliable ? > First tests looks good : 18k blocks / second (145 Mb/s) on a laptop > core i5 2.6Ghz. > > All comments and suggestions welcome > > Thanks in advance, > > Alain > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Esteban A. Maringolo

2014-10-07 16:19 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > Esteban, > > die mq in 0mq is misleading here because it is not a message queue. 0mq is called sockets on stereoids where you can plug communication channels with less overhead. It is more of an orchestration toolkit for distributed computing. I can see. Thank you. I overlooked it, It seems really cool! But certainly it is more low level than a "regular" MQ :) Regards!

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Denis Kudriashov

Hi. Why not use some kind of remote smalltalk like http://www.squeaksource.com/rST.html? 2014-10-07 3:10 GMT+04:00 Alain Rastoul <alf.mmm.cat(a)gmail.com>: > Hi, > I played a bit with ZnServer and other zinc components and have > a question I can't answer myself (googling a bit didn't help neither), > and I'm seeking for advice: does it makes sense to use a > ZnServer/ZnWebSocket > as a mechanism to transfer data between two pharo processes - in my case > 8k ByteArray blocks ? > Or is it a total non sense ? is it reliable ? > First tests looks good : 18k blocks / second (145 Mb/s) on a laptop > core i5 2.6Ghz. > > All comments and suggestions welcome > > Thanks in advance, > > Alain > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by itlists＠schrievkrom.de

0MQ is not message queueing in the normal sense as known from all other MQ tools/libraries. 0MQ is about networking in general ... and their introduction text with all their examples is one of the best examples documentation I've ever read in the area of practical networking. Even though one might not use 0MQ one should read their views about putting network patterns together to form a distributed network of software nodes (in different languages). For Smalltalk 0MQ is a wonderful library: -> because of the interactive character of Smalltalk you might run a 0MQ node and still can inspect the whole traffic. That's a thing other languages can dream of. -> due to the fact, that the whole communcation is done in an external thread you simply win Smalltalk CPU time (which is always needed). Marten

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Norbert Hartl

Esteban, die mq in 0mq is misleading here because it is not a message queue. 0mq is called sockets on stereoids where you can plug communication channels with less overhead. It is more of an orchestration toolkit for distributed computing. Norbert > Am 07.10.2014 um 20:54 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > > Marten, > > I keep a close eye to MQ based architectures, because somehow they > feel "the best way" to implement interprocess/service messaging. And > also because I always wanted to implement something based on message > queues, just for the sake of it. :) > > However I don't find them suitable for interactive bidirectional > communication, but instead as their name suggest, queues. Ideally for > asynchronous communication, a "fire and forget" way of messaging. > If you go by the MQ path Sven implemented STAMP [1], which can work > with RabbitMQ's adapter [2] > > Unless you have an evented/callback based subscription to a queue, the > polling and message consumption from the queue itself will consume > about similar CPU cycles. What you gain using MQ is that you can > offload computation to other "worker images". > > Regards! > > > [1] https://github.com/svenvc/docs/blob/master/neo/stamp.md > [2] http://www.rabbitmq.com/stomp.html > Esteban A. Maringolo > > > 2014-10-07 15:18 GMT-03:00 itlists(a)schrievkrom.de <itlists(a)schrievkrom.de>: >> I have a little different view. lpgl is no real problem for me - it may >> be used for non-open-soure stuff without problems. Therefore I see no >> real problems with that. >> >> The other thing is: speed. And here it might differ a lot. I had written >> a heavy communication server in Smalltalk and with about 30 clients the >> Smalltalk process was CPU bound. No way to go. >> >> Introducing 0MQ and put all communication to an external thread and >> Smalltalk can fly again. That's the difference. >> >> Marten >> >> Am 07.10.2014 um 20:12 schrieb Alain Rastoul: >>> Thanks you for your answers. >>> >>> 0mq looks great, but released with LGPL licence, and I don't like that >>> (I don't >>> understand why there is also a GPL licence file in the distribution ? - >>> clearly a *noway*), >>> I prefer a full smalltalk implementation I can debug when things go wrong. >>> I think latency and timing problems would be the same, no big difference >>> in performance. >>> BTW knowing about this library is cool and may be of some help (who knows), >>> thank you Marten for the reference. >>> >>> I agree totally with you Sven about performance and standards. >>> And I also agree with you about reusing someone else's work ... >>> I don't like to reinvent the wheel, especially a good wheel when mine >>> would be worst, >>> I would if I were a wheel specialist - clearly not the case here. >> >> >> -- >> Marten Feldtmann >> >

Oct. 7, 2014

Re: [Pharo-users] Smalltalks 2014 Pharo Attendants (Meeting/Sprint?)

by stepharo

I cannot travel because this year I promised to take care of the kids while my wife is preparing a difficult exam. So I hope to attend next year. Stef > Is anybody here going to 2014's edition of Smalltalks in Cordoba, Argentina? > > I saw Jannik listed in one of the talks, maybe anybody else is comming > and we can arrange a Pharo Sprint or similar (I've never been in a > Pharo sprint). > > Esteban A. Maringolo > > ps: If anybody is hesitating, Cordoba is a beautiful city, and once > you pay the air tickets, local expenditures are really cheap in terms > of foreign currency. > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by kilon alios

there is nanomsg which is a rethinking on 0mq and from same developers, its MIT licensed --> http://nanomsg.org/index.html On Tue, Oct 7, 2014 at 9:12 PM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Thanks you for your answers. > > 0mq looks great, but released with LGPL licence, and I don't like that (I > don't > understand why there is also a GPL licence file in the distribution ? - > clearly a *noway*), > I prefer a full smalltalk implementation I can debug when things go wrong. > I think latency and timing problems would be the same, no big difference > in performance. > BTW knowing about this library is cool and may be of some help (who knows), > thank you Marten for the reference. > > I agree totally with you Sven about performance and standards. > And I also agree with you about reusing someone else's work ... > I don't like to reinvent the wheel, especially a good wheel when mine > would be worst, > I would if I were a wheel specialist - clearly not the case here. > > Much (if not all) of what I found on the web about WebSocket is about a > browser/server connection > and does not talk about use in a server/server connection, hence my > question. > But you answered it, and your answer is ok with my thoughts > (plus using Zn components is a breeze) > > Thanks again > > regards, > > Alain > Le 07/10/2014 18:26, Paul DeBruicker a Ã©crit : > > marten wrote >> >>> There are some good C libraries out there, which are suitable to >>> connect programs with each other: a good example is 0MQ. >>> >>> Marten >>> >>> -- >>> Marten Feldtmann >>> >> >> >> Hi Marten, >> >> >> Is your 0mq library posted somewhere and MIT licensed? >> >> Thanks >> >> Paul >> >> >> >> -- >> View this message in context: http://forum.world.st/About- >> Zinc-http-components-tp4783071p4783223.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Esteban A. Maringolo

Marten, I keep a close eye to MQ based architectures, because somehow they feel "the best way" to implement interprocess/service messaging. And also because I always wanted to implement something based on message queues, just for the sake of it. :) However I don't find them suitable for interactive bidirectional communication, but instead as their name suggest, queues. Ideally for asynchronous communication, a "fire and forget" way of messaging. If you go by the MQ path Sven implemented STAMP [1], which can work with RabbitMQ's adapter [2] Unless you have an evented/callback based subscription to a queue, the polling and message consumption from the queue itself will consume about similar CPU cycles. What you gain using MQ is that you can offload computation to other "worker images". Regards! [1] https://github.com/svenvc/docs/blob/master/neo/stamp.md [2] http://www.rabbitmq.com/stomp.html Esteban A. Maringolo 2014-10-07 15:18 GMT-03:00 itlists(a)schrievkrom.de <itlists(a)schrievkrom.de>: > I have a little different view. lpgl is no real problem for me - it may > be used for non-open-soure stuff without problems. Therefore I see no > real problems with that. > > The other thing is: speed. And here it might differ a lot. I had written > a heavy communication server in Smalltalk and with about 30 clients the > Smalltalk process was CPU bound. No way to go. > > Introducing 0MQ and put all communication to an external thread and > Smalltalk can fly again. That's the difference. > > Marten > > Am 07.10.2014 um 20:12 schrieb Alain Rastoul: >> Thanks you for your answers. >> >> 0mq looks great, but released with LGPL licence, and I don't like that >> (I don't >> understand why there is also a GPL licence file in the distribution ? - >> clearly a *noway*), >> I prefer a full smalltalk implementation I can debug when things go wrong. >> I think latency and timing problems would be the same, no big difference >> in performance. >> BTW knowing about this library is cool and may be of some help (who knows), >> thank you Marten for the reference. >> >> I agree totally with you Sven about performance and standards. >> And I also agree with you about reusing someone else's work ... >> I don't like to reinvent the wheel, especially a good wheel when mine >> would be worst, >> I would if I were a wheel specialist - clearly not the case here. > > > -- > Marten Feldtmann >

Oct. 7, 2014