> 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?
>
> Thanks
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
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
> 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 repost
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
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 middle, it is possible t
From: Daniel Llorens
* 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/mutable/immutable vectors with
sort
Please ignore this patch, I saw it produces an error elsewhere. I'm sending an
updated patch.
Regards
Daniel
From: Daniel Llorens
* 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 --
test-suite/tests/sort.test | 24
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.
E.g
Guile source is now C99. Can we get rid of this flag?
Regards
Daniel
On 10 Mar 2017, at 09:47, Andy Wingo wrote:
> I have a crazy idea :) What about, we just let (ice-9 format) be
> "format" ? Right now loading (ice-9 format) does a set! to format, as
> you know, overriding the core binding. This is unnecessary and
> complicated. I see that using (ice-9 forma
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 installed (system repl c
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
>>> though it prints the error argument as
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
> though it prints the error argument as one.
>
> --8<---cut here---start---
From: Daniel Llorens
* 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 files changed, 7 insertions(+), 33
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 trunca
From: Daniel Llorens
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/vectors.c (scm_vector_writable_elements): Replace
From: Daniel Llorens
* 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: Test scm_array_slice_for_each with
non-zero lower
From: Daniel Llorens
* 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-print.scm (truncated-print): Support
From: Daniel Llorens
* 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-suite/Makefile.am: Run the new
From: Daniel Llorens
* 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/sort.c (scm_restricted_vector_sort_x
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 ()
> (with-default-trap-handler le-tr
From: Daniel Llorens
* module/ice-9/arrays.scm (array-copy, typed-array-copy): New
functions. 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/sort.c
From: Daniel Llorens
* 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-suite/Makefile.am: Run the new
From: Daniel Llorens
* 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-print.scm (truncated-print): Support
From: Daniel Llorens
* 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: Test scm_array_slice_for_each with
non-zero lower
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 trunca
From: Daniel Llorens
* libguile/vectors.c: Don't include arrays.h.
---
libguile/vectors.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libguile/vectors.c b/libguile/vectors.c
index b9613c5..5e53bf4 100644
--- a/libguile/vectors.c
+++ b/libguile/vectors.c
@@ -29,7 +29,6 @@
#in
From: Daniel Llorens
* 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 files changed, 7 insertions(+), 33
From: Daniel Llorens
* 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 a case for
bitvectors. In the
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.
From: Daniel Llorens
* module/ice-9/pretty-print.scm (print): In the array case, pass
#:inner? along to (print-sequence), unless we're at the last dimension
of the array.
Special case for 0-rank arrays, which cannot be empty and have no
length.
* test-suite/tests/print.test: Test so
This patch fixes a few corner cases in
ee2125c63973e5ebef2a04eb60d85e6a2b3ea412, especially rank-0 arrays which
give an error there.
Regards
Daniel
(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
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 | 54 ++---
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/module
This patch to master fixes (truncated-print) to support general
arrays. It tries to at least print the #(rank)(type) tag and the rest of
the output is handled as a nested list.
Regards
Daniel
From: Daniel Llorens
* 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 | 17 -
2 files changed, 35
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.
From: Daniel Llorens
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.texi | 112 +++-
libguile
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: <3851ac25-3d0a-4f0e-8fd5-8606656c3...@gmail.com>
> Content-Type: text/p
From: Daniel Llorens
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 changed, 3 insertions(+), 31
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 external definitions reified as well?
>>> (3) Do we avoid
From: Daniel Llorens
---
libguile.h | 1 -
libguile/Makefile.am| 2 --
libguile/__scm.h| 69 -
libguile/_scm.h | 1 -
libguile/array-handle.c | 3 +++
libguile/array-handle.h | 12 ++---
libguile/gc.c
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?
>
> All these answers s
On 24 Jun 2016, at 18:18, Matt Wette wrote:
>
>> On Jun 23, 2016, at 9:11 AM, Andy Wingo wrote:
>>
>> On Thu 23 Jun 2016 14:59, Daniel Llorens writes:
>>
>>>>> We are pleased to announce GNU Guile release 2.1.3.
>>>>
>>>
>> 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 test-stack-overflow and
> stopp
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 array-
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:
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi All,
> I thought I'd see how things are looking on master (great to see work
On 18 Feb 2015, at 09:08, Mark H Weaver wrote:
> ...
> Can you post an updated patch?
sure, against current master.
0001-Non-vector-1D-arrays-print-as-1.patch
Description: Binary data
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 docume
> 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 t
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
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
Now with a test. The first patch makes most of test-suite/tests/arrays.test run
under both the compiler and the interpreter. It produces a large amount of
errors under the compiler. The next two patches are the same as in the last
email and fix these errors.
However, it's interesting to me tha
Fix the first patch to verify an assumption used in the new array SCM layout.
Regards
Daniel
0001-Pack-array-dimensions-in-array-object.patch
Description: Binary data
0002-Intern-general-arrays.patch
Description: Binary data
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
> Message: 2
> Date: Wed, 19 Mar 2014 10:22:40 -0400
> From: Barry Fishman
> To: guile-devel@gnu.org
> Subject: Unexpected srfi-4 C Interface Change in 2.0.10
> Message-ID:
> Content-Type: text/plain
>
> When building C interface code using scm_f32vector_writable_elements()
> in 2.0.10 and on t
> Date: Fri, 15 Nov 2013 15:40:47 +0800
> From: Nala Ginrut
> 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 type argume
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 to
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
Hello,
a few weeks ago, a few bugs and some peculiar performance behavior prompted me
to start looking at the array code in Guile.
I have put what I've done on branch ra0 here:
https://gitorious.org/guile-stable-2-0-array-cleanup/guile-stable-2-0-array-cleanup/commits/ra0
This is ~50 commits
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 w
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 vect
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? B
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) (make-sha
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 function
Date: Fri, 12 Apr 2013 17:43:14 -0400
From: Mark H Weaver
> 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 the vector
Date: Fri, 12 Apr 2013 22:06:38 +0800
From: Daniel Hartwig
> 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 that offset index
Message: 8
Date: Fri, 12 Apr 2013 18:15:05 +0800
From: Daniel Hartwig
> 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 ?shared-array-
On Apr 12, 2013, at 01:53, Daniel Hartwig wrote:
> On 11 April 2013 07:07, Daniel Llorens 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:
>>
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.
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.
(u
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
Danie
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
Danie
On Apr 5, 2013, at 19:20, Ludovic Courtès wrote:
> Daniel Llorens 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)
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
0003-Deprecate-scm_array_fill_int.p
On Apr 3, 2013, at 19:06, Ludovic Courtès wrote:
> Daniel Llorens skribis:
>
>> From eb4bbb3f42a4a0fcf1d51ecacd557606533d5b40 Mon Sep 17 00:00:00 2001
>> From: Daniel Llorens
>> Date: Tue, 2 Apr 2013 15:23:55 +0200
>> Subject: [PATCH 2/5] Avoid per-element co
On Apr 3, 2013, at 14:50, Ludovic Courtès wrote:
> Daniel Llorens 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
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 n
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
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.
>> Act
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.
>> Act
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&#
> Message: 5
> Date: Mon, 1 Apr 2013 15:40:48 +0800
> From: Daniel Hartwig
> To: guile-devel@gnu.org
> Subject: Re: Extremly slow for format & string-join
> On 1 April 2013 14:59, Daniel Llorens wrote:
>> How can it be slower to allocate the result at once?
>
Hello,
> From: Daniel Hartwig
>
> 2013/4/1 Nala Ginrut :
>> 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 (str* str n)
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
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
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, ord
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
opt
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
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
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. Mi
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.
> On 5 December 2012 15:21, Nala Ginrut wrote:
> I don't think it's proper to use (ansi term-color)
> purposely, since it's not in Guile.
Maybe we should start moving a few things from guile-lib into Guile proper.
(ansi term-color) may be a candidate. I think that (os process) should be
merge
> 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 fun
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
> To: guile-devel@gnu.org
> Subject: Re: propose deprecation of generalized-vector-*
...
> It seems to me that array-length should return the first non-unity
> dimensio
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.
> Date: Thu, 14 Jun 2012 21:35:48 +0200
> From: David Kastrup
> To: guile-devel@gnu.org
> Subject: Re: Growable arrays
> Message-ID: <87y5npu1nv@fencepost.gnu.org>
> I should think that being able to interchange 0/1 based would be the
> most important application. Then you would want to ha
> Message: 2
> Date: Thu, 14 Jun 2012 10:33:36 -0400
> From: Mark H Weaver
>
> 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. number
> of d
1 - 100 of 115 matches
Mail list logo
