[Chicken-hackers] Possible patches to the module system

Hello, I made two possible patches to the module system fixing some issues with * exports. The patches can be found in the tickets #865 and #843. I have assumed that the module-exist-list is used solely for the purpose of forming the export list in the case the module-export-list is initially

Re: [Chicken-hackers] [Chicken-users] using types

Jörg F. Wittenberger writes: On Feb 21 2013, Jörg F. Wittenberger wrote: Somehow I can't verify that my type declarations are actually effective. I've been able to verify that my .types files are not ever consulted. Using strace I found that the foo.types file is searched for in

Re: [Chicken-hackers] Whishlist entry: macro expansion for type declarations.

Hi, have you tried define-type: syntax(define-type NAME TYPE)/syntax Defines a type-abbreviation {{NAME}} that can be used in place of {{TYPE}}. Type-abbreviations defined inside a module are not visible outside of that module. ___ Chicken-hackers

[Chicken-hackers] [PATCH] Add unexport form for modules (updated for chicken 5)

Hi, here's an updated version of the unexport patch for chicken 5. There were a couple of changes related to renamed identifiers and the new 'library' slot for the module record. Tested with the 5.0.0pre1 tarball. Here's the copy-pasted description from the previous patch: The implementation

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

Evan Hanson writes: > Hi folks, > > I had a quick look at this patch but it doesn't apply cleanly to > chicken-5 anymore, if it ever did. I would like to keep this moving and > eventually land something like it, however, so I've opened issue #1383 > to track it. The patch

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

John Cowan <co...@ccil.org> writes: > On Tue, Jul 4, 2017 at 10:11 AM, megane <megan...@gmail.com> wrote: > > Working with the export list is painful without some syntax support. You >> end up repeating every identifier name otherwise. >> > > I consider th

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

Peter Bex writes: > Unexport seems to me to be solving a non-problem. Exporting * always > seemed questionable to me, since it is too implicit and very error-prone. > It's very rare that you don't introduce *any* helper procedures or > macros. In fact, introducing

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

Peter Bex writes: > On Thu, Jun 08, 2017 at 11:19:05AM +1200, Evan Hanson wrote: [...] >> I like export, personally (in fact, I'd rather do away with the module >> list, but that's neither here nor there), but I do think it's odd that >> it lives in "chicken" while

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

Peter Bex <pe...@more-magic.net> writes: > On Thu, Jun 08, 2017 at 11:24:44AM +0300, megane wrote: >> Reexport is nice if you have a big module (say a graphics library) you >> want to organize into smaller chunks internally. > > Yeah, but why can't "export&q

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

Hi, I was thinking maybe we could leave the declarations as they are and add an explicit counterpart for export. The implementation may be pretty easy to do by just updating the module export and what not lists. Maybe call the new syntax hide-export. I could try creating a patch if this sounds

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

Evan Hanson writes: > If I understand correctly, this would effectively be an "unexport" of > sorts, like so: Yes, that's what I was thinking. > > Is that right? Personally, I'd rather make (declare (hide ...)) simply > do the right thing -- the right thing being the

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

Evan Hanson writes: >> Which foo should be hidden? Both, or none? > > Personally, I'd expect the following behaviour, depending on where the > declaration appears: > I did some tests with and without the POC patch I sent yesterday. Some observations: (these are the only

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

felix.winkelm...@bevuta.com writes: > > Hi! > > > Sorry, I'm rather late to this discussion, and I apologize for that. But > note that > the whole idea to extend the hide declaration for unexporting from modules is > bogus. Declarations work at a completely different level, and aren't even >

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

Hi! This patch adds a counterpart for the export syntax form. The implementation is pretty straightforward. A new slot, called module-unexport-list, is added to the module record. Unexport adds identifiers to this list if the module export list is *. In ##sys#finalize-module all identifiers

Re: [Chicken-hackers] [PATCH 5] Fix compiler-typecase trail restore

One more time. megane <megan...@gmail.com> writes: > Hi! > I wonder what happened. Maybe now? > > felix.winkelm...@bevuta.com writes: > >>> Hi, >>> >>> Here's a small fix. >>> >> >> Hi! Somehow the patch doesn't seemed

[Chicken-hackers] OPATCHO Fix procedure subtype relation when #!rest is involved

