From keithp at keithp.com Tue Oct 2 01:54:03 2007 From: keithp at keithp.com (Keith Packard) Date: Tue, 2 Oct 2007 01:54:03 -0700 (PDT) Subject: [Nickle] nickle: Branch 'master' - 3 commits Message-ID: <20071002085403.791D3114203@keithp.com> builtin-toplevel.c | 1 ctype.5c | 20 ++++++++----- file.c | 79 +++++++++++++++++++++++++++++------------------------ value.h | 1 4 files changed, 57 insertions(+), 44 deletions(-) New commits: commit 2278b93b7e760f1153847a0b3c36d07684f72e0c Author: Keith Packard Date: Tue Oct 2 01:53:02 2007 -0700 Manage file buffer chains with explicit malloc/free. Buffer chains must have life equal to the file they belong to; an unreferenced file may still have buffered data, so the buffers cannot be reclaimed. The nickle GC does not have a separate pass that checks to see which objects can be freed, rather it assumes that such objects are self-contained. Hence, anything hanging off of an object which can refuse to be reclaimed must not have been allocated from the nickle GC system. Yes, this is a significant limitation to this allocator. Someday I'll figure out a good general fix for this problem, right now we'll stop segfaults when applications drop file references without closing them. diff --git a/file.c b/file.c index 77356b1..933b544 100644 --- a/file.c +++ b/file.c @@ -472,6 +472,30 @@ ProcessInterrupt () } } +static FileChainPtr +FileChainAlloc (FileChainPtr next, int size) +{ + FileChainPtr ret; + + ret = malloc (sizeof (FileChain) + size); + ret->next = next; + ret->size = size; + ret->used = 0; + ret->ptr = 0; + return ret; +} + +static void +FileChainFree (FileChainPtr ic) +{ + while (ic) + { + FileChainPtr next = ic->next; + free (ic); + ic = next; + } +} + int FileInit (void) { @@ -521,8 +545,6 @@ FileMark (void *object) FileFlush ((Value) file, False); MemReference (file->next); - MemReference (file->input); - MemReference (file->output); } void @@ -538,10 +560,14 @@ FileFree (void *object) { File *file = object; - if (file->fd == -1) - return 1; - if (FileClose ((Value) file) != FileBlocked) + if (file->fd == -1 || FileClose ((Value) file) != FileBlocked) + { + FileChainFree (file->input); + file->input = NULL; + FileChainFree (file->output); + file->output = NULL; return 1; + } return 0; } @@ -613,30 +639,6 @@ FileResetFd (int fd) #endif } -static void -FileChainMark (void *object) -{ - FileChainPtr chain = object; - - MemReference (chain->next); -} - -DataType FileChainType = { FileChainMark, 0, "FileChainType" }; - -static FileChainPtr -NewFileChain (FileChainPtr next, int size) -{ - ENTER (); - FileChainPtr ret; - - ret = MemAllocate (&FileChainType, sizeof (FileChain) + size); - ret->next = next; - ret->size = size; - ret->used = 0; - ret->ptr = 0; - RETURN (ret); -} - Value FileCreate (int fd, int flags) { @@ -893,7 +895,7 @@ FileStringRead (char *string, int len) file = NewFile (-1); file->file.flags |= FileString|FileReadable; - file->file.input = NewFileChain (0, len); + file->file.input = FileChainAlloc (0, len); memcpy (FileBuffer (file->file.input), string, len); file->file.input->used = len; RETURN (file); @@ -1009,7 +1011,7 @@ FileInput (Value file) EXIT (); return FileEOF; } - file->file.input = NewFileChain (0, FileBufferSize); + file->file.input = FileChainAlloc (NULL, FileBufferSize); } ic = file->file.input; for (;;) @@ -1022,7 +1024,12 @@ FileInput (Value file) else { if (ic->next) - ic = ic->next; + { + file->file.input = ic->next; + ic->next = NULL; + FileChainFree (ic); + ic = file->file.input; + } else if (file->file.flags & FileString) { file->file.flags |= FileEnd; @@ -1084,7 +1091,7 @@ FileUnput (Value file, unsigned char c) ic = file->file.input; if (!ic || ic->ptr == 0) { - ic = file->file.input = NewFileChain (file->file.input, FileBufferSize); + ic = file->file.input = FileChainAlloc (file->file.input, FileBufferSize); ic->ptr = ic->used = ic->size; } FileBuffer(ic)[--ic->ptr] = c; @@ -1175,6 +1182,8 @@ FileFlush (Value file, Bool block) ic->used = ic->ptr = 0; break; } + else + FileChainFree (ic); *prev = 0; } } @@ -1214,7 +1223,7 @@ FileOutput (Value file, char c) } ic = file->file.output; if (!ic) - ic = file->file.output = NewFileChain (0, FileBufferSize); + ic = file->file.output = FileChainAlloc (0, FileBufferSize); if (ic->used == ic->size) { if (FileFlush (file, False) == FileError) @@ -1224,7 +1233,7 @@ FileOutput (Value file, char c) } ic = file->file.output; if (ic->used == ic->size) - ic = file->file.output = NewFileChain (file->file.output, FileBufferSize); + ic = file->file.output = FileChainAlloc (file->file.output, FileBufferSize); } ic = file->file.output; FileBuffer(ic)[ic->used++] = c; diff --git a/value.h b/value.h index c941011..e94428f 100644 --- a/value.h +++ b/value.h @@ -625,7 +625,6 @@ typedef struct _array { #define ArrayValueSet(a,i,v) (BoxValueSet(ArrayValueBox(a,i),ArrayValueElt(a,i), v)) typedef struct _io_chain { - DataType *data; struct _io_chain *next; int size; int used; commit 8e3690cea5da54d83e6fd6d26c073c1c4d8ae403 Author: Keith Packard Date: Tue Oct 2 01:16:05 2007 -0700 Extend Ctype namespace to latin-1. This should be extended to all of unicode, but that's a huge amount of data. diff --git a/ctype.5c b/ctype.5c index 88dd1df..a595452 100644 --- a/ctype.5c +++ b/ctype.5c @@ -16,8 +16,8 @@ namespace Ctype { return ch >= 0 && ch <= 127; } - /* The characteristic vector of sets of ASCII chars. */ - public typedef bool[128] charset; + /* The characteristic vector of sets of Latin-1 chars. */ + public typedef bool[256] charset; public charset make_charset(bool(int) cfun) /* @@ -25,7 +25,7 @@ namespace Ctype { */ { charset result; - for (int i = 0; i < 128; i++) + for (int i = 0; i < dim(result); i++) result[i] = cfun(i); return result; } @@ -35,7 +35,7 @@ namespace Ctype { * Test whether a particular char is in a charset. */ { - return isascii(ch) && v[ch]; + return ch >= 0 && ch < dim(v) && v[ch]; } @@ -51,7 +51,8 @@ namespace Ctype { */ { static bool cfun(int ch) { - return ch >= 'A' && ch <= 'Z'; + return (ch >= 'A' && ch <= 'Z' || + ch >= '??' && ch <= '??'); } static charset v = make_charset(cfun); return member(v, ch); @@ -63,7 +64,8 @@ namespace Ctype { */ { static bool cfun(int ch) { - return ch >= 'a' && ch <= 'z'; + return (ch >= 'a' && ch <= 'z' || + ch >= '??' && ch <= '??'); } static charset v = make_charset(cfun); return member(v, ch); @@ -107,7 +109,8 @@ namespace Ctype { */ { static bool cfun(int ch) { - return ch > ' ' && ch < 127; + return (ch > ' ' && ch < 127 || + ch >= '??' && ch <= '??'); } static charset v = make_charset(cfun); return member(v, ch); @@ -119,7 +122,8 @@ namespace Ctype { */ { static bool cfun(int ch) { - return ch >= ' ' && ch < 127; + return (ch >= ' ' && ch < 127 || + ch >= '??' && ch <= '??'); } static charset v = make_charset(cfun); return member(v, ch); commit 52c9ae4e5c476f6b202b49de3840c7ffdd0e02d8 Author: Keith Packard Date: Tue Oct 2 01:15:16 2007 -0700 Flush file output on exit call. Use of the built-in exit function should flush all file I/O, just as if the program terminated by returning to the top level at EOF. diff --git a/builtin-toplevel.c b/builtin-toplevel.c index 36f854c..6ef745b 100644 --- a/builtin-toplevel.c +++ b/builtin-toplevel.c @@ -422,6 +422,7 @@ do_exit (Value av) if (aborting) RETURN (Void); IoFini (); + FileFini (); exit (code); RETURN (Void); } From keithp at keithp.com Tue Oct 2 02:01:49 2007 From: keithp at keithp.com (Keith Packard) Date: Tue, 2 Oct 2007 02:01:49 -0700 (PDT) Subject: [Nickle] nickle: Changes to 'refs/tags/2.60' Message-ID: <20071002090149.15630114203@keithp.com> Tag '2.60' created by Keith Packard at 2007-10-02 09:59 -0700 Nickl version 2.60 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHAgh0Qp8BWwlsTdMRAkv+AKCQJgX7hjWhtpapLISuybXWHyTsZACgxRBa 9Tbnph8pESwFG493lDjIAnU= =Jd/3 -----END PGP SIGNATURE----- Changes since 2.59: Keith Packard (4): Flush file output on exit call. Extend Ctype namespace to latin-1. Manage file buffer chains with explicit malloc/free. Bump to version 2.60 --- builtin-toplevel.c | 1 configure.in | 2 - ctype.5c | 20 ++++++++----- debian/changelog | 8 +++++ file.c | 79 +++++++++++++++++++++++++++++------------------------ value.h | 1 6 files changed, 66 insertions(+), 45 deletions(-) --- From keithp at keithp.com Tue Oct 2 02:01:58 2007 From: keithp at keithp.com (Keith Packard) Date: Tue, 2 Oct 2007 02:01:58 -0700 (PDT) Subject: [Nickle] nickle: Branch 'master' Message-ID: <20071002090158.8A72F114207@keithp.com> configure.in | 2 +- debian/changelog | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-) New commits: commit b1735afed1a772ca6aee87f0ba349c43e8ab2c3e Author: Keith Packard Date: Tue Oct 2 01:57:55 2007 -0700 Bump to version 2.60 diff --git a/configure.in b/configure.in index 4e8329c..53e7a66 100644 --- a/configure.in +++ b/configure.in @@ -7,7 +7,7 @@ dnl for licensing information. AC_PREREQ(2.59) AC_INIT([nickle], - 2.59, + 2.60, [http://nickle.org], nickle) diff --git a/debian/changelog b/debian/changelog index 5c0c7f4..e5988fe 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +nickle (2.60-1) unstable; urgency=low + * Bump to version 2.60 + * Flush file output on exit call. + * Extend Ctype namespace to latin-1. + * Manage file buffer chains with explicit malloc/free. + + -- Keith Packard Tue, 02 Oct 2007 01:55:20 -0700 + nickle (2.59-1) unstable; urgency=low * Bump to version 2.59 * Have git ignore nickle binary From bart at po8.org Tue Oct 2 11:43:50 2007 From: bart at po8.org (Bart Massey) Date: Tue, 02 Oct 2007 11:43:50 -0700 Subject: [Nickle] nickle: Branch 'master' - 3 commits In-Reply-To: <20071002085403.791D3114203@keithp.com> References: <20071002085403.791D3114203@keithp.com> Message-ID: It should be easy to add finalizer support to your mark-sweep GC, and then just close the file in the finalizer when it becomes unreferenced. This would be the traditional solution, I think. Am I missing something? Bart In message <20071002085403.791D3114203 at keithp.com> you wrote: > --===============1547860296== > > builtin-toplevel.c | 1 > ctype.5c | 20 ++++++++----- > file.c | 79 +++++++++++++++++++++++++++++------------------------ > value.h | 1 > 4 files changed, 57 insertions(+), 44 deletions(-) > > New commits: > commit 2278b93b7e760f1153847a0b3c36d07684f72e0c > Author: Keith Packard > Date: Tue Oct 2 01:53:02 2007 -0700 > > Manage file buffer chains with explicit malloc/free. > > Buffer chains must have life equal to the file they belong to; an > unreferenced file may still have buffered data, so the buffers cannot be > reclaimed. The nickle GC does not have a separate pass that checks to see > which objects can be freed, rather it assumes that such objects are > self-contained. > > Hence, anything hanging off of an object which can refuse to > be reclaimed must not have been allocated from the nickle GC system. Yes, > this is a significant limitation to this allocator. > > Someday I'll figure out a good general fix for this problem, right now we'll > stop segfaults when applications drop file references without closing them. > > diff --git a/file.c b/file.c > index 77356b1..933b544 100644 > --- a/file.c > +++ b/file.c > @@ -472,6 +472,30 @@ ProcessInterrupt () > } > } > > +static FileChainPtr > +FileChainAlloc (FileChainPtr next, int size) > +{ > + FileChainPtr ret; > + > + ret = malloc (sizeof (FileChain) + size); > + ret->next = next; > + ret->size = size; > + ret->used = 0; > + ret->ptr = 0; > + return ret; > +} > + > +static void > +FileChainFree (FileChainPtr ic) > +{ > + while (ic) > + { > + FileChainPtr next = ic->next; > + free (ic); > + ic = next; > + } > +} > + > int > FileInit (void) > { > @@ -521,8 +545,6 @@ FileMark (void *object) > > FileFlush ((Value) file, False); > MemReference (file->next); > - MemReference (file->input); > - MemReference (file->output); > } > > void > @@ -538,10 +560,14 @@ FileFree (void *object) > { > File *file = object; > > - if (file->fd == -1) > - return 1; > - if (FileClose ((Value) file) != FileBlocked) > + if (file->fd == -1 || FileClose ((Value) file) != FileBlocked) > + { > + FileChainFree (file->input); > + file->input = NULL; > + FileChainFree (file->output); > + file->output = NULL; > return 1; > + } > return 0; > } > > @@ -613,30 +639,6 @@ FileResetFd (int fd) > #endif > } > > -static void > -FileChainMark (void *object) > -{ > - FileChainPtr chain = object; > - > - MemReference (chain->next); > -} > - > -DataType FileChainType = { FileChainMark, 0, "FileChainType" }; > - > -static FileChainPtr > -NewFileChain (FileChainPtr next, int size) > -{ > - ENTER (); > - FileChainPtr ret; > - > - ret = MemAllocate (&FileChainType, sizeof (FileChain) + size); > - ret->next = next; > - ret->size = size; > - ret->used = 0; > - ret->ptr = 0; > - RETURN (ret); > -} > - > Value > FileCreate (int fd, int flags) > { > @@ -893,7 +895,7 @@ FileStringRead (char *string, int len) > > file = NewFile (-1); > file->file.flags |= FileString|FileReadable; > - file->file.input = NewFileChain (0, len); > + file->file.input = FileChainAlloc (0, len); > memcpy (FileBuffer (file->file.input), string, len); > file->file.input->used = len; > RETURN (file); > @@ -1009,7 +1011,7 @@ FileInput (Value file) > EXIT (); > return FileEOF; > } > - file->file.input = NewFileChain (0, FileBufferSize); > + file->file.input = FileChainAlloc (NULL, FileBufferSize); > } > ic = file->file.input; > for (;;) > @@ -1022,7 +1024,12 @@ FileInput (Value file) > else > { > if (ic->next) > - ic = ic->next; > + { > + file->file.input = ic->next; > + ic->next = NULL; > + FileChainFree (ic); > + ic = file->file.input; > + } > else if (file->file.flags & FileString) > { > file->file.flags |= FileEnd; > @@ -1084,7 +1091,7 @@ FileUnput (Value file, unsigned char c) > ic = file->file.input; > if (!ic || ic->ptr == 0) > { > - ic = file->file.input = NewFileChain (file->file.input, FileBufferSize); > + ic = file->file.input = FileChainAlloc (file->file.input, FileBufferSize); > ic->ptr = ic->used = ic->size; > } > FileBuffer(ic)[--ic->ptr] = c; > @@ -1175,6 +1182,8 @@ FileFlush (Value file, Bool block) > ic->used = ic->ptr = 0; > break; > } > + else > + FileChainFree (ic); > *prev = 0; > } > } > @@ -1214,7 +1223,7 @@ FileOutput (Value file, char c) > } > ic = file->file.output; > if (!ic) > - ic = file->file.output = NewFileChain (0, FileBufferSize); > + ic = file->file.output = FileChainAlloc (0, FileBufferSize); > if (ic->used == ic->size) > { > if (FileFlush (file, False) == FileError) > @@ -1224,7 +1233,7 @@ FileOutput (Value file, char c) > } > ic = file->file.output; > if (ic->used == ic->size) > - ic = file->file.output = NewFileChain (file->file.output, FileBufferSize); > + ic = file->file.output = FileChainAlloc (file->file.output, FileBufferSize); > } > ic = file->file.output; > FileBuffer(ic)[ic->used++] = c; > diff --git a/value.h b/value.h > index c941011..e94428f 100644 > --- a/value.h > +++ b/value.h > @@ -625,7 +625,6 @@ typedef struct _array { > #define ArrayValueSet(a,i,v) (BoxValueSet(ArrayValueBox(a,i),ArrayValueElt(a,i), v)) > > typedef struct _io_chain { > - DataType *data; > struct _io_chain *next; > int size; > int used; > commit 8e3690cea5da54d83e6fd6d26c073c1c4d8ae403 > Author: Keith Packard > Date: Tue Oct 2 01:16:05 2007 -0700 > > Extend Ctype namespace to latin-1. > > This should be extended to all of unicode, but that's a huge amount of data. > > diff --git a/ctype.5c b/ctype.5c > index 88dd1df..a595452 100644 > --- a/ctype.5c > +++ b/ctype.5c > @@ -16,8 +16,8 @@ namespace Ctype { > return ch >= 0 && ch <= 127; > } > > - /* The characteristic vector of sets of ASCII chars. */ > - public typedef bool[128] charset; > + /* The characteristic vector of sets of Latin-1 chars. */ > + public typedef bool[256] charset; > > public charset make_charset(bool(int) cfun) > /* > @@ -25,7 +25,7 @@ namespace Ctype { > */ > { > charset result; > - for (int i = 0; i < 128; i++) > + for (int i = 0; i < dim(result); i++) > result[i] = cfun(i); > return result; > } > @@ -35,7 +35,7 @@ namespace Ctype { > * Test whether a particular char is in a charset. > */ > { > - return isascii(ch) && v[ch]; > + return ch >= 0 && ch < dim(v) && v[ch]; > } > > > @@ -51,7 +51,8 @@ namespace Ctype { > */ > { > static bool cfun(int ch) { > - return ch >= 'A' && ch <= 'Z'; > + return (ch >= 'A' && ch <= 'Z' || > + ch >= '??' && ch <= '??'); > } > static charset v = make_charset(cfun); > return member(v, ch); > @@ -63,7 +64,8 @@ namespace Ctype { > */ > { > static bool cfun(int ch) { > - return ch >= 'a' && ch <= 'z'; > + return (ch >= 'a' && ch <= 'z' || > + ch >= '??' && ch <= '??'); > } > static charset v = make_charset(cfun); > return member(v, ch); > @@ -107,7 +109,8 @@ namespace Ctype { > */ > { > static bool cfun(int ch) { > - return ch > ' ' && ch < 127; > + return (ch > ' ' && ch < 127 || > + ch >= '??' && ch <= '??'); > } > static charset v = make_charset(cfun); > return member(v, ch); > @@ -119,7 +122,8 @@ namespace Ctype { > */ > { > static bool cfun(int ch) { > - return ch >= ' ' && ch < 127; > + return (ch >= ' ' && ch < 127 || > + ch >= '??' && ch <= '??'); > } > static charset v = make_charset(cfun); > return member(v, ch); > commit 52c9ae4e5c476f6b202b49de3840c7ffdd0e02d8 > Author: Keith Packard > Date: Tue Oct 2 01:15:16 2007 -0700 > > Flush file output on exit call. > > Use of the built-in exit function should flush all file I/O, just as if the > program terminated by returning to the top level at EOF. > > diff --git a/builtin-toplevel.c b/builtin-toplevel.c > index 36f854c..6ef745b 100644 > --- a/builtin-toplevel.c > +++ b/builtin-toplevel.c > @@ -422,6 +422,7 @@ do_exit (Value av) > if (aborting) > RETURN (Void); > IoFini (); > + FileFini (); > exit (code); > RETURN (Void); > } > > --===============1547860296== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > Nickle mailing list > Nickle at nickle.org > http://nickle.org/mailman/listinfo/nickle > > --===============1547860296==-- From keithp at keithp.com Tue Oct 2 12:37:13 2007 From: keithp at keithp.com (Keith Packard) Date: Tue, 02 Oct 2007 12:37:13 -0700 Subject: [Nickle] nickle: Branch 'master' - 3 commits In-Reply-To: References: <20071002085403.791D3114203@keithp.com> Message-ID: <1191353833.7062.34.camel@koto.keithp.com> On Tue, 2007-10-02 at 11:43 -0700, Bart Massey wrote: > It should be easy to add finalizer support to your > mark-sweep GC, and then just close the file in the finalizer > when it becomes unreferenced. This would be the traditional > solution, I think. Am I missing something? It's not the closing of the file that's the trouble here. That's all in place and works fine. The trouble is that the buffers holding unflushed data were getting freed before the file object finalizer was invoked. Explicitly managing these buffers means the GC won't find these unreferenced buffers and toss them. One possible solution would be to have the buffers hooked to the file and have their finalizer also try to flush and free them. Hmm. That might work. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/nickle/attachments/20071002/c0b9ddf0/attachment.pgp From bart at cs.pdx.edu Wed Oct 17 16:15:53 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Wed, 17 Oct 2007 16:15:53 -0700 Subject: [Nickle] Bugs with new output formatting Message-ID: <200710172315.l9HNFsrm002206@murzim.cs.pdx.edu> Unfortunately, the new output formatting seems to have some problems... > 1/(2**64-1) Hangs trying to output. This used to spit something sensible. > 1/3 0.3 In general it appears that the curly braces are simply omitted, without expanding the value in any reasonable way. This seems to be the case even if "infinite precision" is specified---I can't find any way to get the curly braces *back*. > printf("%.-g\n", 1/10!); 0.00000027557319223985890652 > format = "%g"; > format = "%f"; Unhandled exception invalid_argument ("realformat with non-real", 1, "%f") /usr/share/nickle/printf.5c:186: raise invalid_argument ((fmts[i]).message + "format with non-" + (fmts[i]).message, 1, this_arg); fprintf (file, "%f") /usr/share/nickle/command.5c:20: printf (format, v); display ("%f") :5: Command::display ((format = "%f")); - It's never been obvious to me why the first format command is acceptable, but the second is not :-). I'm not sure what to do about all this. I think the user should be able to select between a "%f"-like or "%g"-like output format and the old format with the curly braces for repeats using the format variable. I also think that Nickle should accept curly-repeats on the input, although I know that's a pain in the neck. Keithp? Bart From bart at cs.pdx.edu Wed Oct 17 16:17:32 2007 From: bart at cs.pdx.edu (Barton C Massey) Date: Wed, 17 Oct 2007 16:17:32 -0700 Subject: [Nickle] Should wacky type keywords be modularized? Message-ID: <200710172317.l9HNHWjv002230@murzim.cs.pdx.edu> Right now, "thread", "semaphore", and "file" are among the keywords of the Nickle language. This is a bit strange. It seems better to have them look like normal namespace-controlled types in their respective namespaces. Keithp, is this hard to do, or is there some downside I'm missing? Bart From keithp at keithp.com Wed Oct 17 22:37:28 2007 From: keithp at keithp.com (Keith Packard) Date: Wed, 17 Oct 2007 22:37:28 -0700 Subject: [Nickle] Should wacky type keywords be modularized? In-Reply-To: <200710172317.l9HNHWjv002230@murzim.cs.pdx.edu> References: <200710172317.l9HNHWjv002230@murzim.cs.pdx.edu> Message-ID: <1192685848.8212.48.camel@koto.keithp.com> On Wed, 2007-10-17 at 16:17 -0700, Barton C Massey wrote: > Right now, "thread", "semaphore", and "file" are among the > keywords of the Nickle language. This is a bit strange. It > seems better to have them look like normal > namespace-controlled types in their respective namespaces. > Keithp, is this hard to do, or is there some downside I'm > missing? Should be easy enough to manage. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/nickle/attachments/20071017/aaa3ea53/attachment.pgp From keithp at keithp.com Wed Oct 17 22:41:44 2007 From: keithp at keithp.com (Keith Packard) Date: Wed, 17 Oct 2007 22:41:44 -0700 Subject: [Nickle] Bugs with new output formatting In-Reply-To: <200710172315.l9HNFsrm002206@murzim.cs.pdx.edu> References: <200710172315.l9HNFsrm002206@murzim.cs.pdx.edu> Message-ID: <1192686104.8212.52.camel@koto.keithp.com> On Wed, 2007-10-17 at 16:15 -0700, Barton C Massey wrote: > Unfortunately, the new output formatting seems to have some > problems... > > > > 1/(2**64-1) Do you have something in your .nicklerc file? This works for me > > 1/3 > 0.3 As does this. > In general it appears that the curly braces are simply > omitted, without expanding the value in any reasonable way. > This seems to be the case even if "infinite precision" is > specified---I can't find any way to get the curly braces > *back*. format="%G" does this trick. > It's never been obvious to me why the first format command > is acceptable, but the second is not :-). Yeah, we need some consistent documented behaviour for the various format flags. > I'm not sure what to do about all this. I think the user > should be able to select between a "%f"-like or "%g"-like > output format and the old format with the curly braces for > repeats using the format variable. I also think that Nickle > should accept curly-repeats on the input, although I know > that's a pain in the neck. Uh, this works for both the lexer and scanf... -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/nickle/attachments/20071017/c9dbc39d/attachment.pgp From bart at po8.org Thu Oct 18 11:28:13 2007 From: bart at po8.org (Bart Massey) Date: Thu, 18 Oct 2007 11:28:13 -0700 Subject: [Nickle] Bugs with new output formatting In-Reply-To: <1192686104.8212.52.camel@koto.keithp.com> References: <200710172315.l9HNFsrm002206@murzim.cs.pdx.edu> <1192686104.8212.52.camel@koto.keithp.com> Message-ID: In message <1192686104.8212.52.camel at koto.keithp.com> you wrote: > On Wed, 2007-10-17 at 16:15 -0700, Barton C Massey wrote: > > Unfortunately, the new output formatting seems to have some > > problems... > > > > > 1/(2**64-1) > > Do you have something in your .nicklerc file? This works for me > > > 1/3 > > 0.3 > > As does this. Huh. I apparently have build problems or something; I can't reproduce it from a new build and install. My guess is that the new binary wasn't playing well with the old nickle directory. Sorry for the confusion. > > I can't find any way to get the curly braces > > *back*. > > format="%G" does this trick. Cool. I missed that one reading the source. > > It's never been obvious to me why the first format command > > is acceptable, but the second is not :-). > > Yeah, we need some consistent documented behaviour for the various > format flags. For now, I think that setting any numeric format should work like "%g" does; use "%v" for anything non-numeric. In general, what would probably make more sense would be to provide some more sophisticated output mechanism than a format specifier; probably a formatting function is the right approach. > > I'm not sure what to do about all this. I think the user > > should be able to select between a "%f"-like or "%g"-like > > output format and the old format with the curly braces for > > repeats using the format variable. I also think that Nickle > > should accept curly-repeats on the input, although I know > > that's a pain in the neck. > > Uh, this works for both the lexer and scanf... OK, I officially am an idiot. My apologies. Bart