[Chicken-hackers] [PATCH] Remove temporary hack for making gensym, add1 and sub1 globally available for macro expansion

[Peter Bex]

Hi all,

I just figured out why gensym, add1 and sub1 weren't available at macro
expansion time for some macros (the ffi ones): chicken-ffi-syntax.scm is
compiled with -explicit-use, and in batch-driver.scm we don't add the
default imports when -explicit-use is provided.

So the fix is simple: just add chicken.base to the imports list in
chicken-ffi-syntax.scm.  One less hack!

Cheers,
Peter
From 12821ebf0d0a080ee79e8c720c41a9460a9523f6 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sat, 14 Oct 2017 11:57:32 +0200
Subject: [PATCH] Kill temp hack for making gensym, add1 and sub1 globally
 available

Without the temp hack, we got segfaults due to these being unavailable
in chicken-ffi-syntax and it being declared with no-bound-checks and
no-procedure-checks.  The reason they weren't available is because
chicken-ffi-syntax is compiled with -explicit-use, so we must import
chicken.base manually at the start.
---
 chicken-ffi-syntax.scm | 3 ++-
 library.scm| 9 -
 2 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/chicken-ffi-syntax.scm b/chicken-ffi-syntax.scm
index d78c2728..69808bf2 100644
--- a/chicken-ffi-syntax.scm
+++ b/chicken-ffi-syntax.scm
@@ -39,7 +39,8 @@
   (no-bound-checks)
   (no-procedure-checks))
 
