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] 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

[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

[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:

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

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] [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

[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

[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

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] [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] 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?

[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

[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] 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 {{:}}

[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 @@

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

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] 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] [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] [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

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] 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] 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] 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] 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

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

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

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

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 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

[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] 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 >

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

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

[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] 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

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

[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

<    1   2