Hi, Currently this doesn't compile: (compiler-typecase (the (#!rest fixnum -> *) 1) ((fixnum fixnum -> *) 1)) Error: at toplevel: (rest.scm:7) no clause applies in `compiler-typecase' for expression of type `(procedure (#!rest fixnum) *)': (procedure (fixnum fixnum) *) Here's a more concrete

Re: [Chicken-hackers] OPATCHO Fix procedure subtype relation when #!rest is involved

x) *))) (test (< (procedure (#!rest (or x y)) *) (procedure (#!rest x) *))) (test (< (procedure (#!rest (or x y)) *) (procedure (y #!rest x) *))) I'm trying to find a better fix. megane <megan...@gmail.com> writes: > Hi, > > Currently this doesn't compile: > (compiler-typeca

[Chicken-hackers] [PATCH] Remove some type expansion related code duplication in scrutinizer

Hi, There were cases in match-types which essentially duplicated what expand-type was doing. This is a simple refactoring to remove that duplication. diff --git a/scrutinizer.scm b/scrutinizer.scm index ece07ed..c89bd60 100644 --- a/scrutinizer.scm +++ b/scrutinizer.scm @@ -138,6 +138,15 @@

[Chicken-hackers] [PATCH] Add 'a shorthand for forall types

Hello, This adds support for declaring forall types in more compact manner. It supports syntax like ('a -> 'a) to declare the type (forall (a) (a -> a)). diff --git a/manual/Types b/manual/Types index 6d5de10..cab029d 100644 --- a/manual/Types +++ b/manual/Types @@ -158,6 +158,12 @@ or {{:}}

Re: [Chicken-hackers] [PATCH][5] Change procedure argument type relation to contravariant

Hi, Here's a new version of the patch. This tries to handle #!optional and #!rest in procedure types correctly, in addition to the parameter contravariance stuff. The implementation should be cleaner now. This is still not ready to be merged to the master. At least the signatures in types.db

[Chicken-hackers] Make the struct type parameterized ?

Hi everyone, What do you think about this idea? I had this idea yesterday that you could add parameters to the struct type annotation. For example: (struct hash-table fixnum symbol) With this new syntax you could tweak the types.db a bit with entries like: (hash-table-ref (forall (k v)

[Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages

Hello, This patch changes the warning messages so that any types are printed with `pp` on new lines. This should make it just a bit easier to find the reason for more complex type mismatches. See the attachment for sample output. diff --git a/scrutinizer.scm b/scrutinizer.scm index

[Chicken-hackers] [PATCH] * eval.scm (compile): Remove failing environment lookup in ##core#set!

Hi, Here's a small simplification. >From 1b1a40c347789e3aa01ce6b2a8f596cf15f9c7f0 Mon Sep 17 00:00:00 2001 From: megane Date: Fri, 3 Aug 2018 13:54:05 +0300 Subject: [PATCH] * eval.scm (compile): Remove failing environment lookup in ##core#set! The x is the full expression (e.g. '(##core#

Re: [Chicken-hackers] [PATCH] * eval.scm (compile): Remove failing environment lookup in ##core#set!

I couldn't come up with a way to test this. You can test the old one if you add print to the case and run this: (let ([l '(##core#set! x 1)]) (##sys#current-environment (cons `(,l . foo) (##sys#current-environment))) (eval l)) ___ Chicken-hackers

[Chicken-hackers] Is this rewrite rule for fxmod correct in C5?

Hi, I just found out that fxmod has been changed to work like 'modulo' in C5. (Well actually I found out that fxmod doesn't work like modulo in C4) However, in C5, there's this rule in c-backend.scm: (rewrite 'chicken.fixnum#fxmod 17 2 "C_fixnum_modulo" "C_u_fixnum_modulo") Here's the

[Chicken-hackers] [PATCH] * chicken.h: Fix C_u_fixnum_modulo by extracting the definition from C_fixnum_modulo

Hi, Using the -unsafe flag would cause fxmod to work differently than without. The patch is pretty simple. >From 1fd723ea1ae60a054881b0af903d3e0e0be219e6 Mon Sep 17 00:00:00 2001 From: megane Date: Fri, 17 Aug 2018 14:59:09 +0300 Subject: [PATCH] * chicken.h: Fix C_u_fixnum_mod

Re: [Chicken-hackers] [PATCH] * chicken.h: Fix C_u_fixnum_modulo by extracting the definition from C_fixnum_modulo

Well that was incorrect. There was a missing return. I don't know how the tests passed. >From a5a2a283101a2056b2f8a63873a3869ef2740630 Mon Sep 17 00:00:00 2001 From: megane Date: Fri, 17 Aug 2018 14:59:09 +0300 Subject: [PATCH] * chicken.h: Fix C_u_fixnum_modulo by extracting the definit

Re: [Chicken-hackers] [PATCH] * chicken.h: Fix C_u_fixnum_modulo by extracting the definition from C_fixnum_modulo

I managed to send the same file again, here's the fixed patch. >From cf0cffc4921c4194fc5a807bcf77f3ef1ee284d6 Mon Sep 17 00:00:00 2001 From: megane Date: Fri, 17 Aug 2018 14:59:09 +0300 Subject: [PATCH] * chicken.h: Fix C_u_fixnum_modulo by extracting the definition from C_fixnum_mod

Re: [Chicken-hackers] functor support

Hi Jörg, Jörg F. Wittenberger writes: > Hi Chickeneers, > > attached is a test trying to package the functor example from the > documentation as an egg. This is no good except to showcase some issues. > > 1. "include" should be expanded. (I reported this before, now here is > the simple

[Chicken-hackers] Fwd: Re: basic question regarding interfaces

Hi, This message was supposed to go to the mailing list, but I sent it only to Martin by accident. I opened a ticket (#1482) for this. megane writes: > Hi, > > There indeed seems to be a bug in the interface handling. You can see > that in ##sys#validate-exports (modules.scm

Re: [Chicken-hackers] basic question regarding interfaces

Hi, does this patch work for you? diff --git a/modules.scm b/modules.scm index 73e8947..b0cdce5 100644 --- a/modules.scm +++ b/modules.scm @@ -803,7 +803,7 @@ (cons (cdr x) (loop (cdr xps ; currently not used ((eq? #:interface (car x)) (if (and (pair? (cdr x)) (symbol?

Re: [Chicken-hackers] [PATCH][5] Change procedure argument type relation to contravariant

forall (a b) ((a b -> *) -> *))) Even if you use forall there's a risk the type will go through resolve, which will resolve all non-unified type variables into '*. Evan Hanson <ev...@foldling.org> writes: > Hi megane, > > I just wanted to let you know this hasn't fallen off the map -- I

[Chicken-hackers] [PATCH][5] Use more descriptive names in typematch-tests.scm

Hello, while I was reading the file I decided to refactor the tests a bit. The macro checkp wasn't quite doing what it was supposed to. Checkp tests that predicates work. The statement (checkp PRED TYPE VALUE) tries to assert that in a branch where (PRED VALUE) is true the type of VALUE is

[Chicken-hackers] [PATCH][5] Change procedure argument type relation to contravariant

Hello again, this fixes #1446 I reported earlier. The patch applies after the other patch I posted today. Here's a simple example showing the issue: (define-type T (or string boolean)) (: foo ((T T -> any) T -> any)) (define (foo f a) (f a "foo")) (: bar (string string -> any)) (define (bar a

[Chicken-hackers] [PATCH 5] Fix compiler-typecase trail restore

Hi, Here's a small fix. Consider this example: (compiler-typecase (list 2 'a) ((forall (x) (list x x)) 1) (else #t)) Trying to compile this causes an error in the compiler: Error: (cdr) bad argument type: #f In this typecase the first case fails (cannot match/unify 2 and 'a). The failed

[Chicken-hackers] [PATCH] * scheduler.scm: import chicken.condition for 'signal' used in ##sys#default-exception-handler

rom 80a167ab490e582f4aaf80aa7c74ff1c576cbb5d Mon Sep 17 00:00:00 2001 From: megane Date: Sun, 21 Oct 2018 11:45:49 +0300 Subject: [PATCH] * scheduler.scm: import chicken.condition for 'signal' used in ##sys#default-exception-handler Kooda found this on IRC: ;; Segfaults when run with 'csi -:x test.scm' (import srfi-18) (def

Re: [Chicken-hackers] [PATCH] Add 'a shorthand for forall types

Peter Bex writes: > On Tue, May 29, 2018 at 01:18:02PM +0300, megane wrote: >> Hello, >> >> This adds support for declaring forall types in more compact manner. >> >> It supports syntax like ('a -> 'a) to declare the type >> (fora

Re: [Chicken-hackers] PATCH Re: slow polling

Jörg F. Wittenberger writes: > Am 19.02.2016 um 22:39 schrieb Jörg F. Wittenberger: >> ... >>> I opened ticket 1259 for this. >>> >>> To make the kind reviewers job easier, I'll post diffs in piecemeal here. > > This patch goes after killing a single - but important - comment line in >

Re: [Chicken-hackers] [PATCH] * scrutinizer.scm: Fix renaming issue with 'the'

Evan Hanson writes: > Hey megane, good find once again. Sign-off attached. > > That's a nice idea regarding tv handling. Some thoughts about that are > inline below. Hey Evan, thanks for taking a look. Sorry, I forgot there was this PS about type variable records in the mail when

Re: [Chicken-hackers] [PATCH] * scrutinizer.scm: Fix renaming issue with 'the'

Peter Bex writes: > On Mon, Dec 10, 2018 at 09:24:57PM +0200, megane wrote: >> > On 2018-12-02 18:02, megane wrote: [...] >> >> I think the biggest cost from typeenv comes from the two first tests in >> 'match1. Here we check all symbols against the typeenv, whic

[Chicken-hackers] [PATCH] Change procedure argument type relation to contravariant + issue

'a ... 'a -> 'b)) Or with this syntax suggested by Evan: (: foo (((each (a) a) -> 'b) (each (a) a) -> 'b)) Implementing this is not easy, but not extremely hard, either. Cheers >From f2d011e2d6008e09e37f71f412804ccb85de872f Mon Sep 17 00:00:00 2001 From: megane Date: Thu, 27 Dec 201

Re: [Chicken-hackers] [PATCH] Add unexport form for modules (updated for chicken 5)

Hi, Here's a version with more extensive test suite. Tested to work with master. >From f2ed6123151b96604cf6409cb3f169a7e93b475b Mon Sep 17 00:00:00 2001 From: megane Date: Tue, 11 Dec 2018 09:08:42 +0200 Subject: [PATCH] Add 'unexport form for modules --- expand.

Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages

Heads up. This needs to be updated as 0011 is now in the master branch. I'll update both of these batches and try to write better commit messages for them too. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org

[Chicken-hackers] [PATH] scrutinzer: Fix another renaming issue

Hello, Here's fix to another renaming issue. This is unrelated to the other one I just sent. Patch message should explain everything. Regards >From 849bd565dcf03b1fd03f3426ff4f65810b0dda29 Mon Sep 17 00:00:00 2001 From: megane Date: Sun, 2 Dec 2018 18:23:44 +0200 Subject: [PA

[Chicken-hackers] [PATCH] * scrutinizer.scm: Fix renaming issue with 'the'

Intelligence Programming, there's a short explanation of this in chapter 11.6 "Destructive Unification". Regards >From 049c0a7ebe6351377bff8e11c59a81a5da20eb14 Mon Sep 17 00:00:00 2001 From: megane Date: Sat, 1 Dec 2018 10:24:16 +0200 Subject: [PATCH] * scrutinizer.scm: Fix r

Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages

felix.winkelm...@bevuta.com writes: >> >> Hi, >> >> Here's a reworked patch set. It's not exactly small, but I tried to make >> it pretty easy to follow. Except maybe for the last patch, which >> digs for some extra info from the nodes. >> >> There's small bit of back-and-forth in the

Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages

Evan Hanson writes: > Here's a signed-off version of the first patch in this set. I've also > updated the Windows test script and added the new files to the > distribution manifest. > > Please feel free to review and apply this one without waiting for the > others in megane's message. Doing it

Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages

Evan Hanson writes: > On 2019-01-10 18:12, megane wrote: >> Evan Hanson writes: [snip] >> Do you agree with approach I took about gensym'd variables in the second >> patch? If not, I think I'll have to come up with something else. > > That's a nice idea,

[Chicken-hackers] [PATCH 2/2] * scrutinizer.scm (refine-types): Add special case for (or pair null) and list-of

Hi, Here's a patch for #1533. The fix itself is pretty simple. The first patch makes scrutinizer tests give more info when a test fails, which makes it faster to figure out these refinement issues. >From 7eca29fcaef8a8465b900c1400118982e58eaa7b Mon Sep 17 00:00:00 2001 From: megane Date:

[Chicken-hackers] Regarding #1564: srfi-18: (mutex-unlock) Internal scheduler error

Hi, Here's another version that crashes quickly with "very high probability". (cond-expand (chicken-5 (import (chicken base)) (import (chicken time)) (import srfi-18)) (else (import chicken) (use srfi-18))) (define m (make-mutex)) (print "@@ " (current-thread)

Re: [Chicken-hackers] Some undefined patches

felix.winkelm...@bevuta.com writes: >> Another change is considering 'undefined' as a truthy value. The >> interpreter considers 'undefined' truthy, too. > > Undefined is undefined, we shouldn't make any assumption here. Hi Felix, When the scrutinizer walks (begin) it knows the returned value

Re: [Chicken-hackers] Pessimizing undefined behavior

John Cowan writes: > On Mon, Apr 1, 2019 at 11:26 PM megane wrote: > > When the scrutinizer walks (begin) it knows the returned value is >> undefined. [...] > > In Scheme, whoever writes (begin) in a value context, even as a result > of macro expansion, is almost ce

Re: [Chicken-hackers] Pessimizing undefined behavior

felix.winkelm...@bevuta.com writes: >> And it has to be error, not just a warning. Otherwise the warning just >> flashes by while you're getting some coffee. > > That's the point - it is an error under your interpretation only. It's > still perfectly legal code, even if it may not make sense.

Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages

Evan Hanson writes: > Hi folks, > Hi Evan! [snip] > * Patch 0012 - I don't think the name provides much benefit, and in > any case the way it was printed (with parens) was visually > confusing. Better to use "; " or the like, later. I didn't like that either. I just didn't have

[Chicken-hackers] [PATCH] Remove renaming detail from printed type variables

00:00:00 2001 From: megane Date: Sun, 24 Mar 2019 09:49:00 +0200 Subject: [PATCH] Remove renaming detail from printed type variables --- scrutinizer.scm | 18 -- tests/scrutinizer-message-format.expected | 4 ++-- tests/scrutiny.expec

Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages

felix.winkelm...@bevuta.com writes: >> '(list a123) -> `(list ,(gensym 'a123)), where the symbol a123 is the >> name of the TV. This symbol is used to store a value in the unification >> trail. > > Note that you could store the original name on the plist of the gensym, > then deref the chain

Re: [Chicken-hackers] [PATCH] Fix arguments to scrutiny reporting procedure for `append'

ies on top of this fix. >From 5cac6464f29b660745bbaef2bbe8cc4a2c43302f Mon Sep 17 00:00:00 2001 From: megane Date: Mon, 25 Mar 2019 14:15:19 +0200 Subject: [PATCH] Make scrutinizer message format test suite more comprehensive --- tests/scrutinizer-message-format.expected | 518 ++---

Re: [Chicken-hackers] Pessimizing undefined behavior

felix.winkelm...@bevuta.com writes: >> >> Based on my limited observations (##core#undefined) will always have >> >> the value 30L at runtime. This is not equal to 6L (or #f). Therefore >> >> an undefined value in conditional test will always cause the true >> >> branch to be chosen. >> > >> >

Re: [Chicken-hackers] Pessimizing undefined behavior

megane writes: > felix.winkelm...@bevuta.com writes: > >>> >> Based on my limited observations (##core#undefined) will always have >>> >> the value 30L at runtime. This is not equal to 6L (or #f). Therefore >>> >> an undefined value in condit

Re: [Chicken-hackers] Pessimizing undefined behavior

felix.winkelm...@bevuta.com writes: >> > No, but it could, depending on some arcane optimization that someone >> > may implement in the future (or not). It's simply open to the >> > implementation. >> > >> >> There's the possiblity of documenting this optimization: >> >> "If the expression's

Re: [Chicken-hackers] Pessimizing undefined behavior

felix.winkelm...@bevuta.com writes: > I think this is getting out of hand... I think this got a bit out of hand. I'll try to be more mindful of our time in the future. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org

Re: [Chicken-hackers] Pessimizing undefined behavior

megane writes: > felix.winkelm...@bevuta.com writes: > >>> >>> Nothing changes if we statically assign these values, the user still >>> cannot rely on undefined to be either true or false. >> >> Once you give a fixed meaning, even by doing an optimi

Re: [Chicken-hackers] Pessimizing undefined behavior

felix.winkelm...@bevuta.com writes: >> >> Nothing changes if we statically assign these values, the user still >> cannot rely on undefined to be either true or false. > > Once you give a fixed meaning, even by doing an optimization based > on this meaning, users _will_ start to rely on it. At

Re: [Chicken-hackers] [PATCH] Fix arguments to scrutiny reporting procedure for `append'

Evan Hanson writes: > On 2019-03-25 14:23, megane wrote: >> The last patchset contained a more comprehensive message format test >> suite. I guess I just forgot to mention that, sorry :P >> >> Here's a patch that applies on top of this fix. > > Thanks megane

[Chicken-hackers] [PATCH] * runtime.c (C_delete_symbol_table): Remove dead code

Hi! Here's a small one. >From b0bd69d84ca7825a23a878160b65e0fa29c2e18c Mon Sep 17 00:00:00 2001 From: megane Date: Sun, 24 Mar 2019 10:22:08 +0200 Subject: [PATCH] * runtime.c (C_delete_symbol_table): Remove dead code Variable prev is never assigned to. Therefore only the false branch is e

Re: [Chicken-hackers] [PATCH 2/2] Try constant folding before installing specializations

Peter Bex writes: > On Thu, Feb 28, 2019 at 10:15:50AM +0200, megane wrote: >> Hi, >> >> Here's a small improvement to optimization. The commits should tell the >> story. This might have performance implications. >> >> I'm thinking that maybe this sho

[Chicken-hackers] [PATCH 2/2] Try constant folding before installing specializations

rom 2672fe0808f42810d195a865a8c3187158599e8e Mon Sep 17 00:00:00 2001 From: megane Date: Thu, 28 Feb 2019 07:33:06 +0200 Subject: [PATCH 1/2] * support.scm (constant-form-eval): Simplify logic Change the code so 'k' is only called from tail position. This simplifies the handling of case wh

Re: [Chicken-hackers] [PATCH] Use vertical space more liberally in some scrutinizer messages

felix.winkelm...@bevuta.com writes: >> Hi folks, >> >> I've just pushed most of these patches, with signoffs, to a branch >> called "scrutiny-message-formatting", and I think we should merge it. > > Thanks for doing this, I've ran the tests and so far things look good. > > I'm a bit concerned

[Chicken-hackers] [PATCH] Make imports faster

Hi, Here's a small patch that makes some things compile a lot faster. >From d2d8dbfbb8863b7c5cc227e3f1627e9ebd067d89 Mon Sep 17 00:00:00 2001 From: megane Date: Wed, 20 Mar 2019 15:15:25 +0200 Subject: [PATCH] Make imports faster Importing modules with many identifiers (e.g. wrappers for

Re: [Chicken-hackers] [PATCH] Mostly fix #1604

Peter Bex writes: > On Wed, May 29, 2019 at 10:39:54AM +0300, megane wrote: >> Consider the case (= a b c). If the C_and in the rewrite short-circuits >> then 'c' is never evaluated, right? > > Ah, good observation. That might be a problem. It doesn't seem to b

Re: [Chicken-hackers] [PATCH] Mostly fix #1604

Peter Bex writes: > On Sat, May 18, 2019 at 08:46:40PM +0300, megane wrote: >> Here's what I figured out fwiw: >> ... >> (let ((g234 n10)) >> (let ((g235 0)) >> (k144 (##core#inline "C_eqp" g234 g235 >> ... >&

[Chicken-hackers] [PATCH] Fix memory-statistics

Hi, I think the docs are saying the returned values should be semi-space-size, used-semi-space and nursery size. The patch makes it so. >From 9034923bf13216db9c9b2362bd0ca6ff1d4b92d3 Mon Sep 17 00:00:00 2001 From: megane Date: Thu, 20 Jun 2019 10:14:50 +0300 Subject: [PATCH] Fix mem

[Chicken-hackers] [PATCH] Report undefined identifiers in order of appearance

Hi, Here's a small qol improvement. >From b626cdb4038222690e0ca182cfc1fba2665d473b Mon Sep 17 00:00:00 2001 From: megane Date: Thu, 20 Jun 2019 10:45:59 +0300 Subject: [PATCH] Report undefined identifiers in order of appearance Currently identifiers in (foo bar baz) are reported in reve

[Chicken-hackers] [PATCH] * types.db (min , max): Refine return type for float, fixnum

Hi, Here's a small one. >From 3fdf88e06876a0c2afd3c69f8073ee32f5429064 Mon Sep 17 00:00:00 2001 From: megane Date: Thu, 20 Jun 2019 11:22:02 +0300 Subject: [PATCH] * types.db (min , max): Refine return type for float, fixnum arguments --- types.db | 8 1 file changed, 4 inserti

[Chicken-hackers] [PATCH] Disable inlining for functions using foreign stubs

the module that contains the inline (i.e. my-module.so) >From dbd56ad4fcca22b6b4a5be3e50c655ab8425bc1c Mon Sep 17 00:00:00 2001 From: megane Date: Sun, 23 Jun 2019 16:46:50 +0300 Subject: [PATCH] Disable inlining for functions using foreign stubs A workaround until a better solution appears.

Re: [Chicken-hackers] [PATCH] Mostly fix #1604

Peter Bex writes: > Hi all, > > Attached is a patch to restore rewrites for the common arithmetic > operators when in fixnum arithmetic mode. > Interesing stuff! [snip] > > Finally, I ran into this head scratcher: I tried to replace = with eq? in > the code and it sped up the code by a

Re: [Chicken-hackers] [PATCH] Mostly fix #1604

felix.winkelm...@bevuta.com writes: [...] > > Shouldn't the types.db specialization for scheme#= be applied > here? Or can't it figure out the ffixnum types of the arguments? > Even though it is slightly dangerous, the scrutinizer _could_ assume > arguments to numerical primitives are fixnums

Re: [Chicken-hackers] [PATCH] Mostly fix #1604

felix.winkelm...@bevuta.com writes: >> > Shouldn't the types.db specialization for scheme#= be applied >> > here? Or can't it figure out the ffixnum types of the arguments? >> > Even though it is slightly dangerous, the scrutinizer _could_ assume >> > arguments to numerical primitives are

Re: [Chicken-hackers] [PATCH] Mostly fix #1604

felix.winkelm...@bevuta.com writes: >> > Interprocedural flow-analysis is hard, we shouldn't underestimate >> > this. What happens when we declare a type for a toplevel function? >> >> If you're thinking about reassigning globals, how about making >> -fixnum-arithmetic imply -local? If globals

Re: [Chicken-hackers] Handling multiple args in types.db

Peter Bex writes: > On Sat, Apr 27, 2019 at 07:33:49AM +0300, megane wrote: >> Peter Bex writes: >> > On Fri, Apr 26, 2019 at 10:06:15PM +0300, megane wrote: >> >> Hi folks! >> >> >> >> Do you think that adding specializations for m

Re: [Chicken-hackers] Handling multiple args in types.db

Peter Bex writes: > On Sat, Apr 27, 2019 at 09:35:21AM +0300, megane wrote: >> Peter Bex writes: >> > Ah, so this effectively means some of the rewrites are useless since the >> > specializations make them inapplicable. We should consider what to do >> > w

Re: [Chicken-hackers] Handling multiple args in types.db

Peter Bex writes: > On Fri, Apr 26, 2019 at 10:06:15PM +0300, megane wrote: >> Hi folks! >> >> Do you think that adding specializations for multiple argument calls to >> mathematical functions is worth it? Like this: > > We have a rewrite for this already, I

Re: [Chicken-hackers] Floating point performance

Peter Bex writes: [...] > > Of course this means several more intrinsics will have to be added as > safe versions for each of the specific flonum operators. Thoughts? Can't see a reason why not, except it's a lot of code to write. > > I also wonder why the scrutinizer can't detect that

[Chicken-hackers] Handling multiple args in types.db

Hi folks! Do you think that adding specializations for multiple argument calls to mathematical functions is worth it? Like this: diff --git a/types.db b/types.db index b5bc766..e91c482 100644 --- a/types.db +++ b/types.db @@ -316,7 +316,10 @@ ((integer integer) (integer)

Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of replaced variables

megane writes: > Peter Bex writes: > >> On Wed, Jul 03, 2019 at 02:05:21PM +0200, Peter Bex wrote: >>> You're right, good catch! That was an oversight on my part, I only >>> removed the captured check of the other variable. I hope this makes >>> t

Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of replaced variables

Peter Bex writes: > On Wed, Jul 03, 2019 at 02:05:21PM +0200, Peter Bex wrote: >> You're right, good catch! That was an oversight on my part, I only >> removed the captured check of the other variable. I hope this makes >> things faster in more cases. I can make and test a new patch, but

Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of replaced variables

Peter Bex writes: > Hi all, > > I had a look at #1620 and as far as I can tell there's no reason why > an aliased variable cannot be marked as replaceable when either the > alias or the variable it aliases are captured. > > Captured simply means that it needs to be wrapped up in the closure, >

Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of replaced variables

Peter Bex writes: > On Wed, Jul 03, 2019 at 02:05:21PM +0200, Peter Bex wrote: >> You're right, good catch! That was an oversight on my part, I only >> removed the captured check of the other variable. I hope this makes >> things faster in more cases. I can make and test a new patch, but

Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of replaced variables

megane writes: > Peter Bex writes: > > Regarding the capturing, the capture test is still there: > > >> (when (and value (not global)) >> (when (eq? '##core#variable (node-class value)) >> - (let* ((name (first (node-parameters value))) &

Re: [Chicken-hackers] [PATCH] Disable inlining for functions using foreign stubs

Evan Hanson writes: > Hi megane, > > Thanks, this seems like a good fix for now. > > On 2019-06-23 17:29, megane wrote: >> diff --git a/support.scm b/support.scm >> index f412627d..90635761 100644 >> --- a/support.scm >> +++ b/support.scm >> @@

Re: [Chicken-hackers] [PATCH] Fix couple of hangs related to finalizers and (gc #t)

megane writes: > > Also signal an error if trying to re-enter. This also would cause an > infinite loop (when calling (gc #t) inside a finalizer). It would > need special handling if re-entry is to be supported. This is too aggressive. The call from ##sys#interrupt-hook sho

[Chicken-hackers] [PATCH 4/6] * scrutinizer.scm: Infer more exact types after set!

Hi, I'm working on some inference improvements and I noticed the blist keeps accumulating some bogus entries. Commit 0003 removes some of those. There's also a small improvement (0004). >From abe8809647a0f6b64f37c1c512688f9368a42ab2 Mon Sep 17 00:00:00 2001 From: megane Date: Tue, 20 Aug 2

Re: [Chicken-hackers] [PATCH 4/6] * scrutinizer.scm: Infer more exact types after set!

Peter Bex writes: > On Thu, Aug 22, 2019 at 02:51:26PM +0300, megane wrote: >> Hi, >> >> I'm working on some inference improvements and I noticed the blist keeps >> accumulating some bogus entries. Commit 0003 removes some of those. > > Hi Megane, > > I've

Re: [Chicken-hackers] [PATCH] Some simplification rules for nested ##core#inline forms

Peter Bex writes: > On Wed, Sep 04, 2019 at 11:59:31AM +0200, felix.winkelm...@bevuta.com wrote: >> The attached patch adds two optimization rules for certain uses of >> ##core#inline. It basically rewrites >> >> (let (( (##core#inline ...))) >> ( ... ...)) >> >> into >> >> ( ...

[Chicken-hackers] [PATCH] Revert half of "Add some optimizer simplification rules"

Hi, This reverts the rewrite that unearthed #1648. >From 896601d3fd9fd9e9e1a0bac407dccbf0e4bed1e8 Mon Sep 17 00:00:00 2001 From: megane Date: Mon, 16 Sep 2019 12:04:49 +0300 Subject: [PATCH] Revert half of "Add some optimizer simplification rules" This causes uri-generic to fa

[Chicken-hackers] [PATCH] Fix couple of hangs related to finalizers and (gc #t)

"in finalizer") (gc #t))) (print o)) (gc #t) (print "done") >From 752ebde3e6bd66c6ef306c43c673a5883e0bf829 Mon Sep 17 00:00:00 2001 From: megane Date: Fri, 9 Aug 2019 13:39:36 +0300 Subject: [PATCH] Fix couple of hangs related to finalizers and

[Chicken-hackers] [PATCH] Fix C_u_i_s32vector_ref

Hi, Here's a small typo fix. >From d79eb45c6f11dbffd4dc12b90d79f9660d2de97d Mon Sep 17 00:00:00 2001 From: megane Date: Wed, 17 Jul 2019 17:43:31 +0300 Subject: [PATCH] Fix C_u_i_s32vector_ref Negative values were not returned correctly. --- chicken.h | 2 +- 1 file changed, 1 insertion(+)

Re: [Chicken-hackers] [PATCH] Fix #1620 by ignoring captured state of replaced variables

Peter Bex writes: > On Thu, Jul 11, 2019 at 03:15:00PM +0300, megane wrote: >> Of course if this is dropped the other conditions must still meet. >> [...] >> >> Here's a correct way to drop the (not captured) check: >> >> (and (not assigned) >>

Re: [Chicken-hackers] [PATCH] fix #1648 (correctly)

Hi, I took a look at this. Four points: 1. It fixes the runaway inlining. \o/ 2. I don't think the -unroll-limit is that useful option to expose for the user. The -inline-limit already controls the amount of inlining. I couldn't get anything to unroll more than once without having to

Re: [PATCH] Fix allocation size for C_s_a_i_digits_to_integer

Jani Hakala writes: > Hi, > > I found out that there seems to be two similar cases in srfi-4.scm Thanks for the great work! Attached is a patch for this. >From 804f461b413a49ff5021f742ba289f12d282144b Mon Sep 17 00:00:00 2001 From: megane Date: Mon, 18 Nov 2019 16:02:20 +

  1   2   >