- Pharo-users - lists.pharo.org

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

Re: [Pharo-users] About Zinc http components

by itlists＠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] About Zinc http components

by 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. 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 Paul DeBruicker

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] Glorp + NBSQLite3

by Esteban A. Maringolo

More reasons to consider SQLite as solid option: 50% faster than 3.7.17 The latest SQLite 3.8.7 alpha version (available on the download page http://www.sqlite.org/download.html) is 50% faster than the 3.7.17 release from 16 months ago. That is to say, it does 50% more work using the same number of CPU cycles. http://permalink.gmane.org/gmane.comp.db.sqlite.general/90549 Regards, -- Esteban.

Oct. 7, 2014

Smalltalks 2014 Pharo Attendants (Meeting/Sprint?)

by Esteban A. Maringolo

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 itlists＠schrievkrom.de

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

Oct. 7, 2014