Re: [PATCH] export/rename
Maybe this already works with the current patch, but can we support: (export (rename foo bar)) As well as the version with the colon (suffix keyword notation) on the end of export? Seems like that would be best for symmetry with the import form. (Sorry, it’s just aesthetics, I know.) Evan > On 3/10/2023, at 11:51 PM, felix.winkelm...@bevuta.com wrote: > >> On Mon, Oct 02, 2023 at 06:31:44PM +0200, felix.winkelm...@bevuta.com wrote: >>> This patch adds a new special form to explicitly export renamed bindings >>> from a module: >>> >>>(export/rename (OLD NEW) ...) >> >> Why not add it to the regular "export" form? It's already extendable, >> as it has syntax: and interface:. So for example we could have: >> >> (export (rename: OLD NEW) ...) >> >> Saves having yet another top-level special-case form. > > Ok, I find attached a variant, both more ugly in interface and > implementation, since ##core#module and functor do not yet allow > renamings to be handled. Also, "define-interface" has no notion > of this, so "(rename: OLD NEW)" is purely applicable in "export". > > I prefer the first variant, but feel free to push which one you > like more. > > > felix > <0001-allow-renaming-exports-in-export-form.patch>
Re: [PATCH] Restore read/source-info in support.scm and export it officially from (chicken syntax)
Hi there, On 2023-06-30 9:11, Peter Bex wrote: > Since these eggs are using it, that TODO above ##sys#read/source-info > is settled - it's useful enough for those eggs, so let's just expose > it publically and document it. I wouldn't read too much into those eggs -- most of those are mine, and they're mostly (all?) failing because read/source-info was used in module-declarations, which is a dependency of the whole lot. So, many of those failures only represent a single use of that procedure. That's not to say we shouldn't still expose it -- probably we should? -- I just wanted to point this out so I'm not inflating the statistics. :) Evan
[PATCH] Pass executed filename to execv[pe] unmodified when calling process-execute
Hi there, Earlier today I went in circles trying to figure out why a child process was only getting the basename of the executable in argv[0], rather than the pathname I was passing. Turns out we do that when building the arguments to execvp, but I don't think it's ideal, so here's a patch to leave that pathname alone. Cheers, Evan >From 82cd4c9a8fe4434f7db9e2eb9599a470a8442b3e Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Sun, 4 Jun 2023 00:55:02 +0200 Subject: [PATCH] Pass executed filename to execv[pe] unmodified when calling process-execute Programs created via `process-execute` cannot currently determine their real location from argv[0], since the directory part is discarded before the executed filename is added to argv[0]. This change simply passes the filename verrbatim, which is less surprising. --- NEWS | 2 ++ posix-common.scm | 3 +-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 6ecbbad2..76902eed 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,8 @@ - Added "locative-index", kindly contributed by John Croisant. - Added "fp*+" (fused multiply-add) to "chicken.flonum" module (suggested by Christian Himpe). + - The `process-execute` procedure now sets argv[0] to the unmodified +filename. Previously, the directory part would be stripped. - Tools - The -R option for csi and csc now accepts list-notation like diff --git a/posix-common.scm b/posix-common.scm index caa19e57..76ad3930 100644 --- a/posix-common.scm +++ b/posix-common.scm @@ -712,8 +712,7 @@ EOF (let ((pathname-strip-directory pathname-strip-directory) (nop (lambda (x) x))) (lambda (loc filename argconv arglist envlist proc) - (let* ((stripped-filename (pathname-strip-directory filename)) -(args (cons stripped-filename arglist)) ; Add argv[0] + (let* ((args (cons filename arglist)) ; Add argv[0] (argbuf (list->c-string-buffer args argconv loc)) (envbuf #f)) -- 2.40.1
Re: [PATCH] always check servers if version not given
Applied! Lots of tickets closed lately, very cool. Evan On 2022-10-21 12:22, felix.winkelm...@bevuta.com wrote: > Make sure we check for the newest version, if performing an egg install > without an explicitly given version. See also #1802. > > > felix > From 90113bde332cf6b5b37ae0043390a181eb665b29 Mon Sep 17 00:00:00 2001 > From: felix > Date: Fri, 21 Oct 2022 12:20:47 +0200 > Subject: [PATCH] Fix update logic for eggs without given version. > > Make sure to check servers for newest available version. > See also #1802. > > Signed-off-by: felix > --- > chicken-install.scm | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/chicken-install.scm b/chicken-install.scm > index 524cf0a1..14333ce4 100644 > --- a/chicken-install.scm > +++ b/chicken-install.scm > @@ -447,12 +447,11 @@ > (and (file-exists? vfile) >(with-input-from-file vfile read) >(cond ((and (not cached-only) > - (or (and (string? version) > - (not (equal? version lversion))) > - (and (or (not (file-exists? tfile)) > - (> (- now (with-input-from-file tfile read)) > - +one-hour+)) > - (not (check-remote-version name lversion > cached) > + (if (string? version) > + (not (equal? version lversion)) > + (or (and (file-exists? tfile) > + (> (- now (with-input-from-file tfile read)) > +one-hour+)) > + (not (check-remote-version name lversion > cached) > (d "version of ~a out of date~%" name) > (fetch #t) > (let* ((info (validate-egg-info (load-egg-info eggfile))) ; new > egg info (fetched) > -- > 2.28.0 >
Re: [PATCH] make types-files more deterministic
On 2022-10-21 15:50, felix.winkelm...@bevuta.com wrote: > This patch changes the code in the scrutinizer to output types > file entries in sorted order. Nice change, pushed! Evan
Re: absolute pathname a.k.a. realpath
On 2022-10-25 11:52, felix.winkelm...@bevuta.com wrote: > Does (make-absolute-pathname #f ...) make any sense with the currently > implemented behaviour? It seems to me that this case could handle the > operation as requested by sandra. I think that would be the ideal, yeah, if you could use #f for this. I just don't know if anyone is relying on the current (useless?) behaviour, and whether that would need to be considered a breaking change... But, breakage aside, it does make the most sense to me! Evan
Re: absolute pathname a.k.a. realpath
On 2022-10-24 14:14, John Cowan wrote: > As designed, the pathname module does not access the filesystem (except > that it knows whether the default is Posix or Windows), and I'd like to > keep it that way. Realpath is available in the Posix module. I'd tend to agree with John. Path resolution is kind of a different thing. (Although technically I don't think realpath(3) is available directly, you can use `read-symbolic-link' with the "canonicalize" argument set.) Evan
Re: absolute pathname a.k.a. realpath
On 2022-08-18 10:23, Sandra Snan wrote: > Would you please add something like this to the pathname module? > > (define (absolute-pathname name) > (normalize-pathname >(if (absolute-pathname? name) name >(make-absolute-pathname (current-directory) name > > Whatever you wanna call it, I'm not married to the name. FWIW this appears in almost all the programs I write, too, so I'd also like to see it added. I think rather than adding something new to core, the ideal would be for the existing `make-absolute-pathname` procedure to do this when the first argument is #f. That one is kind of squatting on the optimal name and seems like the right place for this. But, that's backwards-incompatible, so isn't really possible in the 5.x release series. Maybe `make-absolute-pathname` could accept one, two or three arguments. When there's one, it's `file`, we get this behaviour you want. When two or more, it's `dirs` and `file` and the behaviour stays the same. Curious to know what others think. Evan
Re: [PATCH] add fp*+ operator
Cool! I've applied this to master. All the best, Evan
Re: [PATCH] Expose csi toplevel REPL driver
Cool, good idea! That's a really nice addition. Applied. Evan
Re: [PATCH 0/3] Clarify built-in library/SRFI feature behaviour
On 2021-10-19 12:20, felix.winkelm...@bevuta.com wrote: > I wanted to try it, but patch #1 does not apply. Ah, sorry about that. Updated versions attached! Evan >From d7ef79a885d7fc02b2a893e3e000a30db1cac899 Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Mon, 18 Oct 2021 17:00:20 +1300 Subject: [PATCH 1/3] Simplify library requirement processing This is a "clarity" patch that simplifies the handling of `##core#require` forms and tries to improve the naming of a couple of related identifiers to keep things internally consistent. First, rename the `core-unit?` procedure to `core-library?`, since it's used to check all library IDs encountered during compilation and not just units. Then, use that procedure to check whether a library should be added to the list of `required-libraries` directly within core.scm, rather than returning multiple values from `##sys#process-require`. This separates the logic for determining whether something is built-in from the compiler's handling of `##core#require` forms a little more cleanly. If something is a `core-library?` it should _not_ be added to the list, else it should, the result being that `required-libraries` contains only things that needs to be treated as an extension (and thus linked from the eggs repository), and the interpreter doesn't have to care about any of these decisions at all. Then, because what we're building is really a list of _extensions_ that need to be linked, rename `required-libraries` to `required-extensions`. And finally, drop the list of `builtin-features`, which do not actually need any special treatment from a library-loading point of view. --- batch-driver.scm | 4 ++-- core.scm | 23 ++- eval.scm | 45 + 3 files changed, 29 insertions(+), 43 deletions(-) diff --git a/batch-driver.scm b/batch-driver.scm index 6f1d5f56..5ca2eedc 100644 --- a/batch-driver.scm +++ b/batch-driver.scm @@ -676,7 +676,7 @@ (initialize-analysis-database) ;; collect requirements and load inline files - (let ((extensions required-libraries)) + (let ((extensions required-extensions)) (when enable-inline-files (for-each (lambda (id) @@ -851,7 +851,7 @@ ;; generate link file (when emit-link-file - (let ((exts required-libraries)) + (let ((exts required-extensions)) (dribble "generating link file `~a' ..." emit-link-file) (with-output-to-file emit-link-file (cut pp exts diff --git a/core.scm b/core.scm index 0b980913..e35e40ca 100644 --- a/core.scm +++ b/core.scm @@ -315,7 +315,7 @@ extended-bindings standard-bindings ;; Non-booleans set and read by the (batch) driver - required-libraries linked-libraries used-libraries + required-extensions linked-libraries used-libraries ;; non-booleans set by the (batch) driver, and read by the (c) backend target-heap-size target-stack-size unit-name used-units @@ -450,7 +450,7 @@ (define callback-names '()) (define toplevel-scope #t) (define toplevel-lambda-id #f) -(define required-libraries '()) +(define required-extensions '()) (define linked-libraries '()) (define used-libraries '()) @@ -738,17 +738,14 @@ ((##core#require) (let ((lib (cadr x)) (mod (and (pair? (cddr x)) (caddr x - (let-values (((reqform builtin) - (##sys#process-require - lib mod - (if (or (memq lib linked-libraries) - static-extensions) - 'static - 'dynamic - (unless builtin - (set! required-libraries - (lset-adjoin/eq? required-libraries lib))) - (walk reqform e dest ldest h ln #f + (unless (chicken.load#core-library? lib) +(set! required-extensions (lset-adjoin/eq? required-extensions lib))) + (walk (##sys#process-require + lib mod + (if (or (memq lib linked-libraries) static-extensions) + 'static + 'dynamic)) +e dest ldest h ln #f))) ((##core#let) (let* ((bindings (cadr x)) diff --git a/eval.scm
Re: [PATCH 0/3] Clarify built-in library/SRFI feature behaviour
On 2021-10-18 13:31, felix.winkelm...@bevuta.com wrote: > As far as I can tell builtin-features has simply been dropped. How do you > avoid having 'srfi-9 as a requirement? Yeah, that's what the second patch is all about. Since SRFI-9 is a syntax-only module (defined in modules.scm), we can no-op right away when it's imported by marking the module as having "no library" rather than needlessly introducing a `##core#require` form during expansion only to ignore it later during compilation. The same goes for srfi-0, 2, 6, etc. all of those primitive modules. There are fewer moving parts this way, less code involved. > I also don't fully understand why you try so hard to void the multiple value > return of ##sys#process-require. It's not particularly elegant, I admit, but > it looks like the obvious solution here to centralize the decision of what > to do with a requirement ID. Elegance partly, yes, but I also think it is just easier to understand this way. That second value is only used in one place, in core.scm. It's totally ignored in eval.scm and only adds noise to the code there. So, the value is being introduced apart from where it's used, and you have to look in both places to understand what it represents. Because it's only core.scm that needs to determine whether a library is part of core, and we control both sides of this "API" (such as it is), we can separate the tasks and give a better name to the procedure that does this (that is what "core-library?" is for), and call it directly. I'm proposing this because, having gone through the "how is code loaded" machinery a while back, I remember how hard it was to understand some parts of it. The multi-values approach seems needlessly indirect to me, per the above, so I was just looking for ways to clarify things further, building on your changes. Evan
[PATCH 0/3] Clarify built-in library/SRFI feature behaviour
Hi folks, After thinking about #1788 a little bit more I've came up with a few small "code clarity" patches. They don't change the existing solution at all, they're just to simplify the code after looking at it with fresh eyes. Partly, I realised the naming of that "required-libraries" wasn't great, but I also liked that I'd originally been able to simplify `##sys#process-require` so it only returned a single value, and wanted to see if we could preserve that. I think the result is nice and tidy, see if you agree. Looking into this also made me realise that all of the short-circuiting we do when handling require forms for built-in libraries wasn't actually necessary, since we can avoid hitting that code path altogether by simply not adding libraries for those, which is patch number two. And then, once I was already down that rabbit hole, I went through all of the SRFI-related feature identifiers to make sure they were registered in the right files, and that the documentation was up to date. That's patch number three, have a look and let me know what you think. All the best, Evan >From 5458c9b049aef8e4f22581ca0ed529fac8c49ccc Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Mon, 18 Oct 2021 17:00:20 +1300 Subject: [PATCH 1/3] Simplify library requirement processing This is a "clarity" patch that simplifies the handling of `##core#require` forms and tries to improve the naming of a couple of related identifiers to keep things internally consistent. First, rename the `core-unit?` procedure to `core-library?`, since it's used to check all library IDs encountered during compilation and not just units. Then, use that procedure to check whether a library should be added to the list of `required-libraries` directly within core.scm, rather than returning multiple values from `##sys#process-require`. This separates the logic for determining whether something is built-in from the compiler's handling of `##core#require` forms a little more cleanly. If something is a `core-library?` it should _not_ be added to the list, else it should, the result being that `required-libraries` contains only things that needs to be treated as an extension (and thus linked from the eggs repository), and the interpreter doesn't have to care about any of these decisions at all. Then, because what we're building is really a list of _extensions_ that need to be linked, rename `required-libraries` to `required-extensions`. And finally, drop the list of `builtin-features`, which do not actually need any special treatment from a library-loading point of view. --- batch-driver.scm | 4 ++-- core.scm | 23 ++- eval.scm | 45 + 3 files changed, 29 insertions(+), 43 deletions(-) diff --git a/batch-driver.scm b/batch-driver.scm index 6f1d5f56..5ca2eedc 100644 --- a/batch-driver.scm +++ b/batch-driver.scm @@ -676,7 +676,7 @@ (initialize-analysis-database) ;; collect requirements and load inline files - (let ((extensions required-libraries)) + (let ((extensions required-extensions)) (when enable-inline-files (for-each (lambda (id) @@ -851,7 +851,7 @@ ;; generate link file (when emit-link-file - (let ((exts required-libraries)) + (let ((exts required-extensions)) (dribble "generating link file `~a' ..." emit-link-file) (with-output-to-file emit-link-file (cut pp exts diff --git a/core.scm b/core.scm index 0b980913..e35e40ca 100644 --- a/core.scm +++ b/core.scm @@ -315,7 +315,7 @@ extended-bindings standard-bindings ;; Non-booleans set and read by the (batch) driver - required-libraries linked-libraries used-libraries + required-extensions linked-libraries used-libraries ;; non-booleans set by the (batch) driver, and read by the (c) backend target-heap-size target-stack-size unit-name used-units @@ -450,7 +450,7 @@ (define callback-names '()) (define toplevel-scope #t) (define toplevel-lambda-id #f) -(define required-libraries '()) +(define required-extensions '()) (define linked-libraries '()) (define used-libraries '()) @@ -738,17 +738,14 @@ ((##core#require) (let ((lib (cadr x)) (mod (and (pair? (cddr x)) (caddr x - (let-values (((reqform builtin) - (##sys#process-require - lib mod - (if (or (memq lib linked-libraries) - static-extensions) -
Re: [PATCH] Check argument type for setters in (chicken process-context posix)
Looks good, applied to both prerelease and master. Thanks Peter, and thank you Chris for testing as well. Evan
Re: Release process?
On 2021-08-06 10:59, Peter Bex wrote: > Evan just closed the last ticket in our roadmap for 5.3 > (https://bugs.call-cc.org/roadmap). So I think now is a good > time to start the (pre)release process. Yeah, I think we should go ahead too. ISTM the remaining questions have been answered? But even if I'm missing one they don't seem like the kind of issues to block a release candidate. Evan
Re: [PATCH] Add regression test for #1771
Works for me, applied. Thanks Peter! Evan
Re: A facility for debugging type issues
Hey megane! On 2021-04-10 11:24, megane wrote: > here's a POC tool I've been using for a year. It prints the types known to > scrutinizer in the current scope. Finally having a look at this, and I have to say, it is very cool. It still applies cleanly too! :) What were you thinking ought to be done with it? Personally I think a facility like this would be very nice to add "for real", if it were guarded behind a debugging flag of some kind (maybe another "-debug" option?), or perhaps only enabled with DEBUGBUILD. So, normal compilation would just ignore these nodes, but we could still add the feature properly. Was that your thinking? Cheers, Evan
Re: [PATCH] Fix #1757 by not merging module environment into the syntactic environments of reexported macros
On 2021-07-14 12:45, Peter Bex wrote: > Here's a reasonably straightforward patch (I hope) for #1757. > Commit should speak for itself, even if the stuff itself is > a bit tricky. It really is, this took some time to understand... But it does seem like the right thing, now that you've spelled it out. I was wondering whether there are any implications in changing the order of the `sexports` field of the module, now that we're putting all "normal" syntax exports before any re-exported ones. However, after a bit of digging, I don't think this should matter? Anyway, applied. Thank you Peter! Evan
Re: Misc scrutizer annotation fixes for FFI
Nice, thanks megane, these are all nice improvements. I've applied the whole lot. I expanded the commit message for the last patch a bit, since I didn't realise at first that it was fixing both the return type (using forall) and the argument types (changing false to locative). Cheers, Evan
Re: [PATCH] Fix #1727 with patch from ticket
Excellent, applied. Thanks to all involved, this should make some folks' lives easier! Evan
Re: uname -o does not exist on mac
Nice, thanks Lassi and Mario, applied. Evan
Re: [PATCH] Small chicken.h fix to make taglib compile on MinGW
On 2021-04-19 19:15, Vasilij Schneidermann wrote:
> I've tried installing the taglib egg on my MinGW setup today and found
> that including chicken.h in C++ mode fails with "invalid conversion from
> 'void*' to 'char*' [-fpermissive]". The included patch fixes this
> problem.
LGTM, signoff attached.
Evan
>From 9dc7525a7458a48fd0667689d80027bd8d8eefe1 Mon Sep 17 00:00:00 2001
From: Vasilij Schneidermann
Date: Mon, 19 Apr 2021 19:11:20 +0200
Subject: [PATCH] Cast the alloca result to make C++ on MinGW happy
Signed-off-by: Evan Hanson
---
chicken.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/chicken.h b/chicken.h
index 0b9c2613..7e51a38f 100644
--- a/chicken.h
+++ b/chicken.h
@@ -3523,7 +3523,7 @@ inline static int C_stat(const char *path, struct stat
*buf)
goto dircheck;
if(slash && errno == ENOENT) {
-C_strlcpy((str = C_alloca(len + 1)), path, len + 1);
+C_strlcpy((str = (char *)C_alloca(len + 1)), path, len + 1);
while(len > 1 && C_strchr("\\/", path[--len]))
str[len] = '\0';
if(stat(str, buf) == 0)
--
2.29.3
Re: [PATCH] Quit compiling when an invalid import-Library declaration is encountered
Imagine that last email had a nice descriptive subject, like this one. Evan
[no subject]
Thanks megane! On 2021-04-22 14:00, megane wrote: > ITYM it'll never trigger an error, even if the the filname is symbol for > example. In the use case where FILENAME is a string you will hit this: $ csc -analyze-only - < to be added to the alist of import libraries, leading to an error later in the compilation process: $ csc -analyze-only - < Attached is a fix for *this* issue, in which we "quit-compiling" rather than warn when the declaration is invalid. Sorry I didn't notice this in the first place! Evan >From 92fc80908427cf8c998d397eb7541db6190210dc Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Fri, 23 Apr 2021 12:06:54 +1200 Subject: [PATCH] Quit compiling when an invalid import-Library declaration is encountered --- core.scm | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/core.scm b/core.scm index f624781d..a6f8d3cf 100644 --- a/core.scm +++ b/core.scm @@ -1719,8 +1719,7 @@ (symbol? (car il)) (string? (cadr il))) (cons (car il) (cadr il))) (else -(warning - "invalid import-library specification" il +(quit-compiling "invalid `import-library' specification: ~S" il (strip-syntax (cdr spec)) ((emit-types-file) (unless types-output-file -- 2.29.3
[PATCH 1/1] Fix typo'd procedure name in "emit-import-library" declaration handling
This is intended to check for a pair of strings when this declaration is
used in its `(MODULENAME FILENAME)' form, but we currently use `string'
instead of `string?' to check the second item, which will always trigger
an error ("bad argument type").
---
core.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/core.scm b/core.scm
index e548bbc0..9e5a8c62 100644
--- a/core.scm
+++ b/core.scm
@@ -1717,7 +1717,7 @@
(cond ((symbol? il)
(cons il (string-append (symbol->string il)
".import.scm")) )
((and (list? il) (= 2 (length il))
- (symbol? (car il)) (string (cadr il)))
+ (symbol? (car il)) (string? (cadr il)))
(cons (car il) (cadr il)))
(else
(warning
--
2.29.3
[PATCH 0/1] Fix typo'd procedure name in "emit-import-library" declaration handling
Hi there, This is just the fix that was included in the earlier declarations changes, which megane rightly dropped from that patch since it wasn't really related. It makes this form of the "emit-import-library" declaration work again: (declare (emit-import-library (MODULE FILENAME))) Cheers, Evan
[PATCH 2/2] Fall back to null when gathering components for "chicken-status -c" output
--- chicken-status.scm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/chicken-status.scm b/chicken-status.scm index b9dfd759..1b79349f 100644 --- a/chicken-status.scm +++ b/chicken-status.scm @@ -143,7 +143,8 @@ ((c-include) (list (list 'c-include mode (cadr info ((scheme-include) (list (list 'scheme-include mode (cadr info ((program) (list (list 'program mode (cadr info - ((c-object) (list (list 'c-object mode (cadr info)) + ((c-object) (list (list 'c-object mode (cadr info + (else '( (define (list-installed-components eggs) (let ((w (quotient (- (get-terminal-width) 2) 2))) -- 2.29.3
[PATCH 1/2] Include `c-object' components in "chicken-status -c" output
--- chicken-status.scm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/chicken-status.scm b/chicken-status.scm index 7e3e73f7..b9dfd759 100644 --- a/chicken-status.scm +++ b/chicken-status.scm @@ -142,7 +142,8 @@ ((generated-source-file) (list (list 'generated-source-file mode (cadr info ((c-include) (list (list 'c-include mode (cadr info ((scheme-include) (list (list 'scheme-include mode (cadr info - ((program) (list (list 'program mode (cadr info)) + ((program) (list (list 'program mode (cadr info + ((c-object) (list (list 'c-object mode (cadr info)) (define (list-installed-components eggs) (let ((w (quotient (- (get-terminal-width) 2) 2))) -- 2.29.3
[PATCH 0/2] Fix error in "chicken-status -c" when c-object components are installed
Currently, listing components with chicken-status fails when any egg includes a `c-object'. To reproduce, just run: chicken-install tweetnacl chicken-status -c The first patch adds a case for `c-object' in the procedure that gathers installed egg components, and the second patch adds a default case that will prevent this problem whenever we add more component types in the future (it's optional, and we could produce a more specific error instead, but this seemed like a natural safety valve). Cheers, Evan
Re: FIXED [PATCH] Report more information for unresolved identifiers in modules
Cool, here is a signed off copy. But, I made some small changes, so if you or another hacker could have a look just to make sure you're OK with it? I fixed two places where the `resolve-variable` procedure didn't have the new `outer-ln` argument passed through, and one typo in a string (changed "in2" to "in"). These are pretty small tweaks, and necessary. But, I also capitalised the output messages to match the style in scrutinizer.scm and it now looks like the below when suggesting things, these are stylistic changes so I didn't want to push them directly, someone else can have a look and do that: Error: Module `mod' has unresolved identifiers In file `test.scm': Unknown identifier `bar' In procedure `foo' on line 10 Suggestion: try importing module `lexgen' Unknown identifier `last' On line 12 On line 17 Suggestion: try importing module `srfi-1' Unknown identifier `baz' On line 13 On line 16 Unknown identifier `string-index' In procedure `foo' on line 14 In procedure `quux' on line 20 Suggestion: try importing one of these modules: srfi-130 srfi-152 utf8-srfi-13 srfi-13 Cheers, Evan >From e7db0e600e2331ce2031d4090cc20028422e9f06 Mon Sep 17 00:00:00 2001 From: megane Date: Fri, 9 Apr 2021 17:04:52 +0300 Subject: [PATCH] Report more information for unresolved identifiers in modules The new format gives more clues to resolve unresolved identifiers warnings. Especially compare the messages for 'last' below. Given this input: (module mod () (import scheme) (define-syntax mac (ir-macro-transformer (lambda (e i c) `(last (define (foo) (+ bar) (lambda () (mac) (+ baz)) (+ fx+) (lambda () (+ baz) (mac))) (define (quux) (+ fx+)) ) Signed-off-by: Evan Hanson --- core.scm| 13 +++ modules.scm | 108 ++-- 2 files changed, 78 insertions(+), 43 deletions(-) diff --git a/core.scm b/core.scm index cdfbefa2..8d459702 100644 --- a/core.scm +++ b/core.scm @@ -565,7 +565,7 @@ (cadr x) x) ) - (define (resolve-variable x0 e dest ldest h) + (define (resolve-variable x0 e dest ldest h outer-ln) (when (memq x0 unlikely-variables) (warning (sprintf "reference to variable `~s' possibly unintended" x0) )) @@ -596,7 +596,7 @@ (finish-foreign-result ft body) t) e dest ldest h #f #f - ((not (memq x e)) (##sys#alias-global-hook x #f h)) ; only if global + ((not (memq x e)) (##sys#alias-global-hook x #f (cons h outer-ln))) ; only if global ((assq x forbidden-refs) => (lambda (a) (let ((ln (cdr a))) @@ -631,7 +631,7 @@ (define (walk x e dest ldest h outer-ln tl?) (cond ((keyword? x) `(quote ,x)) - ((symbol? x) (resolve-variable x e dest ldest h)) + ((symbol? x) (resolve-variable x e dest ldest h outer-ln)) ((not (pair? x)) (if (constant? x) `(quote ,x) @@ -682,9 +682,9 @@ ,(walk (cadddr x) e dest ldest h ln tl?))) ((##core#local-specialization) -(let* ((name (resolve-variable (cadr x) e dest ldest h)) +(let* ((name (resolve-variable (cadr x) e dest ldest h outer-ln)) (raw-alias (caddr x)) - (resolved-alias (resolve-variable raw-alias e dest ldest h)) + (resolved-alias (resolve-variable raw-alias e dest ldest h outer-ln)) (specs (##sys#get name '##compiler#local-specializations '( (letrec ((resolve-alias (lambda (form) (cond ((pair? form) (cons (resolve-alias (car form)) (resolve-alias (cdr form @@ -798,8 +798,7 @@ ((##core#with-forbidden-refs) (let* ((loc (caddr x)) (vars (map (lambda (v) - (cons (resolve-variable v e dest - ldest h) + (cons (resolve-variable v e dest ldest h outer-ln) loc)) (cadr x (fluid-let ((forbidden-refs diff --git a/modules.scm b/modules.scm index 4f9b507b..cecd4f02 100644 --- a/modules.scm +++ b/modules.scm @@ -42,7 +42,9 @@ chicken.internal chicken.keyword chicken.platform - ch
Re: FIXED [PATCH] Report more information for unresolved identifiers in modules
Hi megane, This is really nice, I like it a lot because it shares a "look and feel" with the scrutiny messages. I'll take a look. Just one question right away, though, rather than "hint" can we say "suggestion"? The word hint to me makes it seem like the compiler knows the answer, but we are really just guessing what the user meant. Evan
[PATCH] Add `emit-types-file` declaration
---
NEWS| 3 +++
batch-driver.scm| 12 +++-
core.scm| 12 ++--
manual/Declarations | 10 ++
4 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/NEWS b/NEWS
index 18c225c5..448fc1ac 100644
--- a/NEWS
+++ b/NEWS
@@ -45,6 +45,9 @@
- Compiler
- Avoid re-using argvector when inline rest operations are being
used in CPS calls (#1703, thanks to Jakob L. Keuze).
+ - An `emit-types-file` declaration has been added, which corresponds
+to the compiler flag of the same name (#1644, thanks to Marco Maggi
+for the suggestion).
- Build system
- Auto-configure at build time on most platforms. Cross-compilation
diff --git a/batch-driver.scm b/batch-driver.scm
index 857dfbad..78296c9d 100644
--- a/batch-driver.scm
+++ b/batch-driver.scm
@@ -232,7 +232,6 @@
(time-breakdown #f)
(forms '())
(inline-output-file #f)
- (type-output-file #f)
(profile (or (memq 'profile options)
(memq 'accumulate-profile options)
(memq 'profile-name options)))
@@ -392,7 +391,7 @@
(set! local-definitions #t)
(set! inline-output-file (option-arg ifile)))
(and-let* ((tfile (memq 'emit-types-file options)))
- (set! type-output-file (option-arg tfile)))
+ (set! types-output-file (option-arg tfile)))
(and-let* ([inlimit (memq 'inline-limit options)])
(set! inline-max-size
(let ([arg (option-arg inlimit)])
@@ -759,9 +758,12 @@
(when (memq 'v debugging-chicken)
(dump-global-refs db))
;; do this here, because we must make sure we have a db
- (when type-output-file
-(dribble "generating type file `~a' ..."
type-output-file)
-(emit-types-file filename type-output-file db
block-compilation)))
+ (and-let* ((tfile (or (and (eq? types-output-file #t)
+ (pathname-replace-extension
filename "types"))
+(and (string? types-output-file)
+ types-output-file
+(dribble "generating type file `~a' ..." tfile)
+(emit-types-file filename tfile db block-compilation)))
(set! first-analysis #f)
(end-time "analysis")
(print-db "analysis" '|4| db i)
diff --git a/core.scm b/core.scm
index fa19c354..4001fa05 100644
--- a/core.scm
+++ b/core.scm
@@ -49,6 +49,7 @@
; (compile-syntax)
; (disable-interrupts)
; (emit-import-library { | ( )})
+; (emit-types-file [])
; (export {})
; (fixnum-arithmetic)
; (foreign-declare {})
@@ -299,7 +300,7 @@
optimize-leaf-routines standalone-executable undefine-shadowed-macros
verbose-mode local-definitions enable-specialization block-compilation
inline-locally inline-substitutions-enabled strict-variable-types
- static-extensions emit-link-file
+ static-extensions emit-link-file types-output-file
;; These are set by the (batch) driver, and read by the (c) backend
disable-stack-overflow-checking emit-trace-info external-protos-first
@@ -422,6 +423,7 @@
(define enable-specialization #f)
(define static-extensions #f)
(define emit-link-file #f)
+(define types-output-file #f) ; #t |
;;; Other global variables:
@@ -1711,12 +1713,18 @@
(cond ((symbol? il)
(cons il (string-append (symbol->string il)
".import.scm")) )
((and (list? il) (= 2 (length il))
- (symbol? (car il)) (string (cadr il)))
+ (symbol? (car il)) (string? (cadr il)))
(cons (car il) (cadr il)))
(else
(warning
"invalid import-library specification" il
(strip-syntax (cdr spec))
+ ((emit-types-file)
+(unless types-output-file
+ (set! types-output-file
+(or (null? (cdr spec))
+(and (string? (cadr spec)) (null? (cddr spec)) (cadr spec))
+(quit-compiling "invalid `emit-types-file' declaration: ~S"
spec)
((profile)
(set! emit-profile #t)
(cond ((null? (cdr spec))
diff --git a/manual/Declarations b/manual/Declarations
index 52500dc4..04132afc 100644
--- a/manual/Declarations
+++ b/manual/Declarations
@@ -114,6 +114,16 @@ Note that the import library is only generated if it
cannot be found in the curr
directory, or if it exists but is not equal to the one that would be generated.
+=== emit-types-file
+
+ [declaration specifier] (emit-types-file [FILENAME])
+
+Enables generation of a types file for the current compilation unit, which will
+be written to the specified
[PATCH 0/1] Add `emit-types-file` declaration
Hi there, This small patch closes #1644. Thanks to Marco Maggi for suggesting this feature in a chicken-users thread from a while back. Cheers, Evan
[PATCH 1/1] Allow "-cached" flag with chicken-install for local egg file
--- chicken-install.mdoc | 2 +- chicken-install.scm | 6 ++ 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/chicken-install.mdoc b/chicken-install.mdoc index 0bc1f788..c540e7e0 100644 --- a/chicken-install.mdoc +++ b/chicken-install.mdoc @@ -98,7 +98,7 @@ which has the same format as .Fl list No output. This option may be given multiple times. .It Fl cached -Install given eggs from cache and do not download. +Only install eggs from cache, do not download. .It Fl feature , Fl D Ar name Register feature .Ar name , diff --git a/chicken-install.scm b/chicken-install.scm index d1a57319..efcb47c1 100644 --- a/chicken-install.scm +++ b/chicken-install.scm @@ -429,7 +429,7 @@ (cond ((or (not (probe-dir cached)) (not (file-exists? eggfile))) (d "~a not cached~%" name) - (when cached-only (error "extension not cached")) + (when cached-only (error "extension not cached" name)) (fetch #f)) ((and (file-exists? status) (not (equal? current-status @@ -1011,9 +1011,7 @@ (purge-mode (purge-cache eggs)) (print-repository (print (install-path))) ((null? eggs) - (cond (cached-only - (error "`-cached' needs explicit egg list")) - (list-versions-only + (cond (list-versions-only (print "no eggs specified")) (else (let ((files (glob "*.egg" "chicken/*.egg"))) -- 2.29.2
[PATCH 0/1] Allow "-cached" flag with chicken-install for local egg file
Hi folks, I noticed that "chicken-install -cached" can be used to restrict chicken-install to only installing from the cache when you name eggs on the command line, but not when you it to install from a local egg file (i.e. by just running "chicken-install" without any egg name). But, I don't think that restriction is necessary, and "-cached" can apply usefully to both situations. So, this patch removes that test and early exit when the flag is used with no arguments. Thoughts? Evan
Re: [PATCH] Fix #1725 by adding optional argument for scheme#log to types.db
On 2021-01-13 8:48, Peter Bex wrote: > Here's a fix for a small oversight in the types database. Nice, applied. Thanks Peter, I'll close #1725 now. Evan
Re: [PATCH 0/1] Print message while fetching eggs in chicken-install
On 2021-01-02 0:19, Mario Domenech Goulart wrote: > Thanks. I've pushed your patch. Thanks Mario, and happy new year! Evan
Re: [PATCH 0/1] Print message while fetching eggs in chicken-install
Hi folks, does anyone have an opinion on this? It's a small change and shouldn't take long to review. Cheers, Evan
[PATCH] Remove useless peek-char when read-string is called without read length
This call to `peek-char' was introduced by c78cdcd9, but it's useless and was probably only included in that commit by accident. The `read-string!/port` helper that's used just below to handle input already takes care of everything for us, no need to peek as well. --- extras.scm | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/extras.scm b/extras.scm index cc679697..8a9f6fed 100644 --- a/extras.scm +++ b/extras.scm @@ -165,8 +165,7 @@ (let ([out (open-output-string)] (buf (make-string read-string-buffer-size))) (let loop () - (let ((c (peek-char p)) -(n (read-string!/port read-string-buffer-size buf p 0))) + (let ((n (read-string!/port read-string-buffer-size buf p 0))) (cond ((eq? n 0) (get-output-string out)) (else -- 2.29.2
Re: [PATCH] Better error message in csi for unknown single-char options
Applied, thanks Felix! Evan
Re: New egg: SRFI-87: => in case clauses
On 2020-12-01 19:41, Mario Domenech Goulart wrote:
> I suppose it also has to be added to ##sys#features. Maybe
> library.scm@6543?
Whoops, you're right Mario. Update attached.
Now, is *this* all that's needed?
Evan
>From 77fa085929cf4efafc2de995f8ac1e24baa846e2 Mon Sep 17 00:00:00 2001
From: Evan Hanson
Date: Sun, 29 Nov 2020 21:13:36 +1300
Subject: [PATCH] Add srfi-87 to list of built-in feature identifiers
---
NEWS| 2 ++
eval.scm| 6 +++---
library.scm | 2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/NEWS b/NEWS
index 87587eeb..50d90cd2 100644
--- a/NEWS
+++ b/NEWS
@@ -33,6 +33,8 @@
been deprecated for years.
- At program cleanup, finalizers are only forced when the live
finalizer count is non-zero
+ - The symbol `srfi-87` has been added to the list of built-in
+feature identifiers.
- Compiler
- Avoid re-using argvector when inline rest operations are being
diff --git a/eval.scm b/eval.scm
index 504985d1..2f955104 100644
--- a/eval.scm
+++ b/eval.scm
@@ -940,9 +940,9 @@
; these are actually in unit extras, but that is used by default
(define-constant builtin-features
- '(srfi-30 srfi-46 srfi-61 srfi-62 ; runtime
-srfi-0 srfi-2 srfi-8 srfi-9 srfi-11 srfi-15 ; syntax
-srfi-16 srfi-17 srfi-26 srfi-31 srfi-55 srfi-88)) ; syntax cont
+ '(srfi-30 srfi-46 srfi-61 srfi-62 ; runtime
+srfi-0 srfi-2 srfi-8 srfi-9 srfi-11 srfi-15 srfi-16 ; syntax
+srfi-17 srfi-26 srfi-31 srfi-55 srfi-87 srfi-88)) ; syntax cont
(define default-dynamic-load-libraries
(case (software-version)
diff --git a/library.scm b/library.scm
index d1b6ad22..751244e4 100644
--- a/library.scm
+++ b/library.scm
@@ -6540,7 +6540,7 @@ static C_word C_fcall C_setenv(C_word x, C_word y) {
(define ##sys#features
'(#:chicken
#:srfi-6 #:srfi-8 #:srfi-12 #:srfi-17 #:srfi-23 #:srfi-30
-#:srfi-39 #:srfi-62 #:srfi-88 #:full-numeric-tower))
+#:srfi-39 #:srfi-62 #:srfi-87 #:srfi-88 #:full-numeric-tower))
;; Add system features:
--
2.25.4
Re: New egg: SRFI-87: => in case clauses
On 2020-11-22 11:35, John Cowan wrote: > Since the content of SRFI-87 is built in to the current Chicken, #:srfi-87 > should be added to the output of `features` in (chicken-platform). Hi there, sorry for the necromancy but I figured I'd post a patch for this before we forget. The attached change just adds a feature identifier for `srfi-87`, like John says. I think this is all that's needed, please have a look. Evan >From b03623dc6580ddb4465a27c170e2b5fbf67f3a49 Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Sun, 29 Nov 2020 21:13:36 +1300 Subject: [PATCH] Add srfi-87 to list of built-in feature identifiers --- NEWS | 2 ++ eval.scm | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 87587eeb..50d90cd2 100644 --- a/NEWS +++ b/NEWS @@ -33,6 +33,8 @@ been deprecated for years. - At program cleanup, finalizers are only forced when the live finalizer count is non-zero + - The symbol `srfi-87` has been added to the list of built-in +feature identifiers. - Compiler - Avoid re-using argvector when inline rest operations are being diff --git a/eval.scm b/eval.scm index 504985d1..2f955104 100644 --- a/eval.scm +++ b/eval.scm @@ -940,9 +940,9 @@ ; these are actually in unit extras, but that is used by default (define-constant builtin-features - '(srfi-30 srfi-46 srfi-61 srfi-62 ; runtime -srfi-0 srfi-2 srfi-8 srfi-9 srfi-11 srfi-15 ; syntax -srfi-16 srfi-17 srfi-26 srfi-31 srfi-55 srfi-88)) ; syntax cont + '(srfi-30 srfi-46 srfi-61 srfi-62 ; runtime +srfi-0 srfi-2 srfi-8 srfi-9 srfi-11 srfi-15 srfi-16 ; syntax +srfi-17 srfi-26 srfi-31 srfi-55 srfi-87 srfi-88)) ; syntax cont (define default-dynamic-load-libraries (case (software-version) -- 2.25.4
Re: [PATCH] Fix crash when accessing block header of immediate values in pretty-printer
On 2020-10-21 18:17, megane wrote: > Interesting.. How do you trigger this bug? Here's a simple way: #;1> (pp (block-ref 'aardvark 0)) Error: segmentation violation Call history: (pp (block-ref (quote aardvark) 0)) (block-ref (quote aardvark) 0) (quote aardvark) (##core#quote aardvark) (pp (block-ref (quote aardvark) 0)) (block-ref (quote aardvark) 0)<-- I don't know how else # can spring to life, but there might be other ways? Of course one probably shouldn't do this, but we still shouldn't segfault. Evan
[PATCH] Fix crash when accessing block header of immediate values in pretty-printer
This fixes a segmentation fault when pretty-printing C_SCHEME_UNBOUND, since we reach into the value with C_block_header() in C_anypointerp() before checking for C_unboundvaluep(). This crashes, since unbound is an immediate value. In addition to moving the call to C_unboundvaluep() above the call to C_anypointerp(), this also adds a generic check for any other immediate values before the remaining cases, which handle non-immediate objects. --- extras.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/extras.scm b/extras.scm index 76c23a21..cc679697 100644 --- a/extras.scm +++ b/extras.scm @@ -356,9 +356,9 @@ (out (number->string code 16) col) ] [else (out (make-string 1 obj) col)] ) ) ) ) ((##core#inline "C_undefinedp" obj) (out "#" col)) + ((##core#inline "C_unboundvaluep" obj) (out "#" col)) + ((##core#inline "C_immp" obj) (out "#" col)) ((##core#inline "C_anypointerp" obj) (out (##sys#pointer->string obj) col)) - ((##core#inline "C_unboundvaluep" obj) -(out "#" col) ) ((##sys#generic-structure? obj) (let ([o (open-output-string)]) (##sys#user-print-hook obj #t o) -- 2.28.0
Re: [PATCH] long lambda-info strings + C++ compilers
Makes sense to me, applied. Thanks Felix and Zilti! Evan
Re: [PATCH 1/2] Always treat bare colon as a symbol
On 2020-08-22 11:15, megane wrote: > Here's signed off version of Alice's patch. It all looks good to me. > > The new logic enabled some refactoring, which you might find to make the > logic a bit clearer. Good stuff, applied. Sorry for the slow review. Thank you both! Evan
[PATCH 0/1] Print message while fetching eggs in chicken-install
Hi folks, Here is a very simple one, I have a horrible internet connection so I've often noticed that there is a long pause without any output while chicken-install downloads egg sources, and this also confused someone I was helping to get started with CHICKEN today. So, I thought we should perhaps print a reassuring message for chicken-install users. Thoughts? Evan
[PATCH 1/1] Print message while fetching eggs in chicken-install
When running chicken-install there is often a long pause before any output while remote egg sources are downloaded. For new users this may be confusing as it seems like the program isn't doing anything. We currently print informational messages for building and installing eggs, so let's print one for fetching them as well, and make their indentation consistent, i.e. no indentation. --- chicken-install.scm | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/chicken-install.scm b/chicken-install.scm index 6d976048..755d126b 100644 --- a/chicken-install.scm +++ b/chicken-install.scm @@ -470,6 +470,7 @@ (else name))) (define (fetch-egg-sources name version dest lax) + (print "fetching " name) (let loop ((locs default-locations)) (cond ((null? locs) (let ((tmpdir (create-temporary-directory))) @@ -843,7 +844,7 @@ (run-script dir bscript platform) (unless (if (member name requested-eggs) no-install no-install-dependencies) (check-installed-files name info) -(print " installing " name) +(print "installing " name) (run-script dir iscript platform sudo: sudo-install)) (when (and (member name requested-eggs) run-tests @@ -873,7 +874,7 @@ (print "building " name " (target)") (run-script dir bscript platform) (unless (if (member name requested-eggs) no-install no-install-dependencies) -(print " installing " name " (target)") +(print "installing " name " (target)") (run-script dir iscript platform) (order-installed-eggs))) -- 2.28.0
[PATCH 1/1] Add support for `destination' specification in egg files
---
chicken-install.scm | 1 +
egg-compile.scm | 25 +++--
egg-environment.scm | 1 +
manual/Egg specification format | 13 +++--
4 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/chicken-install.scm b/chicken-install.scm
index 6d976048..a3429610 100644
--- a/chicken-install.scm
+++ b/chicken-install.scm
@@ -183,6 +183,7 @@
(custom-build #f #f #f)
(linkage #f #f #f)
(objects #f #f #f)
+(destination #f #f #f ,list?)
(install-name #f #f #f ,nameprop?)
(target #f #t #f)
(host #f #t #f)
diff --git a/egg-compile.scm b/egg-compile.scm
index f6de778c..8612c747 100644
--- a/egg-compile.scm
+++ b/egg-compile.scm
@@ -128,6 +128,19 @@
(list (implib rtarget
+;;; normalize target path for "random files" (data, c-include, scheme-include)
+
+(define (normalize-destination dest mode)
+ (let ((dest* (normalize-pathname dest)))
+(if (irregex-search '(: bos ".." ("\\/")) dest*)
+(error "destination must be relative to CHICKEN install prefix" dest)
+(normalize-pathname
+ (make-pathname (if (eq? mode 'target)
+default-prefix; XXX wrong!
+(override-prefix "/" host-prefix))
+dest*)
+
+
;;; check condition in conditional clause
(define (check-condition tst mode link)
@@ -264,7 +277,7 @@
(dest #f)
(files '()))
(for-each compile-data/include (cddr info))
-(let* ((dest (or dest
+(let* ((dest (or (and dest (normalize-destination dest mode))
(if (eq? mode 'target)
default-sharedir; XXX wrong!
(override-prefix "/share" host-sharedir
@@ -293,8 +306,8 @@
(dest #f)
(files '()))
(for-each compile-data/include (cddr info))
-(let* ((dest (or dest
- (if (eq? mode 'target)
+(let* ((dest (or (and dest (normalize-destination dest mode))
+ (if (eq? mode 'target)
default-incdir ; XXX wrong!
(override-prefix "/include" host-incdir
(dest (normalize-pathname (conc dest "/"
@@ -308,8 +321,8 @@
(dest #f)
(files '()))
(for-each compile-data/include (cddr info))
-(let* ((dest (or dest
- (if (eq? mode 'target)
+(let* ((dest (or (and dest (normalize-destination dest mode))
+ (if (eq? mode 'target)
default-sharedir ; XXX wrong!
(override-prefix "/share" host-sharedir
(dest (normalize-pathname (conc dest "/"
@@ -1022,7 +1035,7 @@
(root (string-append srcdir "/"))
(mkdir (mkdir-command platform))
(sfiles (map (cut prefix srcdir <>) files))
- (dfile (qs* dest platform #t))
+ (dfile (qs* (normalize-destination dest mode) platform #t))
(ddir (shell-variable "DESTDIR" platform)))
(print "\n" mkdir " " ddir dfile)
(let-values (((ds fs) (partition directory? sfiles)))
diff --git a/egg-environment.scm b/egg-environment.scm
index 50ea972a..470d6894 100644
--- a/egg-environment.scm
+++ b/egg-environment.scm
@@ -79,6 +79,7 @@ EOF
(define target-librarian (foreign-value "C_TARGET_LIBRARIAN" c-string))
(define target-librarian-options (foreign-value "C_TARGET_LIBRARIAN_FLAGS"
c-string))
+(define host-prefix (foreign-value "C_INSTALL_PREFIX" c-string))
(define host-repo (foreign-value "C_INSTALL_EGG_HOME" c-string))
(define host-libdir (foreign-value "C_INSTALL_LIB_HOME" c-string))
(define host-bindir (foreign-value "C_INSTALL_BIN_HOME" c-string))
diff --git a/manual/Egg specification format b/manual/Egg specification format
index 9eabfd2c..73da8566 100644
--- a/manual/Egg specification format
+++ b/manual/Egg specification format
@@ -375,12 +375,13 @@ to this component and that the object components are
dependencies.
[egg property] (destination NAME)
-Specifies an alternative installation destination for the
-built component and only applies
-to components of type {{data}}, {{c-include}} and {{scheme-include}}.
-This property should only be used in extreme
-cases, as it is recommended to use the default installation
-locations, which are:
+Specifies an alternative installation destination for the built
+component and only applies to components of type {{data}}, {{c-include}}
+and {{scheme-include}}. {{NAME}} must be a relative path and is
+considered relative to CHICKEN's installation prefix.
+
+This property should only be used in extreme cases, as it is recommended
+to use the
[PATCH 0/1] Add support for `destination' specification in egg files
Hi folks, Someone noted on IRC that the `destination' specification for egg files is currently documented but not actually implemented. I also noticed this when trying to install a man page into /share a few weeks ago, and prepared the attached patch, but I never got around to sending it. So, here you go. Most of the machinery to support this specification was already there, it just needed an entry in `egg-info-items' and a bit of validation. This patch only allows files to be installed under CHICKEN_INSTALL_PREFIX, which works for my use case and seems like a sensible behaviour, but might not be right. I'm also not sure about the use of `default-prefix' here, I have just followed the examples of the existing code despite the "XXX wrong!" warnings because I don't know any better. (ISTM that value, which is currently defined as C_INSTALL_PREFIX, should perhaps rather be C_TARGET_PREFIX to match the other "default-foo" definitions? But that might be a tangent.) For your consideration, just wanted to get this out there based on the IRC convo. Best, Evan
[PATCH] Avoid re-fetching bootstrapping tarball by using `wget --continue`
This just avoids downloading multiple (useless) copies of the snapshot archive when there is already a local copy by telling wget to "--continue" i.e. reuse the existing archive. --- scripts/bootstrap.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/bootstrap.sh b/scripts/bootstrap.sh index b465667d..e8ea0f30 100755 --- a/scripts/bootstrap.sh +++ b/scripts/bootstrap.sh @@ -6,7 +6,7 @@ set -e mkdir -p boot/snapshot cd boot -wget https://code.call-cc.org/releases/5.2.0/chicken-5.2.0.tar.gz +wget -c https://code.call-cc.org/releases/5.2.0/chicken-5.2.0.tar.gz tar -xzf chicken-5.2.0.tar.gz cd chicken-5.2.0 make "$@" PREFIX="$(pwd)"/../snapshot -- 2.27.0
Re: [PATCH] read-lines: small refactoring and some tests
Hi Mario, LGTM, applied! I also added the new test file to distribution/manifest. All the best, Evan
[PATCH] Use 0666 as default mode for `file-open' (ticket #1698)
On 2020-05-13 17:58, Evan Hanson wrote: > I have created a change request and patch for this here: > > https://bugs.call-cc.org/ticket/1698 Does anyone have any objections to the above CR? If not, here's a patch that includes a NEWS entry for the change. Cheers, Evan >From 82c6de2211a590b9652262d35642b11fa43f2cb9 Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Wed, 13 May 2020 17:50:39 +1200 Subject: [PATCH] Use 0666 as default mode for `file-open' There doesn't seem to be a default mode for the open(2) system call specified anywhere, so let's make `file-open' behave like fopen(3). This way, the permissions of files created using the posix unit will match those created with the normal `open-output-file' procedure, and such files will no longer be executable by default. This closes #1698. --- NEWS | 3 +++ posixunix.scm | 2 +- posixwin.scm | 2 +- tests/posix-tests.scm | 40 4 files changed, 45 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 67b81974..f10c242e 100644 --- a/NEWS +++ b/NEWS @@ -13,6 +13,9 @@ On UNIX, the values returned will be precise to the millisecond instead of rounded down to the nearest second at startup (which would result in erratic startup times). + - The default mode for files created by `file-open' has been changed +to 0666 (plus whatever change the effective umask applies), rather +than 0744 (see #1698). - Runtime system - Sleeping primordial thread doesn't forget mutations made to diff --git a/posixunix.scm b/posixunix.scm index 23ff157e..1bddc429 100644 --- a/posixunix.scm +++ b/posixunix.scm @@ -335,7 +335,7 @@ static int set_file_mtime(char *filename, C_word atime, C_word mtime) res ) ) ) ) ) (set! chicken.file.posix#file-open - (let ((defmode (bitwise-ior _s_irwxu (bitwise-ior _s_irgrp _s_iroth))) ) + (let ((defmode (bitwise-ior _s_irusr _s_iwusr _s_irgrp _s_iwgrp _s_iroth _s_iwoth))) (lambda (filename flags . mode) (let ([mode (if (pair? mode) (car mode) defmode)]) (##sys#check-string filename 'file-open) diff --git a/posixwin.scm b/posixwin.scm index c279c58e..cb31a07b 100644 --- a/posixwin.scm +++ b/posixwin.scm @@ -517,7 +517,7 @@ static int set_file_mtime(char *filename, C_word atime, C_word mtime) (set! chicken.file.posix#open/noinherit _o_noinherit) (set! chicken.file.posix#file-open - (let ((defmode (bitwise-ior _s_irwxu (fxior _s_irgrp _s_iroth + (let ((defmode (bitwise-ior _s_irusr _s_iwusr _s_irgrp _s_iwgrp _s_iroth _s_iwoth))) (lambda (filename flags . mode) (let ([mode (if (pair? mode) (car mode) defmode)]) (##sys#check-string filename 'file-open) diff --git a/tests/posix-tests.scm b/tests/posix-tests.scm index 807730e6..361f55c1 100644 --- a/tests/posix-tests.scm +++ b/tests/posix-tests.scm @@ -87,3 +87,43 @@ (assert (equal? (get-environment-variable "FOO") "bar")) (unset-environment-variable! "FOO") (assert (not (get-environment-variable "FOO"))) + +;; file creation and umask interaction +(letrec-syntax ((test (syntax-rules () +((test umask expected) + (test umask "expected" expected "given")) +((test umask given expected) + (test umask "expected" expected "given" given)) +((test umask "expected" expected "given" given ...) + (let ((mode (file-creation-mode))) + (set! (file-creation-mode) umask) + (delete-file* "posix-tests.out") + (file-open "posix-tests.out" open/creat given ...) + (assert (equal? (file-permissions "posix-tests.out") expected)) + (set! (file-creation-mode) mode)) + ;; default file mode + (test #o000 #o666) + (test #o002 #o664) + (test #o020 #o646) + (test #o022 #o644) + (test #o027 #o640) + (test #o072 #o604) + (test #o077 #o600) + (test #o777 #o000) + ;; explicit file mode argument + (test #o000 #o644 #o644) + (test #o002 #o644 #o644) + (test #o020 #o644 #o644) + (test #o022 #o644 #o644) + (test #o027 #o644 #o640) + (test #o072 #o644 #o604) + (test #o077 #o644 #o600) + (test #o777 #o644 #o000) + (test #o000 #o777 #o777) + (test #o002 #o777 #o775) + (test #o020 #o777 #o757) + (test #o022 #o777 #o755) + (test #o027 #o777 #o750) + (test #o072 #o777 #o705) + (test #o077 #o777 #o700) + (test #o777 #o777 #o000)) -- 2.25.1
Re: Default file creation mode for core/scsh-process sets executable bit
Hello everyone, On 2020-05-09 8:42, Evan Hanson wrote: > On 2020-05-07 16:43, Vasilij Schneidermann wrote: > > Which of the following options would you prefer? > > > > 1. Patching scsh-process to pass the correct file mask when using > > `file-open`. > > 2. Patching posixunix.scm to calculate a better default. > > Option 2 seems preferable to me; it should at least match `open-output-file' > if not the umask, but either change will be backwards-incompatible so anything > we do will probably nee a CR. I have created a change request and patch for this here: https://bugs.call-cc.org/ticket/1698 I think the change itself is simple enough, but it may break code that is relying on the fact that file-open creates an executable file by default, hence the CR. All the best, Evan
Re: [Chicken-hackers] [PATCH] Rework library loading to support conditional unit entry
Hi there, On 2018-11-12 9:08, Evan Hanson wrote: > On 2018-11-11 21:03, Peter Bex wrote: > > I think now's a good time to revisit this patch. Of course it no longer > > applies. Would you care to rebase it? > > Yeah, I will do so, thanks. You can just ignore it until I can prepare a > new version. I've finally gone back and revived this patch, rebased it and made a few improvements. Everything I said in the earlier email is still true, but this version is actually smaller since I was able to simplify a few things and rip out some unnecessary changes. It still looks pretty big, but a lot of the changes are just shuffling forms around so using git with --color-words should help, especially in core.scm and eval.scm. The one change to the tests is there because, with this patch, test-static-eval-compiled.scm will only enter the lolevel unit at line 8 where the chicken.memory.representation module is imported. So, that unit needs to be loaded at the start of the program, before the eval'd imports. Those first two lines are only working by accident, currently, and they will cause an error if the import on line 8 is removed, for example. One thing I also should have pointed out is that this patch removes the "-debug M" flag from csc. I think it isn't especially useful in its current form, and I'm working on a more detailed way of generating dependency information in an egg, but we can put it back if anyone feels strongly. Thanks, please let me know if I can help explain anything. Evan >From a4f9f7013bcd08ea2b6e29aa43e95ca2c5b3c10a Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Sat, 9 May 2020 20:15:46 +1200 Subject: [PATCH] Rework library loading to support conditional unit entry This makes a handful of changes to the way library dependencies are processed in order to support conditional unit loading, i.e. not calling a unit's entry procedure until its code path is actually visited. This resolves a difference in behaviour between dynamically compiled libraries whose entrypoints are only called when their code path is visited, and statically-compiled libraries whose entrypoints are currently hoisted to the start of the program and always called, regardless of whether or where they're actually used. Drop the `file-requirements' hash table in favour of two global lists, `required-libraries' and `linked-libraries', the first of which is a superset of the second. The `linked-libraries' list includes everything that should be linked with the program statically (i.e. as a unit), and everything else is a runtime dependency (i.e. loaded as a shared object or source file). Split the batch driver's `initforms' list into two separate values, one for import forms (which must be included within the program's wrapper module's body, if one is used) and one for compiler-introduced initialisation forms (which must precede the profiling-related expressions that are inserted into the program when profiling is enabled, since they're responsible for loading the "profiler" unit). This is necessary because all libraries now go through the compiler's logic for `##core#require' nodes, whereas units were previously exempt. Move all "forms" bindings together in the `let' that introduces them. Introduce a new `used-libraries' global to keep track of units that are specified with "-uses" or `(declare (uses))'. These are hoisted to the top level and called at the start of the program, just like before this change. The list of `used-units', which is used to generate prototypes for external unit toplevels in the C backend, is constructed by simply remembering all `##core#callunit' nodes as they're encounted during canonicalisation. Because each import form now has the potential to introduce a call to a unit entrypoint, `##core#callunit' nodes are deduplicated during CPS. This ensures that only one call to a given unit's entrypoint will be generated along a given code path. Simplify `##sys#process-require' so that it expects just a library, module, and compilation flag as arguments, and returns just a single value. Get rid of the global `provided' and `linked-static-extensions' lists, which are no longer necessary. For modules that export syntax in static libraries (where module information is compiled into the libraries themselves), generate code that will load the module's library dependencies *before* the code for runtime evaluation of the module's import forms, that is, "(scheme#eval '(import-syntax ...))". This ensures that static programs do not attempt to dynamically load the named import libraries dynamically, since dlopen(3) et al. are disabled by static compilation. We communicate this situation to `##sys#compiled-module-registration' with a compile mode flag, for consistency with `##sys#process-require'. Change the meaning of the "-link" option so that it indicates libraries that should be linked iff they're required, rath
Re: Default file creation mode for core/scsh-process sets executable bit
On 2020-05-07 16:43, Vasilij Schneidermann wrote: > Which of the following options would you prefer? > > 1. Patching scsh-process to pass the correct file mask when using `file-open`. > 2. Patching posixunix.scm to calculate a better default. Option 2 seems preferable to me; it should at least match `open-output-file' if not the umask, but either change will be backwards-incompatible so anything we do will probably nee a CR. But in the meantime, why not option 1 as well? It wouldn't hurt to be explicit in scsh-process, and given that it is intended to be a shell-like tool I would expect the umask to kick in regardless of what core does. Evan signature.asc Description: PGP signature
Re: [PATCH] Fix potential invalid argument error in `##sys#decompose-import'
On 2020-05-03 11:44, felix.winkelm...@bevuta.com wrote: > I'd love to apply your patches, but can you remove the "noprefix=true" option > from your .git/config, please? Apparently git am doesn't recognize this patch. Yes, apologies, I'll fix it for future patches. I didn't consider that Git might become confused on the other end, but that makes sense. Thanks! Evan
[PATCH] Mark identifiers used to collect profiling info as `bound-to-procedure'
Calls to `##sys#register-profile-info' and `set-profile-info-vector!` are inserted into the program when profiling is enabled, so they should be marked as procedures so the resulting call nodes are marked as safe, just like we do for the `##sys#profile-entry' and `exit' procedures. --- c-platform.scm | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git c-platform.scm c-platform.scm index 9d20a524..19a4c97f 100644 --- c-platform.scm +++ c-platform.scm @@ -72,8 +72,10 @@ (define default-profiling-declarations '((##core#declare (uses profiler) - (bound-to-procedure - ##sys#profile-entry ##sys#profile-exit) ) ) ) + (bound-to-procedure ##sys#profile-entry +##sys#profile-exit +##sys#register-profile-info +##sys#set-profile-info-vector! (define default-units '(library eval)) -- 2.25.1
[PATCH] Fix potential invalid argument error in `##sys#decompose-import'
This fixes a small bug in `##sys#decompose-import' where "spec" (which is a list) is passed to the `warn' procedure rather than "name" (which is a symbol, as expected). This leads to an invalid argument error arising from `symbol->string', e.g. $ echo '(import (only (rename scheme (car first)) car))' | csc - Error: (symbol->string) during expansion of (import ...) - bad argument type - not a symbol: (rename scheme (car first)) --- modules.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git modules.scm modules.scm index a199f9e7..beb52eaf 100644 --- modules.scm +++ modules.scm @@ -638,7 +638,7 @@ (cond ((null? ids) (for-each (lambda (id) - (warn "imported identifier doesn't exist" spec id)) + (warn "imported identifier doesn't exist" name id)) missing) (values name lib `(,head ,spec ,@imports) v s impi)) ((assq (car ids) impv) => -- 2.25.1
Re: [PATCH] force finalizers only if finalizers exist
On 2020-04-07 14:51, felix.winkelm...@bevuta.com wrote: > > > This patch disables the final GC for finalizer forcing at normal program > > > termination > > > if no finalizers are live as the GC is unnecessary in such cases. > > > > How about possible pending finalizers? > > You mean pending from a previous GC? I'm not sure - shouldn't they already > be executed at this stage? Hey megane, could you go into a bit more detail about this? If I understand correctly, you mean that some finalizers that have been moved onto the pending_finalizers_symbol may not have been invoked by this point, but will also not included in the C_i_live_finalizers_count, is that right? That seems right to me, but it's not clear to me what the check should rather be. Evan
Re: Exposing subsecond precision in current-seconds
On 2020-04-27 21:26, felix.winkelm...@bevuta.com wrote: > > - Add a new procedure in `(chicken time)` or `(chicken time posix)` that > > gives > > you both seconds and nanoseconds, be it as values, list, vector, ... Same > > Windows considerations as previously apply. > > Probably the best solution, I guess something based on "clock_gettime" > is the most precise and portable method, even though it may need librt on > some platforms. This seems best to me as well. I think giving the user an exact integer is always nicest, compared to returning a vector or somesuch. So, something like `current-microseconds` would be nice, or following the Gambit API that Lassi has mentioned. We already have `time->seconds' and friends in srfi-18, but it's built on top of `current-milliseconds'. They could perhaps be updated to use a `current-microseconds' procedure instead, if we had one, but that might not be necessary (it certainly isn't necessary from a compliance point of view, but "real" time values would be more useful). Cheers, Evan
Re: [PATCH] Fix the definition of srfi-6
Hi Phil, On 2020-04-23 15:53, Phil Hofer wrote: > There is a typo in the definition of SRFI 6: open-output-string is > erroneously defined as open-input-string. See the trivial attached > patch. There is indeed, thank you for the patch! > (First time submitting a patch to this mailing list; let me know if > you'd like an inline patch, sign-off, etc.) This format is fine. We generally use Git's format-patch/am workflow for patches, but we're happy to accept anything that's easily applied. In this case I've reformatted your patch to include contributor info. For bigger changes we'd need another maintainer signoff, but this is a tiny change and obviously correct. Thanks again for the fix! All the best, Evan signature.asc Description: PGP signature
Re: [PATCH 0/1] Prevent excessive major gcs by preserving a decent amount of unused heap
On 2020-04-12 19:11, Peter Bex wrote: > What's the deal with the FAIL for knucleotide in both patched versions? Oh, that's because knucleotide needs srfi-69 and I didn't install it for the testing builds. Here's the comparison for that benchmark with srfi-69 installed. It's pretty similar to the others: https://paste.call-cc.org/paste?id=bdadc47d53512e46e563af1830a7bf6b276eb378#a4 Cheers, Evan
Re: [PATCH 0/1] Prevent excessive major gcs by preserving a decent amount of unused heap
Uh, sorry, this is in reference to megane's email from January 8. Forgot to fill in the "In-Reply-To"! Evan On 2020-03-29 10:10, Evan Hanson wrote: > Hi there, > > I've played around with this first patch a bit, and I think I've found a > way to apply the same technique without complicating the logic in > C_reclaim(). Attached is a sign-off of megane's patch that introduces > the same min-free requirement, but only at the point where reallocations > are triggered. This actually gives a minor performance improvement over > the initial version (which itself is a significant improvement over > master), and it's a less invasive change because it leaves the heap > resizing logic unchanged. > > Here are the benchmarks -- review-0001 (in the middle) is the original > patch, and review-1001 (on the right) is this version: > > http://paste.call-cc.org/paste?id=bdadc47d53512e46e563af1830a7bf6b276eb378 > > (I also played around with the initial and min-free heap values but > couldn't find any improvements that way.) > > megane, could you please have a look at this version and confirm the > results? I'm keen to get this reduction in major GCs, so I'm hoping a > simpler version of the patch is OK. > > Cheers, > > Evan
[PATCH 1/1] Prevent excessive major gcs by preserving a decent amount of unused heap
From: megane
Signed-off-by: Evan Hanson
---
manual/Using the compiler | 2 ++
runtime.c | 11 +--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git manual/Using the compiler manual/Using the compiler
index fd656362..7a96920a 100644
--- manual/Using the compiler
+++ manual/Using the compiler
@@ -223,6 +223,8 @@ by the startup code and will not be contained in the result
of
; {{-:hmNUMBER}} : Specifies a maximal heap size (including both semispaces).
The default is (2GB - 15).
+; {{-:hfNUMBER}} : Specifies the minimum avilable heap space. If the free
space (in one semispace) is less than this number (4MB by default), then the
heap is grown.
+
; {{-:hsPERCENTAGE}} : Sets the shrink rate of the heap in percent. The heap
is shrunk to {{PERCENTAGE}} when the watermark is reached. The default is 50.
Note: If you want to make sure that the heap never shrinks, specify a value of
{{0}}. (this can be useful in situations where an optimal heap-size is known
in advance).
; {{-:huPERCENTAGE}} : Sets the memory usage watermark below which heap
shrinking is triggered. The default is 25.
diff --git runtime.c runtime.c
index 8e049623..b285b4f2 100644
--- runtime.c
+++ runtime.c
@@ -163,6 +163,7 @@ static C_TLS int timezone;
#define DEFAULT_HEAP_GROWTH200
#define DEFAULT_HEAP_SHRINKAGE 50
#define DEFAULT_HEAP_SHRINKAGE_USED25
+#define DEFAULT_HEAP_MIN_FREE (4 * 1024 * 1024)
#define DEFAULT_FORWARDING_TABLE_SIZE 32
#define DEFAULT_LOCATIVE_TABLE_SIZE32
#define DEFAULT_COLLECTIBLES_SIZE 1024
@@ -360,6 +361,7 @@ C_TLS C_uword
C_heap_growth = DEFAULT_HEAP_GROWTH,
C_heap_shrinkage = DEFAULT_HEAP_SHRINKAGE,
C_heap_shrinkage_used = DEFAULT_HEAP_SHRINKAGE_USED,
+ C_heap_min_free = DEFAULT_HEAP_MIN_FREE,
C_maximal_heap_size = DEFAULT_MAXIMAL_HEAP_SIZE;
C_TLS time_t
C_startup_time_seconds,
@@ -1362,6 +1364,7 @@ void CHICKEN_parse_command_line(int argc, char *argv[],
C_word *heap, C_word *st
" -:o disable stack overflow checks\n"
" -:hiSIZE set initial heap size\n"
" -:hmSIZE set maximal heap size\n"
+ " -:hfSIZE set minimum unused heap size\n"
" -:hgPERCENTAGE set heap growth percentage\n"
" -:hsPERCENTAGE set heap shrink percentage\n"
" -:huPERCENTAGE set percentage of memory used at which heap
will be shrunk\n"
@@ -1390,6 +1393,9 @@ void CHICKEN_parse_command_line(int argc, char *argv[],
C_word *heap, C_word *st
*heap = arg_val(ptr + 1);
heap_size_changed = 1;
goto next;
+ case 'f':
+ C_heap_min_free = arg_val(ptr + 1);
+ goto next;
case 'g':
C_heap_growth = arg_val(ptr + 1);
goto next;
@@ -3605,7 +3611,7 @@ C_regparm void C_fcall C_reclaim(void *trampoline, C_word
c)
/*** isn't gc_mode always GC_MAJOR here? */
/* NOTE: count is actual usage, heap_size is both halves */
if(gc_mode == GC_MAJOR &&
- count < percentage(heap_size/2, C_heap_shrinkage_used) &&
+ C_heap_min_free + count < percentage(heap_size / 2,
C_heap_shrinkage_used) &&
C_heap_shrinkage > 0 &&
heap_size > MINIMAL_HEAP_SIZE && !C_heap_size_is_fixed)
C_rereclaim2(percentage(heap_size, C_heap_shrinkage), 0);
@@ -3809,7 +3815,8 @@ C_regparm void C_fcall really_mark(C_word *x)
n = C_header_size(p);
bytes = (h & C_BYTEBLOCK_BIT) ? n : n * sizeof(C_word);
-if(((C_byte *)p2 + bytes + sizeof(C_word)) > tospace_limit) {
+/* Check for needed size plus minimum unused block: */
+if(((C_byte *)p2 + bytes + sizeof(C_word) + C_heap_min_free) >
tospace_limit) {
/* Detect impossibilities before GC_REALLOC to preserve state: */
if (C_in_stackp((C_word)p) && bytes > stack_size)
panic(C_text("Detected corrupted data in stack"));
--
2.25.1
[PATCH 0/1] Prevent excessive major gcs by preserving a decent amount of unused heap
Hi there, I've played around with this first patch a bit, and I think I've found a way to apply the same technique without complicating the logic in C_reclaim(). Attached is a sign-off of megane's patch that introduces the same min-free requirement, but only at the point where reallocations are triggered. This actually gives a minor performance improvement over the initial version (which itself is a significant improvement over master), and it's a less invasive change because it leaves the heap resizing logic unchanged. Here are the benchmarks -- review-0001 (in the middle) is the original patch, and review-1001 (on the right) is this version: http://paste.call-cc.org/paste?id=bdadc47d53512e46e563af1830a7bf6b276eb378 (I also played around with the initial and min-free heap values but couldn't find any improvements that way.) megane, could you please have a look at this version and confirm the results? I'm keen to get this reduction in major GCs, so I'm hoping a simpler version of the patch is OK. Cheers, Evan
Re: [PATCH] remove use of "and" in types.db
Ooh, good find. Applied! Evan
Re: [PATCH] use correct defaults file when updating module db during installation
Makes sense, applied. Thanks Felix! Evan
Re: [PATCH] Add missing build dependencies to targets in makefile
This has been applied to master. Thanks again Jani!
[PATCH] Implement platform autodetection when possible
Hi there, Here's a signed-off version of the latest patch, including removing the handling of iOS as John suggested. I've also fixed the capitalisation of the Haiku platform name, added a bit more info to the NEWS entry, and moved it into the correct section. This has been tested and works correctly on the following platforms: - Cygwin - DragonflyBSD - FreeBSD - Haiku - Linux - MSYS2 - MinGW - NetBSD - OpenBSD Given that the PLATFORM can still be provided manually, I'm happy for this to go in. Thank you to John for the changes, and to Alex for the detection code in the first instance. Evan >From d29028b3db86501b2b4e2042abc320d46a0f4370 Mon Sep 17 00:00:00 2001 From: John Cowan Date: Mon, 30 Dec 2019 14:23:49 -0500 Subject: [PATCH] Implement platform autodetection when possible Cross-compilation still requires PLATFORM to be set, and you can always set it yourself if you want to, but the README examples no longer mention it. Signed-off-by: Evan Hanson --- GNUmakefile | 4 ++- Makefile.detect | 84 +++ NEWS | 5 +++ README| 38 +--- distribution/manifest | 1 + 5 files changed, 118 insertions(+), 14 deletions(-) create mode 100644 Makefile.detect diff --git GNUmakefile GNUmakefile index 68422f39..81b31487 100644 --- GNUmakefile +++ GNUmakefile @@ -37,6 +37,8 @@ include $(CONFIG) endif endif +include Makefile.detect + ifndef PLATFORM $(info Please select your target platform by running one of the following commands:) $(info ) @@ -46,4 +48,4 @@ $(info For more information, consult the README file.) $(error No PLATFORM given.) else include $(SRCDIR)Makefile.$(PLATFORM) -endif \ No newline at end of file +endif diff --git Makefile.detect Makefile.detect new file mode 100644 index ..75dd5d0e --- /dev/null +++ Makefile.detect @@ -0,0 +1,84 @@ +# -*- Makefile -*- +# +# Detect the PLATFORM with uname. +# Based on Chibi Scheme auto-detector +# Heavily revamped by John Cowan +# Copyright (c) 2009-2018 Alex Shinn, John Cowan +# BSD license at <https://github.com/ashinn/chibi-scheme/blob/master/COPYING> + +ifndef PLATFORM + +# First check is for pure MinGW, which doesn't have uname. +# In cmd.exe, echo "test" outputs "test", with quotes. +test:=$(shell echo "test") +quote:=$(findstring ",$(test)) + +ifeq ($(quote),") +PLATFORM=mingw +else + +# Now we can use uname tests +uname_s:=$(shell uname) +uname_o:=$(shell uname -o) + +# Check for specific platforms +ifeq ($(uname_o),Msys) +PLATFORM=mingw-msys +endif + +ifeq ($(uname_s),Darwin) +PLATFORM=macosx +endif + +ifeq ($(uname_s),FreeBSD) +PLATFORM=bsd +endif + +ifeq ($(uname_s),NetBSD) +PLATFORM=bsd +endif + +ifeq ($(uname_s),OpenBSD) +PLATFORM=bsd +endif + +ifeq ($(uname_s),DragonFly) +PLATFORM=bsd +endif + +ifeq ($(uname_o),Cygwin) +PLATFORM=cygwin +endif + +ifeq ($(uname_o),Android) +PLATFORM=android +endif + +ifeq ($(uname_o),GNU/Linux) +PLATFORM=linux +endif + +ifeq ($(uname_s),SunOS) +PLATFORM=solaris +endif + +ifeq ($(uname_s),Haiku) +PLATFORM=haiku +endif + +ifeq ($(uname_s),BeOS) +PLATFORM=haiku +endif + +ifeq ($(uname_s),GNU) +PLATFORM=hurd +endif + +ifeq ($(uname_s),AIX) +PLATFORM=aix +endif + +# add more options here + +endif # have uname +endif # undef PLATFORM diff --git NEWS NEWS index d86ffe23..75253c4d 100644 --- NEWS +++ NEWS @@ -4,6 +4,11 @@ parameters in interrupt handlers anymore. (See #1638. Fix contributed by Sebastien Marie) +- Build system + - Auto-configure at build time on most platforms. Cross-compilation +still requires PLATFORM to be set, and it can still be provided +manually, but it is no longer required in the common case. + 5.1.1 diff --git README README index fd295c9d..3b20cc00 100644 --- README +++ README @@ -78,8 +78,19 @@ _/_/_/_/_/_/ _/_/_/_/_/ currently not supported, so you must be in the toplevel source directory to invoke "make". -Enter "make" without any options to see a list of supported -platforms. +If you enter "make" without the PLATFORM option, CHICKEN will +attempt to figure out what platform you are using. If it cannot +do so, you will see a list of supported platforms. If you are +cross-building, you must specify PLATFORM; for example, +PLATFORM=cross-linux-mingw will build CHICKEN on Linux to +deploy on Windows. + +If CHICKEN somehow detects the wrong platform, type + +make PLATFORM="" + +to get a list of available platforms, and re-run "make" using +the correct platform. Note that parallel builds (using the "-j" make(1) option) are *not* supported. @@ -87,7 +98,7 @@ _/_/_/_/_/_/ _/_/_/_/_/ If you invoke "
Re: [PATCH] Use intermediate variable for exit status in posixunix.scm
On 2020-03-01 16:28, felix.winkelm...@bevuta.com wrote: > This is needed on TCC and newer versions of GCC, it seems. Applied.
Re: [PATCH] Add missing build dependencies to targets in makefile
Hi Jani, Sorry for the delay reviewing this, we've just gotten to it now that 5.2.0 has been released. Thank you for the patch! This looks good to me, sign-off attached. Evan >From 5329d35549bfd8ba0f522e4a5aed6399b718967e Mon Sep 17 00:00:00 2001 From: Jani Hakala Date: Wed, 8 Jan 2020 23:21:58 +0200 Subject: [PATCH] Add missing build dependencies to targets in makefile Add dependencies between * scheme source files, * chicken shared library and module import libraries, * chicken-do and C headers. Signed-off-by: Evan Hanson --- rules.make | 43 --- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git rules.make rules.make index c461458e..fe582b61 100644 --- rules.make +++ rules.make @@ -208,8 +208,8 @@ lib$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX)$(A): $(LIBCHICKEN_STATIC_OBJECTS) # import libraries and extensions -%.so: %.o - $(LINKER) $(LINKER_OPTIONS) $(LINKER_LINK_SHARED_DLOADABLE_OPTIONS) $^ $(LINKER_OUTPUT_OPTION) $@ \ +%.so: %.o $(LIBCHICKEN_SO_FILE) + $(LINKER) $(LINKER_OPTIONS) $(LINKER_LINK_SHARED_DLOADABLE_OPTIONS) $< $(LINKER_OUTPUT_OPTION) $@ \ $(LINKER_LIBRARY_PREFIX)$(PROGRAM_PREFIX)chicken$(PROGRAM_SUFFIX)$(LINKER_LIBRARY_SUFFIX) \ $(LIBRARIES) @@ -252,7 +252,7 @@ $(eval $(call declare-program-from-object,$(CSI_STATIC_EXECUTABLE),csi)) # "chicken-do" -$(CHICKEN_DO_PROGRAM)$(EXE): $(SRCDIR)chicken-do.c +$(CHICKEN_DO_PROGRAM)$(EXE): $(SRCDIR)chicken-do.c chicken.h $(CHICKEN_CONFIG_H) $(C_COMPILER) $(C_COMPILER_OPTIONS) $(C_COMPILER_OPTIMIZATION_OPTIONS) $< -o $@ # scripts @@ -559,6 +559,8 @@ core.c: core.scm mini-srfi-1.scm \ chicken.compiler.scrutinizer.import.scm \ chicken.compiler.support.import.scm \ chicken.eval.import.scm \ + chicken.file.import.scm \ + chicken.fixnum.import.scm \ chicken.format.import.scm \ chicken.io.import.scm \ chicken.keyword.import.scm \ @@ -567,14 +569,17 @@ core.c: core.scm mini-srfi-1.scm \ chicken.string.import.scm optimizer.c: optimizer.scm mini-srfi-1.scm \ chicken.compiler.support.import.scm \ + chicken.fixnum.import.scm \ chicken.internal.import.scm \ chicken.sort.import.scm \ chicken.string.import.scm scheduler.c: scheduler.scm \ + chicken.fixnum.import.scm \ chicken.format.import.scm \ chicken.condition.import.scm scrutinizer.c: scrutinizer.scm mini-srfi-1.scm \ chicken.compiler.support.import.scm \ + chicken.fixnum.import.scm \ chicken.format.import.scm \ chicken.internal.import.scm \ chicken.io.import.scm \ @@ -589,6 +594,7 @@ lfa2.c: lfa2.scm mini-srfi-1.scm \ compiler-syntax.c: compiler-syntax.scm mini-srfi-1.scm \ chicken.compiler.support.import.scm \ chicken.compiler.core.import.scm \ + chicken.fixnum.import.scm \ chicken.format.import.scm chicken-ffi-syntax.c: chicken-ffi-syntax.scm \ chicken.format.import.scm \ @@ -599,6 +605,7 @@ support.c: support.scm mini-srfi-1.scm \ chicken.blob.import.scm \ chicken.condition.import.scm \ chicken.file.import.scm \ + chicken.fixnum.import.scm \ chicken.foreign.import.scm \ chicken.format.import.scm \ chicken.internal.import.scm \ @@ -631,6 +638,7 @@ csc.c: csc.scm \ chicken.string.import.scm csi.c: csi.scm \ chicken.condition.import.scm \ + chicken.file.import.scm \ chicken.foreign.import.scm \ chicken.format.import.scm \ chicken.gc.import.scm \ @@ -641,19 +649,23 @@ csi.c: csi.scm \ chicken.platform.import.scm \ chicken.port.import.scm \ chicken.pretty-print.import.scm \ + chicken.process.import.scm \ chicken.process-context.import.scm \ chicken.repl.import.scm \ chicken.sort.import.scm \ chicken.string.import.scm chicken-profile.c: chicken-profile.scm \ chicken.internal.import.scm \ + chicken.file.import.scm \ chicken.file.posix.import.scm \ + chicken.fixnum.import.scm \ chicken.process-context.import.scm \ chicken.sort.import.scm \ chicken.string.import.scm chicken-status.c: chicken-status.scm \ chicken.file.import.scm \ chicken.file.posix.import.scm \ + chicken.fixnum.import.scm \ chicken.foreign.import.scm \ chicken.format.import.scm \ chicken.irregex.import.scm \ @@ -667,8 +679,10 @@ chicken-install.c: chicken-install.scm \ chicken.condition.import.scm \ chicken.file.import.scm \ chicken.file.posix.import.scm \ + chicken.fixnum.import.scm \ chicken.foreign.import.scm \ chicken.format.import.scm \ + chicken.internal.import.scm \ chicken.io.import.scm \ chicken.irregex.import.scm \ chicken.pathname.import.scm \ @@ -681,6 +695,7 @@ chicken-install.c: chicken-install.scm \ chicken.tcp.import.scm chicken-uninstall.c: chicken-uninstall.scm \ chicken.file.import.scm \ + chicken.fixnum.import.scm \ chicken.foreign.import.scm \ chicken.format.import.scm \ chicken.irregex.import.scm \ @@ -690,10 +705,12 @@ chicken-uninstall.c: chicken-uninstall.scm \ chicken.process-context.import.scm \ chicken.string.
Re: [PATCH] Fix compilation issue in 5.2.0rc1
On 2020-01-17 11:35, Peter Bex wrote: > Sven confirmed that this patch fixes the issue. His code now compiles > and also works as expected. > > I think the solution is a bit hacky, but I don't know of a better way > to do this. Suggestions welcome! Hmmm, we could modify the procedures in runtime.c that use barf() to return C_SCHEME_UNDEFINED (or some other C_word), but that seems wrong and it's probably overkill anyway. (Actually, I'm a bit surprised the C_noret on barf() doesn't kick in here.) Is there a different node type we could use that doesn't produce an assignment? In any case, I've pushed this to resolve #1662. Thanks Peter! Evan
Re: Time to make a 5.2.0 release candidate?
Hi Peter, On 12/28/19 4:42 PM, Peter Bex wrote: I think we're about ready to start the process for a 5.2.0 release. What do you think? Should we wait for the eggs from #1655 to be fixed? What about the plaform auto-detection patch? IMO we should try to fix the eggs but wait until after a new release to add the autodetection patch. Evan
Re: [PATCH 3/3] Let scrutinizer infer types for foreign types with retconv/argconv given
On 2019-12-26 15:51, megane wrote: > It would be ideal if we could add some bits of type information and let > the scrutinizer infer the rest. I think that would need some thought, > and/or experimentation. > > In these patches I dropped the annotations that added no information the > scrutinizer couldn't infer. For example in (* * -> *) the only > information is the arity of the function, which the scrutinizer can > infer. Indeed. I don't want to make perfect the enemy of good, so I've pushed these. I do think we should try to recollapse/resimplify the code in `annotate-foreign-procedure' if we can get the scrutinizer doing the right thing with those annotations (or with the stub call sites, like you suggest in the commit message), but this is a good improvement for now. Thanks megane! > There's only 1 return value from foreign functions, too (right?). Right; C_values, which is the only way to return multiple values from foreign code, only works with foreign-primitive. > There should a way for the user to override (if compatible) the type for > definitions. If the user specifies (: foo (-> *)) the return type of foo > should be * even if the scrutinizer could infer the actual return type > to be, say a fixnum. That gives more freedom for a library writer from > an API design perspective. Yeah, ATM `##core#the' nodes are kind of doing two different jobs; one is carrying user specifiations, and the other is passing info from one compiler phase to another. I guess in the first case we don't want to change anything, but in the second we want to improve the info wherever possible. Could the "strict" flag on those nodes be used for this? Evan
Re: [PATCH 3/3] Let scrutinizer infer types for foreign types with retconv/argconv given
Hi megane, happy holidays! A quick question about this -- ought the scrutinizer try to improve the specificity of the ##core#the annotation, rather than having annotate-foreign-procedure skip emitting it entirely? ISTR it doesn't even look at the types in ##core#the nodes, but maybe it should? I'd guess that would simplify this code, and might also give benefits in other places, but maybe there's a reason it doesn't... Evan
[PATCH] Add redact-gensyms and output files to testclean target
Previously, the "testclean" target would leave a few files lying around: the redact-gensyms executable that's used to iron out unique identifiers in the tests, and the output files it produces. This commit just makes sure those files are removed when `make testclean' is run. --- rules.make | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rules.make b/rules.make index 7b8a33f0..47bd783a 100644 --- a/rules.make +++ b/rules.make @@ -953,6 +953,7 @@ testclean: $(SRCDIR)tests$(SEP)*.obj \ $(SRCDIR)tests$(SEP)*.out \ $(SRCDIR)tests$(SEP)*.profile \ + $(SRCDIR)tests$(SEP)*.redacted \ $(SRCDIR)tests$(SEP)*.so \ $(SRCDIR)tests$(SEP)tmp \ $(SRCDIR)tests$(SEP)tmp.c \ @@ -960,7 +961,8 @@ testclean: $(SRCDIR)tests$(SEP)null \ $(SRCDIR)tests$(SEP)null.c \ $(SRCDIR)tests$(SEP)null.exe \ - $(SRCDIR)tests$(SEP)test-repository + $(SRCDIR)tests$(SEP)test-repository \ + $(SRCDIR)tests$(SEP)redact-gensyms # run tests -- 2.23.0
Re: [PATCH] Fix #1649 by using '* as return value type if foreign type has a retconv procedure
Hi Peter, that makes sense, this is a good fix for now. Thanks, and thank you megane for finding this issue. Evan signature.asc Description: PGP signature
Re: [PATCH] Fix too small memory allocations
Hi Jani,
Thank you! It took a while to track down a gcc that was new enough, but
I've attached a signed-off version.
This one also includes the extra info from Peter and megane's commit
messages, as well as the variable from megane's that gives a name to the
`min-words-per-bignum' value in c-platform.scm.
Cheers,
Evan
From 8de276fb0f14059353e4aeb3af8ca14a889887ec Mon Sep 17 00:00:00 2001
From: Jani Hakala
Date: Wed, 20 Nov 2019 21:37:03 +0200
Subject: [PATCH] Fix incorrect bignum allocation sizes
Memory allocation problems were detected by AddressSanitizer provided
by gcc 9.2.1. When lolevel-tests.scm was run, AddressSanitizer pointed
out bignum1 and bignum2 related problems in library.scm and srfi-4.scm.
In library.scm, C_bignum2 needs 4 words (header, sign and the two digit
words), plus the 2 words for the bignum wrapper.
In srfi-4.scm, the [su]32vector-ref functions might ultimately call
C_bignum1, which needs 5 words.
Signed-off-by: Evan Hanson
---
c-platform.scm | 8 ++--
library.scm| 4 ++--
srfi-4.scm | 4 ++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/c-platform.scm b/c-platform.scm
index 61a4ac87..27fdb65d 100644
--- a/c-platform.scm
+++ b/c-platform.scm
@@ -78,6 +78,7 @@
(define default-units '(library eval))
(define words-per-flonum 4)
+(define min-words-per-bignum 5)
(eq-inline-operator "C_eqp")
(membership-test-operators
@@ -968,8 +969,11 @@
(rewrite 'chicken.memory#pointer-f32-set! 2 2 "C_u_i_pointer_f32_set" #f)
(rewrite 'chicken.memory#pointer-f64-set! 2 2 "C_u_i_pointer_f64_set" #f)
-(rewrite 'chicken.memory#pointer-u32-ref 16 1 "C_a_u_i_pointer_u32_ref" #f words-per-flonum)
-(rewrite 'chicken.memory#pointer-s32-ref 16 1 "C_a_u_i_pointer_s32_ref" #f words-per-flonum)
+;; on 32-bit platforms, 32-bit integers do not always fit in a word,
+;; bignum1 and bignum wrapper (5 words) may be used instead
+(rewrite 'chicken.memory#pointer-u32-ref 16 1 "C_a_u_i_pointer_u32_ref" #f min-words-per-bignum)
+(rewrite 'chicken.memory#pointer-s32-ref 16 1 "C_a_u_i_pointer_s32_ref" #f min-words-per-bignum)
+
(rewrite 'chicken.memory#pointer-f32-ref 16 1 "C_a_u_i_pointer_f32_ref" #f words-per-flonum)
(rewrite 'chicken.memory#pointer-f64-ref 16 1 "C_a_u_i_pointer_f64_ref" #f words-per-flonum)
diff --git a/library.scm b/library.scm
index e52d1452..7b8c577a 100644
--- a/library.scm
+++ b/library.scm
@@ -2468,7 +2468,7 @@ EOF
(end (or hashes digits)))
(and-let* ((end)
(num (##core#inline_allocate
- ("C_s_a_i_digits_to_integer" 5)
+ ("C_s_a_i_digits_to_integer" 6)
str start (car end) radix neg?)))
(when hashes; Eeewww. Feeling dirty yet?
(set! seen-hashes? #t)
@@ -2482,7 +2482,7 @@ EOF
(and-let* ((start (if sign (fx+ start 1) start))
(end (scan-digits start)))
(cons (##core#inline_allocate
- ("C_s_a_i_digits_to_integer" 5)
+ ("C_s_a_i_digits_to_integer" 6)
str start (car end) radix (eq? sign 'neg))
(cdr end)))
(scan-decimal-tail ; The part after the decimal dot
diff --git a/srfi-4.scm b/srfi-4.scm
index 6faaa475..537d8288 100644
--- a/srfi-4.scm
+++ b/srfi-4.scm
@@ -209,13 +209,13 @@ EOF
(define u32vector-ref
(getter-with-setter
- (lambda (x i) (##core#inline_allocate ("C_a_i_u32vector_ref" 4) x i))
+ (lambda (x i) (##core#inline_allocate ("C_a_i_u32vector_ref" 5) x i))
u32vector-set!
"(chicken.srfi-4#u32vector-ref v i)"))
(define s32vector-ref
(getter-with-setter
- (lambda (x i) (##core#inline_allocate ("C_a_i_s32vector_ref" 4) x i))
+ (lambda (x i) (##core#inline_allocate ("C_a_i_s32vector_ref" 5) x i))
s32vector-set!
"(chicken.srfi-4#s32vector-ref v i)"))
--
2.23.0
signature.asc
Description: PGP signature
Re: [PATCH] Also optimize case-lambda using rest-cdr mechanism (#1623)
Hi Peter, On 2019-11-21 17:16, Peter Bex wrote: > The attached patch simply adds another core form ##core#rest-length which > is optimized away to check the "c" argument in the C code which indicates > the length of the argvector instead of taking the length of the rest list > variable. I had a look at this, and finally had some time to look at the earlier patch as well. Impressive stuff! I think, given that all that foundation work is sound, this is an obvious next step, so I've applied it too. Cheers, Evan signature.asc Description: PGP signature
Re: [PATCH] csc: -c and multiple input files
On 2019-11-19 11:54, felix.winkelm...@bevuta.com wrote: > Attached is a patch for handling the case given in #1655 in a less > confusing way (by signalling an error). Makes sense to me, thanks Felix. Evan signature.asc Description: PGP signature
Re: [PATCH] Fix decompose-directory and change drives before attempting to build eggs on Windows
On 2019-11-22 19:16, Peter Bex wrote: > On Mon, Nov 11, 2019 at 08:57:11PM +0100, Peter Bex wrote: > > I actually prefer it the "cd /d" way, because then we can't accidentally > > forget to introduce this elsewhere: we can just call cd-command and it > > will work on Windows if it works on UNIX. The code will be shorter as > > well. So let's make a new patch. > > And here it is. Thanks Peter, applied. Evan signature.asc Description: PGP signature
Re: [PATCH] Fix decompose-directory and change drives before attempting to build eggs on Windows
On 2019-11-11 13:57, Lassi Kortela wrote: > > > The fix is to first switch drives, then run cd. > > `cd /d c:\foo` can be used to switch the drive and the directory both in one > command. > Oh, that's good to know, thanks Lassi. Peter, do you think it's worth switching to use this flag instead? There will be a special case for Windows either way, but one approach might be simpler. Evan
Re: [PATCH] Fix decompose-directory and change drives before attempting to build eggs on Windows
Hi Peter, On 2019-11-09 17:15, Peter Bex wrote: > I had a look at #1647 and the fix seems to me to be pretty > straightforward. The build.bat which chicken-install creates > contains a "cd" command, but on Windows, cd won't change to > the corresponding drive, so when we then try to compile the > source file, we'll get an error because we're still on the other > drive. > > The fix is to first switch drives, then run cd. > > While working on this, I discovered that decompose-directory crashes > on Windows when the path has a drive in it, so the first patch first > fixes that bug, the second patch actually fixes the bug from the ticket. That all makes sense, thanks for investigating this. I've applied both of these, and a quick test on Windows shows everything is OK. Cheers, Evan signature.asc Description: PGP signature
Re: [Chicken-hackers] [PATCH] Print more information about why an identifier cannot be exported
On 2019-10-19 10:23, megane wrote: > This doesn't say why the abbreviation cannot be exported. As a beginner > I'm left wondering that maybe there's some strange reason, but the > compiler is not telling it to me. Good point, thanks for the better suggestions. > - Warning: Cannot export `a-type-alias' because it is a type > abbreviation. > > I'd vote for this, because of its shortness. The warning is actually > fatal, and the compilation will stop shortly with a message that > includes the module name. Yeah, I've gone with this one. "Because it refers to a foo" is probably more correct, but I don't think the extra pedantry will help people fix their programs, which is the whole point of these messages... Anyway, pushed, thank you megane! Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Print more information about why an identifier cannot be exported
Hi megane, That's a nice improvement, good idea. What do you think of these wordings for the warning messages? I think they read a bit more clearly. Warning: In module `mod', type abbreviation `a-type-alias' cannot be exported. Warning: In module `mod', inlined function `an-inline' cannot be exported. Warning: In module `mod', constant `a-constant' cannot be exported. Warning: In module `mod', foreign variable `a-foreign' cannot be exported. Warning: In module `mod', exported identifier `a-undefined' has not been defined. Would you be OK with that change? If so I can apply it. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix how chicken-install handles server errors and add redirect support
Seems to work, thanks Peter. I've applied both. Cheers, Evan 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 #1294 by mentioning in the docs that define-record-printer is not a definition
Hi Peter, On 2019-09-14 15:28, Peter Bex wrote: > I made a few small tweaks to the patch, see attachment. The types.db > entry was syntactically invalid so I fixed that, and I've added checks > that the argument to set-record-printer! is a symbol (the original > macro contains that check as well). I've also added that check to > record-printer, so that both procedures can now be #:enforcing in > types.db. That's better, thanks for catching that (and for having a look in the first place). I've applied this version. Cheers, Evan 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] Replace C_u_i_zerop with inline version
On 2019-09-04 12:38, felix.winkelm...@bevuta.com wrote: > This patch replaces the use of C_u_i_zerop with an inline variant. > The new version has been renamed for binary compatibility, the > old version is deprecated. Looks good to me, pushed! Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] R7RS .sld library imports
Hi Lassi,
On 2019-08-29 15:51, Lassi Kortela wrote:
> How much work would it be to support R7RS .sld imports, such that
>
> (import (foo bar baz))
>
> loads a (define-library ...) form from "{root}/foo/bar/baz.sld" for the
> first matching {root} in the load path? This appears to be the emerging
> standard for R7RS imports.
That shouldn't be too hard, and I think a patch adding such a feature
would be welcome. If that's the convention then we should probably make
it easy to use.
In any case, it should be done in the R7RS egg rather than CHICKEN core.
That already has some extensions w.r.t. library handling (e.g. to make
cond-expand recognise the `library' form). It might need to be
implemented as a compiler extension, though, in order to control library
location.
Cheers,
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1470 and unignore clean/pure declarations
Makes sense to me, applied. This should improve scrutiny when running csc with the default options, too. Cheers, Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1294 by mentioning in the docs that define-record-printer is not a definition
On 2019-08-13 22:16, Evan Hanson wrote: > On 2019-07-12 10:45, Peter Bex wrote: > > On Fri, Jul 12, 2019 at 08:29:58PM +1200, Evan Hanson wrote: > > > As a sidenote, this issue also applies to `define-reader-ctor', and > > > perhaps others; I didn't review the lot. > > > > hm, I didn't think of that one. That's a procedure, which is even > > weirder. > > Yeah, I'm just going to pretend we didn't notice that one for now... I had a look at the behaviour of the other definition forms (read: things that start with "define-") when dropped into the example program on ticket #1294. These work fine: define-record define-record-type define-values These don't work, but they also don't really make sense outside the toplevel (and most of them are documented as such) so I think they're fine to ignore: define-constant define-external define-foreign-type define-foreign-variable define-inline define-interface define-location These don't work, but seem like they probably ought to: define-compiler-syntax define-for-syntax define-reader-ctor define-record-printer define-specialization define-syntax define-type I was surprised to find `define-syntax' in this list. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1294 by mentioning in the docs that define-record-printer is not a definition
On 2019-07-12 10:45, Peter Bex wrote: > On Fri, Jul 12, 2019 at 08:29:58PM +1200, Evan Hanson wrote: > > In any case, I think we should try to address the issue one way or the > > other rather than keep a potential pitfall around. If we don't make it a > > "real" (i.e. fake) definition, could we at least introduce a new name > > and encourage its use? Perhaps `set-record-printer!', maybe even with a > > SRFI 17 setter on the type descriptor? Unfortunately, we probably can't > > remove the old name, since it comes from SRFI 99. But again, making it > > an actual definition seems OK to me. > > It's not from SRFI-99 (or SRFI-9) AFAICT. We can rename it, but that's > a breaking change. Of course we could keep around the old one during a > deprecation phase. Sure, here's a patch that adds a procedural interface as proposed above. This is also the approach Guile uses, although theirs is called `set-record-type-printer!`. Let me know what you think. > > As a sidenote, this issue also applies to `define-reader-ctor', and > > perhaps others; I didn't review the lot. > > hm, I didn't think of that one. That's a procedure, which is even > weirder. Yeah, I'm just going to pretend we didn't notice that one for now... Evan >From a9c71a2dcab99f5b3359fd42e442162d97c82bcf Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Tue, 13 Aug 2019 21:53:35 +1200 Subject: [PATCH] Add `record-printer' and `set-record-printer!' procedures These offer a procedural way to specify how records are printed. They deprecate the `define-record-printer' macro, which isn't a "real" definition (see #1294). --- DEPRECATED| 3 +++ NEWS | 3 +++ chicken.base.import.scm | 2 ++ distribution/manifest | 1 + library.scm | 28 ++-- manual/Module (chicken base) | 19 +-- tests/record-printer-test.scm | 29 + tests/runtests.bat| 6 ++ tests/runtests.sh | 3 +++ types.db | 3 +++ 10 files changed, 85 insertions(+), 12 deletions(-) create mode 100644 tests/record-printer-test.scm diff --git a/DEPRECATED b/DEPRECATED index 6a43e129..8ab451e9 100644 --- a/DEPRECATED +++ b/DEPRECATED @@ -5,6 +5,9 @@ Deprecated functions and variables - ##sys#check-exact and its C implementations C_i_check_exact and C_i_check_exact_2 have been deprecated (see also #1631). +- The define-record-printer macro has been deprecated in favour of + record-printer and set-record-printer! procedures, and a SRFI-17 + setter for the former. 5.0.0 diff --git a/NEWS b/NEWS index e8cc6054..56ad305d 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,9 @@ - for-each and map now behave consistently in compiled and interpreted mode, like in SRFI-1. They now stop when the shortest list is exhausted instead of raising an exception (fixes #1422). + - The procedures `record-printer` and `set-record-printer!` and a +corresponding SRFI-17 setter have been added. These deprecate +`define-record-printer` which isn't a "real" definition (see #1294). - Runtime system - Quoted empty keywords like ||: and :|| are now read like prescribed diff --git a/chicken.base.import.scm b/chicken.base.import.scm index 7c823271..79c8e19f 100644 --- a/chicken.base.import.scm +++ b/chicken.base.import.scm @@ -96,6 +96,8 @@ (quotient . chicken.base#quotient) (rassoc . chicken.base#rassoc) (ratnum? . chicken.base#ratnum?) + (record-printer . chicken.base#record-printer) + (set-record-printer! . chicken.base#set-record-printer!) (setter . chicken.base#setter) (signum . chicken.base#signum) (sleep . chicken.base#sleep) diff --git a/distribution/manifest b/distribution/manifest index 928d5ef1..316736e5 100644 --- a/distribution/manifest +++ b/distribution/manifest @@ -129,6 +129,7 @@ tests/compiler-tests.scm tests/inlining-tests.scm tests/locative-stress-test.scm tests/record-rename-test.scm +tests/record-printer-test.scm tests/r4rstest.scm tests/r4rstest.expected tests/null.scm diff --git a/library.scm b/library.scm index bc0ef42c..142e7f8f 100644 --- a/library.scm +++ b/library.scm @@ -592,6 +592,7 @@ EOF notice procedure-information setter signum string->uninterned-symbol subvector symbol-append vector-copy! vector-resize warning quotient quotient + record-printer set-record-printer! alist-ref alist-update alist-update! rassoc atom? butlast chop compress flatten intersperse join list-of? tail? constantly complement compose conjoin disjoin each flip identity o @@ -660,6 +661,8 @@ EOF (define procedure-information) (define setter) (define string->uninterned-symbol) +(define record-printer) +(define set-record-printer!) (define gensym) @@ -4654,12 +4657,25 @@ EOF (define ##sys#r
Re: [Chicken-hackers] [PATCH 1/1] Fix csi's "report" feature and add guard for `keyword-style' parameter
On 2019-06-29 12:06, Peter Bex wrote: > We could extend this check to ensure it's one of the three recognised > styles, but maybe that's overkill? It looks like if you put any other keyword in there it falls back to the portable style, so I personally think it's OK to leave it alone. Cheers, Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Handle import libraries with static linkage egg property
Hi there, On 2019-05-29 11:39, ko...@upyum.com wrote: > felix.winkelm...@bevuta.com wrote: > > > On 2019-05-07 7:45, Evan Hanson wrote: > > > > On 2019-05-06 13:04, ko...@upyum.com wrote: > > > > > I don't think that patch is right. If you emit import libraries from > > > > > the > > > > > static builds, you will not be able to import modules from the > > > > > evaluator > > > > > when the modules are statically linked, because the module > > > > > registration > > > > > code is taken out. > > > > > > > > Oh, of course, you're right. I suppose the bug is really that the build > > > > script tries to compile these files, then, and not that they aren't > > > > emitted? > > > > > > No, that's not right either. It's a combination of the two: if they're > > > not emitted, there's no file to install and separate compilation is > > > impossible, but if they *are* emitted then they're removed from the > > > compiled artifacts and ipmort-in-eval fails (as you point out). > > > > > > I wonder... For static-only extensions, do we perhaps need to add a call > > > to csc with "-analyze-only" just to produce the import libraries? And in > > > the meantime, should we "undocument" the static option for "linkage" > > > with something like the attached? > > > > I dunno, this somehow defeats the purpose of the linkage property. > > I think it is better to change the behaviour to do the right thing instead > > of defining an switch that has just a single option. > > Should we fix this for 5.1? > > In any case we should probably open a ticket to keep track of that issue. I finally got around to this. I decided it would be dumb to invoke the compiler an extra time just to emit import libraries when we're already compiling the extension once; better to just have csc do what we need it to on that one pass. I spent a while trying to make this work with the current set of options, but in retrospect that's impossible. There are now three situations we need to support: (1) the current "sane default" behaviour where emitting an import library removes it from the program, (2) the situation where a user explicitly drops the library code by passing the "-no-module-registration" flag, and (3) this new situation where we need to both emit the library code and keep it in the program. To support this third case I've added a flag that causes the module registration code to be preserved in the program unconditionally -- basically the inverse of `-no-module-registration' -- which chicken-install then uses. I think this is a pretty logical addition, and it fixes the linkage egg property, but let me know what you think. Cheers, Evan >From 38500878dd3e6251c8d4ec0de89209d5c22677c7 Mon Sep 17 00:00:00 2001 From: Evan Hanson Date: Sat, 27 Jul 2019 19:46:43 +1200 Subject: [PATCH] Handle import libraries with static linkage egg property For fully-static extensions, we need to both emit import libraries (so they can be installed to support batch compilation) and compile module registration code into the resulting objects (so the modules work when imported in eval from statically-compiled programs). This isn't possible with the current options, so add a flag and make the `compile-module-registration` setting tri-valued: yes, no, and unset (to keep the default behaviour). The egg toolchain then uses this flag to compile static objects as usual while also emitting import libraries when the static-linkage egg property is used. --- NEWS | 5 + batch-driver.scm | 11 +++ c-platform.scm | 3 ++- chicken.mdoc | 7 +-- core.scm | 33 - csc.mdoc | 7 +-- csc.scm | 8 ++-- egg-compile.scm | 14 ++ support.scm | 4 +++- 9 files changed, 59 insertions(+), 33 deletions(-) diff --git a/NEWS b/NEWS index 653f5f0d..c25b4b0b 100644 --- a/NEWS +++ b/NEWS @@ -26,6 +26,11 @@ - Inline files no longer refer to unexported foreign stub functions (fixes #1440, thanks to "megane"). +- Tools + - The new "-module-registration" options causes module registration +code to always be included in the program, even when it has also +been emitted as a separate file (for example with "-J"). + 5.1.0 diff --git a/batch-driver.scm b/batch-driver.scm index a7d791fd..ac871a8b 100644 --- a/batch-driver.scm +++ b/batch-driver.scm @@ -181,8 +181,10 @@ (initialize-compiler) (set! explicit-use-flag (memq 'explicit-use options)) (set! emit-debug-info (memq 'debug-info options)) - (set! enable-mo
Re: [Chicken-hackers] [PATCH] Fix #1422 by always stopping on the first list that's exhausted
LGTM, applied. Thanks Peter. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1294 by mentioning in the docs that define-record-printer is not a definition
On 2019-07-12 10:45, Peter Bex wrote: > > In any case, I think we should try to address the issue one way or the > > other rather than keep a potential pitfall around. If we don't make it a > > "real" (i.e. fake) definition, could we at least introduce a new name > > and encourage its use? Perhaps `set-record-printer!', maybe even with a > > SRFI 17 setter on the type descriptor? Unfortunately, we probably can't > > remove the old name, since it comes from SRFI 99. But again, making it > > an actual definition seems OK to me. > > It's not from SRFI-99 (or SRFI-9) AFAICT. We can rename it, but that's > a breaking change. Of course we could keep around the old one during a > deprecation phase. Oh, indeed. The srfi-99 egg includes it so I assumed it came from the SRFI, but that must just be for compatibility with CHICKEN. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1625 and add srfi-88 module plus feature identifier
Hi Peter, Very nice work, I've pushed these. Thanks for the detailed explanation. On 2019-06-29 17:10, Peter Bex wrote: > The second patch completes SRFI-88 support by registering a module > for it and adding the feature identifier (which I think was just an > oversight). Strictly speaking, we might not define the identifier > when keyword mode is prefix or none, but then we still do have the > srfi-88 procedures, so I'm not 100% sure. > > We could let the features procedure check the keyword style and add > srfi-88 dynamically if it's #:suffix only... Yeah, I'm not sure. I can see it both ways. Oh well, that can follow if we decide it's best, but I didn't want to hold these patches up for now. Cheers, Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix #1294 by mentioning in the docs that define-record-printer is not a definition
On 2019-06-30 19:25, Peter Bex wrote: > I had another look at #1294 and decided that, while we *could* fake the > record type printer as a definition by wrapping it in a (define) call > with a gensym, I think it doesn't make much sense. This actually makes good sense to me. Why don't you like this approach? In any case, I think we should try to address the issue one way or the other rather than keep a potential pitfall around. If we don't make it a "real" (i.e. fake) definition, could we at least introduce a new name and encourage its use? Perhaps `set-record-printer!', maybe even with a SRFI 17 setter on the type descriptor? Unfortunately, we probably can't remove the old name, since it comes from SRFI 99. But again, making it an actual definition seems OK to me. As a sidenote, this issue also applies to `define-reader-ctor', and perhaps others; I didn't review the lot. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix memory-statistics
Applied, thanks megane! Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
