Re: [PATCH] Support ~N in SRFI-19 string->date

> On 12 Dec 2018, at 02:53, Mark H Weaver wrote: > > The instances of '3600' above, given as the last argument to > 'make-date', enable the tests to succeed in your time zone (+0100). > They fail in every other time zone. > > Can you look into it and apply an appropriate fix? > >

Re: [PATCH] Support ~N in SRFI-19 string->date

The previous patch had a broken test. New attempt, tested on stable-2.2. Regards Daniel 0001-Support-N-in-SRFI-19-string-date.patch Description: Binary data

[PATCH] Support ~N in SRFI-19 string->date

I copied from the reference implementation, added a test and fixed the doc. OK to apply? Regards Daniel From 95b024dbf4ac0788560dcc9b251b9ad855296d67 Mon Sep 17 00:00:00 2001 From: Daniel Llorens Date: Mon, 10 Dec 2018 11:57:05 +0100 Subject: [PATCH] Support ~N in SRFI-19 string

Re: [PATCH] Let (format) used in exceptions be overriden

> On 20 Oct 2018, at 21:36, Mark H Weaver wrote: >> replace uses of (format) by (exception-format). > > What's the rationale for this proposed change? > > ... Hi Mark, I don't know how that just ended on guile-devel. It's part of a patch series I sent last year and I don't remember

[PATCH] Let (format) used in exceptions be overriden

From: Daniel Llorens * module/ice-9/boot-9.scm (exception-format): new variable. Globally replace uses of (format) by (exception-format). --- module/ice-9/boot-9.scm | 52 ++--- 1 file changed, 28 insertions(+), 24 deletions(-) diff --git a/module

Re: GC Warning related to large mem block allocation - Help needed

On 01 Jan 2018, at 15:11, Freja Nordsiek wrote: > The only worry then would be that it would get collected while still > being used. I think most cases, this would not be a problem. However, if > someone makes a new bytevector from an existing one from somewhere in > the

[PATCH] Allow scm_XXX_writable_elements on empty vectors, even if immutable

From: Daniel Llorens <daniel.llor...@bluewin.ch> * libguile/array-handle.c (initialize_vector_handle): Set both element pointers to NULL if the vector is empty. * libguile/array-map.c (racp): Ignore immutability if destination is empty. * test-suite/tests/sort.test: Check empty/m

Re: [PATCH] Allow scm_XXX_writable_elements on empty vectors, even if immutable

Please ignore this patch, I saw it produces an error elsewhere. I'm sending an updated patch. Regards Daniel

[PATCH] Allow scm_XXX_writable_elements on empty vectors, even if immutable

From: Daniel Llorens <daniel.llor...@bluewin.ch> * libguile/array-handle.c (initialize_vector_handle): Set both element pointers to NULL if the vector is empty. * test-suite/tests/sort.test: Check empty/mutable/immutable vectors with sort!. --- libguile/array-handle.c| 6 --

_writable_elements & empty vectors

There is a whole set of functions scm_TYPE_writable_elements in Guile. In 2.2 these functions must be called with mutable containers. The problem is that empty vectors or arrays are immutable, so one is forced to guard every call to scm_TYPE_writable_elements with a superfluous size check.

-Wdeclaration-after-statement

Guile source is now C99. Can we get rid of this flag? Regards Daniel

Re: GNU Guile 2.1.7 released (beta)

On 28 Feb 2017, at 01:04, David Pirotte wrote: > Hi Andy, > >> So! Release blockers. >> ... > > Not a blocker, at all, but I was thinking to this, wrt manipulating (very) > large > vectors, arrays, lists ... > > -]repl - truncated-print > > Right now I edit the

Re: `bytevector-length' doesn't accept a shared array from a bytevector

On 21 Feb 2017, at 19:51, Diogo F. S. Ramos wrote: >> On 21 Feb 2017, at 14:21, Diogo F. S. Ramos wrote: >> >>> I want to take the length of a shared array, but `bytevector-length' >>> throws an error claiming the shared array isn't a bytevector, even >>>

