Re: [Chicken-hackers] [PATCH] Drop now-unnecessary exports from the "chicken.export" module

> This brings up the obvious question: what should we do with > (chicken expand)? I was considering a patch to rename it to > (chicken syntax) like we have in c-l-r, but should we then also > rename the expand.scm file to syntax.scm? I think this would > be the most sensible thing to do. > >

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

> 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" (or the export list) do that job? Because you have to import first. IIRC,

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

> On Wed, Jun 7, 2017 at 2:06 PM, wrote: > > Isn't it easy to forget particular identifiers that happen to start with > > "fp" > > as well? I think explicit "rename" imports are clearer and less error > > prone. > > > > My example is bad: you'd want to use it with a

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

> First, let me ramble some: > > 1. If you hide an exported identifier the compiler is free to drop the > actual definition from the compiled object. This happens without any > warnings currently and you get a runtime error if you try to use the > identifier. > > 2. If an identifier is not

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

Re: [Chicken-hackers] [PATCH] Moving some things from library.scm and eval.scm to internal.scm

> I think we should strive to make library the first, and potentially the > only, unit that the user needs to care about when distributing compiled > C or compiling programs with "-explicit-use". These changes move things > further away from that ideal by making programs that use the `time` >

Re: [Chicken-hackers] [C5] `extension' components & non-modules

> > The multi-module case is indeed not covered. There is an note on the > > wiki regarding functors that emit 2 import libs (used in some places), > > this has to be handled automatically (compile + install .import.so > > and _.import.so, if the latter one exists). Another option would be > > to

Re: [Chicken-hackers] [C5] `extension' components & non-modules

> Should extension components specified in .egg files be required to be > modules? > > If I understand correctly, that's the case at the moment, as the build > script will try to compile .import.scm files supposedly emited for files > specified as extensions (they might not exist if the files

Re: [Chicken-hackers] [PATCH] Re: Alternative egg installation directories

> Is CHICKEN_INSTALL_PREFIX intended to be used together with > CHICKEN_INSTALL_REPOSITORY? If I don't set CHICKEN_INSTALL_REPOSITORY, > extensions and .egg-info files end up in the canonical repository. Not > sure if this is by design. Yes, this is the case. I thought it is better to have two

[Chicken-hackers] [PATCH] Re: Alternative egg installation directories

Hello! Here a patch for this. CHICKEN_INSTALL_PREFIX overrides the bin, include or share directories when generating the install scripts. Note that the installed egg-info files refer to the new directory as well, so this is not the same as DESTDIR. chicken-status + chicken-uninstall will list

Re: [Chicken-hackers] Alternative egg installation directories

> Attached is a patch that adds an extra environment variable > (CHICKEN_INSTALL_BINDIR) to specify an alternative directory for > executables (please don't consider applying -- it only serves to > illustrate the situation). I don't think it is enough, though. Maybe > eggs will want to install

Re: [Chicken-hackers] [PATCH 1/1] Correct a typo causing inline files to be installed incorrectly

Applied and pushed. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH 0/4] Some symbol and module-related patches

> On 2017-05-15 9:24, felix.winkelm...@bevuta.com wrote: > > I would like to elevate it to an official policy that patches that > > break bootstrapping should only be pushed when there is a publicly > > available snapshot tarball. > > That certainly makes sense to me. > > If there are no

Re: [Chicken-hackers] [PATCH 0/4] Some symbol and module-related patches

> Please note that you will need to use a chicken (or a > boot-chicken) that includes the first commit in order to build this > second one. I would like to elevate it to an official policy that patches that break bootstrapping should only be pushed when there is a publicly available snapshot

Re: [Chicken-hackers] About (chicken process) and (chicken process-context)

> I was filling in the "Module (chicken process)" wiki page for the new > manual, and noticed something peculiar: > > current-process-id and parent-process-id are in (chicken process-context), > but process-group-id and its related setter, and create-session are in > (chicken process). This

[Chicken-hackers] [PATCH] [5] drop chicken-prefix

Hi! This patch removes the internal procedure "chicken-prefix" in eval.scm, and thus any support for the CHICKEN_PREFIX environment variable. Also, some old refrences to CHICKEN_INSTALL_PREFIX have been removed from the documentation. felix From 00ed94a099f25e20b141a1e54f5fa0548e174517 Mon Sep

[Chicken-hackers] [PATCH] [5] make -all the default behaviour for chicken-status

Hi! As evhan suggested, this patch drops the "-all" option for chicken-status, giving it thhe same view of the set of available eggs as is represented by CHCIKEN_REPOSITORY_PATH. This is more consistent with what the user sees. CHICKEN_INSTALL_REPOSITORY is still fully functional, but needs to be

Re: [Chicken-hackers] [Chicken-janitors] #1218: chicken-install may fail if TMPDIR is mounted noexec (depending on setup-file details)

> Ubuntu-derived distributions now ship with /tmp mounted as noexec by > default. This results in a chicken-install error that is difficult to > diagnose by non-expert users. The remedy can be as simple as setting > TMPDIR (but perhaps that should be prominently documented), an option > that

Re: [Chicken-hackers] chicken-5-new-egg-install branch

Hi! There was a bug in the linking-test section of tests/runtests.sh (fix pushed.( The base64-installation problem I can't reproduce. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org

[Chicken-hackers] chicken-5-new-egg-install branch

Hello! The new egg-installation stuff is now in a state that seems to be basically usable and I wonder how to go on with this, as it is a bit of a hassle to keep this branch in sync with the C5 master. Egg installation (for the basic set of eggs we currently have) seems to work fine, including

Re: [Chicken-hackers] [PATCH] Fix a logical bug in the optimizer

> On Mon, Mar 27, 2017 at 08:37:05PM +0200, lemonboy wrote: > > As promised here's the patch, sorry for the noise. > > I don't understand this code at all. Why does it (touch) and then > scan the first expression again, and what does "escaped" mean exactly? The second scan of "first" was

Re: [Chicken-hackers] [PATCH] [5] Aggressively reject definitions in expression contexts (#1309)

> On Sat, Feb 25, 2017 at 06:13:48PM +0100, Peter Bex wrote: > > However, I figured out that the real cause of #1309 is much, much deeper > > and has to do with a nasty bug in ##sys#canonicalize-body: it invokes > > "fini" as soon as it sees a non-pair. However, fini doesn't handle > > expansions

Re: [Chicken-hackers] [PATCH 0/8] Add posix replacement modules

Hi! IIRC, all the module changes are not documented, yet, is this correct? Would it be a good idea to start documenting these changes? Speaking only for myself, I completely lost my grasp on what functionality is provided by what modules felix

Re: [Chicken-hackers] [PATCH 0/2] Move "compile-file" to egg and drop utils unit

> I'll tag version 1.0 of the compile-file egg once they've been applied, > assuming they look OK. Excellent. Could you add the egg also to the chicken-5-eggs repo? felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org

Re: [Chicken-hackers] [PATCH] Make process procedures in the posix module accept alists for environments.

> On 2017-03-02 10:34, felix.winkelm...@bevuta.com wrote: > > Is this for CHICKEN 5? If not, then we need a change request, as this is an > > incompatible change. > > I think this, and in fact all changes that aren't strictly bug fixes for 4.12, > should go into chicken-5 only from this point on.

[Chicken-hackers] new egg install update

Hello! I've pushed a few changes regarding the new egg install and would be happy about feedback regarding these changes: * chicken-status + chicken-uninstall use exact matching by default (use -match to use globbing) * there are now 2 env vars: CHICKEN_REPOSITORY_PATH: one or more

Re: [Chicken-hackers] [PATCH 1/8] Add chicken.file module

> On 2017-03-02 10:36, felix.winkelm...@bevuta.com wrote: > > I can't recall whether we have settled on this, but having a "file" > > and a "files" module strikes me and somewhat confusing. > > Right, it's my intention that we drop "files" once it (and posix) have > been refactored into "file"

Re: [Chicken-hackers] [PATCH 1/8] Add chicken.file module

I can't recall whether we have settled on this, but having a "file" and a "files" module strikes me and somewhat confusing. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Make process procedures in the posix module accept alists for environments.

Hi! Is this for CHICKEN 5? If not, then we need a change request, as this is an incompatible change. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] new CHICKEN 5 egg installation

> > Mario, would this help with Salmonella? > > Not sure if I undertand the proposal. You mean chicken-install would > install eggs in the directory pointed by CHICKEN_REPOSITORY? I would suggest to _lookup_ eggs (during loading + linking) from any of the directories given in

Re: [Chicken-hackers] new CHICKEN 5 egg installation

> On Thu, Feb 23, 2017 at 02:00:46PM +0100, felix.winkelm...@bevuta.com wrote: > > Some time ago there was a strong interest in supporting mulitple local egg > > repos (i.e. CHICKEN_REPOSITORY would specify a list of directories, each > > of which may contain eggs). Would that allow dropping

Re: [Chicken-hackers] new CHICKEN 5 egg installation

> Exciting news! What would it take to get deployment working? In the > past, I found it immensely useful to be able to distribute binary, > particularly with Windows and Mac OS X users who are not likely to > have a compiler installed, or a readily installable Chicken binary > distribution.

[Chicken-hackers] new CHICKEN 5 egg installation

Hello! I have now a first prelininary version of the new egg installation tools for CHICKEN 5 working, and before we go on, I'd like people to review and reflect on the changes that have been made so far. I also need some advice regarding a number of issues... The branch is

Re: [Chicken-hackers] [PATCH 0/1] Add _XOPEN_SOURCE feature test macro

> I really hate playing this stupid game of whack-a-mole with header > definitions (there seems to be no sane combination of definitions that > will work on all OSes). Instead, I think it's better to just give in > and add the --std=gnu99 on all platforms where we're using gcc and clang. > I'd

[Chicken-hackers] testers for new CHICKEN 5 install needed

Hello! I'm currently trying to implement the new egg-install for CHCIKEN 5 and if people like to contribute by testing this, I would be very grateful. The branch is "chicken-5-new-egg-install", in the chicken repo. The main "innovation" is a new egg description file format, that can be

Re: [Chicken-hackers] Add branch prediction for C_demand checks [was: Re: [PATCH] Statically determine if argvector can be reused]

> And here's another one, that adds C_likely() and C_unlikely() macros, > a la the Linux kernel's likely() and unlikely(). These are simple > wrappers for __builtin_expect() which tell the compiler which branches > in a conditional expression are likely to be taken. > Signed off and pushed.

Re: [Chicken-hackers] [PATCH] Statically determine if argvector can be reused

> Hi all, > > I've been playing around a little bit with "perf" and Valgrind's > cachegrind tool, and I noticed that the number of branch prediction > misses can be reduced if the argvector reusing check can be hardcoded > for cases where we know the size of the calling function's argvector. > >

Re: [Chicken-hackers] Should we make a 4.12 release?

> > I think it would. To truly test in a clean environment I would suggest to > > use a fresh chicken installation for case 1 as well. Note that this can > > be done by pure copying/hardlinking of files, assuming the user didn't > > modify installed files. I was talking nonsense here - of course

Re: [Chicken-hackers] Should we make a 4.12 release?

> On Tue, 03 Jan 2017 21:35:46 +0100 felix.winkelm...@bevuta.com wrote: > > >> Salmonella relies on -prefix to install eggs into a fresh local egg > >> repository. That's how it is able to catch dependency problems, for > >> example. > > > > Shouldn't you use a separately built chicken

Re: [Chicken-hackers] Should we make a 4.12 release?

> Salmonella relies on -prefix to install eggs into a fresh local egg > repository. That's how it is able to catch dependency problems, for > example. Shouldn't you use a separately built chicken insallation for that, with a pristine egg repository for each run? felix

Re: [Chicken-hackers] Should we make a 4.12 release?

> The question was actually related to C4, as the behavior of -prefix > changed in 4.11 (see http://bugs.call-cc.org/ticket/1298 ). Yes, that might be. The answer is still the same. It was a hack from the beginning. > > Regarding C5, any idea on how to implement a tool like salmonella? I

Re: [Chicken-hackers] Should we make a 4.12 release?

> Felix: what was the original intended behavior for -prefix, regarding > handling of dependencies? IIRC, it was just a hack for overriding the installation prefix, among other crude methods (CHICKEN_PREFIX, or CHICKEN_INSTALL_PREFIX, or whatever, I lost track...). It should go, IMHO. No

Re: [Chicken-hackers] Should we make a 4.12 release?

> I'm not sure what to do about #1293. We don't have a simple way > of assigning unique object IDs, so some objects will "notice" they > get moved by the GC and all objects will notice when they're mutated. I don't really consider this a bug. It's a natural result of using eq? as hash-table

Re: [Chicken-hackers] [PATCH] Ensure chicken-install honors -prefix when using -keep-installed (#1144)

> Hi all, > > Attached is a pretty straightforward patch to fix #1144. > The problem is that we're using "extension-information" > while walking the egg list to see which eggs already exist. > If extension-information returns a non-#f value, it will > be removed from the list. > > When using

[Chicken-hackers] happy christmas!

Dear CHICKEN folks! I wish all of you a very happy christmas. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] [5] Aggressively reject definitions in expression contexts (#1309)

> On Sun, Dec 11, 2016 at 10:58:50PM +0100, felix.winkelm...@bevuta.com wrote: > > I don't know, but reading what you wrote in the ticket ("... this will > > require quite a bit of rework and hardcoding all defining forms into the > > compiler (which we have to do already anyway, to make internal

Re: [Chicken-hackers] [PATCH] [5] Aggressively reject definitions in expression contexts (#1309)

I don't know, but reading what you wrote in the ticket ("... this will require quite a bit of rework and hardcoding all defining forms into the compiler (which we have to do already anyway, to make internal defines work)...") makes me cringe. It's the responsibility of the defining forms to

Re: [Chicken-hackers] [PATCH] Improve read/write invariance of keywords (#1332)

> Hi all, > > I've taken a look at #1332. Attached are patches against master and > CHICKEN 5 to fix keyword handling. I would propose to change this only in 5, since this might break things (as you hint at below). > To avoid all these issues, I think it's simplest to just ignore the > keyword

Re: [Chicken-hackers] [PATCH] [5] Let's get rid of ##sys#fudge

> But yeah, we might want to consider exposing the three version thingies > (major, minor, binary) as procedures or constants from Scheme as well. "chicken-version" returns this string, where the 4rd number already has a different meaning. So I would not throw this together with the exissting

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

> 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" means tagged pointers? I agree. > > > > I continue to

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

> > A somewhat disturbing patch, but it does indeed simplify the > > code. > > What's disturbing? The huge amount of changes? So many hardcoded numbers, easy to get things wrong. > > > Having only one type bit lefft worries me a bit, though. > > We could still get rid of the tagged pointer

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

> On Mon, Aug 08, 2016 at 10:56:39PM +0200, Peter Bex wrote: > > The attached patches add a custom type for bignums (first patch) and > > custom types for ratnums/cplxnums (second patch). This reduces the > > aforementioned C_s_a_i_times() pre-allocation from 40 to 29 words. > > Here's an

Re: [Chicken-hackers] [PATCH] [5] Simplify weak symbol GC and make it the default

> On Thu, Sep 29, 2016 at 01:49:47PM +0200, felix.winkelm...@bevuta.com wrote: > > Hello! > > > > I'm currently trying to evaluate these patches and have a few questions: > > > > - If I understand correctly, a symbol must be explicitly persisted by > > marking it using > >

Re: [Chicken-hackers] [PATCH] [5] Simplify weak symbol GC and make it the default

Hello! I'm currently trying to evaluate these patches and have a few questions: - If I understand correctly, a symbol must be explicitly persisted by marking it using "C_i_persist_symbol", but that only seems to happen when assigning to a global in the evaluator, or when using

[Chicken-hackers] [PATCH] patches for feathers

Hello! The following two patches change the default colors in feathers to something more neutral and fix an issue with the use of the source file search path: running the debugger in a different directory didn't use the search path passed with "-dir" correctly. felix From

Re: [Chicken-hackers] [PATCH] Fix #1173 (weak symbol GC)

Hi! Signed off and pushed. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] substring

> > Hello all, > > Sjamaan and Mario on the channel brought up an interesting issue with > substring=?. The current semantics check only to the length of the > shorter string, so: > > (and (substring=? "foo" "foobar") (substring=? "foobar" "foo")) => #t > > > I submit that this behaviour is

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

> My main concern, after giving it some more thought, is that you can't > easily make the FFI check the pointer type, unless you enforce that > pointer tags are somehow either compile-time constants, or also stored > in some global that's directly accessible to the FFI. There should be > a

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

> All in all, I think these changes are worthwhile but for the caveat > that it results in us having NO MORE reserved type tags left! In > fact, the complete change is only possible because we dropped the > SWIG pointer type; before that we only had two reserved types left. > I don't see an easy

Re: [Chicken-hackers] scheme-bytestructures, multi-implementation libraries

> I think it would be good for chicken's spread and adoption in the scheme > world if its install system supported this case of multi-implementation > libraries, where the chicken-specific files can all be in a > subdirectory. To that end, I propose that some declaration could be > added to

Re: [Chicken-hackers] [PATCH] Hash all the record slots

> The limit probably was put in there for a > reason. Maybe Felix can enlighten us here? Well, performance, obviously - you don't want to iterate over all elements of a vector just to get a hash. felix ___ Chicken-hackers mailing list

Re: [Chicken-hackers] [PATCH 4/5] Add scrutinizer test suite

: > +(test (not (<= cplxnum integer))) > +(test (= (or fixnum bignum) integer)) > + > +;;; deprecated > + > +(= deprecated deprecated) > +(! deprecated *) > +(! (deprecated x) *) > +(! (deprecated x) deprecated) > + > +;;; immediate types > + > +(= eof immediate) > +(< eof immediate) > +(< null

Re: [Chicken-hackers] [PATCH] Make CHICKEN build process deterministic

Hello! >[...] Why an additional unit? felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

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

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

> 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 is where something like a dedicated interrupt handling > thread

Re: [Chicken-hackers] [PATCH] Truncate overlong lines in ##sys#error-handler

> On Wed, May 25, 2016 at 09:41:52PM +0200, lemonboy wrote: > > Hello, > > this patch makes ##sys#error-handler respect the width limit as it's > > done in the other code paths. > > (Limits have been bumped to 100 to make those uniform throughout the code) > > I hope the merge window is still open

Re: [Chicken-hackers] [PATCH] #1277 make check failure on OS X 10.11

> This is an initial patchset for #1277 on which I invite comments. Note that I'm currently revamping the chicken-5 egg setup stuff, which means that shell command execution will be significantly changed in that part (and will probably not need such a change as you here propose.) I must say

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

> This is why I dislike the posix module so much, it's so low-level that > it doesn't even bother to abstract away these things. It's C with > parentheses, except in some cases where the abstraction is so high that > it's even unlike POSIX (for example in the "process" procedures). As they say,

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

> > 1) Generated CPS functions will allocate what they need on the >stack for local variables up front, then do a C_stack_probe() >or a C_demand, but they will allocate an arbitrary amount of >words for the argvectors *WITHOUT ANY CHECK WHETHER IT WILL FIT*. > > 2) C_stack_probe()

Re: [Chicken-hackers] slow polling

> > Does it have to be fixed in Chicken 4 at all? > > Not necessarily, but I figured that since the scheduler hasn't changed > much between the two versions, if we have a fix for 5 it can be applied > to master without too many changes as well. This goes for several > improvements that have been

Re: [Chicken-hackers] slow polling

> On Wed, Feb 24, 2016 at 11:12:09AM +0100, Jörg F. Wittenberger wrote: > > 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

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

> > 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, then we needed zero allocation for most cps calls. Careful. Global register variables increase register pressure in the

[Chicken-hackers] [PATCH] fix for #1231

Hello! Attached is a new version of Jörg's patch for srfi-18, that fixes some problems with mutexes. It contains an additional change supplied by Jörg that sets the "blocking object" slot in the thread structure correctly. A patch for the srfi-18 egg for chicken5 is attached as well. I ran

[Chicken-hackers] ##sys#delq

Hi! I'm currently testing Jörg's srif-18 patch with chicken-5 and found that ##sys#delq is not available anymore. Is there any replacement provided by core that can be used? It seems that srfi-18 wasn't tested for quite a while, it may be a good idea to test the few chicken-5 eggs that we have

Re: [Chicken-hackers] ##sys#delq

> On Sat, Feb 06, 2016 at 10:50:14AM +0100, felix.winkelm...@bevuta.com wrote: > > Hi! > > > > I'm currently testing Jörg's srif-18 patch with chicken-5 and found that > > ##sys#delq is not > > available anymore. Is there any replacement provided by core that can be > > used? > > That

Re: [Chicken-hackers] [PATCH] Fix unsafe code generation caused by debugger change in core target language

> Hi all, > > The attached patch's commit message says it all. Thanks for finding (and fixing) this. Signed off and pushed. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] Xmas Greetings

A very happy christmas to all of you! felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

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

> Now, if you look at the patch you'll see that it changes irregex-core.scm, > which means it creates a "fork" against that part of the code in upstream. > I don't see a way to declare the type from the "outside", in irregex.scm, > unless we also copy that code body as a macro, but that feels

Re: [Chicken-hackers] [PATCH] treat backslash as normal filename character in "files" unit

Hello, again. Mario did some serious testing on Windows, and found yet more problems with the changed way of normalizing pathnames for UNIX/Windows. As we generate shell-commands for both UNIX and Windows (each with their own weird and obscure quoting behaviour), this had a number of

Re: [Chicken-hackers] [PATCH] treat backslash as normal filename character in "files" unit

Hello! Mario kindly tested the patch and found a problem with chicken-install on Windows, with regard to shell-quoting. Attached a new version. felix From dbf0a0a5487007950c61f80bd2ed7bf94a371dfe Mon Sep 17 00:00:00 2001 From: felix Date: Fri, 6 Nov

[Chicken-hackers] [PATCH] treat backslash as normal filename character in "files" unit

Hello! Attached is a patch that corrects pathname handling in the "files" unit. Currently / and \ characters are both treated as valid pathname separators, which is of course not correct on UNIX, where backslash is a normal filename-character. On Windows (in the Explorer and the Win32-API, but

Re: [Chicken-hackers] [PATCH] Disable getc_unlocked on MinGW

Hi! I applied and signed off this patch. It is required with certain flavors of mingw32, it seems. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH][5] Make temporary stack resizable (fixes #1098)

> On Sun, Nov 01, 2015 at 01:36:53AM +0100, felix.winkelm...@bevuta.com wrote: > > Is this really necessary? I think runtime.c is already complicated enough > > as it > > is. I understand your intent, but I'm always wary of "arbitrary fixes to > > reasonable > > limitations, just because they

Re: [Chicken-hackers] [PATCH][5] Make temporary stack resizable (fixes #1098)

> > That doesn't change the fact that it is very bad programming style. It > > doesn't > > scale, is not portable and very inefficient. Endorsing such a programming > > style > > encourages writing bad code, therefore I really recommend a hard limit. > > It's not up to us to tell other how to

Re: [Chicken-hackers] [PATCH][5] Make temporary stack resizable (fixes #1098)

> Hi all, > > Now that we're using argvectors, we're no longer limited by any arbitrary > C macros or platform-specific hacks. The only two things that determine > the number of arguments that can be passed to a procedure are: > > 1) The size of the C stack (because that's where argvectors are

Re: [Chicken-hackers] [PATCH][5] Make the "-module" option take the module name as an argument

> This is a bit of a niche option, isn't it? I don't really see the use > of it: nothing gets exported anyway, so why should the name of the > module matter? Besides, wrapping something in a module isn't really > that useful, except maybe to catch errors. > > I'd like to hear the opinion of

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

> On Sat, Oct 17, 2015 at 04:58:06PM +0200, Peter Bex wrote: > > Well, here's a bunch of patches to fix this issue (#1221) as well as a > > handful of memory-related issues. I still haven't managed to pinpoint > > the crashes we're seeing on Salmonella, but this is a separate issue > > which

Re: [Chicken-hackers] [PATCH] Another argvector memcpy misuse causing segfaults

> Alexander Shendi reported that syntax-tests.scm triggered a segfault > on OpenBSD 5.7, but only when compiling with clang. I was able to > reproduce it in a VM, and the stack trace pointed to C_apply at > runtime.c:5975. > > The stack trace contained a call to C_apply which was called from >

[Chicken-hackers] merging the argvector changes

Hello! Peter asked me to write a few words about the status of the argvector related changes (passing arguments to CPS-procedures in a stack-allocated vector instead of doing it directly). As I already wrote, the initial reason for this change was the new ARM64 iOS ABI, which rigorously

[Chicken-hackers] argvector chicken (was: ABI woes)

- The maximal number of arguments is limited by the temporary stack. Note that this is not fixed (and depends on temp-stack usage), and I had to remove some code in apply-test.scm, as it assumed a fixed limit. The official arg-limit is 2000 now. It's been on my todo-list for a

[Chicken-hackers] argvector chicken (was: ABI woes)

Scripsit felix.winkelm...@bevuta.com: CPS calls are surprisingly expensive in general in CHICKEN, Ah, I'm confused now. Are CPS calls a specific type of call? I had assumed that all calls (except to C primitives) are CPS calls. Yes, that's true. There is support for so-called direct

[Chicken-hackers] argvector chicken (was: ABI woes)

Scripsit felix.winkelm...@bevuta.com: The new approach passes all arguments in a stack-allocated C_word array. I would expect this to deeply suck on systems that have lots of registers and whose C compilers routinely pass arguments in registers. In particular, not significantly

[Chicken-hackers] ABI woes

- There is no need for rest-arg wrappers, functions that extract the rest argument and then call the actual compiled C function. This can be done directly from the argvector. This is cool, but if I understand correctly it also means that all the C_fast_retrieve_proc(lf[123])(a, b, c)

[Chicken-hackers] ABI woes

Hello! After thinking about this, it seems to be that the compound literal approach is the best one. What this means is that CPS-calls are changed in such a manner, that arguments are passed rthrough a pointer to a C_word-array (so it doesn't have to do anything with compound literals, that

[Chicken-hackers] New dimensions in ABI design braindamage

felix.winkelm...@bevuta.com scripsit: a function ptr of type typedef void (*C_proc4)(C_word, C_word, C_word, C_word, C_word) that points to a function of (say) this type void myproc(C_word c, C_word k, C_word a1, ...) will break, Yes. That's undefined behavior

[Chicken-hackers] New dimensions in ABI design braindamage

Hello! We are currently investigating a problem with CHICKEN code compiled on ARM64 (iOS) and it seems that the way procedure-calls are compiled is entirely incompatible with Apple's modifications of the ARM64 ABI. I'm not completely sure, but judging from the Information found at [1] and [2],

Re: [Chicken-hackers] (Removing) ambiguity in csc's command line options

(tl;dr: don't) I know, I'm a bit late to this discussion, but let me ask, nay, implore you to leave things as they are, for the following reasons: First, nobody really wants to go through each and every tool, figuring out the command-line parsing, changing (and breaking) everything in the

Re: [Chicken-hackers] [PATCH][5] Minor cleanup patches

Two very simple cleanup patches. Thanks - signed off and pushed. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] More efficient numbers integration through scratchspace

The scratch area is seen as an extension of the nursery: the C_demand() and C_stack_probe() checks will add the size of the scratch space to the stack's size, and trigger a minor GC when the sum of the two exceeds the maximum nursery size. So this is just a heuristic, as the data in

Re: [Chicken-hackers] [PATCH 0/2] Fix #t being not always-true

1. We remove -local from $(CHICKEN_COMPILER_OPTIONS). This is the simplest option, and the attached patch does just this. I'm for this option. It's clearly a misuse of the option, and yet another annotation just makes things ugly and complicated. felix

<    1   2   3   4   5   6   7   8   9   >