Error in wip-rtl

Hello,

I tried to build the latest wip-rtl today, and hit an error that I
don't know how to debug. First, when the build gets to "GEN
guile-procedures.texi", I get a segmentation fault.

I tried to debug it by doing meta/gdb-uninstalled-guile. When I did
that, Guile made it to a command prompt, but when I try to evaluate
any sort of expression, even #t, I got "ERROR: unbound variable:
compile".

What might make that happen?

Thanks,
Noah

a few proposed patches

After reading the "dynamic ffi and C struct" thread this weekend, I started thinking, "I wonder if that's
really done so as to handle X and Y and Z, and if we're actually testing it well enough", and got the urge to do
another Mac build, which I hadn't done in a while.  After installing libgc 7.2 to get around flaky failures,
and fighting with the build system a bit (I have gmp installed via Macports, and that tree also has libgc
7.1…), and waiting hours for builds to finish and looking into why, I have a few patches to propose.  I've
uploaded them to the branch wip-raeburn-misc for review, since I'm not sure you'll want to address the
issues the same way.

* Eliminate use of GC_PTR.  Looks like it's a holdover from earlier versions of libgc.  Some versions don't
define it, so we do.  Apparently the 7.2 release defines it, too, which resulted in bug #11500.  It turns out,
too, that some of the casts weren't quite right (casting to GC_PTR when GC_PTR* was needed), and only
worked because GC_PTR is void* and thus can be converted to the correct type; I've tried to fix up those
cases.  The change discards some minor abstraction of the pointer interface to libgc, but I don't think we
really need an abstract name for void* anyways.

* Don't use addresses of code labels with LLVM, even if the compiler supports them.  At least with the version
of LLVM GCC on my Mac ("gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)"), the
performance seems to be quite poor; "guild compile" was showing about a 4x penalty in CPU time.  (For
psyntax-pp.go, it was 10 minutes of CPU time vs 46 minutes.)  Later/future versions may do better, so we can
update it with version-number checks, unless we want to build performance tests into the configure
script, which doesn't sound like a great idea to me.  Related to this, I made two more changes: Always define
statement labels in the VM code anyway, because vm-i-scheme.c uses some of them unconditionally (which
makes me wonder if any non-GCC configs are getting tested); and report the time taken for each "guild
compile" command during the build.

* Require libgc 7.2 or better.  Too often the fix to flaky problems seems to be "try updating to the latest
libgc and see if that fixes it", so let's just require it.  Or is 7.1 really *that* consistently reliable for
our use cases on some platforms?  I decided to go with a test in the C code because I was having problems with
include directory ordering for a while on my system, with both 7.1 and 7.2 installed.  A configure-time
check would work fine in addition, but the C check takes effect after the various include directories for

problems evaluating code depending on version

bug in syntax-case in master

Re: Making every goops object applicable

Krister Svanlund <krister.svanlund <at> gmail.com> writes:
> For example an instance of a class inheriting a class that inherits
> <applicable-struct> that defines 'procedure is not applicable.

Looking at the code, it is clear that in order for a GOOPS instance to
be applicable, it is not enough for <applicable-struct> to be a
superclass.  It is also necessary for the _metaclass_ of its class to
have the SCM_VTABLE_FLAG_APPLICABLE_VTABLE bit set.

One such metaclass is already built-in: <applicable-struct-class>, which
is the metaclass for <applicable-struct>, but if you'd like to define
your own metaclass for applicable objects, you can set the bit manually
on the metaclass as described by Ludovic.

However, keep in mind that the presence of that bit in the metaclass
indicates that the first slot of all instances _must_ be the procedure
slot.

     Mark

Fwd: Making every goops object applicable

terribly complex syntax objects in syntax parse

how to implement mutual recursive parsers in syntax-parse

Making every goops object applicable

[Proposal] Why not add a "shell" procedure?

hi folks!
Sometimes we need to run shell script and get the result as string type.
Say, in Ruby:
irb: `ls`
==> "ice-9\nlanguage\nMakefile.am\nMakefile.am~\nMakefile.in\noop\nrnrs\nrnrs.scm\nscripts\nsrfi\nstatprof.scm\nsxml\nsystem\ntexinfo\ntexinfo.scm\nweb\n"

* Note: "system" lib function is useless for this, because "system"
can't return the result as string, but just the retval.

This feature is very easy to implement in Guile, but I recommend to
add a global env-var %current-shell to point any shell-interpreter,
like csh/bash/sh/..., or modify it as user wish.
The "shell" implementation maybe like this:
-------------code----------------
(define %current-shell (getenv "SHELL"))
(use-modules (ice-9 popen) (rnrs io ports))
(define shell
   (lambda (cmd)
       (let ((str (string-append %current-shell " -c " cmd)))
          (get-string-all (open-pipe str OPEN_READ)))))
-------------end----------------

and use it like regular shell:
(shell "sed -i \"s:guile/Guile/g" somefile")

Moreover, we can implement "pwd" with this "shell" easily:
----------code----------
(use-module (ice-9 rdelim))
(define (pwd)
  (call-with-input-string (shell "pwd")
                                     (lambda (port) (read-line port))))
-----------end-----------

(pwd)
==> "/home/nalaginrut/Project/gnulib-20100109+stable"

Any comment?

Wish List

Hi all,

As I have been playing around with the sources of Guile, I looked at
the bug section on Savannah. I couldn't see much bugs and even less
bugs which are not pending already. Can anyone hint to some things
that are easy enough to pick up so I can start contributing something
sensible?

Regards,
Sjoerd