Re: [Chicken-users] Updating the zmq egg
Just a thought; but does nanomsg interoperate nicely with protobuf?-DanSentfrommyBlackBerry10smartphone.From: Matt GusheeSent: Monday, March 9, 2015 11:35 AMTo: chicken-users@nongnu.orgSubject: Re: [Chicken-users] Updating the zmq eggFirst of all, thanks to all who responded - especially Thomas, for the extended code example.I think I may use nanomsg after all.On Mon, Mar 9, 2015 at 2:06 AM, Kristian Lein-Mathisen kristianl...@gmail.com wrote:The main reason I wanted to try nanomsg was that it offers Level-triggered Polling.This allows us to do thread-wait-for-i/oon a nanomsg-socket, waiting for a message while other Chicken threads are running. We couldn't solve this with zmq because the zmq_poll C call (just like all C calls) would block the Chicken world.So I discovered. And I'm not sure yet if this will affect my project - it's a great big experiment - but I think there's a significant chance of it.No final decision yet. But I did see that even though nanomsg doesn't appear to have a large community yet, it was created by one of the original 0MQ developers, and seems to have good reasons for existing.--Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Updating the zmq egg
I'd stick with zmq, particularly considering that you've already begun updating the egg. It also looks like it has a greater amount of community and developer support. -Dan Matt Gushee m...@gushee.net writes: On Thu, Mar 5, 2015 at 6:18 PM, Dan Leslie d...@ironoxide.ca wrote: You might want to consider the nanomsg egg, which doesn't appear to have a wiki page yet. https://github.com/Adellica/chicken-nanomsg Oh, great, yet another alternative to consider! :-/ Well, maybe. I've never heard of nanomsg before. Any idea how widely-used/well-supported it is? PS: I still think the future of the zmq egg should be addressed, even if I end up not using it. It doesn't seem very useful to have a library binding that is two major versions behind. Unless someone is using it in production, I'd say it should either be updated or withdrawn. Matt ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- -Dan Leslie ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Updating the zmq egg
Hello, folks-- I am developing a distributed application for which I would like to use ZeroMQ. I've discovered, however, that the zmq egg is unmaintained and very out of date (the egg is compatible with libzmq 2.x, while the current stable version of the C library is 4.05). The good news is that I was able to bring all the foreign type definitions and API calls up to date, and the code compiles. I don't know yet if its behavior is correct (in fact I know of one thing that is probably incorrect - see below). Anyway, I have several questions related to this. First of all, shall I take over maintainership of the egg? I'm not really the best person to do this kind of thing - I'm not really a C programmer, and have no real-world experience with ZeroMQ yet. But if there is no better-qualified person available, I'm willing to take on this task. If my plans work out, I expect to be using the egg for several years at least. Second, the egg documentation mentions that the egg has some known problems. Can Moritz or someone tell me what those problems are? Next, there are a couple of details of the code I'm wondering about. One of the significant API changes is in the 'zmq_send' and 'zmq_recv' functions. Both these functions now take a 'len' argument, representing the size of the message buffer. Their signatures are as follows: *int zmq_recv (void *socket, void *buf, size_t len, int flags);* *int zmq_send (void *socket, void *buf, size_t len, int flags);* Does a size_t argument require any special handling on the Chicken side? Or can I just treat it as a regular integer? Another issue with message length is whether there should be a default value. There is a Scheme function that generates a buffer for both sending and receiving functions. Its signature looks like this: *(initialize-message message #!optional data)* The DATA argument is provided when the buffer is used for sending, and not when it is used for receiving. When there is data, the buffer size - and the 'len' argument to 'zmq_send' is derived from the length of the data. The problem arises when receiving a message - when there is no data. For the time being I set the default value to 0 - but that clearly is not going to be a useful value. I suppose the best size for the message buffer would vary greatly according to what type of application you are building, but there has to be some sort of number. Can anyone suggest a reasonable default (the ZeroMQ API doc includes a usage example with a value of 256, but I have no idea how arbitrary that is). Or maybe there just shouldn't be a default, and INITIALIZE-MESSAGE should require a buffer length argument in cases where no data is provided. Any opinions about this? Finally, if I am going to maintain this egg I would like it to have a test suite. However, I'm somewhat at a loss as to how to test a networking library. Simple unit testing is not going to do much good. Any ideas about how to approach this? Thanks for any feedback, Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Updating the zmq egg
Hi, Evan-- On Thu, Mar 5, 2015 at 6:13 PM, Evan Hanson ev...@foldling.org wrote: Does a size_t argument require any special handling on the Chicken side? Or can I just treat it as a regular integer? A regular size_t, even: http://api.call-cc.org/doc/foreign/types/size_t Thanks, but I guess my question wasn't sufficiently clear. My updated code already has: *(foreign-lambda int zmq_recv socket message size_t int); and (foreign-lambda int zmq_send socket message size_t int)* What I was wondering is whether I need to take any special measures to ensure that the value being passed as a size_t is in the correct range. In this case, the 'len' argument is produced by calling (number-of-bytes data). I would be really surprised if that value ever exceed the int32 range, but I suppose that could theoretically happen. Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Updating the zmq egg
On Thu, Mar 5, 2015 at 6:18 PM, Dan Leslie d...@ironoxide.ca wrote: You might want to consider the nanomsg egg, which doesn't appear to have a wiki page yet. https://github.com/Adellica/chicken-nanomsg Oh, great, yet another alternative to consider! :-/ Well, maybe. I've never heard of nanomsg before. Any idea how widely-used/well-supported it is? PS: I still think the future of the zmq egg should be addressed, even if I end up not using it. It doesn't seem very useful to have a library binding that is two major versions behind. Unless someone is using it in production, I'd say it should either be updated or withdrawn. Matt ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Updating the zmq egg
You might want to consider the nanomsg egg, which doesn't appear to have a wiki page yet. https://github.com/Adellica/chicken-nanomsg -Dan Matt Gushee m...@gushee.net writes: Hello, folks-- I am developing a distributed application for which I would like to use ZeroMQ. I've discovered, however, that the zmq egg is unmaintained and very out of date (the egg is compatible with libzmq 2.x, while the current stable version of the C library is 4.05). The good news is that I was able to bring all the foreign type definitions and API calls up to date, and the code compiles. I don't know yet if its behavior is correct (in fact I know of one thing that is probably incorrect - see below). Anyway, I have several questions related to this. First of all, shall I take over maintainership of the egg? I'm not really the best person to do this kind of thing - I'm not really a C programmer, and have no real-world experience with ZeroMQ yet. But if there is no better-qualified person available, I'm willing to take on this task. If my plans work out, I expect to be using the egg for several years at least. Second, the egg documentation mentions that the egg has some known problems. Can Moritz or someone tell me what those problems are? Next, there are a couple of details of the code I'm wondering about. One of the significant API changes is in the 'zmq_send' and 'zmq_recv' functions. Both these functions now take a 'len' argument, representing the size of the message buffer. Their signatures are as follows: *int zmq_recv (void *socket, void *buf, size_t len, int flags);* *int zmq_send (void *socket, void *buf, size_t len, int flags);* Does a size_t argument require any special handling on the Chicken side? Or can I just treat it as a regular integer? Another issue with message length is whether there should be a default value. There is a Scheme function that generates a buffer for both sending and receiving functions. Its signature looks like this: *(initialize-message message #!optional data)* The DATA argument is provided when the buffer is used for sending, and not when it is used for receiving. When there is data, the buffer size - and the 'len' argument to 'zmq_send' is derived from the length of the data. The problem arises when receiving a message - when there is no data. For the time being I set the default value to 0 - but that clearly is not going to be a useful value. I suppose the best size for the message buffer would vary greatly according to what type of application you are building, but there has to be some sort of number. Can anyone suggest a reasonable default (the ZeroMQ API doc includes a usage example with a value of 256, but I have no idea how arbitrary that is). Or maybe there just shouldn't be a default, and INITIALIZE-MESSAGE should require a buffer length argument in cases where no data is provided. Any opinions about this? Finally, if I am going to maintain this egg I would like it to have a test suite. However, I'm somewhat at a loss as to how to test a networking library. Simple unit testing is not going to do much good. Any ideas about how to approach this? Thanks for any feedback, Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- -Dan Leslie ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Updating the zmq egg
On Thu, Mar 05, 2015 at 06:24:26PM -0700, Matt Gushee wrote: Thanks, but I guess my question wasn't sufficiently clear. My updated code already has: *(foreign-lambda int zmq_recv socket message size_t int); and (foreign-lambda int zmq_send socket message size_t int)* What I was wondering is whether I need to take any special measures to ensure that the value being passed as a size_t is in the correct range. In this case, the 'len' argument is produced by calling (number-of-bytes data). I would be really surprised if that value ever exceed the int32 range, but I suppose that could theoretically happen. It accepts a flonum, so if you exceed 32 bits, you can go all the way up to 52 bits without precision loss. If you need more bits, you'll get into trouble because the air gets too thin ;) I'm working on adding core bignum support to CHICKEN 5, which shall eliminate this problem and allow you to use arbitrarily large integers in the FFI as well. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
