Re: [Chicken-hackers] testcase -strict-types
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
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
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
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
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