Re: Plan for 2.0
Hi Neil, On Sat 03 Jan 2009 19:38, Neil Jerram neiljer...@googlemail.com writes: We're clearly moving towards a 2.0 release. Here is my attempt to pull that together a bit and flesh out what needs to be done. I think the plan is sensible. 2. The vm branch. Once the review of master is done, we'll merge vm into master. I still need to finish documenting things, and tying up loose ends. I'm especially concerned about ABI and future compatibility. But this can be done in vm or master. I'm wondering now if we should instead move the GH code into a separate library, libgh, but continue to provide this as part of the Guile distribution. If we do this, the resulting product should have deprecated somewhere in its name. You wouldn't want people mistaking it for high-level. My personal opinion is that we should move this stuff to C files that the user can include in her own project, and distribute those C files somewhere. But perhaps this is not feasible. That's all for now. Any concerns or comments? Yay! :-) Cheers, Andy -- http://wingolog.org/
Re: vm status update
Hey hey, On Mon 05 Jan 2009 17:06, l...@gnu.org (Ludovic Courtès) writes: Neil Jerram neiljer...@googlemail.com writes: Nice. Regarding the merge to master, though, - I think that would imply that the VM is included in the next release series (1.10.x or 2.0.x); is that your intention? (I have no objection!) No objection either, but... some benchmarking would be really nice. :-) Yes, you're right. Also, what's the status of the VM/compiler test suite? Well, there are larger tests, in that the normal test suite passes with VM-compiled code (e.g. ice-9 and all that). However the normal test suite code is interpreted always -- we need to figure out how to run it with the interpreter and the evaluator. And there are smaller tests, which test that VM compilation and execution produces the same result as interpretation. But there are no unit tests of the compiler itself. Also, these particular tests are not yet integrated with the main test suite. Benchmark-wise, there's not much. I am not currently running many benchmarks, fwiw -- been focusing more on correctness. So yes, there's still some work to be done. Andy -- http://wingolog.org/
Re: vm status update
Hi! On Mon 05 Jan 2009 22:03, l...@gnu.org (Ludovic Courtès) writes: I think it's good to have unit tests for the compiler/VM too. Sure, would be good. First I'm going to work on documenting the compiler though, so there's something to test. But honestly speaking, I'm not going to go on a spree of unit-test writing -- I write them as I find bugs, but not much otherwise. So, ahem, what I mean to say is that the small number of tests reflects the small number of bugs, or something? ;-) Benchmark-wise, there's not much. I am not currently running many benchmarks, fwiw -- been focusing more on correctness. Maybe we could start focusing on that now that the VM/compiler have matured a lot? Sure, and at some point I'll switch to benchmarking and optimization -- but in the meantime perhaps someone whose named ends in udovic Courtès could make make a benchmarking suite? ;-)) I hear you're all finished with the BDW GC branch, right? :) Back to the hack, Andy -- http://wingolog.org/
another thing about merging guile-vm
Hi, Licensing would be another thing to look at when merging the vm branch -- currently it's under GPL + exception. Kei is still contactable though, I have his mail somewhere. If Kei has already signed papers we can just relicense it ourselves, however. Andy -- http://wingolog.org/
vm status update
Hey hackers, I just finished up a lot of typing at the manual, and I hope I'm done with that. The net result is that the VM is documented quite thoroughly, and the compiler as well. I'll send those documents to the list in separate mails for inline comments. Otherwise, in the course of documentation, I've made a few minor cleanups, some internal name changes and such. No sense polishing a turd, they say. I had an idea regarding unit tests recently: since GHIL and GLIL now have (documented!) S-expression representations, we should be able to easily and expressively test individual compiler passes. Looking forward to that. I also had another realization, that now that VM frames go into stack structures, that statprof should work with the VM. Have yet to check though. Anyway, just some babblings. I'll probably switch to benchmarking and profiling sometime soon. I also need to merge in master to vm, it's been a while and there are probably some conflicts. So that's my status. Happy hacking! Andy -- http://wingolog.org/
vm.texi: A virtual machine for guile
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=doc/ref/vm.texi;hb=refs/heads/vm
@c -*-texinfo-*-
@c This is part of the GNU Guile Reference Manual.
@c Copyright (C) 2008,2009
@c Free Software Foundation, Inc.
@c See the file guile.texi for copying conditions.
@node A Virtual Machine for Guile
@section A Virtual Machine for Guile
Guile has both an interpreter and a compiler. To a user, the
difference is largely transparent -- interpreted and compiled
procedures can call each other as they please.
The difference is that the compiler creates and interprets bytecode
for a custom virtual machine, instead of interpreting the
S-expressions directly. Running compiled code is faster than running
interpreted code.
The virtual machine that does the bytecode interpretation is a part of
Guile itself. This section describes the nature of Guile's virtual
machine.
@menu
* Why a VM?::
* VM Concepts::
* Stack Layout::
* Variables and the VM::
* VM Programs::
* Instruction Set::
@end menu
@node Why a VM?
@subsection Why a VM?
For a long time, Guile only had an interpreter, called the evaluator.
Guile's evaluator operates directly on the S-expression representation
of Scheme source code.
But while the evaluator is highly optimized and hand-tuned, and
contains some extensive speed trickery (@pxref{Memoization}), it still
performs many needless computations during the course of evaluating an
expression. For example, application of a function to arguments
needlessly conses up the arguments in a list. Evaluation of an
expression always has to figure out what the car of the expression is
-- a procedure, a memoized form, or something else. All values have to
be allocated on the heap. Et cetera.
The solution to this problem is to compile the higher-level language,
Scheme, into a lower-level language for which all of the checks and
dispatching have already been done -- the code is instead stripped to
the bare minimum needed to ``do the job''.
The question becomes then, what low-level language to choose? There
are many options. We could compile to native code directly, but that
poses portability problems for Guile, as it is a highly cross-platform
project.
So we want the performance gains that compilation provides, but we
also want to maintain the portability benefits of a single code path.
The obvious solution is to compile to a virtual machine that is
present on all Guile installations.
The easiest (and most fun) way to depend on a virtual machine is to
implement the virtual machine within Guile itself. This way the
virtual machine provides what Scheme needs (tail calls, multiple
values, call/cc) and can provide optimized inline instructions for
Guile (cons, struct-ref, etc.).
So this is what Guile does. The rest of this section describes that VM
that Guile implements, and the compiled procedures that run on it.
Note that this decision to implement a bytecode compiler does not
preclude native compilation. We can compile from bytecode to native
code at runtime, or even do ahead of time compilation. More
possibilities are discussed in @xref{Extending the Compiler}.
@node VM Concepts
@subsection VM Concepts
A virtual machine (VM) is a Scheme object. Users may create virtual
machines using the standard procedures described later in this manual,
but that is usually unnecessary, as Guile ensures that there is one
virtual machine per thread. When a VM-compiled procedure is run, Guile
looks up the virtual machine for the current thread and executes the
procedure using that VM.
Guile's virtual machine is a stack machine -- that is, it has few
registers, and the instructions defined in the VM operate by pushing
and popping values from a stack.
Stack memory is exclusive to the virtual machine that owns it. In
addition to their stacks, virtual machines also have access to the
global memory (modules, global bindings, etc) that is shared among
other parts of Guile, including other VMs.
A VM has generic instructions, such as those to reference local
variables, and instructions designed to support Guile's languages --
mathematical instructions that support the entire numerical tower, an
inlined implementation of @code{cons}, etc.
The registers that a VM has are as follows:
@itemize
@item ip - Instruction pointer
@item sp - Stack pointer
@item fp - Frame pointer
@end itemize
In other architectures, the instruction pointer is sometimes called
the ``program counter'' (pc). This set of registers is pretty typical
for stack machines; their exact meanings in the context of Guile's VM
is described in the next section.
A virtual machine executes by loading a compiled procedure, and
executing the object code associated with that procedure. Of course,
that procedure may call other procedures, tail-call others, ad
infinitum -- indeed, within a guile whose modules have all been
compiled to object code, one might never leave the virtual machine.
compiler.texi: Compiling to the virtual machine
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=doc/ref/compiler.texi;hb=refs/heads/vm
@c -*-texinfo-*-
@c This is part of the GNU Guile Reference Manual.
@c Copyright (C) 2008
@c Free Software Foundation, Inc.
@c See the file guile.texi for copying conditions.
@node Compiling to the Virtual Machine
@section Compiling to the Virtual Machine
Compilers have a mystique about them that is attractive and
off-putting at the same time. They are attractive because they are
magical -- they transform inert text into live results, like throwing
the switch on Frankenstein's monster. However, this magic is perceived
by many to be impenetrable.
This section aims to pay attention to the small man behind the
curtain.
@xref{Read/Load/Eval/Compile}, if you're lost and you just wanted to
know how to compile your .scm file.
@menu
* Compiler Tower::
* The Scheme Compiler::
* GHIL::
* GLIL::
* Object Code::
* Extending the Compiler::
@end menu
@node Compiler Tower
@subsection Compiler Tower
Guile's compiler is quite simple, actually -- its @emph{compilers}, to
put it more accurately. Guile defines a tower of languages, starting
at Scheme and progressively simplifying down to languages that
resemble the VM instruction set (@pxref{Instruction Set}).
Each language knows how to compile to the next, so each step is simple
and understandable. Furthermore, this set of languages is not
hardcoded into Guile, so it is possible for the user to add new
high-level languages, new passes, or even different compilation
targets.
Languages are registered in the module, @code{(system base language)}:
@example
(use-modules (system base language))
@end example
They are registered with the @code{define-language} form.
@deffn {Scheme Syntax} define-language @
name title version reader printer @
[parser=#f] [read-file=#f] [compilers='()] [evaluator=#f]
Define a language.
This syntax defines a @code{#language} object, bound to @var{name}
in the current environment. In addition, the language will be added to
the global language set. For example, this is the language definition
for Scheme:
@example
(define-language scheme
#:title Guile Scheme
#:version 0.5
#:reader read
#:read-file read-file
#:compilers `((,ghil . ,compile-ghil))
#:evaluator (lambda (x module) (primitive-eval x))
#:printer write)
@end example
In this example, from @code{(language scheme spec)}, @code{read-file}
reads expressions from a port and wraps them in a @code{begin} block.
@end deffn
The interesting thing about having languages defined this way is that
they present a uniform interface to the read-eval-print loop. This
allows the user to change the current language of the REPL:
@example
$ guile
Guile Scheme interpreter 0.5 on Guile 1.9.0
Copyright (C) 2001-2008 Free Software Foundation, Inc.
Enter `,help' for help.
scheme@@(guile-user) ,language ghil
Guile High Intermediate Language (GHIL) interpreter 0.3 on Guile 1.9.0
Copyright (C) 2001-2008 Free Software Foundation, Inc.
Enter `,help' for help.
ghil@@(guile-user)
@end example
Languages can be looked up by name, as they were above.
@deffn {Scheme Procedure} lookup-language name
Looks up a language named @var{name}, autoloading it if necessary.
Languages are autoloaded by looking for a variable named @var{name} in
a module named @code{(language @var{name} spec)}.
The language object will be returned, or @code{#f} if there does not
exist a language with that name.
@end deffn
Defining languages this way allows us to programmatically determine
the necessary steps for compiling code from one language to another.
@deffn {Scheme Procedure} lookup-compilation-order from to
Recursively traverses the set of languages to which @var{from} can
compile, depth-first, and return the first path that can transform
@var{from} to @var{to}. Returns @code{#f} if no path is found.
This function memoizes its results in a cache that is invalidated by
subsequent calls to @code{define-language}, so it should be quite
fast.
@end deffn
There is a notion of a ``current language'', which is maintained in
the @code{*current-language*} fluid. This language is normally Scheme,
and may be rebound by the user. The runtime compilation interfaces
(@pxref{Read/Load/Eval/Compile}) also allow you to choose other source
and target languages.
The normal tower of languages when compiling Scheme goes like this:
@itemize
@item Scheme, which we know and love
@item Guile High Intermediate Language (GHIL)
@item Guile Low Intermediate Language (GLIL)
@item Object code
@end itemize
Object code may be serialized to disk directly, though it has a cookie
and version prepended to the front. But when compiling Scheme at
runtime, you want a Scheme value, e.g. a compiled procedure. For this
reason, so as not to break the abstraction, Guile defines a fake
language, @code{value}. Compiling to @code{value} loads the
someone please implement a lua language
Hello. Lua gets a fair amount of press, and is fine in its way. People like it for the same reason that people liked Tcl: Lua is simple, embeddable, and has the mainstream, Algol-like syntax. Also, it has a reasonably fast implementation. That's cool! It would be interesting to enhance Lua with the rich runtime of Guile -- all of POSIX, pthreads, and all of Guile's excellent libraries. Lua is *really* simple. See http://www.lua.org/manual/5.1/manual.html#8. Does someone want to write a simple Lua parser (ideally finding an EBNF parser first) and compile that to GHIL? That would be a great project. Andy -- http://wingolog.org/
what happened with gds breakpoints?
Hi Neil,
Why did you remove GDS breakpoints? The idea sounded nice:
While they are an important piece of infrastructure, and directly
usable in some scenarios, traps are still too low level to meet some
of the requirements of interactive development.
A common scenario is that a newly written procedure is not working
properly, and so you'd like to be able to step or trace through its
code to find out why. Ideally this should be possible from the IDE
and without having to modify the source code. There are two problems
with using traps directly in this scenario.
@enumerate
@item
They are too detailed: constructing and installing a trap requires you
to say what kind of trap you want and to specify fairly low level
options for it, whereas what you really want is just to say ``break
here using the most efficient means possible.''
@item
The most efficient kinds of trap --- that is, @code{procedure-trap}
and @code{source-trap} --- can only be specified and installed
@emph{after} the code that they refer to has been loaded.
Just wondering.
Andy
--
http://wingolog.org/
marking overhead, and on the cost of conditionals in hot code
I dropped into cachegrind, and it tells me thing about scm_gc_mark in a
simple guile -c 1 run:
. void
. scm_gc_mark (SCM ptr)
794,344 {
155,170 = ???:0x00024917 (77585x)
198,586if (SCM_IMP (ptr))
. return;
.
513,038if (SCM_GC_MARK_P (ptr))
. return;
.
84,580if (!scm_i_marking)
. {
.static const char msg[]
. = Should only call scm_gc_mark() during GC.;
.scm_c_issue_deprecation_warning (msg);
. }
.
42,290SCM_SET_GC_MARK (ptr);
63,435scm_gc_mark_dependencies (ptr);
2,666,432 =
/home/wingo/src/guile/vm/libguile/gc-mark.c:scm_gc_mark_dependencies (5222x)
704 =
/usr/src/debugglibc-20081113T2206/elf/../sysdeps/i386/dl-trampoline.S:_dl_runtime_resolve
(1x)
595,758 }
I think that the items on the left are cycle counts, and are of relative
importance. The = lines are the cumulative costs of the subroutines.
The salient point for me is that the scm_i_marking check slows down
this function by about 10%! Also, that the majority of the time in this
function is in the SCM_GC_MARK_P line.
If I thought that we'd keep our GC, I would work at inlining this
function, i think.
Andy
--
http://wingolog.org/
guile-lib licensing (input requested)
Hey hackers, In an attack of CADT[0], I have decided to move Guile-lib to savannah.nongnu.org, so that Guile contributors can more easily contribute to Guile-lib. I've also migrated to Git. As part of the savannah submission process, Sebastian Gerhardt rightfully pointed out some schitzophrenia regarding licensing. Many of our sources come from the public domain, but some of our code is GPL. We should probably have some kind of policy regarding licenses. Here are some options that I can think of: 1) Guile-lib itself has no one license. Individual modules have clearly-stated licenses. Advantage: reflects the current situation. Disadvantage: difficult for the user to know the licenses of the software they are using. License of the tarball as a whole is ambiguous. 2) Guile-lib has one license, the GPLv3+. Advantage: Clarity, and supportive of software freedom. Disadvantage: License is different from that of Guile (LGPLv2+, perhaps becoming v3+). Much more restrictive than some public-domain sources that we base our work on (e.g. ssax). 3) One license, the LGPLv3+. Advantage: Clarity, harmony with Guile's license. Disadvantage: Getting some GPL code relicensed to LGPL, although there's not that many contributors for GPL code. A weaker support for software freedom. What do people think? Btw: until the guile-lib submission goes through, you can get guile-lib from git as follows: git clone http://wingolog.org/git/guile-lib.git Cheers, Andy [0] http://www.jwz.org/doc/cadt.html -- http://wingolog.org/
Re: Wide strings
On Tue 27 Jan 2009 06:52, Mike Gran spk...@yahoo.com writes:
I said
(Though, such a scheme would force scm_take_locale_string to become
scm_take_iso88591_string.)
which is incorrect. Under the proposed scheme, scm_take_locale_string
would only be able to use that storage directly if it happened to be
ASCII or 8859-1.
Perhaps as part of this, we should add
scm_{from,take}_{ascii,iso88591,ucs32}_string. This would help greatly
when you know the format of data that you're writing to object code or
in C, but you don't know the locale of the user.
Andy
ps. Good luck! Having this problem looked at, with an eye to solutions,
makes me very happy :-))
--
http://wingolog.org/
Re: r6rs libraries
Hi Julian, On Mon 26 Jan 2009 01:27, Julian Graham jool...@gmail.com writes: Maybe some more advanced Schemers than I can shed some light on the following: Well, that's not me, but I'll join you in fumbling for a solution :-) The levels system is simply a numerical way of encapsulating this information, but the proper order of evaluation can also be inferred by inspecting the import- and export-specs of the libraries being loaded I think you're right, yes. I think that the approach that you describe has been called Implicit phasing by Ghuloum and Dybvig. They have a paper about it, Implicit phasing in R6RS libraries -- but I haven't been able to find it freely on the web. ACM fail. * R6RS says that a library's imports need to be visited/instantiated at the time the bindings they export are referenced. Why? As above, why can't they be visited/instantiated at the time the imports for the importing library are processed? I could not find the quote that you referred to here -- I think what I can tell (from 7.2): If any of a library’s definitions are referenced at phase 0 in the expanded form of a program, then an instance of the referenced library is created for phase 0 before the program’s definitions and expressions are evaluated. This rule applies transitively: if the expanded form of one library references at phase 0 an identifier from another library, then before the referencing library is instantiated at phase n, the referenced library must be instantiated at phase n. When an identifier is referenced at any phase n greater than 0, in contrast, then the defining library is instantiated at phase n at some unspecified time before the reference is evaluated. Similarly, when a macro keyword is referenced at phase n during the expansion of a library, then the defining library is visited at phase n at some unspecified time before the reference is evaluated. So what this says to me is that: (1) At phase 0, libraries that you need to run a /program/ are instantiated before the program is run. (2) At phase n 0, we do not specify when libraries are imported. Is there any noticeable difference to the user? Dunno, to me it sounds like a concession, that side effects from loading libraries occur before side effects from running a program; but that for meta-levels things are left unspecified. Or do you guys read R6RS 7.2 to mean that the side-effects of top-level expressions absolutely need to happen at a time determined by the import level? No. So, for some of your other questions here's section 7.5 of the rationale: 7.5. Instantiation and initialization Opinions vary on how libraries should be instantiated and initialized during the expansion and execution of library bodies, whether library instances should be distinguished across phases, and whether levels should be declared so that they constrain identifier uses to particular phases. As I read this, it means that at least PLT wanted the separate instantiation model, and Chez wanted single-instantiation, implicit phasing. This report therefore leaves considerable latitude to implementations, while attempting to provide enough guarantees to make portable libraries feasible. So from 7.2 of R6RS itself: An implementation may distinguish instances/visits of a library for different phases or to use an instance/visit at any phase as an instance/visit at any other phase. Which is to say, we allow single instantiation -- as Guile modules are. An implementation may further expand each library form with distinct visits of libraries in any phase and/or instances of libraries in phases above 0. Which is to say, we also allow the PLT model, explicitly. An implementation may create instances/visits of more libraries at more phases than required to satisfy references. This is an odd one. I suppose what it means is that if you need a macro from library A to expand library B, but you don't need library A at runtime, the spec allows library A to be /instantiated/ at runtime. When an identifier appears as an expression in a phase that is inconsistent with the identifier’s level, then an implementation may raise an exception either at expand time or run time, or it may allow the reference. So, furthermore, it seems that not only may library A be instantiated at runtime, /it may be in library B's import list as well/. This is what happens with Guile's current module semantics. Thus, a library whose meaning depends on whether the instances of a library are distinguished or shared across phases or library expansions may be unportable. Indeed, indeed. I understand that the authors of the reference implementation re-created a lot of machinery
pushed to master: extensibility to (ice-9 session)
Hi, I pushed the following patch to master. Is it OK to push to 1.8 as well? That way I could drop some modules from guile-lib, and make guile-lib depend on guile = 1.8.x. (Perhaps we can set up a list for patches that get pushed to Guile ?) Andy commit 4f7a0504aac215832e99290e31c9944795c5d206 Author: Andy Wingo wi...@pobox.com Date: Tue Jan 27 13:43:07 2009 +0100 merge in from guile-lib: add some extensibility to `help' * ice-9/session.scm (add-value-help-handler!) (remove-value-help-handler!, add-name-help-handler!) (remove-name-help-handler!): New public interfaces, to allow some basic extensibility of the help interface. Merged in from guile-lib's (scheme session). diff --git a/ice-9/session.scm b/ice-9/session.scm index 1c9f480..6971a78 100644 --- a/ice-9/session.scm +++ b/ice-9/session.scm @@ -20,12 +20,61 @@ :use-module (ice-9 documentation) :use-module (ice-9 regex) :use-module (ice-9 rdelim) - :export (help apropos apropos-internal apropos-fold - apropos-fold-accessible apropos-fold-exported apropos-fold-all - source arity system-module)) + :export (help + add-value-help-handler! remove-value-help-handler! + add-name-help-handler! remove-name-help-handler! + apropos apropos-internal apropos-fold apropos-fold-accessible + apropos-fold-exported apropos-fold-all source arity + system-module module-commentary)) +(define *value-help-handlers* '()) + +(define (add-value-help-handler! proc) + Adds a handler for performing `help' on a value. + +`proc' will be called as (PROC NAME VALUE). `proc' should return #t to +indicate that it has performed help, a string to override the default +object documentation, or #f to try the other handlers, potentially +falling back on the normal behavior for `help'. + (set! *value-help-handlers* (cons proc *value-help-handlers*))) + +(define (remove-value-help-handler! proc) + Removes a handler for performing `help' on a value. + +See the documentation for `add-value-help-handler' for more +information. + (set! *value-help-handlers* (delete! proc *value-help-handlers*))) + +(define (try-value-help name value) + (or-map (lambda (proc) (proc name value)) *value-help-handlers*)) + + +(define *name-help-handlers* '()) + +(define (add-name-help-handler! proc) + Adds a handler for performing `help' on a name. + +`proc' will be called with the unevaluated name as its argument. That is +to say, when the user calls `(help FOO)', the name is FOO, exactly as +the user types it. + +The return value of `proc' is as specified in +`add-value-help-handler!'. + (set! *name-help-handlers* (cons proc *name-help-handlers*))) + +(define (remove-name-help-handler! proc) + Removes a handler for performing `help' on a name. + +See the documentation for `add-name-help-handler' for more +information. + (set! *name-help-handlers* (delete! proc *name-help-handlers*))) + +(define (try-name-help name) + (or-map (lambda (proc) (proc name)) *name-help-handlers*)) + + ;;; Documentation ;;; (define help @@ -45,6 +94,10 @@ You don't seem to have regular expressions installed.\n)) type x (cond +;; User-specified +((try-name-help name) + = (lambda (x) (if (not (eq? x #t)) (display x + ;; SYMBOL ((symbol? name) (help-doc name @@ -60,10 +113,12 @@ You don't seem to have regular expressions installed.\n)) ((and (list? name) (= (length name) 2) (eq? (car name) 'unquote)) - (cond ((object-documentation - (local-eval (cadr name) env)) -= write-line) - (else (not-found 'documentation (cadr name) + (let ((value (local-eval (cadr name) env))) + (cond ((try-value-help (cadr name) value) + = noop) + ((object-documentation value) + = write-line) + (else (not-found 'documentation (cadr name)) ;; (quote SYMBOL) ((and (list? name) @@ -109,7 +164,8 @@ You don't seem to have regular expressions installed.\n)) (let ((entries (apropos-fold (lambda (module name object data) (cons (list module name -(object-documentation object) +(or (try-value-help name object) + (object-documentation object)) (cond ((closure? object) a procedure
Re: pushed to master: extensibility to (ice-9 session)
Hi, On Tue 27 Jan 2009 21:30, l...@gnu.org (Ludovic Courtès) writes: Looks OK to me. (Too bad [(ice-9 session)] isn't documented BTW.) Do you have example use cases? From (texinfo reflection): (cond ((defined? 'add-value-help-handler!) (define (stexi-help-handler name value) (stexi-plain-text (object-stexi-documentation value name #:force #t))) (define (module-help-handler name) (and (list? name) (and-map symbol? name) (stexi-plain-text (module-stexi-documentation name (add-value-help-handler! stexi-help-handler) (add-name-help-handler! module-help-handler))) +(define *value-help-handlers* '()) The convention within Guile is rather `%'-prefixed names for globals, as in `%load-path'. I'm going to have to agree with Neil here ;) See also %make-void-port, %search-load-path, %package-data-dir, etc. Search the manual for scm_sys_ for more. Shouldn't `object-documentation' as a default value helper, as in: (define %value-help-handlers `(,(lambda (n v) (object-documentation v Yes, nice one. Thanks, Andy -- http://wingolog.org/
Re: Wide strings
Hi, On Wed 28 Jan 2009 17:44, Mike Gran spk...@yahoo.com writes: Since I need this functionality taken care of, and since I have some time to play with it, what's the procedure here? The best thing IMO would be to hack on it on a Git branch, with small and correct patches. We could get you commit access if you don't already have it (Ludo or Neil would have to reply on that). Then you could push your work directly to a branch, so we all can review it easily. Do we need to talk more about what needs to be accomplished? Do we need a complete specification? Do we need a vote on if it is a good idea? I think you're going in the right direction. More importantly, although I can't speak for them, Neil and Ludo seem to think so too. 1. Convert the internal char and string representation to be explicitly ISO 8859-1. Add the to/from locale conversion functionality while still retaining 8-bit strings. Replace C library funcs with Gnulib string funcs where appropriate. Sounds appropriate to me. I am unfamiliar with the gnulib code; where do the unicode codepoit tables live? How does one update them? Do we get full introspection on characters and their classes, properties, etc? 2. Convert the internal representation of chars to 4-byte codepoints, while still retaining 8-bit strings. Currently, characters are immediate values, with an 8-bit tag. See tags.h:333. So it seems we have 24 bits remaining, and unicode claims that 21 bits are the minimum necessary -- so we're good, if you can figure out a reasonable way to go from a 32-bit codepoint to a 24-bit codepoint. 3. Convert strings to be a union of 1 byte and 4 byte chars. There's room on stringbufs to have a flag, I think. Dunno if that's the right way to do it. Converting the symbols and keywords code to do the right thing will be a little bit of work, too. Happy hacking, Andy -- http://wingolog.org/
guile-lib has moved: http://www.nongnu.org/guile-lib/
Hello all, Guile-Lib has moved to http://www.nongnu.org/guile-lib/, and has switched to git. We hope that this change will make it easier for Guile contributors to get involved with Guile-Lib, and vice versa. Check out guile-lib from git like this: git clone git://git.sv.gnu.org/guile-lib.git Visit guile-lib's git on the web: http://git.savannah.gnu.org/cgit/guile-lib.git Accesses to the old web page will redirect to the new one. An update to the bzr repository will give you this information also, and the download area on GNA has a new readme that points people to the new locations. Voila. Guile-Lib will now use Guile's mailing lists as its own. Questions? Concerns? Patches? Send them to guile-user or guile-devel, whatever seems appropriate. Happy hacking, Andy -- http://wingolog.org/
vm status update
Greets! So, yes, it's Saturday night: but I do love Guile hacking so. (Also: my partner is away.) So a VM status update it is! * The parts of the instruction stream that are mapped directly to struct scm_objcode are now aligned to 8-byte boundaries, and written in native endianness. * Much more source information propagates through the compiler and into the metadata now. In short, whereas before it was expressions are only marked as coming from a source location if they are eq? to an expression read in by guile, now it is expressions are marked with the source location of their containing expression, unless they are eq? to an expression read by guile. The upshot is that original source information is preserved to a much broader extent than before, as macro-expanded or transformed expressions all have some kind of anchor to the original source. Another ramification of this is that procedures have source information corresponding to where they were really defined, in addition to locations of their subexpressions. (program-source foo 0) will give you that. * The in-bytecode metadata representation has been compressed. Now we associate bytecode offsets with line-column pairs, and only record that information when it changes. The idea is, byte N in the instruction stream corresponds to source info for byte M, where M = N. Also, we only record the filename when it changes. This means that we can have more source information, as mentioned above, but still have objcode files of similar size. * The VM dispatches to signal handlers (asyncs) more often, specifically: on return from a call, just before a call, and on a tail call. * Stack captures are much more reliable. Before there were some bugs. This allows statprof to work properly, capturing the whole stack up to a common root. * I set out to optimize GOOPS, and ended up writing a new call tree visualizer: http://wingolog.org/archives/2009/02/09/visualizing-statistical-profiles-with-chartprof It turns out that most of the time loading GOOPS is in the compiler, which comes from those dynamic recompilation bits I mentioned in the past. So I focused on optimizing the compiler -- it is much faster now. But still, for the uses that GOOPS has, a closure is better than a compiler. I changed thing in GOOPS so that it doesn't compile at runtime any more, and now on this machine GOOPS loads in something like 40ms. That's pretty good! Though improvements are possible, of course. * The VM now has support for separate engines. Currently the engines are just regular and debug, defaulting to debug. There are not interfaces to change this at runtime, yet. But it turns out there's not much difference. See vm-engine.c for more details. It seems that native compilation would be much better than a reckless engine. Well, that's about it as far as changes go. And as far as status? I'm going to update the docs for changes in the last month, then talk seriously about a merge to master. I think it's ready. Happy hacking, Andy ps. Guile finally loads faster than Python now. It's about time... -- http://wingolog.org/
Re: Thoughts on g-wrap, guile FFI and guile-gnome
Hello! Your insights in reverse: On Sat 21 Feb 2009 03:52, Andreas Rottmann a.rottm...@gmx.at writes: it might make sense to provide a pure-Scheme FFI inside Guile core (perhaps just molding the current G-Wrap runtime library into shape). Once you have that, you can create bindings without the need for any binding generation step, hence doing away (in principle) the need for G-Wrap altogether. I completely agree, this makes sense, and we should do this at some point this year. I wonder how the advent of gobject-introspection will influence the future of guile-gnome. I want to switch to it. But this is like a 200 hour project, and with less deployment than our existing solution. I don't anticipate working on this in 2009. Happy hacking, Andy -- http://wingolog.org/
Re: [VM] Should `compile' always be visible?
Yo, On Tue 24 Feb 2009 00:44, l...@gnu.org (Ludovic Courtès) writes: Yeah, dunno. It would be great to have `compile' in the toplevel environment. OTOH it takes time. Just to be clear: I wasn't so much concerned about load time, but rather about namespace pollution and fuzzy dependencies (ambient authority). Why add yet another set of global bindings if we can avoid it? OK. Still I feel that it would be great to have `compile' and `compile-file' available in the default environment -- they're in the same category as `load', `eval', etc. It would also be good for scripts. But I could be convinced otherwise :) This is all on my laptop running at full speed, an average over 10 runs. Is it when running `pre-inst-guile', the Libtool-generated `guile' script, or the raw `guile' executable? The 1.8 results were against the Fedora guile, and the vm results against libguile/.libs/lt-guile, run inside pre-inst-guile-env. I agree that `syncase' should be loaded by default now that we no longer have to worry about its execution time. Great. We'll have to document syntax-rules at least in the manual though, and we should document syntax-case too. Not that that should block their inclusion. Andy -- http://wingolog.org/
Re: [VM] Should `compile' always be visible?
On Wed 25 Feb 2009 22:16, l...@gnu.org (Ludovic Courtès) writes: The 1.8 results were against the Fedora guile, and the vm results against libguile/.libs/lt-guile, run inside pre-inst-guile-env. The issue is that `pre-inst-guile-env' adds overhead, which may not be negligible when measuring startup time. Perhaps I was unclear. They were run as: wi...@unquote:~/src/guile/vm$ ./pre-inst-guile-env bash wi...@unquote:~/src/guile/vm$ time for i in 0 1 2 3 4 5 6 7 8 9; do libguile/.libs/lt-guile -c 1; done real0m0.098s user0m0.059s sys 0m0.026s I don't think there's overhead here. There certainly is if you time ./pre-inst-guile instead: wi...@unquote:~/src/guile/vm$ time for i in 0 1 2 3 4 5 6 7 8 9; do ./pre-inst-guile -c 1; done real0m0.307s user0m0.164s sys 0m0.120s Andy -- http://wingolog.org/
Re: [VM] Tail recursion and multiple values
Hey Ludo! On Sat 28 Feb 2009 15:45, l...@gnu.org (Ludovic Courtès) writes: l...@gnu.org (Ludovic Courtès) writes: Use of multiple values breaks tail recursion in VM-compiled code: (let loop ((x 100)) (and ( x 0) (call-with-values (lambda () (values (1+ x) (1- x))) (lambda (next prev) (loop prev) Actually no: it works with VM-compiled code, but it breaks when using Guile-VM with `,o interp #t' (which appears to be the default, except at the REPL). This is a misunderstanding. Last things first: code is not run through the VM unless it is compiled. The REPL in the vm branch compiles expressions by default, though it has an option to use the interpreter instead (,option interp #t). So if you are running this code via e.g. guile -s foo.scm, the code in foo.scm is evaluated with the interpreter. Sometimes this is faster, in that the compiler doesn't have to be loaded up -- see the recent numbers that I posted. It depends on what foo.scm does. In this case, `loop' is an interpreter procedure while `call-with-values' is a program. Just as you cannot have tail recursion between interpreted code and primitive (C-compiled) code, you cannot have tail recursion between VM and interpreted (or primitive) code. Multiple values actually doesn't have anything to do with this, except for one thing -- r4rs.scm defines call-with-values like this: (define (call-with-values producer consumer) (@call-with-values producer consumer)) @call-with-values is a primitive understood to the interpreter. In this way the interpreter preserves tail recursion, not only for calls to call-with-values, but also (apply call-with-values ...). Indeed, call/cc and even `apply' have similar definitions in this file. So what I really mean to say is: 1) It is expected that you don't have tail recursion between interpreted and VM code. 2) This particular problem manifests itself in that call-with-values is VM code (when r5rs.scm is compiled). 3) The strategy used by r5rs.scm is actually not bad, as it handles the `apply' case well. If we really want to preserve tail recursion in this case, we could add hacks to the interpreter, e.g. to recognize VM programs that are eq? to call-with-values as being the same as @call-with-values; but the interpreter already has enough hacks. Better to make loading the compiler faster, so we can just compile by default. Cheers, Andy -- http://wingolog.org/
Re: [VM] Tail recursion and multiple values
Heya, On Mon 02 Mar 2009 00:48, l...@gnu.org (Ludovic Courtès) writes: 1) It is expected that you don't have tail recursion between interpreted and VM code. 2) This particular problem manifests itself in that call-with-values is VM code (when r5rs.scm is compiled). (The latter is what I meant to say in my message.) As for (1), I'm unsure. The issue is that as long as running code with the interpreter is the default, people may hit this kind of problem, which is, well, problematic. Now, I have no idea how this could be solved without resorting to dirty hacks such as the one you suggested. Yeah. It is certainly a counterintuitive situation. The compiler recognizes both call-with-values and @call-with-values, so we could just not compile call-with-values; less nasty, but still nasty, and penalizes the vm in the (apply call-with-values ...) case. As a side note, I think it makes sense to keep the interpreter as the default when evaluating `.scm' files Sure, for now -- or we could do what python does, and automatically create .go files as needed (and if possible). Then it would certainly pay off over time, and the compilation time would probably be a wash because in that case the .scm probably isn't even in the disk cache. the program is short-lived This would be the normal case if the compiler performs smart optimizations, Hahaahaha! More seriously, I think that the bar for including optimizations in the normal compilation path will be if they actually speed up the compiler as well (since the compiler is self-compiled). Cheers, Andy -- http://wingolog.org/
eval-case and toplevel prohibitions
Hi all, I've been hacking at the compiler in recent days, separating out expansion from compilation (currently they are intertwingled, which produces some bugs), and making GHIL a more simple language, more amenable to optimization. I've grown to really like syncase in its psyntax.scm incarnation. (I have something of a Dybvig adoration complex.) It has in it an eval-when construct, but eval-when doesn't have separate rules for toplevel and nontoplevel, just '(eval compile load): http://www.scheme.com/csug7/system.html#g91 (see the section on eval-when) So I was thinking: why do we have this fetish for prohibiting certain forms in a non-toplevel context? I am of a mind to replace eval-case with eval-when, which is actually more expressive, as it allows us to discriminate the different phases in non-toplevel contexts as well. Cheers, Andy -- http://wingolog.org/
Re: [VM] Tail recursion and multiple values
Howdy howdy, On Mon 02 Mar 2009 22:55, l...@gnu.org (Ludovic Courtès) writes: Andy Wingo wi...@pobox.com writes: The compiler recognizes both call-with-values and @call-with-values, so we could just not compile call-with-values; less nasty, but still nasty, and penalizes the vm in the (apply call-with-values ...) case. Yes, but OTOH that's an unusual case, no? Yes, it is. As a side note, I think it makes sense to keep the interpreter as the default when evaluating `.scm' files Sure, for now -- or we could do what python does, and automatically create .go files as needed (and if possible). Then it would certainly pay off over time, and the compilation time would probably be a wash because in that case the .scm probably isn't even in the disk cache. I prefer having to compile things explicitly, though. I prefer magic, if magic works ;-) The compiler is almost to the point that it can replace the interpreter, semantically. What is needed is to read and compile toplevel definitions one at a time, so we can e.g. change the reader, or the other dynamic things that people expect. Then if that's the case, then we can just hit the user with the one-time cost, for the long-term benefit. This would also allow us to move closer to having a single codepath, which has its benefits, broader tail-recursion among them. if the compiler performs smart optimizations, Hahaahaha! To put it another way, the compiler may not be designed from the ground up to minimize compilation time, whereas the interpreter (supposedly) tries to achieve this. I understand. I wish that we lived in a world in which (timewise) compilation + running == interpretation, so we could just do the former, but that is not yet our world. However both Chez and SBCL have the former model, so in a software engineering sense it might be worth it, in some future in which the compiler is faster. So in that sense I'd really like to make sure that the compiler only gets faster. Hey, walking in Dybvig's footsteps? ;-) I can only hope to do so ;-) That guy is smart! Cheers, Andy -- http://wingolog.org/
Re: Locks and threads
Hi Linas, On Thu 05 Mar 2009 22:56, Linas Vepstas linasveps...@gmail.com writes: Perhaps I'm naive, perhaps some naming convention could be used to indicate that SCM_OUT_OF_RANGE will never return? None of the functions in the call stack gave any real hint that they might now return; they mostly looked liked ordinary functions. Changing the names would be quite an undertaking. Perhaps we should be more clear about this point in the docs, though, as it is fundamental to Guile programming in C. Cheers, Andy -- http://wingolog.org/
Re: eval-case and toplevel prohibitions
Hi, On Wed 04 Mar 2009 09:48, l...@gnu.org (Ludovic Courtès) writes: Andy Wingo wi...@pobox.com writes: So I was thinking: why do we have this fetish for prohibiting certain forms in a non-toplevel context? I am of a mind to replace eval-case with eval-when, which is actually more expressive, as it allows us to discriminate the different phases in non-toplevel contexts as well. Could it be because `eval-case' expressions can evaluate to nothing, which can be confusing in non-top-level contexts, e.g., (define (nothing) (let ((foo (eval-case ((never-true) 'foo foo)) Actually, this yields #unspecified in Guile-VM and #f in `master'. The definition of `toplevel-env?' in there in quite sloppy... I would suspect this depends on whether this code is being compiled or interpreted too, as the toplevel-env? check pokes the env arg to a mmacro... Here's a reason, maybe: (define (foo) (define-public (bar) 10) ...) That will expand to (define (bar 10)) (export bar), but bar does not have a variable in the current module. OTOH... `define-public' is a bit silly, and it and the `export' interface seem to be to be a part of the first-class module interface, which is a sharp tool -- it's assumed that you know what you're doing. Or, we could make define-public expand to something else that actually makes sense, like (module-define! (current-module) 'bar (lambda () ...)), then export that definition. My take: let's relax prohibitions, and try to produce intuitive behavior in more circumstances. Andy -- http://wingolog.org/
vm status update
Gentlemen, ladies: so long the hack, and so short the time. But the Creator in her wisdom or absence has given us this moment in which to ponder the novelties of the VM branch. Since we last rapped together, let's see: * One Sunday, I decided that we couldn't honestly claim to have a multilingual environment without actually implementing other languages. So I wrote a JavaScript tokenizer, a parser, a compiler to GHIL, and a runtime -- a week later, it was working! I wrote more about it here: http://wingolog.org/archives/2009/02/22/ecmascript-for-guile * Ludovic fixed loading of large unsigned integers, and added a -o option to the compiler, and coalesced the Makefiles in to just one in module/. My -j8 machine at work compiles much faster now ;) * I've started to think about optimization, and what's clear is that GHIL as it stands is too much of a pain in the ass -- you can't turn a ((lambda ...) ...) into a (let ... ...) without like 30 lines of code. I decided that having alpha-renamed variables would eliminate the need for ghil-env, and make GHIL actually readable and writable without loss of information. So I started looking at separating expansion + renaming from compilation, as the Scheme lords decree, but I'm not quite there yet. I have an expander, but we really want source information -- so I just fixed syncase expansion to give us source information corresponding to its output variables, but haven't yet figured how to recover the source lexical names. But I'll get it. Having now looked much more at syncase, I think it's pretty great. Also given that it finally loads quickly, and gives us source information, I want to include it at the heart of Guile -- early on in boot-9.scm. It goes against lazy memoization, but given that expansion is fast (and linear), that shouldn't be a big problem. We'll see how that goes. Syncase + GHIL without ghil-env also gives us the opportunity to simplify GHIL itself, removing e.g. quasiquote in favor of syncase's expansion. That can let us simplify the evaluator too. The interpreter could even become threadsafe, eventually. Anyway, that's where I am. Bug-wise we still have a bug in backtraces, which I need to pin down at some point, and update docs -- but generally speaking we're mergeable. What do people think, should I be working on master at some point? Cheers, Andy -- http://wingolog.org/
Re: vm status update
On Sun 08 Mar 2009 23:40, Neil Jerram n...@ossau.uklinux.net writes: l...@gnu.org (Ludovic Courtès) writes: Anyway, that's where I am. Bug-wise we still have a bug in backtraces, which I need to pin down at some point, and update docs -- but generally speaking we're mergeable. What do people think, should I be working on master at some point? Sure. Neil: what do you think? No problem, I'm happy for Andy to merge now. Great, I'll get to this within a week or so. Looking at `vm', it's been sometime since the last merge with `master', so it'd be worth checking that things still work. I guess that would mean merging master into vm first, and checking that, then merging vm into master. Yep. Cheers, Andy -- http://wingolog.org/
Re: Locks and threads
Hey Neil, On Thu 12 Mar 2009 01:53, Neil Jerram n...@ossau.uklinux.net writes: Thanks to a hint from helgrind, I think the problem might be that the symbols obarray is not thread-safe. But surely using a mutex for every symbol that Guile reads would be terrible for performance... Dunno, in GStreamer we found that uncontended locks are cheap cheap cheap. AFAIU they don't even cause context switches. And the reader will be less important in terms of e.g. startup time once the VM lands. Andy -- http://wingolog.org/
Re: vm merged to master
Hi, On Sat 14 Mar 2009 14:19, Neil Jerram n...@ossau.uklinux.net writes: - make distcheck fails; looks like because vm-i-*.i not included in the distribution (i.e. EXTRA_DIST). I have not yet poked distcheck, but non-srcdir builds do work as of now. I don't know what the deal with your make check issue is; can you reproduce it with a fresh checkout? Andy -- http://wingolog.org/
Re: vm merged to master
On Sun 15 Mar 2009 01:01, Greg Troxel g...@ir.bbn.com writes: My autobuild failed this morning (1000Z) during the build phase: I believe this problem is fixed. Please let me know if you find others. Andy -- http://wingolog.org/
Re: Locks and threads
On Sat 14 Mar 2009 15:23, l...@gnu.org (Ludovic Courtès) writes: Still, I would measure the impact on `module-define!' and `module-ref' because that's at least an additional function call. You probably know, but at least in the VM (and I thought in the interpreter too), the locations are computed once, and the resulting variable is cached. So module-ref is not called repeatedly for the same binding. Andy -- http://wingolog.org/
bugfix regarding recent master-vm merge rewrites history
Hi, There was a problem in the conversion of subrs to double-cells, in which the additional cells were not being marked. This was quite a number of commits ago, on master, and having such a large period in which that bug was present is not good for bisection. So I've revived the VM branch. It's the same as master, except commit 325226dad9ab6f0488500e7381a5d1c07dc9ae91 was retroactively introduced in the history. Anyway, all this to say that VM has been rewritten, and I'd like to copy it over to master. This is fine, but whenever you pull and get a forced update you always wonder why that was -- and this is why. If no one objects, I'll forcibly reset master to vm later this evening. Sorry for the confusion. Play around in gitk if it's not clear to you: gitk origin/master...origin/vm All of the merges are from when I was trying to figure out which patch introduced the bug. Cheers, Andy -- http://wingolog.org/
Re: Again on Windows support
Hi Carlo, Thanks for doing this testing. I do not know of anyone who has built Guile with the VM on Windows, so some of these problems are interesting. I can't speak to all of your issues, but regarding some of them: On Wed 18 Mar 2009 12:05, carlo.bramix carlo.bra...@libero.it writes: LIBGUILE/GSUBR.C function alloca() is undefined because under Windows the intrinsic function is called _alloca(). Hm, I thought the Gnulib alloca thing should have fixed this. Does adding #include alloca.h in gsubr.c not fix this? LIBGUILE/OBJCODES.C === sys/mmap.h is absent. This is unfortunate. But I understand that windows has ways of mapping files to memory, and we should use those. Do you know what those calls are? 'ulong' is undefined. Ah, I wonder how this got there. Fixed. compilation of function make_objcode_by_mmap() fails because function mmap() does not exist. I would rather implement this properly on windows than make a new, hacky function. This is a very important function, actually. LIBGUILE/VM.C = I have not really understood this error: ../../guile-git/libguile/vm-engine.c: In function `vm_regular_engine': ../../guile-git/libguile/vm-engine.c:277: error: unable to find a register to spill in class `SIREG' This is because in the VM we declare some variables to be in registers, but this confuses some gccs, especially on win32. I don't know what the real answer is -- perhaps we shouldn't force register allocation for these variables. It happens with GCC3.4.5, GCC4.1.3 and GCC4.3.0. That is good to know, thank you for testing with all of these. For the record I have only seen this problem with GCC 4.1.2 on Linux; e.g. 4.3.0 works for me. So there must be more register pressure on windows or something. We can work around it by setting vm-engine.h:72 to be: #if defined(__i386__) !defined(__windows__) But I need to know the right thing to put there for __windows__. I hope you will find it useful. Thank you! Andy -- http://wingolog.org/
Re: master/vm merged into `boehm-demers-weiser-gc'
Hi Ludo, On Sun 22 Mar 2009 11:26, l...@gnu.org (Ludovic Courtès) writes: The `master' branch (which contains the VM) was merged into the `boehm-demers-weiser-gc' branch: Startup time seems to be the same, which is good. I don't know about longer runs. I tried to run valgrind on Guile though and it segfaulted: wi...@unquote:~/src/guile$ ./pre-inst-guile-env gdb --args valgrind --tool=callgrind --num-callers=100 libguile/.libs/lt-guile -c 1 GNU gdb Fedora (6.8-29.fc10) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i386-redhat-linux-gnu... (gdb) r Starting program: /usr/bin/valgrind --tool=callgrind --num-callers=100 libguile/.libs/lt-guile -c 1 Executing new program: /usr/lib/valgrind/x86-linux/callgrind ==23226== Callgrind, a call-graph generating cache profiler. ==23226== Copyright (C) 2002-2007, and GNU GPL'd, by Josef Weidendorfer et al. ==23226== Using LibVEX rev 1804, a library for dynamic binary translation. ==23226== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==23226== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==23226== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==23226== For more details, rerun with: -v ==23226== ==23226== For interactive control, run 'callgrind_control -h'. Program received signal SIGSEGV, Segmentation fault. 0x62a880bd in ?? () (gdb) bt #0 0x62a880bd in ?? () #1 0x62a82f38 in ?? () #2 0x0001 in ?? () #3 0x0025 in ?? () #4 0x387062bc in vgPlain_threads () #5 0x62a82f2c in ?? () #6 0x0062d8ab in ?? () #7 0x38037cb6 in run_thread_for_a_while () at m_scheduler/scheduler.c:636 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x62ac54bb in ?? () (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x62ad9d9f in ?? () (gdb) c Continuing. ==23226== ==23226== Process terminating with default action of signal 11 (SIGSEGV) ==23226== Access not within mapped region at address 0xBF00 ==23226==at 0x4C091F8: GC_push_all_eager (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C09243: GC_push_all_stack (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C11F14: GC_push_all_stacks (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C0D5D6: GC_default_push_other_roots (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C0AFA4: GC_push_roots (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C0A89B: GC_mark_some (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C0226C: GC_stopped_mark (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C024E8: GC_try_to_collect_inner (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C0C52C: GC_init_inner (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4C0C656: GC_init (in /usr/lib/libgc.so.1.0.3) ==23226==by 0x4045D30: scm_storage_prehistory (gc.c:635) ==23226==by 0x4053773: scm_i_init_guile (init.c:432) ==23226==by 0x409C60C: scm_i_init_thread_for_guile (threads.c:670) ==23226==by 0x409C844: scm_i_with_guile_and_parent (threads.c:819) ==23226==by 0x409C99D: scm_with_guile (threads.c:801) ==23226==by 0x405361E: scm_boot_guile (init.c:354) ==23226==by 0x80487B1: main (guile.c:69) ==23226== ==23226== Events: Ir ==23226== Collected : 1893973 ==23226== ==23226== I refs: 1,893,973 Program received signal SIGSEGV, Segmentation fault. 0x3802c142 in do_syscall_WRK () (gdb) c Continuing. Program terminated with signal SIGSEGV, Segmentation fault. Andy -- http://wingolog.org/
Re: request review: branch wingo
Hey all, On Fri 27 Mar 2009 16:29, Andy Wingo wi...@pobox.com writes: On the wingo branch in the main repository, you will find the following patches: So, I really intended to wait for review, but it's irritating having `master' broken, so I went ahead and merged this in. I think the stack calibration stuff is correct, but perhaps more jarring in this commit is a move from ./pre-inst-guile to ./meta/guile, and ./pre-inst-guile-env to ./meta/uninstalled-env. I describe the rationale in 0b6d8fdc28ed8af56e93157179c305fef037e0a0. But then again, given that Neil invested so much time into the stack calibration stuff, that might be jarring too. Please let me know if yall have a concern with this merge -- we can fix it tomorrow or Monday. Cheers, Andy -- http://wingolog.org/
Re: Again on Windows support
Hi Carlo, On Fri 27 Mar 2009 02:39, carlo.bramix carlo.bra...@libero.it writes: Hello, I did a patch in the usual way instead of using GIT. It's good to have the patch inline to review. It looks fine to me but I will punt to Neil or Ludovic for the final review. Also, thanks for taking care of the mmap issue. (still need to know if the mapping created in function make_objcode_by_mmap() needs to be freed somewhere or not!) Guile never unmaps these files. I suppose it's possible, but if it is a bug it's a Guile bug and not specific to the win32 side of things. After that, compilation continued until it said that there was an error with restrict keyword. I was forced to change it to __restrict or __restrict__ otherwise it did not work. Odd, but your fix has no negative effects that I can see. make[3]: Entering directory `/home/Carlo/g/module' /bin/mkdir -p `dirname system/base/pmatch.go` ../pre-inst-guile-env ../guile-tools compile -o system/base/pmatch.go ../../guile/module/system/base/pmatch.scm ERROR: In procedure dynamic-func: ERROR: symbol not found So, if you've gotten this far, you should be able to run ./meta/guile, or ./pre-inst-guile (depending on how up-to-date your git is). If that doesn't work then perhaps set this as the equivalent of ~/.guile: (debug-enable 'backtrace) (debug-set! depth 80) and re-run guile; you should get a Scheme backtrace that you can paste here. Try also ./meta/guile -c 1 or ./meta/guile -c '(display foo)'. Let us know how it goes! Andy -- http://wingolog.org/
Re: stack calibration
Hi Neil,
On Mon 30 Mar 2009 13:43, Neil Jerram n...@ossau.uklinux.net writes:
Andy Wingo wi...@pobox.com writes:
Hey Guilers,
Hi Andy,
In summary, I'm not sure I'm following the logic here...
The recent commit to compile with the stack calibration file,
7ca96180f00800414a9cf855e5ca4dceb9baca07, breaks compilation because the
compile scripts have hash-bang lines like this:
#!/bin/sh
# -*- scheme -*-
exec ${GUILE-guile} -e '(@ (scripts compile) compile)' -s $0 $@
!#
FWIW, I think this kind of incantation is really horrible. Ditto for
usage of guile-tools What kind of a scripting language is it
that needs to be bootstrapped by a different language?
Dunno. While guile-tools should probably be written in Scheme, it
doesn't bother me. The strange invocation stuff is just to get around
posix's #! limitations -- it should be:
#!/usr/bin/env guile -e
but we all know the problem with that.
As far as needing the -e clause, it's so we can (use-modules (scripts
compile)) in addition to being able to run it as a script. Not that I
use that feature, but it is interesting.
Also, it is a bit irritating to have to load a file just so Guile won't
be broken (exaggerated wording, but I think that's what it is.)
I think you may be misunderstanding. stack-limit-calibration.scm
should make precisely 0 difference on the canonical build platform -
which in practice means ia32 GNU/Linux.
ia32 GNU/Linux is sometimes broken -- for example, build it with -O0,
and things often don't work at all.
stack-limit-calibration.scm is all about scaling down/up the hardcoded
value for a non-canonical platform that might use more or less stack
on average than the canonical platform - e.g. because it has fewer
registers, because its pointers are twice the size (ia64) etc.
The primary purpose of stack-limit-calibration.scm is to allow make
check to succeed on those platforms, and it now makes sense to
generalize that to any other guile-using operations that we run during
the build - such as compiling.
You want to actually use Guile after it's installed too of course, and
in those cases stack-calibration.scm doesn't help you.
I think I explained my perspective as well as I can in the other mail --
perhaps we can follow that part of the discussion there?
Andy
--
http://wingolog.org/
syntax-case + modules
Hi, In the syncase branch you will find a start at macro-expansion that is hygienic with respect to modules. Finally. There are some bugs in compilation right now, which I will fix soon, and explain later when I am less sleepy, but if you run with ,o interp #t things should be peachy. Yay! Andy -- http://wingolog.org/
Re: request review: branch wingo
Howdy howdy, On Tue 31 Mar 2009 14:31, l...@gnu.org (Ludovic Courtès) writes: Besides, there's the thread about cross-compilation where we mention building the compiler with an already installed Guile that may have an inappropriate stack limit. I don't think that is relevant. Since the Guile that is running would choose a stack size appropriate for it, based on the host getrlimit, there would be no problem. The already-installed Guile wouldn't use getrlimit(2) since that would be an old 1.8. You probably saw the other response already, but I don't think that the compiler will work with 1.8 as a host. You'd have to install a 1.9 on the host, and somehow tell it that it should compile .go files with the endianness of the target. Linking against uninstalled libtool libraries works fine, as long as you don't install. That's right, but that seems awkward to me, except for tests. I've used it in GStreamer for years now -- not a proof of correctness to be sure, but it works well enough to hack. Cheers, Andy -- http://wingolog.org/
Re: GSoC: Emacs Lisp support for GNU Guile
Hi Clinton, On Tue 31 Mar 2009 13:28, Clinton Ebadi clin...@unknownlamer.org writes: This is an excellent plan! Agreed! There is already a working elisp-scheme translator for the interpeter in lang/elisp. Yes, that would be a great starting point. replacing the @fop and @bind operators in the interpeter with a bit of GHIL implementing the same behavior. We can add ops to the VM if needed. - Remove handling of NIL in Scheme. I used to think as you do, but Neil convinced me otherwise. For me, %nil can stay. - Reimplement the basic elisp list operators in elisp/ghil rather than using the existing Scheme implementations This could be interesting but doesn't seem necessary - [Potentially] Remove value/function slots from Guile's symbol type and implement the Lisp-2ness of elisp in another way Dunno. - [Assuming the above is done; if not ((fref SYMBOL) ...) works already] Implement a convenient way to call elisp functions from Scheme. Something like (funcall SYMBOL ...) As Neil mentions, this seems possible already -- though not with VM code. Cheers, Andy -- http://wingolog.org/
Re: GSoC: Emacs Lisp support for GNU Guile
Hi Daniel, On Tue 31 Mar 2009 12:44, Daniel Kraft d...@domob.eu writes: as already discussed briefly with the Guile guys behind the new VM thing, I got the idea to implement Emacs Lisp as supported language for the Guile VM system. This sounds great! I'd love to assist. As the fellow who's hacked most on Guile's VM, I can offer mentorship if you like, on the Guile side -- though I am not as knowledgable about Emacs as I'd like to be. I'll direct replies to further Guile-type details to the Guile list, but in summary: Originally, Guile as the GNU scripting language was designed as a language based on the Scheme lisp dialect; however, as a prime example for use of a scripting language (and with a huge existing base of scripts) Emacs Lisp is another popular lisp based scripting language. With the new capabilities of Guile, it will be possible to add support of this language to Guile and thus allow it (and all programs using Guile as scripting engine) to be programmed not only in Scheme but also Emacs lisp; thus, it will also be possible to utilize all the existing elisp code for creating even more nifty and useful scripts. YMMV, but I think that elisp is most useful within the context of Emacs itself -- its data types, its libraries, its runtime. So after getting Emacs Lisp's semantics to compile, perhaps as a if time allows thing, defining a Guile implementation of emacs/src/lisp.h would allow Guile to slip into Emacs with minimal modification of C sources. Or perhaps it's better to limit this SOC to just the Scheme side of things? Dunno. In any case, I think with world enough and time, Guile can do whatever it takes to provide a faster, better Elisp implementation -- including adding Elisp-specific ops to its VM, if necessary. Communication: Depends on the requests from my mentor / the community, but I think the public development mailing lists and private email should be fine; other ideas are instant messaging / IRC. I'm often on #guile, with CET as my timezone. Between there and the mailing lists we should be good, avoiding private email. I hope this works out! Andy -- http://wingolog.org/
Re: GSoC: Emacs Lisp support for GNU Guile
Hi Neil :) Though I was not the person to whom the question was addressed, a comment :) On Tue 31 Mar 2009 15:23, Neil Jerram n...@ossau.uklinux.net writes: If you followed this kind of approach, note that it would also need work - in addition to the Elisp/VM translation - to implement whatever Emacs primitives the Elisp code relies on. That would make the project as a whole less pure-language-translation, but (in my view) more real and useful. I keep thinking that it should be possible to write some kind of C shim so that Guile could implement the Emacs C API. That way we keep the existing C code working, we keep the fine-tuned implementations and semantics, and we can move on from re-implementing to implementing -- e.g. adding to Emacs instead of just reproducing it. Happy hacking, Andy -- http://wingolog.org/
Re: request review: branch wingo
Howdy, On Wed 01 Apr 2009 15:23, Neil Jerram n...@ossau.uklinux.net writes: l...@gnu.org (Ludovic Courtès) writes: I have no objection to that. We still want to support existing scripts, of course - but I assume that's why you said mark as deprecated and not remove. :-) I agree :) We can make guile-config get its information from pkg-config instead. Cheers, Andy -- http://wingolog.org/
Re: stack calibration
Hi Neil, On Tue 31 Mar 2009 15:47, Neil Jerram n...@ossau.uklinux.net writes: Andy Wingo wi...@pobox.com writes: #!/usr/bin/env guile -e but we all know the problem with that. Only one argument being portably supported? (I _think_ that's the problem, but I'm not so sure that I don't want to check that that's what you mean!) Heh, yes. Sorry, I should have been more clear. As far as needing the -e clause, it's so we can (use-modules (scripts compile)) in addition to being able to run it as a script. Not that I use that feature, but it is interesting. I don't use it either, and I don't think it's interesting enough to justify the oddness of the incantation. I can't think of a scenario where it really makes sense to have a module and main program combined in the same file. If the module part isn't generally useful it doesn't need to be written as a module. If the module is generally useful, it should be given a place in the proper module tree (i.e. not scripts/...), and the script file should (use-modules ...) it. I kindof agree. There's no need to have those scripts be executable files -- we can have them be modules instead. Then guile-tools can just use-module them, as you say. But they can probably stay in the scripts directory, so as to mark them as runnable -- so you can query what scripts do I have installed? But at least they can go into module/scripts/. I'll do that at some point if you have no objections. Cheers, Andy -- http://wingolog.org/
Re: master build failure on netbsd
Hi, On Thu 02 Apr 2009 05:05, Greg Troxel g...@ir.bbn.com writes: debug.c: In function 'init_stack_limit': debug.c:532: warning: comparison is always false due to limited range of data type debug.c:535: warning: comparison is always false due to limited range of data type I pushed a patch just now that should fix this. It also removes the 1 MB cap on the default stack limit, as discussed in other threads. Thanks for the report, Andy -- http://wingolog.org/
request review testing: syncase
Hey folks, I've rebased the syncase branch on top of current master, and fixed everything I know about. Now you can have macros in modules that expand to references to identifiers that are local to the module that the macro was defined in. I mean to say: (define-module (foo) #:use-module (ice-9 syncase) #:export (bar)) (define-syntax bar (syntax-rules () ((_ y) (kar (frob y) (define kar car) (define-syntax frob (syntax-rules () ((_ y) y))) (define-module (baz) #:use-module (foo)) (bar '(a b c d)) = a Give it a look-see, a whirl, a what-have-you! I'd like to merge this one in at some point within the next week or two. I'll wait for an OK from Ludo or Neil before doing so, though. Peace, Andy -- http://wingolog.org/
Re: request review testing: syncase
Hi Neil,
Thanks for the review!
On Mon 13 Apr 2009 11:05, Neil Jerram n...@ossau.uklinux.net writes:
serialize module information into syncase's output -- getting ready
for hygiene
Renaming (ice-9 annotate) to (ice-9 expand-support)... is that really
compelling enough for the risk of upsetting someone (if there is
anyone!) who is using (ice-9 annotate) ?
(ice-9 annotate) is new, it's only been in for a month or two. So it's
not possible that anyone uses it :)
So far, not understanding why we don't generate (@ ...) or (@@
... directly), but perhaps that will become clear.
That's because syntax-case operates natively on syntax objects, which
already carry information with them regarding what piece of code
introduced them into an expansion. Adding modules to that information
was a natural fit, and allowed existing predicates to keep on working
(e.g. identifier?).
Also, using a part of existing Scheme (namely, @ and @@) introduces
hygiene problems of its own. One can imagine sandbox modules in which
certain imported macros are available, but @ and @@ are not available.
(This latter point is moot in the current implementation, but that will
change; the expansion stripper will do different, appropriate things
for the memoizer and for the compiler.)
add modules to syntax objects (part 1, intermediate step)
Out of interest, why use a vector here, whereas in the previous commit
you used structs?
Structs are actually vectors, within syncase at least. (This is all
within a big letrec IIRC, so these definitions don't escape the
expansion definitions.)
finish bootstrap to syntax-objects with modules
OK. I see now why the vector representation didn't matter. I hadn't
realized before that psyntax.scm required itself to bootstrap.
That's the magical thing about psyntax.scm, that it's an expander that
expands itself. Also the source of much consternation ;-)
thread the module through syntax-case's expansion
+SCM_DEFINE (scm_procedure_module, procedure-module, 1, 0, 0,
+ (SCM proc),
+ Return the module that was current when this procedure was defined.\n
+ Free variables in this procedure are resolved relative to the\n
+ procedure's module.)
Can you delete the second sentence?
Sure.
+#define FUNC_NAME s_scm_procedure_module
+{
+ SCM_VALIDATE_PROC (SCM_ARG1, proc);
Could you use scm_env_module () here to simplify the code?
Ooh, good point. Done.
more work on modules and hygiene, not finished yet, alas.
Hmm, eval closures are so 1990s: I think I agree, but I believe the
idea of eval closures was to allow other top levels than modules (and
the root). In case anyone out there is actually using a non-module
eval closure, are we inadvertently removing support for using syncase
with such top levels?
Hm, I think so. Given that Guile assumes that eval closure lookup is
idempotent, module binder procedures should have expressive power
similar to that of eval closures. I would like to remove eval closures
altogether.
+ ;(debug-disable 'debug 'procnames)
+ ;(read-disable 'positions)
Is that temporary?
It was intended to be ;-) Good catch, fixed locally.
-;; The following lines are necessary only if we start making changes
-;; (use-syntax sc-expand)
-;; (load-from-path ice-9/psyntax)
Am I correct in thinking that we have Makefile rules to automatically
do the needed generation when psyntax.scm changes?
Yes. If you touch psyntax.scm and then make, you'll see it.
- (build-global-reference (source-annotation (car e)) value mod)
+ (build-global-reference (source-annotation (car e)) value
+ (if (syntax-object? (car e))
+ (syntax-object-module (car e))
+ mod))
Didn't understand this change, and I'm not sure if the changelog
covers it. Can you explain more?
Sure. Consider a form produced by an expansion: `(a b c)'. The origin of
the list structure could be different than the origin of the parts; for
example a pmatch macro expansion would produce a (ppat ...) form whose
contents depend on the source text, and thus the expanded form belongs
to the source text, but the ppat identifier was introduced by the
expansion, and thus belongs to the module that pmatch was defined in.
The macro the above diff comes from, syntax-type, operates both on leaf
nodes and at one level removed from the leaf node. That is to say, it
can process identifiers, for dealing with identifier-syntax, and forms,
for dealing with macro expansion. The above diff deals with a form like:
(foo . rest)
which should be expanded out if `foo' is a macro. If `foo' is not a
macro, and not lexically bound, it is a call to a global procedure. But
that global procedure should be looked up to relative to the macro that
introduced it, not to the macro that introduced the enclosing form.
The diff says, if `foo' was introduced via hygienic expansion, scope it
relative to the macro that introduced it. (It could have been introduced
via datum-syntax-object, in which case we just give it the scope of the
compile-file works expression-by-expression
Hey folks, Compile-file now reads and compiles expressions one at a time. This means that an eval-when can affect the current language or current reader -- though we currently only use the current language's reader, the current-reader fluid is ignored. Ludovic, want to give it a poke? :) Gitk master for great justice, Andy -- http://wingolog.org/
Re: stack calibration
Hi Neil all,
On Mon 30 Mar 2009 22:43, Neil Jerram n...@ossau.uklinux.net writes:
Andy Wingo wi...@pobox.com writes:
#!/bin/sh
# -*- scheme -*-
exec ${GUILE-guile} -e '(@ (scripts compile) compile)' -s $0 $@
!#
FWIW, I think this kind of incantation is really horrible. Ditto for
usage of guile-tools What kind of a scripting language is it
that needs to be bootstrapped by a different language?
I've changed guile-tools in master to be a scheme script, and the
scripts themselves to be normal modules. Things moved around a bit, but
use-wise you shouldn't notice a difference.
Man, do I have a job ahead of me wrt NEWS updates...
Andy
--
http://wingolog.org/
Re: Wide chars and the VM
On Sat 18 Apr 2009 17:04, Mike Gran spk...@yahoo.com writes: Andy et al. What happens to the VM if characters become UCS-4 that ranges from 0 to 10? For example, in compile-bytecode.scm, (define (write-bytecode asm write-byte get-addr labels) (define (write-char c) (write-byte (char-integer c))) We add a make-char24 instruction, and write a uint24 if the (char-integer c) is bigger than 255. Sound right to you? Andy -- http://wingolog.org/
Re: Git questions
On Mon 20 Apr 2009 16:52, Mike Gran spk...@yahoo.com writes: I have a head (a string-abstraction branch) on my local clone of the git repository that I'd like to upload to the one on gnu.org. How do I do that? Assuming that you have the ssh:// git repo registered as origin, then: git push origin string-abstraction Cheers, Andy -- http://wingolog.org/
syncase merged to master
Hi all, I went ahead and merged the syncase branch to master. So syntax-case / syntax-rules macros in master will be hygienic with respect to modules in addition to lexical bindings. If I might rhapsodize a moment: it's fashionable in the Scheme world to criticize Guile. There are four major points: 1) Syncase macros are unhygienic with respect to modules 2) Syncase macros not available by default 3) Guile is slow (many flavors of this argument) 4) Guile doesn't even do unicode We're fixing all of these. Within the next couple months. We're doing great work, and we should be proud. #scheme can go to hell. Andy -- http://wingolog.org/
Re: syncase merged to master
Hey Julian, On Mon 20 Apr 2009 22:56, Julian Graham jool...@gmail.com writes: We're fixing all of these. Within the next couple months. We're doing great work, and we should be proud. #scheme can go to hell. Well, *you're* fixing most of them While it's true I have had a bit of time lately to poke at things, you've been looking at R6RS syntactic integration, Ludovic has been on the R6RS library problem (in addition to doing great work on the GC), Neil does great work with the manual and on subtle bugs, Mike will bring us something nice with Unicode support... and then besides the past that we are building on, there are those waiting in the wings to hack Elisp and threads and persistent data structures and better Emacs integration and on and on and on. It's a lovely time to hack Guile :-) some kind of marketing blitz is in order. Can the FSF / GNU project help with publicity in any way? I think you're totally right. FSF/GNU can help, but we need to have the vision -- strongly articulated, so as to cut through cobwebs of the past. But, and this is my perception, I think we have to be ready for the push when it comes. Documentation is /really/ important in that regard. As far as the new developments are concerned, we need to have a depth of documentation in place -- and already some of the stuff I wrote a few months ago needs updating already. So I think we need to have our ducks in a row before we really start pushing FSF/GNU. Andy -- http://wingolog.org/
Re: Merging Guile-R6RS-Libs in `master'
Hello Ludovic, On Tue 21 Apr 2009 23:18, l...@gnu.org (Ludovic Courtès) writes: Hello Guilers! I think it'd be nice to merge what's in Guile-R6RS-Libs into `master'. I do too! The 2 available modules are named `(rnrs ...)', as described in R6RS. However, R6RS specifies the version number `(6)' as part of the name as well, which we don't support. Modules could be called `(r6rs ...)', which would address the version number problem, or even `(ice-9 ...)', which would make it clear that the implementation is not R6RS-compliant but rather inspired by R6RS APIs. I'm not sure which one of these 3 options is the best one. This will probably depend on how Unicode support evolves. My intuition is that the Guile module `(foo)' should be representable as the R6RS module `(foo)', and vice versa. At this point, I know of no caveats. If this intuition is correct, `rnrs' should be the prefix; what to do with (6) is another question. Julian, do you know of any pitfalls in unifying the R6RS module namespace with the Guile module namespace? 2. C name space C function/macro/variable names are all prefixed with `scm_r6rs_'. Should it change to `scm_'? FWIW, I think so. 3. Bytevectors as generalized vectors? We could easily make bytevectors accessible through the generalized vector API. Pros: good integration, intuitive, convenient. Cons: incentive to use a standard API in a non-standard way. The latter may not be a problem since SRFI-4 vectors already behave this way. I have never used e.g. generalized-vector-ref. Too much typing. Do it if it makes sense, or if it's too much work add a FIXME to the docs so someone else can come along and take care of it. 4. Bytevector read syntax ... needs to be implemented. You are the reader master :) Comments welcome. o/~ Did you ever know that you're my hero o/~ Andy -- http://wingolog.org/
Re: Merging Guile-R6RS-Libs in `master'
On Wed 22 Apr 2009 17:53, l...@gnu.org (Ludovic Courtès) writes: Julian Graham jool...@gmail.com writes: Hey, if we're open to extending the module system, then sure -- that would certainly make for a cleaner, more efficient implementation. That's got my vote. Mine too :) The trick is to extend it in a backward-compatible way as much as possible. But now that we have hygiene and `use-syntax' has been sort-of phased out (Andy?), that should be doable. use-syntax deprecation is coming soon, perhaps tonight. Perhaps we could create a branch so that you could experiment things? What would it have? Module versions? We should probably take advantage of the occasion to separate the variable namespace from the module namespace. Cheers, Andy -- http://wingolog.org/
Re: Merging Guile-R6RS-Libs in `master'
Hi Julian! On Wed 22 Apr 2009 20:32, Julian Graham jool...@gmail.com writes: I have to confess, I'm totally at a loss as to how we're going to make versioning work with the autoload system. In particular, I see some difficulty in terms of determining whether to fully load and evaluate a module form during search. My understanding is that, in general terms, the existing system does the following: 1. Checks the set of registered modules 2. Locates a candidate module based on filename and loads it 3. Re-checks the set of registered modules This is the process for the modules that exist currently. Note that no module that currently exists has a version; so the lookup procedure for versioned modules can be different than what we currently have. For example, we can load a file, knowing with certainty that it should define a module of the given name and version. Not sure where I'm going with this ;) But given that the non-normative Appendix F states: Names for libraries may include a version. An import spec may designate a set of acceptable versions that may be imported. Conversely, only one version of each library should be part of a program. This allows using the “name part” of a library name for different purposes than the version. In particular, if several different variants of a library exists where it is feasible that they coexist in the same program, it is recommended that different names be used for the variants. In contrast, for compatible versions of a library where coexistence of several versions is unnecessary and undesirable, it is recommended that the same name and different versions be used. In particular, it is recommended that new versions of libraries that are conservative extensions of old ones differ only in the version, not in the name. Correspondingly, it is recommended that import specs do not constrain an import to a single version, but instead specify a wide range of acceptable versions of a library. Implementations that allow two libraries of the same name with different versions to coexist in the same program should report when processing a program that actually makes use of this extension. Guile should probably only support one live version of a module. So Guile's internal module namespace stays the same. Versions are only important when loading files from disk. I propose that we do it like this: (foo bar) - foo/bar.scm in the path, just as we have it now (foo bar (n)) - foo/barSEPn.scm, where SEP is some separator not valid in identifiers. Candidates for SEP? Unfortunately all the ones that can be bare in the shell seem to be taken. Actually maybe `/' is a good candidate, or in general the path separator. So it would be foo/bar/n.scm, where n would be the version. We then fix the path-searching functions in load.c to understand versions -- some trickiness there but we can do it. Cheers, Andy -- http://wingolog.org/
Re: Merging Guile-R6RS-Libs in `master'
On Wed 22 Apr 2009 22:22, Julian Graham jool...@gmail.com writes: Hi Andy, Guile should probably only support one live version of a module. So Guile's internal module namespace stays the same. Versions are only important when loading files from disk. I propose that we do it like this: Actually, I'd like to disagree here -- maybe I've been writing too much Java, but isn't it possible that the VM would be running more than one program (or maybe I misunderstand that term)? Or let's say that I absolutely need version 4 of library `foo', but that in the transitive closure of my library dependencies, there's another library (which I may prefer not to modify) that absolutely needs version 3 of `foo'. I can imagine this, but I can't imagine it working. What if those modules dlopen different versions of a shared library? There's going to be breakage, one way or another. Better to error out, Version 3.2 is already loaded, incompatible with = 4.0, or something. I agree with Ludo that versions are a bit half-baked. We should do what it takes to support them, but my personal opinion is that we don't have to think more about the things that the editors forgot to think about -- i.e. concurrent versions of the same lib. The problem of upgrading a module's version within a running system seems to be isomorphic to reloading a module. Jao has some ideas about how to do that. (foo bar baz (m n)) - foo/bar/m/n/baz.scm Looks good to me! My two cents, Andy -- http://wingolog.org/
syncase in boot-9
Hello all, A brief note. I have syncase in boot-9, with define-macro implemented in terms of syntax-case. This work can be found on the syncase-in-boot-9 branch. It's not quite ready yet, as there are some Scheme bits that still don't compile. I had to add docstring support to psyntax -- surprising to learn that other Schemes don't do docstrings. But the current linguistic sticking point are idioms like this: (if (something) (define foo bar)) or (if (defined? foo) (redefine foo) (define foo)) The latter is used in define-class for class redefinition. The former could be replaced with: (define bar (if (something) new-bar bar)) And the latter cases could probably be reimplemented using syntax-case instead of defmacro, but it's still really a shame that definitions and expressions are different things. Anyway, if you want to give it a try, checkout the syncase-in-boot-9 branch, and make -k, to step over the noncompiling scheme files. It's a work in progress, but I will not be rebasing it. Cheers, Andy -- http://wingolog.org/
Re: [Guile-commits] GNU Guile branch, syncase-in-boot-9, updated. 6a952e0ee9093424cdc8f300406d09ce195ebf5c
Hi, On Thu 30 Apr 2009 12:32, l...@gnu.org (Ludovic Courtès) writes: Andy Wingo wi...@pobox.com writes: * module/ice-9/boot-9.scm (and-map, or-map): Move these definitions up so psyntax can use them. (andmap): Remove, yay. I'm not sure how the latter relates to the rest of the commit. Make sure to at least have a `NEWS' entry for this. For what? andmap has been in no public release. Andy -- http://wingolog.org/
Re: [Guile-commits] GNU Guile branch, syncase-in-boot-9, updated. 3d5f3091e100550052abc698e980b3e86cc01b65
Hi,
On Thu 30 Apr 2009 12:30, l...@gnu.org (Ludovic Courtès) writes:
Andy Wingo wi...@pobox.com writes:
* libguile/macros.h: Add API for syncase macros.
Perhaps these should be made `SCM_INTERNAL'?
The functions should probably be public, as they are public to Scheme.
The bit-twiddlings should either be left as-is, or pulled into
macros.c -- but there is already some bit-twiddling that's public.
+SCM_DEFINE (scm_make_syncase_macro, make-syncase-macro, 2, 0, 0,
+(SCM type, SCM binding),
+Return a @dfn{macro} that requires expansion by syntax-case.\n
[...]
+SCM_DEFINE (scm_make_extended_syncase_macro, make-extended-syncase-macro,
3, 0, 0,
+(SCM m, SCM type, SCM binding),
+Extend a core macro @var{m} with a syntax-case binding.)
Can you explain how it works? Having a SMOB type for `syntax-case'
macros seems counter-intuitive to me. :-)
It's the same smob type as normal macros, but a different macro type.
Have another look :)
Andy
--
http://wingolog.org/
Re: Sting abstraction 2
On Wed 20 May 2009 17:24, Mike Gran spk...@yahoo.com writes: I've been working on the Unicode problem in Guile, and I had been too ambitious. I hacked it up pretty harsh and started getting errors that were tough to debug. Anyway, I backtracked a bit. FWIW this has happened to me a number of times. Bite off something big, understand the problem better, then come back and move from known-good state to known-good state. Yay git! :) Happy hacking, Andy -- http://wingolog.org/
Re: srfi-18 and the vm
On Fri 22 May 2009 17:10, l...@gnu.org (Ludovic Courtès) writes: ¡Hola! Andy Wingo wi...@pobox.com writes: I'm catching up with mail. On my syncase-in-boot-9 branch, I enabled compilation of srfi-18 and fixed a bug in it regarding multiple-value returns. Now I just ran the srfi-18 test like 100 times in a row and it didn't show any strange errors. Yy! What kind of strange errors would it lead to before? Random ones based on races, as code was lazily memoized from multiple threads at once. When SRFI-18 wasn't compiled, I would expect multiple value returns would translate in a `value.c' struct that would then be passed along as a single value. Indeed. The VM truncates multiple values, but here we were doing a (let ((x (values))) something x), which returned 0 values to a continuation needing a value, raising a valid error. Fixed that in the original source code. In addition, we were sometimes getting 0 values in a for-effect context, which the GHIL-GLIL compiler didn't support. Like this: (begin (call/cc (lambda (k) (k))) 10) I've fixed this in the tree-il-glil compiler. Cheers, Andy -- http://wingolog.org/
request review: syncase-in-boot-9
Hey folks! The syncase-in-boot-9 branch puts syntax-case expansion at the heart of Guile -- as the default expander, all Guile Scheme code would run through it; and as the first pass of the compiler, it analyzes all Scheme code, producing typed output. It makes syntax-rules and syntax-case available by default to all Guile Scheme code. Along with this branch comes a new intermediate language, to replace GHIL: Tree IL. It's much like GHIL, but with alpha-renamed lexicals instead of the intertwingliness of ghil-env. Its compiler to GLIL is much the same as the GHIL-GLIL compiler, though it adds some new tricks, and in the future will be augmented by a consistent inliner. It's time to merge it to master! :) Such a time is good for a few more eyeballs to see things, though, and point out regressions that need fixing, or ugliness. (I am not aware of any regressions. There is scattered ugliness, but I tried to keep that down, too.) What follows are the commit logs, from first to last, for replies to review. Cheers, Andy commit 757937c290ae64a7a75232793c659d0cca3dea10 Author: Andy Wingo wi...@pobox.com Date: Wed Apr 22 23:10:35 2009 +0200 more steps on the way to boot-time syncase * module/ice-9/boot-9.scm: Define a version of module-add! for psyntax, before modules are booted. * module/ice-9/psyntax.scm: Remove a warning, and rename a variable. Initialize a new variable to 'sc-macro, though it will have no effect. * module/ice-9/psyntax-pp.scm: Regenerated. commit a26934a850fba4ee1caf5d44cdbbe95115c91be0 Author: Andy Wingo wi...@pobox.com Date: Fri Apr 24 13:50:14 2009 +0200 module-name returns '(guile) during boot; psyntax tweak * module/ice-9/boot-9.scm (module-name): Return '(guile) before the module system is booted, for syncase's benefit. Defer redefinition until the module system is booted. * module/ice-9/psyntax.scm (put-global-definition-hook): Only set a variable if it's unbound. * module/ice-9/psyntax.scm: Regenerated. commit 131826039c62bdfd5932272b5d19d4b08cbe4e63 Author: Andy Wingo wi...@pobox.com Date: Fri Apr 24 13:54:38 2009 +0200 syncase early in boot-9, defmacros in terms of syntax-case -- halfway working * module/ice-9/boot-9.scm (eval-when): Remove, as syncase is going to handle this one for us. (sc-expand, sc-expand3, sc-chi, install-global-transformer) (syntax-dispatch, syntax-error, annotation?, bound-identifier=?) (datum-syntax-object, free-identifier=?, generate-temporaries) (identifier?, syntax-object-datum, void, andmap): Oh, ugly of uglies: add these exciting definitions to the main environment. Hopefully we can pull them back out soon. (make-module-ref, resolve-module): Stub these out, as a replacement for expand-support. (%pre-modules-transformer): Define to sc-expand, so that we are using syncase from the very start. (defmacro, define-macro): Define in terms of syntax-case. (macroexpand, macroexpand-1): Remove, there should be a different way to get at this -- though perhaps with the same name. (make-module): Make sc-expand the default module-transformer. (process-define-module): Issue a deprecation warning when using ice-9 syncase. (primitive-macro?): Remove, no meaning... (use-syntax): Deprecate. (define-private, define-public, defmacro-public): Rework in terms of syntax-rules. * module/ice-9/syncase.scm: Gut, as syncase is provided by core now. commit 64e5d08d3e7076b554f724efede860883f846b5f Author: Andy Wingo wi...@pobox.com Date: Fri Apr 24 14:01:26 2009 +0200 leap of faith: (ice-9 syncase) in psyntax-pp.scm - (guile) * module/ice-9/psyntax-pp.scm: Manually switch psyntax-pp over to (guile) from (ice-9 syncase). Heh heh. commit 85e95b47108a84f0829cf17c5dde40f53814186e Author: Andy Wingo wi...@pobox.com Date: Fri Apr 24 14:08:32 2009 +0200 fix load for syncase-in-boot-9; compile-psyntax works again * module/ice-9/r4rs.scm: * module/ice-9/boot-9.scm (%load-verbosely, assert-load-verbosity) (%load-announce, %load-hook, load): Move these from r4rs.scm to boot-9.scm. * module/ice-9/compile-psyntax.scm: Update to work with syncase-in-boot-9. * module/ice-9/psyntax-pp.scm: Recompiled with syncase-in-boot-9. commit c5ad45c7b34346f0f7084477479e7367c30a67f6 Author: Andy Wingo wi...@pobox.com Date: Thu Apr 23 12:41:03 2009 +0200 allow redefinition of global macros to variables * module/ice-9/psyntax.scm: Allow the redefinition of keywords to variables. Otherwise we can't do (define let #f), which is totally useful and stuff. * module/ice-9/psyntax-pp.scm: Regenerated. commit 01c161ca11b19d56ce994cba477a8fc4aeb8ac43 Author: Andy Wingo wi...@pobox.com Date: Thu Apr 23 13:30:23 2009 +0200 it is alive
Re: srfi-18 and the vm
Hi! On Sun 24 May 2009 00:03, l...@gnu.org (Ludovic Courtès) writes: I'm slightly concerned that doing things ahead of time rather than just in time (i.e., lazily) would have a negative impact on the interpreter's start-up time, which may be noticeable for short-lived scripts. In the guile -c 0 case, we don't have this issue, because no source is expanded; it's all compiled already. The load time on my machine is about 20 ms, which is about equal to what we discussed before (10 ms base + 10 ms for psyntax). It is faster than before, and will get faster. For loading uncompiled scripts, things will be slower, unless your modules #:use-syntax some other transformer. I don't know where the tradeoff is between the increased expansion speed due to compilation and slowdown due to a complete codewalk, but it's certainly there. OTOH I would suspect that we can implement some kind of just-in-time compilation -- essentially for each use-modules we can check to see if the module is compiled, and if not just compile it then and there. It would be a little slow the first time, but after that it would load much faster, even faster than before. Python does this. We could add a guile --no-comp option to disable it. What do you think? I think it's a good question, and we're going to have to settle on a good answer at some point. Cheers, Andy. -- http://wingolog.org/
Re: [Guile-commits] GNU Guile branch, string_abstraction2, updated. 823e444052817ee120d87a3575acb4f767f17475
On Tue 26 May 2009 00:22, l...@gnu.org (Ludovic Courtès) writes: However, this relies on eval-after-read semantics. That is, if the whole file is read at once, *then* evaluated, that won't work, right? Or read at once, *then* compiled, *then* evaluated; or even, read one expression at a time, compiled one at a time, but evaluated all of a piece. A -- http://wingolog.org/
Re: Merging Guile-R6RS-Libs in `master'
Hi Ludovic! On Thu 28 May 2009 00:27, l...@gnu.org (Ludovic Courtès) writes: Attached is my initial patch to integrate Guile-R6RS-Libs (bytevectors and I/O ports). I'll commit it shortly to `master' if nobody objects. Yay! It adds a dependency on GNU libunistring (by Bruno Haible). We could avoid it by importing all the Gnulib modules libunistring is based on, but I think it's better to not ship and link a copy of such a large body of code. Mike's work needs it as well. This is unfortunate, to have a new dependency, and on a library that's not in released distros, nor even very googlable. (I'm on the fedora 11 prereleases, and it seems there is no unistring package.) It's also unfortunate that we won't be sharing unicode tables with other apps that exist. But, I guess this is the right way forward. ASCII and wchar were even less fortunate ;-) Yay for unicode in Guile! Andy -- http://wingolog.org/
Re: 1.9.1 checklist
Hello! On Thu 28 May 2009 15:01, l...@gnu.org (Ludovic Courtès) writes: For 2.0, though, I think it may be wiser to let Andy take care of it, if he wants to: he's been more responsive than me, and he's the 2.x guy after all. ;-) Andy: what do you think? (I'm happy to take care of it if you can't or don't want to do it, but I don't want to be a burden for you and the other people involved.) To be honest, I'd rather not [have to] handle release mechanics -- while I can do it, I would be more than happy for you to keep handling releases, Ludovic. Or perhaps we should share the burden? For this upcoming series of 1.9.x releases, they come pretty frequently, and one of us might be out on holiday or something for the actual release day. So maybe we can coordinate together to determine who will handle individual releases. What do you think? Andy -- http://wingolog.org/
Re: [Guile-commits] GNU Guile branch, string_abstraction2, updated. 823e444052817ee120d87a3575acb4f767f17475
Hi, On Thu 28 May 2009 16:37, l...@gnu.org (Ludovic Courtès) writes: Andy Wingo wi...@pobox.com writes: This is complicated in Guile by #!. A reasonable thing would be to have the reader have a bit on whether it actually saw an expression yet or not. If not, ^;+ [^\n]*coding: ... would set the file's encoding. I think it would make sense to follow Emacs' specification of file-local variables as closely as possible (info (emacs) Specifying File Variables), as well as its naming scheme for encodings as shown by `M-x list-coding-systems'. Good points. Although, I wonder how emacs does the right thing regarding coding: if the variable list is at the end of a file. But certainly recognizing it in the first two lines of the file would be robust and follow emacs. Andy -- http://wingolog.org/
syncase-in-boot-9 merged to master; savannah down
Hey all, With Ludovic's blessing, I went ahead and merged syncase-in-boot-9 into master. Unfortunately I can't push it, because savannah is down. It appears they have had catastrophic disk failure. So what I've done is reset my origin/master ref to my master ref: git update-ref refs/remotes/origin/master `git rev-parse master` And created a git bundle for the origin/master ref : git bundle create guile-master.bundle --since=10.days origin/master Download guile-master.bundle from http://wingolog.org/pub/guile-master.bundle Then verify it: git bundle list-heads guile-master.bundle git bundle verify guile-master.bundle The list-heads output should be: 938d46a35d39ec5d7b5fa858a8783136ce24d10d refs/remotes/origin/master And then apply: git bundle unpack guile-master.bundle Then you can pull from master from your branches: git merge origin/master You can repeat the first two steps to upload your changes. Let me know how it goes, Andy -- http://wingolog.org/
Re: r6rs libraries, round two
Hey Julian, On Sun 31 May 2009 01:22, Neil Jerram n...@ossau.uklinux.net writes: Julian Graham jool...@gmail.com writes: 1. Add an optional `version' field to the module record type Sounds good. Agreed. * What's a good format here? We could mirror the requirements of R6RS here (i.e., (v1 v2 ...) where vx is a whole number) or be more flexible. Given that your objective is to get R6RS library support in, I'd say just stick to the R6RS format for now. It sounds like it will be fairly easy to extend this in future, if we want to. Also agreed. * Should we establish some rules for what you get when you don't specify a version? Yes! The latest available? I don't know. To me this could be a distro decision, like Debian's alternatives system. It would be nice to minimize the number of `stat' calls it takes to load a library -- which would fall out nicely if when asking for a module without specifying a version, like `(foo bar)', we give foo/bar.scm. In the presence of multiple versions, installation rules could handle making the symlink so there is a default version -- typically the version that was installed most recently. Given what we've decided about loading multiple versions of a library (i.e., you can't) I didn't follow why we decided that, but it feels wrong to me. (It seems to me that Guile should be able to handle loading ((foo) v1) and ((foo) v2) simultaneously as easily as it could handle loading ((foo-v1)) and ((foo-v2)) simultaneously.) I guess I should look up the previous thread, please let me know if you have a convenient reference. I agree it would be nice, but as I said in the thread that Julian referenced, that would take some more thought -- more than the R6RS editors were willing to give the problem. And for us, I suspect we would need some changes to our hierarchical namespaces. We probably shouldn't let this be a sticking point for Guile's R6RS libraries support. Regards, Andy -- http://wingolog.org/
Re: Publishing the manual...
On Sun 31 May 2009 02:11, Neil Jerram n...@ossau.uklinux.net writes: I should let you all know that Brian Gough has approached me about publishing the Guile manual. How lovely! This is great news :-) If you have any ideas about this, or would like to help out, or have any concerns, please let me know. Consider adding a section on GOOPS, from the GOOPS manual and tutorial. Folding that into the Guile manual would be great. We need to document syntax-rules and syntax-case, and the concept of hygiene wrt macros and modules. We should document the new REPL. Anyway, just some scattered evening thoughts. Good luck, and let me know if I can help in any specific way! Andy -- http://wingolog.org/
savannah back
Hey all, Savannah is back, with a backup of our Git repo from one month ago. I pushed master and syncase-in-boot-9; when you pull, you should get normal fast-forward updates. But other branches that changed in the last month (string_abstraction, string_abstraction2, Daniel's brainfuck compiler) will need to be pushed again. So Mike and Daniel, just run a git fetch; git push and things should be fine. Cheers, Andy -- http://wingolog.org/
autocompilation support in master
Hey folks, I pushed support for automatic compilation in master. That is, whenever load-from-path sees that it should compile a file, and autocompilation is enabled, it compiles the file then and there. I went ahead and enabled this feature, to see exactly what kinds of bugs this will cause. There's a lot of trickiness to this, but I think we all have instincts on how this should work. I'll write docs soon, but in the meantime, I would like for folks to ignore the implementation, and just use Guile for a while, and see if what it does sounds right to you. It prints some status info on the console when autocompiling. Of course, after the gut reaction, I would appreciate implementation criticisms as well :) Regards, Andy -- http://wingolog.org/
preserving timestamps on installation
Hey folks, Development Guile support compilation of Scheme files, finally. But the deal is that it will load the source file instead if the mtimes on the Scheme and compiled files differ. Where automake comes in is that installing a file touches its mtime, always, not preserving the mtime of the file being installed. What I would suggest is, given that automake ships with an install.sh, add the -p option to install.sh, corresponding to install(1), and use it by default. I can't think of any downsides. Cheers, Andy -- http://wingolog.org/
1.9 on the 19th; freeze 10 june (this wednesday)
Hey folks, After talking with Ludovic I think we're aiming for next friday for a release, 19 june. In order to test thoroughly, I'd like to put Guile master into freeze mode this Wednesday, 10 June. What does that mean? It means, between 10 June and the 1.9.1 release, no new code should go into Guile master. It is time to focus on testing. Commits to fix regressions would be welcome, as would documentation. If there are no objections, then let's settle on that. One more thing, since time is running short: if there are people reading this that package software for distributions, please package libunistring, or poke the right person to do that. It will make installing Guile easier. Thanks! Andy -- http://wingolog.org/
Re: preserving timestamps on installation
On Sat 06 Jun 2009 15:21, l...@gnu.org (Ludovic Courtès) writes: Hi Andy, Andy Wingo wi...@pobox.com writes: Where automake comes in is that installing a file touches its mtime, always, not preserving the mtime of the file being installed. Could it be solved with an `install-hook' target that would touch all the installed `.go' files? That's what I do now, though I'm not sure if the -r argument to `touch' is portable. A -- http://wingolog.org/
Re: 1.9 on the 19th; freeze 10 june (this wednesday)
On Sat 06 Jun 2009 16:16, l...@gnu.org (Ludovic Courtès) writes: Hi Andy, I happen to have a very short time slot to do some testing... Anyway, here's what make check tells me: FAIL: test-fast-slot-ref ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-autocompile argument to disable. ;;; compiling /home/ludo/src/guile/module/srfi/srfi-1.scm ;;; compiling /home/ludo/src/guile/module/system/base/compile.scm ;;; it seems /home/ludo/src/guile/module/system/base/compile.scm ;;; is part of the compiler; skipping autocompilation This must mean you didn't run a `make' first. Is this the case? If so, we should fix up our make rules to require a `make' first. Andy -- http://wingolog.org/
Re: autocompilation support in master
On Sat 06 Jun 2009 15:19, l...@gnu.org (Ludovic Courtès) writes: Incidentally, I just did a `pull', and compiling the compiler appears to be much slower than in my recollections (pre-syncase merge, I think). Is it just an impression? Nope, not just an impression, it's true. Reasons discussed in the last message in the srfi-18 and the vm thread. A -- http://wingolog.org/
Re: [Guile-commits] GNU Guile branch, master, updated. a9b0f876c12bbbca9bdf1890eb014a30f004d9f8
On Fri 05 Jun 2009 15:21, l...@gnu.org (Ludovic Courtès) writes:
Hello!
Andy Wingo wi...@pobox.com writes:
@deffn Instruction object-ref n
-Push @var{n}th value from the current program's object vector.
+...@deffnx Instruction long-object-ref n
+Push @var{n}th value from the current program's object vector. The
+``long'' variant has a 16-bit index instead of an 8-bit index.
@end deffn
Good that you fixed it! However, I'm wondering whether it's really a
good idea to keep both the long and short instruction variants, instead
of having a single 16-bit variant. What do you think?
The 8-bit cases are more common, leading to less code size, and
hopefully more cache hits. But see below...
+VM_DEFINE_INSTRUCTION (52, long_object_ref, long-object-ref, 2, 0, 1)
+{
+ unsigned int objnum = FETCH ();
+ objnum = 8;
+ objnum += FETCH ();
Perhaps a FETCH32() macro would actually be handy, and possibly more
efficient on platforms with 32-bit GP registers.
Actually, it would be even better if OBJNUM was encoded as part of the
instruction, since it would reside on the same cache line as the
instruction that's just been read. It'd look like:
#v+
objnum = ((* (ip - 1)) ~SCM_VM_INSTRUCTION_MASK)
SCM_VM_INSTRUCTION_MASK_LOG2;
#v-
Well, if you were to do this, you would want aligned, word-sized
instructions. This might be the right thing but I am not convinced, as
it would double or quadruple the size of the code, thus increasing cache
pressure. Java's bytecode is one byte in width, Lua's is too, Self's was
one byte wide, ... I don't know I guess is my perspective. I'd be
interested in checking this out, but it would take a few days, and I'm
trying to focus on broad correctness, then we could analyze such a
change with regards to benchmarks.
Also, I've forgotten about the details, but I was expecting one of the
fields in `scm_objcode' to become 16-bit after this change. Probably
I'm just confused? :-)
Yes you are confused :) The object table is stored in a Scheme vector.
Cheers,
Andy
--
http://wingolog.org/
Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509
Heya,
On Sat 06 Jun 2009 16:31, l...@gnu.org (Ludovic Courtès) writes:
Hello,
Andy Wingo wi...@pobox.com writes:
+SCM_DEFINE (scm_uniform_array_to_bytevector, uniform-array-bytevector,
+1, 0, 0, (SCM array),
+Return a newly allocated bytevector whose contents\n
+will be copied from the uniform array @var{array}.)
+#define FUNC_NAME s_scm_uniform_array_to_bytevector
+{
+ SCM contents, ret;
+ size_t len;
+ scm_t_array_handle h;
+ const void *base;
+ size_t sz;
+
+ contents = scm_array_contents (array, SCM_BOOL_T);
+ if (scm_is_false (contents))
+scm_wrong_type_arg_msg (FUNC_NAME, 0, array, uniform contiguous
array);
+
+ scm_array_get_handle (contents, h);
+
+ base = scm_array_handle_uniform_elements (h);
+ len = h.dims-inc * (h.dims-ubnd - h.dims-lbnd + 1);
+ sz = scm_array_handle_uniform_element_size (h);
+
+ ret = make_bytevector (len * sz);
+ memcpy (SCM_BYTEVECTOR_CONTENTS (ret), base, len * sz);
Is this memcpy valid in the case of shared arrays? Looks like we end up
copying more elements than needed, but maybe it's better this way.
I'm not entirely sure. I thought that scm_array_contents will give me a
contiguous array, though trolling around in srfi-4.[ch] and unif.[ch]
makes me grumpy ;)
+ uniform-array-bytevector
I would not export it from `(rnrs bytevector)' given that it has nothing
to do with RnRS.
No, but it does have to with bytevectors... Where would you put it?
Also, I would make the new C functions private, given that they are not
intended for general use AIUI.
Dunno. I could imagine calling both of them from C. Would there be a
problem with leaving them to be public?
Cheers,
Andy
--
http://wingolog.org/
Re: Build problem in guile trunk
On Sun 07 Jun 2009 19:08, Juhani Viheräkoski moonsh...@kapsi.fi writes: Guile trunk as of today seems does not build (I ran make distclean after updating to latest version, this might explain if you do not get the same error). This is what it chokes on, after the error message it goes to an infinite loop: Thanks for the report, and apologies for the breakage. I think I fixed this last night. Can you give it another roll? Thanks, Andy -- http://wingolog.org/
Re: autocompilation support in master
On Tue 09 Jun 2009 20:47, Mark H Weaver m...@netris.org writes: On Tue, Jun 09, 2009 at 09:27:37AM +0200, Andy Wingo wrote: It's a strange thing, and I don't see it on my x86-32 laptop running Fedora. But I've heard reports of this. A backtrace at the time of stack overflow would be helpful. Strangely, the stack overflow doesn't happen when I run the compile command (as echoed by make) directly from the command line. I only see it happen when compiling via make. Hm, that is indeed odd. Also odd is that here, I only get errors building this if I set my ulimit below 128 *kilo*bytes. gcc (GCC) 4.4.0 20090506 (Red Hat 4.4.0-4) To generate the backtrace, I added the following lines near the top of guile-tools. Is there a better way? (debug-enable 'debug) (debug-enable 'backtrace) (debug-set! depth 100) (write (debug-options-interface)) (newline) No, this is the best way we have currently. As I understand it, the debugging evaluator is slower than the normal one -- but at this point, who cares? With the VM we are already faster and we keep backtraces. We should have backtraces on, always. Does anyone have objections to that? If not, I'll make that change within the week. GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o language/ecmascript/spec.go language/ecmascript/spec.scm (show-file-name #t stack 4 debug backtrace depth 100 maxdepth 1000 frames 3 indent 10 width 79 procnames cheap) Backtrace: In ice-9/psyntax-pp.scm: 20: 271 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 272 [# core-form # # ...] In unknown file: ?: 273* [map #program 4060aa30 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] Hmmm. I'll poke some options. Thanks for the BT. Andy -- http://wingolog.org/
Re: (debug-options 'full) is broken
On Tue 09 Jun 2009 21:27, Mark H Weaver m...@netris.org writes: According to node User level options interfaces of api-options.texi, (debug-options 'full) should print a list of options, but it fails with ERROR: unbound variable: option-name. The other options interfaces (eval-options, read-options, print-options, traps) are broken as well. The problem is here, in boot-9.scm: (defmacro define-option-interface (option-group) (let* ((option-name car) (option-value cadr) (option-documentation caddr) ;; Below follow the macros defining the run-time option interfaces. (make-options (lambda (interface) `(lambda args (cond ((null? args) (,interface)) ((list? (car args)) (,interface (car args)) (,interface)) (else (for-each (lambda (option) (display (option-name option)) (if ( (string-length (symbol-string (option-name option))) 8) (display #\tab)) (display #\tab) (display (option-value option)) (display #\tab) (display (option-documentation option)) (newline)) (,interface #t))) [...etc...] How was this supposed to work? How were the local bindings of option-name, option-value, and option-documentation supposed to be referenced from within the expansion of this non-hygienic macro? Umm... Oops :) See, these things used to be memoizing macros, the thing that Guile's old defmacros were built on. I translated them to defmacros, but, um, not very well, apparently ;-) I'll see if I can push a fix. BTW I pushed something that might affect the stack overflow issue, can you give that a try? I have one report of it working where it didn't use to work. Cheers, Andy -- http://wingolog.org/
Re: Emacs Lisp revived
Howdy, On Tue 09 Jun 2009 22:07, Daniel Kraft d...@domob.eu writes: I finally started real work on implementing the elisp compiler and just pushed a first start-off code to branch elisp. It is however not yet usable for anything, but also already has some very few things done. Yay!! I hope to have time to look at your branch soon :) 1) In implementing all those special forms like progn, prog1, if, while, ... I think it is best to translate a basic set directly to TreeIL via the compiler, but also implement some (where that's reasonably possible) simply as elisp macros (or even some things as functions). What do you think about this plan? A core should compile to tree-il, and then you should be able to build the rest with macros. What fun, no? :) 2) It seems that elisp uses nil as false value (and does not have a dedicated false); so the question raises, should be then always use #f for nil, or maybe TreeIL's void? Don't use void. You should use Guile's %nil, and we should have a make-nil instruction. %nil was added to Guile for precisely this purpose. tree-il@(guile-user) (if (void) (const 1) (const 2)) Oh yes, (void) is true indeed. (I'm happy you're using the tree-il repl btw, that's nice :) Not related, but I came across it: (if (begin) 1 2) gives an error, don't know if that's expected. Yes, it is an error. Surprising to me when I found that out, but even R5RS prohibits it. 3) I still haven't got building lexical constructs in TreeIL working (and I figure that named-lets for compiling the while-construct are even more interesting), but will hopefully manage to do so soon... Ooh, sorry for not getting back to you about that. I'm sleepy now though ;) Here's some examples: scheme@(guile-user) (use-modules (language tree-il)) scheme@(guile-user) (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il)) $3 = (let (x) (x33) ((const 10)) (apply (toplevel +) (lexical x x33) (lexical x x33))) scheme@(guile-user) (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il)) $4 = (let (x) (x34) ((const 10)) (apply (toplevel +) (lexical x x34) (lexical x x34))) scheme@(guile-user) (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il)) $5 = (let (x) (x35) ((const 10)) (apply (toplevel +) (lexical x x35) (lexical x x35))) scheme@(guile-user) (compile '(let ((x 10)) (+ x x)) #:to 'tree-il) $6 = #let src: #f names: (x) vars: (x36) vals: (#const src: #f exp: 10) body: #application src: #f proc: #toplevel-ref src: #f name: + args: (#lexical-ref src: #f name: x gensym: x36 #lexical-ref src: #f name: x gensym: x36) You see what changes and what does not? The gensyms are fresh names for the lexically bound vars. They are introduced in the binding constructs and included in the references. You can make a gensym with the `gensym' procedure. Happy hacking! Andy -- http://wingolog.org/
string_abstraction2 review
Howdy good sir! I've been taking a look at string_abstraction2 this evening. (Well, I wrote that last evening. Time passes!) I'm really looking forward to it going in. The concepts seem sound, but I think the branch could be even better with a rebase. Further comments and impressions: commit 6d1c2613b799c86ac183a2f520c789f0afb8cf60 Author: Michael Gran spk...@yahoo.com Date: Sun May 17 20:07:53 2009 -0700 Gnulib updates to support wide characters We can probably drop this one entirely, no? [It imports the libunistring gnulib module, but we depend on libunistring being installed instead.] commit ffc654adb020bd8bd1b108e7c7047c8b7da410a3 Author: Michael Gran spk...@yahoo.com Date: Sun May 17 20:33:53 2009 -0700 Use 32 bit characters This one looks great. My only comment is that it would be better to keep SCM_MAKE_CHAR as a pure macro. commit dfbcbe20c7d010bc9f0a64f40b0aaae635915405 Author: Michael Gran spk...@yahoo.com Date: Sun May 17 21:03:00 2009 -0700 String abstraction -- don't unpack symbol characters in eval. Looks good, though to my eyes there's no need for the String abstraction -- prefix -- in the end these commits will stand alone in the git history. Please ignore if it's against other input you have received, or against your sensibilities :) commit 53464169b1799036ddee2fcf07b0dd92e3fc8d4b Author: Michael Gran spk...@yahoo.com Date: Sun May 17 22:36:04 2009 -0700 String abstraction -- use string operators in hash Looks good also. Only question is why scm_i_string_ref_to_int32 -- why not scm_t_wchar, and just call it scm_c_string_ref ? commit d311521f6e280aca9a2687624a5b36b38f60cfc7 Author: Michael Gran spk...@yahoo.com Date: Sun May 17 22:55:21 2009 -0700 String abstraction -- use string operators for filesys Looks good -- though again, scm_i_string_ref_eq_char doesn't sound right as a name. scm_i_string_has_char_at, maybe? Dunno.commit 07ed5be21432fcb2b092d372067a002f6662aac5 Author: Michael Gran spk...@yahoo.com Date: Sun May 17 23:24:44 2009 -0700 string abstraction -- use symbol operators in garbage collector Same notes for scm_i_symbol_ref_eq_char, and I don't think scm_i_symbol_ref_to_char should exist -- the cost of that struct vtable layout cruftiness should probably be borne by struct.c. commit 554c99e7c348ce7d02f2337fa2f04d666c6de892 Author: Michael Gran spk...@yahoo.com Date: Sun May 17 23:34:46 2009 -0700 string abstraction -- avoid unpacking strings when defining goops classes Looks fine, though some logic is duplicated. Still it's OK. Say, you're using tabs in some of these commits -- please don't :-) (setq indent-tabs-mode nil) if you use emacs. commit 6443bf5de7dd727cf5f5ededc016e6c349518da4 Author: Michael Gran spk...@yahoo.com Date: Mon May 18 06:35:08 2009 -0700 string abstraction -- avoid unpacking port mode strings Excelente commit 3570ed124988dbcc3f2085c5ef501cd124b945a7 Author: Michael Gran spk...@yahoo.com Date: Mon May 18 06:42:39 2009 -0700 string abstraction -- avoid unpacking mode mknod strings Cool commit 12348d6335c2cb9da08badc707dc1bd069844bb1 Author: Michael Gran spk...@yahoo.com Date: Mon May 18 06:47:43 2009 -0700 string abstraction -- don't unpack random state string The remember_upto_here needs to go just before the return. commit 322197c8e2e5aac004290a075d5391b88a66a7f7 Author: Michael Gran spk...@yahoo.com Date: Mon May 18 06:57:38 2009 -0700 string abstraction -- avoid unpacking delimiter strings Do we really need the eq_char version and the eq_wchar version? Can't we just have the latter, and char casts to wchar transparently? commit 4c57c26923c0b6ae5027c76dc32e5251a2f6cbcf Author: Michael Gran spk...@yahoo.com Date: Mon May 18 07:23:10 2009 -0700 string abstraction -- avoid unpacking strings in send/recv Hm. It seems it would be better for send/recv to take bytevectors, but to accept strings for back compatibility. It's a somewhat orthogonal question to your patch, but now that we have bytevectors, this is exactly what they're for. That way we can deprecate passing strings to these functions. What do you think? commit a462ad13abac7f12fa370fb1724a6eb7d80edcb2 Author: Michael Gran spk...@yahoo.com Date: Mon May 18 07:50:21 2009 -0700 string abstraction on charsets and combine redundant string_ref_to_XXX I still thing scm_i_string_ref should just return a wchar :) Regarding character sets: I understand that Will Clinger has an efficient implementation of character sets in Scheme that works well with the sparse nature of Unicode codepoints. Perhaps that could be of use. Dunno. commit 1091a38a8599f41c551686845fa4559f67e898a1 Author: Michael Gran spk...@yahoo.com Date: Mon May 18 08:27:29 2009 -0700 Convert
Re: 1.9 on the 19th; freeze 10 june (this wednesday)
Hi Ken, On Thu 11 Jun 2009 04:13, Ken Raeburn raeb...@raeburn.org writes: On Jun 6, 2009, at 05:45, Andy Wingo wrote: * r6rs-ports.c needs to include libguile/r6rs-ports.x, like the other source files do, instead of r6rs-ports.x Neil seems to have fixed this one. Thanks for the report. * There needs to be a SCM_API declaration of scm_cells_allocated, or it won't be exported from the library, and the test programs won't link. I put one in gc.h and it seems to work. The library sources apparently get compiled with -fvisibility=hidden, and SCM_API overrides that. (Which makes me wonder why it isn't blowing up for everyone on other systems...) Which test programs are these? I don't see references to scm_cells_allocated anywhere other than in gc.c. Perhaps this is related to your next comment: * At least in test-suite/standalone the preprocessor options telling the compiler where to find Guile's headers seem to come after the configure-time CPPFLAGS. This doesn't work out well if I need the latter to tell Guile where GNU MP is installed, but there's also a version of Guile installed there too. It seems you hit http://thread.gmane.org/gmane.lisp.guile.bugs/3874 . I guess we should fix this before the prerelease... Regards, Andy -- http://wingolog.org/
Re: guile and emacs: unexec
Hi Ken, On Fri 12 Jun 2009 07:02, Ken Raeburn raeb...@raeburn.org writes: I'm glad to see the emacs-lisp work is progressing. As it happens, a month or so ago I blew some of the dust off my old guile-emacs project and started working on it again too. This flavor of emacs+guile work aimed to replace Lisp objects in Emacs with Guile objects at the lowest level (numbers, cons cells; symbols and such become smobs) and then work upwards from there. Very interesting! To be clear -- the goal would be to represent as much of Emacs using cheap Guile structures as possible: numbers and cons cells and such, and represent specific Emacs objects as smobs? That's probably a good idea. Symbols however should probably be represented as Guile symbols, not smobs. I think that you will find that with a more compilation-centric approach, we will be able to keep more simple datatypes, as we compile the procedures that operate on those data types to appropriate code. I've updated to recent Emacs sources and Guile 1.8.6. I've gotten it to a point where it seems to start up fine in tty mode, reads in (and does color highlighting of) C files and directories, does some other basic stuff. I'm tweaking it now to see if I can get more stuff working (like Cocoa support and make bootstrap) and do more extensive testing. Very neat! That's fantastic that you were able to get it this far, I didn't know that was possible. If this is an effort that you want to pay off in the future, though, I would strongly suggest updating to the 1.9/2.0 series of Guile. The expressive range of Guile's multilingual facilities is much higher there, and significantly different from 1.8. OTOH, the emacs lisp support is not yet up to the level that it is at in 1.8, so perhaps now is not yet the time. One really big hiccup I've run into, which I've sort of sidestepped for the moment: Guile is not unexec-friendly. There is a way to build Emacs so it doesn't use unexec, but it then has to load a lot of Lisp code at run time, really killing the startup performance, and I don't think it's tested all that much (e.g., make bootstrap doesn't work even without the Guile hacks). To really make this project work, I need to be able to link against Guile (static is fine, and probably necessary), do a bunch of Lisp/Scheme processing, write out a memory image into a new executable, and later be able to run that executable. It's true that Guile doesn't do unexec currently. It might in the future -- obviously it will if you implement it of course ;) But I would ask that you reconsider your approach to making Guile-Emacs load quickly. There is no a priori reason that loading Lisp code should be slow. With Guile-compiled elisp, loading a file is just mapping it into memory -- the same as you have with an image. The loaded code needs to be run to establish definitions, but that is a very quick operation. I agree that heap saving could be slightly faster. But I think that Emacs should be able to load from bytecode within 100 ms or so /with the current Guile-VM code/ -- and even faster if we do native ahead-of-time compilation at some point. Any record of current threads needs to go away, and be replaced with info on the new one-and-only thread in the new process; I'm building without thread support for now to get around it. Any record of stack regions to be scanned for SCM objects likewise needs resetting. Allocated objects must *not* go away, and must continue to be processed by the garbage collector, so I can't just reinitialize everything. Assigned smob types must remain in effect, and for now I'm ignoring the possibility that some smobs may need some kind of reinitialization. Mutexes... well, I don't know if they need reinitializing; POSIX is kind of unclear on interactions with unexec. :-) I expect reinitializing them is probably safe, even if not required in some implementations. This could be complicated if we merge in the BDW-GC branch, to use libgc. Note that SCM does have unexec, IIRC, we could steal parts of their implementation Is this something that could be useful to anyone outside of Emacs? Unexec certainly could, to deliver self-contained binaries. But TBH I think the booting-from-compiled-files option is more maintainable. In any case this would be a neat hack. Have fun! :) P.S. If anyone wants to take a look at my current work, http://www.mit.edu/~raeburn/guilemacs/guile-emacs.tar.bz2 has a snapshot from tonight. Cool! Have you considered using git, and branching from Emacs' git mirror? That way it is trivial to set up something other people can comment on, in easily-digestible patch chunks. Happy hacking, Andy -- http://wingolog.org/
NEWS entries -- user-visible?
Greets, It seems that some of the NEWS entries that are currently there for the 1.9.0 release reflect awesomeness, but not awesomeness which users can react to. Specifically, I am going to remove the following NEWS entries, which are great stuff but thankfully invisible to the user: ** Guile now uses Gnulib as a portability aid ** Primitive procedures (aka. subrs) are now stored in double cells This removes the subr table and simplifies the code. ** Primitive procedures with more than 3 arguments (aka. gsubrs) are no longer implemented using the compiled closure mechanism. This simplifies code and reduces both the storage and run-time overhead. Let me know any feedback you might have. I'll be working on compiling a more comprehensive NEWS tonight and in the coming days. Peace, Andy -- http://wingolog.org/
LGPLv3?
Hi, Some motions were made to switch to LGPLv3. I think it's a good for Free Software if Guile switches to LGPLv3. Shall we update copyrights before Friday's release? Andy -- http://wingolog.org/
release update
Hey Guilers, I didn't push anything specific regarding a freeze, but in practice since we're so few, we've been great at just putting in release-worthy fixes :) I would say that we are definitely on track for a 1.9 on the 19th. I have a list of things to add to the NEWS, which I'm appending to this mail just to give some scope -- the list only goes back to September of last year, when it really needs to go back to May or so when I started work on the VM, but it's close to complete WRT what I need to add. Please add on any missing points. Note that the 1.9 release notes will become the 2.0 release notes, I think; over the next few months we will be editing them, adding and removing things, so that readers for the 2.0 release will understand what it is we've been up to over the last few years. One question is that I've been calling this thing 1.9.1 under the assumption that we made a 1.9.0; but that does not seem to be the case. Should this one be 1.9.0 or 1.9.1? OK, enough rambling. I have a plane flight tomorrow in which to write proper NEWS entries, after which hopefully all will be set for a release on Friday. Cheers, Andy raw NEWS notes: stack limits -- rlimit and default limit fix false-if-exception automatic compilation -- note mtime implications GUILE_LOAD_COMPILED_PATH, %load-compiled-path, %load-compiled-extensions the ~/.guile-ccache dir libdir installs for compiled code scm_primitive_load_path additional arg: exception_on_error scm_stat exception_on_error optional arg ccachedir to build-info ? #', #`, #,, #,@ -- and note the difference #; tail calls and stack narrowing source location tracking in psyntax macros before uses of macros no more currying modules do have names -- even gensymmed named different syntax exception strings (and sometimes keys?) values truncates values in the some cases requires 1 value interactions between hygienic macros and defmacros first-class macro values psyntax propagates original variable names -- into compiled code only, though the extended macro types -- make-syncase-macro, make-extended-syncase-macro, macro-type, syncase-macro-type, syncase-macro-binding removed sc-expand3 remove (void) (ice-9 syncase) deprecated -- and along with that, andmap, void, ... syntax-dispatch - $sc-dispatch syntax-object-datum - syntax-datum, etc no more syntax-error; but syntax-violation, yes. no more sc-macro fix module-bound? if the local variable was not bound, b * module/ice-9/boot-9.scm (module-bound?): module-bound? was returning true if (not (variable-bound? (module-local-variable m v))), but (variable-bound? (module-variable m v)). Fix to cut out on the first variable it finds. This bug has been there for a while now. BUGS: autocompilation when it shouldn't: elisp. change in the meaning of module transformers? was there really? BUG: disabled macroexpansion of emacs lisp code defmacros may now have docstrings eval-case and eval-when definitions in expression context unquoting values into defmacro expansions allow docstrings with internal definitions with syntax-case etc eval-when for functions used by macros scoping of keywords -- important? (ice-9 syncase) deprecated can now redefine keywords to normal values new defns: bound-identifier=? free-identifier=? generate-temporaries identifier? %pre-modules-transformer remove macroexpand, macroexpand-1; should add macroexpand back in tho FIXME bytevectors. FIXME unistring. more robust threading support. syncase knows about @/@@ macros and hygiene and modules eval-closure-module? what? procedure-module / scm_procedure_module guile-config info sitedir change -- 922d369 guile-config and pkg-config (system xref), procedure-callers, procedure-callees, can work as variables get redefined getrlimit and setrlimit wrappers FIXME: getrlimit crazy namespaces... add method-formals BUG? procedure-property 'arity on compiled procedures will be wrong BUG: SCM_SNAME - SCM_SUBR_NAME (ice-9 session): add-value-help-handler! remove-value-help-handler! add-name-help-handler! remove-name-help-handler! export module-commentary procedure-arguments procedure-memoizing-macro, procedure-syntax totally superdeprecated? FIXME: update copyrights ecmascript support? new repl... guile-tools compile, guile-tools disassemble (does that work?) BUG: stack walks to see number of frames, then fills those frames. sometimes those numbers differ, warning to console, a test case would be nice. FIXME: dance disassembly bug srfi-18 method has formals, body slots; (make-procedure procedure ?) FIXME: rewrite while removed (the-environment) new function: scm_module_public_interface BUG: help at guile prompt new procedure, make-promise -- http://wingolog.org/
ongoing NEWS
Hey, Not yet done with my part of the NEWS, though I hope to finish by noon or so tomorrow. But here is some of what I have, for review: ** The stack limit is now initialized from the environment. If getrlimit(2) is available and a stack limit is set, Guile will set its stack limit to 80% of the rlimit. Otherwise the limit is 16 words, a four-fold increase from the earlier default limit. ** Fix bad interaction between `false-if-exception' and stack-call. Exceptions thrown by `false-if-exception' were erronously causing the stack to be saved, causing later errors to show the incorrectly-saved backtrace. This has been fixed. ** Files loaded with primitive-load-path will now be compiled automatically. If a compiled .go file corresponding to a .scm file is not found or is not fresh, the .scm file will be compiled on the fly, and the resulting .go file stored away. An advisory note will be printed on the console. Note that this mechanism depends on preservation of the .scm and .go modification times; if the .scm or .go files are moved after installation, care should be taken to preserve their original timestamps. Autocompiled files will be stored in the user's ~/.guile-ccache directory, which will be created if needed. This is analogous to ccache's behavior for C files. To inhibit autocompilation, set the GUILE_AUTO_COMPILE environment variable to 0, or pass --no-autocompile on the Guile command line. ** New environment variables: GUILE_LOAD_COMPILED_PATH, GUILE_SYSTEM_LOAD_COMPILED_PATH GUILE_LOAD_COMPILED_PATH is for compiled files what GUILE_LOAD_PATH is for source files. It is a different path, however, because compiled files are architecture-specific. GUILE_SYSTEM_LOAD_COMPILED_PATH is like GUILE_SYSTEM_PATH. ** New global variables: %load-compiled-path, %load-compiled-extensions These are analogous to %load-path and %load-extensions. ** New installation directory: $(pkglibdir)/1.9/ccache If $(libdir) is /usr/lib, for example, Guile will install its .go files to /usr/lib/guile/1.9/ccache. These files are architecture-specific. ** scm_primitive_load_path has additional argument, exception_on_error ** scm_stat has additional argument, exception_on_error ** New entry into %guile-build-info: `ccachedir' Probably should be removed? ** New reader macros: #' #` #, #,@ These macros translate, respectively, to `syntax', `quasisyntax', `unsyntax', and `unsyntax-splicing'. See the R6RS for more information. These reader macros may be overridden by `read-hash-extend'. ** Incompatible change to #' Guile did have a #' hash-extension, by default, which just returned the subsequent datum: #'foo = foo. In the unlikely event that anyone actually used this, this behavior may be reinstated via the `read-hash-extend' mechanism. ** Scheme expresssions may be commented out with #; #; comments out an entire expression. See the R6RS for more information. ** make-stack with a tail-called procedural narrowing argument no longer works (with compiled procedures) It used to be the case that a captured stack could be narrowed to select calls only up to or from a certain procedure, even if that procedure already tail-called another procedure. This was because the debug information from the original procedure was kept on the stack. Now with the new compiler, the stack only contains active frames from the current continuation. A narrow to a procedure that is not in the stack will result in an empty stack. To fix this, narrow to a procedure that is active in the current continuation, or narrow to a specific number of stack frames. ** backtraces through compiled procedures only show procedures that are active in the current continuation Similarly to the previous issue, backtraces in compiled code may be different from backtraces in interpreted code. There are no semantic differences, however. Please mail bug-gu...@gnu.org if you see any deficiencies with Guile's backtraces. ** syntax-rules and syntax-case macros now propagate source information through to the expanded code This should result in better backtraces. ** The currying behavior of `define' has been removed. Before, `(define ((f a) b) (* a b))' would translate to (define f (lambda (a) (lambda (b) (* a b Now a syntax error is signalled, as this syntax is not supported by default. If there is sufficient demand, this syntax can be supported again by default. ** All modules have names now Before, you could have anonymous modules: modules without names. Now, because of hygiene and macros, all modules have names. If a module was created without a name, the first time `module-name' is called on it, a fresh name will be lazily generated for it. ** Many syntax errors have different texts now Syntax errors still throw to the `syntax-error' key, but the arguments are often different now. Perhaps in the future, Guile will switch to using standard srfi-35 conditions. ** Returning multiple values to compiled code will silently
Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509
Howdy, On Thu 18 Jun 2009 22:28, l...@gnu.org (Ludovic Courtès) writes: Andy Wingo wi...@pobox.com writes: + uniform-array-bytevector I would not export it from `(rnrs bytevector)' given that it has nothing to do with RnRS. No, but it does have to with bytevectors... Where would you put it? Dunno, maybe not anywhere public? Er, I wrote it so I could use it in my code... Not being able to get at the bits of uniform arrays from Scheme has been a sorely missing feature for a long time now... Also, I would make the new C functions private, given that they are not intended for general use AIUI. Dunno. I could imagine calling both of them from C. Would there be a problem with leaving them to be public? Yes, while we're not more confident wrt. shared arrays and similar. What do you mean? I think that shared arrays will be attempted to be linearized via scm_array_contents, which will throw an error for a non-contiguous array. That's as good as we can do, no? Andy -- http://wingolog.org/
Re: guile and emacs: unexec
Howdy Ken! On Sun 14 Jun 2009 07:21, Ken Raeburn raeb...@raeburn.org writes: On Jun 13, 2009, at 09:06, Andy Wingo wrote: Yes -- for now, that includes anything I haven't converted, including strings, symbols, vectors of objects, hash tables, etc. Many of what are currently smobs should eventually be converted to using Guile's versions, either directly or with some simple wrapping. They need to stay identifiable in Lisp as the correct object types, so I can't implement a Lisp string with, say, a Guile list containing a string plus text-property data. In the long term perhaps some of them could be implemented partly or fully in Scheme, but I don't want to diverge radically while I still need to track the main Emacs code base. (Please let me keep the illusion that replacing the fundamental object representation, allocator and garbage collector, and compensating for initialization problems throughout the code, isn't all that radical a change. :-) :-)) Sounds like a good path to me, though I know you've thought much more about it :) I figure, once I've got this set of changes working correctly (i.e., nearly indistinguishable, no random unexplained errors or differences in behavior), then I can tackle the next steps with more confidence that differences observed there are due to the new changes in progress, not semantic differences previously introduced with further- reaching effects than I expected. Sounds like a plan. 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 *would* like some help. I was just intending to fix a few more problems before making the plea. :-) I'm happy to help in making Guile a better implementation of Elisp than the one Emacs has. I'm specifically *not* trying to do some of the other things that have been discussed but aren't about running Emacs -- make buffers independent objects that can be used outside of Emacs, stuff like that. That can come later (or not), and I'd be glad to see it happen, but getting Emacs running at all is a big enough project for me on my own. Yes this sounds like a good plan. Symbols however should probably be represented as Guile symbols, not smobs. I think that you will find that with a more compilation-centric approach, we will be able to keep more simple datatypes, as we compile the procedures that operate on those data types to appropriate code. Eventually, yes, I think so. They should probably be one of the next things to change, though some like vectors and strings might be simpler. I'm also concerned about the performance impact of making such a switch; another reason for getting something working soon is so it's practical to look at performance questions. Daniel's work looks promising in this regard -- his idea was to make function values and symbol values resolve the same Guile symbol in different modules. The bindings would be Guile's fluids. Compilation would take care of the translation. Hopefully by the time you're ready, we'll be ready with that too. I actually had it pretty far along once or twice before (I seem to keep reviving this every few years, and spend a lot of time updating to newer code bases), but I think I've managed to push it a bit further than I had it earlier. With just me working on it, depending on the demands of my job, there tend to be large periods when no progress gets made, and it doesn't keep up with the upstream sources; the prospect of having to do a bunch of catch-up work just makes it that much less appealing to get back into it. It's been moving forward in spurts for over a decade now, very slowly. :-( You know though, this whole free software thing is actually OK in this respect. There are some technologies that just don't change very quickly. Keisuke had a VM working in 2001, but only now in the middle of 2009 have we merged it into Guile. We'll make it :) If this is an effort that you want to pay off in the future, though, I would strongly suggest updating to the 1.9/2.0 series of Guile. The expressive range of Guile's multilingual facilities is much higher there, and significantly different from 1.8. I was looking at updating, but ran into the -I ordering problem I reported. Since that's fixed, I'll try again sometime. The multilingual facilities aren't very important to me right now -- Ah, I was referring to programming languages ;) Human language is another kettle of fish. Doesn't emacs support a superset of unicode? But in general I am very sympathetic to the goal of making minimal, correct changes. OTOH, the emacs lisp support is not yet up to the level that it is at in 1.8, so perhaps now is not yet the time. And, I haven't started using any of that code yet, either... that's another big change to try at some
Re: release update
On Thu 18 Jun 2009 23:01, l...@gnu.org (Ludovic Courtès) writes: guile-config and pkg-config We should deprecate the former, BTW, if this hasn't already been done. Indeed, though we need to keep it working through 2.0, at least until new guile.m4 (yet to be ported...) becomes common. (system xref), procedure-callers, procedure-callees, can work as variables get redefined I think this should be added to the manual as well. Yes. BUG: SCM_SNAME - SCM_SUBR_NAME Ooh, I didn't worry much about it back then. Should we? I fixed this one. SNAME was very confusing to me :) FIXME: update copyrights Yes. (There's (add-hook 'write-file-hooks 'copyright-update), which I find convenient.) Looks like Neil took care of things. I've added this one to my .emacs. ecmascript support? Yes, although it's currently undocumented. Indeed, needs fixing. new function: scm_module_public_interface Speaking of which, I was thinking at some point about adding a `public-interface' slot to `module-type', to avoid hash table lookups. What do you think? Yes! %module-public-interface is a terrible hack. Andy -- http://wingolog.org/
Re: Guile HEAD on Cygwin-1.7
On Thu 18 Jun 2009 09:33, szgyg sz...@ludens.elte.hu writes:
** wrong path when compiling psyntax-pp.scm
First time only
Making all in module
make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
/home/szgyg/src/GIT/guile/=build/meta/guile --no-autocompile -s
../../module/ice-9/compile-psyntax.scm \
../../module/ice-9/psyntax.scm
../../module/ice-9/psyntax-pp.scm
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
ice-9/psyntax-pp.go ice-9/psyntax-pp.scm
ERROR: In procedure open-file:
ERROR: No such file or directory: ice-9/psyntax-pp.scm
make[2]: *** [ice-9/psyntax-pp.go] Error 1
Subsequent makes use the correct path:
Making all in module
make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build/module'
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
ice-9/psyntax-pp.go ../../module/ice-9/psyntax-pp.scm
wrote `ice-9/psyntax-pp.go'
I wonder why it's regenerating psyntax-pp.scm. It shouldn't, psyntax.scm
should be newer than psyntax-pp.scm. Can you make a fresh checkout and
try again? It could have been an accidental change from the copyright
updating.
** readline is required, not optional
GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o
ice-9/lineio.go ../../module/ice-9/lineio.scm
ERROR: readline is not provided in this Guile installation
Yes this is a problem. Guile shouldn't depend on readline at all, not
even in Scheme modules that are not loaded by default. We should move
this module to guile-readline, IMO, or work out some other solution.
make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
make check-TESTS
make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-autocompile argument to disable.
;;; compiling /home/szgyg/src/GIT/guile/test-suite/lib.scm
;;; compiled
/home/szgyg/.guile-ccache/1.9//home/szgyg/src/GIT/guile/test-suite/lib.scm.go
ERROR: Stack overflow
Running alist.test
[...]
What revision of the git repo was this?
On one occasion I got
make[1]: Entering directory `/home/szgyg/src/GIT/guile/=build'
make check-TESTS
make[2]: Entering directory `/home/szgyg/src/GIT/guile/=build'
Testing /home/szgyg/src/GIT/guile/=build/meta/guile ...
with GUILE_LOAD_PATH=/home/szgyg/src/GIT/guile/test-suite
/bin/sh: line 5: 3944 Segmentation fault (core dumped) ${dir}$tst
FAIL: check-guile
To me that looks like a segfault in your shell.
Thanks for the report,
Andy
--
http://wingolog.org/
Re: ongoing NEWS
On Thu 18 Jun 2009 23:49, Andreas Rottmann a.rottm...@gmx.at writes: Andy Wingo wi...@pobox.com writes: Autocompiled files will be stored in the user's ~/.guile-ccache directory, which will be created if needed. This is analogous to ccache's behavior for C files. As long as nothing is set in stone, perhaps you want to consider following the XDG basedir spec[0], which would suggest using something under ~/.cache/ per default; this would make e.g. having reasonable backup policies easier, as stuff under ~/.cache can be safely ignored for backups, and it avoids cluttering $HOME with yet-another dotfile/dotdir (although that is somewhat of a lost cause on GNU/Linux anyway). Sure, sounds like a good idea. Andy -- http://wingolog.org/
Re: GNU Guile 1.9.0 released (alpha)
Hi, On Sat 20 Jun 2009 00:05, l...@gnu.org (Ludovic Courtès) writes: We are pleased to announce GNU Guile release 1.9.0. Thank you for doing the release! Guile is an interpreter, compiler, and virtual machine for the Scheme programming language Perhaps in the future we can just say implementation of the Scheme programming language, and then make it obvious later that we indeed have a compiler. Strictly speaking, the VM could be said to be an interpreter :) Cheers, Andy -- http://wingolog.org/
Re: GNU Guile 1.9.0 released (alpha)
On Sat 20 Jun 2009 05:00, Linas Vepstas linasveps...@gmail.com writes:
Running r6rs-ports.test
/bin/sh: line 4: 7268 Segmentation fault ${dir}$tst
FAIL: check-guile
A few more things you could try, in addition to what Neil and Ludovic
said:
./check-guile r6rs-ports.test
Does this segfault for you? If so:
./check-guile -i meta/gdb-uninstalled-guile r6rs-ports.test
Then run, and post the backtrace please.
Thanks!
Andy
--
http://wingolog.org/