-(import chicken.format
+(import chicken.base
+	chicken.format
 	chicken.string)
 
 (include "common-declarations.scm")
diff --git a/library.scm b/library.scm
index 864d3032..5b55d5b4 100644
--- a/library.scm
+++ b/library.scm
@@ -5951,12 +5951,3 @@ EOF
 	 (loop (##sys#slot ids 1))
 
 ) ; chicken.platform
-
-
-;; TODO: Figure out how to ensure chicken.base is always available at
-;; syntax expansion time.  Related to #1131?  This is a temporary
-;; workaround (go ahead, laugh) so at least macros have gensym,
-;; add1 and so on available without needing (import (chicken base)):
-(define gensym chicken.base#gensym)
-(define add1 chicken.base#add1)
-(define sub1 chicken.base#sub1)
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Clean up obsolete definitions

[Peter Bex]

Hi all,

Here's a series of patches to get rid of some stuff marked OBSOLETE.
Since we have a 5.0.0pre2 development snapshot, we no longer need to
keep all these bootstrapping workarounds.  New ones will be introduced
anyway, so let's clean up some cruft.

I also noticed that C_mutate2() has been deprecated for a very long time,
but we still generate calls to it in the compiler, so we can't get rid
of it just yet.  The second patch at least changes the compiler to
generate C_mutate() calls instead (which is identical to C_mutate2()).
This means in the next cleanup round, we can finally get rid of it.

Finally, the -n switch for csc (an old alias for -emit-inline-file) has
been deprecated for a very very long time, so let's finally drop it too.

Cheers,
Peter
From 6e182136c48fef03ed92593173bf43908ebd65c4 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Thu, 12 Oct 2017 16:09:33 +0200
Subject: [PATCH 1/3] Delete things marked OBSOLETE for the pre2 snapshot

We'll introduce a couple more with the (chicken base) change and
perhaps others, too.  So let's remove the ones which are no longer
necessary.

Note: the scheduler used the flonum 0.0 as a default timeout value as
an argument to a foreign-lambda that accepts an unsigned-int, this had
to be changed to fixnum 0 to avoid a crash due to the removal of the
OBSOLETE compatibility for automatically coercing flonums to these
argument types.  This crash only happens because the scheduler has an
`unsafe' declaration.
---
 NEWS |  1 +
 c-platform.scm   |  4 +-
 chicken-syntax.scm   |  3 --
 chicken.condition.import.scm |  5 +--
 chicken.h| 55 -
 chicken.import.scm   | 10 -
 extras.scm   |  4 --
 library.scm  |  9 -
 runtime.c| 95 +---
 scheduler.scm|  2 +-
 support.scm  |  9 +
 synrules.scm |  5 ---
 tweaks.scm   | 12 +-
 13 files changed, 18 insertions(+), 196 deletions(-)

diff --git a/NEWS b/NEWS
index 3727dba0..9fa2daaf 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,7 @@
   - Continuations which discard additional values beyond the first now
 also accept multiple values via direct invocation after being
 captured through `call/cc`, not just via `values` (#1390)
+  - Removed the deprecated C_locative_ref C function.
 
 - Compiler
   - Fixed an off by one allocation problem in generated C code for (list ...).
diff --git a/c-platform.scm b/c-platform.scm
index b01b6edb..4ce20a17 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -66,8 +66,8 @@
  ##sys#list ##sys#cons ##sys#append ##sys#vector ##sys#foreign-char-argument ##sys#foreign-fixnum-argument
  ##sys#foreign-flonum-argument ##sys#error ##sys#peek-c-string ##sys#peek-nonnull-c-string 
  ##sys#peek-and-free-c-string ##sys#peek-and-free-nonnull-c-string
- ##sys#foreign-block-argument ##sys#foreign-string-argument ##sys#foreign-pointer-argument ##sys#foreign-integer-argument
- ##sys#call-with-current-continuation) ) )
+ ##sys#foreign-block-argument ##sys#foreign-string-argument
+ ##sys#foreign-pointer-argument ##sys#call-with-current-continuation) ) )
 
 (define default-profiling-declarations
   '((##core#declare
diff --git a/chicken-syntax.scm b/chicken-syntax.scm
index c951d467..cf675f6d 100644
--- a/chicken-syntax.scm
+++ b/chicken-syntax.scm
@@ -1129,9 +1129,6 @@
 	   (x (r 'x))
 	   (y (r 'y))
 	   (slotnames (map car slots)))
-  ;; TODO OBSOLETE remove after snapshot release
-  (unless (feature? #:namespaced-record-type-tags)
-	(set! tag plain-name))
   `(##core#begin
 	;; TODO: Maybe wrap this in an opaque object?
 	(,%define ,type-name (##core#quote ,tag))
diff --git a/chicken.condition.import.scm b/chicken.condition.import.scm
index 6ab6ce8b..943996c1 100644
--- a/chicken.condition.import.scm
+++ b/chicken.condition.import.scm
@@ -39,7 +39,4 @@
(condition-predicate . chicken.condition#condition-predicate)
(condition-property-accessor . chicken.condition#condition-property-accessor)
(get-condition-property . chicken.condition#get-condition-property))
- ;; OBSOLETE: This can be removed after bootstrapping
- (if (##sys#symbol-has-toplevel-binding? '##sys#chicken.condition-macro-environment)
- ##sys#chicken.condition-macro-environment
- ##sys#chicken-macro-environment))
+ ##sys#chicken.condition-macro-environment)
diff --git a/chicken.h b/chicken.h
index 3aeb0028..b08f0de2 100644
--- a/chicken.h
+++ b/chicken.h
@@ -1113,9 +1113,6 @@ typedef void (C_ccall *C_proc)(C_word, C_word *) C_noret;
  */
 #if C_STACK_GROWS_DOWNWARD
 # define C_demand(n)  (C_stress && ((C_word)(C_stack_pointer - C_stack_limit) > ((n)+C_scratch_usage)))
-/* OBSOLETE: */
-# define C_stack_probe(p) (C_stress && (((C_wor

Re: [Chicken-hackers] [PATCH] Add initial version of (chicken base)

[Peter Bex]

On Sat, Sep 16, 2017 at 04:23:33PM +0200, Peter Bex wrote:
> So for now I've updated the patch (attached) to simply keep warning and
> notice where they are.  (chicken base) is not exporting it.  The old
> patch didn't apply anymore due to a merge conflict, which I've also fixed
> in this new one.

Are there any further problems with this patch?  I would like to move on
with the module refactoring, we're almost there!  AFAIK only scheme needs
to be done and then there are some remaining loose ends, but the
(chicken base) is the bulk of the work.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add a more thorough workaround for stat() issues on MinGW

[Peter Bex]

On Wed, Oct 11, 2017 at 01:41:48PM +1300, Evan Hanson wrote:
> I think the cleanest way to address these problems is to simply provide
> a wrapper for stat(2) on MinGW that makes it behave more correctly, as
> in the attached patch. Please see the commit message for details and let
> me know if you have any questions; I tried to be very explicit about the
> approach in the description and comments.

Excellent analysis and patch.  I've done some quick tests (which took
forever because I overlooked the fact that I was testing another PREFIX
than I was installing to) and it seems to work more reliably now!

Pushed!

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix #1367 by using some black magic

[Peter Bex]

Hi all,

After some pondering I think I know what's going on in #1367.
When we enter (##sys#schedule), we simply fetch the suspended
thread's continuation (stored in a thunk) from the thread
structure and invoke it.

This invocation implicitly is done with the continuation that
would return in the old thread from the call to (##sys#schedule).
Of course, ##sys#schedule is not even _supposed_ to return, so
that makes no sense.  This continuation holds a reference to the
code that was active at the point where we called thread-start!,
which in the example program is running in the old thread (which
it also keeps a reference to).

Now, this example is a pathological case because all the threads
do is acquire a mutex and then fire off the next thread, after
which the thread is supposed to die.  The next thread does the
same and so on, resulting in a long chain of continuations that
goes all the way back to the primordial thread.

At least, I *think* that's what's going on.  Running the test
program with -:d shows a steady buildup of memory usage.
The fix is to call the thunk with an empty continuation.  We know
that it won't ever be invoked, so it doesn't matter what the
continuation does.  And of course we have the perfect fit for
that: ##sys#call-with-cthulhu!

I'm not sure if I would've come up with this if it wasn't for #1408...

Anyway, I hope this explanation makes sense.  It's a bit difficult to
explain this because it involves both the garbage collector _and_ the
scheduler.  Also, I'm not 100% sure about my analysis of the situation,
but the patch does seem to change the memory profile of the example
program to be completely steady.

IMO, this patch should go into both master and chicken-5.

Cheers,
Peter
From 85a3141d2de3e2fd8e0f1dd49d3b665f2119fde2 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Tue, 10 Oct 2017 17:29:44 +0200
Subject: [PATCH] Threads are tricky business.  We must sacrifice a goat in the
 name of the dark gods to make them work properly!

When scheduling a new thread, we need to invoke it with a continuation
that goes nowhere.  We know the thread call won't return, so the
continuation must be swapped out because the scheduler continuation
still has a reference to the old thread before invocation.  This
continuation itself still may holds a reference to the previous
thread, and so on, resulting in infinite memory buildup.

This fixes #1367
---
 NEWS  | 3 +++
 scheduler.scm | 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 2321084c..397fd532 100644
--- a/NEWS
+++ b/NEWS
@@ -23,6 +23,9 @@
 - Runtime system:
   - The profiler no longer uses malloc from a signal handler which may
 cause deadlocks (#1414, thanks to Lemonboy).
+  - The scheduler no longer indirectly hangs on to the old thread
+when switching to a new one, which caused excessive memory
+consumption (#1367, thanks to "megane").
 
 - Syntax expander
   - Renaming an identifier twice no longer results in an undo of the
diff --git a/scheduler.scm b/scheduler.scm
index 0532048d..0b292f7f 100644
--- a/scheduler.scm
+++ b/scheduler.scm
@@ -158,7 +158,9 @@ EOF
 (##sys#restore-thread-state-buffer thread)
 ;;XXX WRONG! this sets the t/i-period ("quantum") for the _next_ thread
 (##core#inline "C_set_initial_timer_interrupt_period" (##sys#slot thread 9))
-((##sys#slot thread 1)) )
+;; Call upon ye ancient gods to forget about the current
+;; continuation; it still refers to the old thread (#1367).
+(##sys#call-with-cthulhu (##sys#slot thread 1)) )
   (let* ([ct ##sys#current-thread]
 	 [eintr #f]
 	 [cts (##sys#slot ct 3)] )
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Improve SRFI-69 documentation as per #1290

[Peter Bex]

Hi all,

Here's a simple documentation fix for master.  If accepted, I'll add it
to the wiki for CHICKEN 4 and the srfi-69 egg for CHICKEN 5 as well.

Cheers,
Peter
From 5321998de0371d87b9761f0f79b29f9a25a7976f Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Tue, 10 Oct 2017 12:13:01 +0200
Subject: [PATCH] Mention which keys win in case of conflicts with
 hash-table-merge[!] and alist->hash-table

Fixes #1290
---
 manual/Unit srfi-69 | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/manual/Unit srfi-69 b/manual/Unit srfi-69
index 8eb222e8..14412b63 100644
--- a/manual/Unit srfi-69	
+++ b/manual/Unit srfi-69	
@@ -37,6 +37,9 @@ to each other, even if they contain exactly the same key/value pairs.
 Returns a new {{HASH-TABLE}}. The {{HASH-TABLE}} is populated from the
 {{A-LIST}}. The keyword arguments are per {{make-hash-table}}.
 
+If a key occurs multiple times in {{A-LIST}}, the first occurrance
+will be used in the hash table.
+
 
  hash-table?
 
@@ -237,7 +240,8 @@ Deletes all entries in {{HASH-TABLE}}.
 (hash-table-merge HASH-TABLE-1 HASH-TABLE-2)
 
 Returns a new {{HASH-TABLE}} with the union of {{HASH-TABLE-1}} and
-{{HASH-TABLE-2}}.
+{{HASH-TABLE-2}}.  Keys that exist in both tables will be taken from
+{{HASH-TABLE-1}}.
 
 
  hash-table-merge!
@@ -245,7 +249,8 @@ Returns a new {{HASH-TABLE}} with the union of {{HASH-TABLE-1}} and
 (hash-table-merge! HASH-TABLE-1 HASH-TABLE-2)
 
 Returns {{HASH-TABLE-1}} as the union of {{HASH-TABLE-1}} and
-{{HASH-TABLE-2}}.
+{{HASH-TABLE-2}}.  Keys that exist in both tables will be taken from
+{{HASH-TABLE-1}}.
 
 
  hash-table-map
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix README instructions for building from git

[Peter Bex]

Hi all,

As pointed out by Caolan in #1360, the instructions for building from
git are not exactly right.  I think it's better to avoid messing
with LD_LIBRARY_PATH entirely, as a proper (temporary) install is
much simpler.

If someone absolutely wants to avoid installing first, they should
be knowledgeable enough to make it work with LD_LIBRARY_PATH, but
I don't think the official instructions need to deal with this edge
case.

This patch should apply to both master and chicken-5.

Cheers,
Peter
From c455d8c9a87d07de8e9ad3af5e888ec88b877e1f Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Tue, 10 Oct 2017 11:39:59 +0200
Subject: [PATCH] Improve instructions for building from git

The instructions mentioned using LD_LIBRARY_PATH to override the
library search location but in an incorrect way.  Besides, just
setting LD_LIBRARY_PATH might not be enough and it's more complicated
than simply instructing the user to install to a (temporary) location.

Furthermore, the instructions mentioned getting the latest release
tarball, but it's generally more reliable to use the closest
development snapshot.

Finally, just building might not work, you might need to build a
boot-chicken first.
---
 README | 39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/README b/README
index 6ee15437..7f599029 100644
--- a/README
+++ b/README
@@ -95,8 +95,7 @@ _/_/_/_/_/_/  _/_/_/_/_/
 
 If you build CHICKEN directly from the development sources out
 of the git repository, you will need a "chicken" executable to
-generate the compiled C files from the Scheme library
-sources.
+generate the compiled C files from the Scheme library sources.
 
 If you are building in a checkout where you have built other
 versions of chicken, you need to make sure that all traces of
@@ -105,25 +104,23 @@ _/_/_/_/_/_/  _/_/_/_/_/
 
 	make PLATFORM= spotless
 
-	If you have a recent version of CHICKEN installed, then pass
-"CHICKEN=" to the "make" invocation to
-override this setting. "CHICKEN" defaults to "chicken".
+You will need to have a "chicken" binary installed, ideally
+	from the development snapshot tarball that is closest to the
+	git version you are trying to build (significantly older or
+	newer ones are unlikely to work), and then use that chicken
+	to build from your git sources.  Installing this CHICKEN is
+	recommended, if necessary you can install it to a temporary
+	location in your homedir for example.
 
-If you do not have a "chicken" binary installed, you will have
-	to build from the closest release tarball to the git version
-	you are trying to build (significantly older or newer ones are
-	unlikely to work), and then use that chicken to build from
-	your git sources. You don't need to install the release
-	tarball chicken; simply unpack and build it in its own
-	directory with "make PLATFORM=", then use it to
-	build your git chicken like so:
+	Then, to build you can do:
 
-	LD_LIBRARY_PATH= make PLATFORM= \
-  CHICKEN=/chicken
+	make PLATFORM= CHICKEN=/bin/chicken
 
-The LD_LIBRARY_PATH is needed on Linux to allow chicken to
-find libchicken; it may or may not be needed on your platform,
-but probably won't do any harm.
+	In some cases, the sources may have diverged enough to
+	become unbuildable even with the snapshot.  Then you'll need
+	to first build a bootstrapping compiler with the installed
+	CHICKEN and then use that to build the version from git.
+	See the "Bootstrapping" section below.
 
 2.3. Finishing the installation
 
@@ -645,9 +642,9 @@ _/_/_/_/_/_/  _/_/_/_/_/
  6. Bootstrapping
 
 To build a bootstrapping compiler yourself, get the most
-recent release tarball from http://code.call-cc.org, unpack
-it, build and install it.  Then change to the directory
-containing the git code and run:
+recent development snapshot tarball from
+	http://code.call-cc.org, unpack it, build and install it.
+	Then change to the directory containing the git code and run:
 
   make PLATFORM= CHICKEN= \
 boot-chicken
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Two minor file-related patches

[Peter Bex]

On Mon, Sep 25, 2017 at 08:53:40PM +0200, Peter Bex wrote:
> On Fri, Sep 15, 2017 at 10:07:18PM +1200, Evan Hanson wrote:
> > Hi hackers,
> > 
> > Here are two small patches. The first just removes a helper procedure
> > that I think is no longer necessary, `##sys#platform-fixup-pathname`,
> > which only affects MinGW and doesn't seem to be needed anymore (see the
> > commit message for details about that).
> 
> It seems that this patch is necessary after all.

I meant procedure, not patch.  I'm too tired.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Two minor file-related patches

[Peter Bex]

On Fri, Sep 15, 2017 at 10:07:18PM +1200, Evan Hanson wrote:
> Hi hackers,
> 
> Here are two small patches. The first just removes a helper procedure
> that I think is no longer necessary, `##sys#platform-fixup-pathname`,
> which only affects MinGW and doesn't seem to be needed anymore (see the
> commit message for details about that).

It seems that this patch is necessary after all.  I tested with the
"regular" MingW with MSYS (for some reason csi just hangs on MSYS2...)
and I see the following:

#;1> (use (chicken file))
#;2> (directory-exists? "c:/cygwin")
"c:/cygwin"
#;3> (directory-exists? "c:/cygwin/")
#f

In the old implementation it returned the path in both calls.  So, as
you can see it seems this functionality is required after all.

I do agree that fixup-pathname should probably remove all trailing
path separators rather than just the last one; that's just broken.

> The second patch fixes a TOCTTOU
> problem with `delete-file*`, brings its return value in line with the
> documentation, and also speeds it up by about 2x judging by my testing.

This also changes the semantics drastically.  When using delete-file*,
you generally do so because you're not interested if it doesn't exist;
you're just interested in the end effect, that the file no longer exists
after having called the procedure.

However, if the file *can't* be deleted for whatever reason, the original
implementation would raise an exception, whereas the version after this
patch will merrily return #f and continue the program.

In other words, this will hide *all* errors, which can result in the program
to fail specatularly because its preconditions don't hold.  I believe
we need to check errno in case the return value is nonzero, and only
ignore ENOENT, or am I missing some other return codes?  I don't know
what to do with EAGAIN/EWOULDBLOCK: POSIX doesn't mention these codes
in remove(), but maybe some implementations could return them anyway?

This page seems to imply that unlink() (and by extension remove()) may
return EAGAIN:
https://www.kernel.org/doc/htmldocs/filesystems/API-vfs-unlink.html

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Patch to make chicken build on DragonFlyBSD again

[Peter Bex]

On Thu, Sep 21, 2017 at 09:31:45PM +1200, Evan Hanson wrote:
> Hi Markus,
> 
> On 2017-09-20 17:17, Markus Pfeiffer wrote:
> > the following patch makes chicken build for DragonFly again (and hence
> > after a release would make it possible to include it in dports, etc).
> 
> Thanks a lot, we appreciate it.
> 
> Here are signoffs for both master and chicken-5.

Thanks all, I've pushed this.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix #1414 by not mallocing in a signal handler

[Peter Bex]

On Sun, Sep 17, 2017 at 05:43:07PM +1200, Evan Hanson wrote:
> Hi Peter,
> 
> I've applied this to both branches. Thanks for the explanation, it was
> helpful in trying to figure out what will happen when the trace buffer
> is filled more quickly than signals arrive. I also had to convince
> myself that the behaviour is correct when signals outpace new trace
> entries, and it seems to me that in this case the active trace entry
> will remain the same across multiple invocations of
> take_profile_sample() and no allocation is actually necessary due to the
> early exit.

Yeah, this is a bit subtle, and maybe overly clever.  But it helps a lot
to keep this code relatively short and simple.

> Attached is a tiny, unrelated change for something I noticed while
> reviewing: I think we don't need to check for NULL trace buffer keys in
> take_profile_sample() since the top pointer of that buffer is only ever
> bumped *after* the whole entry has been populated, so that procedure
> will never see a NULL value in the "raw" field.

Well spotted, I've applied it.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add initial version of (chicken base)

[Peter Bex]

On Sun, Sep 17, 2017 at 11:44:09AM +0200, felix.winkelm...@bevuta.com wrote:
> > > It should be possible to link with units, but I guess that can be done 
> > > via "declare".
> > > If that is still possible then "require-library" may indeed go.
> >
> > Yeah, I think that's still possible.
> 
> What it does is allowing runtime-linking to a compiled unit that is compiled
> into a library (not a loadable .so). The expansion (using '##core#require')
> is a bit too involved for user code. We should investigate and compare
> the remaining loading/linking forms and make every possible case is handled:
> loadable .so (module), static library, dynamically loadable library (also a 
> .so,
> confusingly), source code, etc.

Let's discuss this in person at the meetup.  In any case, this doesn't
need to hold up further development on the chicken-5 branch.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix #1414 by not mallocing in a signal handler

[Peter Bex]

Hi all,

Lemonboy found another stupid mistake I made; the statistical profile
calls malloc() in the middle of a signal handler.  Apparently, malloc
is not reentrant and takes a global lock, which will result in deadlock
if the signal arrives while malloc() is doing its thing.

Attached are patches for master and chicken-5, I think this is simple
and serious enough to warrant a fix in master.

The fix is relatively straightforward: when profiling is active, we
pre-allocate a bucket in C_trace(), which can be consumed by the
signal handler.  It takes a little bit of care, because we must
allocate before actually putting some contents into the trace buffer,
since the signal might occur in between.

A signal may occur before the next trace() call, but that's okay
because in that situation, the topmost trace buffer entry _must_ have
a corresponding bucket from taking the previous profile sample.
Essentially, trace() prepares the state for a potential profile sample
to be taken, but if that doesn't happen, the previous pre-allocation
will just sit there.  The next trace() will see it and avoid
pre-allocating, so the overhead this introduces during trace is neglible.

Cheers,
Peter
From 67e42a95fc4e59e4bdc094200f21db711919c692 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sat, 16 Sep 2017 21:03:33 +0200
Subject: [PATCH] Pre-allocate profile bucket to avoid malloc() in signal
 handler

This can cause deadlock because malloc() is not reentrant, see #1414.
---
 NEWS  |  4 
 runtime.c | 28 
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index 46420a00..9b756319 100644
--- a/NEWS
+++ b/NEWS
@@ -124,6 +124,10 @@
   - Large literals no longer crash with "invalid encoded numeric literal"
 on mingw-64 (#1344, thanks to Lemonboy).
 
+- Runtime system:
+  - The profiler no longer uses malloc from a signal handler which may
+ cause deadlocks (#1414, thanks to Lemonboy).
+
 - Syntax expander
   - Renaming an identifier twice no longer results in an undo of the
 rename (fixes #1362, thanks to "megane").
diff --git a/runtime.c b/runtime.c
index ae032f3a..dd78336b 100644
--- a/runtime.c
+++ b/runtime.c
@@ -473,7 +473,9 @@ static C_TLS FINALIZER_NODE
 static C_TLS void *current_module_handle;
 static C_TLS int flonum_print_precision = FLONUM_PRINT_PRECISION;
 static C_TLS HDUMP_BUCKET **hdump_table;
-static C_TLS PROFILE_BUCKET **profile_table = NULL;
+static C_TLS PROFILE_BUCKET
+  *next_profile_bucket = NULL,
+  **profile_table = NULL;
 static C_TLS int 
   pending_interrupts[ MAX_PENDING_INTERRUPTS ],
   pending_interrupts_count,
@@ -4391,10 +4393,10 @@ static void take_profile_sample()
   }
 
   /* Not found, allocate a new item and use it as bucket's new head */
-  b = (PROFILE_BUCKET *)C_malloc(sizeof(PROFILE_BUCKET));
+  b = next_profile_bucket;
+  next_profile_bucket = NULL;
 
-  if(b == NULL)
-panic(C_text("out of memory - cannot allocate profile table-bucket"));
+  assert(b != NULL);
 
   b->next = *bp;
   b->key = key;
@@ -4415,6 +4417,16 @@ C_regparm void C_fcall C_trace(C_char *name)
 C_fputc('\n', C_stderr);
   }
 
+  /* When profiling, pre-allocate profile bucket if necessary.  This
+   * is used in the signal handler, because it may not malloc.
+   */
+  if(profiling && next_profile_bucket == NULL) {
+next_profile_bucket = (PROFILE_BUCKET *)C_malloc(sizeof(PROFILE_BUCKET));
+if (next_profile_bucket == NULL) {
+  panic(C_text("out of memory - cannot allocate profile table-bucket"));
+}
+  }
+
   if(trace_buffer_top >= trace_buffer_limit) {
 trace_buffer_top = trace_buffer;
 trace_buffer_full = 1;
@@ -4430,6 +4442,14 @@ C_regparm void C_fcall C_trace(C_char *name)
 
 C_regparm C_word C_fcall C_emit_trace_info2(char *raw, C_word x, C_word y, C_word t)
 {
+  /* See above */
+  if(profiling && next_profile_bucket == NULL) {
+next_profile_bucket = (PROFILE_BUCKET *)C_malloc(sizeof(PROFILE_BUCKET));
+if (next_profile_bucket == NULL) {
+  panic(C_text("out of memory - cannot allocate profile table-bucket"));
+}
+  }
+
   if(trace_buffer_top >= trace_buffer_limit) {
 trace_buffer_top = trace_buffer;
 trace_buffer_full = 1;
-- 
2.11.0

From c03da8f9a4d74192d18ffa205b242d1440b0e730 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sat, 16 Sep 2017 21:03:33 +0200
Subject: [PATCH] Pre-allocate profile bucket to avoid malloc() in signal
 handler

This can cause deadlock because malloc() is not reentrant, see #1414.
---
 NEWS  |  4 
 runtime.c | 28 
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/NEWS b/NEWS
index f745b94b..9051f8d1 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,10 @@
   - Large literals no longer crash with "invalid encoded numeric literal"
 on mingw-64 (#1344, thanks to Lemonboy).
 
+- Runtime system:
+  - Th

Re: [Chicken-hackers] [PATCH] Add initial version of (chicken base)

[Peter Bex]

On Sat, Sep 16, 2017 at 08:00:28PM +0200, felix.winkelm...@bevuta.com wrote:
> >
> > Agreed, let's drop those from (chicken base).  This includes the
> > "enable-warnings" procedure, because it makes no sense to have a way
> > of programmatically enabling/disabling warnings that only the core
> > tools should be emitting anyway.
> 
> I would leave "warning" and "enable-warnings", as we expose "error"
> too.

I tend to think of "error" as different.  For one, it's a SRFI, and for
another, there's lots of user code using it.

> It has uses - "notice" is different, and can be replaced by a (trivially)
> implemented user-made logging facility. This may sound a bit like 
> bikeshedding,
> but we will break a bit of code otherwise.

Note that the second patch I supplied doesn't remove "notice" or "warning",
it merely keeps them at the toplevel in library.scm, so we can later decide
what to do with it.

> > require-library is so weird and does so much (at least, it looks like it
> > does from the docs), I don't know what to do with it.  Maybe we can indeed
> > just remove it?
> 
> It should be possible to link with units, but I guess that can be done via 
> "declare".
> If that is still possible then "require-library" may indeed go.

Yeah, I think that's still possible.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add initial version of (chicken base)

[Peter Bex]

On Sat, Sep 16, 2017 at 04:40:49PM +1200, Evan Hanson wrote:
> On 2017-09-12 10:51, felix.winkelm...@bevuta.com wrote:
> > > - notice (we already had "warning" and "error", however, notice seems
> > >   to be used mostly in the compiler)
> > 
> > Does this need to be exposed? I'm not sure how useful this is for user
> > code.
> 
> I think we should drop "notice" and "warning" from the public API. As
> you say they're not very useful for end users, and I'd prefer it if
> there were a well-supported egg for that sort of thing rather than
> something we have to worry about maintaining in core (kind of like how
> "test" is the de-facto standard unit testing egg).

Agreed, let's drop those from (chicken base).  This includes the
"enable-warnings" procedure, because it makes no sense to have a way
of programmatically enabling/disabling warnings that only the core
tools should be emitting anyway.

Maybe we can move this into support.scm or something similar?  I looked
into it, but saw that chicken-install and friends are using "warning"
too, and they don't use support.scm, so I think it's not too simple.

So for now I've updated the patch (attached) to simply keep warning and
notice where they are.  (chicken base) is not exporting it.  The old
patch didn't apply anymore due to a merge conflict, which I've also fixed
in this new one.

> > > - use
> > > - require-library
> > > - require-extension
> > > - quotient&{remainder,modulo}
> > > 
> > > I'm not 100% sure about require-library, require-extension and use,
> > > especially given that import is in (chicken module).
> > 
> > Hm... I thought we try to get rid of all these alternative loading forms?
> 
> Yeah, let's drop these once the "base" module has landed.
> 
> The `require-extension` macro can go in a srfi-55 egg.

I think it makes more sense to keep it in core, for compatibility with
the srfi.  Maybe we can clarify in the documentation that it's just an
alias for (import)?  I think (use) is a bit more questionable, now that
it's also just an alias for (import).

require-library is so weird and does so much (at least, it looks like it
does from the docs), I don't know what to do with it.  Maybe we can indeed
just remove it?

> I think just "scheme" and "base" would be fine, but including the
> modules you listed would also make a lot of sense. Whatever we do, I
> think it's important that compiled and interpreted code behave the same.

100% agreed!  The difference between available identifiers in compiled
and interpreted code is what really gets to people.

> I also don't think we should just include everything from library.scm
> since it includes some libraries like "gc" and "plist" that aren't
> commonly used, and we may want the freedom to shuffle things around in
> the future.

Ah, I hadn't considered that.  I suppose we should just use only
chicken.base and scheme, then, and document it clearly.

Cheers,
Peter
From 70a52ba3cbfb638cd393b26d16669a874871e7d6 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Mon, 11 Sep 2017 18:35:10 +0200
Subject: [PATCH] Add priliminary version of (chicken base) module

This is a primitive module because it has several syntax exports.

We first define the module containing mostly stub definitions which
are set! further down in the file.  This ensures we won't have to
import the module into itself, which will result in strange/unexpected
errors.

There's one hack: at the end of library.scm, we define a few toplevel
aliases for procedures that are supposed to be in the default macro
namespace.  Without this, we'd need (import-for-syntax chicken.base)
in practically every low-level macro use.  We will need to find out
why this is needed, and take better control over what's available in
the initial macro environment.

This also removes the enable-warnings procedure, as warnings (and
notices) will be removed from the public API.
---
 README|   1 +
 c-platform.scm|  61 ---
 chicken-syntax.scm| 289 ---
 chicken.base.import.scm   |  72 
 chicken.import.scm|  89 +-
 defaults.make |   3 +-
 distribution/manifest |   2 +
 expand.scm|  10 +-
 library.scm   | 422 +++---
 modules.scm   |  25 +--
 tests/scrutiny-2.expected |   8 +-
 tests/scrutiny.expected   |  16 +-
 types.db  | 255 ++--
 13 files changed, 722 insertions(+), 531 deletions(-)
 create mode 100644 chicken.base.import.scm

diff --git a

Re: [Chicken-hackers] [PATCH] Add "chicken.type" module

[Peter Bex]

On Fri, Sep 15, 2017 at 12:34:10AM +, Evan Hanson wrote:
> On 2017-09-11 19:04, Peter Bex wrote:
> > Now, does anyone want to look at what to do with the documentation?
> > The current "Types" manual page is quite well-written, but it's
> > structured like a tutorial which makes it less suited for the
> > reference manual style which we use for module documentation
> > in the rest of the CHICKEN 5 manual.  The same is true for the
> > bits on FFI and the module system.
> 
> Perhaps we should leave the content of these pages alone, but move the
> documentation for specific procedures and macros into separate pages that
> correspond to the modules they live in? As you say, the current docs are
> well-written and effective as tutorials and big-picture explanations, but a
> clear separation between "user guide" and "procedure reference" might do us
> well. Then the user guide pages can link through to the relevant procedure- 
> and
> and macro-specific docs wherever they're mentioned.
> 
> So, we'd have something like:
> 
>  - manual/Types
>  - manual/Modules
>  - manual/Foreign Interface
>  - manual/Module (chicken foreign)
>  - manual/Module (chicken module)
>  - manual/Module (chicken type)
> 
> Thoughts?

That could work, probably with only minimal changes to ensure we don't end
up with duplicate procedure "reference definitions".

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Less type smashing

[Peter Bex]

On Tue, Sep 12, 2017 at 10:20:24AM +0200, LemonBoy wrote:
> Hello hackers,
> after debugging some code I noticed the compiler was smashing the type for 
> some
> list I had defined via `define-constant`. That's not needed since the 
> constants
> aren't exported nor they are modifiable so here's a patch to make the
> scrutinizer aware of that.

I think this patch is too dangerous.  The reason is that the compiler does
absolutely nothing to prevent mutation of "constants":

$ cat test.scm
(define-constant foo '(a b c))
(set-car! foo 1)
(print foo)

(set-cdr! foo 2)
(print foo)

$ csc -O3 test.scm
$ ./test
(1 b c)
(1 . 2)

Now I'd agree your patch would be a good thing, but _only_ if we can make
the compiler enforce immutability of constant objects (which can't be
done in general, AFAIK).

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix the inconsistent behavior between values and call/cc

[Peter Bex]

On Fri, Sep 08, 2017 at 01:46:14AM +0200, Kooda wrote:
> Hi!
> 
> Here is a patch and a test case for the #1390 ticket.
> 
> I’m not too sure about the quality and implications of this patch, please 
> review
> it thoroughly. :)

Thanks a lot!  Especially the tests are nice and concise.

Nevertheless, to be absolutely thorough, I've added another
test to ensure that we don't bail out when the argument count
is correct.  I've also added a note to NEWS (it's a relatively
important user-visible change) and added the new test file to
the distribution manifest.  Finally, I've also renamed
call_cc_values_wrapper() to call_cc_wrapper(), removing the old
one, because of the two functions, only one was still being used.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add initial version of (chicken base)

[Peter Bex]

On Tue, Sep 12, 2017 at 10:51:56AM +0200, felix.winkelm...@bevuta.com wrote:
> > - notice (we already had "warning" and "error", however, notice seems
> >   to be used mostly in the compiler)
> 
> Does this need to be exposed? I'm not sure how useful this is for user
> code.

Currently ##sys#notice is used by ##sys#import when re-importing
identifiers.  Maybe it could be useful for user macros as well, if one
wants to allow the user to enable / disable these notices.

> > - use
> > - require-library
> > - require-extension
> >
> > I'm not 100% sure about require-library, require-extension and use,
> > especially given that import is in (chicken module).
> 
> Hm... I thought we try to get rid of all these alternative loading forms?

I think that's still a TODO (we can of course do that afterwards).

> > I'm less certain what we should add to the non-macro toplevel default
> > Perhaps (chicken type), (chicken fixnum), (chicken flonum) and
> > (chicken foreign) [the latter for compiled code], but we could also
> > keep it otherwise empty, or even add everything from library.scm, much
> > like we do today in CHICKEN 4.  This would make it easier for scripts,
> > but perhaps a bit more confusing for beginners ("what do you mean,
> > sometimes I have to import and sometimes it's already there?!!")
> 
> Does this apply to interpreted or compiled code? My assumption was
> that only the base stuff is initially visible.

I don't know really; I got compilation errors but those may be due to
macros that failed (which is interpreted code).

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Add initial version of (chicken base)

[Peter Bex]

Hi all,

Attached is a first stab at a (chicken base) module.  I implemented what
was on the wiki and took the liberty of adding a few "obvious" candidates
to the list, and implementing that at the same time.  These additions are:

- case-lambda
- define-constant
- define-record-type (we already had only define-record)
- define-record-printer
- define-values
- exact-integer?
- exact-integer-sqrt and exact-integer-nth-root
- include-relative
- let-optionals and optional
- let{,*,rec}-values
- nth-value
- notice (we already had "warning" and "error", however, notice seems
  to be used mostly in the compiler)
- use
- require-library
- require-extension
- quotient&{remainder,modulo}

I'm not 100% sure about require-library, require-extension and use,
especially given that import is in (chicken module).

I've put a few even more questionable entries under TODO on the wiki
core-library-reorganization page.

IMO, ideally in the end we'd only have (module) declarations and (set!)
calls at the toplevel in library.scm.  However, we need to find out how
to control what's available at toplevel and in macros by default.
Currently only the toplevel definitions are visible there, which is
why I had to add a nasty hack at the end of the file to ensure that
add1, sub1 and gensym are available in macros (without the hack,
everything will break).

I think by default the entire scheme and (chicken base) modules should
be available at the regular and meta toplevels.

I'm less certain what we should add to the non-macro toplevel default
Perhaps (chicken type), (chicken fixnum), (chicken flonum) and
(chicken foreign) [the latter for compiled code], but we could also
keep it otherwise empty, or even add everything from library.scm, much
like we do today in CHICKEN 4.  This would make it easier for scripts,
but perhaps a bit more confusing for beginners ("what do you mean,
sometimes I have to import and sometimes it's already there?!!")
Clear documentation is a must in any case.

Cheers,
Peter
From bddb0b2b7e130d5766d695bc7e0da1e03605c112 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Mon, 11 Sep 2017 18:35:10 +0200
Subject: [PATCH] Add priliminary version of (chicken base) module

This is a primitive module because it has several syntax exports.

We first define the module containing mostly stub definitions which
are set! further down in the file.  This ensures we won't have to
import the module into itself, which will result in strange/unexpected
errors.

There's one hack: at the end of library.scm, we define a few toplevel
aliases for procedures that are supposed to be in the default macro
namespace.  Without this, we'd need (import-for-syntax chicken.base)
in practically every low-level macro use.  We will need to find out
why this is needed, and take better control over what's available in
the initial macro environment.
---
 README|   1 +
 c-platform.scm|  61 ---
 chicken-syntax.scm| 289 --
 chicken.base.import.scm   |  75 
 chicken.import.scm|  95 +-
 defaults.make |   3 +-
 distribution/manifest |   2 +
 expand.scm|  10 +-
 library.scm   | 447 +++---
 modules.scm   |  25 +--
 tests/scrutiny-2.expected |   8 +-
 tests/scrutiny.expected   |  16 +-
 types.db  | 260 ++-
 13 files changed, 751 insertions(+), 541 deletions(-)
 create mode 100644 chicken.base.import.scm

diff --git a/README b/README
index 6ee15437..54641e04 100644
--- a/README
+++ b/README
@@ -284,6 +284,7 @@ _/_/_/_/_/_/  _/_/_/_/_/
 	|   |-- chicken
 	|   |   `-- 9
 	|   |   |-- chicken.import.so
+	|   |   |-- chicken.base.import.so
 	|   |   |-- chicken.bitwise.import.so
 	|   |   |-- chicken.blob.import.so
 	|   |   |-- chicken.compiler.user-pass.import.so
diff --git a/c-platform.scm b/c-platform.scm
index b01b6edb..a4e932fa 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -61,7 +61,7 @@
 (bound-to-procedure
  ##sys#for-each ##sys#map ##sys#print ##sys#setter
  ##sys#setslot ##sys#dynamic-wind ##sys#call-with-values
- ##sys#start-timer ##sys#stop-timer ##sys#gcd ##sys#lcm ##sys#make-promise ##sys#structure? ##sys#slot 
+ ##sys#start-timer ##sys#stop-timer ##sys#gcd ##sys#lcm ##sys#structure? ##sys#slot 
  ##sys#allocate-vector ##sys#list->vector ##sys#block-ref ##sys#block-set!
  ##sys#list ##sys#cons ##sys#append ##sys#vector ##sys#foreign-char-argument ##sys#foreign-fixnum-argument
  ##sys#foreign-flonum-argument ##sys#error ##sys#peek-c-string ##sys#peek-nonnull-c-string 
@@ -76,8 +76,8 @@
##sys#profile-entry ##sys#profile-exit) ) ) )
 
 (define default-units '(library eval))
-(define default-imports '(sc

Re: [Chicken-hackers] [PATCH] Add "chicken.type" module

[Peter Bex]

On Mon, Sep 11, 2017 at 09:05:57AM +1200, Evan Hanson wrote:
> Hi folks,
> 
> Here's a patch that creates the "chicken.type" module. It's pretty
> straightforward, let me know if you have any questions.

Great job, thanks!  I've pushed this.

Now, does anyone want to look at what to do with the documentation?
The current "Types" manual page is quite well-written, but it's
structured like a tutorial which makes it less suited for the
reference manual style which we use for module documentation
in the rest of the CHICKEN 5 manual.  The same is true for the
bits on FFI and the module system.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Move around {rename, delete}-file and a question about module for inexact

[Peter Bex]

On Sun, Sep 10, 2017 at 05:33:16PM +0200, Peter Bex wrote:
> Given that we're trying to put r7rs-like procedures under similar
> namespace (but with scheme replaced by chicken) that creates a small
> inconsistency; (chicken base) would hold finite?, infinite? and nan?
> but they're really in (scheme inexact) in r7rs.

This same inconsistency crops up in (scheme lazy), which has
delay, delay-force, force, promise? and make-promise, whereas
the scheme module has delay and force.

Again, we could put delay-force, promise? and make-promise into
(chicken base) _and_ make an aliasing module (chicken lazy)
that has both the extended and r5rs procedures, but that seems
awkward and annoying when you import both; you'd get constant
warnings about re-importing identifiers.  OTOH, putting it just
under (chicken base) might result in the aforementioned confusion
for people familiar with r7rs.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Move around {rename, delete}-file and a question about module for inexact

[Peter Bex]

Hi all,

Here's a straightforward patch to move those two procedures from
library.scm to file.scm.

I tried to move {file,directory}-exists? as well, but it seems
there are a few places which use it, and that would mean eval
will depend on file, irregex and posix, which I think is a bit
too heavy of a dependency.  I'm not sure how to fix this properly.

Also, a quick question: I noticed that finite?, infinite?, nan?
are in (scheme inexact) in r7rs.  Unfortunately, that module
also holds exp, sqrt, [as]sin, [as]cos, [as]tan and log, which
are all r5rs procedures.

Given that we're trying to put r7rs-like procedures under similar
namespace (but with scheme replaced by chicken) that creates a small
inconsistency; (chicken base) would hold finite?, infinite? and nan?
but they're really in (scheme inexact) in r7rs.  This might cause
confusion for users who are familiar with r7rs.  I don't know
how to solve that in a satisfactory way, unless we want to add a
module alias for it, so that some procedures are defined in
(chicken base) and scheme but re-exported by (chicken inexact).
What do you all think?

Cheers,
Peter
From 3b2cd55dea9dda88491a8693d6c40a1e12424ef9 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 10 Sep 2017 17:22:19 +0200
Subject: [PATCH] Move delete-file and rename-file from library.scm to file.scm

Nothing really depends on it, so we can move them without problems.

Fix up csc.scm's dependencies while we're at it (it also gets a new
dependency on file.import.scm)
---
 chicken.import.scm |  2 --
 csc.scm|  5 +++--
 file.scm   | 18 ++
 library.scm| 20 
 rules.make |  8 ++--
 5 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/chicken.import.scm b/chicken.import.scm
index ad4b677f..06212515 100644
--- a/chicken.import.scm
+++ b/chicken.import.scm
@@ -54,7 +54,6 @@
cplxnum?
current-error-port
(current-exception-handler . chicken.condition#current-exception-handler)
-   delete-file
directory-exists?
(dynamic-load-libraries . chicken.load#dynamic-load-libraries)
enable-warnings
@@ -155,7 +154,6 @@
quotient&remainder
ratnum?
(register-feature! . chicken.platform#register-feature!)
-   rename-file
(repository-path . chicken.platform#repository-path)
(require . chicken.load#require)
return-to-host
diff --git a/csc.scm b/csc.scm
index 23241fac..15882f27 100644
--- a/csc.scm
+++ b/csc.scm
@@ -29,12 +29,13 @@
 
 (import scheme
 chicken
-chicken.posix
+	chicken.file
 	chicken.foreign
 	chicken.format
 chicken.io
-chicken.process
 	chicken.pathname
+chicken.posix
+chicken.process
 	chicken.string)
 
 (include "egg-environment.scm")
diff --git a/file.scm b/file.scm
index f9f42949..69b76949 100644
--- a/file.scm
+++ b/file.scm
@@ -104,12 +104,30 @@ EOF
 	(apply ##sys#signal-hook type loc (string-append msg " - " (strerror rn)) args) ) ) ) )
 
 
+(define (delete-file filename)
+  (##sys#check-string filename 'delete-file)
+  (unless (eq? 0 (##core#inline "C_delete_file" (##sys#make-c-string filename 'delete-file)))
+(##sys#update-errno)
+(##sys#signal-hook
+ #:file-error 'delete-file
+ (##sys#string-append "cannot delete file - " strerror) filename) )
+  filename)
+
 ;;; Like `delete-file', but does nothing if the file doesn't exist:
 
 (define delete-file*
   (lambda (file)
 (and (file-exists? file) (delete-file file
 
+(define (rename-file old new)
+  (##sys#check-string old 'rename-file)
+  (##sys#check-string new 'rename-file)
+  (unless (eq? 0 (##core#inline "C_rename_file" (##sys#make-c-string old 'rename-file) (##sys#make-c-string new)))
+(##sys#update-errno)
+(##sys#signal-hook
+ #:file-error 'rename-file
+ (##sys#string-append "cannot rename file - " strerror) old new) )
+  new)
 
 ;;; Directory management:
 
diff --git a/library.scm b/library.scm
index d190fd03..d75635a9 100644
--- a/library.scm
+++ b/library.scm
@@ -2897,26 +2897,6 @@ EOF
   (##sys#values (##sys#slot port 4) (##sys#slot port 5))
   (##sys#error 'port-position "cannot compute position of port" port) ) )
 
-(define (delete-file filename)
-  (##sys#check-string filename 'delete-file)
-  (unless (eq? 0 (##core#inline "C_delete_file" (##sys#make-c-string filename 'delete-file)))
-(##sys#update-errno)
-(##sys#signal-hook
- #:file-error 'delete-file
- (##sys#string-append "cannot delete file - " strerror) filename) )
-  filename)
-
-(define (rename-file old new)
-  (##sys#check-string old 'rename-file)
-  (##sys#check-string new 'rename-file)
-  (unless (eq? 0 (##core#inline "C_rename_file" (##sys#make-c-string old 'rename-file) (##sys#make-c-string new)))
-(##sys#update-er

Re: [Chicken-hackers] [PATCH] Remove the `any?` procedure

[Peter Bex]

On Sun, Sep 10, 2017 at 01:05:31PM +1200, Evan Hanson wrote:
> Hi folks,
> 
> Here's a very simple one, removing `any?` (since `constantly` can
> provide the same thing easily enough).

Thanks, this procedure has always bothered me: I tend to get confused
between SRFI-1 any and this one, and it seems overly specific to have
something like this when we also have `constantly` and you can always
just write a lambda that always returns #t.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Make `current-directory` a pure getter with associated setter

[Peter Bex]

On Fri, Sep 01, 2017 at 04:18:07PM -0400, Evan Hanson wrote:
> Here is a small API change for the `current-directory` procedures, after
> some discussion of the other patch on IRC. See the commit message for
> rationale.

Thanks, pushed.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5][RESEND] Teach the heap dumper about the numeric tower types

[Peter Bex]

On Wed, Aug 30, 2017 at 01:53:10PM +0200, lemonboy wrote:
> Hello hackers,
> here's a small patch that prevents `##sys#dump-heap-state` to segfault when 
> the
> heap contains one of those newfangled numeric types.

Thanks, pushed (it's trivial enough not to require double signoff, IMO).

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Rewrite vararg generic numeric procedures to dyadic ones

[Peter Bex]

Hi all,

Christian came up with a very nice benchmark that showed how chicken-5 is
quite a bit slower than master:
http://paste.call-cc.org/paste?id=1591b9c68d7296c7458ed31312d636cfff1ee41d

I've identified one problem and that's that this benchmark uses a call to
the * procedure with 3 arguments which results in a CPS call to C_times,
which in chicken-5 is much, much slower due to the missing unboxed flonum
loop and such.  Now, we could try to optimise these vararg procedures too,
but I noticed a much better opportunity.

When we rewrite (* a b c) to (* (* a b) c), we get dyadic calls but not
only that, the scrutiny type information can be used to specialize those
calls (we only have specializations for dyadic calls).  The generic
versions can't be optimized, even if we know for sure that all arguments
are flonums.

Attached is a patch that does this.  I decided to get rid of the old
"19" class, because only one rewrite was using it and we probably want
to get rid of the fixnum mode some day.

A quick run of the benchmark suite points out that this is a small win
and gives a handful of benchmarks that are 20% faster, the other ones
are unaffected (modulo some noise).

Of course we could still put some effort in the generic operators, but
after this patch, the compiler should no longer generate calls to those
in the vast majority of cases.  Only when "apply" is used or when * is
used as an unknown higher-order procedure it would be used.

Cheers,
Peter
From 9ea8c9f4887f7d30c231903759644d59d25d0938 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Wed, 23 Aug 2017 21:43:50 +0200
Subject: [PATCH] Rewrite vararg generic operators to dyadic ones

This allows for further optimizations because specialization rules are
only defined for dyadic versions of procedures, so even if all
argument types were known, vararg procedures would never be optimized
at all.

Now, even if not all types are known, we can at least specialize a few
intermediate operations.
---
 c-platform.scm | 14 --
 optimizer.scm  | 53 ++---
 2 files changed, 38 insertions(+), 29 deletions(-)

diff --git a/c-platform.scm b/c-platform.scm
index 9f0554e7..864f371e 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -248,8 +248,6 @@
 
 ;;; Rewriting-definitions for this platform:
 
-(rewrite '+ 19 0 "C_fixnum_plus" "C_u_fixnum_plus" #f)
-
 (let ()
   ;; (add1 ) -> (##core#inline "C_fixnum_increase" ) [fixnum-mode]
   ;; (add1 ) -> (##core#inline "C_u_fixnum_increase" )   [fixnum-mode + unsafe]
@@ -579,6 +577,10 @@
 
 (rewrite 'abs 14 'fixnum 1 "C_fixnum_abs" "C_fixnum_abs")
 
+(rewrite 'chicken.bitwise#bitwise-and 19)
+(rewrite 'chicken.bitwise#bitwise-xor 19)
+(rewrite 'chicken.bitwise#bitwise-ior 19)
+
 (rewrite 'chicken.bitwise#bitwise-and 21 -1 "C_fixnum_and" "C_u_fixnum_and" "C_s_a_i_bitwise_and" 5)
 (rewrite 'chicken.bitwise#bitwise-xor 21 0 "C_fixnum_xor" "C_fixnum_xor" "C_s_a_i_bitwise_xor" 5)
 (rewrite 'chicken.bitwise#bitwise-ior 21 0 "C_fixnum_or" "C_u_fixnum_or" "C_s_a_i_bitwise_ior" 5)
@@ -663,10 +665,18 @@
 (rewrite 'lcm 12 '##sys#lcm #t 2)
 (rewrite 'chicken.data-structures#identity 12 #f #t 1)
 
+(rewrite 'gcd 19)
+(rewrite 'lcm 19)
+
 (rewrite 'gcd 18 0)
 (rewrite 'lcm 18 1)
 (rewrite 'list 18 '())
 
+(rewrite '+ 19)
+(rewrite '- 19)
+(rewrite '* 19)
+(rewrite '/ 19)
+
 (rewrite '+ 16 2 "C_s_a_i_plus" #t 29)
 (rewrite '- 16 2 "C_s_a_i_minus" #t 29)
 (rewrite '* 16 2 "C_s_a_i_times" #t 33)
diff --git a/optimizer.scm b/optimizer.scm
index 67f92374..e7d773da 100644
--- a/optimizer.scm
+++ b/optimizer.scm
@@ -1224,35 +1224,34 @@
 	  (intrinsic? name)
 	  (make-node '##core#call (list #t) (list cont (qnode (first classargs))) ) ) )
 
-;; () -> 
-;; ( ) -> 
-;; (  ...) -> (##core#inline   (##core#inline  ...)) [fixnum-mode]
-;; (  ...) -> (##core#inline   (##core#inline  ...)) [fixnum-mode + unsafe]
-;; - Remove "" from arguments.
-((19) ; classargs = (   )
+;; (  ... ) -> ( (  ...) ) [in CPS]
+((19)
  (and may-rewrite
 	  (intrinsic? name)
-	  (let* ((id (first classargs))
-		 (fixop (if unsafe (third classargs) (second classargs)))
-		 (callargs 
-		  (filter
-		   (lambda (x)
-		 (not (and (eq? 'quote (node-class x))
-			   (eq? id (first (node-parameters x))) ) ) )
-		   callargs) ) )
-	(cond ((null? callargs) (make-node '##core#call (list #t) (list cont (qnode id
-		  ((null? (cdr callargs))
-		   (make-node '##core#call (list #t) (list cont (first callargs))) )
-		  ((or (fourth classargs) (eq? number-type 'fixnum))
-		   (ma

[Chicken-hackers] [PATCH] Rename (chicken lolevel) to (chicken memory representation)

[Peter Bex]

Hi all,

Another reasonably straightforward patch.

I'm not sure what to do with the ##sys#slot, ##sys#setslot and
##sys#setislot yet.  We could move it to chicken.memory.representation
but I'm not sure that will provide much of a win yet, because then we'd
need to duplicate all the code that specialises these for the new name
as well, and we can't get rid of the old one anyway because library.scm
uses these extensively.  So this patch doesn't do anything with those.

Cheers,
Peter
From 6318503f0ac39f4bffa88fa922952224621b1b83 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Mon, 21 Aug 2017 21:12:59 +0200
Subject: [PATCH] Rename (chicken lolevel) to (chicken memory representation)

This module was already finalized, we just hadn't decided on a final
name yet.
---
 README  |  2 +-
 c-platform.scm  | 18 ++
 defaults.make   |  8 
 distribution/manifest   |  4 ++--
 lolevel.scm |  4 ++--
 modules.scm |  1 -
 rules.make  |  5 +++--
 tests/lolevel-tests.scm |  3 ++-
 tests/posix-tests.scm   |  2 +-
 types.db| 38 +++---
 10 files changed, 44 insertions(+), 41 deletions(-)

diff --git a/README b/README
index d6305711..251debe8 100644
--- a/README
+++ b/README
@@ -306,8 +306,8 @@ _/_/_/_/_/_/  _/_/_/_/_/
 	|   |   |-- chicken.keyword.import.so
 	|   |   |-- chicken.load.import.so
 	|   |   |-- chicken.locative.import.so
-	|   |   |-- chicken.lolevel.import.so
 	|   |   |-- chicken.memory.import.so
+	|   |   |-- chicken.memory.representation.import.so
 	|   |   |-- chicken.pathname.import.so
 	|   |   |-- chicken.platform.import.so
 	|   |   |-- chicken.plist.import.so
diff --git a/c-platform.scm b/c-platform.scm
index 9f0554e7..46572b91 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -178,8 +178,6 @@
 srfi-4#blob->u32vector/shared srfi-4#blob->s32vector/shared
 srfi-4#blob->u64vector/shared srfi-4#blob->s64vector/shared
 srfi-4#blob->f32vector/shared srfi-4#blob->f64vector/shared
-chicken.lolevel#number-of-slots chicken.lolevel#make-record-instance
-chicken.lolevel#block-ref chicken.lolevel#block-set!
 chicken.memory#u8vector-ref chicken.memory#s8vector-ref
 chicken.memory#u16vector-ref chicken.memory#s16vector-ref
 chicken.memory#u32vector-ref chicken.memory#s32vector-ref
@@ -190,6 +188,10 @@
 chicken.memory#u16vector-set! chicken.memory#s16vector-set!
 chicken.memory#u32vector-set! chicken.memory#s32vector-set!
 chicken.memory#u64vector-set! chicken.memory#s64vector-set!
+chicken.memory.representation#number-of-slots
+chicken.memory.representation#make-record-instance
+chicken.memory.representation#block-ref
+chicken.memory.representation#block-set!
 chicken.locative#locative-ref chicken.locative#locative-set!
 chicken.locative#locative->object chicken.locative#locative?
 chicken.memory#pointer+ chicken.memory#pointer=?
@@ -560,8 +562,8 @@
 (rewrite 'list-tail 2 2 "C_i_list_tail" #t)
 (rewrite '##sys#structure? 2 2 "C_i_structurep" #t)
 (rewrite '##sys#bytevector? 2 2 "C_bytevectorp" #t)
-(rewrite 'chicken.lolevel#block-ref 2 2 "C_slot" #f)	; ok to be unsafe, lolevel is anyway
-(rewrite 'chicken.lolevel#number-of-slots 2 1 "C_block_size" #f)
+(rewrite 'chicken.memory.representation#block-ref 2 2 "C_slot" #f)	; ok to be unsafe, lolevel is anyway
+(rewrite 'chicken.memory.representation#number-of-slots 2 1 "C_block_size" #f)
 
 (rewrite 'assv 14 'fixnum 2 "C_i_assq" "C_u_i_assq")
 (rewrite 'assv 2 2 "C_i_assv" #t)
@@ -648,9 +650,9 @@
 (rewrite 'setter 11 1 '##sys#setter #t)
 (rewrite 'for-each 11 2 '##sys#for-each #t)
 (rewrite 'map 11 2 '##sys#map #t)
-(rewrite 'chicken.lolevel#block-set! 11 3 '##sys#setslot #t)
+(rewrite 'chicken.memory.representation#block-set! 11 3 '##sys#setslot #t)
 (rewrite '##sys#block-set! 11 3 '##sys#setslot #f)
-(rewrite 'chicken.lolevel#make-record-instance 11 #f '##sys#make-structure #f)
+(rewrite 'chicken.memory.representation#make-record-instance 11 #f '##sys#make-structure #f)
 (rewrite 'substring 11 3 '##sys#substring #f)
 (rewrite 'string-append 11 2 '##sys#string-append #f)
 (rewrite 'string->list 11 1 '##sys#string->list #t)
@@ -964,7 +966,6 @@
 (srfi-4#f32vector-ref . srfi-4#f32vector-set!)
 (srfi-4#f64vector-ref . srfi-4#f64vector-set!)
 (chicken.locative#locative-ref . chicken.locative#locative-set!)
-(chicken.lolevel#block-ref . chicken.lolevel#block-set!)
 (chicken.memory#pointer-u8-ref . chicken.memory#pointer-u8-set!)
 (chicken.memory#poin

Re: [Chicken-hackers] [PATCH] Update types.db entries for chicken.string procedures

[Peter Bex]

On Mon, Aug 21, 2017 at 06:40:01PM +1200, Evan Hanson wrote:
> To follow the patch applied earlier today.
> 
> I didn't notice that these types.db updates were missing from that
> changeset until after it was already pushed, sorry about that.

Sorry for that, it was a stupid oversight on my part.  Thanks for
noticing.  I've pushed this patch as well.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Remove workaround for MingW's isnormal() which is no longer required

[Peter Bex]

Hi all,

I noticed the workaround for MingW's broken isnormal() is no longer
needed because in CHICKEN 5, C_flonum_rat has been removed and that
was the only function that used it.  This is another minor cleanup
with no downsides, IMO.

Cheers,
Peter
From 69e308ad1f4ff4313936aa9157e833749ca22be8 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 20 Aug 2017 16:38:19 +0200
Subject: [PATCH] Remove MingW isnormal() workaround; we no longer use this
 function in our runtime

---
 chicken.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/chicken.h b/chicken.h
index 6d72fcea..ce4aa9f0 100644
--- a/chicken.h
+++ b/chicken.h
@@ -342,12 +342,6 @@ void *alloca ();
 #define ___s64  C_s64
 
 
-/* Mingw's isnormal() is broken on 32bit; use GCC's builtin (see #1062) */
-#ifdef __MINGW32__
-# undef isnormal
-# define isnormal __builtin_isnormal
-#endif
-
 /* Constants: */
 
 #define C_STACK_RESERVE   0x1
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Create chicken.string module in data-structures.scm

[Peter Bex]

Hi all,

Attached is a straightforward patch to move the string stuff into
chicken.string in the data-structures unit.

I decided for now to not mess with the ##sys#substring... stuff,
but we'll probably want to get rid of the ##sys# prefix some day
too.

Cheers,
Peter
From f42d27d177a21db2432ae6751a85f3718fe10ee3 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 20 Aug 2017 16:06:55 +0200
Subject: [PATCH] Move string manipulation stuff from data-structures to
 chicken.string

---
 README  |  1 +
 batch-driver.scm|  2 +-
 c-backend.scm   |  3 ++-
 c-platform.scm  | 14 ++
 chicken-bug.scm |  3 ++-
 chicken-ffi-syntax.scm  |  4 ++--
 chicken-install.scm |  3 ++-
 chicken-profile.scm |  6 +++---
 chicken-status.scm  |  6 +++---
 chicken-uninstall.scm   |  6 +++---
 chicken.scm |  2 +-
 core.scm|  3 ++-
 csc.scm |  4 ++--
 csi.scm |  3 ++-
 data-structures.scm | 23 ++
 defaults.make   |  2 +-
 distribution/manifest   |  2 ++
 extras.scm  |  2 +-
 optimizer.scm   |  5 +++--
 pathname.scm|  2 +-
 rules.make  | 42 +
 scrutinizer.scm |  4 +++-
 support.scm |  3 ++-
 tests/compiler-tests.scm|  2 +-
 tests/data-structures-tests.scm |  6 --
 tests/executable-tests.scm  |  2 +-
 tests/port-tests.scm|  3 ++-
 tests/reexport-tests.scm|  2 +-
 tests/test-irregex.scm  |  3 ++-
 tests/test.scm  |  2 +-
 tests/typematch-tests.scm   |  3 ++-
 tests/version-tests.scm |  2 +-
 32 files changed, 101 insertions(+), 69 deletions(-)

diff --git a/README b/README
index 288f6e64..d6305711 100644
--- a/README
+++ b/README
@@ -320,6 +320,7 @@ _/_/_/_/_/_/  _/_/_/_/_/
 	|   |   |-- chicken.random.import.so
 	|   |   |-- chicken.repl.import.so
 	|   |   |-- chicken.sort.import.so
+	|   |   |-- chicken.string.import.so
 	|   |   |-- chicken.read-syntax.import.so
 	|   |   |-- chicken.syntax.import.so
 	|   |   |-- chicken.tcp.import.so
diff --git a/batch-driver.scm b/batch-driver.scm
index 66f5c803..c61557ff 100644
--- a/batch-driver.scm
+++ b/batch-driver.scm
@@ -36,7 +36,6 @@
 (compile-source-file)
 
 (import chicken scheme
-	chicken.data-structures
 	chicken.format
 	chicken.gc
 	chicken.internal
@@ -44,6 +43,7 @@
 	chicken.pathname
 	chicken.platform
 	chicken.pretty-print
+	chicken.string
 	chicken.time
 	chicken.compiler.support
 	chicken.compiler.compiler-syntax
diff --git a/c-backend.scm b/c-backend.scm
index 1fe60dd3..f1328c42 100644
--- a/c-backend.scm
+++ b/c-backend.scm
@@ -36,12 +36,13 @@
 
 (import chicken scheme
 	chicken.bitwise
-	chicken.data-structures
+	(only chicken.data-structures intersperse)
 	chicken.flonum
 	chicken.foreign
 	chicken.format
 	chicken.internal
 	chicken.sort
+	chicken.string
 	chicken.time
 	chicken.compiler.core
 	chicken.compiler.c-platform
diff --git a/c-platform.scm b/c-platform.scm
index f94dcfd4..9f0554e7 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -204,10 +204,8 @@
 chicken.memory#pointer-u32-set! chicken.memory#pointer-s32-set!
 chicken.memory#pointer-f32-set! chicken.memory#pointer-f64-set!
 chicken.data-structures#o
-chicken.data-structures#substring-index
-chicken.data-structures#substring-index-ci
-chicken.data-structures#substring=?
-chicken.data-structures#substring-ci=?
+chicken.string#substring-index chicken.string#substring-index-ci
+chicken.string#substring=? chicken.string#substring-ci=?
 chicken.data-structures#any? chicken.data-structures#atom?
 chicken.data-structures#alist-ref chicken.data-structures#rassoc
 chicken.io#read-string chicken.format#format
@@ -1039,10 +1037,10 @@
 (rewrite 'read-char 23 0 '##sys#read-char/port '##sys#standard-input)
 (rewrite 'write-char 23 1 '##sys#write-char/port '##sys#standard-output)
 (rewrite 'chicken.io#read-string 23 1 'chicken.io#read-string/port '##sys#standard-input)
-(rewrite 'chicken.data-structures#substring=? 23 2 '##sys#substring=? 0 0 #f)
-(rewrite 'chicken.data-structures#substring-ci=? 23 2 '##sys#substring-ci=? 0 0 #f)
-(rewrite 'chicken.data-structures#substring-index 23 2 '##sys#substring-index 0)
-(rewrite 'chicken.data-structures#substring-index-ci 23 2 '##sys#substring-index-ci 0)
+(rewrite 'chicken.string#substring=? 23 2 '##sys#substring=? 0 0 #f)
+(rewrite 'chicken.string#substring-ci=? 23 2 '##sys#substring-ci=? 0 0 #f)
+(rewrite 'chicken.string#substring

[Chicken-hackers] [PATCH] Remove change-directory and change-directory*

[Peter Bex]

Hi all,

The attached patch gets rid of change-directory and change-directory*
in favour of using (current-directory) with an argument.  The argument
can either be a string or a file descriptor.  As far as I know we can't
have ports open on directories.  If we can, we'll have to add support for
using current-directory with a port, too, for consistency.

This opens an important question though: Should current-directory return
whatever is passed in, or should it call itself with no arguments to get
the name of the directory we changed into?  Note that this will fail if
we passed in a file descriptor to a directory which was unlinked!  So
even though this is somewhat weird I think just returning whatever was
passed in (if the change succeeded) is probably the best we can do.
Trying to return a normalized pathname if a string is passed in could
be acceptable, but might be too much magic.

Cheers,
Peter
From 672dfe5a3f613c752178444596d2fd335f9a5472 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 13 Aug 2017 17:45:52 +0200
Subject: [PATCH] Remove change-directory(*) in favour of current-directory

We now also implement fchdir() in Windows, by abstracting out the file
descriptor->path mapping first introduced with fchmod().  Windows
won't in fact actually allow you to "open" a directory so you won't be
able to obtain a file handle to a directory using file-open, but at
least this allows us to use the exact same code on Windows and Unix,
thus reducing code duplication.

In any case, abstracting the fd to path function can prove helpful in
other situations too.
---
 chicken-install.scm |  4 ++--
 posix-common.scm| 16 ++--
 posix.scm   |  7 +++
 posixunix.scm   | 17 -
 posixwin.scm| 39 ---
 types.db|  5 +
 6 files changed, 40 insertions(+), 48 deletions(-)

diff --git a/chicken-install.scm b/chicken-install.scm
index ad8bbfa6..2f209be8 100644
--- a/chicken-install.scm
+++ b/chicken-install.scm
@@ -853,12 +853,12 @@
  (file-exists? tscript))
 (let ((old (current-directory))
   (cmd (string-append default-csi " -s " tscript " " name " " (or version ""
-  (change-directory testdir)
+  (current-directory testdir)
   (let ((r (system cmd)))
 (d "running: ~a~%" cmd)
 (flush-output (current-error-port))
 (cond ((zero? r) 
-   (change-directory old)
+   (current-directory old)
#t)
   (else
 (print "test script failed with nonzero exit status")
diff --git a/posix-common.scm b/posix-common.scm
index da68a48c..d265d578 100644
--- a/posix-common.scm
+++ b/posix-common.scm
@@ -496,8 +496,20 @@ EOF
 
 (define (current-directory #!optional dir)
   (if dir
-  (change-directory dir)
-  (let* ((buffer (make-string 1024))
+  (let ((r (cond ((fixnum? dir) (##core#inline "C_fchdir" dir))
+		 ((string? dir)
+		  (##core#inline "C_chdir"
+ (##sys#make-c-string dir 'current-directory)))
+		 (else
+		  (##sys#signal-hook
+		   #:type-error 'current-directory
+		   "bad argument type - not a fixnum or string" dir)) ) ) )
+	(if (fx< r 0)
+	(posix-error #:file-error 'current-directory "cannot change current directory" dir)
+	;; TODO: Always return a (canonicalized?) string?
+	;; Now we're returning whatever is passed in, as-is.
+	dir) )
+  (let* ((buffer (make-string 1024)) ; TODO: Buffer length?
 	 (len (##core#inline "C_curdir" buffer)) )
 	#+(or unix cygwin)
 	(##sys#update-errno)
diff --git a/posix.scm b/posix.scm
index 8115bfd3..5dbc4c3b 100644
--- a/posix.scm
+++ b/posix.scm
@@ -41,10 +41,9 @@
 
 (module chicken.posix
   (block-device? call-with-input-pipe call-with-output-pipe
-   change-directory change-directory* character-device? close-input-pipe
-   close-output-pipe create-fifo create-pipe
-   create-session create-symbolic-link current-directory
-   current-effective-group-id current-effective-user-id
+   character-device? close-input-pipe close-output-pipe
+   create-fifo create-pipe create-session create-symbolic-link
+   current-directory current-effective-group-id current-effective-user-id
current-effective-user-name current-group-id current-process-id
current-user-id current-user-name directory
directory? duplicate-fileno emergency-exit fcntl/dupfd fcntl/getfd
diff --git a/posixunix.scm b/posixunix.scm
index 170e6494..d5224be2 100644
--- a/posixunix.scm
+++ b/posixunix.scm
@@ -560,23 +560,6 @@ static C_word C_i_fifo_p(C_word name)
 		(and fdsw (if (fixnum? fdsw) (and (memq fdsw wl) fdsw) wl)
 
 
-;;; Directory stuff:
-
-(define change-directory
-  (lambda (name)
-(##sys#check

[Chicken-hackers] [PATCH] Add chicken.sort module

[Peter Bex]

Hi all,

Attached is a patch that splits the sorting procedures from
data-structures into chicken.sort.

I noticed that we currently don't export "merge!" from data-structures.
Should we do that for master?  It is documented as existing, so I
suppose this is strictly speaking a bug.

Cheers,
Peter
From 9cc9d7afd1aa92577c588a73badf733f4e7f1f5b Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 13 Aug 2017 14:42:46 +0200
Subject: [PATCH] Move sorting procedures from chicken.data-structures to
 chicken.sort

This also wraps the chicken-bug and chicken-profile programs in a
"main" module.  This helped find a bug in chicken-profile: we forgot
to import chicken.file in chicken-profile when we moved "glob" into
that module.

We also forgot to export merge!, the side-effect version of merge from
data-structures.  The new chicken.sort module does export this
procedure.
---
 README  |  1 +
 c-backend.scm   |  1 +
 chicken-bug.scm |  9 ++-
 chicken-install.scm |  3 ++-
 chicken-profile.scm | 11 +++--
 chicken-status.scm  |  5 ++--
 csi.scm |  1 +
 data-structures.scm | 12 --
 defaults.make   |  2 +-
 distribution/manifest   |  2 ++
 optimizer.scm   |  5 ++--
 rules.make  | 18 ++
 support.scm |  1 +
 tests/data-structures-tests.scm |  3 ++-
 tests/test-find-files.scm   |  5 +++-
 types.db| 52 ++---
 16 files changed, 90 insertions(+), 41 deletions(-)

diff --git a/README b/README
index 75f51e0a..288f6e64 100644
--- a/README
+++ b/README
@@ -319,6 +319,7 @@ _/_/_/_/_/_/  _/_/_/_/_/
 	|   |   |-- chicken.process-context.import.so
 	|   |   |-- chicken.random.import.so
 	|   |   |-- chicken.repl.import.so
+	|   |   |-- chicken.sort.import.so
 	|   |   |-- chicken.read-syntax.import.so
 	|   |   |-- chicken.syntax.import.so
 	|   |   |-- chicken.tcp.import.so
diff --git a/c-backend.scm b/c-backend.scm
index 6be88abe..1fe60dd3 100644
--- a/c-backend.scm
+++ b/c-backend.scm
@@ -41,6 +41,7 @@
 	chicken.foreign
 	chicken.format
 	chicken.internal
+	chicken.sort
 	chicken.time
 	chicken.compiler.core
 	chicken.compiler.c-platform
diff --git a/chicken-bug.scm b/chicken-bug.scm
index e0977546..7b5b04ff 100644
--- a/chicken-bug.scm
+++ b/chicken-bug.scm
@@ -25,7 +25,11 @@
 
 (declare (block))
 
-(import chicken.data-structures
+(module main ()
+
+(import chicken scheme)
+
+(import (only chicken.data-structures chop string-intersperse)
 	chicken.foreign
 	chicken.format
 	chicken.io
@@ -34,6 +38,7 @@
 	chicken.port
 	chicken.posix
 	chicken.platform
+	chicken.sort
 	chicken.time)
 
 (define-constant +bug-report-file+ "chicken-bug-report.~a-~a-~a")
@@ -164,3 +169,5 @@ EOF
   (print "\nA bug report has been written to `" fname "'."))
 
 (main (command-line-arguments))
+
+)
diff --git a/chicken-install.scm b/chicken-install.scm
index ad8bbfa6..5ca3947e 100644
--- a/chicken-install.scm
+++ b/chicken-install.scm
@@ -29,8 +29,8 @@
 (import (scheme))
 (import (chicken))
 (import (chicken condition))
-(import (chicken foreign))
 (import (chicken data-structures))
+(import (chicken foreign))
 (import (chicken keyword))
 (import (chicken file))
 (import (chicken format))
@@ -39,6 +39,7 @@
 (import (chicken posix))
 (import (chicken port))
 (import (chicken io))
+(import (chicken sort))
 (import (chicken time))
 (import (chicken pathname))
 (import (chicken process))
diff --git a/chicken-profile.scm b/chicken-profile.scm
index 78582a84..b676f474 100644
--- a/chicken-profile.scm
+++ b/chicken-profile.scm
@@ -26,9 +26,14 @@
 
 (declare (block))
 
-(import chicken.data-structures
+(module main ()
+
+(import chicken scheme)
+(import (only chicken.data-structures string-intersperse)
+	chicken.file
 	chicken.internal
-	chicken.posix)
+	chicken.posix
+	chicken.sort)
 
 (include "mini-srfi-1.scm")
 
@@ -251,3 +256,5 @@ EOF
   (for-each print-row data
   
 (run (command-line-arguments))
+
+)
diff --git a/chicken-status.scm b/chicken-status.scm
index a51e18d5..5f4bbb2d 100644
--- a/chicken-status.scm
+++ b/chicken-status.scm
@@ -27,7 +27,7 @@
 
   (import (scheme))
   (import (chicken))
-  (import (chicken data-structures)
+  (import (only (chicken data-structures) ->string)
 	  (chicken file)
 	  (chicken foreign)
 	  (chicken format)
@@ -35,7 +35,8 @@
 	  (chicken port)
 	  (chicken posix)
   (chicken pathname)
-	  (chicken pretty-print))
+	  (chicken pretty-print)
+	  (chicken sort))
 
   (include "mini-srfi-1.scm")
   (include "egg-environment.scm")
diff --git a/csi.scm b/csi.scm
index 55f8ec3f..cab891ae 100644
--- a/csi.scm
+++ b/csi.scm
@@ -58,6 +58,7 @

[Chicken-hackers] [PATCH] Move current-read-table to chicken.read-syntax

[Peter Bex]

Hi all,

The attached patch is very straightforward (I think), and implements
another part of the proposal Felix and I sent to this list.  It completes
the (chicken read-syntax) module in its current state.

Cheers,
Peter
From 0bc789364558b67aa8bc00206cd4e9c89bdf6345 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 13 Aug 2017 13:38:32 +0200
Subject: [PATCH] Move current-read-table to chicken.read-syntax module

---
 chicken.import.scm | 1 -
 library.scm| 4 ++--
 read-syntax.scm| 4 +++-
 types.db   | 5 ++---
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/chicken.import.scm b/chicken.import.scm
index a812d0d9..a3a7753d 100644
--- a/chicken.import.scm
+++ b/chicken.import.scm
@@ -54,7 +54,6 @@
cplxnum?
current-error-port
(current-exception-handler . chicken.condition#current-exception-handler)
-   current-read-table
delete-file
directory-exists?
(dynamic-load-libraries . chicken.load#dynamic-load-libraries)
diff --git a/library.scm b/library.scm
index 07bebe1f..ae158fb5 100644
--- a/library.scm
+++ b/library.scm
@@ -3170,7 +3170,7 @@ EOF
 (define keyword-style (make-parameter #:suffix))
 (define parentheses-synonyms (make-parameter #t))
 (define symbol-escape (make-parameter #t))
-(define current-read-table (make-parameter (##sys#make-structure 'read-table #f #f #f)))
+(define ##sys#current-read-table (make-parameter (##sys#make-structure 'read-table #f #f #f)))
 
 (define ##sys#read-warning
   (let ([string-append string-append])
@@ -3201,7 +3201,7 @@ EOF
 	(case-sensitive case-sensitive)
 	(parentheses-synonyms parentheses-synonyms)
 	(symbol-escape symbol-escape)
-	(current-read-table current-read-table)
+	(current-read-table ##sys#current-read-table)
 	(kwprefix (string (integer->char 0
 (lambda (port infohandler)
   (let ((csp (case-sensitive))
diff --git a/read-syntax.scm b/read-syntax.scm
index 087c9f3d..506ebd48 100644
--- a/read-syntax.scm
+++ b/read-syntax.scm
@@ -30,7 +30,7 @@
   (disable-interrupts))
 
 (module chicken.read-syntax
-  (copy-read-table define-reader-ctor set-read-syntax!
+  (copy-read-table current-read-table define-reader-ctor set-read-syntax!
set-sharp-read-syntax! set-parameterized-read-syntax!)
 
 (import scheme chicken chicken.internal chicken.platform)
@@ -43,6 +43,8 @@
 	(##sys#setslot a 1 proc)
 	(set! ##sys#read-marks (cons (cons sym proc) ##sys#read-marks)
 
+(define current-read-table ##sys#current-read-table)
+
 (define ((syntax-setter loc slot wrap) chr proc)
   (if (symbol? chr)
   (set-read-mark! chr proc)
diff --git a/types.db b/types.db
index e62c82db..35f48583 100644
--- a/types.db
+++ b/types.db
@@ -982,6 +982,8 @@
 ;; read-syntax
 
 (chicken.read-syntax#copy-read-table (#(procedure #:clean #:enforce) chicken.read-syntax#copy-read-table ((struct read-table)) (struct read-table)))
+(chicken.read-syntax#current-read-table
+ (#(procedure #:clean) chicken.read-syntax#current-read-table (#!optional (struct read-table)) (struct read-table)))
 (chicken.read-syntax#define-reader-ctor (#(procedure #:clean #:enforce) chicken.read-syntax#define-reader-ctor (symbol procedure) undefined))
 
 (chicken.read-syntax#set-parameterized-read-syntax!
@@ -1011,9 +1013,6 @@
 (chicken.time#current-seconds (#(procedure #:clean) chicken.time#current-seconds () integer))
 (chicken.time#current-milliseconds (#(procedure #:clean) chicken.time#current-milliseconds () integer))
 
-(current-read-table
- (#(procedure #:clean) current-read-table (#!optional (struct read-table)) (struct read-table)))
-
 (delete-file (#(procedure #:clean #:enforce) delete-file (string) string))
 (enable-warnings (#(procedure #:clean) enable-warnings (#!optional *) *))
 
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix a minor type warning when compiling library.scm

[Peter Bex]

Hi all,

Here's a simple patch to get rid of the following warning:
Warning: at toplevel:
  assignment of value of type `(procedure print-call-chain (#!rest) (or pair 
null))' to toplevel variable `print-call-chain' does not match declared type 
`(procedure print-call-chain (#!optional (refine (output) port) fixnum * 
string) undefined)'

Alternatively, we could change the type to match the implementation,
but then we should also document the fact that the call chain is
returned.  This doesn't make much sense to me.

Cheers,
Peter
From e779d41c785eb9f5e5966019535fb5aef77b5fbe Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 13 Aug 2017 13:18:53 +0200
Subject: [PATCH] Make print-call-chain match the declared type in types.db

It is declared not to return anything (void), but it takes some effort
to return the call chain, resulting in a type warning.
---
 library.scm | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/library.scm b/library.scm
index 07bebe1f..1efe5c3d 100644
--- a/library.scm
+++ b/library.scm
@@ -4439,9 +4439,7 @@ EOF
   (##sys#check-output-port port #t 'print-call-chain)
   (##sys#check-fixnum start 'print-call-chain)
   (##sys#check-string header 'print-call-chain)
-  (let ((ct (get-call-chain start thread)))
-(##sys#really-print-call-chain port ct header)
-ct))
+  (##sys#really-print-call-chain port (get-call-chain start thread) header) )
 
 
 ;;; Interrupt handling:
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Move reset and reset-handler to (chicken repl)

[Peter Bex]

Hi all,

The attached patch completes (chicken repl) as per the proposal Felix
and I sent to chicken-hackers a while ago.

Cheers,
Peter
From 3b66ad41b5caa4a60702e907434e06627d09d2b9 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 13 Aug 2017 13:13:38 +0200
Subject: [PATCH] Move reset and reset-handler to (chicken repl)

---
 chicken.import.scm |  2 --
 library.scm| 11 ---
 repl.scm   |  5 -
 types.db   |  4 ++--
 4 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/chicken.import.scm b/chicken.import.scm
index a812d0d9..b59dcfe7 100644
--- a/chicken.import.scm
+++ b/chicken.import.scm
@@ -159,8 +159,6 @@
rename-file
(repository-path . chicken.platform#repository-path)
(require . chicken.load#require)
-   reset
-   reset-handler
return-to-host
reverse-list->string
set-port-name!
diff --git a/library.scm b/library.scm
index 07bebe1f..4f8d7c83 100644
--- a/library.scm
+++ b/library.scm
@@ -237,7 +237,6 @@ EOF
 ;;; System routines:
 
 (define (exit #!optional (code 0)) ((##sys#exit-handler) code))
-(define (reset) ((##sys#reset-handler)))
 (define (##sys#debug-mode?) (##core#inline "C_i_debug_modep"))
 
 (define (error . args)
@@ -4455,11 +4454,6 @@ EOF
 
 ;;; Default handlers
 
-(define reset-handler 
-  (make-parameter 
-   (lambda ()
- ((##sys#exit-handler) _ex_software)) ) )
-
 (define exit-in-progress #f)
 
 (define exit-handler
@@ -4478,8 +4472,11 @@ EOF
  (##sys#cleanup-before-exit) ) ) )
 
 (define ##sys#exit-handler exit-handler)
-(define ##sys#reset-handler reset-handler)
 (define ##sys#implicit-exit-handler implicit-exit-handler)
+(define ##sys#reset-handler ; Exposed by chicken.repl
+  (make-parameter
+   (lambda ()
+ ((##sys#exit-handler) _ex_software
 
 (define force-finalizers (make-parameter #t))
 
diff --git a/repl.scm b/repl.scm
index 66383dc5..b86da83a 100644
--- a/repl.scm
+++ b/repl.scm
@@ -30,7 +30,7 @@
   (not inline ##sys#repl-read-hook ##sys#repl-print-hook ##sys#read-prompt-hook))
 
 (module chicken.repl
-  (quit repl repl-prompt)
+  (quit repl repl-prompt reset reset-handler)
 
 (import scheme
 	chicken
@@ -50,6 +50,9 @@
 (define (quit-hook result) (exit))
 (define (quit #!optional result) (quit-hook result))
 
+(define reset-handler ##sys#reset-handler)
+(define (reset) ((reset-handler)))
+
 (define repl-prompt
   (make-parameter (lambda () "#;> ")))
 
diff --git a/types.db b/types.db
index e62c82db..be42b13b 100644
--- a/types.db
+++ b/types.db
@@ -1293,8 +1293,6 @@
   (((struct promise)) #(1)))
 
 (rename-file (#(procedure #:clean #:enforce) rename-file (string string) string))
-(reset (procedure reset () noreturn))
-(reset-handler (#(procedure #:clean #:enforce) reset-handler (#!optional (procedure () . *)) procedure))
 (return-to-host (procedure return-to-host () . *))
 (reverse-list->string (#(procedure #:clean #:enforce) reverse-list->string ((list-of char)) string))
 
@@ -1308,6 +1306,8 @@
 
 (chicken.repl#repl (#(procedure #:enforce) chicken.repl#repl (#!optional (procedure (*) . *)) undefined))
 (chicken.repl#repl-prompt (#(procedure #:clean #:enforce) chicken.repl#repl-prompt (#!optional (procedure () string)) procedure))
+(chicken.repl#reset (procedure chicken.repl#reset () noreturn))
+(chicken.repl#reset-handler (#(procedure #:clean #:enforce) chicken.repl#reset-handler (#!optional (procedure () . *)) procedure))
 (chicken.repl#quit (procedure chicken.repl#quit (#!optional *) noreturn))
 
 (set-port-name! (#(procedure #:clean #:enforce) set-port-name! (port string) undefined)
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Move `print-error-message' into (chicken condition)

[Peter Bex]

On Wed, Aug 09, 2017 at 08:49:28PM +1200, Evan Hanson wrote:
> Thanks Peter.
> 
> On 2017-08-08 19:34, Peter Bex wrote:
> > When we discussed that, the call chain stuff was listed under
> > (chicken base), but I now noticed that these are already part of
> > (chicken condition).  I'm not sure it's worth reverting that again...
> 
> Sure, let's -- it's easy enough to move. Here's a patch that kicks it
> back out into just "chicken". It can move into "base" along with
> everything else once we get to that.

Thanks, I've pushed this.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] Proposal / patch for fixing #1385 (swapped bit-set? argument order)

[Peter Bex]

Hi all,

I've discussed #1385 with Felix, and after some consideration we agreed
the lesser of three evils is to rename the procedure to something
completely nonstandard.  Swapping the argument order in CHICKEN 5 will
almost certainly introduce insidious bugs when porting existing programs
from CHICKEN 4 or from other Schemes.  And keeping the argument order is
bad too, because we will pay the price for having a nonstandard argument
order for the rest of all time.

Keeping the old procedure and adding a new one just moves the problem of
how to rectify this into the future, so that's not an option either.
Renaming it to a completely nonstandard name should make it easy to port,
and later on (CHICKEN 5.1 or even 5.2) we can re-introduce the bit-set?
procedure with the correct argument order, and deprecate the new procedure.

The name of the nonstandard procedure is not very relevant since it is
going to disappear anyway, but I think bit->boolean is a relatively clean
name.  Luckily, core itself doesn't use bit-set? anywhere, so we can
just rename it with impunity, no need to keep the OBSOLETE name around.

If nobody disagrees, let's get this over with!

Cheers,
Peter
From 32b45a6ac3b0297762c1d5bb85847535d85abedb Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Tue, 8 Aug 2017 19:48:07 +0200
Subject: [PATCH] Rename bit-set? to bit->boolean to avoid confusion (fixes
 #1385)

The problem with bit-set? is that our definition has the argument
order swapped when compared to SRFI-33 and SRFI-60.  Given that all
our other procedures follow the definitions given in these SRFIs, it
is extra confusing that this one procedure has a different argument
order.  This may result in very subtle bugs.

To make matters worse, swapping the argument to match the SRFIs would
be downright evil, because it would make porting bugs harder to
find: (bit-set? 1 2) for example will return different values
depending on which argument indicates the number and which the bit
position, but the result is still a boolean and in other cases it
might "accidentally" return the expected result, making it very very
difficult to figure out why a program is failing.

So this is why we rename it: When porting any program from CHICKEN 4
to CHICKEN 5 (or from another Scheme), it will immediately error out,
and after a quick search one will be able to find the CHICKEN 5
procedure bit->boolean (and curse us for deviating from the SRFI, not
knowing our alternatives were even worse).

The new bit->boolean procedure immediately has a sort of deprecated
status.  Later on, after enough time has passed to have ported all
CHICKEN 4 code, bit-set? may be re-introduced with the
correct (SRFI-compliant) argument order, and we can then officially
deprecate bit->boolean.  Even later still we can finally get rid of
this ugly temporary procedure.
---
 NEWS  |  3 +++
 c-platform.scm|  6 +++---
 chicken.h | 10 ++
 library.scm   |  4 +++-
 runtime.c |  9 +
 tests/numbers-test-ashinn.scm |  4 ++--
 tests/numbers-test.scm| 26 +-
 types.db  |  8 
 8 files changed, 39 insertions(+), 31 deletions(-)

diff --git a/NEWS b/NEWS
index a7622b9b..6c0b6487 100644
--- a/NEWS
+++ b/NEWS
@@ -50,6 +50,9 @@
   - Added the `glob->sre` procedure to the irregex library.
   - Removed the `get-host-name' and `system-information' procedures.
 These are available in the "system-information" egg.
+  - Renamed bit-set? to bit->boolean because of swapped argument order
+with respect to SRFI-33 and SRFI-60, which was confusing (fixes
+#1385, thanks to Lemonboy).
 
 - Module system
   - The compiler has been modularised, for improved namespacing.  This
diff --git a/c-platform.scm b/c-platform.scm
index 100cccb9..f94dcfd4 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -157,7 +157,7 @@
 chicken.bitwise#integer-length
 chicken.bitwise#bitwise-and chicken.bitwise#bitwise-not
 chicken.bitwise#bitwise-ior chicken.bitwise#bitwise-xor
-chicken.bitwise#arithmetic-shift chicken.bitwise#bit-set?
+chicken.bitwise#arithmetic-shift chicken.bitwise#bit->boolean
 add1 sub1 exact-integer? nan? finite? infinite?
 void flush-output print print* error call/cc chicken.blob#blob-size
 identity chicken.blob#blob=? equal=? make-polar make-rectangular
@@ -1013,7 +1013,7 @@
 		  (list arg)) ) ) ) ) ) ) )
 
 (rewrite
- 'chicken.bitwise#bit-set? 8
+ 'chicken.bitwise#bit->boolean 8
  (lambda (db classargs cont callargs)
(and (= 2 (length callargs))
 	(make-node
@@ -1021,7 +1021,7 @@
 	 (list cont
 	   (make-node
 		'##core#inline 
-		(list (if (eq? number-type 'fixnum) "C_u_i_bit_setp" "C_i_bit_setp"))
+		(list (if (eq? number-type 'fixnum) "C_u_i_bit_to_bool" "C_i_b

Re: [Chicken-hackers] [PATCH] Move `print-error-message' into (chicken condition)

[Peter Bex]

On Mon, Aug 07, 2017 at 09:46:19PM +1200, Evan Hanson wrote:
> Per Felix and Peter's recent proposal.
> 
> That post also mentions an "error-message" procedure that should be
> moved, but I'm not sure what that refers to so haven't included it (is
> that possibly a mistake, or maybe something that we decided to add to
> the standard library but haven't gotten to yet?).

Thanks!  I don't remember either.  It might have something to do with
get-call-chain vs print-call-chain, we might've mistakenly thought
that there would be a [get-]error-message since there's also a
print-error-message.

We went back and forth on the call-chain stuff and in the end we decided
it belong in (chicken base) because a call chain is always available and
it has nothing to do with exceptions as such: it's just very often that
you want to know the call chain when an exception is raised, but a call
chain can be requested without having an exception.

When we discussed that, the call chain stuff was listed under
(chicken base), but I now noticed that these are already part of
(chicken condition).  I'm not sure it's worth reverting that again...

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Minor srfi-4 fixes

[Peter Bex]

On Sat, Jul 29, 2017 at 09:57:45AM +0200, lemonboy wrote:
> Hello hackers,
> I found and fixed two small problems in the srfi-4 module, here's a patch 
> (made
> against the chicken-5 branch, it should be easily backported to master if
> needed) that also includes some tests.

Very nice, here's a signed-off copy of the patch.  Thanks!

Applying the safe fixnum calculation stuff to master: might be worthwhile,
what do the other hackers think?

Cheers,
Peter
From d5290595ecdc82ecc6763aa72e22ff061cd4034d Mon Sep 17 00:00:00 2001
From: LemonBoy 
Date: Sat, 29 Jul 2017 09:54:01 +0200
Subject: [PATCH] Minor fixes in the srfi-4 module

* subs64vector used the wrong element length (4 instead of 8)
* Make sure the N parameter given to the make-NNvector is a fixnum, do
  not forcibly coerce it to a fixnum before doing so. Raise an error if
  the calculated vector length overflows.

Signed-off-by: Peter Bex 
---
 srfi-4.scm | 47 ---
 tests/srfi-4-tests.scm | 28 
 2 files changed, 52 insertions(+), 23 deletions(-)

diff --git a/srfi-4.scm b/srfi-4.scm
index 14c0f080..112837b8 100644
--- a/srfi-4.scm
+++ b/srfi-4.scm
@@ -80,6 +80,7 @@ EOF
 
 (import scheme chicken)
 (import chicken.bitwise
+	chicken.fixnum
 	chicken.foreign
 	chicken.gc
 	chicken.platform
@@ -367,16 +368,18 @@ EOF
 	(foreign-lambda* void ((scheme-object bv))
 	  "C_free((void *)C_block_item(bv, 1));") )
(alloc
-	(lambda (loc len ext?)
-	  (##sys#check-fixnum len loc)
-	  (when (fx< len 0) (##sys#error loc "size is negative" len))
-	  (if ext?
-	  (let ((bv (ext-alloc len)))
-		(or bv
-		(##sys#error loc "not enough memory - cannot allocate external number vector" len)) )
-	  (let ((bv (##sys#allocate-vector len #t #f #t))) ; this could be made better...
-		(##core#inline "C_string_to_bytevector" bv)
-		bv) ) ) ) )
+	(lambda (loc elem-size elems ext?)
+	  (##sys#check-fixnum elems loc)
+	  (when (fx< elems 0) (##sys#error loc "size is negative" elems))
+	  (let ((len (fx*? elems elem-size)))
+	(unless len (##sys#error "overflow - cannot allocate the required number of elements" elems))
+	(if ext?
+		(let ((bv (ext-alloc len)))
+		  (or bv
+		  (##sys#error loc "not enough memory - cannot allocate external number vector" len)) )
+		(let ((bv (##sys#allocate-vector len #t #f #t))) ; this could be made better...
+		  (##core#inline "C_string_to_bytevector" bv)
+		  bv) ) ) ) ))
 
   (set! release-number-vector
 (lambda (v)
@@ -386,7 +389,7 @@ EOF
 
   (set! make-u8vector
 (lambda (len #!optional (init #f)  (ext? #f) (fin? #t))
-  (let ((v (##sys#make-structure 'u8vector (alloc 'make-u8vector len ext?
+  (let ((v (##sys#make-structure 'u8vector (alloc 'make-u8vector 1 len ext?
 	(when (and ext? fin?) (set-finalizer! v ext-free))
 	(if (not init)
 	v
@@ -398,7 +401,7 @@ EOF
 
   (set! make-s8vector
 (lambda (len #!optional (init #f)  (ext? #f) (fin? #t))
-  (let ((v (##sys#make-structure 's8vector (alloc 'make-s8vector len ext?
+  (let ((v (##sys#make-structure 's8vector (alloc 'make-s8vector 1 len ext?
 	(when (and ext? fin?) (set-finalizer! v ext-free))
 	(if (not init)
 	v
@@ -410,7 +413,7 @@ EOF
 
   (set! make-u16vector
 (lambda (len #!optional (init #f)  (ext? #f) (fin? #t))
-  (let ((v (##sys#make-structure 'u16vector (alloc 'make-u16vector (##core#inline "C_fixnum_shift_left" len 1) ext?
+  (let ((v (##sys#make-structure 'u16vector (alloc 'make-u16vector 2 len ext?
 	(when (and ext? fin?) (set-finalizer! v ext-free))
 	(if (not init)
 	v
@@ -422,7 +425,7 @@ EOF
 
   (set! make-s16vector
 (lambda (len #!optional (init #f)  (ext? #f) (fin? #t))
-  (let ((v (##sys#make-structure 's16vector (alloc 'make-s16vector (##core#inline "C_fixnum_shift_left" len 1) ext?
+  (let ((v (##sys#make-structure 's16vector (alloc 'make-s16vector 2 len ext?
 	(when (and ext? fin?) (set-finalizer! v ext-free))
 	(if (not init)
 	v
@@ -434,7 +437,7 @@ EOF
 
   (set! make-u32vector
 (lambda (len #!optional (init #f)  (ext? #f) (fin? #t))
-  (let ((v (##sys#make-structure 'u32vector (alloc 'make-u32vector (##core#inline "C_fixnum_shift_left" len 2) ext?
+  (let ((v (##sys#make-structure 'u32vector (alloc 'make-u32vector 4 len ext?
 	(when (and ext? fin?) (set-finalizer! v ext-free))
 	(if (not init)
 	v
@@ -446,7 +449,7 @@ EOF
 
   (set! make-u64vector
 (lambda (len #!optional (init #f)  (ext? #f) (fin? #t))
-  (let ((v (##sys#make-structure 'u64vector (alloc 'make-u64vector (##core#inline "C_fixnum_shift_left" len 3) ext?
+  (let ((v (##sys#make-structure 

Re: [Chicken-hackers] [PATCH] correct size calculation for ffi return types

[Peter Bex]

On Mon, Jul 31, 2017 at 06:31:28PM +0200, lemonboy wrote:
> Hello hackers,
> I managed to stumble across this nasty compiler bug while trying to figure out
> why some code was segfaulting in a FFI stub. It turns out that I forgot to 
> place
> a define-foreign-type form before the lines the type was referenced in and the
> compiler happily assumed it had size 0 and skipped the generation of the 
> scratch
> space buffer.
> Here's a simple patch, I'm not too fond of the catch-all case but it shouldn't
> be a problem (the `make check` shows no regression).

Like I said on IRC, I'm not quite sure what to do with this one.  A similar
fix is already part of CHICKEN 5 (5bc3b2d25768f9bd89bafa3b9dd4b85376b0c10a),
see http://lists.gnu.org/archive/html/chicken-hackers/2017-06/msg00081.html

We could apply the error part to master too, but I don't know what kind
of breakage it will cause.  I know it's buggy and probably stupid and
unsafe to leave it, but I'm not sure it's worth risking potentially massive
breakage of existing code that already works.

What do the other hackers think?

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add chicken.plist module

[Peter Bex]

On Thu, Jul 27, 2017 at 05:15:07PM +1200, Evan Hanson wrote:
> Again per Felix and Peter's proposal. Note that this patch is based on
> the one that moves 'quit' to chicken.repl (to avoid conflicts), so that
> one will need to be applied first.

Thanks again, pushed!

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add chicken.blob module

[Peter Bex]

On Thu, Jul 27, 2017 at 09:24:13AM +1200, Evan Hanson wrote:
> Per Felix and Peter's recent proposal.

Pushed, thanks!

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Move `quit' into (chicken repl)

[Peter Bex]

On Thu, Jul 27, 2017 at 09:21:58AM +1200, Evan Hanson wrote:
> Per Felix and Peter's recent proposal.

Thanks, pushed.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Move `create-directory' into (chicken file)

[Peter Bex]

On Tue, Jul 25, 2017 at 08:33:32PM +1200, Evan Hanson wrote:
> Another simple one. `create-directory` is pretty small and relies only
> on "C_mkdir" (which is already in file.scm) as far as C functions go, so
> it's easy to move.

On Mon, Jul 24, 2017 at 05:17:44PM +1200, Evan Hanson wrote:
> Straightforward, finishes off "chicken.module".

Both have been pushed, thanks!

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Another symbol GC sanity check fix [was: Re: [PATCH] Fix record type tags to be nonglobal by module-prefixing them]

[Peter Bex]

On Wed, Jul 19, 2017 at 09:38:14AM +0200, felix.winkelm...@bevuta.com wrote:
> I'm slightly frightened by all the plans for various overhauls and want to 
> point
> out that once 5.0 is released, such changes will require a Change Request
> (which is a good thing, as I think we are going slightly overboard by trying
> to fix everything, regardless of criticality).

Agreed.  The reason I got to thinking about this is because the symbol GC
seems to be a bit wonky due to keywords being somewhat ill-defined.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Another symbol GC sanity check fix [was: Re: [PATCH] Fix record type tags to be nonglobal by module-prefixing them]

[Peter Bex]

On Tue, Jul 18, 2017 at 10:52:01PM +0200, Peter Bex wrote:
> Here's another attempt at improving the sanity check, but if this
> keeps cropping up we might as well just get rid of the sanity check.
> On the other hand, it does point out several issues, so maybe it's
> useful after all:
> 
> - Any symbol that starts with \x00 is seen as a keyword, which isn't
>really true (even if unbound or bound to some other value).
>This also has an impact on how these symbols are written.
> - This means that any symbol that was defined to itself and then
>got its plist modified and reset would be registered as
>collectible (because the propset would think it's a keyword)
>even though it was still bound.
> - In general, we can't really distinguish between keywords and
>symbols.

I think we should fix those issues some day.  For now I think (hope!
fingers crossed!) that the current situation is "good enough".
Maybe for CHICKEN 5.1 we can consider refactoring how keywords
work and make them truly distinct from symbols.

I think the basic approach would be to simply "bind" keywords to a
special value, much like we have C_SCHEME_UNBOUND we could have
something like C_SCHEME_KEYWORD (just making things up here) to
indicate unambiguously that it's a keyword.  Then, the \x00 at
the start of the name can be dropped.

This should really simplify the symbol GC and its associated sanity
check, and reduce any confusing aspects (like how keywords can
be bound to something else than themselves and still be considered
a keyword).  Instead, we can reject attempts at manipulating the
bound value of keywords and perhaps even reject plist modifications
of keywords.

From there, there are two ways to ensure they don't interfere with
symbols that are spelled the same:

- Make the lookup know what we're looking for and use the symbol's
  value to determine whether to return the object or not.
- Create a new symbol table for keywords specifically.

My preference is the second option: it's cleaner and less confusing,
and we can even experiment with a differently sized "keyword table".
This table can perhaps also be assumed to always have only weak
references.

To guarantee backwards compatibility, we could check that an interned
symbol starts with a \x00 and intern it into the keyword table.
A lookup would then also need to ignore the \x00 at the start when
hashing and searching.  Once everything is using unprefixed keywords
we can drop the special-casing for the initial \x00 value.

If people agree this is a good idea, I'll create a ticket for 5.1.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Another symbol GC sanity check fix [was: Re: [PATCH] Fix record type tags to be nonglobal by module-prefixing them]

[Peter Bex]

On Tue, Jul 18, 2017 at 09:55:21AM +1200, Evan Hanson wrote:
> Regarding whether to namespace the core record types, I think we
> probably _should_ do so, but it's not a priority.

Fun fact: Because we now define it as a symbol, we trigger another
GC sanity check assertion failure...

The problem is that it assumes that all symbols that are bound to
themselves are keywords.  However, (define foo 'foo) proves that
this is not necessarily the case.

Here's another attempt at improving the sanity check, but if this
keeps cropping up we might as well just get rid of the sanity check.
On the other hand, it does point out several issues, so maybe it's
useful after all:

- Any symbol that starts with \x00 is seen as a keyword, which isn't
   really true (even if unbound or bound to some other value).
   This also has an impact on how these symbols are written.
- This means that any symbol that was defined to itself and then
   got its plist modified and reset would be registered as
   collectible (because the propset would think it's a keyword)
   even though it was still bound.
- In general, we can't really distinguish between keywords and
   symbols.

The attached patch also tries to make it easier to change how
keywords are represented.

In short, I expect that now the assertion (also the one not in
the DEBUGBUILD) will still trigger if you have a symbol that's
bound to itself, and starts with \x00.  I hope that's an
acceptably rare situation.

Cheers,
Peter
From df8f55184d2cc2e98f7e14e5137d0e825fb2eced Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Tue, 18 Jul 2017 22:32:48 +0200
Subject: [PATCH] Introduce an inline helper function to check for keywords.

Symbols bound to themselves aren't always keywords, which would trip
up the GC sanity check.

To make it easier to change how keywords are represented, the keyword?
predicate now also makes use of this new C_u_i_keywordp() function.
---
 chicken.h   | 12 ++--
 library.scm |  4 ++--
 tests/library-tests.scm |  5 +
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/chicken.h b/chicken.h
index d2e9db6d..443565d3 100644
--- a/chicken.h
+++ b/chicken.h
@@ -2215,6 +2215,15 @@ inline static C_word C_u_i_namespaced_symbolp(C_word x)
   return C_mk_bool(C_memchr(C_data_pointer(s), '#', C_header_size(s)));
 }
 
+inline static C_word C_u_i_keywordp(C_word x)
+{
+  /* TODO: This representation is rather bogus */
+  C_word n = C_symbol_name(x);
+  return C_mk_bool(C_symbol_value(x) == x &&
+   C_header_size(n) > 0 &&
+   ((C_byte *)C_data_pointer(n))[0] == '\0');
+}
+
 inline static C_word C_flonum(C_word **ptr, double n)
 {
   C_word 
@@ -2705,9 +2714,8 @@ inline static C_word C_i_symbolp(C_word x)
 
 inline static int C_persistable_symbol(C_word x)
 {
-  C_word val = C_symbol_value(x);
   /* Symbol is bound (and not a keyword), or has a non-empty plist */
-  return ((val != C_SCHEME_UNBOUND && val != x) ||
+  return ((C_truep(C_boundp(x)) && !C_truep(C_u_i_keywordp(x))) ||
   C_symbol_plist(x) != C_SCHEME_END_OF_LIST);
 }
 
diff --git a/library.scm b/library.scm
index 7f0d60ad..0c296847 100644
--- a/library.scm
+++ b/library.scm
@@ -2109,7 +2109,7 @@ EOF
 (import scheme chicken chicken.fixnum)
 
 (define (keyword? x)
-  (and (symbol? x) (fx= 0 (##sys#byte (##sys#slot x 1) 0))) )
+  (and (symbol? x) (##core#inline "C_u_i_keywordp" x)) )
 
 (define string->keyword
   (let ([string string] )
@@ -4031,7 +4031,7 @@ EOF
 		((not (##core#inline "C_blockp" x)) (outstr port "#"))
 		((##core#inline "C_forwardedp" x) (outstr port "#"))
 		((##core#inline "C_symbolp" x)
-		 (cond ((fx= 0 (##sys#byte (##sys#slot x 1) 0)) ; keyword
+		 (cond ((##core#inline "C_u_i_keywordp" x)
 			;; Force portable #: style for readable output
 			(case (and (not readable) ksp)
 			  ((#:prefix)
diff --git a/tests/library-tests.scm b/tests/library-tests.scm
index 1e33adcb..ed2b4b09 100644
--- a/tests/library-tests.scm
+++ b/tests/library-tests.scm
@@ -403,6 +403,11 @@
   (assert (keyword? empty-kw))
   (assert (string=? "" (keyword->string empty-kw
 
+;; TODO: It should eventually be possible to distinguish these (#1077)
+#;(let ((nul-sym (with-input-from-string "|\\x00|" read)))
+  (assert (not (keyword? nul-sym)))
+  (assert (string=? "\x00" (symbol->string nul-sym
+
 (assert (keyword? (with-input-from-string "42:" read)))
 (assert (keyword? (with-input-from-string ".:" read)))
 
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Two small changes for the (chicken port) module

[Peter Bex]

Hi all,

Attached are two simple patches to make the (chicken port) module
conform a bit better to core-libraries-reorganization.

Cheers,
Peter
From 8a2fdff30184a00907bcf6aaf27338fbebda2020 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Tue, 18 Jul 2017 21:46:38 +0200
Subject: [PATCH 1/2] Move set-buffering-mode! from posix{unix,win}.scm to
 port.scm

There was no real reason for having the two implementations separated
in Windows- and UNIX-specific POSIX files, so this just moves the
definition.  To avoid another ugly #define block, the ##core#inline
is replaced with a simpler foreign-lambda*.
---
 port.scm  | 27 ++-
 posix.scm |  4 ++--
 posixunix.scm | 22 --
 posixwin.scm  | 22 --
 types.db  |  2 +-
 5 files changed, 29 insertions(+), 48 deletions(-)

diff --git a/port.scm b/port.scm
index 3964ed5a..c61a046b 100644
--- a/port.scm
+++ b/port.scm
@@ -48,6 +48,7 @@
make-bidirectional-port
make-broadcast-port
make-concatenated-port
+   set-buffering-mode!
with-error-to-port
with-input-from-port
with-input-from-string
@@ -56,10 +57,34 @@
with-error-to-string)
 
 (import scheme chicken)
-(import chicken.io)
+(import chicken.foreign
+	chicken.io)
 
 (include "common-declarations.scm")
 
+(define-foreign-variable _iofbf int "_IOFBF")
+(define-foreign-variable _iolbf int "_IOLBF")
+(define-foreign-variable _ionbf int "_IONBF")
+(define-foreign-variable _bufsiz int "BUFSIZ")
+
+(define set-buffering-mode!
+  (lambda (port mode . size)
+(##sys#check-port port 'set-buffering-mode!)
+(let ((size (if (pair? size) (car size) _bufsiz))
+	  (mode (case mode
+		  ((#:full) _iofbf)
+		  ((#:line) _iolbf)
+		  ((#:none) _ionbf)
+		  (else (##sys#error 'set-buffering-mode! "invalid buffering-mode" mode port)) ) ) )
+  (##sys#check-fixnum size 'set-buffering-mode!)
+  (when (fx< (if (eq? 'stream (##sys#slot port 7))
+		 ((foreign-lambda* int
+			  ((scheme-object p) (int m) (int s))
+			"C_return(setvbuf(C_port_file(p), NULL, m, s));")
+		  port mode size)
+		 -1)
+		 0)
+	(##sys#error 'set-buffering-mode! "cannot set buffering mode" port mode size) ) ) ) )
 
  Port-mapping (found in Gauche):
 
diff --git a/posix.scm b/posix.scm
index d4815ff7..44cf77b0 100644
--- a/posix.scm
+++ b/posix.scm
@@ -68,8 +68,8 @@
process-group-id process-run process-signal process-sleep
process-spawn process-wait read-symbolic-link regular-file?
seconds->local-time seconds->string seconds->utc-time seek/cur
-   seek/end seek/set set-alarm! set-buffering-mode!
-   set-environment-variable! set-file-group! set-file-owner!
+   seek/end seek/set
+   set-alarm! set-environment-variable! set-file-group! set-file-owner!
set-file-permissions! set-file-position! set-file-times!
set-root-directory! set-signal-handler! set-signal-mask!
signal-handler signal-mask signal-mask! signal-masked? signal-unmask!
diff --git a/posixunix.scm b/posixunix.scm
index 63f0f891..9203c03a 100644
--- a/posixunix.scm
+++ b/posixunix.scm
@@ -150,7 +150,6 @@ static C_TLS struct stat C_statbuf;
 #define C_ftruncate(f, n)   C_fix(ftruncate(C_unfix(f), C_num_to_int(n)))
 #define C_uname C_fix(uname(&C_utsname))
 #define C_alarm alarm
-#define C_setvbuf(p, m, s)  C_fix(setvbuf(C_port_file(p), NULL, C_unfix(m), C_unfix(s)))
 #define C_test_access(fn, m) C_fix(access((char *)C_data_pointer(fn), C_unfix(m)))
 #define C_close(fd) C_fix(close(C_unfix(fd)))
 #define C_umask(m)  C_fix(umask(C_unfix(m)))
@@ -1286,27 +1285,6 @@ static C_word C_i_fifo_p(C_word name)
 
 (define set-alarm! (foreign-lambda int "C_alarm" int))
 
-(define-foreign-variable _iofbf int "_IOFBF")
-(define-foreign-variable _iolbf int "_IOLBF")
-(define-foreign-variable _ionbf int "_IONBF")
-(define-foreign-variable _bufsiz int "BUFSIZ")
-
-(define set-buffering-mode!
-  (lambda (port mode . size)
-(##sys#check-port port 'set-buffering-mode!)
-(let ([size (if (pair? size) (car size) _bufsiz)]
-	  [mode (case mode
-		  [(#:full) _iofbf]
-		  [(#:line) _iolbf]
-		  [(#:none) _ionbf]
-		  [else (##sys#error 'set-buffering-mode! "invalid buffering-mode" mode port)] ) ] )
-  (##sys#check-fixnum size 'set-buffering-mode!)
-  (when (fx< (if (eq? 'stream (##sys#slot port 7))
-		 (##core#inline "C_setvbuf" port mode size)
-		 -1)
-		 0)
-	(##sys#error 'set-buffering-mode! "cannot set buffering mode" port mode size) ) ) ) )
-
 (define (terminal-port? port)
   (##sys#check-open-port port 'terminal-port?)
   (let ([fp (##sys#peek-unsigned-integer port 0)])
diff --git a/posixwin.scm b/posixwin.scm
index b6c6ff0b..2e0819ac 100644
--- a/posixwin.scm
+++ b/posixwin.scm
@@ -

Re: [Chicken-hackers] [PATCH] Fix record type tags to be nonglobal by module-prefixing them

[Peter Bex]

On Tue, Jul 18, 2017 at 09:55:21AM +1200, Evan Hanson wrote:
> Thanks Peter, I've applied this as it is. I agree with Lemon that we
> should dry up the repeated naming logic, but for now I think we can live
> with the duplication in order to keep things moving.
> 
> The patch wasn't quite careful enough with regards to bootstrapping,
> however, and caused some problems with our use of `define-record-type`
> within core. I've added some compatibility shims where necessary to
> allow us to continue bootstrapping from the chicken-5 branch. These can
> be removed after another snapshot release.

Good catch, thanks!

> Regarding whether to namespace the core record types, I think we
> probably _should_ do so, but it's not a priority. My attitude towards
> wrapping the tags in a record type is similar; I'd be fine with that,
> but I also don't see a real need for it, so until there's a clear
> benefit to doing so or a lot of time to spare let's leave it alone.

After some thought, I believe we should do this before the release.
Given that the identifier is defined and therefore user-visible, having
it as an opaque object makes it easier to later add more stuff to it.
For example, we could add introspection information in there, that allows
things like SLIME to get the available slot names.  If people start to
rely on it being a symbol this will make things harder later on.

> I do think we should make the default record printer omit the namespace
> part of the tag, though, so that records continue to be printed as
> "#" and not "#". I'll post something for this later in the
> week, unless anyone else is keen.

I'm not sure that's even needed.  This makes clear that it's the foo
defined by the abc module, so it gives more information than just "#".

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Minor lfa2 improvements wrt ffi arguments

[Peter Bex]

On Mon, Jul 17, 2017 at 09:06:15AM +0200, Peter Bex wrote:
> On Mon, Jul 17, 2017 at 12:08:04PM +1200, Evan Hanson wrote:
> > I suppose now would be a good time to discuss whether we should (1) add
> > any warnings to this pass, for example when one of these FFI arguments
> > is known to have the wrong type, and (2) try to enable the pass for
> > optimization levels < 5, as both lfa2 and clustering are disabled with
> > "XXX" annotations in chicken.scm. Thoughts?
> 
> I think this makes sense.  I suppose they were commented out initially
> because the new passes might break things, but they've been in there for
> many years now.  I'd prefer we add them all to -O3 and higher for now.
> Then, if they cause no problems we can move them up to -O2 and perhaps
> -O1 if we're feeling confident enough.

Also, should we wait until 5.1 with this?  Considering we've made so
many changes already, it makes sense to let things settle before enabling
these optimizations.  That way, if stuff breaks we have less places to
look for potential reasons.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Minor lfa2 improvements wrt ffi arguments

[Peter Bex]

On Mon, Jul 17, 2017 at 12:08:04PM +1200, Evan Hanson wrote:
> Thanks folks, this is a very nice improvement.
> 
> I've applied a combination of these two patches that includes the
> C_i_foreign_integer_argumentp case but leaves the fallback behaviour
> alone. As Lemon says, this pass doesn't do unions so we can't "reduce"
> r1 and instead just pass it through.
> 
> I suppose now would be a good time to discuss whether we should (1) add
> any warnings to this pass, for example when one of these FFI arguments
> is known to have the wrong type, and (2) try to enable the pass for
> optimization levels < 5, as both lfa2 and clustering are disabled with
> "XXX" annotations in chicken.scm. Thoughts?

I think this makes sense.  I suppose they were commented out initially
because the new passes might break things, but they've been in there for
many years now.  I'd prefer we add them all to -O3 and higher for now.
Then, if they cause no problems we can move them up to -O2 and perhaps
-O1 if we're feeling confident enough.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Fix record type tags to be nonglobal by module-prefixing them

[Peter Bex]

On Sat, Jul 15, 2017 at 03:48:54PM +0200, lemonboy wrote:
> On 14 Jul, Peter Bex wrote:
> > Hi all,
> > 
> > A long time ago, we had a patch that tried to prefix the current module
> > name onto a record type's tag (727b2b3fea271474540f215af4842d32e82e7e6d).
> > 
> Awesome news!
> 
> A minor nit: the whole module-prefixing dance is repeated three times in this
> patch alone, I think it'd be better to reuse the existing but hidden
> module-rename: an helper function module-rename/mod that takes a symbol name 
> and
> a module (remember that module-name isn't exported) would clear the code a bit
> and I'd also need that for another patch :)

I agree that would be cleaner, but I didn't want to make this patch
dependent on a huge other huge change regarding the "chicken.module"
module.

> > There are two remaining questions:
> > - Should the core record types like "promise", "thread" and so on be
> >tagged with a module prefix?  I think it's fine to keep them the
> >way they are.
> Why not? If having clear and separate namespaces is the end goal I don't see 
> why
> the core should be exempt (besides the fact that the types.db diff is going to
> be huge!)

Not everything has been namespaced yet, and some objects are created in
various places so might not have a single "home".  Also, it's a lot of
work to do, which we can always do later in 5.1.  Remember, we want 5.0
to be finished this century ;)

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix record type tags to be nonglobal by module-prefixing them

[Peter Bex]

Hi all,

A long time ago, we had a patch that tried to prefix the current module
name onto a record type's tag (727b2b3fea271474540f215af4842d32e82e7e6d).
This was reverted later on because it turned out to be somewhat
incompatible with various things, like the record-variants egg.

I think this is quite an important change which we should try to get
in for CHICKEN 5 again, because it's a change that changes fundamentally
how record types are tagged.  I believe record-variants can be fixed
if we also fix #1342 by defining the "type name" which you pass to
define-record-type as an identifier.

So (define-record foo a) defines foo?, make-foo, foo-a, foo-a-set!, but
also just foo.  This is apparently a requirement of SRFI-99 and R7RS
anyway, and it should also help us to access the tag in record-variants.

The attached patch is a fairly straightforward re-application of 727b2b3,
with a slightly ore extensive test suite.  It also adds the definition
of the identifier like I mentioned before.

I'd add a patch for record-variants, but I see we have no port to
CHICKEN 5 for it yet.  In any case, instead of quoting the type name,
it would simply be used unquoted, as that's the identifier which holds
the tag.  I don't know exactly what the problem with coops was, but I
presume it was either caused by record-variants not working or we can
fix it in a similar way by using the record identifier instead of the
quoted tag.

There are two remaining questions:
- Should the core record types like "promise", "thread" and so on be
   tagged with a module prefix?  I think it's fine to keep them the
   way they are.
- Should the identifier be bound to the raw tag, or should it be wrapped
   in some kind of opaque object (perhaps a "record type" record type)?
   Personally, I think it's probably better (and also less confusing to
   the user) to wrap it, but that's a slightly larger change which can
   go in later, so I decided to keep this patch simple.

Cheers,
Peter
From 3bd2f845d9efa342bc656de35eb30163d9f1417f Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Fri, 14 Jul 2017 13:51:24 +0200
Subject: [PATCH] Get rid of "global namespace" for record types.

Before, when define-record-type or define-record were used, the name
that's passed in is taken directly as the tag.  Therefore, if two
completely unrelated modules define a record type (with a completely
different layout), both predicates would accept eachother's record
objects.  Worse, if an accessor was used on one of them this could
be an unsafe operation resulting in segfaults and other Bad Things.

This restores "applied zbigniew's record-rename patch (finally), added
test-case", which is 727b2b3fea271474540f215af4842d32e82e7e6d.
Thereby, we revert commit 045524a45217ff1eed79a73190d61c561999fba5.

Furthermore, we now expose the "type name" as an identifier which is
bound to the value of the type tag stored in the record.  This is a
requirement of both SRFI-99 and R7RS (see #1342), and ensures we can
access the tag of a record type defined in another module.  This is
useful for the record-variants egg; it extends existing/predefined
record types with new behaviour, but to do so it needs to be able to
know what the tag is even if the record was defined in another module.
---
 NEWS |  5 
 chicken-syntax.scm   | 61 
 distribution/manifest|  1 +
 tests/record-rename-test.scm | 50 
 tests/runtests.bat   |  4 +++
 tests/runtests.sh|  3 +++
 6 files changed, 107 insertions(+), 17 deletions(-)
 create mode 100644 tests/record-rename-test.scm

diff --git a/NEWS b/NEWS
index 5db0be65..54d1b404 100644
--- a/NEWS
+++ b/NEWS
@@ -62,6 +62,11 @@
 undocumented and not officially supported anyway.
   - define and friends are now aggressively rejected in "expression
 contexts" (i.e., anywhere but toplevel or as internal defines).
+  - define-record and define-record-type now create record types
+which are tagged with the module in which they're defined, so
+predicates no longer return #t for records with the same tag
+defined in another module.  This tag is now also available under
+an identifier that matches the record type name (fixes #1342).
 
 - Eggs management
   - Egg-installation and building has been completely overhauled.
diff --git a/chicken-syntax.scm b/chicken-syntax.scm
index 7a461726..0f95cd38 100644
--- a/chicken-syntax.scm
+++ b/chicken-syntax.scm
@@ -124,9 +124,14 @@
  (##sys#er-transformer
   (lambda (x r c)
 (##sys#check-syntax 'define-record x '(_ symbol . _))
-(let* ((name (cadr x))
+(let* ((type-name (cadr x))
+	   (plain-name (strip-syntax type-name))
+	   (prefix (symbol->string plain-name))
+	   (tag (if (##sys#current-module)
+		

Re: [Chicken-hackers] [PATCH][5] Minor lfa2 improvements wrt ffi arguments

[Peter Bex]

On Fri, Jul 14, 2017 at 01:02:45PM +0200, Peter Bex wrote:
> However, if the derived type is, say (or char fixnum), and we find that
> the predicate C_i_foreign_fixnum_argumentp is used, the final type will
> most definitely _not_ be (or char fixnum), but fixnum (or an error occurs).

Better would be to merge the types so we actually get fixnum as the type.
But doing so would require lfa2 to drag in the scrutinizer's complexity,
while the whole idea of LFA2 is to be a very lightweight final pass.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Minor lfa2 improvements wrt ffi arguments

[Peter Bex]

On Wed, Jul 05, 2017 at 01:50:58PM +0200, lemonboy wrote:
> Hello hackers,
> here's a small patch that instructs the lfa2 pass how to get rid of some type
> checks on the arguments passed to the ffi stubs when we can safely recover the
> argument types at compile time.

Hi Lemonboy,

The basic idea of the patch is very good.  I think there's one small
mistake: if the node isn't replaced by the object, you still return
the derived type r1, on the grounds that the check is enforcing.

However, if the derived type is, say (or char fixnum), and we find that
the predicate C_i_foreign_fixnum_argumentp is used, the final type will
most definitely _not_ be (or char fixnum), but fixnum (or an error occurs).

Attached is a signed off copy of your patch with three changes:
- I also added C_i_foreign_integer_argumentp
- The returned type is r1 if we performed the rewrite, otherwise it will
   be (or ...) where the ... is all the types that the predicate checks.
- I've clarified in the commit message why we can't replace the ranged
   integer FFI checks.

Ideally we'd add some tests for the LFA2 pass, but I think that's very
tricky to do, and the number of cases is too large.

Cheers,
Peter
From e5625725f99c80387d05950b2758d424a4a7dca2 Mon Sep 17 00:00:00 2001
From: LemonBoy 
Date: Wed, 5 Jul 2017 13:29:23 +0200
Subject: [PATCH] Elide pointless type checks in the lfa2 pass

Some (but not all!) C_i_foreign_*_argumentp functions can be safely
elided if we can prove the arguments have the correct type.
All ranged integer checks can't be removed because the type system
currently does not represent any range info.

Signed-off-by: Peter Bex 
---
 lfa2.scm | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/lfa2.scm b/lfa2.scm
index e53ffe37..8cdcb728 100644
--- a/lfa2.scm
+++ b/lfa2.scm
@@ -117,6 +117,15 @@
 ("C_i_portp" port)
 ("C_i_nullp" null)))
 
+;; Maps foreign type checks to types
+
+(define +ffi-type-check-map+
+  '(("C_i_foreign_fixnum_argumentp" fixnum)
+("C_i_foreign_integer_argumentp" integer fixnum bignum)
+("C_i_foreign_char_argumentp" char)
+("C_i_foreign_flonum_argumentp" flonum)
+("C_i_foreign_string_argumentp" string)
+("C_i_foreign_symbol_argumentp" symbol)))
 
 ;; Maps constructors to types
 
@@ -313,6 +322,24 @@
 			((member r1 (cdr a))
 			 (extinguish! n "C_i_noop")))
 		  '*)))
+		 ((assoc (first params) +ffi-type-check-map+) =>
+		  (lambda (a)
+		(let ((arg (first subs))
+			  (r1 (walk (first subs) te ae)))
+		  (cond
+		   ((member r1 (cdr a))
+			;; The ffi checks return the object, so we can
+			;; replace the check with the bare object.
+			(node-class-set! n (node-class arg))
+			(node-parameters-set! n (node-parameters arg))
+			(node-subexpressions-set! n (node-subexpressions arg))
+			;; The final type is as derived
+			r1)
+		   (else
+			;; The ffi checks are enforcing so we always
+			;; end up with the correct type, even if we
+			;; didn't rewrite the node.
+			(cons 'or (cdr a)))
 		 ((assoc (first params) +predicate-map+) =>
 		  (lambda (a)
 		(let ((arg (first subs)))
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] The other part of the FFI improvements

[Peter Bex]

On Mon, Jul 10, 2017 at 01:48:27PM +0200, lemonboy wrote:
> On 10 Jul, Peter Bex wrote:
> > I'm a bit concerned about the patch itself though.  For one, in the interest
> > of modularity and code layout, I think all type annotations on variables
> > should _only_ be made by the scrutinizer.  It's the scrutinizer's job to
> > assign types, not anything else's.
> > 
> We have to translate the ffi types into something the scrutinizer understands
> and we have to do that somewhere. Building ##core#the expression during the
> expansion proved to be a not-so-wise choice so I thought that producing the 
> type
> annotation when the stub itself is brought to life was a sensible choice.

Sure, this is a fine place to determine the foreign types.  It might even
be the right place to convert those foreign types to CHICKEN types, but
IMO only the scrutinizer should be putting that property on the stub-id
symbol, so that part is iffy.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] The other part of the FFI improvements

[Peter Bex]

On Mon, Jul 03, 2017 at 05:22:26PM +0200, lemonboy wrote:
> This patch offloads all the heavy lifting to the scrutinizer, most of it is 
> just
> boilerplate (that I hope I've got right) to introduce a new node to the core
> language named ##core#invoke (the name is up for discussion of course).
> The node serves as a simple way to represent the call of a ffi stub and it is 
> a
> nice mixture of ##core#call, ##core#primitive and ##core#inline that's easy to
> analyze during the scrutiny phase and is desugared into simpler code later in
> the pipeline.

Hi Lemonboy,

For the benefit of those not on IRC, I'll recap my comments from yesterday.

The patch's functionality is something that's definitely desirable, and many
thanks for actually putting in the effort after my off-hand comments about
how to improve this!

I'm a bit concerned about the patch itself though.  For one, in the interest
of modularity and code layout, I think all type annotations on variables
should _only_ be made by the scrutinizer.  It's the scrutinizer's job to
assign types, not anything else's.

There's of course the fact that the FFI knows the foreign types, and I think
it's fine to decorate the node tree with foreign types, or perhaps add a
node that contains the type (somehow use ##core#the in this situation?),
but straight up annotating the stub symbol with the types is not done, IMHO.
Having the foreign types in the node tree might even help us get rid of
some attributes in the ffi stubs table (though that's not really a goal).

The other thing I think may cause some headache in the future is the fact
that in the scrutinizer, ##core#invoke will cause a temporary ##core#call to
be faked out in order to leverage the existing code.  This is (potentially)
problematic, because everywhere else in the compiler, nodes are treated as
"final", and may be mutated at will.  By creating a throwaway temporary
node, this will cause any mutations on the node to be thrown away.

I think a proper solution will probably involve some pretty large
refactoring of either ##core#call (so the code can be re-used by
##core#invoke), or a refactoring of ##core#inline/##core#primitive
so that it becomes more "like" a ##core#call node and can contain
type information.

Given that this is a non-user visible change (at least, API-wise),
perhaps we should shelve this feature for 5.1?  It's not that important
of a change, and we have enough other things to worry about.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Simplify forwarding pointer wrapping and unwrapping

[Peter Bex]

Hi all,

While looking at the GC bug I already posted a patch for, I noticed that
forwarding pointers are constructed in a bit of a roundabout way, and
this could be simplified purely for readability reasons.

I tested the attached patch on x86_64 as well as 32-bit PowerPC and
nothing breaks.  Unfortunately, it doesn't make any difference in
performance - I had hoped GCs would be sped up a bit due to less
instructions being needed to create the forwarding pointers.

In case you're wondering if there's a reason for why it's done in the
way it's done, we can check the original commit in which it changed
from a simple setting of the top bit to the current code:

cvs -d:pserver:anonymous:@cvs.sv.nongnu.org:/cvsroot/chicken rlog -r1.55 
chicken/runtime.c 
cvs -d:pserver:anonymous:@cvs.sv.nongnu.org:/cvsroot/chicken rdiff -r1.55 
chicken/runtime.c 

I also added a comment to the code to (hopefully) clarify what's going
on in these macros.

Cheers,
Peter
From 4100803abea8dd1b4e9481e67ee060b5442fc9f5 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Fri, 30 Jun 2017 21:39:04 +0200
Subject: [PATCH] Simplify forwarding pointer wrapping/unwrapping

The original version would take the high bit and put it in the low
bit, clobbering what was there.  That's okay because pointers are
word-aligned so they won't have their lowest bit set anyway.

Then the high bit would be set to mark the header as a forwarding
pointer.  But a much simpler way of achieving the same is to simply
shift right by one and set the high bit.
---
 runtime.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/runtime.c b/runtime.c
index 64020e24..f35d30c1 100644
--- a/runtime.c
+++ b/runtime.c
@@ -193,7 +193,6 @@ static C_TLS int timezone;
 /* Constants: */
 
 #ifdef C_SIXTY_FOUR
-# define FORWARDING_BIT_SHIFT  63
 # ifdef C_LLP
 #  define ALIGNMENT_HOLE_MARKER ((C_word)0xfffeLL)
 #  define UWORD_FORMAT_STRING   "0x%016llx"
@@ -205,7 +204,6 @@ static C_TLS int timezone;
 # endif
 #else
 # define ALIGNMENT_HOLE_MARKER ((C_word)0xfffe)
-# define FORWARDING_BIT_SHIFT  31
 # define UWORD_FORMAT_STRING   "0x%08x"
 # define UWORD_COUNT_FORMAT_STRING "%u"
 #endif
@@ -242,9 +240,13 @@ static C_TLS int timezone;
 #define C_uhword_set(x, p, d)(C_uhword_ref(x,p) = (d))
 
 #define free_tmp_bignum(b)   C_free((void *)(b))
+
+/* Forwarding pointers abuse the fact that objects must be
+ * word-aligned, so we can just drop the lowest bit.
+ */
 #define is_fptr(x)   (((x) & C_GC_FORWARDING_BIT) != 0)
-#define ptr_to_fptr(x)   x) >> FORWARDING_BIT_SHIFT) & 1) | C_GC_FORWARDING_BIT | ((x) & ~1))
-#define fptr_to_ptr(x)   (((C_uword)(x) << FORWARDING_BIT_SHIFT) | ((x) & ~(C_GC_FORWARDING_BIT | 1)))
+#define ptr_to_fptr(x)   (((C_uword)(x) >> 1) | C_GC_FORWARDING_BIT)
+#define fptr_to_ptr(x)   ((C_uword)(x) << 1)
 
 #define C_check_real(x, w, v)   if(((x) & C_FIXNUM_BIT) != 0) v = C_unfix(x); \
  else if(C_immediatep(x) || C_block_header(x) != C_FLONUM_TAG) \
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Move some low-hanging fruit from posix.scm to file.scm

[Peter Bex]

On Sun, Jul 02, 2017 at 12:20:45PM +1200, Evan Hanson wrote:
> I think it should stay in irregex. Glob patterns are generally useful,
> and the procedure actually returns a regexp or SRE, so making it part of
> the library that deals with those data types makes sense to me.
> 
> In fact, if we're going to expose it, I think it would be best to drop
> the flag that changes its return type and make the procedure *always*
> return an SRE. This is more flexible, matches the existing conversion
> procedures like "string->sre" nicely, and the other behaviour is just
> one `irregex` call away. Here's a patch that does this, let me know what
> you think.

Excellent, I've pushed this.

BTW, I did notice a small but annoying problem: When I ran "make check",
I got an error on test-glob.scm that glob->sre wasn't defined.  Turns out
that there is still an issue with csi and library loading; after
"make install" the tests ran fine, so it was due to the irregex library
being loaded from the installed location rather than the source dir.
I'm not quite sure how to fix that.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix small but critical bug in symbol GC sanity checks and fix randomization of symbol table (security fix)

[Peter Bex]

Hi all,

The first attached patch fixes a problem with an assertion error
that sometimes crops up during symbol GC.  The problem is that the
C_persistable_symbol() check says that the bound value of a
symbol must be either C_SCHEME_UNBOUND or the symbol itself.

However, during GC a keyword may get moved around, so the
symbol's value slot might contain a forwarding pointer to its
own new location.  Then, C_symbol_value(s) != s, so it will
think the keyword should have been persisted and trigger the
assertion.  The patch also moves the forwarding pointer chasing
for symbols to a helper function.

Many thanks to Mario and Kooda for reporting this issue and
TheLemonMan for putting in the effort to make it reproducible
by hacking rand() to always return a given value, and for
pointing out that symbol_table->rand always had the same
value.

The second patch fixes this fixed value problem: we called
initialize_symbol_table() which uses rand(), *before* calling
C_randomize(), so the randomization factor wouldn't be initialized
properly, or rather have an undefined value which happens to be a
fixed value on most platforms.  I think this second patch should
also go into master (it applies cleanly).

Cheers,
Peter
From cb0e9e86609c837e02957dd8132b64d83506b15a Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Fri, 30 Jun 2017 15:28:08 +0200
Subject: [PATCH 1/2] Fix unpersistability sanity check for symbol GC

The sanity check we do just before dropping symbols from the symbol
table will ensure that the "bound value" slot of a symbol is either
empty or contains the symbol itself.  If either is violated, the
assertion check fails.

This is correct, but keywords may have been moved by the GC and
replaced with forwarding pointers.  This means the symbol value slot
could contain a forwarding pointer, which is definitely _not_ equal to
the symbol itself.

To fix this, before performing our sanity checks, we now fix up any
forwarding pointers in the symbol's value.
---
 runtime.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/runtime.c b/runtime.c
index 64020e24..311a1be7 100644
--- a/runtime.c
+++ b/runtime.c
@@ -4132,6 +4132,25 @@ C_regparm void C_fcall update_locative_table(int mode)
   if(mode != GC_REALLOC) locative_table_count = hi;
 }
 
+static C_regparm void fixup_symbol_forwards(C_word sym)
+{
+  C_word val, h;
+  int i, s = C_header_size(sym); /* 3 */
+
+  for (i = 0; i < s; i++) {
+val = C_block_item(sym, i);
+if (!C_immediatep(val)) {
+  h = C_block_header(val);
+
+  while(is_fptr(h)) {
+val = fptr_to_ptr(h);
+h = C_block_header(val);
+  }
+  C_set_block_item(sym, i, val);
+}
+  }
+}
+
 C_regparm void C_fcall update_symbol_tables(int mode)
 {
   int weakn = 0, i;
@@ -4159,17 +4178,11 @@ C_regparm void C_fcall update_symbol_tables(int mode)
 
 #ifdef DEBUGBUILD
 /* Detect inconsistencies before dropping / keeping the symbol */
+fixup_symbol_forwards(sym);
 	{
 	  C_word str = C_symbol_name(sym);
   int str_perm;
 
-	  h = C_block_header(str);
-
-	  while(is_fptr(h)) {
-	str = fptr_to_ptr(h);
-	h = C_block_header(str);
-	  }
-
   str_perm = !C_in_stackp(str) && !C_in_heapp(str) &&
   !C_in_scratchspacep(str) &&
   (mode == GC_REALLOC ? !C_in_new_heapp(str) : 1);
@@ -4196,7 +4209,10 @@ C_regparm void C_fcall update_symbol_tables(int mode)
 	  if(last) C_set_block_item(last, 1, C_block_item(bucket,1));
 	  else stp->table[ i ] = C_block_item(bucket,1);
 
+#ifndef NDEBUG
+  fixup_symbol_forwards(sym);
 	  assert(!C_persistable_symbol(sym));
+#endif
 	  ++weakn;
 	} else {
 	  C_set_block_item(bucket,0,sym); /* Might have moved */
-- 
2.11.0

From ae2633195cc5f4f61c9da4ac90f0c14c010dcc3d Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Fri, 30 Jun 2017 15:39:45 +0200
Subject: [PATCH 2/2] Initialize symbol table after setting up randomization

Otherwise, the symbol table wouldn't be correctly randomized.
---
 NEWS  | 3 +++
 runtime.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index f4b0e041..6588b30e 100644
--- a/NEWS
+++ b/NEWS
@@ -96,6 +96,9 @@
 buffer overrun and/or segfault (thanks to Lemonboy).
   - CVE-2017-9334: `length' no longer crashes on improper lists (fixes
 #1375, thanks to "megane").
+  - The randomization factor of the symbol table was set before
+the random seed was set, causing it to have a fixed value on many
+platforms.
 
 - Core Libraries
   - Unit "posix": If file-lock, file-lock/blocking or file-unlock are
diff --git a/runtime.c b/runtime.c
index 81c54dd2..a4580abc 100644
--- a/runtime.c
+++ b/runtime.c
@@ -799,7 +799,6 @@ int CHICKEN_initialize(int heap, int stack, int symbols, void *toplevel)
   C_initial_timer_interrupt_period = INITIAL_TIMER_INTERRUPT_PERIOD;
   C_timer_inter

[Chicken-hackers] [PATCH] Finish (chicken load) module

[Peter Bex]

Hi all,

Now that we have the "namespaced identifier" support, we can finish
the (chicken load) module by not exporting load from it.  I've also
removed load-extension, because that's really just a one-argument
alias for `require', and it's confusing/redundant to have both, which
is probably why we reomved it from c-l-r.

Note that I had to add (import scheme) to module.scm, which isn't
wrapped in a module yet, because otherwise I'd get an error about
`load' not being defined.  This shouldn't be necessary, but probably
has to do with how the bootstrapping CHICKEN's chicken.load does
export `load' while the CHICKEN being built doesn't?  If someone
can explain to me exactly how it works, please do!

Cheers,
Peter
From eb806b43006940ad03a829a3def34ebb3f874450 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 25 Jun 2017 16:01:59 +0200
Subject: [PATCH] Finalize (chicken load) by hiding `load' and `load-extension'

`load-extension' was deprecated in favor of `require'. `load' must be
exported by scheme, and it makes no sense to export it in two modules
so we do not export it from (chicken load).

This also adds those type database entries which were missing for the
remaining exported procedures in (chicken load).
---
 chicken.import.scm |  1 -
 core.scm   |  2 +-
 eval.scm   | 39 ---
 modules.scm|  3 ++-
 types.db   |  5 -
 5 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/chicken.import.scm b/chicken.import.scm
index 8a5f28f8..7b0600a4 100644
--- a/chicken.import.scm
+++ b/chicken.import.scm
@@ -127,7 +127,6 @@
(installation-repository . chicken.platform#installation-repository)
(ir-macro-transformer . chicken.syntax#ir-macro-transformer)
keyword-style
-   (load-extension . chicken.load#load-extension)
(load-library . chicken.load#load-library)
(load-noisily . chicken.load#load-noisily)
(load-relative . chicken.load#load-relative)
diff --git a/core.scm b/core.scm
index c2632cd4..54c34b41 100644
--- a/core.scm
+++ b/core.scm
@@ -693,7 +693,7 @@
 			   ,(walk (caddr x) e se dest ldest h ln #f)))
 
 			((##core#require-for-syntax)
-			 (load-extension (cadr x))
+			 (require (cadr x))
 			 '(##core#undefined))
 
 			((##core#require)
diff --git a/eval.scm b/eval.scm
index 772d0fb0..e86d2e58 100644
--- a/eval.scm
+++ b/eval.scm
@@ -584,7 +584,7 @@
 
 			 [(##core#require-for-syntax)
 			  (let ((id (cadr x)))
-			(chicken.load#load-extension id)
+			(chicken.load#require id)
 			(compile '(##core#undefined)
 			 e #f tf cntr se #f))]
 
@@ -876,9 +876,9 @@
 
 
 (module chicken.load
-  (dynamic-load-libraries
-   load load-extension load-library load-noisily load-relative load-verbose
-   provide provided? require set-dynamic-load-mode!)
+  (dynamic-load-libraries set-dynamic-load-mode!
+   load-library load-noisily load-relative load-verbose
+   provide provided? require)
 
 (import (except scheme load)
 	chicken
@@ -1098,13 +1098,14 @@
 		(close-input-port in
   (##core#undefined
 
-(define (load filename . evaluator)
-  (load/internal filename (optional evaluator #f)))
+;; Exported by "scheme", so use full name to avoid exporting it here.
+;; TODO: Maybe change this later to (set! scheme#load (lambda ..))
+(define (chicken.load#load filename #!optional evaluator)
+  (load/internal filename evaluator))
 
-(define (load-relative filename . evaluator)
-  (load/internal
-   (make-relative-pathname ##sys#current-load-filename filename)
-   (optional evaluator #f)))
+(define (load-relative filename #!optional evaluator)
+  (let ((fn (make-relative-pathname ##sys#current-load-filename filename)))
+(load/internal fn evaluator)))
 
 (define (load-noisily filename #!key (evaluator #f) (time #f) (printer #f))
   (load/internal filename evaluator #t time printer))
@@ -1258,7 +1259,7 @@
 		 (or (check pa)
 		 (loop (##sys#slot paths 1)) ) ) ) ) ) ) ))
 
-(define (load-extension/internal id alternates loc)
+(define (chicken.load#load-extension id alternates loc)
   (cond ((##sys#provided? id))
 	((any ##sys#provided? alternates))
 	((memq id core-units)
@@ -1270,17 +1271,9 @@
 	(else
 	 (##sys#error loc "cannot load extension" id
 
-(define (##sys#load-extension id #!optional (alternates '()) loc)
-  (load-extension/internal id alternates loc)
-  (##core#undefined))
-
-(define (load-extension id)
-  (##sys#check-symbol id 'load-extension)
-  (##sys#load-extension id '() 'load-extension))
-
 (define (require . ids)
   (for-each (cut ##sys#check-symbol <> 'require) ids)
-  (for-each (cut ##sys#load-extension <> '() 'require) ids))
+  (for-each (cut chicken.load#load-extension <> '() 'require) ids))
 
 (define (provide . ids)
   (for-each (cut ##sys#check-symbol <> 'provide)

Re: [Chicken-hackers] [PATCH 3/3] Fix repository searching for "-link" flag and associated tests

[Peter Bex]

On Wed, Jun 21, 2017 at 12:01:48PM +1200, Evan Hanson wrote:
> On 2017-06-20 13:11, felix.winkelm...@bevuta.com wrote:
> > You seem to drop the reference to "destination-repository". Are you sure 
> > this is
> > right in the face of cross-compilation?
> 
> I think so. Or rather, this patch makes "-link" behave like "normal"
> compilation in that it respects CHICKEN_REPOSITORY_PATH and the
> "repository-path" parameter, which is what we want, I think. Previously,
> it would ignore those values and go straight to the target repo, so
> something/lib/chicken/9, since the "destination-repository" helper
> doesn't seem to consider C_R_P at all. I might be missing something,
> though. How is C_R_P intended to behave when cross-compiling?

I've pushed the first two patches, as they're obviously correct (we've
applied them before).  I don't quite understand how dropping the
destination-repository host/target selection will impact cross-
compilation.  Felix, can you answer Evan's question and perhaps
review the third patch?

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix result size calculation for enums, resulting in crash (maybe related to #1377?)

[Peter Bex]

Hi all,

I decided to investigate #1377, and while I wasn't able to reproduce it
yet, on 32 bits GNU Hurd I got a segfault due to there being no result
size calculation for "enum" foreign types.  I discovered that if the type
is unknown, the result size is assumed to be zero, so the generate C stub
function receives C_SCHEME_UNDEFINED as a "buffer" (see core.scm:1815).

This is obviously not big enough to hold a bignum that might be returned
from an enum on 32-bit systems, thus we're scribbling into unmapped
memory.

This *might* be the fix for #1377, but I don't think it is, since it
should print "Good, unrepresentable C strings cause errors", before
testing all the FFI conversions.  Nevertheless, the attached patch is
pretty crucial I think.

The patch converts the assumption of 0 size for unknown foreign types
in estimate-foreign-result-size to an error, much like the code in
estimate-foreign-result-location-size already did.  I don't know why
they weren't the same, so beware that this patch may break things.

And finally, this patch also converts the foreign type "(enum x)" into
an "integer" scrutiny type.  Before it would just use "number", but
we know it must be an integer rather than, say, a ratnum, cplxnum or
flonum, so let's use that knowledge.

Cheers,
Peter
From a7bd09a7b014547a9c85653adfc90efc4d1a0af1 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Mon, 19 Jun 2017 15:01:14 +0200
Subject: [PATCH] Add foreign result size computation for enums and enum
 locations

Also, error out instead of assuming 0 size when encountering an
unknown type, because that is too dangerous an assumption.

Finally, we improve the scrutiny type of "enum" to be "integer" rather
than the nondescript "number".
---
 support.scm | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/support.scm b/support.scm
index 233ad961..a9d67ed9 100644
--- a/support.scm
+++ b/support.scm
@@ -1144,6 +1144,8 @@
 ;;; Compute foreign result size:
 
 (define (estimate-foreign-result-size type)
+  (define (err t)
+(quit-compiling "cannot compute size for unknown foreign type `~S' result" type))
   (follow-without-loop
type
(lambda (t next)
@@ -1168,8 +1170,9 @@
 	   (case (car t)
 		 ((ref nonnull-pointer pointer c-pointer nonnull-c-pointer function instance instance-ref nonnull-instance) 
 		  (words->bytes 3) )
-		 (else 0) ) )
-	  (else 0) ) ) ) )
+		 ((enum) (words->bytes 6)) ; 1 bignum digit on 32-bit (overallocs on 64-bit)
+		 (else (err t)) ) )
+	  (else (err t)) ) ) ) )
(lambda () (quit-compiling "foreign type `~S' refers to itself" type)) ) )
 
 (define (estimate-foreign-result-location-size type) ; Used only in compiler.scm
@@ -1179,8 +1182,8 @@
type
(lambda (t next)
  (case t
-   ((char int short bool unsigned-short unsigned-char unsigned-int long unsigned-long byte unsigned-byte
-	  c-pointer nonnull-c-pointer unsigned-integer integer float c-string symbol
+   ((char int short bool unsigned-short unsigned-char unsigned-int long unsigned-long byte
+	  unsigned-byte c-pointer nonnull-c-pointer unsigned-integer integer float c-string symbol
 	  scheme-pointer nonnull-scheme-pointer int32 unsigned-int32 integer32 unsigned-integer32
   unsigned-c-string unsigned-c-string* nonnull-unsigned-c-string*
 	  nonnull-c-string c-string* nonnull-c-string* c-string-list c-string-list*)
@@ -1193,7 +1196,7 @@
 	  ((pair? t)
 	   (case (car t)
 		 ((ref nonnull-pointer pointer c-pointer nonnull-c-pointer function
-		   scheme-pointer nonnull-scheme-pointer)
+		   scheme-pointer nonnull-scheme-pointer enum)
 		  (words->bytes 1))
 		 (else (err t)) ) )
 	  (else (err t)) ) ) ) )
@@ -1293,7 +1296,7 @@
 		((ref pointer function c-pointer)
 		 '(or boolean pointer locative))
 		((const) (foreign-type->scrutiny-type (cadr t) mode))
-		((enum) 'number)
+		((enum) 'integer)
 		((nonnull-pointer nonnull-c-pointer) 'pointer)
 		(else '*)))
 	 (else '*))
-- 
2.11.0



signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] rename (chicken expand) module to (chicken syntax) [was: Re: [PATCH] Drop now-unnecessary exports from the "chicken.export" module]

[Peter Bex]

On Sat, Jun 17, 2017 at 07:21:30PM +0200, felix.winkelm...@bevuta.com wrote:
> > I'd also like to hear what the other core members think.
> 
> (chicken syntax), and keep expand.scm. Don't overdo it.

The attached patch makes it so.

Cheers,
Peter
From 828ad1e73c0476411088f916a619a372a5db7382 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 18 Jun 2017 19:24:50 +0200
Subject: [PATCH] Rename (chicken expand) to (chicken syntax)

This adds a small hack to the chicken.import.scm import library to
define chicken.syntax#er-macro-transformer and friends as aliases for
their chicken.expand# version, if those are defined.

This is required when building the new chicken with an old one,
because the old compiler will load "chicken.import.scm", but the name
mappings aren't right for anything that happens at expansion time if
there are no definition from the chicken.syntax module inside that
compiler's libchicken.

We also make some internal definitions in expand.scm explicit, namely
match-expression and expand-curried-define.  This happened to work
because the macros that use these definitions live inside the same
unit of compilation.  If we were to move them, things would
mysteriously start breaking.
---
 README   |  2 +-
 chicken-ffi-syntax.scm   | 24 
 chicken-syntax.scm   | 46 +++---
 chicken.import.scm   | 21 +++--
 core.scm |  8 
 csi.scm  |  3 ++-
 defaults.make|  4 ++--
 distribution/manifest|  4 ++--
 eval.scm |  4 ++--
 expand.scm   | 43 ++-
 irregex.scm  |  4 +++-
 modules.scm  |  8 
 rules.make   | 25 +
 scrutinizer.scm  |  4 ++--
 srfi-4.scm   |  4 ++--
 support.scm  |  2 +-
 tests/compiler-tests.scm |  2 +-
 types.db | 30 +++---
 18 files changed, 126 insertions(+), 112 deletions(-)

diff --git a/README b/README
index 00eca60e..e8df7e3a 100644
--- a/README
+++ b/README
@@ -292,7 +292,6 @@ _/_/_/_/_/_/  _/_/_/_/_/
 	|   |   |-- chicken.data-structures.import.so
 	|   |   |-- chicken.errno.import.so
 	|   |   |-- chicken.eval.import.so
-	|   |   |-- chicken.expand.import.so
 	|   |   |-- chicken.file.import.so
 	|   |   |-- chicken.file.posix.import.so
 	|   |   |-- chicken.fixnum.import.so
@@ -319,6 +318,7 @@ _/_/_/_/_/_/  _/_/_/_/_/
 	|   |   |-- chicken.random.import.so
 	|   |   |-- chicken.repl.import.so
 	|   |   |-- chicken.read-syntax.import.so
+	|   |   |-- chicken.syntax.import.so
 	|   |   |-- chicken.tcp.import.so
 	|   |   |-- chicken.time.import.so
 	|   |   |-- chicken.time.posix.import.so
diff --git a/chicken-ffi-syntax.scm b/chicken-ffi-syntax.scm
index a825a221..fc9ebbcd 100644
--- a/chicken-ffi-syntax.scm
+++ b/chicken-ffi-syntax.scm
@@ -180,7 +180,7 @@
 		  "bad argument type - not a string or symbol" 
 		  code
 	(##core#the ,(chicken.compiler.support#foreign-type->scrutiny-type
-		  (chicken.expand#strip-syntax (caddr form))
+		  (chicken.syntax#strip-syntax (caddr form))
 		  'result) 
 		#f ,tmp) ) ) ) ) )
 
@@ -221,8 +221,8 @@
   (lambda (form r c)
 (##sys#check-syntax 'foreign-primitive form '(_ _ . _))
 (let* ((hasrtype (and (pair? (cddr form)) (not (string? (caddr form)
-	   (rtype (and hasrtype (chicken.expand#strip-syntax (cadr form
-	   (args (chicken.expand#strip-syntax (if hasrtype (caddr form) (cadr form
+	   (rtype (and hasrtype (chicken.syntax#strip-syntax (cadr form
+	   (args (chicken.syntax#strip-syntax (if hasrtype (caddr form) (cadr form
 	   (argtypes (map car args)))
   `(##core#the (procedure
 		,(map (cut chicken.compiler.support#foreign-type->scrutiny-type <> 'arg)
@@ -241,9 +241,9 @@
 (##sys#check-syntax 'foreign-lambda form '(_ _ _ . _))
 `(##core#the
   (procedure ,(map (cut chicken.compiler.support#foreign-type->scrutiny-type <> 'arg)
-		   (chicken.expand#strip-syntax (cdddr form)))
+		   (chicken.syntax#strip-syntax (cdddr form)))
 		 ,(chicken.compiler.support#foreign-type->scrutiny-type
-		   (chicken.expand#strip-syntax (cadr form)) 'result))
+		   (chicken.syntax#strip-syntax (cadr form)) 'result))
   #f
   (##core#foreign-lambda ,@(cdr form))
 
@@ -258,9 +258,9 @@
 			 (chicken.compiler.support#foreign-type->scrutiny-type
 			  (car a)
 			  'arg))
-			(chicken.expand#strip-syntax (caddr form)))
+			(chicken.syntax#strip-syntax (caddr form)))
 		  ,(chicken.compiler.support#foreign-type->scrutiny-type
-		(chicken.expand#st

Re: [Chicken-hackers] [PATCH 0/1] Move `module-environment' into chicken.eval

[Peter Bex]

On Sat, Jun 17, 2017 at 12:32:19PM +1200, Evan Hanson wrote:
> Let me know what you think. The patch is pretty simple, with the main
> implementation staying in modules.scm (where the module-related
> procedures it needs are defined) but the public version moved to
> eval.scm.

I like this.  Maybe we can just change (define ##sys#eval/meta) to
(define chicken.eval#eval/meta) instead to avoid the ##sys# prefix.
But for now I don't think that's very important.

I pushed the patch.

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 0/1] Add "chicken.module" module

[Peter Bex]

On Sat, Jun 17, 2017 at 12:05:35PM +1200, Evan Hanson wrote:
> Hi all,
> 
> Here's a patch that adds a "chicken.module" module according to some of
> the discussion in the "Add unexport form to modules" thread, and from
> the "undecided" section of c-l-r (which already proposed a lot of the
> same changes, in fact).
> 
> The library is syntax-only and contains CHICKEN's "module language"
> (well, most of it -- it doesn't include `functor` or `define-interface`
> quite yet). It's actually a pretty small change, mostly just reshuffling
> things in expand and capturing the macro environment at the right time.

Looks good to me, pushed!  I've moved (chicken module) up to "decided"
and added a few missing import variants to the list of identifiers.
What's the reason you've only marked functor and define-interface as
TODO and not moved them yet?  Are they problematic somehow?

Cheers,
Peter


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chicken.export" module

[Peter Bex]

On Sat, Jun 17, 2017 at 07:57:25PM +0200, felix.winkelm...@bevuta.com wrote:
> You know what? I don't know. I just realize that too many things are
> changing too much, at too fast a rate. So much that I'm now totally
> confused, which is an indication that perhaps this might be getting
> out of hand... :-)

Regarding the module layout, we haven't changed anything fundamentally
since we decided on http://wiki.call-cc.org/core-libraries-reorganization
way back in September 2015.  So far we've only made a few internal
changes that are necessary to make this library organisation work as
intended, and fixed a few small mistakes and oversights in the details.

> As a minimal suggestion, let's try to keep filenames as they are
> and only change to exported interfaces and module names. Internal
> reorganizations can be done later.

OK, fair enough.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chicken.export" module

[Peter Bex]

On Sat, Jun 17, 2017 at 07:21:30PM +0200, felix.winkelm...@bevuta.com wrote:
> > I'd also like to hear what the other core members think.
> 
> (chicken syntax), and keep expand.scm. Don't overdo it.

Do you mean we rename (chicken expand) to (chicken syntax) in
expand.scm (with perhaps the other macros in (chicken base),
or we keep (chicken expand) and move the other macros into
(chicken syntax)?

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chicken.export" module

[Peter Bex]

On Sat, Jun 17, 2017 at 10:40:28AM -0400, John Cowan wrote:
> On Sat, Jun 17, 2017 at 10:25 AM, Peter Bex  wrote:
> I can imagine those macros going into (chicken base) and/or some
> > other modules, but a (chicken syntax) module with them in it makes
> > sense too.  Then we could just rename (chicken syntax) on the
> > c-l-r page to (chicken expand) and keep expand.scm as-is.
> 
> That sounds right to me.  The R7RS Yellow Edition (next after the current
> Orange Edition) will focus on syntax, and I plan to propose that all the
> macros added to the large language be put in a single (scheme syntax)
> library, possibly including SRFIs 2, 8, 17, 26, 31   Keeping the macro
> expansion machinery in (chicken expand) makes sense to me as well.

Good to know, it makes sense to make CHICKEN's structure match R7RS.
On the other hand, the (scheme base) library contains things like
syntax-rules, and, or, define-record-type, all the "let" variants and
so on, so it makes equal sense for us to include all the "standard"
CHICKEN macros in (chicken base).

Having them in (chicken base) feels a bit less arbitrary, too:
otherwise users will need to (import (chicken base)) for things like
add1 and error, while they need to (import (chicken syntax)) for
and-let* and define-inline.  And define-record-type would probably
go into (chicken base) too, since it's in R7RS (scheme base).
So why have some macros in (chicken syntax) and others in (chicken base)?

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] FFI improvements, take two

[Peter Bex]

On Wed, Jun 14, 2017 at 09:39:13PM +0200, lemonboy wrote:
> Hello hackers,
> the first two patches are meant to be applied after you review them, they are
> pretty much the same I've previously sent but with some minor corrections so
> those should be fine now.

Thanks for the patches.  Attached are signed-off copies.  I was tempted
to just push them, as they're kind of trivial, but we know what happened
last time, so to stay on the safe side I'll ask for a second review.

Cheers,
Peter
From 719d72dc2ef5f2de9c1b62a5f0e9cc8412c145cb Mon Sep 17 00:00:00 2001
From: LemonBoy 
Date: Wed, 14 Jun 2017 21:28:52 +0200
Subject: [PATCH 1/2] Propagate the tl? flag to the inner definitions

The define-foreign-type form defines some auxiliary functions using
define and this was bound to always fail as we'd treat those as
non-toplevel ones.

Signed-off-by: Peter Bex 
---
 core.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core.scm b/core.scm
index e6f3c39..2dccf48 100644
--- a/core.scm
+++ b/core.scm
@@ -1218,7 +1218,7 @@
 	(define
 	 ,ret
 	 ,(if (pair? (cdr conv)) (second conv) '##sys#values)) )
- e se dest ldest h ln #f) ) ]
+ e se dest ldest h ln tl?))]
  [else
   (register-foreign-type! name type)
   '(##core#undefined) ] ) ) )
-- 
2.1.4

From 351977f0c2e5fefe30fddd7ca020ab4c2d2713a1 Mon Sep 17 00:00:00 2001
From: LemonBoy 
Date: Wed, 14 Jun 2017 21:30:48 +0200
Subject: [PATCH 2/2] Restrict define-foreign-type forms to the toplevel

This brings this in line with how the other define forms work.

Signed-off-by: Peter Bex 
---
 core.scm | 5 +
 1 file changed, 5 insertions(+)

diff --git a/core.scm b/core.scm
index 2dccf48..c24ee15 100644
--- a/core.scm
+++ b/core.scm
@@ -1204,6 +1204,11 @@
 			 (let ((name (second x))
 			   (type (strip-syntax (third x)))
 			   (conv (cdddr x)))
+			   (unless tl?
+			 (quit-compiling
+			   "~adefinition of foreign type `~s' in non-toplevel context"
+			   (if ln (sprintf "(~a) - " ln) "")
+			   name))
 			   (cond [(pair? conv)
   (let ([arg (gensym)]
 	[ret (gensym)] )
-- 
2.1.4



signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chicken.export" module

[Peter Bex]

On Sat, Jun 17, 2017 at 11:34:30AM +1200, Evan Hanson wrote:
> As of afd7867, we can make these values available to the other files
> that need to use them without making them part of the chicken.export
> module's public API by assigning directly to namespaced identifiers.

Excellent.  This completes the export list on c-l-r for (chicken syntax).
I've pushed it.

This brings up the obvious question: what should we do with
(chicken expand)?  I was considering a patch to rename it to
(chicken syntax) like we have in c-l-r, but should we then also
rename the expand.scm file to syntax.scm?  I think this would
be the most sensible thing to do.

But if we do that, this makes the name of chicken-syntax.scm a bit
confusing, as it doesn't contain the chicken.syntax implementation.
Perhaps we should first decide what to do with the macros defined in
chicken-syntax.scm before finalizing what we do with expand.scm.

I can imagine those macros going into (chicken base) and/or some
other modules, but a (chicken syntax) module with them in it makes
sense too.  Then we could just rename (chicken syntax) on the
c-l-r page to (chicken expand) and keep expand.scm as-is.

I honestly don't know what the best course of action is.

I'd also like to hear what the other core members think.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix some symbol GC issues

[Peter Bex]

Hi all,

As Kooda found out when working on #1379, there's still some problems
with the symbol GC stuff in CHICKEN 5.  Sometimes you'll see an assertion
failure in update_symbol_tables: assert(!C_persistable_symbol(sym)) will
bail out due to some symbols being released while they still had a global
value or plist.

Attached is a patch to fix this.  First, I added the #ifdef DEBUGBUILD
block in update_symbol_tables() to more aggressively check for
inconsistencies.  Then, one by one, I fixed the problems that were
detected by this sanity check.

The main problem is that originally, I thought symbols were statically
allocated by C_h_intern, but it's only the *string* that's statically
allocated.  Making the entire symbol statically allocated is AFAICT not
possible (because the GC will skip its value and plist), so instead I
changed add_symbol() to check for this and allocate a weak or regular
pair from the start, instead of attempting to detect statically allocated
symbols during garbage collection.  This should make GCs ever so slightly
faster, too :)

C_i_unpersist() now also needs to check for static strings, to avoid
unpersisting those symbols prematurely.

I also noticed a sort of race condition in eval.scm where it could persist
the symbol before its value would be filled in, tripping up the sanity
check.  I worked around that by first performing the calculation and then
persisting.  I also removed ##sys#persist-symbol in favor of using
a ##core#inline in eval.scm, which should also make things slightly
faster and not susceptible to interrupts.

Finally, there's a weird situation where some symbols will be allocated
statically, but someone else might have interned the same symbol before.
This means the existing symbol might be dynamically allocated, and it
could be GCed, which means lf[...] will refer to dead memory (the GC can't
update lf[...] entries).  To fix this, I decided to go ahead and allocate
the string statically, and replace the existing symbol's dynamic string
with the newly allocated one, and persisting the symbol to ensure it
won't get GCed.

I'm reasonably sure that this weird situation can also occur in master.
I don't think it can be fixed as easily there, though, due to how the
weak table stuff works: if nothing currently refers to the symbol, it
will always be collected, even though the C code can refer to lf[...]
items later.

Cheers,
Peter
From 2940a1f6a74141ddb5bc7e9517778f95b5dd8b09 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Fri, 16 Jun 2017 19:54:42 +0200
Subject: [PATCH] Fix some edge cases with symbol GC

Symbols are never statically allocated, their name strings are, so the
permanentp() check in update_symbol_tables was bogus.  It might
trigger collection of a symbol even though it would be statically
allocated.

This could potentially cause problems when generated C code accessed a
symbol global through lf[...], for example, because its symbol would
have been collected.

Instead, we now ensure persistence in add_symbol, based on whether the
symbol's string name is in non-GCable memory, and C_i_unpersist_symbol
will now also check the string for being GCable before unpersisting.

This commit also adds a very paranoid check to update_symbol_tables
which detects such edge cases.  This check found more edge cases:

- When a symbol is immediately given a value in C_intern3, it should
   also be persisted.
- If a static symbol is to be generated by C_h_intern, but it has
   already been created in the heap (a practical example is the
   pending-finalizers symbol), there is no guarantee that it will
   stick around after GC.  So, if a symbol is found already in the
   symbol table, and its string name isn't statically allocated,
   we replace it by a newly allocated static string, to ensure that
   the code which created it won't allow the symbol to get GCed.
- The code in eval.scm had a problem if a GC happened in between
   persisting the symbol and actually assigning the value.  This is
   not a problem in practice, but persisting it after calculating
   the value is cleaner.  We also use the inline operator for
   performance and to avoid a GC in between persisting and assigning.
---
 eval.scm|  5 +++--
 library.scm |  1 -
 runtime.c   | 66 +
 3 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/eval.scm b/eval.scm
index 8167774..0eb395e 100644
--- a/eval.scm
+++ b/eval.scm
@@ -267,8 +267,9 @@
 	 (lambda (v)
 	   (##sys#error 'eval "environment is not mutable" evalenv var)) ;XXX var?
 	 (lambda (v)
-	   (##sys#persist-symbol var)
-	   (##sys#setslot var 0 (##core#app val v))
+	   (let ((result (##core#app val v)))
+		 (##core#inline "C_i_persist_symbol" var)
+		 (##sys#setslot var 0 result))
   ((zero? i) (lambda (v) (##sys#setslot (##s

[Chicken-hackers] [PATCH] Move some low-hanging fruit from posix.scm to file.scm

[Peter Bex]

Hi all,

The attached patch moves glob, find-files and delete-directory
from posix.scm to file.scm.  I also tried to move "directory",
and some of the "stat"-based file type predicates but that's
just too hairy to move, at least for now.

What should we do with ##sys#glob->regex?  I think it's useful
enough to expose to the user, which conveniently allows us to get
rid of the ##sys# prefix too.  But in which unit does it belong
the most?  Personally, I think file might make more sense, as
it's strictly not an irregex procedure, and it belongs with "glob".

On the other hand, it doesn't actually hit the file system; it's an
abstract operation over data-structures only, without any side effects.

Cheers,
Peter
From ee6672c0308e54f47526ce32a0e4ed87bd722e86 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Wed, 14 Jun 2017 21:34:58 +0200
Subject: [PATCH] Move several procedures from "posix" to "file"

- delete-directory
- glob
- find-files

This also moves the dependency on irregex from posix to file, since
only these three procedures used irregex helpers.
---
 file.scm  | 99 ++-
 posix-common.scm  | 88 -
 posix.scm |  9 ++---
 posixunix.scm |  1 -
 posixwin.scm  |  1 -
 rules.make|  3 +-
 tests/test-find-files.scm |  6 +--
 types.db  |  7 ++--
 8 files changed, 110 insertions(+), 104 deletions(-)

diff --git a/file.scm b/file.scm
index c1768af..b5c1661 100644
--- a/file.scm
+++ b/file.scm
@@ -35,7 +35,7 @@
 
 (declare
   (unit file)
-  (uses extras pathname posix)
+  (uses extras irregex pathname posix)
   (fixnum)
   (disable-interrupts)
   (foreign-declare #<regexp (make-pathname #f (or fil "*") ext
+		(let loop ((fns (directory (or dir ".") #t)))
+		  (cond ((null? fns) (conc-loop (cdr paths)))
+			((irregex-match rx (car fns))
+			 => (lambda (m)
+			  (cons
+			   (make-pathname dir (irregex-match-substring m))
+			   (loop (cdr fns )
+			(else (loop (cdr fns))) ) ) ) ) ) ) ) ) )
+
+;;; Find matching files:
+
+(define (find-files dir #!key (test (lambda _ #t))
+			  (action (lambda (x y) (cons x y)))
+  (seed '())
+  (limit #f)
+  (dotfiles #f)
+  (follow-symlinks #f))
+  (##sys#check-string dir 'find-files)
+  (let* ((depth 0)
+ (lproc
+  (cond ((not limit) (lambda _ #t))
+((fixnum? limit) (lambda _ (fx< depth limit)))
+(else limit) ) )
+ (pproc
+  (if (procedure? test)
+  test
+  (let ((test (irregex test))) ; force compilation
+(lambda (x) (irregex-match test x))
+(let loop ((dir dir)
+   (fs (directory dir dotfiles))
+   (r seed))
+  (if (null? fs)
+  r
+  (let* ((filename (##sys#slot fs 0))
+ (f (make-pathname dir filename))
+ (rest (##sys#slot fs 1)))
+(cond ((directory? f)
+   (cond ((member filename '("." "..")) (loop dir rest r))
+ ((and (symbolic-link? f) (not follow-symlinks))
+  (loop dir rest (if (pproc f) (action f r) r)))
+ ((lproc f)
+  (loop dir
+rest
+(fluid-let ((depth (fx+ depth 1)))
+  (loop f
+(directory f dotfiles)
+(if (pproc f) (action f r) r)
+ (else (loop dir rest (if (pproc f) (action f r) r)
+  ((pproc f) (loop dir rest (action f r)))
+  (else (loop dir rest r
+
 )
diff --git a/posix-common.scm b/posix-common.scm
index 3543e6b..ca8136a 100644
--- a/posix-common.scm
+++ b/posix-common.scm
@@ -507,28 +507,6 @@ EOF
 	 #:file-error
 	 'current-directory "cannot retrieve current directory") ) ) ) )
 
-(define delete-directory
-  (lambda (name #!optional recursive)
-(define (rmdir dir)
-  (let ((sname (##sys#make-c-string dir)))
-	(unless (fx= 0 (##core#inline "C_rmdir" sname))
-	  (posix-error #:file-error 'delete-directory "cannot delete directory" dir) )))
-(##sys#check-string name 'delete-directory)
-(if recursive
-  (let ((files (find-files ; relies on `find-files' to list dir-contents before dir
- name
- dotfiles: #t
- follow-symlinks: #f)))
-(for-each
-  (lambda (f)
-((cond ((symbolic-link? f) delete-file)

Re: [Chicken-hackers] [PATCH] [5] Make syntax-rules "fully" self-contained

[Peter Bex]

On Thu, Jun 08, 2017 at 09:19:24PM +0200, Peter Bex wrote:
> Hi all,
> 
> Here's a reasonably simple patch that moves the expansion-time support
> helpers for ye olde syntax-rules into an internal module in synrules.scm.

Well, not simple enough I guess ;).  I decided at the last minute to
rename "chicken.syntax-rules.internal" to "chicken.internal.syntax-rules"
which is more consistent with our other naming conventions, but forgot
to rename the reference in expand.scm as well.

This new version of the patch fixes that problem.

Cheers,
Peter
From 83e2487703ded3ac52c0ce75e10933e8ac3ca1f9 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Thu, 8 Jun 2017 21:02:18 +0200
Subject: [PATCH] Make syntax-rules fully self-contained

All expansion time support code for the generated expanders is moved
into a (chicken internal syntax-rules) module, which is not emitted,
so it's not available to users, but expansions can use the things
defined by the module through explicit reference to the fully
qualified name.
---
 expand.scm   |  6 ++
 library.scm  | 21 -
 rules.make   |  4 +++-
 synrules.scm | 56 +++-
 4 files changed, 52 insertions(+), 35 deletions(-)

diff --git a/expand.scm b/expand.scm
index 3c04a4f..ab60f3d 100644
--- a/expand.scm
+++ b/expand.scm
@@ -250,7 +250,8 @@
   (let ((exp2
 	 (if cs
 		 ;; compiler-syntax may "fall through"
-		 (fluid-let ((##sys#syntax-rules-mismatch (lambda (input) exp))) ; a bit of a hack
+		 (fluid-let ((chicken.internal.syntax-rules#syntax-rules-mismatch
+			  (lambda (input) exp))) ; a bit of a hack
 		   (handler exp se dse))
 		 (handler exp se dse))) )
 	(when (and (not cs) (eq? exp exp2))
@@ -736,9 +737,6 @@
 			   (else (loop (cdr cx
 	  (##sys#syntax-error-hook (get-output-string out))
 
-(define (##sys#syntax-rules-mismatch input)
-  (##sys#syntax-error-hook "no rule matches form" input))
-
 (define (get-line-number sexp)
   (and ##sys#line-number-database
(pair? sexp)
diff --git a/library.scm b/library.scm
index 3c55eb2..9da4ef9 100644
--- a/library.scm
+++ b/library.scm
@@ -5737,27 +5737,6 @@ EOF
 	z
 	(f (##sys#slot lst 0) (loop (##sys#slot lst 1))
 
-;; contributed by Peter Bex
-(define (##sys#drop-right input temp)
-  ;;XXX use unsafe accessors
-  (let loop ((len (length input))
-	 (input input))
-(cond
- ((> len temp)
-  (cons (car input)
-	(loop (- len 1) (cdr input
- (else '()
-
-(define (##sys#take-right input temp)
-  ;;XXX use unsafe accessors
-  (let loop ((len (length input))
-	 (input input))
-(cond
- ((> len temp)
-  (loop (- len 1) (cdr input)))
- (else input
-
-
 ;;; Platform configuration inquiry:
 
 (module chicken.platform
diff --git a/rules.make b/rules.make
index a163856..954fde4 100644
--- a/rules.make
+++ b/rules.make
@@ -784,7 +784,9 @@ read-syntax.c: $(SRCDIR)read-syntax.scm $(SRCDIR)common-declarations.scm
 repl.c: $(SRCDIR)repl.scm $(SRCDIR)common-declarations.scm
 	$(bootstrap-lib) -emit-import-library chicken.repl
 expand.c: $(SRCDIR)expand.scm $(SRCDIR)synrules.scm $(SRCDIR)common-declarations.scm
-	$(bootstrap-lib) -emit-import-library chicken.expand
+	$(bootstrap-lib) \
+	-no-module-registration \
+	-emit-import-library chicken.expand
 modules.c: $(SRCDIR)modules.scm $(SRCDIR)common-declarations.scm $(SRCDIR)mini-srfi-1.scm
 	$(bootstrap-lib)
 extras.c: $(SRCDIR)extras.scm $(SRCDIR)common-declarations.scm
diff --git a/synrules.scm b/synrules.scm
index cf8912e..7fdf7fa 100644
--- a/synrules.scm
+++ b/synrules.scm
@@ -40,7 +40,6 @@
 ; ((or e1 e ...) (let ((temp e1))
 ;		   (if temp temp (or e ...))
 
-
 (##sys#extend-macro-environment
  'syntax-rules
  '()
@@ -55,10 +54,44 @@
 	(set! ellipsis subkeywords)
 	(set! subkeywords (car rules))
 	(set! rules (cdr rules)))
-  (##sys#process-syntax-rules ellipsis rules subkeywords r c)
+  (chicken.internal.syntax-rules#process-syntax-rules
+   ellipsis rules subkeywords r c)
+
+
+;; Runtime internal support module exclusively for syntax-rules
+(module chicken.internal.syntax-rules
+(drop-right take-right syntax-rules-mismatch)
+
+(import scheme)
 
+(define (syntax-rules-mismatch input)
+  (##sys#syntax-error-hook "no rule matches form" input))
 
-(define (##sys#process-syntax-rules ellipsis rules subkeywords r c)
+(define (drop-right input temp)
+  ;;XXX use unsafe accessors
+  (let loop ((len (length input))
+	 (input input))
+(cond
+ ((> len temp)
+  (cons (car input)
+	(loop (- len 1) (cdr input
+ (else '()
+
+(define (take-right input temp)
+  ;;XXX use unsafe accessors
+  (let loop ((len (length input))
+	 (input input))
+(cond
+ ((> len temp)
+  (loop (- len 1) (cdr input)))
+ (else input
+
+;; OBSOLETE
+;; These two can be removed after 

[Chicken-hackers] [PATCH] [5] Make syntax-rules "fully" self-contained

[Peter Bex]

Hi all,

Here's a reasonably simple patch that moves the expansion-time support
helpers for ye olde syntax-rules into an internal module in synrules.scm.
process-syntax-rules is also stripped from its ##sys# prefix, since
that's no longer required with the new support for fully qualified symbols.

This shouldn't offend anyone because the expansion of syntax-rules itself
is a macro that requires er-macro-transformer.  Given that you need to
link expand.scm into a program that uses er-macro-transformer, these
helpers will also be available and do not have to be in library.scm.

Of course it's not 100% self-contained because the expansion still refers
to other identifiers from library.scm, but those are all standard Scheme.

Cheers,
Peter
From e40d9d4f6c020c5e0c1b0da8965ee6109e1188b1 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Thu, 8 Jun 2017 21:02:18 +0200
Subject: [PATCH] Make syntax-rules fully self-contained

All expansion time support code for the generated expanders is moved
into a (chicken internal syntax-rules) module, which is not emitted,
so it's not available to users, but expansions can use the things
defined by the module through explicit reference to the fully
qualified name.
---
 expand.scm   |  6 ++
 library.scm  | 21 -
 rules.make   |  4 +++-
 synrules.scm | 56 +++-
 4 files changed, 52 insertions(+), 35 deletions(-)

diff --git a/expand.scm b/expand.scm
index 3c04a4f..8525755 100644
--- a/expand.scm
+++ b/expand.scm
@@ -250,7 +250,8 @@
   (let ((exp2
 	 (if cs
 		 ;; compiler-syntax may "fall through"
-		 (fluid-let ((##sys#syntax-rules-mismatch (lambda (input) exp))) ; a bit of a hack
+		 (fluid-let ((chicken.syntax-rules.internal#syntax-rules-mismatch
+			  (lambda (input) exp))) ; a bit of a hack
 		   (handler exp se dse))
 		 (handler exp se dse))) )
 	(when (and (not cs) (eq? exp exp2))
@@ -736,9 +737,6 @@
 			   (else (loop (cdr cx
 	  (##sys#syntax-error-hook (get-output-string out))
 
-(define (##sys#syntax-rules-mismatch input)
-  (##sys#syntax-error-hook "no rule matches form" input))
-
 (define (get-line-number sexp)
   (and ##sys#line-number-database
(pair? sexp)
diff --git a/library.scm b/library.scm
index 3c55eb2..9da4ef9 100644
--- a/library.scm
+++ b/library.scm
@@ -5737,27 +5737,6 @@ EOF
 	z
 	(f (##sys#slot lst 0) (loop (##sys#slot lst 1))
 
-;; contributed by Peter Bex
-(define (##sys#drop-right input temp)
-  ;;XXX use unsafe accessors
-  (let loop ((len (length input))
-	 (input input))
-(cond
- ((> len temp)
-  (cons (car input)
-	(loop (- len 1) (cdr input
- (else '()
-
-(define (##sys#take-right input temp)
-  ;;XXX use unsafe accessors
-  (let loop ((len (length input))
-	 (input input))
-(cond
- ((> len temp)
-  (loop (- len 1) (cdr input)))
- (else input
-
-
 ;;; Platform configuration inquiry:
 
 (module chicken.platform
diff --git a/rules.make b/rules.make
index a163856..954fde4 100644
--- a/rules.make
+++ b/rules.make
@@ -784,7 +784,9 @@ read-syntax.c: $(SRCDIR)read-syntax.scm $(SRCDIR)common-declarations.scm
 repl.c: $(SRCDIR)repl.scm $(SRCDIR)common-declarations.scm
 	$(bootstrap-lib) -emit-import-library chicken.repl
 expand.c: $(SRCDIR)expand.scm $(SRCDIR)synrules.scm $(SRCDIR)common-declarations.scm
-	$(bootstrap-lib) -emit-import-library chicken.expand
+	$(bootstrap-lib) \
+	-no-module-registration \
+	-emit-import-library chicken.expand
 modules.c: $(SRCDIR)modules.scm $(SRCDIR)common-declarations.scm $(SRCDIR)mini-srfi-1.scm
 	$(bootstrap-lib)
 extras.c: $(SRCDIR)extras.scm $(SRCDIR)common-declarations.scm
diff --git a/synrules.scm b/synrules.scm
index cf8912e..7fdf7fa 100644
--- a/synrules.scm
+++ b/synrules.scm
@@ -40,7 +40,6 @@
 ; ((or e1 e ...) (let ((temp e1))
 ;		   (if temp temp (or e ...))
 
-
 (##sys#extend-macro-environment
  'syntax-rules
  '()
@@ -55,10 +54,44 @@
 	(set! ellipsis subkeywords)
 	(set! subkeywords (car rules))
 	(set! rules (cdr rules)))
-  (##sys#process-syntax-rules ellipsis rules subkeywords r c)
+  (chicken.internal.syntax-rules#process-syntax-rules
+   ellipsis rules subkeywords r c)
+
+
+;; Runtime internal support module exclusively for syntax-rules
+(module chicken.internal.syntax-rules
+(drop-right take-right syntax-rules-mismatch)
+
+(import scheme)
 
+(define (syntax-rules-mismatch input)
+  (##sys#syntax-error-hook "no rule matches form" input))
 
-(define (##sys#process-syntax-rules ellipsis rules subkeywords r c)
+(define (drop-right input temp)
+  ;;XXX use unsafe accessors
+  (let loop ((len (length input))
+	 (input input))
+(cond
+ ((> len temp)
+  (cons (car input)
+	(loop (- len 1) (cdr input
+ (else '()
+
+(define (take-right input temp)
+  ;;XXX use unsafe accessors
+  (let loop ((l

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[Peter Bex]

On Thu, Jun 08, 2017 at 11:24:44AM +0300, megane wrote:
> Reexport is nice if you have a big module (say a graphics library) you
> want to organize into smaller chunks internally.

Yeah, but why can't "export" (or the export list) do that job?

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[Peter Bex]

On Thu, Jun 08, 2017 at 10:39:45AM +0300, megane wrote:
> Peter Bex  writes:
> > Unexport seems to me to be solving a non-problem.  Exporting * always
> > seemed questionable to me, since it is too implicit and very error-prone.
> > It's very rare that you don't introduce *any* helper procedures or
> > macros.  In fact, introducing "unexport" just to paper over the problems
> > that exporting everything creates seems like the wrong direction to
> > me.
> 
> The only reason I'm using * export is to export is structs. That is,
> automatically exporting all defines created by a defstruct call. I
> already have a wrapper for defstruct, so maybe I should just export all
> identifiers from there.

That might be a bit saner but still very implicit, or unhygienic.  But
then so is defstruct.

> Maintaining the export list by hand is just busywork to me. So I only
> use either empty export list or *.
> 
> Nice thing about empty export list + export or * + unexport is that you
> can conditionally export all identifiers for e.g. unit testing.

The typical way to do that is to put the module definition in another file
than where you put the definitions.  Then you can simply
(include "defs.scm") in the tests and in the module.  But yeah, this is
a bit unwieldy, I admit.

> Why not just move all the module syntax to a new library? You currently
> have to have '(import chicken scheme)' in the beginning anyways.
> Wouldn't be a big deal if you had to add module-syntax and
> module-syntax-yolo there as well.

Yeah, that's what Evan suggested as well, and I like that idea.
I wouldn't mind having unexport in (chicken module) or so.

> I don't like this drop-prefix because that would make editor support
> harder. Say you want to look-up documentation for an identifier. With
> drop-prefix the editor would have to understand the import statement and
> go looking for the identifier for all modules for which you had used
> drop-prefix. OK, not a big problem, and applies to the current rename
> facility as well.

Yeah, that's not really a fundamentally different problem.  It'd be nice
if someone wrote some tooling around all this stuff to make code
navigation or even refactoring easier.  And I'd like a pony.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[Peter Bex]

On Thu, Jun 08, 2017 at 11:19:05AM +1200, Evan Hanson wrote:
> Hi Peter,
> 
> Firstly, thank you for the writeup. It takes time and energy to consider
> design issues like this, and your effort is appreciated.

No prob.  I really wanted to preempt adding more features without
considering the consequences first and wasn't sure where the other
hackers stood.

> On 2017-06-07 22:07, Peter Bex wrote:
> > But my more immediate concern is with proliferation of the magic set of
> > special forms that's always available in a supposedly "empty" new
> > namespace that a new module represents (the "initial macro environment").
> > In CHICKEN we have these:
> > 
> > - import
> > - import-for-syntax
> > - reexport
> 
> These make sense where they are to me. Maybe reexport could go in
> "chicken" (or "chicken.module", eventually, as in c-l-r).

I'd like that.  If the only things you have is forms to import other
things, you can get everything else from there.  Perhaps even just
"import" is enough, as you could import import-for-syntax first
(optionally renaming it), and then use that to import stuff for your
macro transformers.  I *think* that wouldn't cause any phasing issues.

In fact, maybe we can get rid of import-for-syntax.
(begin-for-syntax (import foo)) should be equivalent to
(import-for-syntax foo), right?

> > then there's these, which currently seem to be nicely put away in the
> > "chicken" namespace in CHICKEN 4, but in CHICKEN 5 are initially
> > available (might want to take a look at why that is...):
> > 
> > - begin-for-syntax
> 
> Agreed, this doesn't need to be in the default environment. I don't
> think this difference between CHICKEN 4 and 5 is intentional.
> 
> Shall we put it in "chicken.syntax" (what is currently "chicken.expand")
> instead?

I'd like that.  Or, if like you propose below, we add the other
export/reexport etc forms to chicken.module, we can add it there.
But chicken.syntax is probably the best place.

> > - import-syntax (WTF)
> > - import-syntax-for-syntax (WTF)
> 
> Why WTF? These import syntax. Do you have a better name for them? Or do
> you think they should live in a separate namespace from "normal" import?

The WTF was because I typed this message at too late an hour and didn't
remember what these did.  They're there to avoid the import from actually
loading any code, right?  Perhaps if we get rid of import-for-syntax we
can also get rid of import-syntax-for-syntax on the same grounds.  Then
we'd have just "import" and "import-syntax" in the initial macro
environment.

Perhaps later we can add some optional thing to the module form to allow
changing what they're called.  But for now we're good.

> These didn't exist in CHICKEN 4, and when they were added to CHICKEN 5
> we put them next to the existing import form. I still think that's
> where they belong.

Yeah, I think you're right.

> > And "chicken" exports this in both chicken-5 and master:
> > 
> > - export (which I always found rather useless, given that you have a
> >list of exports right at the top already)
> 
> I like export, personally (in fact, I'd rather do away with the module
> list, but that's neither here nor there), but I do think it's odd that
> it lives in "chicken" while reexport is in the initial environment. They
> should either be swapped or moved so that they're both outside the
> default namespace.
> 
> (Personally, I think reexport is the strange one here, but that's
> another topic for another day...)

Yeah, reexport is obscure.  Why do we need it again?  And to me, export
only makes sense if the module form doesn't have an export list.
Combining the two is just weird.

> I don't think this change is right for CHICKEN. I see the value in
> having a separate library language, of course, and I understand why R7RS
> works that way, but that's not how CHICKEN works, and in my opinion it's
> the wrong choice for a Scheme that's aiming to be pragmatic overall.

Yeah, like I said, R7RS's library system isn't programmable (AFAICT), and
that's a bit weird for a Lisp, which is the ultimate "programmable
programming language".  Having module forms be part of the language we
can do a lot more, for example having the s48-modules or r7rs module forms
available as pure user-level extensions wouldn't (as easily?) be possible
with the R7RS library, I think (nor would something like this be possible
with the s48 package declaration syntax).

> This being the case, the initial environment can't be empty, but s

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[Peter Bex]

On Wed, Jun 07, 2017 at 03:54:43PM -0400, John Cowan wrote:
> On Wed, Jun 7, 2017 at 2:06 PM,  wrote:
> 
> Isn't it easy to forget particular identifiers that happen to start with
> > "fp"
> > as well? I think explicit "rename" imports are clearer and less error
> > prone.
> >
> 
> My example is bad: you'd want to use it with a module where all the names
> begin with the same prefix, or almost all.  Another application is to drop
> the author's prefix and then add your own:  (import (prefix (drop-prefix
> srfi-13 string-) s:)) would change all the SRFI 13 identifiers beginning
> "string-" to begin "s:" instead (you'd want to change the Scheme
> identifiers too).
> 
> An open question is what to do when an identifier is the same as the
> prefix:  Chibi imports it unchanged, Chez changes it to || (the empty
> identifier).  A third possibility is to not import it.

What happens if you have an export list that includes both a prefixed
identifier and the same unprefixed identifier?  So you have (foo my-foo)
as an export list and you import it elsewhere as
(import (drop-prefix mymodule my-)).

To me this seems to introduce a nasty ambiguity.  You could warn, but
that's ugly and somewhat dangerous, if a new version of the module
suddenly contains such an ambiguity: you never know how a user is
going to rename.  Perhaps a saner approach is to only ever import
identifiers that actually have the prefix.


Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[Peter Bex]

On Wed, Jun 07, 2017 at 12:41:03PM -0400, John Cowan wrote:
> On Wed, Jun 7, 2017 at 9:28 AM, megane  wrote:
> 
> If the module export list is not *, module-unexport-list is not used. In
> > this case, it's enough to just remove the identifier to be unexported
> > from the module-export-list.
> >
> 
> Very nice!
> 
> While you are messing around with the module system, I'd like to see
> "strip-prefix", which is just like "prefix" except it removes a prefix from
> identifiers (if present) rather than adding one.

Both these proposals make me very very uneasy, for slightly different
but somewhat related reasons.

Warning: what follows turned into a long rant.  Please bear with me.

Unexport seems to me to be solving a non-problem.  Exporting * always
seemed questionable to me, since it is too implicit and very error-prone.
It's very rare that you don't introduce *any* helper procedures or
macros.  In fact, introducing "unexport" just to paper over the problems
that exporting everything creates seems like the wrong direction to me.

But my more immediate concern is with proliferation of the magic set of
special forms that's always available in a supposedly "empty" new
namespace that a new module represents (the "initial macro environment").
In CHICKEN we have these:

- import
- import-for-syntax
- reexport

then there's these, which currently seem to be nicely put away in the
"chicken" namespace in CHICKEN 4, but in CHICKEN 5 are initially
available (might want to take a look at why that is...):

- begin-for-syntax
- import-syntax (WTF)
- import-syntax-for-syntax (WTF)

And "chicken" exports this in both chicken-5 and master:

- export (which I always found rather useless, given that you have a
   list of exports right at the top already)

Now we are discussing adding "unexport" onto that set.  Ideally, the
initial module environment should be empty.  As in, completely void,
a blank canvas.  This allows for maximum flexibility in whatever the
user wants to define inside the module.  R7RS small avoids the problem
of polluting the initial environment by strictly separating the library
definitions from the Scheme code within it (the Scheme code must always
be wrapped in (begin ...)).

By doing this, R7RS allows for an almost infinitely extensible
"library language", that will never pollute the Scheme module inside.
Unfortunately, because it's not Scheme, this language isn't (easily?)
programmable by the user.  CHICKEN mixes up both things somewhat by
having this initial macro environment.  I'd prefer if we can avoid
adding *any* new identifiers to this macro environment, to avoid
stepping on the user's toes.  So without a change in how the module
language works I'd be against this change.  FWIW, I think making this
change is probably the Right Thing(TM), but also probably a too large
change to do now, in CHICKEN 5.


Regarding drop-prefix, it makes me uneasy because of the dual use
of symbols and lists as library identifiers.  In R7RS, again, you
have an "import set" which is any of (only ...), (rename ...),
(except ...) or (prefix ...) or a "library name", which is ALWAYS
a list.  So there's no ambiguity whatsoever: you can have a library
called (rename file pattern) and it can always be distinguished from
a rename of an identifier from a library, because "file" and "pattern"
are not valid library names.

In CHICKEN, we allow both "(file)" and "file" as a library name, so
there's an ambiguity.  With every new import option we add we make
this problem worse.  I would prefer us to reconsider allowing this
duality by either going the R7RS route and requiring the identifier
to always be a list, or dropping the list syntax altogether and
only allowing symbols.  Without this change, I'd be EXTREMELY
hesitant to add any more import operators.

Regarding the list syntax versus symbols, it would be easier on
our users, porting-wise, to only allow symbols as library names.
It also maps more clearly to the file system.  Aesthetically and
for compatibility with other Schemes, I'd prefer the list syntax
only.  But accepting both is (in hindsight) quite the mistake.
We can still change things before it's too late...


Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] [5] Fix a few 64-bit issues

[Peter Bex]

Hi all,

I noticed two problems after looking over the file-modification-time
patches I recently submitted.  The first is that on 32-bit systems, the
mtime or atime that the user passes in would get truncated to 32 bits
on a 32-bit platform (and presumably also on a 64-bit LLP platform, ie
64-bit Windows) due to using C_int_to_num instead of C_int_to_num64.

The other problem is related; size_t is an unsigned type, not a signed
type, and it can be 64-bit even on 32-bit systems, so we should better
use C_int_to_num64 for that type as well.

Attached are patches for this.

Strictly speaking, I suppose we should really add a new C_num_to_size_t
or such, but if we do that, we will need to add it for every stupid
opaque type that C might offer.  In practice, size_t is at most 64 bits
so let's just keep that assumption (for now?).

Cheers,
Peter
From 44a187085319c440d28402914ad8ba4ac7b62578 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Tue, 6 Jun 2017 21:06:57 +0200
Subject: [PATCH 1/2] Do not truncate file times to 32 bits on 32-bit or LLP
 platforms in setter

---
 posixunix.scm | 4 ++--
 posixwin.scm  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/posixunix.scm b/posixunix.scm
index 54bfe7e..f20623e 100644
--- a/posixunix.scm
+++ b/posixunix.scm
@@ -370,12 +370,12 @@ static int set_file_mtime(char *filename, C_word atime, C_word mtime)
   if (atime == C_SCHEME_FALSE) {
 tb.actime = sb.st_atime;
   } else {
-tb.actime = C_num_to_int(atime);
+tb.actime = C_num_to_int64(atime);
   }
   if (mtime == C_SCHEME_FALSE) {
 tb.modtime = sb.st_mtime;
   } else {
-tb.modtime = C_num_to_int(mtime);
+tb.modtime = C_num_to_int64(mtime);
   }
   return utime(filename, &tb);
 }
diff --git a/posixwin.scm b/posixwin.scm
index 735504c..c0a2cf8 100644
--- a/posixwin.scm
+++ b/posixwin.scm
@@ -648,12 +648,12 @@ static int set_file_mtime(char *filename, C_word atime, C_word mtime)
   if (atime == C_SCHEME_FALSE) {
 tb.actime = sb.st_atime;
   } else {
-tb.actime = C_num_to_int(atime);
+tb.actime = C_num_to_int64(atime);
   }
   if (mtime == C_SCHEME_FALSE) {
 tb.modtime = sb.st_mtime;
   } else {
-tb.modtime = C_num_to_int(mtime);
+tb.modtime = C_num_to_int64(mtime);
   }
   return _utime(filename, &tb);
 }
-- 
2.1.4

From 95e19db09f94c222e97fb50e0e0e687a2f5a4cee Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Tue, 6 Jun 2017 21:28:21 +0200
Subject: [PATCH 2/2] Fix size_t to map to unsigned 64-bit integers, add signed
 ssize_t

Add a test case to ensure they can represent the proper range.
---
 NEWS |  5 +
 c-backend.scm| 14 --
 support.scm  | 17 -
 tests/compiler-tests.scm |  6 ++
 4 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/NEWS b/NEWS
index d179db0..f4b0e04 100644
--- a/NEWS
+++ b/NEWS
@@ -82,6 +82,11 @@
   - Static compilation of eggs is now fully supported and static
 versions of compiled eggs are available by default.
 
+- Foreign function interface
+  - The foreign type specifier "ssize_t" is now accepted, and "size_t"
+arguments now only accept positive integers.  Return values of
+type size_t are no longer truncated on 32-bit platforms.
+
 
 4.12.1
 
diff --git a/c-backend.scm b/c-backend.scm
index 1c0f8f2..6be88ab 100644
--- a/c-backend.scm
+++ b/c-backend.scm
@@ -1129,9 +1129,10 @@
 		   c-string-list c-string-list*)
 	(string-append ns "+3") )
 	   ((unsigned-integer unsigned-integer32 long integer integer32 
-			  unsigned-long size_t number)
+			  unsigned-long number)
 	(string-append ns "+C_SIZEOF_FIX_BIGNUM"))
-	   ((unsigned-integer64 integer64) ; On 32-bit systems, needs 2 digits
+	   ((unsigned-integer64 integer64 size_t ssize_t)
+	;; On 32-bit systems, needs 2 digits
 	(string-append ns "+C_SIZEOF_BIGNUM(2)"))
 	   ((c-string c-string* unsigned-c-string unsigned-c-string unsigned-c-string*)
 	(string-append ns "+2+(" var "==NULL?1:C_bytestowords(C_strlen(" var ")))") )
@@ -1203,6 +1204,7 @@
   ((unsigned-int32 unsigned-integer32) (str "C_u32"))
   ((int integer bool) (str "int"))
   ((size_t) (str "size_t"))
+  ((ssize_t) (str "ssize_t"))
   ((int32 integer32) (str "C_s32"))
   ((integer64) (str "C_s64"))
   ((unsigned-integer64) (str "C_u64"))
@@ -1303,7 +1305,8 @@
   ((double number float) "C_c_double(")
   ((integer integer32) "C_num_to_int(")
   ((integer64) "C_num_to_int64(")
-  ((size_t) "(size_t)C_num_to_int(")
+  ((size_t) "(size_t)C_num_to_uint64(")
+  ((ssize_t) "(ssize_t)C_num_to_int64(")
   ((unsigned-integer64) "C_num_to_uint64(")
   ((long) "C_num_to_long(")
   ((unsigned-integer

Re: [Chicken-hackers] Regarding the hide declaration, #1376

[Peter Bex]

On Tue, Jun 06, 2017 at 11:01:30AM +0200, felix.winkelm...@bevuta.com wrote:
> > First, let me ramble some:
> > 
> > 1. If you hide an exported identifier the compiler is free to drop the
> > actual definition from the compiled object. This happens without any
> > warnings currently and you get a runtime error if you try to use the
> > identifier.
> > 
> > 2. If an identifier is not exported I think it's safe to declare it hidden.
> > 
> > 3. As you see from the tests, the patch I provided seems to work as it's
> > supposed to. That is, it unexports identifiers using the hide
> > declaration. None of my code broke when I recompiled all eggs I'm using.
> > Just FYI.
> > 
> > Second:
> > 
> > I think there should be a way to remove identifiers from the module export
> > list. I'm happy to try adding an unexport syntax form if that's a good
> > idea (that's why I started this thread).
> 
> I'm not oppossed to an unexport mechanism in general, but declarations
> are not the proper way to address this. Just like qualified symbols they
> are a leftover of the older, unit-related method of namespace management.
> The fact that "declare" is not available in evaluated code should also
> indicate that we should find something different. User code should avoid
> declarations, unless it is truly necessary. Modules do the hiding 
> automatically
> for unexported identifiers, and I think this is much cleaner and simpler.

+1.

That's the whole point of modules.  Not allowing the definition to be
dropped (or inlined) even if it's never used nor exported would be very
counter-intuitive, especially to people who don't use any declarations,
which would be most people.

It's an important within-module optimization to drop the identifier.  If
we made it official that identifiers aren't dropped, people will start
relying on internal implementation details like the module#identifier
syntax even more.  At some point we might decide to change that, and then
all your code will break if you rely on this.

If you want to "hide" some symbols from the export list but keep them
for internal use in an egg, just put them in a different module.  If you
don't install that "internal" module's import library, it won't be usable
by users.  Besides, you can still install it but just not document it :)

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Make setting of the file modification time saner

[Peter Bex]

On Mon, Jun 05, 2017 at 11:11:06PM +0200, Kooda wrote:
> Both changes signed off and pushed. :)
> 
> Sorry for the delay.

No worries, and many thanks for taking a look!

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm

[Peter Bex]

On Mon, Jun 05, 2017 at 05:53:32PM +1200, Evan Hanson wrote:
> Hey Peter,
> 
> On 2017-06-04 13:53, Peter Bex wrote:
> > Regarding time specifically, there are not many stand-alone programs
> > that will use this macro, I think.  It's more a thing for benchmarks
> > and such, so I'm not even sure it must be part of library.  It probably
> > was in there because the macro was in the "chicken" module.  There's a
> > lot of stuff that's much less optional than "time" (as in, used by day
> > to day programs) that lives in other units like file.scm.
> 
> True. I do think the support code for `time` would be good to move, if
> we can sort out the dependency issues.

What exactly are the dependency issues you're concerned about?  AFAIK
there's a simple rule: if you use the "time" macro, you'll need to
include internal.scm into your program.  That's pretty straightforward,
IMHO.  Besides, you also need to know that you need to include, say,
extras.scm when using "randomize" from (chicken random).

The only difference here is that it's the _expansion_ that requires the
unit rather than the direct call.  Is that the issue?

Maybe we can fix the situation by adding something to the manual to
indicate which units map to which modules.  This would solve this
problem more generally, including the "randomize" example I gave above.

We still haven't decided on which module "time" should go into, so maybe
that's part of the problem (it's missing completely from c-l-r).

> It's also probably possible to
> make the compiler generate code to load units as they're required by
> macro expansions, but that's sure to have other implications so I'm not
> super keen to go there right now.

I agree that would be nice but is a bit too complex right now.  Maybe
we'll take a look at this for 5.1 or 5.2.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] Regarding the hide declaration, #1376

[Peter Bex]

On Mon, Jun 05, 2017 at 06:09:54PM +1200, Evan Hanson wrote:
> Is that right? Personally, I'd rather make (declare (hide ...)) simply
> do the right thing -- the right thing being the behaviour you originally
> expected when filing #1376 -- than add a new type of declaration or
> module syntax.
> 
> I think this is similar to what Peter has said on that ticket, so a
> patch of that sort would be very welcome.

This is slightly more complicated due to declare being module-unaware.

(declare (hide foo))

(module a * (import chicken scheme) (define foo 1))
(module b * (import chicken scheme) (define foo 2))

Which foo should be hidden?  Both, or none?

I think the sane thing to do here is to make it error out,
considering there's no top-level foo to hide, and make it
work like this:

(module a *
   (import chicken scheme)
   (define foo 1))
(module b *
   (declare (hide foo))
   (import chicken scheme) (define foo 2))

So here a#foo is visible and exported, while b#foo is hidden and
not exported.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm

[Peter Bex]

On Sun, Jun 04, 2017 at 11:20:06PM +1200, Evan Hanson wrote:
> I'm concerned about the way these introduce an implicit dependency from
> the library unit to the internal unit.
> 
> I think we should strive to make library the first, and potentially the
> only, unit that the user needs to care about when distributing compiled
> C or compiling programs with "-explicit-use".

I see what you mean.

> So, what is the intended purpose of these changes? If it's to shrink
> library.scm, I think there are probably other things in that file that
> could moved more easily and that wouldn't have this problem, but if it's
> just nicer organisation of CHICKEN's source code for our own sake then
> I'd rather not make these particular changes.

It was to shrink library.scm, but also to move an internal procedure
that's rarely used (!), like the runtime support for the "time" macro
elsewhere.  By moving it to "internal", it clearly signals to users
that they should not rely on the procedure directly.

The idea would be to have all the stuff that's not supposed to be
used into "internal".

Regarding time specifically, there are not many stand-alone programs
that will use this macro, I think.  It's more a thing for benchmarks
and such, so I'm not even sure it must be part of library.  It probably
was in there because the macro was in the "chicken" module.  There's a
lot of stuff that's much less optional than "time" (as in, used by day
to day programs) that lives in other units like file.scm.

> All that said, I'm definitely in favour of dropping the optional
> arguments in mini-srfi-1.scm and using that file's procedures in
> csi.scm, and I'd be happy to apply those bits on their own right away.

Please do.  We can argue about where to put the support stuff later :)

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] About (chicken process) and (chicken process-context)

[Peter Bex]

On Sat, May 13, 2017 at 01:39:36PM +0200, Peter Bex wrote:
> On Wed, May 10, 2017 at 11:22:46AM +0200, felix.winkelm...@bevuta.com wrote:
> [about moving some procedures to chicken.process-context and making the
>  posix module's API identical between Windows and UNIX]
> > >
> > > What do you all think?
> > 
> > Yep, makes sense to me.
> 
> Attached are two patches that make it so.
> 
> I also noticed the various spawn/* definitions weren't exported on
> UNIX either.  The open/noinherit wasn't exported there either.

Could someone please take a look at this?

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm

[Peter Bex]

On Wed, May 03, 2017 at 08:29:12AM +0200, Peter Bex wrote:
> On Mon, May 01, 2017 at 06:02:51PM +1200, Evan Hanson wrote:
> > Hi folks,
> > 
> > Just wanted to mention that I've already applied the first of these
> > patches; that one is clearly a nice change and definitely where those
> > procedures belong, good call.
> 
> Is there a problem with the other ones, or have you just not had time
> to properly review them?

Anyone have some time to look at the remaining two patches of this
post?  It's been sitting here without comments for a month.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [C5][PATCH] manual/Extensions: document `modules' property

[Peter Bex]

On Fri, Jun 02, 2017 at 07:56:12PM +0200, Mario Domenech Goulart wrote:
> Hello,
> 
> Attached is proposal of documentation for the `modules' property.

Feel free to put this on the wiki under man/5.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [C5] `extension' components & non-modules

[Peter Bex]

On Wed, May 31, 2017 at 12:19:07PM +0200, felix.winkelm...@bevuta.com wrote:
> > > The multi-module case is indeed not covered. There is an note on the
> > > wiki regarding functors that emit 2 import libs (used in some places),
> > > this has to be handled automatically (compile + install .import.so
> > > and _.import.so, if the latter one exists). Another option would 
> > > be
> > > to add .egg properties specifying the output modules.
> >
> > If I recall correctly, the s48-modules egg also generates two modules per
> > package declaration: one that's "internal" with a leading underscore and
> > one that's the actual module for public consumption.
> 
> Right, that's what I meant.

Note that this is something else than the functor internal modules!

The functor ones are _.import.so, while s48 generates 
_.import.so
because it has a different function (it's a base module from which several
derived modules can export subsets, via define-structures).

> > So there's some precedence of having a single source file that exports
> > multiple modules.  I think it's worth supporting.
> 
> Ok, how about a new .egg extension property named "(modules NAME1 ...)"?
> Defaulting to one module (the extension name). Keeping the list empty
> ("(modules)") specifies an extension without modules.

Sounds good!

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [C5] `extension' components & non-modules

[Peter Bex]

On Wed, May 31, 2017 at 11:34:19AM +0200, felix.winkelm...@bevuta.com wrote:
> All good questions. I'm for making this as simple as possible. The overhead
> for having a module for each extension shouldn't be too much and there
> appears to me (at least at this stage) no disxadvantage of requiring an 
> extension to be a module. Is there a particular use-case that would make
> the current approach problematic?
> 
> The multi-module case is indeed not covered. There is an note on the
> wiki regarding functors that emit 2 import libs (used in some places),
> this has to be handled automatically (compile + install .import.so
> and _.import.so, if the latter one exists). Another option would be
> to add .egg properties specifying the output modules.

If I recall correctly, the s48-modules egg also generates two modules per
package declaration: one that's "internal" with a leading underscore and
one that's the actual module for public consumption.

And of course CHICKEN itself also does this in several files.

So there's some precedence of having a single source file that exports
multiple modules.  I think it's worth supporting.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [SECURITY] Fix segfault in C_i_length() on improper lists

[Peter Bex]

On Wed, May 31, 2017 at 04:52:33PM +1200, Evan Hanson wrote:
> Applied.
> 
> Bit surprised at this one. How on earth did it hang around for so long?

Exactly my thoughts.  This really makes no sense!

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Some FFI improvements

[Peter Bex]

On Sun, May 28, 2017 at 11:29:06PM +0200, lemonboy wrote:
> Hello hackers,

Hi Lemonboy,

Thanks (again!) for your patches.  You're really putting in quite
the effort.

> I'll be brief:
> - The first patch fixes a problem where we'd fail to consider the
> internal defines as toplevel ones,
>  leading to a compiler error.
> - The second patch complements the first by rejecting more `define-`
> forms in non-toplevel contexts.

Those two are pretty straightforward, so I attached signed-off copies
(minus the whitespace changes).

> - The third one is slightly beefier as it prevents us to apply the
> wrong specialization in some cases
>  like in the following snippet.
> 
> ```
> (import foreign)
> (define-foreign-type ty int (lambda (x) 42) (lambda (x) 0.5))
> (let ((t0 ((foreign-lambda* ty ((ty x)) "return 0;") 'sym)))
>   (print (min t0 1))) ;; We expect this to be 0.5 and not 1
> ```

I have two comments about the patch, and a more generic comment:

1) I don't like the extra "mode" argument making its way into the
final-foreign-type API.  It has nothing to do with the _foreign_
type of the value, that's unchanged.  This is purely a scrutinizer
change, and it shouldn't "infect" code that deals only with foreign
types.

2) Your patch bails out if it encounters any conversion functions during
the lookup.  However, this is overly strict: the procedures
foreign-type-convert-{result,argument} will perform a "shallow"
lookup.  That means if you create a foreign type "alias" for another
type, the alias won't inherit the type converters of the other type.
Whether that's desirable is up for debate, of course, but that's how
it currently works.  So we can just use the "final" type if the
initial lookup returns no converters.

More generally, I think indiscriminantly adding (##core#the ...)
annotations for foreign values is too aggressive.  It would be better
to only do that when we can determine a proper result type.

Allowing an optional type annotation would allow the scrutinizer to
analyse the converter's type.  Currently, returning '* just blocks the
scrunitizer from performing its analysis.  In fact, it would be even
better if we can use the foreign type's scrutiny type as information
for the conversion procedures' input or output.  But that's just wishful
thinking.

For now, I think the attached patch will do, and has less impact because
the change is more localised.  I struggled quite a bit to make this code
readable, so if anyone knows how to improve this, please do!

Cheers,
Peter
From 00e97b8b532c80ffbe02c1291d2e96b5bc5401d4 Mon Sep 17 00:00:00 2001
From: LemonBoy 
Date: Sun, 28 May 2017 22:12:32 +0200
Subject: [PATCH 1/3] Do not treat internal defines as non-toplevel ones

We now treat the internal defines as if they're defined at the same
level the define-foreign-type is.

Signed-off-by: Peter Bex 
---
 core.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/core.scm b/core.scm
index e73d207..e87815d 100644
--- a/core.scm
+++ b/core.scm
@@ -1221,7 +1221,7 @@
 	(define
 	 ,ret
 	 ,(if (pair? (cdr conv)) (second conv) '##sys#values)) )
- e se dest ldest h ln #f) ) ]
+ e se dest ldest h ln tl?))]
  [else
   (register-foreign-type! name type)
   '(##core#undefined) ] ) ) )
-- 
2.1.4

From 99a461409be899191e3425285f9901da0755dff7 Mon Sep 17 00:00:00 2001
From: LemonBoy 
Date: Sun, 28 May 2017 22:33:47 +0200
Subject: [PATCH 2/3] Reject more definitions outside of toplevel context

Since we use global tables to store those definitions it makes sense to
restrict those to the toplevel only.

Signed-off-by: Peter Bex 
---
 core.scm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/core.scm b/core.scm
index e87815d..cc1dd9a 100644
--- a/core.scm
+++ b/core.scm
@@ -1195,6 +1195,11 @@
 (name (if (pair? (cdddr x))
 	  (fourth x)
 	  (symbol->string var
+			   (unless tl?
+			 (quit-compiling
+			   "~adefinition of foreign variable `~s' in non-toplevel context"
+			   (if ln (sprintf "(~a) - " ln) "")
+			   var))
 			   (set! foreign-variables
 			 (cons (list var type
 	 (if (string? name)
@@ -1207,6 +1212,11 @@
 			 (let ((name (second x))
 			   (type (strip-syntax (third x)))
 			   (conv (cdddr x)))
+			   (unless tl?
+			 (quit-compiling
+			   "~adefinition of foreign type `~s' in non-toplevel context"
+			   (if ln (sprintf "(~a) - " ln) "")
+			   name))
 			   (cond [(pair? conv)
   (let ([arg (gensym)]
 	[ret (gensym)] )
-- 
2.1.4

From ed4dd017d351b9d7de8ee0630fd257a9896b944b Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Mon, 29 May 2017 22:23:11 +

Re: [Chicken-hackers] [PATCH][5] Add missing syntax checks

[Peter Bex]

On Sat, May 27, 2017 at 11:04:05PM +0200, lemonboy wrote:
> Hello hackers,
> this patch does what it says on the tin and can be safely applied to
> the 4 branch,
> I didn't supply a separate patch in the hope the patch(1) deity
> manages me to spare
> this effort :)

Good catch, however the syntax check for define-foreign-type is too
strict: it should accept anything that evaluates to a procedure,
not just a symbol that refers to one.  The attached patch fixes
that.

Cheers,
Peter
From 935f5362b20db8a3fb22c662e78eaea8cb276d11 Mon Sep 17 00:00:00 2001
From: LemonBoy 
Date: Sat, 27 May 2017 22:58:31 +0200
Subject: [PATCH] Check the syntax correctness for some constructs

Forgetting to do so leads to segfaults in the compiler and suboptimal
error messages for the end user.

Signed-off-by: Peter Bex 
---
 chicken-ffi-syntax.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/chicken-ffi-syntax.scm b/chicken-ffi-syntax.scm
index ea87ced..c997071 100644
--- a/chicken-ffi-syntax.scm
+++ b/chicken-ffi-syntax.scm
@@ -195,6 +195,7 @@
  '()
  (##sys#er-transformer
   (lambda (form r c)
+(##sys#check-syntax 'define-foreign-type form '(_ symbol symbol . #(_ 0 2)))
 `(##core#define-foreign-type ,@(cdr form)
 
 (##sys#extend-macro-environment
@@ -202,6 +203,7 @@
  '()
  (##sys#er-transformer
   (lambda (form r c)
+(##sys#check-syntax 'define-foreign-variable form '(_ symbol symbol . #(string 0 1)))
 `(##core#define-foreign-variable ,@(cdr form)
 
 (##sys#extend-macro-environment
-- 
2.1.4



signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] [SECURITY] Fix segfault in C_i_length() on improper lists

[Peter Bex]

Hi all,

I just noticed ticket #1375 is caused by an incorrect check in C_i_length
which causes a segfault when passed an improper list.  That means this
could be a denial of service if (length) is used on user input.
The attached patch applies both to master and chicken-5.

Cheers,
Peter
From 76bbb0c92c0a9e2cadac9796e55fdd2836424fdb Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 28 May 2017 12:37:44 +0200
Subject: [PATCH] Fix segmentation fault in "length" on improper lists.

This fixes #1375
---
 NEWS| 2 ++
 runtime.c   | 2 +-
 tests/library-tests.scm | 6 ++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 7e395ac..fc05da8 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,8 @@
   - CVE-2017-6949: Remove unchecked malloc() call in SRFI-4 constructors
 when allocating in non-GC memory, resulting in potential 1-word
 buffer overrun and/or segfault (thanks to Lemonboy).
+  - "length" no longer crashes on improper lists
+(fixes #1375, thanks to "megane").
 
 - Core Libraries
   - Unit "posix": If file-lock, file-lock/blocking or file-unlock are
diff --git a/runtime.c b/runtime.c
index 86db413..7a513c2 100644
--- a/runtime.c
+++ b/runtime.c
@@ -5379,7 +5379,7 @@ C_regparm C_word C_fcall C_i_length(C_word lst)
   }
 }
 
-if(C_immediatep(slow) || C_block_header(lst) != C_PAIR_TAG)
+if(C_immediatep(slow) || C_block_header(slow) != C_PAIR_TAG)
   barf(C_NOT_A_PROPER_LIST_ERROR, "length", lst);
 
 slow = C_u_i_cdr(slow);
diff --git a/tests/library-tests.scm b/tests/library-tests.scm
index cd2f6e9..9c7cab4 100644
--- a/tests/library-tests.scm
+++ b/tests/library-tests.scm
@@ -693,3 +693,9 @@ A
 (assert (not (member "foo" '("bar"
 (assert (not (member "foo" '(
 (assert-fail (member "foo" "foo"))
+
+
+;; length
+
+(assert-fail (length 1))
+(assert-fail (length '(x . y)))
-- 
2.1.4



signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Small patch for chicken-install

[Peter Bex]

On Thu, May 25, 2017 at 03:55:42PM +0200, lemonboy wrote:
> Hello hackers,
> here's a small patch that fixes the problem with chicken-install
> reported by Mario in #1373.
> I've briefly tested it and have inspected the contents of the
> .install.sh file and it does look right.

Here's a signed off copy, with one small tweak: the (or oname target)
in the (set! prgs ..) list can be replaced by rtarget, to avoid
repeating ourselves again.  This requires extending the LET's body
to include that set! call, hence the slightly larger patch due to
the reindent.

Cheers,
Peter
From 941e78d5ad8324a1c9e3a5f90ad076bc97a05a7b Mon Sep 17 00:00:00 2001
From: LemonBoy 
Date: Thu, 25 May 2017 15:53:30 +0200
Subject: [PATCH] Respect install-name when specified.

Do this for 'program' and 'extension' components.

Signed-off-by: Peter Bex 
---
 egg-compile.scm | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/egg-compile.scm b/egg-compile.scm
index 4d7332c..e72db6e 100644
--- a/egg-compile.scm
+++ b/egg-compile.scm
@@ -143,15 +143,17 @@
   (oname #f)
   (opts '()))
 (for-each compile-extension/program (cddr info))
-(let ((dest (destination-repository mode #t)))
-  (when (eq? #t tfile) (set! tfile target))
-  (when (eq? #t ifile) (set! ifile target))
+(let ((dest (destination-repository mode #t))
+  ; Respect install-name if specified
+  (rtarget (or oname target)))
+  (when (eq? #t tfile) (set! tfile rtarget))
+  (when (eq? #t ifile) (set! ifile rtarget))
   (addfiles 
 (if (memq 'static link) 
-(list (conc dest "/" target objext)
-  (conc dest "/" target +link-file-extension+))
+(list (conc dest "/" rtarget objext)
+  (conc dest "/" rtarget +link-file-extension+))
 '())
-(if (memq 'dynamic link) (list (conc dest "/" target ".so")) '())
+(if (memq 'dynamic link) (list (conc dest "/" rtarget ".so")) '())
 (if tfile 
 (list (conc dest "/" tfile ".types"))
 '())
@@ -159,8 +161,8 @@
 (list (conc dest "/" ifile ".inline"))
 '())
 (list (if (uses-compiled-import-library? mode)
-  (conc dest "/" target ".import.so")
-  (conc dest "/" target ".import.scm")
+  (conc dest "/" rtarget ".import.so")
+  (conc dest "/" rtarget ".import.scm")
 (set! exts 
   (cons (list target dependencies: deps source: src options: opts 
   link-options: lopts linkage: link custom: cbuild
@@ -235,13 +237,15 @@
 (for-each compile-extension/program (cddr info))
 (let ((dest (if (eq? mode 'target) 
 default-bindir   ; XXX wrong!
-host-bindir)))
-  (addfiles (list (conc dest "/" target exeext
-(set! prgs 
-  (cons (list target dependencies: deps source: src options: opts 
-  link-options: lopts linkage: link custom: cbuild
-  mode: mode output-file: (or oname target)) 
-prgs))
+host-bindir))
+  ; Respect install-name if specified
+  (rtarget (or oname target)))
+  (addfiles (list (conc dest "/" rtarget exeext)))
+	  (set! prgs 
+		(cons (list target dependencies: deps source: src options: opts 
+			link-options: lopts linkage: link custom: cbuild
+			mode: mode output-file: rtarget)
+		  prgs)))
 (define (compile-extension/program info)
   (case (car info)
 ((target) 
-- 
2.1.4



signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Fix types of condition manipulation procedures [was: Re: [PATCH] Add more convenient condition object constructor [was: Re: [PATCH] Turn chicken.condition into a module, with

[Peter Bex]

On Sat, May 27, 2017 at 03:34:54PM +1200, Evan Hanson wrote:
> Yeah, let's leave it at that. It's easy enough to convert property lists
> to something else as needed. I'm also not too worried about breaking
> changes here, so I've applied your patch as-is and updated the
> `condition->list` procedure to use the same plist representation.

I just noticed that you forgot to update its type in types.db.
The old type was

(chicken.condition#condition->list (#(procedure #:clean #:enforce)
 chicken.condition#condition->list
 ((struct condition))
 (list-of (pair symbol *

The (list-of (pair symbol *)) result type is wrong in two ways:
- the list structure has changed from "alist" to "plist", as we discussed
- exception "kind"s are not necessarily symbols

The new type therefore is:

(chicken.condition#condition->list (#(procedure #:clean #:enforce)
 chicken.condition#condition->list
 ((struct condition))
 (list-of pair)))

I chose (list-of pair) instead of just "list", because we know the
kind is always at the head of the "plist", so it's never null.

Given my observation that we incorrectly use "symbol" as the type
of kinds and properties, I went ahead and changed the other types
as well, by changing "symbol" to "*".  The patch is also for master,
given that it's so simple and the situation applies there as well.
In master, the return type of condition->list is also simply
(list-of pair), because only the structure of the cdr of these
pairs differs between master and chicken-5 (and that can be null).

Cheers,
Peter
From 033a2550a582e119095224a62e42373db2d73b64 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sat, 27 May 2017 15:56:29 +0200
Subject: [PATCH] Improve type declarations for condition-manipulation
 procedures

Condition kinds and properties do not have to be symbols: they can be
any type of object.  The only constraint according to SRFI-12 is that
they must be comparable using eqv?, so all type declarations that
assume they're symbols are wrong, strictly speaking.
---
 types.db | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/types.db b/types.db
index 3f38974..004d531 100644
--- a/types.db
+++ b/types.db
@@ -950,9 +950,9 @@
 (chicken.condition#abort (procedure chicken.condition#abort (*) noreturn))
 (chicken.condition#condition (#(procedure #:clean #:enforce) chicken.condition#condition (list #!rest list) (struct condition)))
 (chicken.condition#condition? (#(procedure #:pure #:predicate (struct condition)) chicken.condition#condition? (*) boolean))
-(chicken.condition#condition->list (#(procedure #:clean #:enforce) chicken.condition#condition->list ((struct condition)) (list-of (pair symbol *
-(chicken.condition#condition-predicate (#(procedure #:clean #:enforce) chicken.condition#condition-predicate (symbol) (procedure ((struct condition)) boolean)))
-(chicken.condition#condition-property-accessor (#(procedure #:clean #:enforce) chicken.condition#condition-property-accessor (symbol symbol #!optional *) (procedure ((struct condition)) *)))
+(chicken.condition#condition->list (#(procedure #:clean #:enforce) chicken.condition#condition->list ((struct condition)) (list-of pair)))
+(chicken.condition#condition-predicate (#(procedure #:clean #:enforce) chicken.condition#condition-predicate (*) (procedure ((struct condition)) boolean)))
+(chicken.condition#condition-property-accessor (#(procedure #:clean #:enforce) chicken.condition#condition-property-accessor (* * #!optional *) (procedure ((struct condition)) *)))
 
 (chicken.condition#current-exception-handler
  (#(procedure #:clean #:enforce) chicken.condition#current-exception-handler (#!optional (procedure (*) noreturn) boolean boolean) procedure)
@@ -961,9 +961,9 @@
 		  #(tmp1
  (() ##sys#current-exception-handler))
 (chicken.condition#get-call-chain (#(procedure #:clean #:enforce) chicken.condition#get-call-chain (#!optional fixnum (struct thread)) (list-of vector)))
-(chicken.condition#get-condition-property (#(procedure #:clean #:enforce) chicken.condition#get-condition-property ((struct condition) symbol symbol #!optional *) *))
+(chicken.condition#get-condition-property (#(procedure #:clean #:enforce) chicken.condition#get-condition-property ((struct condition) * * #!optional *) *))
 (chicken.condition#make-composite-condition (#(procedure #:clean #:enforce) chicken.condition#make-composite-condition (#!rest (struct condition)) (struct condition)))
-(chicken.condition#make-property-condition (#(procedure #:clean #:enforce) chicken.condition#make-property-condition (symbol #!rest *) (struct condition)))
+(chicken.condition#make-property-condition (#(procedure #:clean #:enforce) chicken.condition#make-property-condition (* #!rest *) (struct condition)))
 (chicken.condition#with-exception-handler (#(procedure #:enforce) chicken.condition#wit

Re: [Chicken-hackers] [PATCH][5] FQN woes

[Peter Bex]

On Tue, May 23, 2017 at 10:56:23PM +1200, Evan Hanson wrote:
> Thanks, I've pushed the first of these directly. I've also attached
> signoffs for the second, third (squashed) and fourth, editorialised
> slightly in the tests. In particular I've added a Windows test, which
> was missing.

Thanks guys!  I've also pushed the remaining patches.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Drop files.scm

[Peter Bex]

On Sat, May 27, 2017 at 01:43:30PM +0200, Peter Bex wrote:
> On Fri, May 19, 2017 at 10:11:03PM +1200, Evan Hanson wrote:
> > This was only left in place to ease the transition from the "files" and
> > "posix" units to separate "file" and "file.posix" modules. Now that some
> > of the smoke has cleared from other refactoring, we can finish the
> > rename and drop files.scm.
> 
> Thanks, applied.  I think this completes (chicken file), so I've marked
> it as [done] on the core-libraries-reorganization wiki page.

I just realised it's not completed in the sense that the definitions still
live in the "posix" file(s).  I've reset it to [partial].

I'd create a patch to move stuff, but I'm waiting for the other two
patches regarding file permissions and access times to land, first,
to avoid unnecessary conflicts.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers