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

anyway. The latter is just to hard to spot. Am 15.02.2016 um 21:22 schrieb Jörg F. Wittenberger: > 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

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

Am 15.02.2016 um 21:55 schrieb Evan Hanson: > Hi folks, > > On 2016-02-15 21:22, Jörg F. Wittenberger wrote: >> Yes: it is just to avoid the scrunity message. >> >> However: it is not only a message. It results in "some types not >> satisfying typ

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

Hi Folks, I see a certain call pattern which I believe (as in "wild guess") could be the cause of the strange 30% performance loss I observer for some kind of load while I see an almost 50% performance gain for other jobs. Looks like alternating calls procedures with many arguments (9 and 11 in

[Chicken-hackers] this code looks wrong to me

Hi, I'm browsing runtime.c to assess how big a change modifications to the argvector would be. My concept BTW: I'd first introduce a new macro like C_allocate_argvector, which would expand in just to the C_alloc, then change to compiler to use it. From this point we could play with the macros

Re: [Chicken-hackers] this code looks wrong to me

The attached patch does what I think it's the right thing to do. If it's not obvious than beware: I did not yet test it. Am 17.02.2016 um 11:43 schrieb Jörg F. Wittenberger: > Brought me to read C_location_ref and that looks wrong: > > case C_U32_LOCATIVE: > av2 = C_alloc(4);

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

Am 16.02.2016 um 22:54 schrieb Peter Bex: > On Tue, Feb 16, 2016 at 10:43:08PM +0100, felix.winkelm...@bevuta.com wrote: So if we could convince the C compiler to pass the argvector - and as we where about changing things the argument count too - in a global *register* variable,

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

Am 17.02.2016 um 15:37 schrieb Andy Bennett: > Hi Jörg, > > Do you think this patch would affect the issue I was seeing in my 2015 > mail to chicken-users "http-client gets stuck in scheduler when reusing > connect"? > (https://lists.gnu.org/archive/html/chicken-users/2015-06/msg00056.html )

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

Am 17.02.2016 um 13:22 schrieb Jörg F. Wittenberger: > Am 16.02.2016 um 22:54 schrieb Peter Bex: >> How about the stack-allocated vector I proposed? It'd also be the >> smallest change from what we currently have, I think. > > How about trying the following. Thi

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

Am 17.02.2016 um 17:36 schrieb Jörg F. Wittenberger: > Am 17.02.2016 um 13:22 schrieb Jörg F. Wittenberger: >> Am 16.02.2016 um 22:54 schrieb Peter Bex: >>> How about the stack-allocated vector I proposed? It'd also be the >>> smallest change from what we currently ha

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

Am 19.02.2016 um 13:43 schrieb Peter Bex: > On Fri, Feb 19, 2016 at 11:35:01AM +0100, Jörg F. Wittenberger wrote: >> So better the other way around: get rid of the globals. >> >> One thing I did not yet try: maybe it's beneficial to have a version of >> C_kontinue wh

[Chicken-hackers] slow polling

Hi folks, I guess I found the reason, why my 4.9.1 based chicken is about 30% faster in practice while master performs better on all little load and unit benchmarking. Observing that my version has a rather small deviation from the median, while master has extremely fast and extremely low

Re: [Chicken-hackers] slow polling

Am 19.02.2016 um 14:02 schrieb Jörg F. Wittenberger: > Now I see the low load case to be almost 50% faster and the old code to > be 30% faster and more stable on delivering responses. I have no idea > what the combined effect would be. > > How do we deal with this? I ope

[Chicken-hackers] PATCH Re: slow polling

The "Betthupferl" Am 19.02.2016 um 18:46 schrieb Jörg F. Wittenberger: > Am 19.02.2016 um 14:02 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. A "Betthupferl" is B

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

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 scheduler.scm: ;; T

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

compatibility). Am 20.02.2016 um 18:54 schrieb Jörg F. Wittenberger: > 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. > &

Re: [Chicken-hackers] slow polling

. Alternatively (as I submitted the code) we need to conditionally compile scheme code on NO_POSIX_POLL - apparently I'm not the only one who does not know how to do that. Am 19.02.2016 um 18:46 schrieb Jörg F. Wittenberger: > Am 19.02.2016 um 14:02 schrieb Jörg F. Wittenberger: >> Now I see the

[Chicken-hackers] code suggestion

Hi all, given argvector's in place I wonder if we should change some things. If this code would be correct. If so, it could simplify library.scm (list->vector and vector->list would become one-liners, vector a ##core#primitive) and save runtime. --- runtime.c --- void C_ccall

[Chicken-hackers] shouldn't file-close dispatch an interrupt on EINTR?

Hi all, after literally years of wondering why I'm seeing lost file descriptors I _guess_ I spotted the reason. file-close raises an error when close(2) returns a negative value. IMHO it should look like this (not yet tested): (define file-close (lambda (fd) (##sys#check-exact fd

[Chicken-hackers] csc -profile has problems

Hi, csc -profile bails out on some code it otherwise compiles. So far the smallest example I have is the reference implementation of srfi-35. It complains that really-make-condition-type is called with the wrong number of arguments right here: (define-condition-type message-condition?

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

I can only repeat: the all-in-one change did not fly neither will the piecemeal approach. We need to come up with a small API atop of which users can switch scheduler implementations. Am 20.05.2016 um 21:26 schrieb Peter Bex: > On Fri, Feb 19, 2016 at 10:39:23PM +0100, Jörg F. Wittenberger wr

Re: [Chicken-hackers] [PATCH] Handle possible EINTR in file-lock, file-lock/blocking and, file-unlock.

Am 05.02.2017 um 21:07 schrieb Peter Bex: > On Wed, Feb 01, 2017 at 07:50:30PM +0100, Jörg F. Wittenberger wrote: >> Hi all, >> >> I just found a couple of procedures in the posix unit, which did not >> handle EINTR well. > > The patch looks good to me. I must s

[Chicken-hackers] [PATCH] Handle possible EINTR in file-lock, file-lock/blocking and, file-unlock.

Hi all, I just found a couple of procedures in the posix unit, which did not handle EINTR well. Best /Jörg >From 1d325e122f6adc2d02f170639ada657950c6038c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20F=2E=20Wittenberger?= Date: Wed, 1 Feb 2017 19:46:38

Re: [Chicken-hackers] [PATCH] [CHICKEN 5] Change numerics representations

Am 04.10.2016 um 16:19 schrieb felix.winkelm...@bevuta.com: >> On Tue, Oct 4, 2016 at 4:00 AM, wrote: >> We could still get rid of the tagged pointer type. After some more >>> >> >> thought on the matter, I believe they're mostly worthless. >>> >>> "They"

Re: [Chicken-hackers] Howto -extend chicken-5?

Almost! Am Sun, 26 Mar 2017 21:04:25 +0200 schrieb Peter Bex <pe...@more-magic.net>: > On Sun, Mar 26, 2017 at 03:03:02PM +0200, Jörg F. Wittenberger wrote: > > (include "../mechanism/notation/Lalr/lalr-gen.scm");;[1] > > > > (define-syntax lal

Re: [Chicken-hackers] Howto -extend chicken-5?

Am Sat, 25 Mar 2017 21:13:10 +0100 schrieb Peter Bex <pe...@more-magic.net>: > On Sat, Mar 25, 2017 at 09:07:21PM +0100, Jörg F. Wittenberger wrote: > > Am I doing something wrong, which should not have been working in > > chicken4 either? How should I fix this? > &g

[Chicken-hackers] [PATCH] export "sort!" from data-strucutures

Hi all, just missed it. Applicable only to chicken-5. /Jörg >From ae9eec65f4ccc5d7161503405cb1c865da759452 Mon Sep 17 00:00:00 2001 From: jfw Date: Sat, 25 Mar 2017 14:26:04 +0100 Subject: [PATCH] export "sort!" from data-structures --- data-structures.scm |

[Chicken-hackers] [PATCH] chicken-5-eggs: srfi-69 shoulld export hash-table-walk

attached a diff adding the missing export --- srfi-69.scm~ 2017-03-11 06:49:03.0 +0100 +++ srfi-69.scm 2017-03-25 18:48:02.038211597 +0100 @@ -84,6 +84,7 @@ hash-table-fold hash-table-for-each hash-table-map + hash-table-walk hash-by-identity) (import (scheme)

[Chicken-hackers] strange warning

Hi, I noticed a warning confusing me: "Warning: the following extensions are not currently installed:" ... Actually I'm not installing any extensions. I compile and link them into a library of it's own. Currently 108 of them. Will I and up with a list of all 108 components when compiling the

[Chicken-hackers] Howto -extend chicken-5?

Hi, I'm trying to compile code which uses Dominique Boucher's lalr parser generator in chicken-5. This does not work the way it did in chicken-4. I compile like this $ chicken place-common.scm -output-file place-common.c -setup-mode -include-path . -verbose -extend

Re: [Chicken-hackers] strange warning

The latter; experimenting with chicken 5. Using import as in chicken 4. Am Sat, 25 Mar 2017 20:22:41 +0100 schrieb felix.winkelm...@bevuta.com: > > Hi, > > > > I noticed a warning confusing me: > > > > "Warning: the following extensions are not currently installed:" ... > > > > Actually I'm

[Chicken-hackers] Issue in -compile-syntax Was: Howto -extend chicken-5?

until I will see how much harm removing the -compile-syntax did. Test attached. /Jörg Am Sun, 26 Mar 2017 21:04:25 +0200 schrieb Peter Bex <pe...@more-magic.net>: > On Sun, Mar 26, 2017 at 03:03:02PM +0200, Jörg F. Wittenberger wrote: > > (include "../mechanism/notation/Lal

[Chicken-hackers] chicken 5 static linking issue

Hi all, another half baked issue I encountered when giving chicken5 a try. My supposed to be statically linked executable does not work as expected. After ~40 counts of "[debug] entering X..." I get: [debug] entering v-clformat... ; loading /home/u/test-5/lib/chicken/8/chicken.import.so ...

[Chicken-hackers] arm64 problem?

Hi, compling on a fresh rpi3 devuan I ran into a message which may or may not explain why I'm seeing issues. /Jörg clang -Wall -Wno-unused -Wno-invalid-noreturn -fwrapv -fomit-frame-pointer -fno-strict-aliasing -Os -O3 -g -c comparators.c comparators.c:6504:4: warning: absolute value function

[Chicken-hackers] PS: chicken 5 static linking issue

add1 sub1 with-exception-handler) (only srfi-34 raise)) Am Sat, 1 Apr 2017 21:38:13 +0200 schrieb "Jörg F. Wittenberger" <joerg.wittenber...@softeyes.net>: > Hi all, > > another half baked issue I encountered when giving chicken5 a try. > > My supposed

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

I agree that an explicit export list is beneficial for polished code. However I do often use modules for *import* control, a.k.a. catching my typos, rather than export control. That's when the *-export is very useful. /Jörg On Jul 4 2017, megane wrote: John Cowan writes:

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

Am Thu, 8 Jun 2017 13:29:48 -0400 schrieb John Cowan : > As we discussed on IRC, I see unexport as mitigating the problems with > (export *), and it's better to drop exporting * instead. > "Whitelisting is better > than blacklisting." Sure whitelisting better. But rather tedious

[Chicken-hackers] Bugs in C5 eggs with C5 pre4

Just tried. SRFI-13 chicken-install srfi-13 (after installing development snapshot c5 pre4) fails with Warning: reference to possibly unbound identifier `use' Fix was easy: find ~/.chicken-install.cache/srfi-13/srfi-13.scm and change the "(use srfi-14)" into "(import srfi-14)". SRFI-69

[Chicken-hackers] c5 install-cache

Hi all, my gut feeling tell me that the path beeing used in ~/.chicken-install.cache ought to have at least a binary compatibility segment. Otherwise I'd forcast dragons ahead the road. Best /Jörg ___ Chicken-hackers mailing list

[Chicken-hackers] C5 usage problem: chanr-name is gone

last time I tried C5 it ate this: I'm using -extend to feed these lines globaly into my build: (char-name 'NUL (integer->char 0)) (char-name 'nul (integer->char 0)) (char-name 'cr (integer->char 13)) Now it complains: Error: unbound variable: char-name How should I best fix this?

Re: [Chicken-hackers] [PATCH] [5] Avoid storing threads in trace-buffer

Just wondering. If memory usage was the concern, why not simple compile without tracing? This way we pay one more slot per thread. Plus some lookup. What do we earn? Maybe I'm missing something? Joerg On Sat, Oct 28, 2017 at 09:01:15PM +0200, felix.winkelm...@bevuta.com wrote: This is

Re: [Chicken-hackers] [PATCH] [5] Avoid storing threads in trace-buffer

On Nov 4 2017, Christian Kellermann wrote: Given that I presumed to compile with -no-trace and focus on ressource conservation: No. I feel, I have been warned. No, I do not see a point in runtime cost for debug features I could previously disable completely. * J?rg F. Wittenberger

Re: [Chicken-hackers] What to do with CHICKEN 4.13/4.12.1 release/snapshot?

On Nov 6 2017, Kon Lovett wrote: CHICKEN 4 LTS create a "Foundation for the Continuation" to support all NEKCIHCs ...for a to-be-defined length of "long term"; sign me up. Porting hundreds of modules and thousands LOC may or may not reveals issues. Once that's done only, we can see how

Re: [Chicken-hackers] [PATCH] Make the compiler output deterministic

Am Sat, 21 Oct 2017 17:12:33 +0200 schrieb Kooda : > Here is the same set of patches, for master, in case we want that. Congratulations Kooda! I have not looked at any of the patches. But I feel a strong desire to want the result! %% lifting my hat /Jörg

Re: [Chicken-hackers] Chicken 4.13: New bug in syntax-rules

module, than things change. The syntax-rules macro from the fist module will use this foreign binding to shadow the internal binding. Now really hygienic anymore. Cheers /Jörg On Jan 13 2018, Jörg F. Wittenberger wrote: Hi all, I just boiled down an issue with syntax-rules processing new

[Chicken-hackers] type declarations for define-record not working

Hi all, attached foo.scm. try (for C4 and C5): csc -s foo.scm C4 should do, C5 complains for me: Warning: at toplevel: assignment of value of type `(procedure foo#make-foo (*) (struct foo#foo))' to toplevel variable `foo#make-foo' does not match declared type `(procedure foo#make-foo

[Chicken-hackers] C lost -D on chicken-install

Hi all, apparently chicken-install lost the -D switch. To put it mildly: This worries me a lot. Now everyone will be looking for the best way how to bring this back. Or at least learn the answer the big question: Why the hell this is considered a bad idea and how to bring the functionality

Re: [Chicken-hackers] C lost -D on chicken-install

Oh, yes, please. The -D is crucial here. Nevertheless for whatever was dropped: it might be better to at least recognize and reject them with a specific message. Otherwise whatever build scripts will suddenly break with a rather generic message. This would be code which did work for quite a

Re: [Chicken-hackers] C lost -D on chicken-install

I'm not sure this will do the trick. it the environment variable CSC_OPTIONS added to the options given in the .egg file or does it overwrite them? The former would count as a workaround, the latter not help in my case at all. The use case of the -D switch, which I need first and foremost

[Chicken-hackers] csc-options in .eg file

It would be so practical if I could write (csc-options -O3) i.e., if the "arguments" to csc-options (and likewise link-options) would be implicit converted into strings. Any reasons this is not a good idea (TM). Best /Jörg ___ Chicken-hackers

Re: [Chicken-hackers] C lost -D on chicken-install

On Aug 21 2018, Peter Bex wrote: On Tue, Aug 21, 2018 at 09:22:47AM +0200, ko...@upyum.com wrote: felix.winkelm...@bevuta.com wrote: > There is no bad intent behind this - during the rewrite simply a few > options were dropped, since they didn't look crucial. If you want it > back, no

[Chicken-hackers] functor support

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 example.) 2. Line numbers for errors refer to an

Re: [Chicken-hackers] functor support

effort to avoid functors where I'd actually like to use them. (And still did not come up with a nice recipe how to do so.) Best /Jörg Am Sun, 09 Sep 2018 08:59:59 +0300 schrieb megane : > > Hi Jörg, > > Jörg F. Wittenberger writes: > > > Hi Chickeneers, > > &g

[Chicken-hackers] Feature request: make cond more resilient against misuse

Hi all, admitt this is a case of garbage-in-garbage out. A `cond` (or `case`) expression with an `else` branch behaves odd when an empty sequence of expression is given in the `else` branch: it results in an unbound variable "else" at runtime. Attached a test case. Try $ csc

Re: [Chicken-hackers] Eggs for Chicken 5

Am Thu, 22 Mar 2018 12:22:03 -0400 schrieb John Cowan : > On Thu, Mar 22, 2018 at 12:11 PM, Sven Hartrumpf > wrote: > > I use a Chicken-compiled alexpander to get rid of syntax-rules when > > compiling > > some Scheme projects (with non-Chicken compilers). >

Re: [Chicken-hackers] Chicken 4.13: New bug in syntax-rules

On Feb 24 2018, Peter Bex wrote: On Mon, Jan 15, 2018 at 10:11:05PM +0100, Peter Bex wrote: On Sat, Jan 13, 2018 at 03:28:09PM +0100, Jörg F. Wittenberger wrote: > Hi all, > > I just boiled down an issue with syntax-rules processing new in chicken > 4.13. > > It is a bit i

[Chicken-hackers] Would SRFI-157 (pre)support worth a consideration?

Hi all, with Chicken 5 being about to be released I know there is no adding features now. That's why I hesitate to post at all. At the other hand I'd guess it might be easier to now add half the feature I'd desire than later deal with a binary incompatible change. The problem: I've been

[Chicken-hackers] Bug in make-parameter / parameterize

Hi Chickeneers, learning from srfi-154 it seems there is a bug in make-parameter/parameterize. Here a simplified and shortend implementation of srfi-157 plus a test lifted from the srfi. With chicken (tested with version 4.11.1) it fails (returns #f). (chibi-scheme passes the test returning

Re: [Chicken-hackers] Bug in make-parameter / parameterize

25, 2018 at 02:01:08PM +0200, Jörg F. Wittenberger wrote: Hi Chickeneers, learning from srfi-154 it seems there is a bug in make-parameter/parameterize. Here a simplified and shortend implementation of srfi-157 plus a test lifted from the srfi. With chicken (tested with version 4.11.1) it fails

Re: [Chicken-hackers] Would SRFI-157 (pre)support worth a consideration?

On Oct 24 2018, Peter Bex wrote: On Tue, Oct 23, 2018 at 09:33:02PM +0200, Jörg F. Wittenberger wrote: Hi all, with Chicken 5 being about to be released I know there is no adding features now. That's why I hesitate to post at all. At the other hand I'd guess it might be easier to now add

Re: [Chicken-hackers] conditionals in .egg files

On Sep 28 2018, Peter Bex wrote: On Fri, Sep 28, 2018 at 08:28:21PM +0200, Jörg F. Wittenberger wrote: One more idea: How about an entry indicating the version of the egg file syntax? Having something to cond-expand is nice. But it might be hard to settle with a final version without unduly

[Chicken-hackers] Regression in CHICKEN 5

Hi all, commit bb6bf66b4bb6c16fedaf0aea55e965f9497f2885 just undoes what commit 0ae333805f8fc782d4cdc36e1f3675028a26d9fa introduced (argument to csc-options etc. being passed through ->string). Commit dc07113cf79a1930c6a109c738138dbea15afbc0 throws this out completely. Hence egg files can not

Re: [Chicken-hackers] conditionals in .egg files

Hi! I don't have to salute, do I? ;-) On Sep 27 2018, felix.winkelm...@bevuta.com wrote: Hi! I wonder: there is no way to conditionally set options, configure egg building, etc. I think it would be handy to have a "cond-expand" form that can be used inside ..egg files customize the egg

[Chicken-hackers] food for thought - a tentative change proposal

Hi all, attached patch is not yet in final shape. I just want to put it up as food for though. It should apply atop of b2caefa738. If you ever scratched your head about issues of signal handlers running within threads not suspecting that, limitations wrt. synchronization primitives likes

[Chicken-hackers] regarding 1564

Hi all, I just noticed that the fix for #1564 would introduce a fresh bug. Stupid me has sent out a version where the debug code was commented out. A patch will take several days to come around, sorry. The issue is in scheduler.scm ##sys#thread-basic-unblock! It used to begin (define

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

Hello Megane, On Nov 30 2018, megane wrote: Hi, Here's another version that crashes quickly with "very high probability". ... 24 Error: (mutex-unlock) Internal scheduler error: unknown thread state 25 # 26 ready This bears an uncanny resemblance to scheduler issues I've

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

On Dec 3 2018, Peter Bex wrote: On Mon, Dec 03, 2018 at 10:46:38AM +0100, Jörg F. Wittenberger wrote: So for me the question remains: wouldn't it be much, much more efficient to work sort-of hand-in-hand with one of the core developers, or maybe on the list to get the remaining things (bugs

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

wrote: see attached git (C4) & svn (C5) logs #(in C4 core local repo) git log --follow -p -- srfi-18.scm >srfi-18.log #(in C5 svn local repo) svn log --diff trunk >srfi-18_trunk-diff.log hth On Dec 2, 2018, at 1:19 PM, Jörg F. Wittenberger wrote: Thanks for the replies, chicken-

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

pped (srfi-18) to () retrieving ... On Dec 2, 2018, at 10:42 AM, Kon Lovett wrote: C5 evicted srfi-18, along w/ srfi-1, 13, 14, & 69, to the egg store. chicken-install -retrieve. On Dec 2, 2018, at 10:39 AM, Jörg F. Wittenberger wrote: Hi all, when I tried to reply in a timely manne

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

Hi all, when I tried to reply in a timely manner I apparently sent out a link to a broken file. Sorry for that. Just wanted to see if I could create a patch for the current master. For this I need srfi-18 egg source too. Just I can't find it. Jöry On Nov 30 2018, Jörg F. Wittenberger

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

Attached a version against master. This only appears to be correct. :-/ I messed up with the prefix, thus srfi-18 did not load and I will really not find the time to come back to the issue in a timely manner. On Dec 3 2018, Jörg F. Wittenberger wrote: Attached a patch against 4.13 master

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

Attached a patch against 4.13 master still compiling On Nov 30 2018, megane wrote: 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

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

Hi Megane, thanks for looking at my submission. Let me try to answer your questions. On Nov 17 2018, megane wrote: 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

[Chicken-hackers] semantics of thread-suspend! and thread-resume!

Hi, thread-suspend! and thread-resume! are extensions to srfi-18 provided by the srfi-18 unit respectively the srfi-18 egg. A warning in the source hints to the issue at hand: ;XXX what if thread is ready or blocked? The semantics are weekly defined and it easy to create pathological test

[Chicken-hackers] some patches for scheduler and srfi-18

Hi all, attached several patches I owe you. Patches 0001-0004 should apply on chicken 4.13, i.e. 68eeaaef3fc. Patches 0005 and 0006 are against master (9f55823852). Patches 0007 and 0008 are against srfi-18 egg source. 0002 - Fix 1564: This establishes the invariant that slot #11, the

[Chicken-hackers] [PATCH] fix issues regarding force-primordial

Hi all, up to now the primordial thread must sit in thread-join! for force-primordial to do the right thing. It would be the wrong solution to go after all synchronization primitives adding an alternative micro-threading to dispatch signals. This would hopelessly complicate the code.

Re: [Chicken-hackers] [PATCH] Always regenerate import libraries in setup-mode

Hi Evan, I'm not sure what the effect of this patch is going to be. I'm just a bit afraid. I have load of code using Chicken from Makefiles. Typically in setup mode and at the same time these Makefiles rely on the import libraries not being regenerated if they don't change. That's how the

[Chicken-hackers] patch: STATICBUILD for mingw

Hi, STATICBUILD for mingw cross compiled for linux gave me errors of the kind __imp_SYMBOL being undefined. The attached patch is a bit questionable. I dunno what I'm doing here. But at least it went through. Best /Jörg --- Makefile.cross-linux-mingw 2017-12-11 17:46:55.0 +0100 +++

[Chicken-hackers] patch to make PROGAM_SUFFIX do the intented thing

Hi, I tried to use PROGRAM_SUFFIX to install c4 and c5 in parallel using the same prefix (against the documented suggestions, but it looked more coherent in my case). This failed with the include files installed in .../include/chicken$PROGAM_SUFFIX - which looks to me like the right thing to do)

[Chicken-hackers] patch: fix STATICBUILD attempting to install .so's

Hi, using STATICBUILD failed in an attempt to install setup-api.so. rules.make hints to the culprit already. Attached patch made it work for me(TM). Best /Jörg --- rules.make.orig 2017-12-11 17:48:05.0 +0100 +++ rules.make 2019-07-10 15:04:50.217307880 +0200 @@ -379,12 +379,10 @@

Re: [Chicken-hackers] [PATCH] Improve srfi-13 performance quite a bit by inlining optarg handling

Am Fri, 27 Sep 2019 23:27:23 +0200 schrieb felix.winkelm...@bevuta.com: > > Hi all, > > > > Attached is a relatively straightforward patch for SRFI-13. It > > changes the let-string-start+end macro (and also > > let-string-start+end2 but that isn't exported) so that it uses > > let-optionals*

Re: [PATCH] Pick rest argument values directly from the argvector without consing

Thanks Peter for investing your time into this. While I did not proof-read your code, my bet is that this kind of optimizations do add up at the end of the day. On Oct 27 2019, Peter Bex wrote: On Sun, Oct 27, 2019 at 01:16:10PM +0100, Peter Bex wrote: This super simple benchmark runs 25%

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

On Oct 1 2019, felix.winkelm...@bevuta.com wrote: 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 increase the inline-limit, which of

Re: [PATCH] force finalizers only if finalizers exist

On Wed, 6 May 2020 13:13:24 -0400 John Cowan wrote: > The Right Thing is probably to eventually run the GC on a private > thread, at least when multiple threads are running at all. That way > the finalizers run on the same thread that doesn't hold any locks or > otherwise risk trouble. That's

Re: Default file creation mode for core/scsh-process sets executable bit

On Thu, 7 May 2020 16:43:47 +0200 Vasilij Schneidermann wrote: > Hello, > > I've noticed that when using process redirection in the scsh-process > egg, they're always marked as executable. Observe: > > ^_^ csi -R scsh-process -e '(run (ls -l) (> ls.txt))' > ^_^ ls -l ls.txt >

Re: Quiet re-imports

Am Wed, 24 Mar 2021 23:51:13 + schrieb Diego : > I think it would be nice to have a flag/parameter to quiet > "re-importing already imported identifier/syntax" warnings. These > seem rather noisy, and in many cases the user is probably aware of > potential collisions (as in (import r7rs), for

Re: Building pthreads egg on MacOS

Hi Lassi, that's a good question! There has been only so much consideration as to why raise the priority in the first place: there is exactly one Chicken thread, hence it's a precious resource. Let's raise priority. In other words: I'd expect little harm without it. Just inconsistency. :-/

<    1   2   3