-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1> Tom, > Have you considered using glibc? This would address your speed issues, > and possibly allow embedded systems to compile with uclibc.What about flex,bison,C/C++ for the compiler? Regards Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4ASXZzAxnGuSmZcRAnTqAJ4wRTAlXJZfLRRGTyWo7RSfa7meZACeJ4kb qsvlPvZSXKnTPQfUKQ3gvRM=lA19 -----END PGP SIGNATURE----- ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Saturday 24 February 2007 09:25, Christian Roessner wrote:> > Tom, > > Have you considered using glibc? This would address your speed issues, > > and possibly allow embedded systems to compile with uclibc. > > What about flex,bison,C/C++ for the compiler?I wanted to bring Tom some positive comments on his actual questions, but at the risk of just popping up when the bike-sheds need painting, he''s already looking at Perl, and I believe Perl 6 will have a native compiler as well as a bytecode interpreter. So (depending on memory footprint of course) a Perl solution need not be locked out of embedded systems. It could also make it easy to produce an OO type solution (leaving aside arguments whether Perl is really OO, at least it does an imitation!) I like the idea of lex/yacc (well I would as it was my own first introduction to Unix tools, 20 years ago, and I used to be quite good with them). I''d be more than willing to dredge up my memory and help if I can. I wonder if yacc could even be used to generate the current rules more efficiently, by feeding the flatfiles into a yacc-generated parser ? It''s line-input rather than block-structured input but I think it can cope. I''ll think more on that, might even have a play - but have recently had a bust-up with my own management at work and I''m really short on concentration at the moment ;-( It''s not a very radical change though, so maybe won''t be what you need to solve the problems you mentioned. Tom I don''t know how to answer the things you asked directly, as I am still a very happy Shorewall user with simple needs. It is admittedly slow to start on my K6/2-500 firewall but it needs restarting so rarely that it''s fine for me. Shorewall really does make iptables simple, and I think that is the key point we need to remember as we work through your proposals. Many thanks for all your work over the years, and I hope I can help you with the approach you choose. Nick ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Sat, 2007-02-24 at 04:55, Nick Leverton wrote:> On Saturday 24 February 2007 09:25, Christian Roessner wrote: > > > Tom, > > > Have you considered using glibc? This would address your speed issues, > > > and possibly allow embedded systems to compile with uclibc. > > > > What about flex,bison,C/C++ for the compiler? > > I wanted to bring Tom some positive comments on his actual questions, but > at the risk of just popping up when the bike-sheds need painting, he''s > already looking at Perl, and I believe Perl 6 will have a native compiler > as well as a bytecode interpreter. So (depending on memory footprint of > course) a Perl solution need not be locked out of embedded systems.Nick, That was my concern, and the reason for my suggestion. If perl has a native complier, it may work in embedded network appliances. -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Sat, 2007-02-24 at 04:55, Nick Leverton wrote:> On Saturday 24 February 2007 09:25, Christian Roessner wrote: > > > Tom, > > > Have you considered using glibc? This would address your speed issues, > > > and possibly allow embedded systems to compile with uclibc. > > > > What about flex,bison,C/C++ for the compiler? > > I wanted to bring Tom some positive comments on his actual questions, but > at the risk of just popping up when the bike-sheds need painting, he''s > already looking at Perl, and I believe Perl 6 will have a native compiler > as well as a bytecode interpreter. So (depending on memory footprint of > course) a Perl solution need not be locked out of embedded systems.Nick,>From what I''m able to determine it''s in alpha. It looks like it allowswriting in perl and execution in c. I wonder if the generated code will compile with uclibc. Interesting stuff. :-) http://www.perl.com/doc/FMTEYEWTK/comp-vs-interp.html Another code-generator that produces compilable C code, except that this one doesn''t just trace the steps the interpreter would have followed, but actually produces optimized code (for example, it would work with raw integers directly rather than calling the interpreter calls that would have done so). If your code makes use of any dynamically-loaded modules (like POSIX, Socket, Fcntl, FileHandle, etc.), then you must keep those modules'' binary forms (POSIX.so, Socket.so, etc) around so they can be found when your executable gets run. Both backends one and two alleviate the need to store the original, pre-compiled source code anywhere. Backends two and three alleviate the need to keep the old PP interpreter lying about. Backend number three is the only one which is going to speed up execution time when compared with the old PP interpreter. -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Sat, 2007-02-24 at 07:13, Mike Noyes wrote:> >From what I''m able to determine it''s in alpha.Correction, It looks like it didn''t make the feature cut. :-( http://dev.perl.org/perl6/faq.html In the foreseeable future all Perl 6 programs will require the resources of the Parrot engine.> It looks like it allows writing in perl and execution in c. I wonder if > the generated code will compile with uclibc. Interesting stuff. :-) > > > http://www.perl.com/doc/FMTEYEWTK/comp-vs-interp.html > Another code-generator that produces compilable C code, except > that this one doesn''t just trace the steps the interpreter would > have followed, but actually produces optimized code (for > example, it would work with raw integers directly rather than > calling the interpreter calls that would have done so). > > If your code makes use of any dynamically-loaded modules (like > POSIX, Socket, Fcntl, FileHandle, etc.), then you must keep > those modules'' binary forms (POSIX.so, Socket.so, etc) around so > they can be found when your executable gets run. Both backends > one and two alleviate the need to store the original, > pre-compiled source code anywhere. Backends two and three > alleviate the need to keep the old PP interpreter lying about. > Backend number three is the only one which is going to speed up > execution time when compared with the old PP interpreter.-- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Nick Leverton wrote:> > I wanted to bring Tom some positive comments on his actual questions, but > at the risk of just popping up when the bike-sheds need painting, he''s > already looking at Perl, and I believe Perl 6 will have a native compiler > as well as a bytecode interpreter. So (depending on memory footprint of > course) a Perl solution need not be locked out of embedded systems. It > could also make it easy to produce an OO type solution (leaving aside > arguments whether Perl is really OO, at least it does an imitation!)As Mike pointed out in a later post, it looks like the interpreter will be required for the foreseeable future. The Perl experimentation I''ve been involved in so far is definitely not OO.> > I like the idea of lex/yacc (well I would as it was my own first > introduction to Unix tools, 20 years ago, and I used to be quite good with > them). I''d be more than willing to dredge up my memory and help if I can. > I wonder if yacc could even be used to generate the current rules more > efficiently, by feeding the flatfiles into a yacc-generated parser ? It''s > line-input rather than block-structured input but I think it can cope. > I''ll think more on that, might even have a play - but have recently had a > bust-up with my own management at work and I''m really short on > concentration at the moment ;-( It''s not a very radical change though, so > maybe won''t be what you need to solve the problems you mentioned.In my earlier response to Mike, I talked a bit about the notion of using C/C++ (which would include lex/Bison/yacc).> > Tom I don''t know how to answer the things you asked directly, as I am still > a very happy Shorewall user with simple needs. It is admittedly slow to > start on my K6/2-500 firewall but it needs restarting so rarely that it''s > fine for me. Shorewall really does make iptables simple, and I think that > is the key point we need to remember as we work through your proposals. > Many thanks for all your work over the years, and I hope I can help you > with the approach you choose.That''s a good point -- we don''t want to "through out the baby with the bath water". Thanks, Nick. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net''s Techsay panel and you''ll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV