Subject: Re: request review: branch "wingo" - msg#00028

Previous Message by Date: click to view message preview

Re: Wide string strategies

> From: Ludovic Courtès <ludo@xxxxxxx> > Mike Gran writes: > > On Thu, 2009-04-09 at 22:25 +0200, Ludovic Courtès wrote: > Actually, for the file system interface, for instance, it's even > trickier: the encoding of file names usually isn't specified, but some > apps/libraries have their opinion on that, e.g., Glib > (http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html). > We should probably follow their lead here, but that's a secondary > problem anyway. True.  The one real standard that I do know is that NTFS requires UTF-8 filenames. > > > Also, the interaction between strings and sockets needs more thought. > > If sendto and recvfrom are used for datagram transmission, as it > > suggests in their docstrings, then locale string conversion could be a > > bad idea.  (And, these functions should also operate on u8vectors, but > > that's another issue.) > > Agreed. > > > To be more general, I know some apps depend on 8-bit strings and use > > them as storage of non-string binary data. > > Yes, notably because of `sendto' et al. that take a string. > > > I think SND falls into this > > category.  I wonder if ultimately wide strings would have to be a > > run-time option that is off by default.  But I am (choose your English > > idiom here) getting ahead of myself, or jumping the gun, or putting the > > cart before the horse. > > I don't have any idea of how we could usefully handle that. > > Eventually, it may be a good idea to deprecate `(sento "foobar")' in > favor of a variant that takes a bytevector or some such. Maybe its best to leave them unchanged w.r.t strings.  Any char values between 128 and 255 would just be interpreted as if they were UCS-4 characters 128 to 255 and get put in the strings directly. In the short term, socket functions could also be modified to take both strings and u8vectors.  Then, if someone was actually pushing UTF strings over the network, they could use "utf8-encoded-u8vector->string" or some such to do the conversion. And, in the long run, sockets can become a type of port, and those ports can have attached transcoding. > > >> > +SCM_INTERNAL int scm_i_string_ref_eq_int (SCM str, size_t x, int c); > >> > >> Does it assume sizeof (int) >= 32 ? > > > > I suppose it does.  But, I only used it to compare to the output of > > scm_getc which also returns an int. > > I meant, is the intent that C contains a codepoint? Yes.  And when wide strings are implemented, the gnulib convention is that a wide character is represented in C as uint32. > > >> > +SCM_INTERNAL char *scm_i_string_to_write_sz (SCM str); > >> > +SCM_INTERNAL scm_t_uint8 *scm_i_string_to_u8sz (SCM str); > >> > +SCM_INTERNAL SCM scm_i_string_from_u8sz (const scm_t_uint8 *str); > >> > +SCM_INTERNAL const char *scm_i_string_to_failsafe_ascii_sz (SCM str); > >> > +SCM_INTERNAL const char *scm_i_symbol_to_failsafe_ascii_sz (SCM str); > How about: > >   SCM scm_i_from_ascii_string (const scm_t_uint8 *str); > > and similar? OK. > >> > >> > +/* For ASCII strings, SUB can be used to represent an invalid > >> > +  character.  */ > >> > +#define SCM_SUB ('\x1A') > >> > >> Why SUB?  How about `SCM_I_SUB_CHAR', `SCM_I_INVALID_ASCII_CHAR' or > >> similar? > > > > If you're asking why SUB is set to 0x1A, the standard EMCA-48 says 0x1A > > should be used to indicate an invalid ASCII character. > > I suspected that.  Then `SCM_I_SUB_CHAR' may be a good name, perhaps > with a comment saying that this is the "official SUB character". > OK. Thanks, Mike

Next Message by Date: click to view message preview

Re: request review & testing: syncase

Andy Wingo <wingo@xxxxxxxxx> writes: > Hey folks, > > I've rebased the syncase branch on top of current master, and fixed > everything I know about. Now you can have macros in modules that expand > to references to identifiers that are local to the module that the macro > was defined in. > > I mean to say: > > (define-module (foo) > #:use-module (ice-9 syncase) > #:export (bar)) > > (define-syntax bar > (syntax-rules () > ((_ y) > (kar (frob y))))) > > (define kar car) > > (define-syntax frob > (syntax-rules () > ((_ y) > y))) > > (define-module (baz) > #:use-module (foo)) > > (bar '(a b c d)) > => a Cool. Does it work for defmacro and define-macro too? > Give it a look-see, a whirl, a what-have-you! I'd like to merge this one > in at some point within the next week or two. I'll wait for an OK from > Ludo or Neil before doing so, though. Thanks. Starting to review in detail now... Neil

