Re: [Chicken-hackers] testcase -strict-types

2013-03-25 Thread Moritz Heidkamp
Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes:
 Though in a way the explanation is correct.  -strict-types assumes
 '() to be null from the initialization.  Short of a way to declare
 the type of foobar as (list-of whatever) this fails when it's used
 as the initial and correct value of type (list-of whatever) with
 zero length.

You should be able to use `the' or `assume' for that purpose.


 What the optimizer should do is to see into the doloop and notice
 the ambiguous type null being refined to a list.

Given that the description of -strict-types is assume variable do not
change their type I think the behavior is correct.


 Find attached two more variants.  strcttps2.scm, which convinces
 chicken to do the right thing, ans strcttps2.scm, which fails
 the other way around.

Right, here you initialize the variable's type with list (or pair, I
don't know what's detected) and then possible change it to null while
never checking with null? on the whole list but only on the rest. Looks
fine from what I can tell!

Moritz

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


Re: [Chicken-hackers] testcase -strict-types

2013-03-25 Thread Peter Bex
On Mon, Mar 25, 2013 at 09:58:32AM +0100, Jörg F. Wittenberger wrote:
 Though in a way the explanation is correct.  -strict-types assumes
 '() to be null from the initialization.  Short of a way to declare
 the type of foobar as (list-of whatever) this fails when it's used
 as the initial and correct value of type (list-of whatever) with
 zero length.

This seems to be a bug, unless I'm mistaken.  Could you please file a
ticket for this?  Thanks!

 What the optimizer should do is to see into the doloop and notice
 the ambiguous type null being refined to a list.

No, it shouldn't, because you've declared strict types.  That explicitly
tells it not to do this AFAICT.

I'd simply change the code to be functional, this eliminates the
problems you're having.  All this messing around with set! is
needlessly confusing (for the person reading the code as well as
the scrutinizer).