[PATCH 2/6] Remove documentation on uniform-vector-read!, uniform-vector-write

From: Daniel Llorens <daniel.llor...@bluewin.ch> * NEWS: Add specific removal notice. * doc/ref/api-data.texi: Remove documentation on uniform-vector-read!, uniform-vector-write. --- NEWS | 7 +++ doc/ref/api-data.texi | 33 - 2

Better support for non-zero lower bound arrays [v2]

This patchset improves the support for non-zero lower bound arrays. Specifically, the functions sort, sort!, restricted-vector-sort!, array-slice-for-each, and truncated-print from (ice-9 pretty print) now support non-zero lower bound arrays. The patchset also adds support for bitvectors in

[PATCH 6/6] Remove scm_generalized_vector_get_handle

From: Daniel Llorens <daniel.llor...@bluewin.ch> This was deprecated in 2.0.9 (118ff892be199f0af359d1b027645d4783a364ec). * libguile/bitvectors.c (scm_bitvector_writable_elements): Replace scm_generalized_vector_get_handle. Remove unnecessary #includes. * libguile/vec

[PATCH 4/6] Support non-zero lower bounds in array-slice-for-each

From: Daniel Llorens <daniel.llor...@bluewin.ch> * libguile/array-handle.c (scm_array_handle_writable_elements): Fix error message. * libguile/array-map.c (scm_array_slice_for_each): Support non-zero lower bounds. Fix error messages. * test-suite/tests/array-map.test

[PATCH 5/6] Fix bitvectors and non-zero lower bound arrays in truncated-print

From: Daniel Llorens <daniel.llor...@bluewin.ch> * module/ice-9/arrays.scm (array-print-prefix, array-print): New private functions. * libguile/arrays.c (scm_i_print_array): Reuse (array-print-prefix) from (ice-9 arrays). Make sure to release the array handle. * module/ice-9/pretty-pri

[PATCH 1/6] Replace uniform-vector-read benchmark with bytevector-io benchmark

From: Daniel Llorens <daniel.llor...@bluewin.ch> * benchmark-suite/benchmarks/uniform-vector-read.bm: Remove; uniform-vector-read! and uniform-vector-write were deprecated in 2.0 and are have been removed in 2.1. * benchmark-suite/benchmarks/bytevector-io.bm: New benchmark. * benchmark

[PATCH 3/6] Fix sort, sort! for arrays with nonzero lower bound

From: Daniel Llorens <daniel.llor...@bluewin.ch> * module/ice-9/arrays.scm (array-copy): New function, export. * module/Makefile.am: Install (ice-9 arrays). * doc/ref/api-data.texi: Add documentation for (ice-9 arrays). * libguile/quicksort.i.c: Use signed bounds throughout. * libguile/

Re: Bug in system/repl/error-handling.scm ?

On 20 Feb 2017, at 15:40, Matt Wette wrote: > This code looks wrong to me: 3rd arg to catch is not a procedure. Am I > missing something? It starts at line 113 in system/repl/error-handling.scm, > guile-2.0.13: > > (catch #t > (lambda () >

[PATCH 2/6] Replace uniform-vector-read benchmark with bytevector-io benchmark

From: Daniel Llorens <daniel.llor...@bluewin.ch> * benchmark-suite/benchmarks/uniform-vector-read.bm: Remove; uniform-vector-read! and uniform-vector-write were deprecated in 2.0 and are have been removed in 2.1. * benchmark-suite/benchmarks/bytevector-io.bm: New benchmark. * benchmark

[PATCH 6/6] Fix bitvectors and non-zero lower bound arrays in truncated-print

From: Daniel Llorens <daniel.llor...@bluewin.ch> * module/ice-9/arrays.scm (array-print-prefix, array-print): New private functions. * libguile/arrays.c (scm_i_print_array): Reuse (array-print-prefix) from (ice-9 arrays). Make sure to release the array handle. * module/ice-9/pretty-pri

Better support for non-zero lower bound arrays

This patchset adds better support for non-zero lower bound arrays. Specifically, the functions sort, sort!, restricted-vector-sort!, array-slice-for-each, and truncated-print from (ice-9 pretty print) now support non-zero lower bound arrays. The patchset also adds support for bitvectors in

[PATCH 3/6] Remove documentation on uniform-vector-read!, uniform-vector-write

From: Daniel Llorens <daniel.llor...@bluewin.ch> * NEWS: Add specific removal notice. * doc/ref/api-data.texi: Remove documentation on uniform-vector-read!, uniform-vector-write. --- NEWS | 7 +++ doc/ref/api-data.texi | 33 - 2

[PATCH] Fix more corner cases in truncated-print

From: Daniel Llorens <daniel.llor...@bluewin.ch> * libguile/arrays.c (scm_i_print_array_prefix, scm_array_print_prefix): New functions. (scm_i_print_array): Reuse scm_i_print_array_prefix(). Make sure to release the array handle. * module/ice-9/pretty-print.scm (truncated-print): Add

[no subject]

This (I think last) patch for truncated-print adds support for bitvectors and also makes sure to print the correct array print prefix when it's not trivial (non-zero base indices or zero dimensions). For this I need to pull out a piece of scm_i_print_array as array-print-prefix.

Fix array corner cases in truncated-print

This patch fixes a few corner cases in ee2125c63973e5ebef2a04eb60d85e6a2b3ea412, especially rank-0 arrays which give an error there. Regards Daniel

Enable truncation of exception output

(I've messed up with git send-email, the patch with this email is at http://lists.gnu.org/archive/html/guile-devel/2017-02/msg8.html). Some objects have large printed representations and trying to print them can kill the terminal. This is a serious problem when handling e.g. big arrays. For

[PATCH 2/2] Let (format) used in exceptions be overriden

From: Daniel Llorens <daniel.llor...@bluewin.ch> * module/ice-9/boot-9.scm (exception-format): new variable. Globally replace uses of (format) by (exception-format). --- module/ice-9/boot-9.scm | 54 ++--- 1 file changed, 29 insertions(

[PATCH 1/2] Support arrays in truncated-print

From: Daniel Llorens <daniel.llor...@bluewin.ch> * module/ice-9/pretty-print.scm (print): Handle general arrays. * test-suite/tests/print.test: Test truncated-print with general arrays. --- module/ice-9/pretty-print.scm | 21 +++-- test-suite/tests/print.test

name an array function (follow up from guile-user)

See https://lists.gnu.org/archive/html/guile-user/2016-12/msg00014.html. This is just renaming, but the doc could use a review. Thanks.

[PATCH] Final names for new array functions

From: Daniel Llorens <daniel.llor...@bluewin.ch> Globally rename (array-from* -> array-slice), (array-from -> array-cell-ref), (array-amend! -> array-cell-set!), (array-for-each-cell -> array-slice-for-each). --- doc/ref/api-data.te

Re: GNU Guile 2.1.5 released (beta)

On 10 Dec 2016, at 18:00, guile-devel-requ...@gnu.org wrote: > Date: Sat, 10 Dec 2016 05:16:08 -0800 > From: Matt Wette > To: guile-devel@gnu.org > Cc: Andy Wingo > Subject: Re: GNU Guile 2.1.5 released (beta) > Message-ID:

[PATCH] Make scm_gc_warn_proc() write directly to stderr

From: Daniel Llorens <daniel.llor...@bluewin.ch> This avoids a deadlock due to the lookup of cur_warnport_fluid while an allocation is ongoing. * libguile/gc.c (scm_gc_warn_proc): write the warning directly to stderr. --- libguile/gc.c | 34 +++--- 1 file c

Re: [PATCH] Patchset related to array functions

On 31 Aug 2016, at 11:46, Andy Wingo wrote: > On Wed 31 Aug 2016 11:28, Andy Wingo writes: > >> On Thu 14 Jul 2016 20:20, Andy Wingo writes: >> >>> I think the concerns are: >>> >>> (1) Do inlined definitions get inlined? >>> (2) Are

[PATCH] [wip] c99 inline

From: Daniel Llorens <daniel.llor...@bluewin.ch> --- libguile.h | 1 - libguile/Makefile.am| 2 -- libguile/__scm.h| 69 - libguile/_scm.h | 1 - libguile/array-handle.c | 3 +++ libguile/array-handle.

Re: [PATCH] Patchset related to array functions

On 14 Jul 2016, at 20:20, Andy Wingo wrote: > I think the concerns are: > > (1) Do inlined definitions get inlined? > (2) Are external definitions reified as well? > (3) Do we avoid reifying definitions in each compilation unit? > (4) Can you dlsym() an inline function? > >

Re: GNU Guile 2.1.3 released

On 24 Jun 2016, at 18:18, Matt Wette <matt.we...@gmail.com> wrote: > >> On Jun 23, 2016, at 9:11 AM, Andy Wingo <wi...@pobox.com> wrote: >> >> On Thu 23 Jun 2016 14:59, Daniel Llorens <daniel.llor...@bluewin.ch> writes: >> >>>

Re: GNU Guile 2.1.3 released

>> On Jun 19, 2016, at 2:31 AM, Andy Wingo wrote: >> >> We are pleased to announce GNU Guile release 2.1.3. > > Tried on my Mac OS 10.10.5 against Macports 2.3.4 w/ gcc-mp-5. > configure went OK > make went OK > make check generated FAIL for test-language and

Request for review of branch lloda-array-support

Hello fellow Guilers, I'd like to have this branch merged in master. It is already rebased on top. http://git.savannah.gnu.org/gitweb/?p=guile.git;a=shortlog;h=refs/heads/lloda-array-support A summary: * New functions array-from array-from* array-amend! array-amend! array-for-each-cell

Re: Slow compile times on master

On 16 Sep 2015, at 18:01, guile-devel-requ...@gnu.org wrote: > From: Tristan Colgate > To: guile-devel > Subject: Slow compile times on master > Message-ID: >

[patch] array slice functions

Hello, The patches I've just pushed lloda-array-support (ending in http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=64fa67c2f0e08e42a60921db4aa77fa3e52d3fa6) implement the functions (array-from) and (array-amend!), to take or modify array prefix slices. The patches include

[PATCH] parameterize programs used by autogen.sh

I needed this in OS X w/ MacPorts where GNU libtoolize is called glibtoolize. This or a version of this is probably useful in other situations. Thanks, Daniel o.patch Description: Binary data

[PATCH] parameterize programs used by autogen.sh

Date: Mon, 06 Oct 2014 15:25:10 +0200 From: l...@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: guile-devel@gnu.org Subject: Re: [PATCH] parameterize programs used by autogen.sh I ended up reinstating the strategy that chooses ?glibtoolize? based on ?uname -s?. Let me know what you think.

Re: [patch] literal arrays in master

I have pushed a version of these patches to a new branch lloda-array-support in Savannah. If you would like to review them, please review them from there. Thanks, Daniel

[patch] literal arrays in master

Hello, these two patches fix the “don’t know how to intern” error in master when the compiler encounters a literal array (e.g. #2()) in the REPL. All existing array tests pass, but the error didn't happen when loading files (e.g. if you load a file that has (define a #2()) somewhere, that was

Unexpected srfi-4 C Interface Change in 2.0.10

Message: 2 Date: Wed, 19 Mar 2014 10:22:40 -0400 From: Barry Fishman barry_fish...@acm.org To: guile-devel@gnu.org Subject: Unexpected srfi-4 C Interface Change in 2.0.10 Message-ID: m37g7qxo7j.fsf@barry_fishman.acm.org Content-Type: text/plain When building C interface code using

Re: include can't work

Date: Fri, 15 Nov 2013 15:40:47 +0800 From: Nala Ginrut nalagin...@gmail.com I encountered a bug while trying include some file: --cut scheme@(guile-user) (include aa.scm) While compiling expression: ERROR: In procedure string-length: Wrong

Re: attempt at array cleanup

Hello, I've rebased this branch on top of master. It is at https://gitorious.org/guile-stable-2-0-array-cleanup/guile-stable-2-0-array-cleanup/commits/master-ra0 I had conflicts in about 10 of the 50 patches: * scm_i_print_bytevector(), that I had rewritten and had changed from stable-2.0

Re: attempt at array cleanup

On May 1, 2013, at 01:10, Daniel Llorens wrote: In the ra0 branch, that still fails, and this also fails: scheme@(guile-user) #1b@1(#t #t) While compiling expression: ERROR: In procedure uniform-array-bytevector: Wrong type (expecting uniform contiguous array): #1b@1(#t #t) I have now

Re: vectors are something else

On Apr 16, 2013, at 08:19, Mark H Weaver wrote: Yes, I did, and generally I strongly prefer column [1], but we have to be very careful what changes we make in a stable release series that might break compatibility with existing code. I find this frustrating as well, which is one reason why

Re: vectors are something else

Date: Fri, 12 Apr 2013 17:43:14 -0400 From: Mark H Weaver m...@netris.org I've not yet had time to carefully read this thread, but I wanted to say that I think we *should* prohibit passing arrays to the vector interfaces. When we have native code generation, then it will be possible to make

Re: vectors are something else

On Apr 15, 2013, at 14:28, Daniel Hartwig wrote: Though such an array is potentially still a vector according to the simple explanation in the manual. So this requires introducing a more complicated discussion of when is an array a vector. Not really. One just needs to say 'these functions

vector types poll

Let's please agree on a behavior so we can start closing bugs. These are all the objects accepted by the array interface. I've filled the table with some ready-made choices that I think are at least internally consistent. ; -- (import (rnrs bytevectors)) (define (every-two a)

Re: vector types poll

On Apr 16, 2013, at 00:47, Daniel Hartwig wrote: Is column [4] intentionally missing from all but the first set? I was expecting it for atleast s8vector. I wasn't sure, but it makes sense. Then the same for bitvector, I think. What about bytevector? Should it remain a special 'raw' type?

Re: vectors are something else

On Apr 16, 2013, at 04:00, Mark H Weaver wrote: [1] have vector- ops only accept vector- types. This removes container type dispatch from the vector- ops but not from the array- ops. The last patch set I've sent to the list goes in this direction. It matches the behavior of other vector-like

Re: vectors are something else

On Apr 12, 2013, at 01:53, Daniel Hartwig wrote: On 11 April 2013 07:07, Daniel Llorens daniel.llor...@bluewin.ch wrote: After the array-map patches, I've gone through the vector/array implementation and there's some stuff I'd like to fix. In stable-2.0 today: (define a (make-typed

Re: vectors are something else

Message: 8 Date: Fri, 12 Apr 2013 18:15:05 +0800 From: Daniel Hartwig mand...@gmail.com Too restrictive IMO, you may as well just not permit any array passed to vector interfaces. Being restrictive would be my preference, yes. [Besides, you can already get at the underlying vector using

Re: vectors are something else

Date: Fri, 12 Apr 2013 22:06:38 +0800 From: Daniel Hartwig mand...@gmail.com Great. This strikes a nice balance, with simple enough semantics and flexability to massage array data for vector-coded modules. I doubt _anyone_ will miss using non-0-indexed arrays that way. I personally think

Re: vectors are something else

On Apr 11, 2013, at 01:07, Daniel Llorens wrote: Force, and assume, inc and base to be 1 0 for uniform-vector / [srfi4type]vector / vector. Correction: inc, base and lbnd to be 1, 0 and 0 is what I mean.

vectors are something else

After the array-map patches, I've gone through the vector/array implementation and there's some stuff I'd like to fix. In stable-2.0 today: (define a (make-typed-array ''f64 0 '(1 2)) a = #1f64@1(0.0 0.0) so far so good. (uniform-vector? a) = #t (f64vector-ref? a) = #t so far so good.

Re: array-copy! is slow array-map.c

This patch replaces the scm_generalized_vector_get_handle() in the rank-1 functions by scm_array_get_handle(). These calls came from the GVSET/GVREF code that I spliced in there, but the arguments are known to be rank-1, so there's no reason not to use the simpler call. Regards

Fwd: array-copy! is slow array-map.c

This patch replaces the scm_generalized_vector_get_handle() in the rank-1 functions by scm_array_get_handle(). These calls came from the GVSET/GVREF code that I spliced in there, but the arguments are known to be rank-1, so there's no reason not to use the simpler call. Regards

Re: array-copy! is slow array-map.c

On Apr 5, 2013, at 19:20, Ludovic Courtès wrote: Daniel Llorens d...@jast.ch skribis: +(with-test-prefix array-copy! + + (with-test-prefix rank 2 +(pass-if (let ((a #2((1 2) (3 4))) + (b (make-array 0 2 2)) Can you make that: (with-test-prefix array-copy

Re: array-copy! is slow array-map.c

On Apr 3, 2013, at 14:50, Ludovic Courtès wrote: Daniel Llorens d...@jast.ch skribis: These two patches do it for array-map!. The first patch avoids cons for the 1-argument case. The second patch removes the double indirection for the first two arguments in every case. Since there's

Re: array-copy! is slow array-map.c

On Apr 3, 2013, at 19:06, Ludovic Courtès wrote: Daniel Llorens d...@jast.ch skribis: From eb4bbb3f42a4a0fcf1d51ecacd557606533d5b40 Mon Sep 17 00:00:00 2001 From: Daniel Llorens daniel.llor...@bluewin.ch Date: Tue, 2 Apr 2013 15:23:55 +0200 Subject: [PATCH 2/5] Avoid per-element cons

Re: array-copy! is slow array-map.c

Attached 1st a patch with some array-copy! tests, then the array-fill! patch split in two parts. Thanks! Daniel 0001-Tests-for-array-copy.patch Description: Binary data 0002-Remove-double-indirection-in-array-fill.patch Description: Binary data

Re: array-copy! is slow array-map.c (was: Extremly slow for format string-join)

On Apr 1, 2013, at 19:15, Daniel Llorens wrote: Third, none of the above are causing the slowness of array-copy!. I noticed that there's a double indirection in racp(). The second patch removes it. Actually this double indirection goes on all over array-map.c and I don't understand why

Re: array-copy! is slow array-map.c (was: Extremly slow for format string-join)

On Apr 2, 2013, at 12:19, Daniel Llorens wrote: On Apr 1, 2013, at 19:15, Daniel Llorens wrote: Third, none of the above are causing the slowness of array-copy!. I noticed that there's a double indirection in racp(). The second patch removes it. Actually this double indirection goes

Re: array-copy! is slow array-map.c (was: Extremly slow for format string-join)

This patch is for array-for-each. Only the first argument. Before: scheme@(guile-user) (define a (make-array 1 100 10)) scheme@(guile-user) ,time (let ((x 0)) (array-for-each (lambda (a) (set! x (+ a x))) a) x) $8 = 1000 ;; 0.621887s real time, 0.620181s run time. 0.00s spent in

Re: array-copy! is slow array-map.c (was: Extremly slow for format string-join)

Hello, sorry for the repeated message earlier. Ok, i think it's clear that all these double indirections can be eliminated globally by composing the strides of the array descriptor with the stride of SCM_I_ARRAY_V (array) and using that directly in the array descriptor. Is there any reason

Re: Extremly slow for format string-join

Hello, From: Daniel Hartwig mand...@gmail.com 2013/4/1 Nala Ginrut nalagin...@gmail.com: I've tried to implement a function to mimic string multiply like Python: asdf * 10 --code (define (str* str n) (format #f ~{~a~} (make-list n str))) or (define

array operations

On Mar 4, 2013, at 03:27, Noah Lavine wrote: (I'm snipping the rest of your message because it needs more thought than I can give it right now.) That message contained a number of errors, the consequence of talking before walking, I suppose. I have added a simple reduction operator to the

Re: propose deprecation of generalized-vector-*

On Mar 1, 2013, at 03:42, Noah Lavine wrote: There should still be an operator that splits in other ways, but I agree that we can shortcut that in many cases. One think I like about the frame / cell split is that you know that the result will have the same frame. So I imagine an operator

Re: propose deprecation of generalized-vector-*

On Feb 22, 2013, at 01:22, Noah Lavine wrote: I agree about the speed issue, but I hope it will get better soon. The RTL VM will fix some of it, and native compilation will fix more. That's on Scheme, but there are also many optimization issues related to array operations. Temporaries,

Re: propose deprecation of generalized-vector-*

On Feb 18, 2013, at 16:55, Andy Wingo wrote: It could make sense, yes. What do others think? What happens for array-set!? Care to propose a patch? Patch is attached. It looks a bit unwieldy because I am duplicating scm_array_handle_pos(), and I also had to fix the recent array_ref_1

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

Re: propose deprecation of generalized-vector-*

On Jan 21, 2013, at 17:11, Andy Wingo wrote: Hi, Sorry for the long delay. Deprecating the generalized-vector functions sounds mostly sensible to me, and the proposed semantics of array-length sound fine. Attached is a first patch in that direction. The changes look good to me. The

Re: propose deprecation of generalized-vector-*

On Jan 22, 2013, at 15:31, Daniel Llorens wrote: On Jan 21, 2013, at 17:11, Andy Wingo wrote: I always wondered why vector-ref and vector-set! didn't do what generalized-vector-ref and generalized-vector-set! did. I mean, they are primitive generics. Might it make sense to allow vector

Re: propose deprecation of generalized-vector-*

On Jan 22, 2013, at 21:52, Andy Wingo wrote: Hello, Handling stride and bounds is not a problem. The generic array handle interface lets us do this in a straightforward way. Certainly, but in this case, a vector is just an array of rank 1. I guess I don't value that much having a specific

Re: propose deprecation of generalized-vector-*

5. Re: propose deprecation of generalized-vector-* (Ludovic =?utf-8?Q?Court=C3=A8s?=) Yes. That procedure would only make sense for one-dimensional arrays anyway. It could just as well throw an error when passed a multi-dimensional array, no? I think that there should be a

Re: propose deprecation of generalized-vector-*

On Sep 19, 2012, at 18:00, guile-devel-requ...@gnu.org wrote: Date: Wed, 19 Sep 2012 13:02:25 +0100 From: Peter TB Brett pe...@peter-b.co.uk To: guile-devel@gnu.org Subject: Re: propose deprecation of generalized-vector-* ... It seems to me that array-length should return the first

propose deprecation of generalized-vector-*

Hello, today I filed a bug on generalized-vector-list http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12465 I remember similar bugs in the past, and I'm thinking that these functions are redundant since we have array-ref, array-list, and so on, which also work on strings, uniform vectors, etc.

Re: Growable arrays

Message: 2 Date: Thu, 14 Jun 2012 10:33:36 -0400 From: Mark H Weaver m...@netris.org Although Scheme vectors should remain fixed-size for reasons I have given elsewhere in this thread, Guile also includes a more complex 'array' type that includes features such as arbitrary rank (i.e.

Re: [PATCH] Miscellaneous for 2.0

Hello list, Any chance these patches could be committed? they seem to have been lost in the stream… Thanks, Daniel On Mar 2, 2011, at 18:00, guile-devel-requ...@gnu.org wrote: 1. [PATCH] Miscellaneous for 2.0 (Mark H Weaver) 2. [PATCH 1/4] Fix bytevectors VALIDATE_REAL to test

Broken VALIDATE_REAL in master

Such things as #f64(+inf.0) fail. Attached a fix. I tried to look into SCM_VALIDATE_REAL per the comment, I didn't get far. Regards, Daniel — diff --git a/libguile/bytevectors.c b/libguile/bytevectors.c index f014697..cc50e25 100644 --- a/libguile/bytevectors.c +++

Re: bug in scm_arrray_handle_[srfi tag]_elements

On 12 Jan, 2010, at 20:16, Andy Wingo wrote: I gave it another go; please take a look at it :) Looks good! I had not noticed the other two cases. Thanks, Daniel

bug in scm_arrray_handle_[srfi tag]_elements

Hello, That function and the _writable_elements() version are broken for shared arrays because they return a pointer to the beginning of the enclosing array instead of a pointer to their own beginning. This patch against master fixes the issue for me. Cf. the implementation of

Re: bug in scm_arrray_handle_[srfi tag]_elements

On 12 Jan, 2010, at 0:22, Andy Wingo wrote: I've fixed the issues compiling e.g. #...@2(1 2 3) and the like, Thanks for the great support. and applied this patch as well. Thanks for the reports. Anything else? :) Yeah… your patch is wrong :) -return h- elements;

Re: bug in scm_arrray_handle_[srfi tag]_elements

On 12 Jan, 2010, at 0:49, Daniel Llorens del Río wrote: -return h- elements; \ +return ((const ctype*) h-elements) + h- base; \ I wrote it this way at first, too, but it doesn't work for c32/c64 because ctype

Re: guile arrays in 1.9

On 7 Jan, 2010, at 17:29, Andy Wingo wrote: Could be that the tests are running only with the interpreter, and the bugs that you're seeing only appear when an array is attempted to be serialized out to object code. Mm, I don't know how to debug that… You are :-)) Just so… :) More. In

guile arrays in 1.9

Hello, array-list is broken in 1.9.6: scheme@(guile-user) (array-list #(0 1)) ERROR: Value out of range: -1 Patch for libguile/generalized-arrays.c: 246c246 size_t i, lbnd; --- ssize_t i, lbnd; 251c251 pos += (i - h-dims[dim].ubnd) * inc; --- pos += (i - lbnd) *

make-shared-array

Hello, I've found a typo in the documentation and a bug in libguile/unif.c/ scm_make_shared_array(). The last example says: (make-shared-array #1(a b c d e f g h i j k l) (lambda (i) (* i 3)) 4) The 2nd argument should be (lambda (i) (list (* i 3))).

Re: 1.8.0, configure socket.h test fails in OS X

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -Wall -Wmissing- prototypes -Werror -MT posix.lo -MD -MP -MF .deps/posix.Tpo -c posix.c -fno-common -DPIC -o .libs/posix.o In file included from /usr/include/netinet/in.h:78, from /usr/include/netdb.h:86,

Re: Guile-devel Digest, Vol 40, Issue 15

On 29 Mar, 2006, at 19:04, [EMAIL PROTECTED] wrote: I had the very same error. You'll have to edit configure.in and rerun configure, look here: http://lists.gnu.org/archive/html/guile-devel/2006-02/msg00039.html I mean, run autoconf, of course. Sorry.