Previous Message by Thread: click to view message preview

Re: request review: branch "wingo"

Howdy howdy, On Tue 31 Mar 2009 16:25, Neil Jerram <neil@xxxxxxxxxxxxxxxxx> writes: > - On the other hand, it does feel slightly incourteous, and the > argument about master being broken sounds like nonsense - because > everyone has their own local branches, and AFAIK there is never any > need to push those apart from for publication purposes. (Is there?) Yeah, my apologies. By way of explanation though perhaps not justification, I was getting to the point at work where I wanted to tell folks to add Guile to the autobuilding set of dependencies -- but I had to give them a pointer to a branch that worked, and preferred that that branch be `master'. Anyway. Apologies again, and hopefully we won't go through this again any time soon. >>> What's the idea of the numerical args? Should RLIMIT_XXX be defined >>> somewhere as Scheme-level integers? >> >> Uf, dunno. Now that I look at this again I'm not sure. We should >> probably just have RLIM_* and not the symbols, right? Easier for tab >> completion in any case... > > I personally like the symbols, but precedent (e.g. socket, bind etc.) > would favour just the integer constants. If the constants are also > better for completion, I guess that clinches it. :-) Yeah I guess so ;) I'll get to that soon, and document and add a NEWS entry. > I'm favouring 80% getrlimit now because I don't think Guile (and I) > have really benefitted from the time spent investigating stack > overflows recently, OK, so we are familiar in more detail with some > platforms using more stack than others, but that's not that > interesting and the time would probably have been better spent on > something else... so let's try not to have to do any more of this in > future. > > So my concern now is are there platforms that don't provide getrlimit > (or equivalent)? If not, I'm happy to rip out all the stack > calibration stuff; but if there are, don't we still need to keep it as > a fallback option? I went ahead and pushed an 80%-only patch, as you suggest. All UNIX systems that I know of have getrlimit. Windows does not of course, but it seems that their stack limit is hard-coded: http://www.mapleprimes.com/forum/stack_limit In any case, it seems that when Windows people bump up against this limit they'll let us know and we can send them looking for the right #define. >>> - fix "linking" of guile-config >>> >>> I don't understand the problem here. In what way was @bindir@ not >>> fully expanded? >> >> Because it was a make variable and not a shell variable, so it expanded >> to ${exec_prefix}/bin. (There was code in the Makefile.am before to sed >> in the variables at make-time instead of configure-time, but I had >> removed it to simplify things.) > > Should we then put the Makefile.am code back? Or does that break your > uninstalled usage? Other things being equal, I think it's more > important for the generated guile-config to be simple, than for our > Makefile.am to be simple. Perhaps we can just change guile-config to use pkg-config instead, as noted in the other thread. That will remove the need for the "linking" as the installed vs uninstalled case should be handled by pkg-config. Cheers, Andy -- http://wingolog.org/

Next Message by Thread: click to view message preview

master build failure on netbsd

my autobuild failed this morning: /bin/ksh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.. -I.. -I../lib -I../lib -I/usr/pkg/include -I/usr/pkg/include -pthread -Wall -Wmissing-prototypes -Werror -g -O2 -MT libguile_la-debug.lo -MD -MP -MF .deps/libguile_la-debug.Tpo -c -o libguile_la-debug.lo `test -f 'debug.c' || echo './'`debug.c gcc -DHAVE_CONFIG_H -I.. -I.. -I../lib -I../lib -I/usr/pkg/include -I/usr/pkg/include -pthread -Wall -Wmissing-prototypes -Werror -g -O2 -MT libguile_la-debug.lo -MD -MP -MF .deps/libguile_la-debug.Tpo -c debug.c -fPIC -DPIC -o .libs/libguile_la-debug.o cc1: warnings being treated as errors debug.c: In function 'init_stack_limit': debug.c:532: warning: comparison is always false due to limited range of data type debug.c:535: warning: comparison is always false due to limited range of data type gmake[3]: *** [libguile_la-debug.lo] Error 1 gmake[3]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/libguile' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile/libguile' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/gdt/BUILD-GUILE-master/guile' gmake: *** [all] Error 2 pgpPrEbkHBiQr.pgp Description: PGP signature