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. Time will tell.
On Fri, Oct 10, 2014 at 12:38 AM, Alain Rastoul <alf.mmm....@gmail.com> wrote: > 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 little pain (for me) to write some (I did a lot, and even liked it > long time ago, > but for now, I prefer simpler and cleaner way - like smalltalk - to do > just what I want - it's more a matter of taste). > If I use this library they won't debug my code. In smalltalk with > ZnWebSocket, I could easily, > in c or c++ I could too but a bit harder - I'll have to rebuild libraries, > use an external debugguer and so on - not a big deal > but I don't like it much. > > On Wed, Oct 8, 2014 at 8:54 AM, Alain Rastoul >> <alf.mmm....@gmail.com >> <mailto:alf.mmm....@gmail.com>> 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 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 (with sources or more docs readings) if they are >> bound to an external thread. >> If they account for an external thread support, this is not possible >> with the current vm without writing some external C code (I could >> but I would not like). >> Le 08/10/2014 07:07, itli...@schrievkrom.de >> <mailto:itli...@schrievkrom.de> a écrit : >> >> 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. >> >> >> >> >> >> >> >> >> > > >
