(I thought I already responded , and rereading all just saw I did not, I
think I did enregistrer and closed no send, sorry)
Thank you for the update, I 'll have a look at that too.
It does not goes exactly the same way I will, and the slideshare
presentation looks a bit scary ... Die socket Die
Le 11/10/2014 13:44, Alain Rastoul a écrit :
One missing (but probably important precision if you try it) I forgot:
the workspaces are executed in two different pharo processes (vm) of course.
Hi Phil,
Yes, multi core support and communication is important, having that in
pharo could be great.
Hi Phil,
Yes, multi core support and communication is important, having that in
pharo could be great.
Unfortunately, no I actually have no usable project for that, mine is not
a communication project and still really in pre-alpha stage.
For now, I'm starting with Zinc, 0mq is just from a pros
Alain,
Yes, 0mq seems to be a good way to go as there is just more support across
the board.
Have you a project on Smalltalkhub (or elsewhere) with your experiments so
that I could have a look?
I've updated the 0MQ bindings page to list the smalltalkhub pharo client
and also had a look at what w
You are lucky that you hate windoom sometimes, I hate it all the time :D
Yes as I said I am very happy so far with StreamSockets and I have found
ways to minimise the socket communications so that the user don't
experience any noticeable lag so I don't currently need either 0mq or
nanomsg. So its
Hi Kilon,
I wanted to make some experiments with Nanomsg this morning, but had
some problems to build the libraries (they is no prebuilt binaries for
windows):
I discovered that the system path of my os
has been scratched by some recent mercurial installation,
the user path scratched by delphi
Hi Marten,
I took the 0mq binding of Panu on SmalltalkHub and
it worked out of the box for the simple hello world c client/server sample
translated to pharo, slightly modified to send/receive 8k byte arrays.
What I saw in this experiment is that
the reader process (a pharo vm) was 100% cpu bound
Nick Papoulias developed Seamless because he could not fix rST (but he
oversold Seamless a bit) and I asked him to
do a pass on Seamless and write a documentation.
Stef
On 7/10/14 23:08, Alain Rastoul wrote:
This is another subject and another functionality I will need too.
The Rst link is
It would be really interesting to get a binding for Pharo.
Stef
On 7/10/14 23:51, kilon alios wrote:
nope but it is made (unlike 0mq which is made in C++) in C so its
should be relative simple to wrap with NB or even TalkFFI. At least
the parts that interest you.
On Tue, Oct 7, 2014 at 11:5
Exactly, for this part it's all about bytes on a wire :) : just
sending/receiving serialized objects over a stream socket:
consumers will be pulling data from producers
in a synchronous way.
I could use a simple stream socket for that, but I want
to wrap data in messages to keep control over that
On Thu, Oct 09, 2014 at 11:38:47PM +0200, Alain Rastoul wrote:
> but for now, I prefer simpler and cleaner way - like smalltalk - to
> do just what I want - it's more a matter of taste).
Whether using Zinc's websockets or some C library wrapper, you are still
slinging serialized Smalltalk objects
I am interested too, my project depends on streamsocket to send python
commands from pharo to blender . So far I have not stressed it too much and
it looks like it works fast enough. Maybe something like websockets or
nanomsg is better for me in the long run so I too keep an eye on these
solutions.
Le 09/10/2014 14:14, kilon alios a écrit :
I am almost always right.
Good medicine :)
maybe ask the original author/s via github ? Why do things the hard way ;)
Yes may be I will after having looked closely at the source,
no hard way here, it's not a problem to read c or c++ code,
just a l
I am almost always right.
maybe ask the original author/s via github ? Why do things the hard way ;)
On Wed, Oct 8, 2014 at 8:54 AM, Alain Rastoul wrote:
> You are both right.
> Question about nanomsg is the thread model (a big bonus of 0mq), which is
> not clear to me.
> they state: "...In nan
Sorry, I think I have screwed my tests, I wasn't able to reload it right now
(I think I was browsing the changeset while loading 0mq package in
another image).
There are missing references and lot of errors I will investigate later,
I have other works in progress, and this one is in my list lat
You are both right.
Question about nanomsg is the thread model (a big bonus of 0mq), which
is not clear to me.
they state: "...In nanomsg the objects are not tightly bound to
particular threads and thus these problems don't exist...", about some
thread related issues in 0mq.
I'll have to check
0MQ is defined by its exported C interface ...
Am 07.10.2014 um 23:51 schrieb kilon alios:
> nope but it is made (unlike 0mq which is made in C++) in C so its
> should be relative simple to wrap with NB or even TalkFFI. At least the
> parts that interest you.
>
--
Marten Feldtmann
I was try it many years ago with squeak. It was work great. I am sure it
should be not difficult to adobt it for latest pharo
08 окт. 2014 г. 1:09 пользователь "Alain Rastoul"
написал:
> This is another subject and another functionality I will need too.
>
> The Rst link is of interest (thank you
nope but it is made (unlike 0mq which is made in C++) in C so its should
be relative simple to wrap with NB or even TalkFFI. At least the parts that
interest you.
On Tue, Oct 7, 2014 at 11:56 PM, Alain Rastoul
wrote:
> Nanosg looks interesting too, thank you Kilon, I will look at it closer
> to
This is another subject and another functionality I will need too.
The Rst link is of interest (thank you Denis) , I was thinking
of sending command objects with Fuel as all images will have the same
classes and performance is not very important here.
I was able to load RST in Pharo3, but did n
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
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
mes
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 th
2014-10-07 16:19 GMT-03:00 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.
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 :
> 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 fo
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
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. Ma
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 wrote:
> Thanks you for your answers.
>
> 0mq looks great, but released with LGPL licence, and I don't like that (I
> don't
> u
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 3
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 an
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:
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
2014-10-07 4:59 GMT-03:00 Sven Van Caekenberghe :
> Hi Alain,
>
> Any network protocol between two processes has overhead, even the one you
> would write yourself. It does make sense to use something that already
> exists, uses open standards and is used and battle tested by others.
>
> There is
Hi Alain,
Any network protocol between two processes has overhead, even the one you would
write yourself. It does make sense to use something that already exists, uses
open standards and is used and battle tested by others.
There is a fundamental difference between HTTP and WebSockets: HTTP is
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 Byt
35 matches
Mail list logo
