Re: request tmpfile(3) wrapping in Guile 1.9 libguile

Re: request tmpfile(3) wrapping in Guile 1.9 libguile

[Andy Wingo]

On Tue 09 Feb 2010 10:07, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Andy Wingo <wingo@pobox.com>
> () Mon, 08 Feb 2010 12:11:17 +0100
>
>    I think this sounds like a good idea. I have a few concerns, though if
>    none of them can be nicely addressed I'd still be happy adding tmpfile.
>
> I'm happy to see Ken Raeburn answer these concerns.  Personally, i find it
> very nice to have an anonymous seekable chunk of filesystem to play
> with.

Yes, I think that's probably the right answer.

> BTW (veering off-topic, but you started it!)... i dislike `mkstemp!'.
> Its safe use requires `string-copy'.  Why not have all that handled
> automatically, including the "XXXXXX" suffixing?  That's what i do
> in Guile 1.4.x `mkstemp' (note, no "!").

Yes, this sounds better than mkstemp!. Since you seem to have to code
already, can you submit two patches with mkstemp and tempfile,
respectively?

While we're here... Ludovic, Neil and I talked over mail about your
request to (re)join the Guile project, and we're very happy to have your
skills and energy. The one concern that we have is that you tend to be a
bit cavalier; so until we feel like we're on the same page, we would
like for you to refrain from committing to master or the 1.8 branch.

Instead, please feel free to (commit to | create) other branches in the
repository, preferably prefixing those branches with "wip-" if you
intend them to be rebased at some point. Please mail the list when you
would like for us to review and merge your patches into master or 1.8.

I recognize that it's a somewhat awkward situation, but we're so
unfamiliar with each other at this point that a slow rapprochement would
probably be best to avoid unexpected conflicts.

That said, welcome back to Guile!

Cheers,

Andy
-- 
http://wingolog.org/

Re: request tmpfile(3) wrapping in Guile 1.9 libguile

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]


  That said, welcome back to Guile!

I'm really glad to hear this - we scheme weenies are few enough in this
world that we need to stick together!

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: request tmpfile(3) wrapping in Guile 1.9 libguile

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

() Andy Wingo <wingo@pobox.com>
() Wed, 10 Feb 2010 00:17:30 +0100

   Yes, I think that's probably the right answer.

On the (faint) suspicion that `scm_fdes_to_port' does not DTRT, given
the file descriptor extracted via `fileno' from the `FILE *', i ran a
small test:

 (write (getpid)) (newline)
 (define tmp (tmpfile))
 (sleep 10)
 (set! tmp #f) ; lose ref
 (let loop () (gc) (sleep 1) (loop))

and monitored using "watch lsof -p PID".  I observed that the descriptor
is listed as "/tmp/FILENAME (deleted)" from the beginning and that after
some time, this entry goes away.  So my trust in `scm_fdes_to_port' is
not broken (cool).  Still, i wonder what others see.

   Yes, this sounds better than mkstemp!. Since you seem to have to code
   already, can you submit two patches with mkstemp and tempfile,
   respectively?

I think you mean `tmpfile'.  Please see attached patch.

   While we're here... Ludovic, Neil and I talked over mail about your
   request to (re)join the Guile project, and we're very happy to have
   your skills and energy.  The one concern that we have is that you
   tend to be a bit cavalier; so until we feel like we're on the same
   page, we would like for you to refrain from committing to master or
   the 1.8 branch.

Thanks for the frank assessment.  I will try to be less cavalier (or
perhaps more "anti-cavalier", once i figure out what that means in this
context).  I appreciate any tips on this aspect.

   Instead, please feel free to (commit to | create) other branches in
   the repository, preferably prefixing those branches with "wip-" if
   you intend them to be rebased at some point.  Please mail the list
   when you would like for us to review and merge your patches into
   master or 1.8.

OK.  How do you feel about a branches named ttn/wip-TOPIC ?

   I recognize that it's a somewhat awkward situation, but we're so
   unfamiliar with each other at this point that a slow rapprochement
   would probably be best to avoid unexpected conflicts.

Agreed.

   That said, welcome back to Guile!

Thanks for giving me another chance.  Perhaps i can avoid squandering
the privelege as i did the previous time.

thi


____________________________________________________

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-tmpfile-3-to-libguile.patch --]
[-- Type: text/x-diff, Size: 3154 bytes --]

