Hello list,
This part of guile-2.0.pc is quite confusing and I think it's wrong:
...
Libs: -L${libdir} -lguile-2.0 -lgc
...
Cflags: -I${pkgincludedir}/2.0 -pthread
Shouldn't the '-pthread' be in Libs, instead of Cflags? Compilation can fail
when relying on pkg-config [1] (the bug mentions
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
Andy Wingo wi...@pobox.com skribis:
On Thu 04 Apr 2013 09:38, Mark H Weaver m...@netris.org writes:
I just noticed that section 6.19.10 is horribly out of date. It's also
out of place, in a section of the manual that talks about the module
mechanism.
Frankly, I think it should simply be
On 15 April 2013 16:26, Jan Synacek jsyna...@redhat.com wrote:
Hello list,
This part of guile-2.0.pc is quite confusing and I think it's wrong:
...
Libs: -L${libdir} -lguile-2.0 -lgc
...
Cflags: -I${pkgincludedir}/2.0 -pthread
Shouldn't the '-pthread' be in Libs, instead of Cflags?
On 15 April 2013 19:29, Daniel Llorens daniel.llor...@bluewin.ch wrote:
[1] have vector- ops only accept vector- types. …
[2] force all vector objects into arrays. …
For example in [1], you'd prefer vector- to *reject* strided rank-1 arrays
(inc!=1), because those require a descriptor and
On 15 April 2013 19:58, Daniel Hartwig mand...@gmail.com wrote:
or peculiar to the linker, libguile on your system, other?
I see that this is related to the linker in fedora, which debian seems
also in the process of supporting. Indirect linkage like this is out
(apparently), and LIBS should
On 15 April 2013 21:45, Daniel Hartwig mand...@gmail.com wrote:
On 15 April 2013 19:58, Daniel Hartwig mand...@gmail.com wrote:
or peculiar to the linker, libguile on your system, other?
I see that this is related to the linker in fedora, which debian seems
also in the process of supporting.
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
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)
On 15 April 2013 22:08, Daniel Llorens daniel.llor...@bluewin.ch wrote:
On Apr 15, 2013, at 14:28, Daniel Hartwig wrote:
Is it
really much faster to do one or the other:
if lbnd != 0: error
index = …
vs:
index = lbnd + ...
The second should actually be just
index = ...
You do
On 15 April 2013 22:10, Daniel Llorens daniel.llor...@bluewin.ch wrote:
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
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?
Daniel Llorens daniel.llor...@bluewin.ch writes:
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
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
14 matches
Mail list logo
