* I don't want to maintain this
@ 2005-11-28 4:27 Bruce Korb
0 siblings, 0 replies; 11+ messages in thread
From: Bruce Korb @ 2005-11-28 4:27 UTC (permalink / raw)
Hi all,
The following function is disliked by me and disliked by Guile 1.7.
It is a PITA to maintain, but it is compulsory until there is equivalent
functionality available. It is crucially important that error messages
point to the source file where the problem lies.
More and more installations seem to have 1.7, but I still deal with 1.4.
So, I use stuff like SCM_ROCHARS, except that it has been completely
removed from the interface leaving me with hard errors. I've spent a
day and a half trying to fix this stuff and it is very resistant to
being fixed.
Grumble, grumble. Anyway, this belongs in your code. We argued about this
before and someone said, "well, you could do it in any of several ways,
so we won't do it at all." This function is entirely equivalent to
"scm_c_eval_string" except that error results show file name and line
number. This is "The Right Way" for the interface and "The Wrong Way"
for me. Can you please add this (or something similar) to your interface
and reinstate SCM_ROCHARS et al. please? Thank you.
Regards, Bruce
SCM
ag_scm_c_eval_string_from_file_line( tCC* pzExpr, tCC* pzFile, int line )
{
SCM port;
if (OPT_VALUE_TRACE >= TRACE_EVERYTHING) {
fprintf( pfTrace, "eval from file %s line %d:\n%s\n", pzFile, line,
pzExpr );
}
{
tSCC zEx[] = "eval-string-from-file-line";
SCM expr = scm_makfrom0str( pzExpr );
port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );
}
{
static SCM file = SCM_UNDEFINED;
scm_t_port* pt;
if ( (file == SCM_UNDEFINED)
|| (strcmp( SCM_CHARS( file ), pzFile ) != 0) )
file = scm_makfrom0str( pzFile );
pt = SCM_PTAB_ENTRY(port);
pt->line_number = line - 1;
pt->file_name = file;
}
{
SCM ans = SCM_UNSPECIFIED;
/* Read expressions from that port; ignore the values. */
for (;;) {
SCM form = scm_read( port );
if (SCM_EOF_OBJECT_P( form ))
break;
ans = scm_primitive_eval_x( form );
}
return ans;
}
}
P.S. Speaking of error messages:
$ autogen --trace=every --trace-out=trace.log -L../autoopts opts.def
ERROR: In procedure inexact?:
ERROR: Wrong type argument in position 1: #<unspecified>
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
Scheme evaluation error. AutoGen ABEND-ing in template
options on line 86
============== trace.log ====================
== See the entry for "options line 86", below.
== "suffix", "count", "dne" and "exist?" are all functions legally defined
== and this all works with Guile 1.6. If I *ONLY* had a clue about what
== was being said above ``In procedure inexact?:'' and
== ``#<unspecified>''. It is just so nebulous.
==
eval from file options line 19:
(define have-cb-procs (make-hash-table 31))
eval from file options line 20:
(define is-ext-cb-proc (make-hash-table 31))
eval from file options line 21:
(define cb-proc-name (make-hash-table 31))
eval from file options line 22:
(define test-proc-name (make-hash-table 31))
eval from file options line 23:
(define disable-name (make-hash-table 31))
eval from file options line 24:
(define disable-prefix (make-hash-table 31))
eval from file options line 25:
(define ifdef-ed (make-hash-table 31))
eval from file options line 26:
(define extract-fmt "\n/* extracted from %s near line %d */\n")
eval from file options line 28:
(setenv "SHELL" "/bin/sh")
Starting h template
EXPR ( B) in options at line 78
eval from file options line 78:
(dne " * " "/* ")
Text (11) in options at line 78
CASE ( 1) in options at line 82
eval from file options line 82:
(suffix)
CASE string `h' COMPARE_FULL matched `h'
EXPR ( B) in options at line 86
eval from file options line 86:
(if (not (exist? "flag.name"))
(error "No options have been defined" ))
(if (> (count "flag") 100)
(error (sprintf "%d options are too many - limit of 100"
(count "flag")) ))
eval from file autogen.c line 213:
(if (> (string-length shell-cleanup) 0) (shell shell-cleanup) )
-------------------------------------------------------
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* I don't want to maintain this
@ 2005-11-28 4:25 Bruce Korb
2005-11-29 8:16 ` Ludovic Courtès
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Bruce Korb @ 2005-11-28 4:25 UTC (permalink / raw)
Hi all,
The following function is disliked by me and disliked by Guile 1.7.
It is a PITA to maintain, but it is compulsory until there is equivalent
functionality available. It is crucially important that error messages
point to the source file where the problem lies.
More and more installations seem to have 1.7, but I still deal with 1.4.
So, I use stuff like SCM_ROCHARS, except that it has been completely
removed from the interface leaving me with hard errors. I've spent a
day and a half trying to fix this stuff and it is very resistant to
being fixed.
Grumble, grumble. Anyway, this belongs in your code. We argued about this
before and someone said, "well, you could do it in any of several ways,
so we won't do it at all." This function is entirely equivalent to
"scm_c_eval_string" except that error results show file name and line
number. This is "The Right Way" for the interface and "The Wrong Way"
for me. Can you please add this (or something similar) to your interface
and reinstate SCM_ROCHARS et al. please? Thank you.
Regards, Bruce
SCM
ag_scm_c_eval_string_from_file_line( tCC* pzExpr, tCC* pzFile, int line )
{
SCM port;
if (OPT_VALUE_TRACE >= TRACE_EVERYTHING) {
fprintf( pfTrace, "eval from file %s line %d:\n%s\n", pzFile, line,
pzExpr );
}
{
tSCC zEx[] = "eval-string-from-file-line";
SCM expr = scm_makfrom0str( pzExpr );
port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );
}
{
static SCM file = SCM_UNDEFINED;
scm_t_port* pt;
if ( (file == SCM_UNDEFINED)
|| (strcmp( SCM_CHARS( file ), pzFile ) != 0) )
file = scm_makfrom0str( pzFile );
pt = SCM_PTAB_ENTRY(port);
pt->line_number = line - 1;
pt->file_name = file;
}
{
SCM ans = SCM_UNSPECIFIED;
/* Read expressions from that port; ignore the values. */
for (;;) {
SCM form = scm_read( port );
if (SCM_EOF_OBJECT_P( form ))
break;
ans = scm_primitive_eval_x( form );
}
return ans;
}
}
P.S. Speaking of error messages:
$ autogen --trace=every --trace-out=trace.log -L../autoopts opts.def
ERROR: In procedure inexact?:
ERROR: Wrong type argument in position 1: #<unspecified>
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to suppress
this message.
Scheme evaluation error. AutoGen ABEND-ing in template
options on line 86
============== trace.log ====================
== See the entry for "options line 86", below.
== "suffix", "count", "dne" and "exist?" are all functions legally defined
== and this all works with Guile 1.6. If I *ONLY* had a clue about what
== was being said above ``In procedure inexact?:'' and
== ``#<unspecified>''. It is just so nebulous.
==
eval from file options line 19:
(define have-cb-procs (make-hash-table 31))
eval from file options line 20:
(define is-ext-cb-proc (make-hash-table 31))
eval from file options line 21:
(define cb-proc-name (make-hash-table 31))
eval from file options line 22:
(define test-proc-name (make-hash-table 31))
eval from file options line 23:
(define disable-name (make-hash-table 31))
eval from file options line 24:
(define disable-prefix (make-hash-table 31))
eval from file options line 25:
(define ifdef-ed (make-hash-table 31))
eval from file options line 26:
(define extract-fmt "\n/* extracted from %s near line %d */\n")
eval from file options line 28:
(setenv "SHELL" "/bin/sh")
Starting h template
EXPR ( B) in options at line 78
eval from file options line 78:
(dne " * " "/* ")
Text (11) in options at line 78
CASE ( 1) in options at line 82
eval from file options line 82:
(suffix)
CASE string `h' COMPARE_FULL matched `h'
EXPR ( B) in options at line 86
eval from file options line 86:
(if (not (exist? "flag.name"))
(error "No options have been defined" ))
(if (> (count "flag") 100)
(error (sprintf "%d options are too many - limit of 100"
(count "flag")) ))
eval from file autogen.c line 213:
(if (> (string-length shell-cleanup) 0) (shell shell-cleanup) )
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-11-28 4:25 Bruce Korb
@ 2005-11-29 8:16 ` Ludovic Courtès
2005-11-29 20:14 ` Bruce Korb
2005-12-01 0:30 ` Kevin Ryde
2005-12-01 0:38 ` Kevin Ryde
2 siblings, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2005-11-29 8:16 UTC (permalink / raw)
Cc: guile-devel
Hi,
Bruce Korb <bruce.korb@gmail.com> writes:
> Grumble, grumble. Anyway, this belongs in your code. We argued about this
> before and someone said, "well, you could do it in any of several ways,
> so we won't do it at all." This function is entirely equivalent to
> "scm_c_eval_string" except that error results show file name and line
> number.
Sorry if I'm just re-stating what you were already answered: Can't you
implement this as a small Scheme procedure? Something along the lines
of:
(read-enable 'positions)
(define (eval-from-file file)
(with-input-from-file file
(lambda ()
(let loop ((sexp (read))
(result #f))
(if (eof-object? sexp)
result
(begin
(format #t "evaluating `~a' from ~a:~a:~a~%"
sexp (port-filename (current-input-port))
(source-property sexp 'line)
(source-property sexp 'column))
(loop (read) (primitive-eval sexp))))))))
This would certainly be easier for you to maintain.
Thanks,
Ludovic.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-11-29 8:16 ` Ludovic Courtès
@ 2005-11-29 20:14 ` Bruce Korb
2005-11-30 8:39 ` Ludovic Courtès
0 siblings, 1 reply; 11+ messages in thread
From: Bruce Korb @ 2005-11-29 20:14 UTC (permalink / raw)
Cc: guile-devel
On Tuesday 29 November 2005 12:16 am, Ludovic Courtès wrote:
> Hi,
>
> Bruce Korb <bruce.korb@gmail.com> writes:
>
> > Grumble, grumble. Anyway, this belongs in your code. We argued about this
> > before and someone said, "well, you could do it in any of several ways,
> > so we won't do it at all." This function is entirely equivalent to
> > "scm_c_eval_string" except that error results show file name and line
> > number.
>
> Sorry if I'm just re-stating what you were already answered: Can't you
> implement this as a small Scheme procedure? Something along the lines
> of:
Hi Ludovic,
*I* certainly cannot. And I do not understand the usage of the "file"
argument. What I am doing is extracting Scheme code from an encompassing
template and handing it off for evaluation. My program is reading the
file, not Guile. When I hand off the the string for evaluation, I hand
it to that ugly thing that I do not want to maintain. I do this in
exactly the same way as one would with scm_c_eval_string, except I have
the additional parameters file name and line number. Perhaps I could
wrap my strings in something like this:
char* fmt =
"(read-enable 'positions)
(format #t \"evaluating `~a' from ~a:~a:~a~%%\"
sexp (port-filename (current-input-port))
(source-property sexp \"%s\")
(source-property sexp %d))
(begin
%s
)";
and use it thus:
sprintf( buf, fmt, filename, linenum, script );
result = scm_c_eval_string( buf );
Would that work?
Your help is _surely_ appreciated!! Thank you.
Kind regards, Bruce
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-11-29 20:14 ` Bruce Korb
@ 2005-11-30 8:39 ` Ludovic Courtès
2005-11-30 12:30 ` Bruce Korb
0 siblings, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2005-11-30 8:39 UTC (permalink / raw)
Cc: guile-devel
Hi Bruce,
Bruce Korb <bruce.korb@gmail.com> writes:
> *I* certainly cannot.
Do you mean that you don't *want* to, or that this is not possible?
The point is that writing Scheme code will always be easier than writing
C code, and maintaining it will be even more easier.
> And I do not understand the usage of the "file"
> argument. What I am doing is extracting Scheme code from an encompassing
> template and handing it off for evaluation. My program is reading the
> file, not Guile. When I hand off the the string for evaluation, I hand
> it to that ugly thing that I do not want to maintain. I do this in
> exactly the same way as one would with scm_c_eval_string, except I have
> the additional parameters file name and line number. Perhaps I could
> wrap my strings in something like this:
>
> char* fmt =
> "(read-enable 'positions)
> (format #t \"evaluating `~a' from ~a:~a:~a~%%\"
> sexp (port-filename (current-input-port))
> (source-property sexp \"%s\")
> (source-property sexp %d))
> (begin
> %s
> )";
>
> and use it thus:
>
> sprintf( buf, fmt, filename, linenum, script );
> result = scm_c_eval_string( buf );
>
> Would that work?
That might work, but that's "ugly". Are you evaluating reading a file
and evaluating it from C code?
Even if this is the case, nothing prevents you from writing your own
read/eval function in Scheme (along the lines of what I posted earlier)
and using it from C:
eval_proc = scm_c_eval_string ("eval-from-file");
result = scm_call_1 (eval_proc, scm_from_locale_string ("the-file.scm"));
Hope this helps,
Ludovic.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-11-30 8:39 ` Ludovic Courtès
@ 2005-11-30 12:30 ` Bruce Korb
2005-11-30 13:46 ` Ludovic Courtès
0 siblings, 1 reply; 11+ messages in thread
From: Bruce Korb @ 2005-11-30 12:30 UTC (permalink / raw)
Cc: guile-devel
On Wednesday 30 November 2005 12:39 am, Ludovic Courtès wrote:
> Hi Bruce,
>
> Bruce Korb <bruce.korb@gmail.com> writes:
>
> > *I* certainly cannot.
>
> Do you mean that you don't *want* to, or that this is not possible?
Well, okay, I don't find the stuff obvious. With effort, I'm sure
I could puzzle it out. I have never found Lisp to be inherently
"obvious".
> > char* fmt =
> > "(read-enable 'positions)
> > (format #t \"evaluating `~a' from ~a:~a:~a~%%\"
> > sexp (port-filename (current-input-port))
> > (source-property sexp \"%s\")
> > (source-property sexp %d))
> > (begin
> > %s
> > )";
> >
> > and use it thus:
> >
> > sprintf( buf, fmt, filename, linenum, script );
> > result = scm_c_eval_string( buf );
> >
> > Would that work?
>
> That might work, but that's "ugly". Are you evaluating reading a file
> and evaluating it from C code?
I extract the scheme code from a file. Now, I have a string in memory
and I want it eval-ed. If I was reading your suggestion correctly,
I would need to write that string to a real file. I want to avoid
that. I want to hand that string, from memory, to Guile and tell
Guile, "This string came from file XXX on line NNN." (That is what
the ag_scm_c_eval_string_from_file_line() does.)
> Even if this is the case, nothing prevents you from writing your own
> read/eval function in Scheme (along the lines of what I posted earlier)
> and using it from C:
>
> eval_proc = scm_c_eval_string ("eval-from-file");
> result = scm_call_1 (eval_proc, scm_from_locale_string ("the-file.scm"));
Or this?
SCM body = scm_from_locale_string (extracted_text);
SCM file = scm_from_locale_string (current_input_file);
SCM line = scm_from_<integer?> (line_num);
return scm_call_3 (eval_proc, body, file, line);
Obviously, ``eval-from-file'' has to be reformulated to eval "body" instead of
reading input from a file and it must set the file name and line number
from the passed in arguments, but something like this ought to be workable,
yes? Sorry for being dense, but just how to formulate the "eval-from-xxx" thing
isn't real obvious to me. Thank you for your help & patience. Regards, Bruce
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-11-30 12:30 ` Bruce Korb
@ 2005-11-30 13:46 ` Ludovic Courtès
2005-11-30 14:00 ` Bruce Korb
0 siblings, 1 reply; 11+ messages in thread
From: Ludovic Courtès @ 2005-11-30 13:46 UTC (permalink / raw)
Cc: guile-devel
Bruce Korb <bruce.korb@gmail.com> writes:
> Well, okay, I don't find the stuff obvious. With effort, I'm sure
> I could puzzle it out. I have never found Lisp to be inherently
> "obvious".
Oh, but things are different here: this is Scheme! ;-)
Just out of curiosity: why are you writing Scheme if you don't like it?
> I extract the scheme code from a file. Now, I have a string in memory
> and I want it eval-ed. If I was reading your suggestion correctly,
> I would need to write that string to a real file. I want to avoid
> that. I want to hand that string, from memory, to Guile and tell
> Guile, "This string came from file XXX on line NNN." (That is what
> the ag_scm_c_eval_string_from_file_line() does.)
While you're at reading Scheme code from a file, why not use Scheme
construct (be it from Scheme of C code) whose purpose are exactly that?
Consider the following excerpt:
(with-input-from-file "chbouib.scm"
read)
This will read a single balanced expression (S-exp) from "chbouib.scm"
and return it[0]. Additionally, Guile does something interesting: it
attaches to that returned S-exp information about its original location.
IOW, you can then use the source property API[1] with that S-exp to know
where it came from (file name, line number, etc.).
It seems to be exactly the kind of feature you are looking for, isn't
it? What you are describing (reading a file into memory, asking Guile
to evaluate its content as a string, adding location information to it)
is just what Guile's `read' already does.
Thanks,
Ludovic.
[0] http://www.gnu.org/software/guile/docs/guile-ref/Scheme-Read.html#Scheme%20Read
[1] http://www.gnu.org/software/guile/docs/guile-ref/Procedure-Properties.html#Procedure%20Properties
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-11-30 13:46 ` Ludovic Courtès
@ 2005-11-30 14:00 ` Bruce Korb
0 siblings, 0 replies; 11+ messages in thread
From: Bruce Korb @ 2005-11-30 14:00 UTC (permalink / raw)
Cc: guile-devel
On Wednesday 30 November 2005 05:46 am, Ludovic Courtès wrote:
> Bruce Korb <bruce.korb@gmail.com> writes:
>
> > Well, okay, I don't find the stuff obvious. With effort, I'm sure
> > I could puzzle it out. I have never found Lisp to be inherently
> > "obvious".
>
> Oh, but things are different here: this is Scheme! ;-)
Oh. That's right! It is _so_ different. ;)
> Just out of curiosity: why are you writing Scheme if you don't like it?
I needed an extension language for my templates. The Scheme/Guile/Lisp
code is embedded in my template and when my interpreter stumbles into
it, it collects the text and says, "here! You deal with this". (i.e.
it calls some variation on scm_c_eval_string()).
> While you're at reading Scheme code from a file, why not use Scheme
> construct (be it from Scheme of C code) whose purpose are exactly that?
> Consider the following excerpt:
>
> (with-input-from-file "chbouib.scm"
> read)
Because the file is mostly *NOT* scheme. There is just some
embedded scheme phrases. I mmap the text (private and read/write)
and parse its components. The Scheme pieces get passed to Guile.
I know the file name and line number where these pieces come from.
I want Guile error messages to reflect the file/line where these
things live. :)
Thanks again - Bruce
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-11-28 4:25 Bruce Korb
2005-11-29 8:16 ` Ludovic Courtès
@ 2005-12-01 0:30 ` Kevin Ryde
2005-12-01 0:38 ` Kevin Ryde
2 siblings, 0 replies; 11+ messages in thread
From: Kevin Ryde @ 2005-12-01 0:30 UTC (permalink / raw)
Cc: guile-devel
Bruce Korb <bruce.korb@gmail.com> writes:
>
> port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );
scm_open_input_string is probably easier.
> pt->line_number = line - 1;
> pt->file_name = file;
Maybe scm_set_port_line_x and scm_set_port_filename_x instead of
mucking about with the ptab structure.
Apart from that a string port sounds good to me (without actually
trying it :-).
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-11-28 4:25 Bruce Korb
2005-11-29 8:16 ` Ludovic Courtès
2005-12-01 0:30 ` Kevin Ryde
@ 2005-12-01 0:38 ` Kevin Ryde
2005-12-07 0:36 ` Marius Vollmer
2 siblings, 1 reply; 11+ messages in thread
From: Kevin Ryde @ 2005-12-01 0:38 UTC (permalink / raw)
Cc: guile-devel
Bruce Korb <bruce.korb@gmail.com> writes:
>
> ERROR: Wrong type argument in position 1: #<unspecified>
Ah, I see 1.7 now throws an error for a non-number argument to
inexact?, where 1.6 would accept anything.
Looks like a deliberate change "2003-11-19 Marius Vollmer", maybe he
can say what motivated it.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: I don't want to maintain this
2005-12-01 0:38 ` Kevin Ryde
@ 2005-12-07 0:36 ` Marius Vollmer
0 siblings, 0 replies; 11+ messages in thread
From: Marius Vollmer @ 2005-12-07 0:36 UTC (permalink / raw)
Cc: guile-devel
Kevin Ryde <user42@zip.com.au> writes:
> Bruce Korb <bruce.korb@gmail.com> writes:
>>
>> ERROR: Wrong type argument in position 1: #<unspecified>
>
> Ah, I see 1.7 now throws an error for a non-number argument to
> inexact?, where 1.6 would accept anything.
>
> Looks like a deliberate change "2003-11-19 Marius Vollmer", maybe he
> can say what motivated it.
The 1.7 behavior is what R5RS specifies.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-12-07 0:36 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-28 4:27 I don't want to maintain this Bruce Korb
-- strict thread matches above, loose matches on Subject: below --
2005-11-28 4:25 Bruce Korb
2005-11-29 8:16 ` Ludovic Courtès
2005-11-29 20:14 ` Bruce Korb
2005-11-30 8:39 ` Ludovic Courtès
2005-11-30 12:30 ` Bruce Korb
2005-11-30 13:46 ` Ludovic Courtès
2005-11-30 14:00 ` Bruce Korb
2005-12-01 0:30 ` Kevin Ryde
2005-12-01 0:38 ` Kevin Ryde
2005-12-07 0:36 ` Marius Vollmer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).