From 6f5612459b1e414c33b5a1814a5bec57eb81052e Mon Sep 17 00:00:00 2001
From: Thien-Thi Nguyen <ttn@gnuvola.org>
Date: Fri, 12 Feb 2010 16:01:16 +0100
Subject: [PATCH] Add tmpfile(3) to libguile.

* libguile/posix.c (sym_tmpfile): New symbol.
  (scm_tmpfile): New primitive.
* libguile/posix.h (scm_tmpfile): New func decl.

* doc/ref/posix.texi (File System): Document `tmpfile'.

Signed-off-by: Thien-Thi Nguyen <ttn@gnuvola.org>
---
 doc/ref/posix.texi |   14 ++++++++++++++
 libguile/posix.c   |   24 ++++++++++++++++++++++++
 libguile/posix.h   |    1 +
 3 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/doc/ref/posix.texi b/doc/ref/posix.texi
index 6ff7109..349dcbe 100644
--- a/doc/ref/posix.texi
+++ b/doc/ref/posix.texi
@@ -948,6 +948,20 @@ which is usual for ordinary file creation,
 @end example
 @end deffn
 
+@deffn {Scheme Procedure} tmpfile
+@deffnx {C Function} scm_tmpfile
+Return an input/output port to a unique temporary file
+named using the path prefix @code{P_tmpdir} defined in
+@file{stdio.h}.
+The file is automatically deleted when the port is closed
+or the program terminates.
+
+The name of the temporary file associated with the returned
+port is not available to Scheme programs;
+@code{(port-filename (tmpfile))} always returns the
+symbol @code{tmpfile}.
+@end deffn
+
 @deffn {Scheme Procedure} dirname filename
 @deffnx {C Function} scm_dirname (filename)
 Return the directory name component of the file name
diff --git a/libguile/posix.c b/libguile/posix.c
index 73921a2..363de8c 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -1373,6 +1373,30 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 0, 0,
 }
 #undef FUNC_NAME
 
+SCM_SYMBOL (sym_tmpfile, "tmpfile");
+
+SCM_DEFINE (scm_tmpfile, "tmpfile", 0, 0, 0,
+            (void),
+            "Return an input/output port to a unique temporary file\n"
+            "named using the path prefix @code{P_tmpdir} defined in\n"
+            "@file{stdio.h}.\n"
+            "The file is automatically deleted when the port is closed\n"
+            "or the program terminates.\n"
+            "\n"
+            "The name of the temporary file associated with the returned\n"
+            "port is not available to Scheme programs;\n"
+            "@code{(port-filename (tmpfile))} always returns the\n"
+            "symbol @code{tmpfile}.")
+#define FUNC_NAME s_scm_tmpfile
+{
+  FILE *rv;
+
+  if (! (rv = tmpfile ()))
+    SCM_SYSERROR;
+  return scm_fdes_to_port (fileno (rv), "w+", sym_tmpfile);
+}
+#undef FUNC_NAME
+
 SCM_DEFINE (scm_utime, "utime", 1, 5, 0,
             (SCM pathname, SCM actime, SCM modtime, SCM actimens, SCM modtimens,
              SCM flags),
diff --git a/libguile/posix.h b/libguile/posix.h
index 420311e..71c46f2 100644
--- a/libguile/posix.h
+++ b/libguile/posix.h
@@ -68,6 +68,7 @@ SCM_API SCM scm_uname (void);
 SCM_API SCM scm_environ (SCM env);
 SCM_API SCM scm_tmpnam (void);
 SCM_API SCM scm_mkstemp (SCM tmpl);
+SCM_API SCM scm_tmpfile (void);
 SCM_API SCM scm_open_pipe (SCM pipestr, SCM modes);
 SCM_API SCM scm_close_pipe (SCM port);
 SCM_API SCM scm_utime (SCM pathname, SCM actime, SCM modtime,
-- 
1.6.3.2

Re: request tmpfile(3) wrapping in Guile 1.9 libguile

[Andy Wingo]

Greets,

On Fri 12 Feb 2010 16:21, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

>  (write (getpid)) (newline)
>  (define tmp (tmpfile))
>  (sleep 10)
>  (set! tmp #f) ; lose ref
>  (let loop () (gc) (sleep 1) (loop))
>
> I observed that the descriptor is listed as "/tmp/FILENAME (deleted)"
> from the beginning and that after some time, this entry goes away. So
> my trust in `scm_fdes_to_port' is not broken (cool). Still, i wonder
> what others see.