(module
 foo
 (bar)
 (import scheme chicken)

 (define (bar . args)
   (let ((foobar '()))
 (do ((rest args (cddr rest))
  (foobar '() (if (eq? (car rest) #:foobar)
  (cons (cadr rest) foobar)
  foobar)))
 ((null? rest)
  (if (null? foobar)
  'gaga
  foobar))
   (if (null? (cdr rest))
   (error (car rest))

)

(import foo)

(display (bar #:foobar 42))
(newline)


Cheers,
Peter
-- 
http://www.more-magic.net

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


Re: [Chicken-hackers] testcase -strict-types

2013-03-25 Thread Jörg F . Wittenberger

On Mar 25 2013, Moritz Heidkamp wrote:


Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes:

Though in a way the explanation is correct.  -strict-types assumes
'() to be null from the initialization.  Short of a way to declare
the type of foobar as (list-of whatever) this fails when it's used
as the initial and correct value of type (list-of whatever) with
zero length.


You should be able to use `the' or `assume' for that purpose.


Where would I find the respective assume to be documented?

(Would the syntax break standard Scheme compatibility?)





What the optimizer should do is to see into the doloop and notice
the ambiguous type null being refined to a list.


Given that the description of -strict-types is assume variable do not
change their type I think the behavior is correct.



Find attached two more variants.  strcttps2.scm, which convinces
chicken to do the right thing, ans strcttps2.scm, which fails
the other way around.


Right, here you initialize the variable's type with list (or pair, I
don't know what's detected) and then possible change it to null while
never checking with null? on the whole list but only on the rest. Looks
fine from what I can tell!




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


Re: [Chicken-hackers] testcase -strict-types

2013-03-25 Thread Moritz Heidkamp
Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes:

 [1. text/plain]

 On Mar 25 2013, Moritz Heidkamp wrote:

Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes:
 Though in a way the explanation is correct.  -strict-types assumes
 '() to be null from the initialization.  Short of a way to declare
 the type of foobar as (list-of whatever) this fails when it's used
 as the initial and correct value of type (list-of whatever) with
 zero length.

You should be able to use `the' or `assume' for that purpose.

 Where would I find the respective assume to be documented?

In the manual page about the type system,
e.g. http://wiki.call-cc.org/man/4/Types


 (Would the syntax break standard Scheme compatibility?)

They are regular Scheme syntax so you can stub them. You could use
http://wiki.call-cc.org/eggref/4/type-stubs for other Schemes, too (it
is intended to be used with older Chickens).

Moritz

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


Re: [Chicken-hackers] rounding off the heap size_t change to allow initial large heaps

2013-03-25 Thread Peter Bex
On Sun, Mar 24, 2013 at 04:32:56PM -0400, Andrei Barbu wrote:
 Hi,
 
 I've attached a patch that allows for initial large heaps given that
 heap is now a size_t.
 
 The original patch did not update CHICKEN_initialize to have a size_t heap.

I'm not sure this can just be done or requires a CR, since this is a
potentially breaking change.  At least it breaks the ABI, but it might
also break the API though AFAIK size_t should always only be larger than
int so I doubt this is really a problem.  OTOH, the original change
isn't documented in the NEWS either, so it must not have been considered
an important change.

Anyone?

 -C_fctexport int CHICKEN_initialize(int heap, int stack, int symbols,
 void *toplevel);
 +C_fctexport int CHICKEN_initialize(size_t heap, int stack, int
 symbols, void *toplevel);
 
 The patch also did not update the debugging message in
 C_set_or_change_heap_size.
 -C_dbg(C_text(debug), C_text(heap resized to %d bytes\n), (int)heap);
 +C_dbg(C_text(debug), C_text(heap resized to %zu bytes\n), heap);
 %zu is a C99-ism, I don't know if people are ok with that.

So far, generally we've avoided these because they're not very portable.
We don't really have an official policy on this, but I guess if we're
going to use size_t consistently, we should use the matching printf
specifiers too.

The patch itself is fine, so at least here's a signed-off version, which
can be pushed as soon as we've figured out how to do this.

Cheers,
Peter
-- 
http://www.more-magic.net
From 5ecae6a4548339313927ccfe0ef16e7320d5065e Mon Sep 17 00:00:00 2001
From: Peter Bex peter@xs4all.nl
Date: Mon, 25 Mar 2013 20:49:30 +0100
Subject: [PATCH] 623c46bea299fa8fb2e5702661a8e3def1016984 didn't make
 CHICKEN_initialize's initial heap size argument a size_t.  This fixes that
 (thanks to Andrei Barbu)

---
 NEWS  | 2 ++
 chicken.h | 2 +-
 runtime.c | 4 ++--
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index a34fbe0..f886245 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,8 @@
 
 - C API
   - Deprecated C_get_argument[_2] and C_get_environment_variable[_2] functions.
+  - CHICKEN_initialize now accepts a size_t for its initial heap size,
+allowing it to exceed 4GB on 64-bit systems (thanks to Andrei Barbu).
 
 4.8.1
 
diff --git a/chicken.h b/chicken.h
index 2b9030a..6d8a2fe 100644
--- a/chicken.h
+++ b/chicken.h
@@ -1627,7 +1627,7 @@ C_varextern C_TLS C_word 
(*C_get_unbound_variable_value_hook)(C_word sym);
 C_BEGIN_C_DECLS
 
 C_fctexport int CHICKEN_main(int argc, char *argv[], void *toplevel);
-C_fctexport int CHICKEN_initialize(int heap, int stack, int symbols, void 
*toplevel);
+C_fctexport int CHICKEN_initialize(size_t heap, int stack, int symbols, void 
*toplevel);
 C_fctexport C_word CHICKEN_run(void *toplevel);
 C_fctexport C_word CHICKEN_continue(C_word k);
 C_fctexport void *CHICKEN_new_gc_root();
diff --git a/runtime.c b/runtime.c
index 099dbdc..e46fb6a 100644
--- a/runtime.c
+++ b/runtime.c
@@ -600,7 +600,7 @@ void parse_argv(C_char *cmds)
 
 /* Initialize runtime system: */
 
-int CHICKEN_initialize(int heap, int stack, int symbols, void *toplevel)
+int CHICKEN_initialize(size_t heap, int stack, int symbols, void *toplevel)
 {
   int i;
 #ifdef HAVE_SIGACTION
@@ -1151,7 +1151,7 @@ void C_set_or_change_heap_size(C_word heap, int reintern)
   if(fromspace_start  heap_size = heap) return;
 
   if(debug_mode)
-C_dbg(C_text(debug), C_text(heap resized to %d bytes\n), (int)heap);
+C_dbg(C_text(debug), C_text(heap resized to %zu bytes\n), heap);
 
   heap_size = heap;
 
-- 
1.8.0.1

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