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 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
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 Jun 20, 2009, at 05:33, Andy Wingo wrote:
It's also kind of appealing to have something at intermediate stages
that I might be able to show off, and say "hey, this works well
enough
that you can try it out; want to help me on the next steps?" (And
since I'm getting into all this now, I *wo
On Jul 19, 2009, at 16:10, Neil Jerram wrote:
BTW, I implemented also the function bindings of symbols using this
fluid-based dynamic scoping at the moment -- but on second thought,
there's no scoping at all for function slots (all are global), is
there?
No, I don't think there is. `let' can't
On Jul 20, 2009, at 04:12, Daniel Kraft wrote:
No, I don't think there is. `let' can't operate on function slots.
Not in the main emacs lisp implementation. However, cl-macs.el
provides an "flet" macro that does work on function slots; it uses
the "letf" macro which expands to include a use
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.
On Jul 21, 2009, at 15:32, Daniel Kraft wrote:
hm... I just found this page which is not decidedly about a planned
addition to emacs 24, but I think it is quite reasonable that this
addition will be the extension/feature described here:
I was thinking about this:
http://lists.gnu.org/archi
On Jul 21, 2009, at 15:48, Daniel Kraft wrote:
Especially, the question is about "what happens" when a lexical
variable is inside its scope again bound dynamically (say via let or
a lambda expression).
Oh, don't stop there... let's get some buffer-local or frame-local
bindings into the mix
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 r
On Jul 21, 2009, at 11:08, Julian Graham wrote:
Are there any active Guile hackers in Cambridge, MA? That could be a
better choice for a US location.
Define "active". :-)
Not so much on Guile itself, but my Guile-Emacs project is coming
along...
Ken
On Jul 23, 2009, at 16:46, Andy Wingo wrote:
On Tue 21 Jul 2009 15:10, Daniel Kraft 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" lexical varia
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 m
On Jul 30, 2009, at 16:18, Neil Jerram wrote:
The main thing I believe that makes a fluid different from a normal
variable is that a fluid can have a different value in each thread -
which is not relevant to Elisp.
Not yet, at least.
And maybe that's enough. There's other stuff in Emacs besid
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,
I implemented Ackermann's function A(m,n), a recursive function with
scary performance characteristics, based on the definition given at
wikipedia involving lots of +1 and -1 operations... A(0,n) takes
constant time to compute assuming bounded integer sizes, A(1,n) takes
linear time, A(2,n
On Aug 4, 2009, at 09:52, Marijn Schouten (hkBst) wrote:
A more idiomatic way to implement it that also works in other
Schemes is:
I know, shame on me for using "set!" in my code. :-)
I was aiming for code very similar between Lisp and Scheme versions,
so that (insert some hand-waving here)
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 writes:
Daniel Kraft writes:
Lambda arguments are still always dynamically bound, which is
quite a
pity as it inhibits tail
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).
Hmm.
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 woul
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
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 ri
On Aug 11, 2009, at 07:34, Greg Troxel wrote:
Have there been recent reports of success of 1.9.x on platforms other
than GNU/Linux? Guile has been quite portable in the past and it's
surely still very close if not there, and it would be a shame if 2.0
had
issues. I realize this is hard for p
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-ra
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 mixed-ar
Just checking: I assume we don't care about binary compatibility
between 1.9.x unstable releases? Hence changing function signatures
and structure contents, and deleting symbols, while not changing the
library's major version number, is okay?
Ken
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.
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 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 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
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
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
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
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
__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
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
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 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 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 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
[[ 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 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
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 u
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: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 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
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
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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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
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
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
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
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 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
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_
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
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
befo
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
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 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
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 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
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 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
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 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
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 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 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
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 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
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 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 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 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 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 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 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
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
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
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
1 - 100 of 154 matches
Mail list logo
