Re: propose deprecation of generalized-vector-*
On Tue 22 Jan 2013 15:31, Daniel Llorens daniel.llor...@bluewin.ch writes: On Jan 21, 2013, at 17:11, Andy Wingo wrote: The patch attached applies over yours and is to document this function and a couple others in the manual. Thanks, applied and pushed to wip-generalized-vectors. Maybe we should have scm_array_ref_1, scm_array_ref_2, etc. as it is done for some other functions taking rest lists. I can write a patch for that. For C, that makes sense. Something should be done for Scheme as well, but it's not terribly urgent. Perhaps make scm_array_ref not be bound to array-ref, and instead bind array-ref to some function that takes two optional arguments and a rest argument. A poor man's case-lambda... It makes sense to let vector- work on uniform vectors because the implementation should be identical. FWIW this is not the case. Vectors hold SCM objects, whereas uniform vectors hold unpacked machine values. It's possible to have a one-dimensional slice of a uniform array also. Now on to your next mail... Andy -- http://wingolog.org/
Re: propose deprecation of generalized-vector-*
Hi, On Wed 23 Jan 2013 00:27, Daniel Llorens daniel.llor...@bluewin.ch writes: I guess I don't value that much having a specific interface just for rank 1 objects. I don't care much either; I don't think I have ever used the generalized vector routines. If I wanted real polymorphism, I think I would also want it over user types (GOOPS and record types) as well, and that's another kettle of fish. I'm now inclined to punt on any kind of general(ized) solution, and leave it to a module to handle. The array interface seems more logical. Everything is array? and then things are typed-array? of specific types. I see myself not using the vector interface at all. Yes, the array interface is consistent, easy to explain, and completely subsumes the generalized-vector interface. Let's recommend that for now. A guile with generalized arrays (as we have always had) and without generalized vectors is better because it has the same power, fewer concepts, fewer bugs, and less code. I have pushed our patches to a new WIP branch, wip-generalized-vectors. I'd like to leave it open for comments for a week or so before merging, just in case someone hasn't had a chance to wade through all of my mails over the last week. Regards, Andy -- http://wingolog.org/
Re: [PATCH] add new read-delimited option to return #f while terminating delimiter can't be found.
On Wed 07 Mar 2012 17:32, Nala Ginrut nalagin...@gmail.com writes:
I found current read-delimited will return the whole string if delimiter
can't be found. It's inconvenient for some cases.
I expect it return #f for this.
And Andy said it maybe because some back compatible reasons. So I decide
to add an option to do this job.
I have fixed up the docs a bit, and now I really don't want to add it.
Patch attached, but here are the docs:
-- Scheme Procedure: read-delimited delims [port] [handle-delim]
Read text until one of the characters in the string DELIMS is found
or end-of-file is reached. Read from PORT if supplied, otherwise
from the value returned by `(current-input-port)'.
HANDLE-DELIM takes the same values as described for `read-line',
with one addition:
`fail'
If a delimiter is not found, return `#f' instead of returning
a string of the characters that were read. The characters
that were read are lost. Otherwise, return a string of the
characters that were read, without the delimiter, as in
`trim'.
-- Scheme Procedure: read-delimited! delims buf [port] [handle-delim]
[start] [end]
Read text into the supplied string BUF.
If a delimiter was found, return the number of characters written,
with two exceptions: if HANDLE-DELIM is `split', the return value
is a pair, as noted above; and if it is `fail', `#f' is returned
if the delimiter is not found.
As a special case, if PORT was already at end-of-stream, the EOF
object is returned. Also, if no characters were written because the
buffer was full, `#f' is returned.
It's something of a wacky interface, to be honest.
There are three things I don't like about `fail':
* It throws away the characters that were read. A user could expect
(incorrectly, and it's not really possible to do) that a return
value of #f leaves the characters in the port.
* It makes a strange interface even stranger.
* It falls back to the trim behavior, whereas a user might actually
want concat or peek. (If they wanted split, they could check
themselves).
Now that Guile 2.0 always truncates multiple-value returns, I think we
should change this interface to always return two values: the string
that was read, and the delimiter. Then we don't have to think about
modes, the default behavior is sane, and all the information is
available to the client if they call in a two-valued context.
Now it's better:
---cut---
--
(call-with-input-string asdf (lambda (port) (read-delimited @ port
'fail
== #f
If you are reading from strings, there are better interfaces (regexes,
string-split, string-index, etc etc; see srfi-13).
So for now I am thinking that I would not like to apply this patch to
Guile.
Regards,
Andy
From 33f272d55f1a70572e73eb41df34c4d914cf8b49 Mon Sep 17 00:00:00 2001
From: Nala Ginrut nalagin...@gmail.com
Date: Wed, 23 Jan 2013 00:30:25 +0800
Subject: [PATCH] Add 'fail' mode to read-delimited.
* doc/ref/api-io.texi: Update the doc for read-delmited.
* module/ice-9/rdelim.scm: Add new mode to read-delimited.
* test-suite/tests/rdelim.test: Add test case for 'fail' mode.
---
doc/ref/api-io.texi | 20 +++-
module/ice-9/rdelim.scm |2 ++
test-suite/tests/rdelim.test | 21 +
3 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/doc/ref/api-io.texi b/doc/ref/api-io.texi
index 11ae580..4ffad6b 100644
--- a/doc/ref/api-io.texi
+++ b/doc/ref/api-io.texi
@@ -1,7 +1,7 @@
@c -*-texinfo-*-
@c This is part of the GNU Guile Reference Manual.
@c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2007, 2009,
-@c 2010, 2011 Free Software Foundation, Inc.
+@c 2010, 2011, 2013 Free Software Foundation, Inc.
@c See the file guile.texi for copying conditions.
@node Input and Output
@@ -548,16 +548,26 @@ specified, otherwise from the value returned by @code{(current-input-port)}.
Read text until one of the characters in the string @var{delims} is found
or end-of-file is reached. Read from @var{port} if supplied, otherwise
from the value returned by @code{(current-input-port)}.
-@var{handle-delim} takes the same values as described for @code{read-line}.
+
+@var{handle-delim} takes the same values as described for
+@code{read-line}, with one addition:
+@table @code
+@item fail
+If a delimiter is not found, return @code{#f} instead of returning a
+string of the characters that were read. The characters that were read
+are lost. Otherwise, return a string of the characters that were read,
+without the delimiter, as in @code{trim}.
+@end table
@end deffn
@c begin (scm-doc-string rdelim.scm read-delimited!)
@deffn {Scheme Procedure} read-delimited! delims buf [port] [handle-delim] [start] [end]
Read text into the supplied string
Re: [PATCH] add new read-delimited option to return #f while terminating delimiter can't be found.
On Wed, 2013-01-23 at 11:00 +0100, Andy Wingo wrote: On Wed 07 Mar 2012 17:32, Nala Ginrut nalagin...@gmail.com writes: I found current read-delimited will return the whole string if delimiter can't be found. It's inconvenient for some cases. I expect it return #f for this. And Andy said it maybe because some back compatible reasons. So I decide to add an option to do this job. I have fixed up the docs a bit, and now I really don't want to add it. Patch attached, but here are the docs: -- Scheme Procedure: read-delimited delims [port] [handle-delim] Read text until one of the characters in the string DELIMS is found or end-of-file is reached. Read from PORT if supplied, otherwise from the value returned by `(current-input-port)'. HANDLE-DELIM takes the same values as described for `read-line', with one addition: `fail' If a delimiter is not found, return `#f' instead of returning a string of the characters that were read. The characters that were read are lost. Otherwise, return a string of the characters that were read, without the delimiter, as in `trim'. -- Scheme Procedure: read-delimited! delims buf [port] [handle-delim] [start] [end] Read text into the supplied string BUF. If a delimiter was found, return the number of characters written, with two exceptions: if HANDLE-DELIM is `split', the return value is a pair, as noted above; and if it is `fail', `#f' is returned if the delimiter is not found. As a special case, if PORT was already at end-of-stream, the EOF object is returned. Also, if no characters were written because the buffer was full, `#f' is returned. It's something of a wacky interface, to be honest. There are three things I don't like about `fail': * It throws away the characters that were read. A user could expect (incorrectly, and it's not really possible to do) that a return value of #f leaves the characters in the port. * It makes a strange interface even stranger. * It falls back to the trim behavior, whereas a user might actually want concat or peek. (If they wanted split, they could check themselves). Now that Guile 2.0 always truncates multiple-value returns, I think we should change this interface to always return two values: the string that was read, and the delimiter. Then we don't have to think about modes, the default behavior is sane, and all the information is available to the client if they call in a two-valued context. Now it's better: ---cut--- -- (call-with-input-string asdf (lambda (port) (read-delimited @ port 'fail == #f If you are reading from strings, there are better interfaces (regexes, string-split, string-index, etc etc; see srfi-13). So for now I am thinking that I would not like to apply this patch to Guile. OK, since this patch is a little old (one year ago), I can't remember exactly what code-context make me send this patch. So it may lack of persuade power. And I realized that it could be solved like this: --code- (define (read-delimiter-fail delim port) (let ((r (read-delimiter delim 'split))) (if (eof-object? (cdr r)) #f (car r --end-- Though I don't agree the all three points, it's not worthy to get involved with this issue anymore. @andy: it's the cautious in last second I should learn. I confess I don't think hard about this patch. ;-) Regards, Andy differences between files attachment (0001-Add-fail-mode-to-read-delimited.patch) From 33f272d55f1a70572e73eb41df34c4d914cf8b49 Mon Sep 17 00:00:00 2001 From: Nala Ginrut nalagin...@gmail.com Date: Wed, 23 Jan 2013 00:30:25 +0800 Subject: [PATCH] Add 'fail' mode to read-delimited. * doc/ref/api-io.texi: Update the doc for read-delmited. * module/ice-9/rdelim.scm: Add new mode to read-delimited. * test-suite/tests/rdelim.test: Add test case for 'fail' mode. --- doc/ref/api-io.texi | 20 +++- module/ice-9/rdelim.scm |2 ++ test-suite/tests/rdelim.test | 21 + 3 files changed, 38 insertions(+), 5 deletions(-) diff --git a/doc/ref/api-io.texi b/doc/ref/api-io.texi index 11ae580..4ffad6b 100644 --- a/doc/ref/api-io.texi +++ b/doc/ref/api-io.texi @@ -1,7 +1,7 @@ @c -*-texinfo-*- @c This is part of the GNU Guile Reference Manual. @c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2007, 2009, -@c 2010, 2011 Free Software Foundation, Inc. +@c 2010, 2011, 2013 Free Software Foundation, Inc. @c See the file guile.texi for copying conditions. @node Input and Output @@ -548,16 +548,26 @@ specified, otherwise from the value returned by
[FEATURE] List all available languages
As I talked with Andy, we may add a feature to list all available languages. And if users add a new language to the %load-path, they may see it listed out. Besides, this feature could be used in 'guild compile' to detect all the language available. Attached is a proc named 'get-all-available-languages', it'll scan all % load-path and list the union of the languages available. Please review it. If accepted, I'll format a patch into (ice-9 command-line). Thanks! (use-modules (ice-9 ftw) (srfi srfi-1)) (define (is-inner-lang? str) (and (not (member str '(glil glil.scm assembly assembly.scm bytecode objcode.scm objcode tree-il tree-il.scm value .. .))) str)) (define (get-all-available-languages) (let lp((rest (map (lambda (x) (string-append x /language)) %load-path)) (result '())) (cond ((null? rest) (apply lset-union string=? result)) (else (let ((ll (scandir (car rest) is-inner-lang?))) (lp (cdr rest) (if ll (cons ll result) result)))
Re: propose deprecation of generalized-vector-*
On Jan 23, 2013, at 10:06, Andy Wingo wrote:
For C, that makes sense. Something should be done for Scheme as well,
but it's not terribly urgent. Perhaps make scm_array_ref not be bound
to array-ref, and instead bind array-ref to some function that takes
two optional arguments and a rest argument. A poor man's case-lambda...
Just saying…
I have written a general rectangular selector for arrays as in APL.
It depends on having a prefix-selection operator. Here's an example from numpy:
In [1]: import numpy as np
In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
In [3]: a
Out[3]:
array([[1, 2, 3],
[4, 5, 6],
[7, 8, 9]])
In [4]: a[1]
Out[4]: array([4, 5, 6])
In [5]: a[1, 1]
Out[5]: 5
array-ref can be extended very simply to do that. It accumulates on the
position as it is done now, but if the index list comes up short it makes a
shared array with the remaining axes instead of giving a rank error. So it
shouldn't be any slower than array_ref.
This cannot be done properly from user code with current Guile because
scm_i_make_array() and friends are internal. The only option is
make-shared-array. Now, this is a nice interface for general slicing, but it
requires creating a closure that is only going to be used rank+1 times, plus a
bunch of lists. Let's say that I want to iterate through the rows of a [10
x 3] array. Moving from row to row is fundamentally just moving a pointer.
make-shared-array is not a practical way to do it.
The extension of array-ref below isn't a real fix for this use case, because
we're still creating a array descriptor for each iteration. But it's way faster
than make-shared-array and it is a natural extension. I'm proposing a patch for
this.
The only wart is what happens with arrays of rank 0. The function below doesn't
return views of rank 0, but the element instead, just as array-ref does. The
only advantage of returning a rank 0 view is that one could in principle modify
the array through it, but they are a pain to deal with otherwise. My ‘solution’
is to treat the result of array-ref as read-only.
In APL/J there's no difference between an array of rank 0 and a scalar, so this
problem doesn't exist. We may have a similar extension to (array-set! array obj
. idxlist) where obj is an array of rank (rank(obj)-length(idxlist)) but an
element if this gives 0. This would be just a wrapper over
array-copy(array-ref) or the current array-set!.
Otherwise I think it should be possible to manipulate SCM_I_ARRAY_DIMS
directly, at least from C. Unless there is a way already and I didn't realize,
that would be great.
// Generalization of array-ref where the number of indices may be smaller than
the rank of a.
SCM from_(SCM a, SCM i_)
{
SCM i = i_;
scm_t_array_handle ah;
scm_array_get_handle(a, ah);
scm_t_array_dim * as = scm_array_handle_dims(ah);
int arank = scm_array_handle_rank(ah);
int k = arank;
ssize_t pos = 0;
for (; k0 scm_is_pair(i); --k, ++as, i=scm_cdr(i)) {
ssize_t ik = scm_to_ssize_t(scm_car(i));
if (ikas-lbnd || ikas-ubnd) {
scm_array_handle_release(ah);
scm_error_scm(scm_from_locale_symbol(out-of-range),
SCM_BOOL_F,
scm_from_locale_string(indices out of range),
SCM_EOL, i_);
}
pos += (ik-as-lbnd)*as-inc;
}
SCM o;
if (k0) {
if (k==arank) {
o = a;
} else {
o = scm_i_make_array(k);
SCM_I_ARRAY_V(o) = SCM_I_ARRAY_V(a);
SCM_I_ARRAY_BASE(o) = pos + SCM_I_ARRAY_BASE(a); // since
arank1.
scm_t_array_dim * os = SCM_I_ARRAY_DIMS(o);
for (; k0; --k, ++as, ++os) {
os-ubnd = as-ubnd;
os-lbnd = as-lbnd;
os-inc = as-inc;
}
}
} else if (scm_is_null(i)) {
o = scm_array_handle_ref(ah, pos); // these may be non-arrays.
} else {
scm_array_handle_release(ah);
scm_error_scm(scm_from_locale_symbol(out-of-range), SCM_BOOL_F,
scm_from_locale_string(too many indices), SCM_EOL,
i_);
}
scm_array_handle_release(ah);
return o;
}
FWIW this is not the case. Vectors hold SCM objects, whereas uniform
vectors hold unpacked machine values.
Ok, I think I understand that. Still I don't see where the vref field for the
srfi4 types is set. The conversions seem to be done in bytevector.c, can you
point this out?
I've also noticed
scheme@(guile-user) (f64vector-ref #s64(1 2 3) 0)
$1 = #.#
scheme@(guile-user) (c64vector-ref #f64(1 2 3) 0)
$3 = 1.0+2.0i
(!)
Regards
Daniel
Re: propose deprecation of generalized-vector-*
Hi! Andy Wingo wi...@pobox.com skribis: What is a vector? Possible answers: 1. A vector is something that answers #t to vector?, which contains some number of storage slots accessible in a mostly-O(1) way, the number of slots is given by vector-length, and the slots can be accessed with vector-ref and vector-set!. 2. A vector is a specific kind of object, implementing the interface described above, and disjoint from all other kinds of objects. 3. A vector is a specific kind of object, as before, disjoint from all other kinds of objects defined in the R5RS. 4. A vector is a specific kind of object, as before, disjoint from all other kinds of objects defined in the R6RS. (1) defines vectors as an interface. (2) defines vectors as a specific data structure. (3) admits to a number of distinct types that may be vectors, of which one kind is defined by the R5RS. (4) is like (3), but it precludes bytevectors from being vectors. I would vote for (2). Vectors are a specific data structure that has always (?) been defined in the Scheme reports, so it ought to remain disjoint IMO. Guile’s arrays are closer to (1), but with a multi-dimensional interface. Ludo’.
stable-2.0 merged to master; wip-rtl rebased
Hi, Just a note that I have merged stable-2.0 to master, and rebased wip-rtl on top of that. `master' should build and pass make check for everyone. If that is not the case, please let me know. Thanks, Andy -- http://wingolog.org/
Re: More RTL Tests
On Sun 14 Oct 2012 21:59, Noah Lavine noah.b.lav...@gmail.com writes: I have been working on understanding RTL, and I wrote the following tests. They're mostly to illustrate for myself how calling works in RTL, but they also serve to test it. Any objections if I commit them as part of rtl.test? Committed, thanks! Andy -- http://wingolog.org/
rebased wip-rtl-cps
Hi Noah, A brief note to let you know that I rebased wip-rtl-cps, as wip-rtl itself was rebased. Cheers, Andy -- http://wingolog.org/
Re: Thread-unsafe initialization problems in Guile
I wrote: For a good introduction to what is needed to write robust multithreaded code on modern weakly-ordered memory architectures, I recommend the following article: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2480.html and if you want a deeper understanding of what's going on in the hardware to cause these problems, see Paul McKenney's paper Memory Barriers: a Hardware View for Software Hackers: http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf Mark
Re: bug#13342: Errors trying to build Guile 2.0.7
Hi Andy: Thanks for your patient help. GNU make and friends is entirely new to me at the detail level. I did the following (starting from scratch): (0) Starting with the guile-2.0.7 tar ball ./configure make make check This used gcc and had 77 warnings and 1 test failure bad return from expression `(f-sum -1 2000 -3 400)': expected 3971999; got 3972255 FAIL: test-ffi (1) Then I did make clean ./configure CC=/usr/bin/clang make make check This used clang and had 87 warnings and 2 test failures bad return from expression `(f-sum -1 2000 -3 400)': expected 3971999; got 3972255 FAIL: test-ffi fail: scm_is_unsigned_integer ((- (expt 2 64) 1), 0, 18446744073709551615) == 1 FAIL: test-conversion (2) Comments: Many of the warnings were common to both compilers. Based on the above tests I still maintain that the compilers are not at fault in their code generation. Instead I suspect something is amiss in the interpreter. (3) Next step: I would like to step through the interpreter as it handles the Scheme/guile code. Although I looked at the manual I am not sure what to do. (4) Questions: (a) Do I need to build a debug version of guile? I note there is a debug flag that can be set. But I don't know where to set it. (b) From previous emails I understand I have to run the meta uninstalled version. Ideally I would like to run from the terminal and stop the interpreter before it executes the byte code for test-ffi. That way one can look at the bytes representing the int8_t and see if the sign bit is set and interpreted correctly for this data type. NOTE: In stdint.h there is a typedef signed charint8_t Again thanks for the patient replies and help respect… Peter
Re: syntax closures
Hi, I managed to do what you said, the result is at https://gitorious.org/syntax-closures I changed it so that it is enough to do (use-modules (srfi srfi-72)) and hacking along with it using both #, and #,@ Especially #,@ was difficult but using the ck macro the appending become more natural. I would expect the code to be quite expensive computationally though. On a side note, the quasisyntax expander will severely transform syntaxes of the form (a b c #,@( ...) a) though and therefore any macro that assume that this list can have some form on say 'a b c', will fail because the whole list will be transformed by quasisyntax. It is possible to introduce splicing macros in psyntax I think and then the system would be even more true to the srfi-72. Because I suspect that the srfi-72 spec and the huge transformation of the list e.g. append macros, does not mix well. Anyway it was a fun hack, thanks! /Stefan On Tue, Jan 22, 2013 at 5:38 PM, Andy Wingo wi...@pobox.com wrote: On Tue 22 Jan 2013 17:19, Stefan Israelsson Tampe stefan.ita...@gmail.com writes: (read-hash-extend #\_ syntax-closure-reader) Have you tried having your srfi-72 module export a binding for unsyntax? I would like to use that of cause, but does it mix well with other already written code? It should work in a modular fashion. #,foo reads as (unsyntax foo), and the meaning of that depends on the binding of unsyntax that is current. Andy -- http://wingolog.org/
Re: syntax closures
On Thu, Jan 24, 2013 at 8:24 AM, Stefan Israelsson Tampe stefan.ita...@gmail.com wrote: Hi, I managed to do what you said, the result is at https://gitorious.org/syntax-closures I changed it so that it is enough to do (use-modules (srfi srfi-72)) Note SRFI-72 is not an implementation of syntactic-closures. It's an alternate hygiene algorithm closer to the R6RS one which includes a compatible syntax-case and some convenience utilities. Syntactic-closures never had a formal specification, just an informal description and reference implementation, so it's not clear to me if SRFI-72's make-capturing-identifier is equivalent to the synclos free variables. -- Alex
Re: syntax closures
Hi Alex! Note SRFI-72 is not an implementation of syntactic-closures. It's an alternate hygiene algorithm closer to the R6RS one which includes a compatible syntax-case and some convenience utilities. To comments to this: 1. The main reason for SRFI-72 is to e.g. capture the let bound y in the syntax in (define y 1) (define (f x) x) (let-syntax ((g (lambda (x) #`(let ((y 2)) #,(f #'y) g) - 2 And the same with #,@. In SRFI-72 they design a whole new hygiene method etc. for that. What I tried to do was to get this result as well at good approximation within the current syntax system. 2. I was actually hesistant to call this srfi-72 because of trying to do what it want more than what it say's. A main trick to simulate the effect was to introduce a closure in the syntax at one point and therefore a choose the name syntax-closure not knowing that there is an already a notion of that in the wild sorry! Syntactic-closures never had a formal specification, just an informal description and reference implementation, so it's not clear to me if SRFI-72's make-capturing-identifier is equivalent to the synclos free variables. yeah I could be out of the blue saying srfi-72. Maybe the algorithm needs a srfi of it's own because it does useful stuff and integrates well with standard syntax-case systems which srfi-72 don't. And of cause the mentioning of synclos could be confusing. /Stefan
