3 Mar 2011 14:23
3 Mar 2011 14:46
Re: Tcpdump and getopts
On Thursday 03 of March 2011 14:23:12 you wrote: > Tcpdump is a tcp proxy that gives a realtime hexdump of data sent both > ways=3D Your message got cut at that pointIn any case, there is already a rather popular tool named `tcpdump', so re- using this name may lead to poor discoverability via web search. =2D-=20 dexen deVries [[[=E2=86=93][=E2=86=92]]] 47. As Will Rogers would have said, "There is no such thing as a free=20 variable." (Alan Perlis, `Epigrams on Programming') -- -- UNSUBSCRIBE: mailto:picolisp@...?subject=Unsubscribe
3 Mar 2011 20:29
Re: Tcpdump and getopts
On Thu, Mar 3, 2011 at 2:46 PM, dexen deVries <dexen.devries@...> wrote: > Your message got cut at that point
4 Mar 2011 08:59
Re: Tcpdump and getopts
Hi meinbg,
> Let's see if this mail gets through:
Yes, perfectly.
> Tcphex is a tcp proxy that gives a realtime hexdump of data sent both ways.
> ...
> All comments appreciated.
Thanks for your contribution! It looks like you did a really good job!
Perhaps you might also want to publish it in the PicoLisp google code
repository?
I must confess that I didn't analyze everything in detail, still allow
me to write some impressions and hints.
"tcphex"
I don't understand why that such a helper script is necessary. Don't
the mechanisms described e.g. in the "Scripting" chapter of the
tutorial work? If the PicoLisp script starts with
#!/usr/bin/picolisp /usr/lib/picolisp/lib.l
then no additional shell script would be required.
"getopts.l"
In a similar way, it seems to me that (getopts) is a little overkill.
But there are surely situations where it might be extremely useful.
(Continue reading)
4 Mar 2011 10:47
Check for repeating circular lists
Hi Alex, I noticed here <http://code.google.com/p/picolisp/updates/list> that you did an update re. "Check for repeating circular lists" the other day. Is a "repeating circular lists" a special case of a circular lists? If so, could you give an example of such a repeating circular lists? /Jon -- -- UNSUBSCRIBE: mailto:picolisp@...?subject=Unsubscribe
4 Mar 2011 11:11
Re: Check for repeating circular lists
Hi Jon, > you did an update re. "Check for repeating circular lists" the other > day. Is a "repeating circular lists" a special case of a circular > lists? If so, could you give an example of such a repeating circular > lists? Yes, it is a special case, for example (1 2 3 1 2 3 .) is a repeating circular list. In fact (= (1 2 3 1 2 3 .) (1 2 3 .)) returned 'T' in some cases. In certain aspects these two lists might indeed be considered "equal", but it seemed wrong to me. So I introduced an additional check. The current version returns 'NIL'. This additional check is done only in cases where circularity of the first (longer) list was detected, so it doesn't introduce any overhead for normal (non-circular) lists. Cheers, - Alex -- -- UNSUBSCRIBE: mailto:picolisp@...?subject=Unsubscribe
4 Mar 2011 15:45
Re: Tcpdump and getopts
On Fri, 4 Mar 2011 08:59:09 +0100 Alexander Burger <abu@...> wrote: > Hi meinbg, >=20 > > Let's see if this mail gets through: >=20 > Yes, perfectly. >=20 >=20 > > Tcphex is a tcp proxy that gives a realtime hexdump of data sent > > both ways. ... > > All comments appreciated. >=20 > Thanks for your contribution! It looks like you did a really good job! > Perhaps you might also want to publish it in the PicoLisp google code > repository? >=20 >=20 Hi Meinbg, I'm the current maintainer of the picolisp-addons repo at google code, if you want to put your tool in that repo drop me a line, I'll have to make some little modifications to accommodate for the directory structure and documentation :) (that may still change because we haven't set everything in stone) > [snip] Cheers, Jos=C3=A9 -- --(Continue reading)
5 Mar 2011 17:10
Re: Tcpdump and getopts
> > Perhaps you might also want to publish it in the PicoLisp google code > repository? > Sure, why not. "tcphex" > I don't understand why that such a helper script is necessary. It was a (perhaps foolish) attempt to handle the case of nonexistent symlinks to picolisp and lib.l. Also, since I know of no way of finding out the path of the file currently being executed from within picolisp, I made the helper script to find out the path of getopts.l. If there is a standard directory structure, it will not be needed. For now, I have included getopts in the main script and deleted the helper script. "getopts.l" > In a similar way, it seems to me that (getopts) is a little overkill. But there are surely situations where it might be extremely useful. The intention was to create something reusable in other scripts to make the tools more appealing to non-picolispers. Using recur/recurse instead of a loop is interesting. I suspect, > however, that using 'loop' or 'for' would also work. > Changed "(recur .. (when" to "(while". Line 91: (out 2 (prinl (pack (rest))))(Continue reading)
5 Mar 2011 17:17
Re: Tcpdump and getopts
> > Hi Meinbg, I'm the current maintainer of the picolisp-addons repo at > google code, if you want to put your tool in that repo drop me a line, > I'll have to make some little modifications to accommodate for the > directory structure and documentation :) (that may still change because > we haven't set everything in stone) Sure, go on. If you want to, you could move getopts to it's own file and (load ) it from tcphex.l, thereby making it possible to use getopts as a library. //meingbg
6 Mar 2011 09:02
Re: Tcpdump and getopts
On Sat, Mar 05, 2011 at 05:10:12PM +0100, meingbg wrote: > symlinks to picolisp and lib.l. Also, since I know of no way of finding out > the path of the file currently being executed from within picolisp, I made Does 'file' help in this case? Is suspect rather not. It returns the path name of the current input file, but this depends of course on how it was 'load'ed. > the helper script to find out the path of getopts.l. If there is a standard > directory structure, it will not be needed. For now, I have included getopts Yes. As Jose suggested, it could be accessible along the line of " <at> opt/.../getopts.l". > hex2 redefined. Perhaps the fact that (pad) also accepts symbols could be > clarified in the documentation? Indeed. The reference is wrong here, as it specifies just a 'num'. Cheers, - Alex -- -- UNSUBSCRIBE: mailto:picolisp@...?subject=Unsubscribe
RSS Feed