Re: [Chicken-hackers] [PATCH] Fix for #989 and hopefully #877 too

Am 06.11.2013 20:33, schrieb Jörg F. Wittenberger: Am 06.11.2013 20:27, schrieb Peter Bex: On Wed, Nov 06, 2013 at 08:18:20PM +0100, Jörg F. Wittenberger wrote: NAH; I don't expect you to dig into it. Actually it looks as if my assessment was wrong anyway: in the meantime I traced the static

Re: [Chicken-hackers] [PATCH] Fix for #989 and hopefully #877 too

Am 06.11.2013 20:38, schrieb Peter Bex: On Wed, Nov 06, 2013 at 08:34:38PM +0100, Jörg F. Wittenberger wrote: At least we're now within the scope of a letrec ;-) I must say that's a huge relief :) I'm not that sure about the relief. For the fun of it (no more, except that somebody

Re: [Chicken-hackers] [PATCH] Fix for #989 and hopefully #877 too

Am 06.11.2013 21:21, schrieb Peter Bex: On Wed, Nov 06, 2013 at 08:50:05PM +0100, Jörg F. Wittenberger wrote: This second parameter is always vars, which in turn is the third parameter of make-mode-choice below. Are you sure it isn't already #unspecified where make-mode-choice is invoked

Re: [Chicken-hackers] [PATCH] Fix for #989 and hopefully #877 too

