On May 22, 2012, at 03:54, Andy Wingo wrote:
On Mon 21 May 2012 07:45, Ken Raeburn raeb...@raeburn.org 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.
Thank you very much
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 is
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.2
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-GPL code
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 engine,
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 values
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 would
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 integers
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
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,
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 the one from
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. But
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 in
an
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 indeed,
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. I can make
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_extension don't
(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
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
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 of
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 l...@emf.net
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
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 type doesn't have to actually hold any character data for you to be
able to work on the low-level Lisp stuff.
* Ken Raeburn has done proof
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 raeb...@raeburn.org 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, I think it's
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 missing,
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
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 using the
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
c-tokenize.lex to return
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 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, and
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
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, for
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
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
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
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
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 just finish the build
On Nov 15, 2009, at 17:25, Neil Jerram wrote:
Ken Raeburn raeb...@raeburn.org 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 crash
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
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
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
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
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
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
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,
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
before
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,
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
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 raeb...@raeburn.org
Date: Tue Oct 13 11:45:34 2009 -0400
Flush output before forking
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 it try .ISO8859-1, most
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?)
Ken
Author: Ken Raeburn raeb
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 it
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
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.
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 raeb...@raeburn.org writes:
Perhaps I'm building [Guile] in ways that are unusual for the other
developers (build dir != src dir, libgmp and guile-1.8
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
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 replace
On Sep 16, 2009, at 15:00, Andy Wingo wrote:
Hi Ken,
On Tue 11 Aug 2009 15:59, Ken Raeburn raeb...@raeburn.org 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
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
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):
#guardian 124e300 (reachable: 15 unreachable: 1)
Does that mean it’s this whole string that’s accessed with
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
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 seem to
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
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
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 tracing lines added
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
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
[[ 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
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
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 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
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
On Aug 30, 2009, at 07:13, Neil Jerram wrote:
Mark H Weaver m...@netris.org 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
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 up
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 first
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
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/
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
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 11, 2009, at 09:59, Ken Raeburn wrote:
ERROR: In procedure make_objcode_by_mmap:
ERROR: bad header on object file: GOOF-0.6-LE-4---
Ah, that was an old compiled file cached away in $HOME/.cache/
guile/... that I needed to delete in order to make the tests pass.
I re-ran the test
On Aug 11, 2009, at 11:36, Ludovic Courtès wrote:
It appears that the word size and endianness is also encoded into the
header. Is this a good idea, when people can share home directories
across machines of different architectures, and even run mixed-size
binaries on a single system (or
On Aug 5, 2009, at 10:06, Ken Raeburn wrote:
(1) In scm_pthread_mutex_lock, we leave and re-enter guile mode so
that we don't block the thread while in guile mode. But we could
use pthread_mutex_trylock first, and avoid the costs scm_leave_guile
seems to incur on the Mac. If we can't
On Aug 5, 2009, at 10:06, I wrote:
(3) My four-year-old comments on scm_enter/leave_guile, recorded in
threads.c around line 300, still stand Those functions really
ought to go away. At least they're confined to one file, now. Some
of it looks a little messy, but I can probably get
On Aug 5, 2009, at 05:06, Andy Wingo wrote:
Guile's VM does not yet have opcodes for +1 and and -1. It probably
should, though. Still, this is a fairly artificial test.
Yeah, and it turned out to be useless for what I had wanted to test at
the start, but I was still curious to see how it
On Aug 4, 2009, at 06:17, Andy Wingo wrote:
Hello!
(Was away for the weekend, but back hacking all week now.)
Welcome back!
On Thu 30 Jul 2009 22:18, Neil Jerram n...@ossau.uklinux.net writes:
Daniel Kraft d...@domob.eu writes:
Lambda arguments are still always dynamically bound, which is
On Aug 4, 2009, at 11:47, Andy Wingo wrote:
In any case, because of dynamic scoping and the expected behaviour of
flet to change possibly primitives during its extent, I think we
can't
do anything like that for Elisp (except providing guile-primitive for
hand-optimizing such calls).
On Jul 31, 2009, at 02:02, Daniel Kraft wrote:
Iterative prime sieve, (length (find-primes-to 5000)):
Scheme: 0.42s
Elisp, no void checks, lexical let: 3.40s
Elisp, no void checks, dynamic let: 4.43s
Elisp, void checks, dynamic let: 5.12s
Elisp, void checks, lexical let: 4.06s
As Ken says,
On Jul 29, 2009, at 08:50, Daniel Kraft wrote:
Iterative prime sieve, (length (find-primes-to 5000)):
Scheme: 0.42s
Elisp, no void checks, lexical let: 3.40s
Elisp, no void checks, dynamic let: 4.43s
Elisp, void checks, dynamic let: 5.12s
Elisp, void checks, lexical let: 4.06s
It doesn't
On Jul 23, 2009, at 16:46, Andy Wingo wrote:
On Tue 21 Jul 2009 15:10, Daniel Kraft d...@domob.eu writes:
Just a little addition to the subject of extensions: I'd very much
like
to add lexical-let and lexical-let* as another set of extensions,
because this gives the possibility to use fast
On Jul 22, 2009, at 05:11, Daniel Kraft wrote:
It seemed really hard to me to find at least *basic* information
about how the lexbind things works; I did build now an emacs with
lexbind from trunk, but so far as I see this is not meant to
implement lexical-let as the cl package does, but
On Jul 21, 2009, at 09:10, Daniel Kraft wrote:
Just a little addition to the subject of extensions: I'd very much
like to add lexical-let and lexical-let* as another set of
extensions, because this gives the possibility to use fast lexical
variables without the dynamic-scoping-fluid-pain.
1 - 100 of 125 matches
Mail list logo
