Re: (set! (@@ MOD NAME) EXP) considered harmful

[Neil Jerram]

Andy Wingo  writes:

> Hi Mark,
>
> On Wed 02 Sep 2009 18:17, Mark H Weaver  writes:
>
>> The ability to set! arbitrary module top-level variables from outside
>> the module, using the syntax (set! (@@ MOD NAME) EXP), destroys our
>> ability to several important optimizations.
>>
>> As long as such ability exists, we must pessimistically assume that
>> any module top-level variable might change at any time, which means,
>> for example, that we cannot inline top-level procedure applications
>> from within the module itself.  This could be a HUGE efficiency win in
>> the common case where such top-level procedures are never set! from
>> within the module.
>
> I disagree, heartily.
>
> Guile is a dynamic system, one where you can get into modules and
> redefine functions. All you have to do is (set-current-module!
> (resolve-module '(foo))) and (define bar #f) to do the equivalent of
> (set! (@@ (foo) bar) #f). It's just like that.
>
> And we should be proud of that, IMO! Your program might be a reified gem
> once you're finished with it, but it normally doesn't arrive there
> without much debugging.
>
> Furthermore, (set! (@ ..) ..) is a /consequence/ of hygiene. A hygienic
> macro that expands out to a set! of a variable in its context will
> compile to a (set! (@@ ...) ...). You can always get at the
> module-private vars, even with hygienic systems -- see the
> eval-in-module hacks from ikarus if you don't believe me there.
>
> Now, regarding optimizations. We can optimize whatever we like ;)
>
> More seriously, there are many possibilities there. One is to define
> your modules in lexical forms, as Chez does it -- so private functions
> will always be inlined. See the end of section 2.4 on
> http://www.scheme.com/csug7/use.html.
>
> Another is to always present module-private bindings as candidates for
> inlining.
>
> Another is to allow the user to mark certain procedures as inlinable.
> That will certainly be the case with `map', for example.
>
> Another is to have an optimization knob you can crank up, understanding
> that higher levels of optimization prevent some runtime modifiability.
>
> In short, @ and @@ are lovely and useful, and we should be happy with
> them. (set! (@@ ...) ...) is not an expected operation from user code,
> and may reasonably be discounted even at low optimization levels. I
> don't see the problem :)

I agree with all that.  Even as we do more static-feeling things like
compilation, we'd like to keep all the dynamic possibilities too.

Regarding optimization, maybe another possibility would be to have
detailed tracking of the underlying definitions that each piece of
optimized+compiled code depends on, and to recompile+reoptimize
whenever one of the underlying definitions changes.

Or is that just cloud cuckoo land?

(Ludovic recently suggested an optimization for constant additions, and
I assumed that would require this kind of rollback, if the definition of
`+' was later changed.)

  Neil

Re: Some leftover bugs for this release

[Ludovic Courtès]

Hi,

Mike Gran  writes:

> Also, the netbsd build will likely fail because there is new
> 'condition is always true' condition in array-handle.c:103
>
> 100 SCM
> 101 scm_array_handle_element_type (scm_t_array_handle *h)
> 102 {
> 103   
> if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
> 104 abort (); /* guile programming error */
> 105   return scm_i_array_element_types[h->element_type];
> 106 }

Hmm, an enum variable can possibly hold any integer value, so why would
this always be true?  Are you actually hitting this?

Thanks,
Ludo’.

Re: trace examples broken in master

[Neil Jerram]

Neil Jerram  writes:

> Julian Graham  writes:
>
>>> This should all be fixed in master now.  Can you have a go and let me
>>> know if you still see any problems?
>>
>> Just built from HEAD.  The errors I reported earlier are gone, but I'm
>> still not getting any trace output from the `rev' example in the
>> manual.
>
> I'm sorry, I didn't actually try running those examples myself, and I
> still haven't done that yet now - but just a thought: did you try with 
>
>   ,o interp #t
>
> so as to use the evaluator instead of the compiler + VM ?

It works for me with current Git and `,o interp #t'; full transcript
below.  Note that this is even when all of the debugging infrastructure
modules are auto-compiled; the only code that must _not_ be compiled,
for that example to work, is the `rev' procedure.

There is an unexpected "warning: stack count incorrect!", though.  I'll
look into that.

Neil


Guile Scheme interpreter 0.5 on Guile 1.9.2
Copyright (C) 2001-2008 Free Software Foundation, Inc.

Enter `,help' for help.
scheme@(guile-user)> (version)
"1.9.2"
scheme@(guile-user)> ,o interp #t
scheme@(guile-user)> (version)
"1.9.2"
scheme@(guile-user)> (define (rev ls)
 (if (null? ls)
 ls
 (append (rev (cdr ls))
 (list (car ls)
scheme@(guile-user)> (use-modules (ice-9 debugging traps) (ice-9 debugging 
trace))
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-autocompile argument to disable.
;;; compiling /usr/local/share/guile/1.9/ice-9/debugging/traps.scm
;;; compiling /usr/local/share/guile/1.9/ice-9/debugging/trc.scm
;;; compiled 
/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/usr/local/share/guile/1.9/ice-9/debugging/trc.scm.go
;;; compiled 
/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/usr/local/share/guile/1.9/ice-9/debugging/traps.scm.go
;;; compiling /usr/local/share/guile/1.9/ice-9/debugging/trace.scm
;;; compiling /usr/local/share/guile/1.9/ice-9/debugger/command-loop.scm
;;; compiling /usr/local/share/guile/1.9/ice-9/debugger/commands.scm
;;; compiling /usr/local/share/guile/1.9/ice-9/debugger/state.scm
;;; compiled 
/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/usr/local/share/guile/1.9/ice-9/debugger/state.scm.go
;;; compiling /usr/local/share/guile/1.9/ice-9/debugger/utils.scm
;;; compiled 
/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/usr/local/share/guile/1.9/ice-9/debugger/utils.scm.go
;;; compiling /usr/local/share/guile/1.9/ice-9/debugging/steps.scm
;;; compiled 
/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/usr/local/share/guile/1.9/ice-9/debugging/steps.scm.go
;;; compiled 
/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/usr/local/share/guile/1.9/ice-9/debugger/commands.scm.go
;;; compiled 
/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/usr/local/share/guile/1.9/ice-9/debugger/command-loop.scm.go
;;; compiled 
/home/neil/.cache/guile/ccache/1.9-0.D-LE-4/usr/local/share/guile/1.9/ice-9/debugging/trace.scm.go
scheme@(guile-user)> (define t1 (make 
#:procedure rev
#:behaviour (list trace-trap
  trace-at-exit)))
scheme@(guile-user)> rev
#
scheme@(guile-user)> (install-trap t1)
scheme@(guile-user)> (rev '(a b c))
|  2: [rev (a b c)]
warning: stack count incorrect!
|  2: =>(#...@if (null? #{ls\ 37}#) #{ls\ 37}# (append (rev (cdr #{ls\ 37}#)) 
(list (car #{ls\ 37}#
|  3: [rev (b c)]
|  4: [rev (c)]
|  5: [rev ()]
|  5: =>()
|  4: =>(c)
|  3: =>(c b)
(c b a)
scheme@(guile-user)> 

GNU Guile 1.9.3 released (alpha)

[Ludovic Courtès]

We are pleased to announce GNU Guile release 1.9.3.  This is the next
pre-release of what will eventually become the 2.0 release series.  It
provides many new noteworthy features, most notably the addition of a
compiler and virtual machine.  We encourage you to test them and provide
feedback to `guile-de...@gnu.org'.

The Guile web page is located at http://gnu.org/software/guile/, and
among other things, it contains a link to the Guile FAQ and pointers to
the mailing lists.

Guile is an implementation of the Scheme programming language, with
support for many SRFIs, packaged for use in a wide variety of
environments.  In addition to implementing the R5RS Scheme standard,
Guile includes a module system, full access to POSIX system calls,
networking support, multiple threads, dynamic linking, a foreign
function call interface, and powerful string processing.

Guile can run interactively, as a script interpreter, and as a Scheme
compiler to VM bytecode.  It is also packaged as a library so that
applications can easily incorporate a complete Scheme interpreter/VM.
An application can use Guile as an extension language, a clean and
powerful configuration language, or as multi-purpose "glue" to connect
primitives provided by the application.  It is easy to call Scheme code
From C code and vice versa.  Applications can add new functions, data
types, control structures, and even syntax to Guile, to create a
domain-specific language tailored to the task at hand.


Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/guile/guile-1.9.3.tar.gz   (4.2MB)

Here are the GPG detached signatures[*]:
  ftp://alpha.gnu.org/gnu/guile/guile-1.9.3.tar.gz.sig

Here are the MD5 and SHA1 checksums:

b1e319693dd4ed9c564790dce97c5355  guile-1.9.3.tar.gz
c8d1d25ed413b48493ec5b0cbf4de8593cab4a21  guile-1.9.3.tar.gz

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact.  First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

  gpg --verify guile-1.9.3.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

  gpg --keyserver keys.gnupg.net --recv-keys EA52ECF4

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.64
  Automake 1.11
  Libtool 2.2.6


This is a new release series with many new features and differences
compared to 1.8.  The complete list of changes compared to the 1.8.x
series is available in the `NEWS' file.

Changes since the 1.9.2 pre-release:

  ** Guile now uses libgc, the Boehm-Demers-Weiser garbage collector

  The semantics of `scm_gc_malloc ()' have been changed, in a
  backward-compatible way.  A new allocation routine,
  `scm_gc_malloc_pointerless ()', was added.

  Libgc is a conservative GC, which we hope will make interaction with C
  code easier and less error-prone.

  ** Files loaded with `load' will now be compiled automatically.

  As with files loaded via `primitive-load-path', `load' will also compile
  its target if autocompilation is enabled, and a fresh compiled file is
  not found.

  There are two points of difference to note, however. First, `load' does
  not search `GUILE_LOAD_COMPILED_PATH' for the file; it only looks in the
  autocompilation directory, normally a subdirectory of ~/.cache/guile.

  Secondly, autocompilation also applies to files loaded via the -l
  command-line argument -- so the user may experience a slight slowdown
  the first time they run a Guile script, as the script is autocompiled.

  ** Support for non-ASCII source code files

  The default reader now handles source code files for some of the
  non-ASCII character encodings, such as UTF-8. A non-ASCII source file
  should have an encoding declaration near the top of the file. Also,
  there is a new function, `file-encoding', that scans a port for a coding
  declaration. See the section of the manual entitled, "Character Encoding
  of Source Files".

  The pre-1.9.3 reader handled 8-bit clean but otherwise unspecified source
  code.  This use is now discouraged.

  ** Support for locale transcoding when reading from and writing to ports

  Ports now have an associated character encoding, and port read and write
  operations do conversion to and from locales automatically. Ports also
  have an associated strategy for how to deal with locale conversion
  failures.

  See the documentation in the manual for the four new support functions,
  `set-port-encoding!', `port-encoding', `set-port-conversion-strategy!',
  and `port-conversion-strategy'.

  ** String and SRFI-13 functions can operate on Unicode strings

  ** Unicode support for SRFI-14 character sets

  The default character sets are no longer locale dependent and contain
  characters from the whole Unicode range. There is a new predefined
  character set, `char-set:designated', which contains all assigned
  Unicode chara

Re: Some leftover bugs for this release

[Mike Gran]

> From: Ludovic Courtès 
> 
> Hi,
> 
> Mike Gran writes:
> 
> > Also, the netbsd build will likely fail because there is new
> > 'condition is always true' condition in array-handle.c:103
> >
> > 100 SCM
> > 101 scm_array_handle_element_type (scm_t_array_handle *h)
> > 102 {
> > 103 
>   if (h->element_type < 0 || h->element_type > SCM_ARRAY_ELEMENT_TYPE_LAST)
> > 104 abort (); /* guile programming error */
> > 105   return scm_i_array_element_types[h->element_type];
> > 106 }
> 
> Hmm, an enum variable can possibly hold any integer value, so why would
> this always be true?  Are you actually hitting this?

I poked around the gcc source code to see under what conditions the
"comparison is always true due to limited range of data type" warnings
occur.  These are the ones that NetBSD gcc seems to have and that
my gcc doesn't have.  For them to occur, it seems that the Wtype-limits
warning option must be active on that platform, but, not on mine.

I tried to figure out why this was so by looking at some of the BSD
CVS trees, but, I couldn't find out where this was enabled by default.
I'm not that familiar with the the organization of the BSD sources, though.

So when I enable -Wtype-limits on my build, it warns for any enum
value that is beyond those enumerated in the type definition.  The 
smallest value in this enum is zero, hence the warning.

[Insert standard rant about using -Werror here.]

Thanks,

Mike

Re: trace examples broken in master

[Neil Jerram]

Neil Jerram  writes:

> There is an unexpected "warning: stack count incorrect!", though.  I'll
> look into that.

It is fixed (i.e. doesn't occur) with the following changes.

diff --git a/libguile/stacks.c b/libguile/stacks.c
index 45566ca..849a9c7 100644
--- a/libguile/stacks.c
+++ b/libguile/stacks.c
@@ -143,6 +143,11 @@ stack_depth (scm_t_debug_frame *dframe, scm_t_ptrdiff 
offset, SCM vmframe,
{
  scm_t_debug_info *info = RELOC_INFO (dframe->info, offset);
  scm_t_debug_info *vect = RELOC_INFO (dframe->vect, offset);
+ /* If current frame is a macro during expansion, we should
+skip the previously recorded macro transformer
+application frame.  */
+ if (SCM_MACROEXPP (*dframe) && n > 0)
+   --n;
  n += (info - vect) / 2 + 1;
  /* Data in the apply part of an eval info frame comes from previous
 stack frame if the scm_t_debug_info vector is overflowed. */

Here n is the running stack depth.  Missing this decrement will cause
the "stack count incorrect" warning but is actually benign, as it only
means that scm_make_stack allocates a bit more space for the stack than
it really needs.

@@ -178,7 +183,10 @@ stack_depth (scm_t_debug_frame *dframe, scm_t_ptrdiff 
offset, SCM vmframe,
 ++n; /* increment for non-program apply frame */
 }
   else
-   ++n;
+   {
+ abort ();
+ ++n;
+   }
 }
   if (dframe && SCM_VOIDFRAMEP (*dframe))
 *id = RELOC_INFO(dframe->vect, offset)[0].id;

I'm pretty sure this last else branch is unhittable, hence the added
abort ().

@@ -282,6 +290,7 @@ read_frames (scm_t_debug_frame *dframe, scm_t_ptrdiff 
offset,
{
  *(iframe - 1) = *iframe;
  --iframe;
+ ++n;
}
  info =  RELOC_INFO (dframe->info, offset);
  vect =  RELOC_INFO (dframe->vect, offset);

Here n is the number of frames still unused in the allocated stack
object.  Missing this increment will cause the "stack count incorrect"
warning, and will make read_frames think it's filled up all the
available stack frames when there's actually still one frame unused;
it's not benign, because it can cause information to be missing from a
stack trace.  (But unfortunately it doesn't appear to be the fix for the
missing VM frames problem.)

 Neil

Re: BDW-GC branch updated

[Andreas Rottmann]

l...@gnu.org (Ludovic Courtès) writes:

> Hi Neil,
>
> Neil Jerram  writes:
>
>> I just installed libgc1c2 and libgc-dev (both 1:7.1-3) on my Debian
>> stable/testing machine.  Apparently no problem there.
>>
>> But there's still no pkgconfig for libgc, and so 
>>
>> PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
>>
>> fails:
>
> I checked the upstream tarballs and both 7.0 and 7.1 come with
> ‘bdw-gc.pc.in’.  Thus I suspect this is a packaging issue.  Can you
> report it on the Debian side?
>
I've taken the liberty to do so:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546833

Regards, Rotty
-- 
Andreas Rottmann --