> Hi all,
>
> Here's another patch to update irregex to the 0.9.7 release, which
> makes irregex-split, irregex-fold and irregex-replace behave consistently,
> both internally and in comparison to other regex engines when dealing
> with empty matches.
>
Pushed.
felix
> Hi all,
>
> Here's a port of the patch for irregex to fix #1661.
>
> There's still a bug in irregex-split, which Alex plans to fix
> soon as well. In the meantime it's probably a good idea to
> apply this one (and see if it breaks any eggs).
>
Pushed.
felix
> Hi Peter,
>
> On 12/28/19 4:42 PM, Peter Bex wrote:
> > I think we're about ready to start the process for a 5.2.0
> > release. What do you think? Should we wait for the eggs
> > from #1655 to be fixed?
> >
> > What about the plaform auto-detection patch?
>
> IMO we should try to fix the eggs
Folks,
I wish all of you a very happy christmas and a fulfilling and pleasant new
year!
cheers
felix
Hi!
"-:hs0" is currently ineffective, since validity checks between parsing
the option and initializing the heap overwrite the setting.
This patch initializes the heap-parameter variables statically,
removes the validity checks and does an explicit check for
C_heap_shrinkage being 0.
I think
> On Sun, Dec 15, 2019 at 10:06:06PM +0100, felix.winkelm...@bevuta.com wrote:
> > I think you forgot the rest-arg-tests.scm file.
>
> Oops, you're right. Here it is.
>
Thanks, pushed.
felix
I think you forgot the rest-arg-tests.scm file.
felix
Hi!
This patch addresses #1659, as reported by Thomas Chust.
felixFrom 8e97db015dc9a474f521411cb40de736194d9ac7 Mon Sep 17 00:00:00 2001
From: felix
Date: Sat, 14 Dec 2019 13:14:58 +0100
Subject: [PATCH] Compile c-object components with proper flags
Egg components of type c-object should be
> Hi all,
>
> As found by Kon Lovett, there was still a bug in the rest argument
> handling when the rest argument was moved inside a closure and the
> rest argument would no longer be accessible locally but needs to be
> converted to a closure reference.
>
> I have been unable to come up with a
Thanks, pushed.
felix
> On Sun, Dec 01, 2019 at 11:22:37PM +0100, felix.winkelm...@bevuta.com wrote:
> > It seems to work fine, but "-:hs0" doesn't seem to work. I tried
> >
> > csi -:d -:hs0
> > > (define x (make-vector 1000))
> > > (##sys#gc)
> > > (##sys#gc)
> > > ...
> >
> > The heap is
> Hi all,
>
> As suggested by Sven Hartrumpf in #1379, the current logic which
> decides when the heap should be shrunk is confusing and looks
> "obviously wrong".
>
> For one, the "count" variable indicates the actual used memory.
> This is in one half of the heap, so it seems incorrect to me to
Hello!
Attached is a patch for handling the case given in #1655 in a less
confusing way (by signalling an error).
felix
From fde79334d97bb230067880f80e36edca88755e33 Mon Sep 17 00:00:00 2001
From: felix
Date: Tue, 19 Nov 2019 11:52:34 +0100
Subject: [PATCH] disallow using -c option in csc with
> Thanks for the suggestions, they clean up the code quite a bit.
> Attached is a new version of the patch that implements these changes.
> I also found out that there was still a bug: when a procedure was
> customizable, the generated C rest arg accessor would crash because
> there's no "av" nor
Hi!
Very nice, works well and makes sense. Here a few suggestions:
- For new optimizations, I'd add 'x to the debugging flags given
to "debugging", that way one can easily see new or experimental
compiler features at work an whether they cause trouble.
- The implementation of
Hi!
Very cool, Peter. Please let me have a look at this before we seriously
consider adding the patch.
felix
>
> Pushed. Thanks!
and thanks for fixing the comment and your note about O(N)
performance. I don't think it makes much of a difference in real life
to use a different data structure, but nevertheless it is noted for
posterity.
felix
___
> On Sun, Sep 15, 2019 at 01:16:50PM +0200, Peter Bex wrote:
> > On Sun, Aug 25, 2019 at 04:34:02PM +0200, Peter Bex wrote:
> > > On Sat, Jul 20, 2019 at 11:51:28AM +0300, megane wrote:
> > > > Here's a new patch that drops the (not captured) check.
> > >
> > > Thanks for making that! Now that
> >Left as an exercise to you, dear reader. A singly-linked list is
> >simple and straightforward, I find hash-tables ugly and wasteful
> >and will wory about scalability when the time arrives.
>
> IMHO single linked lists do have one drawback: they encode the assumption
> of a specific from of
>
> So, I'd suggest the attached patch instead. I've also updated NEWS
> to mention the other types we check and remove the comment that the
> fix is partial.
Right, please just apply your patch, if you are ok with my changes. I agree
about the types.
felix
This patch extends 21ff0d6affb35f7184a5e78f9d4beccc869b47b2 to
type-names, inline procedures and constants, giving a warning when
an identifier naming such an entity is exported.
felix
From 069f65ef454be763ac011ec04ff4f1f317eb610a Mon Sep 17 00:00:00 2001
From: felix
Date: Thu, 3 Oct 2019
> 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 course has other implications.
The inline-limit
> call-with-environment-variables
> csv
> csv-xml
> dot-locking
> foof-loop
> hostinfo
> pathname-expand
> ports
> regex-case
> rpc
> s11n
> sparse-vectors
> srfi-12
> srfi-19
> tcp
Dot-locking, regex-case and s11n have been ported.
felix
___
Hi!
I noticed long pauses when pushing git commits or committing to svn.
A git push gives me:
pushing to ssh://chic...@call-cc.org/usr/local/repos/chicken-core.git
remote:
remote: Error: (tcp-connect) cannot create socket - Connection timed out
remote:
remote: Call history:
> NOTE: Aside from the effort in porting the code there are still a few
> dependencies on eggs that have not been ported. Triming dependencies
> may eliminate some of these. A quick crude scan of use statements gave
> me this:
>
> call-with-environment-variables
> csv
> csv-xml
> dot-locking
>
> 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* and the entire picking
> apart of the rest arg list into start/end can be completely
Hi!
Sorry, one of the previous patches was broken (thanks to megane
for pointing this out). Here is an updated version.
felix
From c7744fae69b314f1eaf68b2b60de3e90d4cad264 Mon Sep 17 00:00:00 2001
From: felix
Date: Wed, 18 Sep 2019 14:59:51 +0200
Subject: [PATCH] Revert "Revert half of "Add
Hi!
Attached is a revert of the recently reverted patch for folding some
inline-expressions which caused #1648 and another patch
addressing the OOM error when compiling uri-generic.
The problem is that the optimizer does not catch runaway inlining
of recursive procedures, somehow this case never
> On Wed, Aug 28, 2019 at 01:41:22PM +0200, felix.winkelm...@bevuta.com wrote:
> > An attempt to fix #1645. See commit message for more details.
>
> Hi Felix,
>
> I've taken a look at it and the logic itself looks good, but I find the
> usage of fluid-let on a global variable unsettling. Why not
This patch replaces the use of C_u_i_zerop with an inline variant.
The new version has been renamed for binary compatibility, the
old version is deprecated.
felixFrom 8cccbba869209e62f9afbd693e12676ee34400cb Mon Sep 17 00:00:00 2001
From: felix
Date: Thu, 6 Dec 2018 23:21:35 +0100
Subject:
The attached patch adds two optimization rules for certain uses of
##core#inline. It basically rewrites
(let (( (##core#inline ...)))
( ... ...))
into
( ... (##core##inline ...) ...)
plus a variation on this. Removing the intermediate "let" form gives
more opportunities to merge
> Hi Lassi,
>
> On 2019-08-29 15:51, Lassi Kortela wrote:
> > How much work would it be to support R7RS .sld imports, such that
> >
> > (import (foo bar baz))
> >
> > loads a (define-library ...) form from "{root}/foo/bar/baz.sld" for the
> > first matching {root} in the load path? This
An attempt to fix #1645. See commit message for more details.
felix
From a0a8eed96e06520c996a8ee3965eae5aa80c655b Mon Sep 17 00:00:00 2001
From: felix
Date: Wed, 28 Aug 2019 13:37:16 +0200
Subject: [PATCH] Catch self-referencing variables in `letrec' form
"(letrec ((x x)) ...)" results in and
This patch wraps uses of ##sys#register-compiuled-module in a form
that preserves the syntactic environment. Otherwise import ed identifers
leak into the global namespace. See #1548.
felix
From 743be862e89375e46fa69b244d4dea4495fa5591 Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 25 Aug 2019
See #1346.
cheers,
felix
From 717257249d8f4ae5abe0e98380855d81ea7e37ea Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 25 Aug 2019 12:23:05 +0200
Subject: [PATCH] Disallow exporting variables defined with define-external
When finalizing modules, explicitly check in compiled code whether
the
Thanks, pushed.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
> So, this patch marks the procedure deprecated and replaces the remaining
> few uses in core by the equivalent new ##sys#check-fixnum or removed
> them altogether because where it was used, it was often followed
> by ##sys#check-range, which already does a fixnum type check.
Could you list
Hi!
I tested this with standalone files and with a very basic egg and
everything seems to be right. More advanced use should be
tested (I understand that Kooda has a more sophisticated use case -
it would be interesting to see if this works as it should), but the
basic concept and the
Hi, there!
There definitely is something wrong on arm, but it turrns out to be hard
to reproduce, and seems like a memory-related heisenbug to me.
Can you try this test program for me?
---
(import chicken.locative chicken.gc srfi-4)
(define old (u32vector 0 1 2 4294967294 4294967295))
(define
> That seems totally right to me.
>
I wholeheartily disagree.
> On Sun, Jul 28, 2019 at 1:06 AM Evan Hanson wrote:
>
> > Thanks Peter, applied.
> >
> > On Sat, Jun 29, 2019 at 03:26:54PM +0200, Peter Bex wrote:
> > > I'm not happy with the hacky way the reader deals with these, but I could
>
> Hello Felix,
> I'm contacting you about Chicken 5.1.0 and armel architecture.
>
> Some days ago I uploaded the amd64 package to Debian unstable,
> so our porting teams could recompile it on every architecture that
> Debian supports; unfortunately the build process didn't go well
> everywhere,
> The the way things are done in the current version of Chicken is wonky
> because the outline is like this:
>
>child = fork();
>if (!child) {
>// This code runs in the child process.
>execve(exefile, argv, envp);
>// Not only is the errno
> I would make an exception for pkg-config because it is:
>
> 1) almost ubiquitous
> 2) extremely simple
> 3) quite uncontroversial (essentially .ini files listing the same flags
> we'd be passing to compilers anyway, but in a standard format)
I can't comment on that, I don't know enough about
> Hi,
>
> Anybody up for hashing out a design for built-in pkg-config support in
> the egg infrastructure?
>
> I suggested this on Tuesday on the chicken-users list but didn't yet get
> any feedback. Preliminary thoughts at the bottom of this mail:
>
> I also made a small tweak to the tests, the assertion was obviously
> incorrect. You were probably testing something for failure and
> accidentally committed that?
Just a stupid mistake on my side - thanks for fixing this.
felix
___
Hello!
Please ignore the previous patch for #1630, here is an augmented
one, removing an additional compile-time check.This also adds
a test case, kindly provided by megane.
felix
From c3982889e5520aaa9a9a8553d74237f2279a9b11 Mon Sep 17 00:00:00 2001
From: felix
Date: Tue, 9 Jul 2019 13:36:40
Hi!
See commit message, this is intended to fix #1630.
felix
From 690b2961c81cf000d7782a0cd0c735eb65f85936 Mon Sep 17 00:00:00 2001
From: felix
Date: Tue, 9 Jul 2019 13:36:40 +0200
Subject: [PATCH] when contracting/inlining procedure calls, catch
argument-list mismatch.
Previously a mismatch
> I had a look at #1620 and as far as I can tell there's no reason why
> an aliased variable cannot be marked as replaceable when either the
> alias or the variable it aliases are captured.
>
> Captured simply means that it needs to be wrapped up in the closure,
> AFAIK. But if it's replaced,
> On Sun, Jun 30, 2019 at 11:33:17AM -0400, John Cowan wrote:
> > Obviously this is not something you can do in a patch,
> > but at some point Chicken may want to go
> > over to the assignment conversion strategy, in which all mutable
> > local variables are transformed into immutable references
This patch addresses the problem reported by Sven Hartrumpf
(#1624).
felix
From 41bf17c22a5b68e537d041b11b15f42d4b53dd88 Mon Sep 17 00:00:00 2001
From: felix
Date: Tue, 25 Jun 2019 22:51:20 +0200
Subject: [PATCH] Fix lfa2 type analysis for conditionals.
Merge the types of the branches of
> Hi all,
>
> We've seen quite a bit of breakage with the CR patch. Most of it has
> been fixed by aeec82d, but it also uncovered another bug that has been
> there since the beginning. Eggs using srfi-128 fail, see for example:
>
> On Sun, May 26, 2019 at 09:05:37PM +0200, felix.winkelm...@bevuta.com wrote:
> > >
> > > The attached patch ensures we write such identifiers as |:type-tests:|
> > > regardless of keyword style. This way, it can also be read by any
> > > program, even if it uses a different keyword style than
>
> The attached patch ensures we write such identifiers as |:type-tests:|
> regardless of keyword style. This way, it can also be read by any
> program, even if it uses a different keyword style than the writer.
>
Ugh... How ugly. Is there no way around this? The "|" are only necessary
in
> Note that Wasamasa pointed out on IRC that we still need to add -feature
> to chicken-install, which ties in nicely with cond-expand (see
> https://bugs.call-cc.org/ticket/1617)
Isn't this already the case? (f701e594dd59b8ab4dc04d340e81440f84ae5d9a)
felix
> > Interprocedural flow-analysis is hard, we shouldn't underestimate
> > this. What happens when we declare a type for a toplevel function?
>
> If you're thinking about reassigning globals, how about making
> -fixnum-arithmetic imply -local? If globals cannot be re-defined then
> the types are
> Besides, like I said in the other mail, then we'd still be calling
> allocating functions because (+ fixnum fixnum) => (or fixnum bignum).
> In fixnum mode, we'd want to use the overflowing unsafe fixnum ops.
And I think that is a situation where assuming a specific type is ok,
or at least not
> > Shouldn't the types.db specialization for scheme#= be applied
> > here? Or can't it figure out the ffixnum types of the arguments?
> > Even though it is slightly dangerous, the scrutinizer _could_ assume
> > arguments to numerical primitives are fixnums in fixnum mode...
>
> That's right, the
> Here's what I figured out fwiw:
>
> This is the program from #1604:
>
> (define (fib n)
> (if (or (= n 0) (= n 1))
> n
> (+ (fib (- n 1)) (fib (- n 2)
>
> (time (let loop ((n 0))
> (when (< n 35)
> (fib n)
> (loop (+ n 1)
>
>
> Finally, I ran into this head scratcher: I tried to replace = with eq? in
> the code and it sped up the code by a *lot*. However, in fixnum
> arithmetic mode, = gets rewritten to C_eqp. The difference in the C
> output is that the code that uses eq? directly gets this completely
> inlined in
> To sum up, we could:
>
> 1) Not make this change at all
> 2) Do it anyway in 5.1
> 3) Do it in some later version (but how long do we wait?)
>
> What do the other hackers think? Please, speak up!
>
Well, then let's do it anyway.
felix
___
> On 2019-05-07 7:45, Evan Hanson wrote:
> > On 2019-05-06 13:04, ko...@upyum.com wrote:
> > > I don't think that patch is right. If you emit import libraries from the
> > > static builds, you will not be able to import modules from the evaluator
> > > when the modules are statically linked,
> > One could do that, for example by using 1/3 or 1/4 of the symbol
> > table size.
>
> Attached is a patch to make this so.
>
Thanks, pushed.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
> On Fri, May 03, 2019 at 09:20:15PM +0200, Peter Bex wrote:
> > The diff in synrules.scm fixes that part. I also then changed the
> > binding forms from expand.scm and chicken-syntax to use "variable"
> > instead of "symbol" in their ##sys#check-syntax calls.
>
> Whoops, attached an old version
> Attached patches fix #1576. The first patch should be applied first,
> then you should build CHICKEN via a bootstrap CHICKEN. Then, install
> it and apply the second patch and rebuild again.
Pushed.
> A few minor remaining questions:
>
> - What should the (initial) size of the keyword table
> In scrutinizer, just at the beginning of 'walk' just try different kind
> of optimizations. Like rewrite 19 and the constant folding thing that
> was added recently (which is done in pretty icky place currently). Like
> this:
>
> (try-optimizations node)
> .. continue with normal walk ..
>
>
> In this case I would just move rewrite 19 to happen before scrutiny.
>
> In general, some optimizations like rewrite 19 help the scrutinizer. The
> scrutinizer makes transformations that might enable some optimizations,
> which might help the scrutinizer, ... i.e. "cascading optimizations".
> felix.winkelm...@bevuta.com wrote:
> > Can anybody give details about the coops problem?
>
> From what I can remember, the main problem is not in coops itself, but
> in record-variants, that uses low-level ##sys# procedures to define
> records and doesn’t use the right tags (which don’t work
> To make this code specialize two things are needed:
>
> 1. Infer more specific types for (recursive) functions.
>
> 2. Prove that a function is always called with correct arguments.
>
> If we can do this then we can effectively re-walk the function with the
> arguments assumed to be of the
> On Thu, Apr 11, 2019 at 03:06:07PM +0200, ko...@upyum.com wrote:
> > Peter Bex wrote:
> > > Here's a relatively straightforward patch, which fixes #1581 as we
> > > discussed at SaarCHICKEN.
> >
> > Please don’t apply this patch.
> >
> > The conclusion we arrived to, at SaarCHICKEN, was that
> > I wonder, though, whether all the accessor code
> > wouldn't be more compact using some fat C macros. On the
> > other hand that doesn't help readability much...
>
> Yeah, I considered it but decided against it.
>
Ok,
> The function calls for checking the types could be made inlineable
>
> Hi all,
>
> Here's a reasonably straightforward patch to make XXXvector-ref,
> XXXvector-set!, XXXvector-length and XXXvector? inlineable, as
> per #757. The predicate wasn't really part of the ticket but it
> seemed like a good thing to add (we can use it instead of copy/pasting
> all the
> > Once you give a fixed meaning, even by doing an optimization based
> > on this meaning, users _will_ start to rely on it. At that stage it isn't
> > undefined anymore.
>
> There's two ways I can think of getting warnings, then.
>
> a) Easy version. Randomly choose true or false at each if.
>
> Nothing changes if we statically assign these values, the user still
> cannot rely on undefined to be either true or false.
Once you give a fixed meaning, even by doing an optimization based
on this meaning, users _will_ start to rely on it. At that stage it isn't
undefined anymore.
> >
> > No, but it could, depending on some arcane optimization that someone
> > may implement in the future (or not). It's simply open to the
> > implementation.
> >
>
> There's the possiblity of documenting this optimization:
>
> "If the expression's value can be determined statically to be
> >> Based on my limited observations (##core#undefined) will always have
> >> the value 30L at runtime. This is not equal to 6L (or #f). Therefore
> >> an undefined value in conditional test will always cause the true
> >> branch to be chosen.
> >
> > That's an implementation artefact, (begin)
> And it has to be error, not just a warning. Otherwise the warning just
> flashes by while you're getting some coffee.
That's the point - it is an error under your interpretation only. It's
still perfectly legal code, even if it may not make sense.
> Based on my limited observations
> In my opinion, this is not a good direction for implementations of any
> language
> to go. The Chicken community has been repeatedly bitten by the increasing
> tendency of C compilers to do whatever they want rather than whatever makes
> sense in the context of undefined behavior (the C
> Another change is considering 'undefined' as a truthy value. The
> interpreter considers 'undefined' truthy, too.
Undefined is undefined, we shouldn't make any assumption here.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
> Hi!
>
> Here's a small one.
>
I think the original code is wrong (as this function is never used it
didn't crash so far). We should probably remove this altogether.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
> '(list a123) -> `(list ,(gensym 'a123)), where the symbol a123 is the
> name of the TV. This symbol is used to store a value in the unification
> trail.
Note that you could store the original name on the plist of the gensym,
then deref the chain of gensyms/orig names when printing.
felix
Attached a patch for (hopefully) fixing #1588.
felix
From b0e0d61308e48335af7125f0a4b42f3706b8b359 Mon Sep 17 00:00:00 2001
From: felix
Date: Mon, 18 Mar 2019 12:06:39 +0100
Subject: [PATCH] chicken-install: fix double quoting
The custom build command for several component target build scripts
> I've just pushed most of these patches, with signoffs, to a branch
> called "scrutiny-message-formatting", and I think we should merge it.
I have merged the branch into master.
The messages are nice, but may be a bit over the top, regarding
verbosity. Still, it is an improvement.
felix
> Hi folks,
>
> I've just pushed most of these patches, with signoffs, to a branch
> called "scrutiny-message-formatting", and I think we should merge it.
Thanks for doing this, I've ran the tests and so far things look good.
I'm a bit concerned about the verbosity of the warnings. For
> Hi all,
>
> Here's a tiny patch that makes the debug server end the program when a
> client disconnects unexpectedly, i.e. without first sending a terminate
> signal. Currently, the program will instead go into an infinite loop and
> burn 100% of a CPU until it's killed.
>
Pushed. Thanks,
> On Tue, Mar 05, 2019 at 09:03:14PM +0100, felix.winkelm...@bevuta.com wrote:
> > It's called EX_SOFTWARE, see .
>
> I found it, but I don't quite understand when one would return EX_SOFTWARE
> rather than 1 on error. If it should stay this way the manpage needs to
> be tweaked, though; it's
> On Thu, Feb 28, 2019 at 02:06:33PM +0100, felix.winkelm...@bevuta.com wrote:
> > Here are two patches addressing comments and suggestions by
> > megane.
>
> I've applied these and pushed, but I'm wondering why the exit status on
> error is 70 here.
>
> Basically:
>
> $ csi -e '(error "foo")'
>
> I might have found an issue here. There doesn’t seem to be a way to locate
> the installed files after you’ve installed them into your install prefix.
>[...]
>
> Although this isn’t widespread, it seems odd to have a property that is
> write-only. Clearly, it is possible to check
> I agree also given the existence of complex demotion in Chicken, whereby
> (make-rectangular 1.0 0.0) => (the flonum 1.0). On the other hand, I think
> complex demotion is actually a Bad Thing because it means that inexactness
> in the computation of the imaginary part can make an inexact
> On Thu, Feb 28, 2019 at 02:25:33PM -0500, John Cowan wrote:
> > See the ticket for explanations.
>
> After discussing on IRC, I'm not sure I believe this is correct.
> Given that we don't support complex numbers of mixed exactness, it
> makes more sense to return 0.0 for the imaginary part of a
Here are two patches addressing comments and suggestions by
megane.
felix
From 652446a34d51f0bcb7f9b05300228e6ad7305237 Mon Sep 17 00:00:00 2001
From: felix
Date: Thu, 28 Feb 2019 14:02:12 +0100
Subject: [PATCH] chicken-install: exit with status 3 if no eggs are processed
Suggested by megane.
> It turns out that here (and also in open-input-file*), keywords are
> supposed to be accepted to control the file mode. These are written
> as qualified symbols with no namespace (###text and ###append), which
> used to read the same as keywords. This is more of an accident than
> by design,
> When porting chickadee to Chicken 5, I hit a roadblock when installing data
> files into a namespaced directory — /share/chicken/chickadee.
>
> In Chicken 4, we can execute code in .setup to obtain this directory —
> (make-pathname (chicken-home) "chickadee”) — and use copy-file. In Chicken
> I don't think this change fixes the example you gave as a "certain
> strange combination" in ticket #1572, i.e. (#! (foo bar)). ISTM that
> happens because any whitespace after a "#!" token causes the reader to
> skip everything until the end of the line (and the same goes for a
> forward
> On Wed, Jan 09, 2019 at 05:06:00PM +0100, felix.winkelm...@bevuta.com wrote:
> > > If everyone is okay with this, I can try to find some time to do it
> > > this weekend.
> >
> > Sounds good. Attached are the signed-off patches.
>
> Thanks, I've published the snapshot and updated the
> > It would probably be safer if you apply #1 locally, publish a
> > snapshot and push after that, with an updated scripts/bootstrap.sh
> > (I'm not totally sure - this is all somewhat confusing...).
>
> You're probably right. I don't even know if the dev snapshots script
> still functions for
Hi!
Seems to work fine. I applied patch #1, built, installed, ran
"make check", built a boot-chicken, applied #2, built with the new
boot-chicken, installed, ran "make check" and
"chicken-install -v -test awful", with no apparent problems.
It would probably be safer if you apply #1 locally,
> Hello, here's a fix for a bug I encountered while testing Felix's recent
> patch on Windows.
>
> The buffer used for the command line executed by chicken-do had size
> MAX_PATH, but that's quite short (only 260) so the program would almost
> always write beyond it and into the locals passed to
Here an amended patch, using "a" as library extension, exclusively.
felix
From f2af40a83fd7b8ac719622cf1b95f9c8198587a4 Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 9 Dec 2018 13:20:00 +0100
Subject: [PATCH] Add c-objects component type to egg format.
- adds component type "c-object"
-
> I've tried this on Windows and there's just one issue: the patch uses
> the ".lib" file extension for archive files on Windows, and ".a" on
> other platforms (csc.scm:106). However, we currently build the static
> version of the CHICKEN library as "libchicken.a" on all platforms, so
> when you
I wish all CHICKEN -users, -hackers,- janitors, -meisters, -lovers and -haters
a very happy christmas. Take care of yourself and keep your parentheses
in shape.
felix
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
201 - 300 of 826 matches
Mail list logo