I wonder as well; but if the API works as advertised, then the file must
be deleted, whether fclose(3) is called or not; so I guess this part of
things works out fine. If the FILE* is never written to then we don't
have buffering problems either.

>    Yes, this sounds better than mkstemp!. Since you seem to have to code
>    already, can you submit two patches with mkstemp and tempfile,
>    respectively?
>
> I think you mean `tmpfile'.  Please see attached patch.

Yes indeed, and thanks.

>    While we're here... Ludovic, Neil and I talked over mail about your
>    request to (re)join the Guile project, and we're very happy to have
>    your skills and energy.  The one concern that we have is that you
>    tend to be a bit cavalier; so until we feel like we're on the same
>    page, we would like for you to refrain from committing to master or
>    the 1.8 branch.
>
> Thanks for the frank assessment.  I will try to be less cavalier (or
> perhaps more "anti-cavalier", once i figure out what that means in this
> context).  I appreciate any tips on this aspect.
>
> [...]  How do you feel about a branches named ttn/wip-TOPIC ?

Thanks for understanding. I think ttn/wip-TOPIC is a fine convention.
I'm also fine with simply wip-TOPIC. But either way works for me.

Regarding our reservations / impedance mismatches, I think the best
thing for all would be for you to hack away as you see fit, commit to
branches, and we give feedback on the branches.

Happy hacking,

Andy
-- 
http://wingolog.org/

Re: request tmpfile(3) wrapping in Guile 1.9 libguile

[Thien-Thi Nguyen]

() Andy Wingo <wingo@pobox.com>
() Fri, 12 Feb 2010 21:48:20 +0100

   I wonder as well; but if the API works as advertised, then the
   file must be deleted, whether fclose(3) is called or not; so I
   guess this part of things works out fine.

If you s/file must be deleted/filename must be removed from the
directory listing/, then yes.

However, i do think that Guile MUST call fclose(3), so as to avoid
starving long-running processes that call tmpfile(3) many times of
file descriptors.  Unfortunately, i don't see a portable way of
verifying this (e.g., doing "watch lsof" depends on both watch(1)
and lsof(8)), otherwise i'd have included a test case.

   If the FILE* is never written to then we don't
   have buffering problems either.

Right.  We "faithfully maintain" the abstraction presented by the OS.
It's true that we could fool around w/ FILE* but that:
- is inelegant;
- creates more work (blech);
- breaks the "spirit" of the abstraction (as i see it).

   I think ttn/wip-TOPIC is a fine convention.  I'm also fine with
   simply wip-TOPIC.  But either way works for me.

   Regarding our reservations / impedance mismatches, I think the
   best thing for all would be for you to hack away as you see
   fit, commit to branches, and we give feedback on the branches.

OK, i will change my current MO from posting patches to updating
ttn/{wip-}foo branches plus signalling to the mailing list for review.
(I will continue to ask WDYT-type questions, in any case.)

I have some git-non-expert questions, too (this is the first
project in which i use "git push"), but i'll start another thread
for those.

thi

Re: request tmpfile(3) wrapping in Guile 1.9 libguile

[Andy Wingo]

On Sat 13 Feb 2010 12:15, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> OK, i will change my current MO from posting patches to updating
> ttn/{wip-}foo branches plus signalling to the mailing list for review.
> (I will continue to ask WDYT-type questions, in any case.)

Great!

Happy hacking,

Andy
-- 
http://wingolog.org/