Re: Adding new information to scm_t_port (was Re: always O_BINARY?)

2013-03-05 Thread Mark H Weaver
Andy Wingo writes: > On Thu 28 Feb 2013 04:24, Mark H Weaver writes: > >> Instead of having 'input_cd' and 'output_cd' point directly to the >> platform's iconv_t structures, let's have them point to our own internal >> structure(s) that hold the needed transcoder state. This could include >> t

Re: Adding new information to scm_t_port (was Re: always O_BINARY?)

2013-03-01 Thread Ludovic Courtès
Andy Wingo skribis: > On Thu 28 Feb 2013 12:04, l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo skribis: >> >>> On Thu 28 Feb 2013 04:24, Mark H Weaver writes: >>> Instead of having 'input_cd' and 'output_cd' point directly to the platform's iconv_t structures, let's have them

Re: Adding new information to scm_t_port (was Re: always O_BINARY?)

2013-02-28 Thread Andy Wingo
On Thu 28 Feb 2013 12:04, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo skribis: > >> On Thu 28 Feb 2013 04:24, Mark H Weaver writes: >> >>> Instead of having 'input_cd' and 'output_cd' point directly to the >>> platform's iconv_t structures, let's have them point to our own internal >>> s

Re: Adding new information to scm_t_port (was Re: always O_BINARY?)

2013-02-28 Thread Ludovic Courtès
Andy Wingo skribis: > On Thu 28 Feb 2013 04:24, Mark H Weaver writes: > >> Instead of having 'input_cd' and 'output_cd' point directly to the >> platform's iconv_t structures, let's have them point to our own internal >> structure(s) that hold the needed transcoder state. This could include >>

Re: Adding new information to scm_t_port (was Re: always O_BINARY?)

2013-02-28 Thread Andy Wingo
On Thu 28 Feb 2013 04:24, Mark H Weaver writes: > Instead of having 'input_cd' and 'output_cd' point directly to the > platform's iconv_t structures, let's have them point to our own internal > structure(s) that hold the needed transcoder state. This could include > things like the state for int

Adding new information to scm_t_port (was Re: always O_BINARY?)

2013-02-27 Thread Mark H Weaver
l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo skribis: > >> The (newline) function can write CRLF >> The ~% format directive should DTRT >> read-line should DTRT > > IMO the correct abstraction here is transcoders à la R6RS. Agreed. > The problem is that scm_t_port doesn’t have any s

Re: always O_BINARY?

2013-02-24 Thread Ludovic Courtès
Hi! Andy Wingo skribis: > Just thinking aloud here -- Windows has this O_BINARY thing that > translates CRLF to LF when reading, and LF to CRLF when writing. It > seems to me to be a useless thing. We already have our own i/o > abstractions and should deal with CRLF vs LF in Scheme, I think:

Re: always O_BINARY?

2013-02-24 Thread Mike Gran
> From: Andy Wingo > So, what do you think about always adding O_BINARY to files that Guile > opens? Lilypond, Gnucash, Denemo, Autogen and Emacs all run on Windows to varying degrees. As does Gnome Games. If it doesn't break any of them, then it might be okay. In an ideal world, there would b

Re: always O_BINARY?

2013-02-24 Thread Neil Jerram
Andy Wingo writes: > Hi, > > Just thinking aloud here -- Windows has this O_BINARY thing that > translates CRLF to LF when reading, and LF to CRLF when writing. It > seems to me to be a useless thing. We already have our own i/o > abstractions and should deal with CRLF vs LF in Scheme, I think:

always O_BINARY?

2013-02-24 Thread Andy Wingo
Hi, Just thinking aloud here -- Windows has this O_BINARY thing that translates CRLF to LF when reading, and LF to CRLF when writing. It seems to me to be a useless thing. We already have our own i/o abstractions and should deal with CRLF vs LF in Scheme, I think: The (newline) function can w