Evan Hanson writes:
> 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
Evan Hanson writes:
>
> 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).
Thanks for adding the clarity.
The forall only matters when not
Hi,
Here are some fixes that will result in more specific scrutinizer
annotations, and removes some spurious type warnings (0003).
>From 42657f466937e2dcaf19b385eed31ed27fda0dbd Mon Sep 17 00:00:00 2001
From: megane
Date: Sat, 22 May 2021 07:47:53 +0300
Subject: [PATCH 1/4] FFI: M
LGTM, pushed. Thanks for you both.
I tweaked some whitespace. Also, I reflowed the Acknowledgements file a
bit to make it merge.
Hi,
This is another typo in the code path enabled by the previous rest-arg
typo fix.
>From d916e55a3182c0f015b3c04065c9a171b04dabe0 Mon Sep 17 00:00:00 2001
From: megane
Date: Sun, 30 May 2021 09:48:23 +0300
Subject: [PATCH] * core.scm: Fix rest-arg related typo
---
core.scm | 2 +-
1 f
Evan Hanson writes:
Thanks, pushed.
> 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").
Evan Hanson writes:
> 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?
Looks good, pushed!
>
> I fixed two places where the `resolve-variable` procedure didn't have the new
> `outer-ln`
Evan Hanson writes:
> Hi there,
>
> This small patch closes #1644.
>
> Thanks to Marco Maggi for suggesting this feature in a chicken-users
> thread from a while back.
Pushed. Thanks for you both.
There was a fix for apparent typo in argument handling for emit-impor-library
declaration. I
o.nz>
Evan Hanson writes:
> 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 "suggest
Hi,
the vertical spacing was a bit off in the previous patch, here's a fixed
one.
>From 97733d03230891d14facef5487b75d28ebac35ba 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
Peter Bex writes:
> Hi all,
>
> Here's a simple patch. Found while reviewing Megane's patch for
> improving line number reporting in [ei]r-macro-transformer; this
> recompiled expand.scm which rubbed those compiler warnings in my
> face.
>
Thanks, pushed.
is not pretty (I just use a editor macro to insert the form)
A nice addition would be if it told what is the expected type:
(+ )
would tell that number is expected.
>From 89e2a655d9ba53b64d3d5186c1a4902883feaca7 Mon Sep 17 00:00:00 2001
From: megane
Date: Mon, 2 Sep 2019 10:36:04 +0300
Subj
Hi,
a small patch to make the compiler maintain more fine grained line number
info.
>From 98f76b162d7c4984092f5db42cad2648d992ceea Mon Sep 17 00:00:00 2001
From: megane
Date: Sat, 10 Apr 2021 07:46:01 +0300
Subject: [PATCH] Make ir-macro-transformer retain more of line-number
informat
Hi,
here is some improvements for unknown identifier messages.
>From 235e7641362657711702f4905a9dc28aa740ff1e 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 m
felix.winkelm...@bevuta.com writes:
>> Am Wed, 24 Mar 2021 23:51:13 +
>> schrieb Diego :
>>
...
>>
>> Hm. Out of principle I tend to rather spam the user with warnings (at
>> least by default) and contemplate how to circumvent the issue in the
>> first place.
>
> True, but in some cases it
into fewer steps. :)
>From ebf61282318f92bbbae2e4180fcf0b7e3e5da422 Mon Sep 17 00:00:00 2001
From: megane
Date: Sun, 14 Mar 2021 08:08:21 +0200
Subject: [PATCH 1/4] * chicken.h: Add temporary C_main_entry_point2
---
c-backend.scm | 2 +-
chicken.h | 2 ++
2 files changed, 3 insertions(+)
Hi,
here's a small patch for #1733.
>From 37ec1f2776c9e4a5a760cabd18c339d3da3f622e Mon Sep 17 00:00:00 2001
From: megane
Date: Sat, 13 Mar 2021 12:25:55 +0200
Subject: [PATCH] * types.db: Fix set-parameterized-read-syntax! ,
set-sharp-read-syntax! types
Both take CHAR-OR-SYMBOL, not just c
Sven Hartrumpf writes:
> Hello.
>
[snip]
>> I need some -:hi option (only for the new GC!), otherwise it crashes as
>> follows:
>>
>> # nallch.x32 -:a0 -:o -:s4096k 0
>> [panic] out of memory - cannot allocate next heap segment - execution
>> terminated
>
> I have experimented some more
Sven Hartrumpf writes:
> Hi Mario.
>
[snip]
> Run options are:
>
> -:hi256m -:H -:hs0 -:o -:s4096k
Hi Sven,
The combination of -:hi256m and -:hs0 pretty much guarantees these
patches won't help you.
- The first patch would bump the heap size up if your program constantly
needed, say
Thanks, applied.
I added your example as a test.
Evan Hanson writes:
> 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
>
Evan Hanson writes:
> 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
(t "':")
(t "#")
(t ":,")
(t ":||,")
(t ",:||")
(t ",||:")
(t ",#:||")
)
(all #:suffix)
(all #:prefix)
(all #:none)
---
>From 28b4c691780896e2c840bfdcf137d35d170f2253 Mon Sep 17 00:00:00 200
ntal, but I'm not sure the reasoning.
Fixes #1715
Signed-off-by: megane
- I copied the rationale from the Trac issue page.
---
support.scm | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/support.scm b/support.scm
index 5eff6e23..f610349d 100644
--- a/supp
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 g
felix.winkelm...@bevuta.com writes:
> 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?
>
> felix
Mario Domenech Goulart writes:
> Hi,
>
> On Wed, 4 Mar 2020 16:15:20 +0100 Sebastien Marie wrote:
>
>> Attached a patch for fixing #1638.
>
> Thanks a lot, Sebastien. Attached is your patch, signed-off.
>
Pushed. Thank for the analysis and fix, Sebastien!
Peter Bex writes:
> On Wed, Feb 12, 2020 at 06:18:51PM +0200, megane wrote:
>> Is there any technical reason we couldn't call external functions
>> directly?
>
> In principle, this should be possible:
>
> 1) Just mark it "extern" in its own compilation un
Peter Bex writes:
> Hi all,
>
> Attached is a relatively straightforward patch for #1665. The unroll
> limit was causing the procedure calls to stay, and the compiler would
> replace those calls with a direct call, thinking the fid would be valid
> locally (but it isn't, because it was loaded
With -:hf4M
Total run time (CPU time): 4m57.95101s
Total time spent in major GCs: 15.862s
Total number of major GCs: 4766
>From d57b4cb1f8c849585ae049c85dbd225ce9804667 Mon Sep 17 00:00:00 2001
From: megane
Date: Sun, 5 Jan 2020 09:03:14 +0200
Subject: [PATCH 1/2] Prev
Evan Hanson writes:
> Hi megane, happy holidays!
Happy holidays, Evan and everyone!
>
> 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 enti
Hi,
Here's a small helper for newbies (and those who can't remember, like
me).
>From 69da758b16887f43583042c62e08bc3a905e046e Mon Sep 17 00:00:00 2001
From: megane
Date: Sun, 8 Dec 2019 08:13:25 +0200
Subject: [PATCH] Add help info to csi banner
---
csi.scm | 3 ++-
1 file changed
47f4d Mon Sep 17 00:00:00 2001
From: megane
Date: Sun, 1 Dec 2019 09:23:29 +0200
Subject: [PATCH 1/3] * chicken-ffi-syntax.scm: Add annotate-foreign-procedure
helper function
---
chicken-ffi-syntax.scm | 53 +-
1 file changed, 21 insertions(+), 32 de
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 +
Evan Hanson writes:
> 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
megane writes:
> Evan Hanson writes:
>
>> 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
Evan Hanson writes:
> 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
>
Pushed. Thanks!
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Hi,
Here's a small QOL improvement for the export checks.
>From fdd9d1af41ad8f08ce45849ec9704bc7e0b4328d Mon Sep 17 00:00:00 2001
From: megane
Date: Thu, 10 Oct 2019 12:11:07 +0300
Subject: [PATCH] Print more information about why an identifier cannot be
exported
After change:
Warn
Peter Bex writes:
> On Thu, Oct 03, 2019 at 01:11:31PM +0200, felix.winkelm...@bevuta.com wrote:
>> This patch extends 21ff0d6affb35f7184a5e78f9d4beccc869b47b2 to
>> type-names, inline procedures and constants, giving a warning when
>> an identifier naming such an entity is exported.
>
> Hi
Peter Bex writes:
> On Sat, Jul 20, 2019 at 11:51:28AM +0300, megane wrote:
>> Here's a new patch that drops the (not captured) check.
>
> Thanks for making that! Now that my original patch has been pushed,
> here's an incremental patch based on yours which only drops that
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
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
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
>>
>> ( ...
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
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
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
"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
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)
>>
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(+)
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)))
&
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
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
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
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,
>
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
>> @@
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.
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
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
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
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
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
>> ...
>&
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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.
>> >
>> >
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.
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
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
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
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
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
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 ++---
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
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
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
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
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
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
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,
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
'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
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
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.
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
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
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
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
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)
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
1 - 100 of 139 matches
Mail list logo
