Re: [Chicken-users] macro and module question from newbie.
Hi, You must indicate that `m` should be visible within the expansion of `bar`, using the following export format: (module foo ((bar m)) ...) Otherwise, everything looks fine. See the IDENTIFIER syntax under http://wiki.call-cc.org/man/4/Modules#module for more information. Cheers, Evan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] macro and module question from newbie.
hello, I'm chicken/scheme newbie. I'm long time use CommonLisp. but I feel difference with scheme. I writing first test program. but (module foo (bar) (import chicken scheme) (define m 10) (define-syntax bar (ir-macro-transformer (lambda (expr a b) `(+ m ,@(cdr expr)) (import foo) (bar (+ 10 20)) I got Error: unbound variable: m I want result 40. If export with 'm' ..it works. but I'm not want export variable 'm'. plz help me! ___ 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
[Chicken-users] [TFPIE 2015] 2nd call for papers
Trends in Functional Programming in Education (TFPIE 2015) 2nd Call for papers https://wiki.science.ru.nl/tfpie/TFPIE2015 The 4th International Workshop on Trends in Functional Programming in Education, TFPIE 2015, will be held on June 2, 2015 in Sophia-Antipolis in France. It is co-located with the Symposium on Trends in Functional Programming (TFP 2015) which takes place from June 3 - 5. *** Goal *** The goal of TFPIE is to gather researchers, teachers and professionals that use, or are interested in the use of, functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas and work-in-progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. The program chair of TFPIE 2015 will screen submissions to ensure that all presentations are within scope and are of interest to participants. Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website/wiki. Visitors to the TFPIE 2015 website/wiki will be able to add comments. This includes presenters who may respond to comments and questions as well as provide pointers to improvements and follow-up work. After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles for publication in the journal Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. TFPIE workshops have previously been held in St Andrews, Scotland (2012), Provo Utah, USA (2013), and Soesterberg, The Netherlands (2014). *** Program Committee *** Peter Achten, Radboud University Nijmegen, The Netherlands Edwin Brady, University of St Andrews, UK Johan Jeuring, Utrecht University and Open University, The Netherlands (Chair) Shriram Krishnamurthi, Brown University, US Rita Loogen, Philipps-Universität Marburg, Germany Marco Morazan, Seton Hall University, US Norman Ramsey, Tufts University, US *** Submission Guidelines *** TFPIE 2015 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: - FP and beginning CS students - FP and Computational Thinking - FP and Artificial Intelligence - FP in Robotics - FP and Music - Advanced FP for undergraduates - Tools supporting learning FP - FP in graduate education - Engaging students in research using FP - FP in Programming Languages - FP in the high school curriculum - FP as a stepping stone to other CS topics - FP and Philosophy *** Best Lectures *** In addition to papers, we request “best lecture” presentations. What is your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. *** Submission *** Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2015 It is expected at at least one author for each submitted paper will attend the workshop. *** Important Dates *** April 7, 2015: Early Registration for TFP closes April 27, 2015: Submission deadline for draft TFPIE papers and abstracts May 3 2015: Notification of acceptance for presentation ?? (Probably May 22 2015): Registration for TFPIE closes - as does late registration for TFP June 2, 2015: Presentations in Sophia-Antipolis, France July 7, 2015: Full papers for EPTCS proceedings due. September 1, 2015: Notification of acceptance for proceedings September 22, 2015: Camera ready copy due for EPTCS Submission of an abstract implies no obligation to submit a full version; abstracts with no corresponding full versions by the full paper deadline will be considered as withdrawn. ___ 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
