On May 22, 2012, at 04:17, Andy Wingo wrote:
> These are related. Until recently, the intention was that 7.1 was the
> minimum version, though we supported compilation against 6.8, which is
> the version in Debian stable. As it is, the final 7.2 release was only
> made a couple weeks ago, which i
On May 22, 2012, at 03:54, Andy Wingo wrote:
> On Mon 21 May 2012 07:45, Ken Raeburn writes:
>
>> I've also checked in on master a couple pretty straightforward-looking
>> fixes. I don't know if either would be applicable to the current
>> release.
>
> T
After reading the "dynamic ffi and C struct" thread this weekend, I started
thinking, "I wonder if that's really done so as to handle X and Y and Z, and if
we're actually testing it well enough", and got the urge to do another Mac
build, which I hadn't done in a while. After installing libgc 7.
On Nov 12, 2011, at 10:00, joa...@verona.se wrote:
>> Hmm... this touches on a political issue I'd been avoiding thinking about.
>> Namely, adding Guile to Emacs, with Guile's new FFI support, would make
>> dynamically loading new executable code into Emacs easy, technically,
>> including non-G
On Nov 11, 2011, at 04:46, joa...@verona.se wrote:
> Where is your public repository? I would be interested to have a look.
Try git://raeburn.scripts.mit.edu/guile-emacs.git. But it's about two years
old. :-(
One of these days
> As a concrete example, one could use guiles libffi integration
On Oct 9, 2011, at 15:22, Noah Lavine wrote:
>
> One question I have is, how much of Emacs' C code can Guile use right
> now? I guess Ken Raeburn's patches are the ones that address that, but
> I don't know what is left to do.
With the stuff I've done, not much execution happens with Guile's engi
On May 17, 2011, at 14:59, Mark H Weaver wrote:
>> But the question I was after was, even if we want to use the full
>> range of the values, do we need the entire set to be representable *in
>> immediate form*? I doubt the very largest and smallest values are
>> used often, so making just those va
On May 15, 2011, at 11:47, Andy Wingo wrote:
> However... note that GCC obsoleted all vax ports but openbsd and netbsd
> in 4.3, removed them in 4.4, and just obsoleted it on netbsd recently I
> think. Just saying :)
I knew a bunch of ancient OSes for Vax were made obsolete in gcc, but last I
lo
On May 14, 2011, at 05:47, Andy Wingo wrote:
> However, I realized that this isn't going to work on 32-bit, and for an
> unexpected reason: GC. The problem is that the low 32-bits can be
> interpreted as a pointer, so you need to tag those bits to make the
> payloads of immediate values like integ
On May 12, 2011, at 06:17, Andy Wingo wrote:
> I'm looking at new SCM representation and tagging possibilities in 2.2.
> Read the whole mail please, as it's a little complicated.
Iteresting
> I would like to revisit the SCM representation and tagging scheme in
> 2.2. In particular, I wou
On Mar 25, 2011, at 06:40, Ludovic Courtès wrote:
> I guess we could even add the new opcode in stable-2.0 because Andy
> tweaked objcode version check to be smarter—i.e., 2.0.1 would be able to
> read objcodes produced by either 2.0.1 or 2.0.0.
If I switch from a machine with 2.0.1 installed to a
On Feb 23, 2011, at 15:14, Bruce Korb wrote:
> * guile should provide autoconf macros to do checking,
> like for wrong version headers.
That seems like a good idea, but unless all the other packages' header
directories have already been added to the include path by the time this test
is run, it
On Feb 22, 2011, at 07:00, Hans Aberg wrote:
[quoting others...]
>>> I noticed that that is possible - in fact, to make sure to get it right, I
>>> removed all Guile headers in /usr/local/include/ and reinstalled guile-2.0.
>>>
>>> The Guile 1.8 header libguile.h is in /usr/local/include/, but th
On Feb 10, 2011, at 17:19, Andy Wingo wrote:
>> procproc.c: There's a mutex to protect overrides, but it looks like
>> set-procedure-property! doesn't use it correctly; it should look more
>> like set-object-property! does.
>
> I'm going to punt on this one, since it cannot access the hash table i
On Feb 10, 2011, at 17:19, Andy Wingo wrote:
> Hey Ken,
>
> I got tired of seeing your mail marked as starred in my inbox, so I
> decided to take a look at it ;-)
Thanks! :-)
I'm sorry I haven't had time in a while to investigate more.
>> symbols.c: I don't think 'symbols' is handled safely. Bu
On Feb 12, 2011, at 06:55, Andy Wingo wrote:
> Regarding multiple values: instead of unpacking values objects (ugh),
> can you instead make versions of _divide that return two values
> directly, as output arguments?
Or maybe a function returning a struct of two SCM fields (or a single
array-of-2
On Feb 13, 2011, at 08:55, Noah Lavine wrote:
> OS X, which I use, has a somewhat weird field-naming situation. The
> generic sockaddr structure has sa_len, but sockaddr_in has a sin_len
> field.
No, that's normal for a traditional C/UNIX API. Each structure's field names
use a prefix that's an
What platforms have sin_len in the generic sockaddr structure? The one I've
always seen is sa_len, and that's consistent with sa_family in terms of field
name prefixes.
sockaddr -> sa_
sockaddr_in -> sin_
sockaddr_in6 -> sin6_
sockaddr_storage -> ss_
I suspect you'd do fine if
On Jan 28, 2011, at 09:33, Noah Lavine wrote:
>
>> And also... why not rely on gcc's tail-call optimization, in the case
>> where it works? You can check for it at configure-time. I just ran
>> some small tests for tail-calls between functions in separate
>> compilation units and it shows that i
On Nov 28, 2010, at 17:36, Ludovic Courtès wrote:
>>> * A uniform way to invoke native code from the VM, and VM code from
>>> native code -- *preserving tail calls*. This seems to require either
>>> trampolines within the VM or platform-specific tail-call assembly.
>>
>> This one could be hard
On Aug 28, 2010, at 15:20, Andy Wingo wrote:
>> Unfortunately this applies to some internals of the implementation too.
>> For example, "set-object-property!" and friends use a hash table and
>> assoc lists internally.
>
> Fixed, thanks.
>
>> scm_c_issue_deprecation_warning and scm_c_register_ext
(switching to guile-devel from guile-user since I think this is more of a
developers' issue)
On Aug 18, 2010, at 11:56, Andy Wingo wrote (quoting the manual):
> Thus, you need to put in additional synchronizations when multiple
>threads want to use a single hashtable, or any other mutab
On Jun 24, 2010, at 09:03, Andy Wingo wrote:
> There are actually two kinds of begin: one in definition context and one
> in expression context. The former takes 0 or more forms, and splices
> those forms into the input, where the (begin ...) appears. The other
> takes 1 or more expressions, and ev
On Jun 23, 2010, at 17:09, Michael Lucy wrote:
> Is there any scheme expression that will just get ignored when the
> scheme code is compiled?
>
> I'm generating some code with a function like:
>
> (define (gen-update-ab updatea updateb)
> `(begin
> ,(if updatea `(set! a (+ a 1)) `(donothing
On Apr 18, 2010, at 07:41, Andy Wingo wrote:
> Specifically, we should make it so that there is nothing you would want
> to go to a core file for. Compiling Scheme code to native code should
> never produce code that segfaults at runtime. All errors would still be
> handled by the catch/throw mecha
On Apr 19, 2010, at 05:33, Andy Wingo wrote:
> Dunno. To be able to write in native endianness and actually see
> benefits, the data needs to be aligned, too. Integer widths are
> generally chosen as some point in the size/speed vs generality tradeoff.
> I would be very hesitant about poking some o
Good stuff, Andy!
On Apr 16, 2010, at 07:09, Andy Wingo wrote:
> Currently, Guile has a compiler to a custom virtual machine, and the
> associated toolchain: assemblers and disassemblers, stack walkers, the
> debugger, etc. One can get the source location of a particular
> instruction pointer, for
In case people aren't following the emacs-devel list...
Begin forwarded message:
> From: Thomas Lord
> Date: April 12, 2010 16:05:39 EDT
> To: r...@gnu.org
> Cc: t...@lifelogs.com, emacs-de...@gnu.org
> Subject: Re: Guile in Emacs (was: integer overflow)
>
> On Mon, 2010-04-12 at 08:30 -0400, R
holds a few Scheme variables, and a C
function called from Scheme could print out or return the values stored in the
structure associated with a buffer object denoted by a global variable
"the-current-buffer", which could be changed by calling "set-buffer", etc.
This buffer
On Mar 22, 2010, at 20:04, Neil Jerram wrote:
>> Having just bought a Lemote Yeelong notebook at LibrePlanet [...]
>
> Aside: I was wondering about buying one of those too, but haven't yet
> because of performance concerns. Can it compile Guile successfully, and
> if so how long does it take?
It
On Mar 22, 2010, at 20:04, Neil Jerram wrote:
> Ken Raeburn writes:
>> Yes... you then also need to decide if Guile is exposing GNU/POSIX
>> functionality, whatever the native OS functionality is, or some
>> abstraction...
>
> Ideally, yes, I think. In other words,
On Mar 21, 2010, at 16:51, Neil Jerram wrote:
> First, I've found that completing a successful build (i.e. autogen.sh,
> configure and make) is not at all the end of the story; it's only the
> first part of what is really needed - because at runtime some key pieces
> of function can still be missin
On Mar 4, 2010, at 05:52, Ludovic Courtès wrote:
> I have this:
>
> --8<---cut here---start->8---
> $ grep yyget_leng libguile/c-tokenize.c
> int yyget_leng (void);
> int yyget_leng (void );
> int yyget_leng (void)
Interesting... looks like Apple's not usi
On Mar 2, 2010, at 05:23, Ludovic Courtès wrote:
>>> We don't actually reference yyget_leng elsewhere explicitly; can we just
>>> get rid of the declaration?
>>
>> This patch has been working fine for me on my Mac; we may be able to delete
>> more of the declarations, depending what other lex im
On Mar 1, 2010, at 14:24, Neil Jerram wrote:
> Looks good to me; presumably you'll commit this?
Sure, I'll check it in shortly.
I also just sent a couple of patches in other mail (subject "Re: build
problems"); Jose, you will probably need the patch to doc/ref/Makefile.am as
well.
Ken
On Feb 15, 2010, at 08:41, Ken Raeburn wrote:
> #1: c-tokenize.lex declares yyget_leng() as returning int, but the flex
> template defines it as returning yy_size_t (which is size_t, a.k.a. unsigned
> long), so c-tokenize.c doesn't compile. Changing the declaration in
>
On Feb 28, 2010, at 20:22, Jose A. Ortega Ruiz wrote:
> When building guile form git's HEAD off-tree, i get this error during make:
>
> ../../src/libguile/control.c:279:21: error: control.x: No such file or
> directory
Ah, yeah, I meant to send email about that too. This patch should fix it, an
I tried doing a build on my Mac (running 10.6.2) this morning, and ran into
some problems.
#1: c-tokenize.lex declares yyget_leng() as returning int, but the flex
template defines it as returning yy_size_t (which is size_t, a.k.a. unsigned
long), so c-tokenize.c doesn't compile. Changing the d
On Feb 14, 2010, at 10:50, Andy Wingo wrote:
> My only qualm regards the number of potential pthread_key variables. My
> current emacs session has about 15K functions and 7K variables. Does the
> pthread_key mechanism scale well to this number of thread-local
> variables?
Repeating the IRC info, f
On Nov 28, 2009, at 20:24, Linas Vepstas wrote:
googleing the error messages indicates that anonymous structs
are OK in C, but are somehow bad form in C++, thus gcc
generates this error. I don't understand why this would matter.
The error message you quoted refers specifically to a function tak
On Nov 21, 2009, at 13:22, Andy Wingo wrote:
It's confusing a bit, and delightful :) See
http://wingolog.org/pub/goops-inline-slots.png.
Nice diagram! :-)
Followed up by
http://wingolog.org/archives/2009/11/09/class-redefinition-in-guile :)
Nice description.
But, I'm looking at it, and thi
On Nov 18, 2009, at 04:37, Ludovic Courtès wrote:
From time to time, I test it on some “exotic” hardware architectures
of
the GCC Compile Farm (MIPS, Alpha, PPC64, etc.), and it’s been working
pretty well so far. I also got accounts on Tru64, AIX, and now
Solaris
and HP-UX, which I’m hoping
Picking up this thread again...
I've run some basic tests, and it looks like setting
SCM_DEBUG_TYPING_STRICTNESS to 0 (which causes SCM to be defined as an
integer type) also fails, though not quite as messily as setting it to
2.
On Sep 16, 2009, at 15:20, Andy Wingo wrote:
I don't see i
On Nov 16, 2009, at 01:08, Ken Raeburn wrote:
Andy's just changed a bunch of stuff affecting these files; I've
remerged my changes, but I'm not sure if they're needed any more.
I'll try to examine this further tomorrow.
I had to run the test suite rather than
On Nov 16, 2009, at 08:03, Ludovic Courtès wrote:
As far as encoding names are concerned, Bruno Haible pointed me to
http://www.iana.org/assignments/character-sets and I added a link to
it
in the manual a couple of days ago.
Between your link and Mike's, it looks to me like we should add
s
On Nov 15, 2009, at 17:25, Neil Jerram wrote:
Ken Raeburn writes:
Here's my revised patch. I've simplified the check, and it still
passes the tests (except the options tests that were just committed
with a log message indicating that they don't pass) and doesn't c
The Mac build started failing for me again, complaining about an
unknown encoding "UTF-8;" -- yes, with a semicolon on the end. So it
may not be surprising to find that it's a minor fencepost error in
processing the emacs-style encoding spec in boot-9.scm.
Why did this not show up before f
On Nov 14, 2009, at 12:07, Ken Raeburn wrote:
On Nov 14, 2009, at 08:47, Neil Jerram wrote:
Thanks, Andy. I'm confident now that your patch is correct, Ken, so
please could you apply it? Also please let me know if you're happy
to
do the other changes (mostly comment updat
On Nov 14, 2009, at 08:47, Neil Jerram wrote:
Thanks, Andy. I'm confident now that your patch is correct, Ken, so
please could you apply it? Also please let me know if you're happy to
do the other changes (mostly comment updates) that I suggested to go
with it, or if you'd prefer me to do those
On Oct 31, 2009, at 19:11, Ludovic Courtès wrote:
Looks good to me. In addition we could add this to
‘deprecated.h’: ...SCM_GC_MARK_P...
SCM_GC_MARK_P wasn't deprecated in 1.8.0, so, yeah, if someone might
actually be using it (optimization within a smob mark function?), it
should probabl
Two patches here, both relating to the fact that the GNU "libtool"
package is installed as "glibtool" (both in the main OS and in
macports; haven't checked fink), and "/usr/bin/libtool" is a different
tool, from Apple.
The autogen script wants to display a version number from libtool
befo
On Oct 29, 2009, at 18:24, Ludovic Courtès wrote:
I just took a little bit of a look... on my NetBSD 5.0.1 x86 system,
the __thread support simply uses the %gs segment register,
That’s weird because it should only do such things with the
‘initial-exec’ or ‘local-exec’ thread models; otherwise,
At Andy's suggestion, re-posting the still-pending part that needs
review. Without these changes, the code in the loops applies SCM_CAR
to non-pair objects.
GUILE_AUTO_COMPILE=0\
../meta/uninstalled-env \
guile-tools compile -Wunbo
Since support for "futures" in C has been completely disabled for
some
time, and should be easily implementable in Scheme with the current
thread support, delete the C code.
* libguile/futures.c, libguile/futures.h: Delete.
* libguile/Makefile.am (libguile_la_SOURCES, DOT_
On Oct 23, 2009, at 19:40, Greg Troxel wrote:
Thanks - I think there is actually no tls support yet.
I will take a look at the autoconf issue when I have time - but I'm
very
busy at work this week.
I just took a little bit of a look... on my NetBSD 5.0.1 x86 system,
the __thread support s
The SCM_GC_MARK_P macro doesn't exist any more, but is still mentioned
in a few places. With SCM_DEBUG defined, one of them actually gets
compiled. While looking at this, I also noticed three macros in
deprecated.h (which were there in 1.8) which use non-existent macros
including SCM_GC_M
On Oct 24, 2009, at 09:30, Andy Wingo , n...@a-pb-sasl-sd.pobox.com wrote:
I have been experiencing intermittent segfaults recently, as I
worked on
wip-case-lambda. They would almost always go away immediately -- as
in,
while rebuilding guile, the process would stop because of a segfault,
but
On Oct 18, 2009, at 18:44, Neil Jerram wrote:
I've been trying to reproduce the guardian finalisation problem that
you
see with SCM_DEBUG==1 but, like Ludovic, I haven't had any luck. With
SCM_DEBUG=1 for the whole build (plus the SCM_GC_MARK_P change), I'm
afraid my machine grinds to a halt w
file or piping through more enables buffering and can
produce the problem. The patch below has fixed it for me in my
testing so far. Okay to commit?
Thanks to Andy for suggesting in IRC what the problem might be
Ken
Author: Ken Raeburn
Date: Tue Oct 13 11:45:34 2009 -0400
Flush o
defined as $libdir instead of $pkglibdir is
easy enough, if the current location is where we want those
libraries. Do we need programs to be able to link against them
directly? Do we need non-guile programs to be able to find them with
dlopen? (Is it too late to consider changing it?)
K
On Oct 9, 2009, at 03:54, Ken Raeburn wrote:
The code in regexp.test tries the suffixes ".ISO-8859-1" and
".iso88591" when selecting locale names. I take it that means
there's inadequate standardization on the naming of encodings across
systems? Well, when I make
On Oct 6, 2009, at 17:35, Mike Gran wrote:
Also, I need to revert the regexp.test which seems
to be broken on Darwin but work elsewhere.
Hi, Mike. I've done a little more digging...
The code in regexp.test tries the suffixes ".ISO-8859-1" and
".iso88591" when selecting locale names. I take
On Oct 6, 2009, at 17:35, Mike Gran wrote:
I need to roll back the changes made to i18n.c
that made locale-specific case conversion of strings
work on GNU but break on Darwin. Locale-specific
case conversion of strings works, but only when
the locale is set using setlocale.
Thanks. Though per
On Oct 6, 2009, at 16:05, Daniel Kraft wrote:
If any such value is hit when reading/setting a variable, we do the
needed stuff for handling aliases/foolocal variables instead of
doing the operation directly. While this should work, I fear that
it hits performance once again... But I do not
On Oct 4, 2009, at 10:03, Ludovic Courtès wrote:
I looked again at how/whether we could improve thread-local storage
access, using compiler support (the ‘__thread’ storage class).
For the most part I think the wip-tls changes look good. In the non-
__thread case, though, you've eliminated the
On Sep 30, 2009, at 16:59, Neil Jerram wrote:
I've cherry-picked the following branch_release-1-8 fixes.
With these fixes, indeed, I can't reproduce the problem any more; I
left the test program running for over an hour, whereas before it
would trigger the problem almost immediately.
Thank
On Sep 28, 2009, at 18:42, Neil Jerram wrote:
Regarding the throw from critical section problem, I guess I'm not
seeing this because of not running on a multi-core machine.
You're on a single-core machine? How quaint! ;-)
Can someone
who does see this problem
- run under GDB
- set a breakp
On Sep 25, 2009, at 17:59, Ken Raeburn wrote:
On Sep 16, 2009, at 15:00, Andy Wingo wrote:
Hi Ken,
On Tue 11 Aug 2009 15:59, Ken Raeburn writes:
Perhaps I'm building [Guile] in ways that are unusual for the other
developers (build dir != src dir, libgmp and guile-1.8 installed in
the
On Sep 27, 2009, at 05:10, Ludovic Courtès wrote:
I got version 6.8. It had the function, just not the declaration.
You should use 7.x. In fact, IIRC, 6.x is not detected by ‘configure’
because it has no ‘bdw-gc.pc’.
True, though the error message from the configure script itself
suggeste
On Sep 26, 2009, at 11:45, Mike Gran wrote:
Backing up to bcccf04, it builds okay, but lots of regexp tests fail
with "illegal byte sequence" errors. With "make -k check", that's
the
only error reported.
This does surprise me. I thought I had fixed that problem. Does it
pass
if you repl
On Sep 26, 2009, at 17:02, Ludovic Courtès wrote:
Running srfi-18.test
WARNING: (srfi srfi-18): imported module (srfi srfi-34) overrides
core
binding `raise'
throw from within critical section.
error key: foo
/bin/sh: line 1: 74711 Abort trap ${dir}$tst
FAIL: check-guile
This mu
On Sep 16, 2009, at 15:00, Andy Wingo wrote:
Hi Ken,
On Tue 11 Aug 2009 15:59, Ken Raeburn writes:
Perhaps I'm building [Guile] in ways that are unusual for the other
developers (build dir != src dir, libgmp and guile-1.8 installed in
the same place, libgmp and libunistring install
On Sep 21, 2009, at 13:21, Mike Gran wrote:
There is another curious thing, which may be unrelated
#6 0x7f7ffdb80605 in scm_lfwrite_str (str=0x6e4720,
port=0x5bcba0) at ports.c:1276
#7 0x7f7ffdb848fc in iprin1 (exp=0xfff8,
port=0x5bcba0, pstate=0xdd6770) at print.c:723
On Sep 17, 2009, at 17:53, Ludovic Courtès wrote:
I was thinking we could have a dedicated machine running benchmarks,
say, everyday, and publishing plots somewhere.
I'd suggest multiple machines, if possible. Different operating
systems (for example, I've seen that mutex performance differs
On Sep 7, 2009, at 05:22, Ludovic Courtès wrote:
Non-pair accessed with SCM_C[AD]R: `ERROR: In procedure symbol-
>string:
ERROR: Wrong type argument in position 1 (expecting symbol):
#
Does that mean it’s this whole string that’s accessed with SCM_C[AD]R?
I'm not sure... it should be printin
On Sep 8, 2009, at 19:37, Neil Jerram wrote:
Then, given that you (Ken) think that STRICTNESS 0 doesn't work
either, I'd favour hardcoding the STRICTNESS 1 macros and then
discarding the whole STRICTNESS concept.
That (0 not working) is only a guess, but I'll try it out to see.
I kind of like
BTW, the bdw-gc branch with my patch and SCM_DEBUG==1 still fails
tests on my Mac.
In guardians.c, line 169, SCM_CAR is applied to a non-pair:
Running popen.test
Running ports.test
scm_error_pair_access
Non-pair accessed with SCM_C[AD]R: `ERROR: In procedure symbol->string:
ERROR: Wrong type
I have a suggestion: Let's set SCM_DEBUG=1 by default for the 1.9.x
series.
Clearly, it should be easy to disable, for doing performance testing
builds or whatever. But having it on by default makes it more likely
that we'll catch some kinds of errors sooner.
There are a couple of obviou
Okay, I found some more time to look into it. I have a patch that now
passes "make && make install && make check" with SCM_DEBUG==1.
There was an additional issue in goops.c where SCM_C[AD]R get used
with objects that have just been verified to be structs, not pairs.
Since there don't see
On Sep 3, 2009, at 17:04, Ken Raeburn wrote:
[...] Scheme compilation bug is still there, though.
I'm still not sure where the bug is, but here's what I've traced
through so far;
The error is happening in eval.i.c, line number in the high 800s (I've
got a bunch of tr
On Sep 1, 2009, at 15:35, Ludovic Courtès wrote:
--- a/libguile/gc.h
+++ b/libguile/gc.h
@@ -248,7 +248,7 @@ SCM_INTERNAL void scm_i_ensure_marking(void);
SCM_API int scm_debug_cell_accesses_p;
SCM_API int scm_expensive_debug_cell_accesses_p;
SCM_API int scm_debug_cells_gc_interval ;
-void scm_i_
On Sep 2, 2009, at 04:08, Ludovic Courtès wrote:
In the Guile case, I'm a tiny bit concerned about some of the
pointer/
int games played (e.g., I'm pretty sure C99 does not guarantee that
you can convert an arbitrary uintptr_t value to pointer and back and
be guaranteed of getting the original
On Sep 1, 2009, at 15:47, Ludovic Courtès wrote:
Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h
Another compilation flag that must be rarely used. :-)
Do you find it useful?
Not so far. :-) There seems to be a lot of otherwise correct code
making assumptions about u
Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 causes SCM to be defined
as a union type (though the comments say a struct type), which
enhances the type checking by making random conversions and casts to
and from pointer and integer types not work without going through the
correct conversion
On Sep 1, 2009, at 02:23, Ken Raeburn wrote:
I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as
needed, change == to scm_is_eq. The initializers make it slightly
less trivial, and I can imagine different courses of action.
Okay, not quite so trivial as I blithely asserted.
It
[[ Resending from an account I'm actually subscribed with. ]]
Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 as discussed in __scm.h
causes SCM to be defined as a union type (though the comments say a
struct type), which enhances the type checking by making random
conversions and casts to and
On Aug 31, 2009, at 17:59, Ludovic Courtès wrote:
I think I'm mildly in favor of keeping all-bits-zero as an invalid
representation. But, if it's a huge win for BDW-GC, maybe it's worth
it.
As discussed in my other message, it would actually be harmful.
Then I'm definitely in favor of keepin
On Aug 30, 2009, at 07:13, Neil Jerram wrote:
Mark H Weaver writes:
This numbering has the nice properties that 0 is #f.
Just to be clear: will this mean that (SCM_BOOL_F == 0) ? As things
stand I don't think it will, because SCM_MAKIFLAG shifts and adds
0x04.
Just checking this because Ludovi
On Aug 27, 2009, at 13:00, Daniel Kraft wrote:
yesterday and today I implemented the promised elisp reader and just
pushed the changes. Now Guile's elisp support in my branch should
be somewhat "complete" because not only there's a compiler but also
a genuine parser for elisp, handling for
On Aug 27, 2009, at 18:32, Ken Raeburn wrote:
I wonder, though, what is loading up
srfi-1 for you?
I wish I could tell, but as I mentioned in IRC, backtraces aren't
working for me. I suppose I can try instrumenting everything
listing srfi-1 in use-modules, to print out a message
On Aug 27, 2009, at 17:15, Andy Wingo wrote:
I have reverted that part of the "eval is actually compile" commit
that
seems to have caused you problems.
Thanks; that puts it back to the "print a warning and go on" case,
which lets me get other work done.
I wonder, though, what is loading
__scm.h suggests defining SCM_DEBUG this as a way of turning on all
debugging options, so I tried adding -DSCM_DEBUG=1 to CPPFLAGS on the
configure command line, using the latest git version (3bcf189). But
the test programs in the tree don't build on my Mac, because
scm_i_expensive_validat
After the build-order problem I just reported causes a module to fail
to load, the build process hangs here:
./guile_filter_doc_snarfage --filter-snarfage) > regex-posix.doc ||
{ rm regex-posix.doc; false; }
cat alist.doc [...] regex-posix.doc | GUILE_AUTO_COMPILE=0 ../meta/
uninstalled-env
Building on GNU/Linux, with a fresh build tree, and without an
installed tree under $prefix, fails for me. I get:
./guile_filter_doc_snarfage --filter-snarfage) > regex-posix.doc ||
{ rm regex-posix.doc; false; }
cat alist.doc [...] regex-posix.doc | GUILE_AUTO_COMPILE=0 ../meta/
uninstalle
I've updated my code to the latest Emacs sources, and changed the
build process so that it uses an installed version of Guile instead of
a private, hacked copy. I've also got a public repository available.
My testing is mainly x11 builds using guile 1.8.7 on Mac OS X; no
Windows, no NS, bu
Hi. I've sent in some patches recently that haven't gotten checked
in, and haven't gotten much feedback (except, one of them is unneeded
if BDW-GC is folded in, which we all want but isn't a given). Could
someone please take a look and maybe incorporate them, or let me know
what I should
On Aug 17, 2009, at 14:52, carlo.bramix wrote:
Hello,
if I understood the problem, I think it can be easily fixed without
using an inline function.
For example:
#ifdef __GNUC__
Relying on GCC-specific syntax is probably worse than an inline
function. Part of Ludovic's complaint was that
On Aug 16, 2009, at 18:13, Ludovic Courtès wrote:
There's always the inline-function approach, too.
Unfortunately no, because we're still not assuming `inline' keyword
support from the compiler.
Right, but inline.h deals with that; if "inline" isn't supported you
just get a declaration and
On Aug 15, 2009, at 08:00, Ludovic Courtès wrote:
Hello,
We still have troubles with the `(scm_t_int32) (x) < 0' test in
`SCM_MAKE_CHAR ()':
--8<---cut here---start->8---
l...@gcc54:~/guile-1.9.1/+build$ cat ,,t.c
int
foo (unsigned char x)
{
return (((int)x)
On Aug 11, 2009, at 13:04, Greg Troxel wrote:
So it seems that NULL is expanding to (void *) 0, and "sizeof (void *)
0" is not legit. AFAIK sizeof is specified to work on variables and
types, and NULL is neither a variable nor a type.
No, sizeof should work fine on expression values as well.
1 - 100 of 154 matches
Mail list logo
