funk-devel Mailing List for Funk
Status: Planning
Brought to you by:
awgh
Menu
▾
▴
funk-devel — List for funk developers.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
|
Nov
(1) |
Dec
|
|---|
|
From: Magnus T. <ma...@th...> - 2007-11-06 13:45:00
|
On Tue, Sep 25, 2007 at 13:56:56 -0400, Ben Kurtz wrote: >Hello! > >Unfortunately the SVN is currently in a bad state. Elf has been moving >from the original version of the raw-sockets egg to the >new-and-improved version. > >He has assured me that he will be checking in the rest of the new egg >sometime today. The new egg will be called 'raw-sockets' as well. > >What can you do in the meantime? > >Rather than patching the old raw-sockets, you can always install >raw-sockets via the chicken repository. We will only be submitting >known-good versions of our eggs to the chicken repository... > >Try "chicken-setup raw-sockets", it should work. > >Another, more important topic, is how to keep the SVN from being in a >bad state. > >I have been (and will continue to be) very open with handing out SVN >accounts. I would ask everyone with commit to please make sure that >the Makefiles still work at a minimum before checking anything in. > >I will be adding a basic test script in the near future, and will be >automating more testing and validation as we go. I've finally found the time to have a second look at funk. Using $CHICKEN_REPOSITORY I managed to install the dependencies without polluting any system directories. Then I put together the patch I've attached. Besides making better use of autoconf/automake this patch also makes funk buildable in a sub-directory. Something that's needed for `make distcheck` to succeed. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus |
|
From: Ben K. <bk...@al...> - 2007-09-28 16:19:16
|
Awesome! Thank you, I've been trying to work that out for a while!
- b
On 9/28/07, felix winkelmann <bun...@gm...> wrote:
>
> On 9/27/07, Ben Kurtz <bk...@al...> wrote:
> >
> > The issue isn't with "include" itself. The problem is how to include
> eggs
> > with source that will work from the interpreter or compiled.
> >
> > Of use/require/require-extension, I haven't found a method of using an
> egg
> > that will work compiled and interpreted without changing code. The file
> > demo1.scm is an example of my workaround for compilation.
> >
>
> The usual approach is to split an egg into two parts: a compile-time
> part (installed in a .setup script, with a "(syntax)" property) and a
> run-time part (setup: "(require-at-runtime ...)" property). Doing a
> "require-extension" will load the compile-time part in both the
> interpreter and the compiler and you can here differentiate between
> the two cases via "(cond-expand (compiling ...) (else ...))".
> It sounds somewhat complicated but really isn't.
>
> Here a simple example:
>
> % cat foo.scm
> (cond-expand
> (compiling (print "compiled foo."))
> (else (print "interpreted foo.")))
> % cat foo-base.scm
> (print "foo base is executing.")
> % cat foo.setup
> (compile -s foo-base.scm)
> (install-extension
> 'foo
> '("foo.scm" "foo-base.so")
> '((syntax)
> (require-at-runtime foo-base)))
> % cat x.scm
> (require-extension foo)
> % chicken-setup foo
> /home/fwinkel/bin/csc -feature compiling-extension -s foo-base.scm
> cp -r foo.scm /home/fwinkel/lib/chicken/3/foo.scm
> chmod a+r /home/fwinkel/lib/chicken/3/foo.scm
> rm -fr /home/fwinkel/lib/chicken/3/foo-base.so
> cp -r foo-base.so /home/fwinkel/lib/chicken/3/foo-base.so
> chmod a+r /home/fwinkel/lib/chicken/3/foo-base.so
> chmod a+r /home/fwinkel/lib/chicken/3/foo.setup-info
> % csi -R foo -nqb
> interpreted foo.
> foo base is executing.
> % csc x.scm
> compiled foo.
> % x
> foo base is executing.
>
>
> cheers,
> felix
>
>
|
|
From: felix w. <bun...@gm...> - 2007-09-28 07:36:40
|
On 9/27/07, Ben Kurtz <bk...@al...> wrote:
>
> The issue isn't with "include" itself. The problem is how to include eggs
> with source that will work from the interpreter or compiled.
>
> Of use/require/require-extension, I haven't found a method of using an egg
> that will work compiled and interpreted without changing code. The file
> demo1.scm is an example of my workaround for compilation.
>
The usual approach is to split an egg into two parts: a compile-time
part (installed in a .setup script, with a "(syntax)" property) and a
run-time part (setup: "(require-at-runtime ...)" property). Doing a
"require-extension" will load the compile-time part in both the
interpreter and the compiler and you can here differentiate between
the two cases via "(cond-expand (compiling ...) (else ...))".
It sounds somewhat complicated but really isn't.
Here a simple example:
% cat foo.scm
(cond-expand
(compiling (print "compiled foo."))
(else (print "interpreted foo.")))
% cat foo-base.scm
(print "foo base is executing.")
% cat foo.setup
(compile -s foo-base.scm)
(install-extension
'foo
'("foo.scm" "foo-base.so")
'((syntax)
(require-at-runtime foo-base)))
% cat x.scm
(require-extension foo)
% chicken-setup foo
/home/fwinkel/bin/csc -feature compiling-extension -s foo-base.scm
cp -r foo.scm /home/fwinkel/lib/chicken/3/foo.scm
chmod a+r /home/fwinkel/lib/chicken/3/foo.scm
rm -fr /home/fwinkel/lib/chicken/3/foo-base.so
cp -r foo-base.so /home/fwinkel/lib/chicken/3/foo-base.so
chmod a+r /home/fwinkel/lib/chicken/3/foo-base.so
chmod a+r /home/fwinkel/lib/chicken/3/foo.setup-info
% csi -R foo -nqb
interpreted foo.
foo base is executing.
% csc x.scm
compiled foo.
% x
foo base is executing.
cheers,
felix
|
|
From: Ben K. <bk...@al...> - 2007-09-27 16:19:40
|
Sorry, I wasn't clear. The issue isn't with "include" itself. The problem is how to include eggs with source that will work from the interpreter or compiled. Of use/require/require-extension, I haven't found a method of using an egg that will work compiled and interpreted without changing code. The file demo1.scm is an example of my workaround for compilation. I haven't had any luck using cond-expand to load/use/require eggs. Does that make sense? Is there a way to do this? Thanks much! - b On 9/27/07, felix winkelmann <bun...@gm...> wrote: > > On 9/24/07, Ben Kurtz <bk...@al...> wrote: > > > > * I've been asked if there is any way to make sure that files are > included, > > and I don't know how to do this in a way that works in both compiled > mode > > and in the interpreter. My current dirty hack is to write files that > work > > in the interpreter, and then separate files (ala. demo1.scm ) that are > only > > for compilation. Does anyone have a better way of doing this in > Chicken? > > > > I'm not sure I understand completely: The "include" macro includes source > files, both in compiled and interpreted mode. If you want to have pieces > of code that are only for compiled mode, you can wrap them in > > (cond-expand > (compiled ...code for compilation...) > (else ...code for interpretation...) ) > > > cheers, > felix > > |
|
From: felix w. <bun...@gm...> - 2007-09-27 05:43:58
|
On 9/24/07, Ben Kurtz <bk...@al...> wrote: > > * I've been asked if there is any way to make sure that files are included, > and I don't know how to do this in a way that works in both compiled mode > and in the interpreter. My current dirty hack is to write files that work > in the interpreter, and then separate files (ala. demo1.scm ) that are only > for compilation. Does anyone have a better way of doing this in Chicken? > I'm not sure I understand completely: The "include" macro includes source files, both in compiled and interpreted mode. If you want to have pieces of code that are only for compiled mode, you can wrap them in (cond-expand (compiled ...code for compilation...) (else ...code for interpretation...) ) cheers, felix |
|
From: Ben K. <bk...@al...> - 2007-09-25 17:56:56
|
Hello! Unfortunately the SVN is currently in a bad state. Elf has been moving from the original version of the raw-sockets egg to the new-and-improved version. He has assured me that he will be checking in the rest of the new egg sometime today. The new egg will be called 'raw-sockets' as well. What can you do in the meantime? Rather than patching the old raw-sockets, you can always install raw-sockets via the chicken repository. We will only be submitting known-good versions of our eggs to the chicken repository... Try "chicken-setup raw-sockets", it should work. Another, more important topic, is how to keep the SVN from being in a bad state. I have been (and will continue to be) very open with handing out SVN accounts. I would ask everyone with commit to please make sure that the Makefiles still work at a minimum before checking anything in. I will be adding a basic test script in the near future, and will be automating more testing and validation as we go. Thanks much! - Ben Kurtz On 9/24/07, Magnus Therning <ma...@th...> wrote: > > I didn't make it to CCC, again, but looking through the presentation > funk stood out as something *really* cool. > > I just downloaded it from SVN and tried building it. I failed :( > > Here are some initial observations: > > - Several files in the SVN repo are automatically generated by > autotools. It's generally a bad thing to include those. It's better > to assume that people who want to build bleeding edge know how to run > 'autoreconf'. > > - There is a bit of a mixed use of automake and manual make files. > It'd probably improve accessibility to do one or the other. > > - The build fails since recent changes haven't been reflected in the > build structure (renaming of raw-sockets and introducing rawsock). > > I'd be happy to contribute a diff that removes the automatically > generated files. I might even find the time to remove the manually > written makefiles and replace them with automakefiles. > > I've attached a small patch for src/eggs/Makefile. Am I correct in my > assumptions there? > > In the meantime please check in the Makefile for rawsock. > > /M > > -- > Magnus Therning (OpenPGP: 0xAB4DFBA4) > magnus＠therning．org Jabber: magnus．therning＠gmail．com > http://therning.org/magnus > > C++ is history repeated as tragedy. Java is history repeated as farce. > -- Scott McKay > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Funk-devel mailing list > Fun...@li... > https://lists.sourceforge.net/lists/listinfo/funk-devel > > > |
|
From: Magnus T. <ma...@th...> - 2007-09-25 07:33:17
|
I didn't make it to CCC, again, but looking through the presentation funk stood out as something *really* cool. I just downloaded it from SVN and tried building it. I failed :( Here are some initial observations: - Several files in the SVN repo are automatically generated by autotools. It's generally a bad thing to include those. It's better to assume that people who want to build bleeding edge know how to run 'autoreconf'. - There is a bit of a mixed use of automake and manual make files. It'd probably improve accessibility to do one or the other. - The build fails since recent changes haven't been reflected in the build structure (renaming of raw-sockets and introducing rawsock). I'd be happy to contribute a diff that removes the automatically generated files. I might even find the time to remove the manually written makefiles and replace them with automakefiles. I've attached a small patch for src/eggs/Makefile. Am I correct in my assumptions there? In the meantime please check in the Makefile for rawsock. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus C++ is history repeated as tragedy. Java is history repeated as farce. -- Scott McKay |
|
From: Ben K. <bk...@al...> - 2007-09-24 17:53:28
|
-- Good evening, please do not attempt to adjust your reader, there is nothing wrong... -- I apologize for the delay, but I've been traveling and it was sunny outside. My sun-eschewing colleague Elf has been hard at work, however... He's completely refactored the raw-sockets egg, adding support for reading as well as writing to packet sockets and non-blocking I/O! This egg currently lives in src/eggs/rawsock, but will soon replace the original raw-sockets. Over the next few days, new code will be checked in, which will add support for SIGIO and signal handling to the raw-sockets egg. Once tested and working, this will complete the second phase of development. This means that the ability to read and respond to network events is very close at hand! Thank you Elf! ----- Where do we go from here? ----- Phase 1 was writing, Phase 2 was reading... So next is Phase 3: -- Query and Response - RFC -- We need a way of specifying certain packets that we want to respond to (a 'query') and then indicating what packets to generate and send as a response. Assume that the raw-sockets egg will handle the actual sending and receiving of packets, and that incoming packets will all come through a single point of control in the signal handler, a 'packet handler'. We need to answer the following questions: 1) How does a user specify a Query? 2) How can the protocol definitions be modified to make Query matching more efficient? 3) Should all Queries be compiled to allow to the packet handler to be more efficient? How? 4) What else needs to be added or changed in protocol definitions to allow the decomposition of packets as well? 5) How can the user specify a set of state transitions at once? I would like to provide an easy way of describing a state machine, where transitions occur on incoming packets matching a Query and the states correspond to generating traffic. I'm thinking the sequence would go something like this: 1) User specifies a function that generates some packets. 2) User writes a query that calls this function when it matches certain packets. 3) User starts the sniffer with his query, which triggers an implicit compilation of queries. 4) When one of the interfaces the sniffer is attached to receives a packet, it will invoke the packet handler. 5) The packet handler compares the compiled queries with the incoming packet and generates some kind of event on a match. 6) This event will trigger a state change in the state machine, which will transition to a new state, which is associated with the packet generating function. 7) Packet generating function is called with input packet as argument, GOTO STEP 4. There are any number of problems with this, but I think this can be made to work, and I believe the benefits to be insanely great. So... What do you all think of this? Do you have better ideas for this design? Do you have any idea of how to implement parts of this in Chicken? I believe that the Query and Protocol definitions would be greatly simplified with macros... Any thoughts? --- Other Thoughts --- * We've opted not to use libpcap in any shape or form, although I'm still planning to support PCAP capture and playback. * I've been asked if there is any way to make sure that files are included, and I don't know how to do this in a way that works in both compiled mode and in the interpreter. My current dirty hack is to write files that work in the interpreter, and then separate files (ala. demo1.scm ) that are only for compilation. Does anyone have a better way of doing this in Chicken? * Protocol Development Stalled - We're currently revisiting the format of the protocol descriptions, to ensure that they will work with Query/Response. Until we have a better idea of if and how these formats will be changed, we're not doing too much in the way of protocol development. That is left until Phase 4, loosely titled "Write a bunch of protocols and demos". Thanks to all of you for your input! - Ben Kurtz |