Thanks John, Am 07.11.2013 17:40, schrieb John Cowan: So for RScheme purposes, just write a trivial syntax-rules macro: (define-syntax letrec* (syntax-rules () ((letrec* . x) (letrec . x (This requires loading the RScheme syntax-rules support.) The main point for me is in your

[Chicken-hackers] patch: treat #t as alternative to else in cond

Hi all, attached a single statement patch. It makes cond expand clauses with #t as condition like else. That is (define (testcase x) (cond ((eq? x 'a) 1) (#t 2) ((eq? x 'b) 3))) will result in a warning: Warning: non-`else' clause following `else' clause in `cond': ((eq? x (quote

Re: [Chicken-hackers] pastiche db drop

As this thread is already a bit off-topic I feel compelled to add a me too story here as well. You know what: the whole Askemos/BALL thing we have been working on for the past decade is made that way (and I actually felt sorry when I read about the incident thinking could not have happened

Re: [Chicken-hackers] chicken-fuse

. At worst I'd recommend to simply remove the ability to use any Scheme object as file handle and simply require them to be integers. Then we could do away with the evict/unevict code. Any thought? Thanks /Jörg Am 10.03.2014 09:34, schrieb Jörg F. Wittenberger: Am 09.03.2014 21:01, schrieb Evan

Re: [Chicken-hackers] chicken-fuse

Turns out there's some other bug (though in fuse.scm) Am 17.03.2014 15:55, schrieb Jörg F. Wittenberger: Hi Evan, I'm running up against some crazy segfault. It happens under some locally reproducibly circumstances, though I do not yet understand it. Nevertheless, I'm concerned

Re: [Chicken-hackers] [PATCH] Improve performance by skipping mutations on non-stack pointers

Good catch! Though I don't understand what those counters are good for. /Jörg Am 05.04.2014 21:19, schrieb Peter Bex: Hi all, I happened to be working on some benchmarks for the Postgres egg and due to random reasons started digging into why (time) was showing mutations in the GC even if I

Re: [Chicken-hackers] [PATCH] Generalize deprecation type warnings

Am 12.05.2014 21:09, schrieb Evan Hanson: On 2014-05-12 20:54, Peter Bex wrote: On Mon, May 12, 2014 at 11:42:26AM -0700, Evan Hanson wrote: This is instead of library procedures, since deprecated identifiers need not be procedures. But I don't see syntax identifiers as having a value in the

Re: [Chicken-hackers] [PATCH] Generalize deprecation type warnings

: On 2014-05-13 9:22, John Cowan wrote: Jörg F. Wittenberger scripsit: use of deprecated `~a' - consider `~a' Reads fine to me. Same -- good idea, Jörg. Here's a patch for that. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https

Re: [Chicken-hackers] incorrect warning during compilation

This one I'd like. Currently using the scheme-pointer plus type cast in C approach. Quite often actually. Am 27.06.2014 17:13, schrieb Kristian Lein-Mathisen: Actually, that's really cool! A string-buffer type! I wouldn't mind seeing this in core. So how does this work, Felix, do we vote

Re: [Chicken-hackers] [PATCH] Fix #1133

OK, since Peter mentioned me… Am 28.06.2014 12:40, schrieb Peter Bex: On Sat, Jun 28, 2014 at 12:18:24AM +0400, Oleg Kolosov wrote: Looks like it is mostly setup api that pulls POSIX. Making it optional along with csc and friends will allow us to strip the core much more. And they are hard to

Re: [Chicken-hackers] [PATCH] Fix #1133

+1 … Am 03.07.2014 20:23, schrieb Aleksej Saushev: In general, CMake doesn't solve any real problem of Make. In some aspects it is a step back even. CMake is mostly equivalent to Make + some autotools. Plus: this mixing of make's job with the configuration management is what I perceive as

Re: [Chicken-hackers] [PATCH] Fix #1133

Am 05.07.2014 23:31, schrieb Felix Winkelmann: Finalizers have an impact on every GC, as every GC may free memory at any time. What may be possible is to register finalizers only when it is known that the associated data is not held in global variables. But I'm not sure if it isn't in the end

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

Am 29.08.2014 20:50, schrieb Oleg Kolosov: On 08/23/14 19:35, Peter Bex wrote: I've made a start on the wiki, at what we'd like CHICKEN 5 to be about. I've remembered one more thing: why not stick the terminating '\0' at the end of all strings in internal representation? This looks pretty

Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

Am 09.09.2014 um 17:39 schrieb Oleg Kolosov: On 09/04/14 13:30, Jörg F. Wittenberger wrote: Am 29.08.2014 20:50, schrieb Oleg Kolosov: On 08/23/14 19:35, Peter Bex wrote: I've made a start on the wiki, at what we'd like CHICKEN 5 to be about. I've remembered one more thing: why not stick

Re: [Chicken-hackers] [PATCH 0/5] List scrutiny special cases

Am 09.09.2014 um 15:34 schrieb Moritz Heidkamp: John Cowan co...@mercury.ccil.org writes: Thanks, that's helpful. The trouble is that such a file is an internal (not publicly documented, unstable) format. So if I want to ship portable code along with type information for Chicken, I have to:

Re: [Chicken-hackers] CHICKEN in production

Am 08.10.2014 um 19:46 schrieb Peter Bex: On Wed, Oct 08, 2014 at 11:54:06AM -0400, John Cowan wrote: Peter Bex scripsit: The danger could be avoided by a taint bit: if the string is known to not contain \0, it can be passed directly. Otherwise, it needs to be checked and marked if it's safe.

Re: [Chicken-hackers] CHICKEN in production

I don't think that I ever wrote that using memory debuggers like valgrind would work out of the box with chicken to any usable extend. To the contrary: when I did so, I posted fixes to runtime.c the mailing list to make this feasible. /Jerry Am 08.10.2014 um 23:17 schrieb Oleg Kolosov: We

Re: [Chicken-hackers] CHICKEN in production

Am 08.10.2014 um 21:27 schrieb John Cowan: Peter Bex scripsit: Thanks for speaking up, I hadn't considered how big of a problem this would be for large, existing projects. We could possibly make it a runtime option, so the checking (or just the enforcing) could be enabled or disabled at will.

Re: [Chicken-hackers] CHICKEN in production

Am 10.10.2014 um 11:52 schrieb Christian Kellermann: Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes: Since chicken 5 is already there (and I'm depending on the fixes to the current version to run our code at all, which forces more work to set up a compile your modified chicken

Re: [Chicken-hackers] CHICKEN in production

They are not *that* huge. Just the downside of what's usually a strength of chicken one C source file plays in badly. Let's take that to private mail for the time, not to spam the list. Am 10.10.2014 um 12:20 schrieb Christian Kellermann: Jörg F. Wittenberger joerg.wittenber...@softeyes.net

Re: [Chicken-hackers] CHICKEN in production

Am 14.10.2014 um 04:25 schrieb John Cowan: Florian Zumbiehl scripsit: String containing slash to filename? Exception! String containing colon to hostname? Exception! String containing NUL to C string? Exception! These aren't all the same. Filenames and hostnames are specific uses of strings,

Re: [Chicken-hackers] Merging of import, types and inline information

On Sat, Jan 17, 2015 at 02:28:27PM +0300, Oleg Kolosov wrote: Hello All! I’ve been thinking about an idea to merge module type and inline information into import libraries for a long time, and, before starting to hack, decided to ask for opinions in hope to produce useful discussion.

Re: [Chicken-hackers] extracting srfi-1 from chicken 5

Just a remark. If the mini-srfi-1 stuff is only (to be) required in operator position it could be given as syntax. Am 15.02.2015 um 23:44 schrieb Felix Winkelmann: - There is an include file (mini-srfi-1.scm) that holds the procedures that are currently needed. It is included by several

Re: [Chicken-hackers] [PATCH][5] numbers integration

Am 11.02.2015 um 13:09 schrieb Felix Winkelmann: Personally I'd be more than happy to take the performance hit on this so long as I can rely on fx operations and/or (declare fixnum-arithmetic) to recover the original performance. You can; I didn't change any of those. The fixnum mode

Re: [Chicken-hackers] regression - probably in let*

Am 19.06.2015 um 10:36 schrieb felix.winkelm...@bevuta.com: Am 18.06.2015 um 15:00 schrieb felix.winkelm...@bevuta.com: thanks for your confirmation. So it's -strict-types. Maybe the test should go into the test suite to prevent the issue sneaking into future releases. (As for -unsafe:

[Chicken-hackers] regression - probably in let*

The attached test case works in csi but fails in csc. Possibly related to optimization options. Compile as: csc -O3 -clustering -no-argc-checks -no-procedure-checks -no-bound-checks -no-trace -no-lambda-info -specialize -lfa2 -strict-types -disable-stack-overflow-checks -unsafe

Re: [Chicken-hackers] proposed change to identify.sh

No thoughts on this. You are right. I don't recall why it was written this way. Am 13.06.2015 um 14:53 schrieb Peter Bex: On Sat, Jun 13, 2015 at 02:19:10PM +0200, Jörg F. Wittenberger wrote: When building chicken without git I never really succeed. Hence I'm using a modified identity.sh

[Chicken-hackers] debian package build

Attached a debian package build. At least csi and csc do their job for me. Maybe some things are missing or at the wrong place? /Jörg From c46f71552758d5ac60f2dde34c50c4dab7bd661e Mon Sep 17 00:00:00 2001 From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net Date: Sat, 13 Jun 2015

[Chicken-hackers] [PATCH]: Handle missing error codes in `barf`

IMHO `barf` should never reach this line: default: panic(C_text(illegal internal error code)); From 30b197e7675946181c67f493eae88b0f455f111d Mon Sep 17 00:00:00 2001 From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net Date: Sat, 13 Jun 2015 10:38:28 +0200 Subject: [PATCH] Add cases for

Re: [Chicken-hackers] An alternative internal time type.

Sorry, the attached patch was rather non-sensical. Dunno how I managed to compile the wrong directory... :-/ Am 13.06.2015 um 08:54 schrieb Jörg F. Wittenberger: Hi, the attached patch adds initial support for an alternative internal time representation. (Keeps the default as double

Re: [Chicken-hackers] An alternative internal time type.

Am 13.06.2015 um 13:39 schrieb Peter Bex: On Sat, Jun 13, 2015 at 08:54:44AM +0200, Jörg F. Wittenberger wrote: Hi, the attached patch adds initial support for an alternative internal time representation. (Keeps the default as double.) The idea is to ease future porting and special use

Re: [Chicken-hackers] regression - probably in let*

Jörg, On Mon, 15 Jun 2015 17:35:07 +0200 Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: The attached test case works in csi but fails in csc. Possibly related to optimization options. Compile as: csc -O3 -clustering -no-argc-checks -no-procedure-checks -no-bound-checks

Re: [Chicken-hackers] regression - probably in let*

Am 04.07.2015 um 06:53 schrieb Evan Hanson: Hi Jörg, It's as the others say: the scrutinizer differentiates between true and false, so your assignment of one over the other breaks the assumptions that strict-types implies. I understood that already. Thanks for the explanation anyway.

Re: [Chicken-hackers] small patch

Am 23.05.2015 um 16:45 schrieb Peter Bex: On Fri, May 15, 2015 at 02:25:56PM +0200, Jörg F. Wittenberger wrote: Attached a small patch against origin/master. It's just to silence a valgrind warning. The patch looks good to me, except for the headers. See below. I agree with you that git

[Chicken-hackers] [PATCH] mutex-lock! sometimes not srfi-18 compliant

Hi, try the test case: (use srfi-18) ;; Make a locked mutex (define mux (make-mutex 'foo)) (mutex-lock! mux #f #f) ;; Have a thread waiting for it. (define t1 (thread-start! (lambda () (mutex-lock! mux #f #f) (print "Got " mux " state " (mutex-state mux) "\n" ;; Give it time

[Chicken-hackers] [PATCH] thread-join! does not like sleeping threads

I ran into this one: "Internal scheduler error: unknown thread state: " sleeping the attached patch seems to fix this. /Jörg >From 7f7390aaa7aef12f60a8f76c3e06fcdaa146753b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20F=2E=20Wittenberger?= Date: Sat, 7

[Chicken-hackers] [PATCH] remove unused code (##sys#hash-table-location)

Hi, ##sys#hash-table-location is not used anywhere in chicken-core. Attached patch removes it from branch compiler-modules. Best /Jörg >From ab8c4d8d9beeba48ef75f1c786a3ce6a077b2bcd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20F=2E=20Wittenberger?=

Re: [Chicken-hackers] Heap size calculation in rereclaim2

Am 14.10.2015 um 09:43 schrieb Peter Bex: > (looks like you accidentally hit reply instead of reply all/reply to list) > > On Tue, Oct 13, 2015 at 11:06:58PM +0200, felix.winkelm...@bevuta.com wrote: >>> Am I correct in thinking that double_plus is misnamed and should really >>> be called

[Chicken-hackers] Diagnosis for; How to interpret chicken post mortem?

Am 26.11.2015 um 11:29 schrieb Jörg F. Wittenberger: > Something is definitely wrong at master and it is non-deterministic. I found the cause. The issue pertains to all recent versions of CHICKEN. To trigger the bug you need to do the following in order: 1. Use set-signal-hand

Re: [Chicken-hackers] Diagnosis for; How to interpret chicken post mortem?

Am 29.11.2015 um 17:55 schrieb Jörg F. Wittenberger: > I'd suggest to simply register the interrupt in the C handler and handle > *all* interrupts within ##sys#thread-yield!. Actually I'd even block all signals and use sigwaitinfo (if that's available on Windows too?) for signals. I'd

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

;-) as promised: Am 02.12.2015 um 14:57 schrieb Jörg F. Wittenberger: > No more patches today. This again is no good > because it allocates a slot in pending_interrupts, but doesn't - and > can't deallocate it. No more patches yesterday. This one sustained the test to sleep one n

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Am 03.12.2015 um 14:01 schrieb John Cowan: > Jörg F. Wittenberger scripsit: > >> One more question. I would have expected chicken to store signals >> received while C_interrupts_enabled==0 and deliver them at some point >> after C_interrupts_enabled becomes true. Why a

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Hi all, I guess I must apologize for first posting an almost good patch and then once I found this cut error, I became confused and made a mess out of it. Am 30.11.2015 um 12:44 schrieb Jörg F. Wittenberger: > Am 29.11.2015 um 17:55 schrieb Jörg F. Wittenberger: >> Am 26.11.2015 um 11:2

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Jörg F. Wittenberger: > Argh, this is still no good. > > Now the pending_interrupts_count will grow beyond bounds. > > Use the attached version instead. > > Sorry. > > /Jörg > > > > Am 02.12.2015 um 13:28 schrieb Jörg F. Wittenberger: >> Hi all, >

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Argh, this is still no good. Now the pending_interrupts_count will grow beyond bounds. Use the attached version instead. Sorry. /Jörg Am 02.12.2015 um 13:28 schrieb Jörg F. Wittenberger: > Hi all, > > I guess I must apologize for first posting an almost good patch and then >

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

I don't believe it. No more patches today. This again is no good because it allocates a slot in pending_interrupts, but doesn't - and can't deallocate it. Maybe tracking saved_stack_limit as in my second patch is actually the simpler change. Am 02.12.2015 um 14:05 schrieb Jörg F. Wittenberger

Re: [Chicken-hackers] [PATCH] Improve irregex matching performance a lot by adding two type declarations

Am 12.12.2015 um 16:13 schrieb John Cowan: > Peter Bex scripsit: > >> Maybe this is a good feature to add: a way to indicate that a type >> declaration for the argument types to a procedure declared elsewhere >> should be considered an assumption in the procedure body. This way >> it would not

Re: [Chicken-hackers] [PATCH] Improve irregex matching performance a lot by adding two type declarations

Am 12.12.2015 um 20:28 schrieb Peter Bex: >>> Maybe this is a good feature to add: a way to indicate that a type >>> > > declaration for the argument types to a procedure declared elsewhere >>> > > should be considered an assumption in the procedure body. >> > >> > I'm afraid that I don't quite

[Chicken-hackers] Ticket 1231

Hi all, Wishing you a a pleasant 2016! May I ask you a favor: could someone please look into applying the patch attached to ticket 1231. For this bug is bothering me much. Not so much for the negligible memory leak of one cons cell per mutex-lock!, but because: a) Code using the pattern given

[Chicken-hackers] PS: Ticket 1231

Am 31.12.2015 um 12:32 schrieb Jörg F. Wittenberger: > I do understand that there may be some fear that fixing the bug could > cause some existing (though buggy) chicken code to break, just because > this hypothetical code would rely on the bug canceling out the bug in > the other code

Re: [Chicken-hackers] [PATCH] Use pair as loop result handle in compiler-syntax for `map`

Am 21.12.2015 um 04:25 schrieb Evan Hanson: > Hi hackers, > > Here's a patch for an issue Felix pointed out way back in April, in >. .. > However, that conditional is really only needed the first time through > the loop, in order to update a `##core#box` to refer to the head of the > ... > Let me

[Chicken-hackers] How to interpret chicken post mortem?

Hi all, just managed to switch to the master branch, eventually. (Congrats to myself, sight ;-) Now there is a segfault. Looks almost random. The program runs for a fairly long time until crash. (Megabytes of chicken -:r backtrace and no hint either). Some gdb backtraces from a debug build

Re: [Chicken-hackers] How to interpret chicken post mortem?

Am 26.11.2015 um 20:08 schrieb Peter Bex: > On Thu, Nov 26, 2015 at 06:01:13PM +0100, Jörg F. Wittenberger wrote: >> Am 26.11.2015 um 11:34 schrieb Peter Bex: >>>> Error: (assq) bad argument type: # >>> Do you also get this when compiling said code with the 4.10.1

Re: [Chicken-hackers] [PATCH] mutex-lock! sometimes not srfi-18 compliant

ch for git with both these changes rolled into one? Anyway, attached "part two" of the change. This adds more tests and fixed mutex-unlock! the way it should have been done before. Best /Jörg Am 23.11.2015 um 17:29 schrieb Jörg F. Wittenberger: > Hi all, > > Am 07.11.2015 um 21:55

Re: [Chicken-hackers] [PATCH] mutex-lock! sometimes not srfi-18 compliant

Am 25.11.2015 um 00:23 schrieb Jim Ursetto: > Use git commit --amend to fix if you haven't committed the second one yet. > > Use git rebase -i to squash existing commits together. Thanks Jim, that's what I've been looking for. Attached a merged version with a better commit message. This one

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Attached a better version. Am 30.11.2015 um 12:44 schrieb Jörg F. Wittenberger: > Am 29.11.2015 um 17:55 schrieb Jörg F. Wittenberger: >> Am 26.11.2015 um 11:29 schrieb Jörg F. Wittenberger: >> The signal handler in the other thread will happily set the global >> variable C

[Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Am 29.11.2015 um 17:55 schrieb Jörg F. Wittenberger: > Am 26.11.2015 um 11:29 schrieb Jörg F. Wittenberger: > The signal handler in the other thread will happily set the global > variable C_stack_limit to point 1000 word off the stack pointer at the > other thread. Perhaps the at

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Wait, this patch has a bug. Sorry. Am 30.11.2015 um 12:44 schrieb Jörg F. Wittenberger: > Am 29.11.2015 um 17:55 schrieb Jörg F. Wittenberger: >> Am 26.11.2015 um 11:29 schrieb Jörg F. Wittenberger: >> The signal handler in the other thread will happily set the global >> v

Re: [Chicken-hackers] How to interpret chicken post mortem?

not switch to master now. :-/ (I'm running this from master with debugbuild; no optimizations.) Any suggestions? Thanks /Jörg Am 24.11.2015 um 21:48 schrieb Jörg F. Wittenberger: > Hi all, > > just managed to switch to the master branch, eventually. (Congrats to > myself, sight ;-)

Re: [Chicken-hackers] How to interpret chicken post mortem?

Am 26.11.2015 um 11:34 schrieb Peter Bex: > On Thu, Nov 26, 2015 at 11:29:20AM +0100, Jörg F. Wittenberger wrote: >> Something is definitely wrong at master and it is non-deterministic. >> >> I may be able to help narrowing this down, since I get these segfaults >> with

Re: [Chicken-hackers] How to interpret chicken post mortem?

Am 26.11.2015 um 13:56 schrieb Jörg F. Wittenberger: > Am 26.11.2015 um 11:34 schrieb Peter Bex: >> On Thu, Nov 26, 2015 at 11:29:20AM +0100, Jörg F. Wittenberger wrote: >>> Something is definitely wrong at master and it is non-deterministic. ... >>> (if (let ((g10816 k

Re: [Chicken-hackers] How to interpret chicken post mortem?

Am 26.11.2015 um 11:34 schrieb Peter Bex: >> Error: (assq) bad argument type: # > Do you also get this when compiling said code with the 4.10.1 snapshot? I get the same strange segfaults from 4.10.1 snapshot (plus both the mutex-related fixes I posted these days as they are essential to work long

[Chicken-hackers] [PATCH] mutex-lock! sometimes not srfi-18 compliant

Hi all, Am 07.11.2015 um 21:55 schrieb "Jörg F. Wittenberger": > Hi, > > try the test case: looks like I messed up with this one. (I sent out half the patch.) Attached a better version. This one adds a test case which actually fails until chicken is recompiled.

Re: [Chicken-hackers] [PATCH] Reschedule when a thread blocked on thread-join! is forcibly resumed

Am 02.06.2016 um 13:28 schrieb Evan Hanson: > On 2016-06-02 11:32, Jörg F. Wittenberger wrote: >> No need to actually try. You patch does exactly what my first >> workaround was when I discovered the issue. > > Excellent, in that case we can re-hide `##sys#force-primordial`

Re: [Chicken-hackers] [PATCH] Reschedule when a thread blocked on thread-join! is forcibly resumed

Am 02.06.2016 um 14:18 schrieb felix.winkelm...@bevuta.com: >> AFAICT from past discussions, whether forcing is good, bad, or just a >> necessary evil is still unclear, and this needs some agreement before we >> can simply rip out that code. I'm open to removing it in chicken-5, at >> least, which

Re: [Chicken-hackers] [PATCH] Reschedule when a thread blocked on thread-join! is forcibly resumed

On Jun 2 2016, felix.winkelm...@bevuta.com wrote: Am 02.06.2016 um 14:18 schrieb felix.winkelm...@bevuta.com: >> AFAICT from past discussions, whether forcing is good, bad, or just >> a necessary evil is still unclear, and this needs some agreement >> before we can simply rip out that code.

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Sorry for replying to my own message. Am 14.01.2016 um 22:18 schrieb Jörg F. Wittenberger: > Great that this made it so far. > > Am 14.01.2016 um 20:20 schrieb Peter Bex: >> On Fri, Jan 15, 2016 at 12:59:28AM +1300, Evan Hanson wrote: >>> Hi all, >>>

[Chicken-hackers] Fwd: SRFI-1 egg

sure: forgot the mentioned cross-posting. Weitergeleitete Nachricht Betreff: SRFI-1 egg Datum: Thu, 14 Jan 2016 19:01:33 +0100 Von: Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> An: chicken-users <chicken-us...@nongnu.org> I always was sooo keen to wri

Re: [Chicken-hackers] [Chicken-users] Need help to figure out where this strange performance impact is coming from

which 17 bindings. Rewrote the test to not import "extras" -> still fast. Removed the "(use extras)" -> slow down. Use random egg exporting many bindings instead -> fast again. Weird. Am 14.01.2016 um 12:12 schrieb Christian Kellermann: > * Jörg F. Wittenberger

[Chicken-hackers] PATCH: wrong type for alist-delete!

Hi all, the srfi document wants a different type for alist-delete! than types.db declares. Patch attached. >From 5834292305ac4882484169104535c72981e0167b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20F=2E=20Wittenberger?= Date: Thu, 14 Jan 2016 15:12:26

Re: [Chicken-hackers] [Chicken-users] Need help to figure out where this strange performance impact is coming from

use srfi-1) is close to the end of the file. (Even though I'm not completely sure that's enough.) > Perhaps you should consider asking Chicken Hackers? > > -Dan > > Original Message > From: Jörg F. Wittenberger > Sent: Wednesday, January 13, 2016 3:38 AM > To: chicken-users &g

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Thanks Evan. Am 18.01.2016 um 03:59 schrieb Evan Hanson: > On 2016-01-15 11:31, Jörg F. Wittenberger wrote: >> I would not be surprised if an innocent reader would read the code >> with the comment missing and conclude that we save the local variable >> `stack_lim

Re: [Chicken-hackers] PATCH: allow signal handlers to be called from any thread.

Great that this made it so far. Am 14.01.2016 um 20:20 schrieb Peter Bex: > On Fri, Jan 15, 2016 at 12:59:28AM +1300, Evan Hanson wrote: >> Hi all, >> >> Attached is a signed-off copy of this patch, with some of the info in >> the comments moved into the commit message. Actually I'm slightly

Re: [Chicken-hackers] on ticket 1231

for the reviewers to grok the code, I'll put more comments into the test case. For the curious attached my current version of the test. Best /Jörg Am 23.01.2016 um 13:19 schrieb Peter Bex: > On Fri, Jan 22, 2016 at 07:42:09PM +0100, Jörg F. Wittenberger wrote: >> Hi all, >> >> ther

[Chicken-hackers] PATCH ticket 1231

07:42:09PM +0100, Jörg F. Wittenberger wrote: >> Hi all, >> >> there is a problem I have with ticket 1231. >> http://bugs.call-cc.org/ticket/1231 >> >> In short: I'd love to see the patch applied. (Or learn about issues it >> causes.) > > I hadn't

Re: [Chicken-hackers] PATCH ticket 1231 -- some explanations

Hi all, attached a plain text file to be viewed with a rather wide screen containing some explanations wrt. the old and the new code. Best /Jörg Am 26.01.2016 um 13:32 schrieb Jörg F. Wittenberger: > Hi all, > > attached a fresh patch. Fixes actually three bugs, adds tests for all

Re: [Chicken-hackers] code suggestion

vector (##core#primitive "C_make_vector")) This time with test attached. Cheers /Jörg Am 01.02.2016 um 19:27 schrieb Jörg F. Wittenberger: > Hi all, > > given argvector's in place I wonder if we should change some things. > > If this code would be correct. If so, it c

Re: [Chicken-hackers] Argvector handling - maybe we could do better at that

Am 19.02.2016 um 13:59 schrieb Peter Bex: > I'd be happy to hear if it gives good results, of course. You did not expect earth shattering results, did you? Here some numbers. At this time only unit-benchmarks using the tests from llrb-tree egg. Numbers are execution time of (master / modified

Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

Am 27.02.2016 um 14:46 schrieb Jörg F. Wittenberger: > Am 27.02.2016 um 13:09 schrieb Jörg F. Wittenberger: >> Am 27.02.2016 um 12:25 schrieb Jörg F. Wittenberger: >>> Hi folks, >>> >>> if you really consider anything to be done to the argvector

Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

Am 28.02.2016 um 15:19 schrieb Jörg F. Wittenberger: > BTW: currently a make check completed here. This one re-uses a single, > stack allocated argvector of TEMPORARY_STACK_SIZE whenever the current > code would do C_alloc or av2[N]. Notable exception C_context_switch. > Interest

Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

argvector is consistently about 2% faster here on all tests so far. Cheers /Jörg Am 27.02.2016 um 20:58 schrieb Jörg F. Wittenberger: > Am 27.02.2016 um 14:46 schrieb Jörg F. Wittenberger: >> Am 27.02.2016 um 13:09 schrieb Jörg F. Wittenberger: >>> Am 27.02.2016 um 12:25 schrieb Jörg F.

[Chicken-hackers] Saver a patch: Re: Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

to #define USE_FIXED_DFLT ( !USE_OLD_AV && 0) that is - change to 1 to 0 - if you want to try length-prefixed argvector (I hope this still works). Cheers /Jörg Am 28.02.2016 um 15:39 schrieb Jörg F. Wittenberger: > Am 28.02.2016 um 15:19 schrieb Jörg F. Wittenberger: >> BTW: curre

Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

28.02.2016 um 15:19 schrieb Jörg F. Wittenberger: > There is an number of arguments limit documented in "Deviations from the > standard". (BTW: I guess the 1000 claimed there is outdated.) > > But is this limit checked anywhere? My reading of C_apply makes be > wonder. Am I

Re: [Chicken-hackers] Saver a patch: Re: Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

Hi, sorry for the disturbance. I did not expect those to be unwelcome. I assumed that there was a problem and a fix too, it might be a good thing. Am 28.02.2016 um 17:49 schrieb Peter Bex: > On Sun, Feb 28, 2016 at 03:58:11PM +0100, Jörg F. Wittenberger wrote: >> Hi, >> >

Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

Hi folks, if you really consider anything to be done to the argvector handling before the next release, please have a look at the patch I posted recently here http://lists.nongnu.org/archive/html/chicken-hackers/2016-02/msg00082.html not for the minor performance gain, read it for the

Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

Am 27.02.2016 um 12:25 schrieb Jörg F. Wittenberger: > Hi folks, > > if you really consider anything to be done to the argvector handling > before the next release ... I wonder: why not malloc exactly one argvector of TEMPORARY_STACK_SIZE word and drop all the checking? Then either

Re: [Chicken-hackers] Release blocker? Stack checks completely FUBAR? Or am I just paranoid?

Am 27.02.2016 um 13:09 schrieb Jörg F. Wittenberger: > Am 27.02.2016 um 12:25 schrieb Jörg F. Wittenberger: >> Hi folks, >> >> if you really consider anything to be done to the argvector handling >> before the next release > > ... > > I wonde

Re: [Chicken-hackers] slow polling

Am 24.02.2016 um 09:29 schrieb felix.winkelm...@bevuta.com: >> I've done some tests and I was able to get strange behaviour from the >> scheduler, see >> http://paste.call-cc.org/paste?id=d9e4c5b8f8473fd1114dcec56c9c8a079b252362 >> However, none of these behaved any different under CHICKEN

[Chicken-hackers] force-primordial: proposal of a compromise solution - was Re: slow polling

Am 24.02.2016 um 10:21 schrieb Jörg F. Wittenberger: > Am 24.02.2016 um 10:15 schrieb Jörg F. Wittenberger: >> Am 24.02.2016 um 09:29 schrieb felix.winkelm...@bevuta.com: >>>> I've done some tests and I was able to get strange behaviour from the >>>> scheduler, s

Re: [Chicken-hackers] slow polling

Am 24.02.2016 um 10:29 schrieb Peter Bex: > I really hope you understand this and can agree with it. As I wrote in this other mail before I received this one: how about removing the identifier from the hide list. This should not be able to break anything and allow me to get rid of the overhead.

[Chicken-hackers] on ticket 1231

Hi all, there is a problem I have with ticket 1231. http://bugs.call-cc.org/ticket/1231 In short: I'd love to see the patch applied. (Or learn about issues it causes.) Long story: The pigeon-hole egg I recently published looks internally somewhat like the "rewrite it using condition-variables"

Re: [Chicken-hackers] [Chicken-users] PS: problem compiling master

26, 2016 at 06:10:18PM +0100, Jörg F. Wittenberger wrote: >> Maybe I should add that the installation updated >> setup-download.{import.so, so} >> in /usr/local/lib/chcken/8 as expected. > > Did you fetch master which includes ad5f74dce9e9b5? > > This fixed a b

[Chicken-hackers] force-primordial - dunno what to do

Hi, chickens leaves me with a segfault every now and then. Turned out this is dues to: (dbg "select(2)/poll(2) returned with result -1" ) (##sys#force-primordial) in ##sys#unblock-threads-for-i/o I did not yet understand how this comes to produce a segfault. Less I understand why the

Re: [Chicken-hackers] force-primordial - dunno what to do

in case nobody finds why we ##sys#force-primordial find a patch attached which simply removes it. /Jörg Am 14.02.2016 um 19:35 schrieb Jörg F. Wittenberger: > Hi, > > chickens leaves me with a segfault every now and then. Turned out this > is dues to: > > (dbg "sel

Re: [Chicken-hackers] PATCH: more efficient scheduler

moving everything now to chicken 5 while I have not completed to move to master looks like too much a change at once for me to handle. Best /Jörg Am 15.02.2016 um 14:10 schrieb Peter Bex: > On Mon, Feb 15, 2016 at 01:57:52PM +0100, Jörg F. Wittenberger wrote: >> Hi, >> >> th

[Chicken-hackers] PATCH fixing to recent changes to parameterize

Hi, the attached patch is not yet tested. I'm waiting for re-compilation, which will take hours to really test. However "it looks to me"(TM) as if should fix the problem: when compiled with -strict-types the compiler will substitute code calling the parameter's convert procedure as before. I

Re: [Chicken-hackers] PATCH fixing to recent changes to parameterize

Am 15.02.2016 um 21:18 schrieb Evan Hanson: > Hi Jörg, > > On 2016-02-15 21:03, Jörg F. Wittenberger wrote: >> + ((,convert? (,the ,boolean ((lambda (x) x) #t ; Convert only >> first time extent is entered! > > Can you explain the lambda? If it's just to

<    1   2   3   >