> Another attempt at fixing #1835, hopefully this time for good.
>
> Adds a +1 to each paramter string's length, to permit starting to compare at
> end of string, and corresponding tests.
>
> The errors I experienced in csi were caused by a bug in the breadline egg.
> Will share a patch with
> Hi all,
>
> Here's a patch to bring irregex in line with upstream 0.9.11 (plus one
> more commit that fixes a bug in sre->string). It would be nice to have
> that for 5.4.0.
>
> Not that much changed in this release, but a lot of code was
> restructured, so it would make it easier to port
> Hi,
>
> On Mon, 15 Apr 2024 12:50:44 +0200 felix.winkelm...@bevuta.com wrote:
>
> > This patch addresses #1823, which was caused by an off-by-one error
> > in the check of the end-index, which is exclusive. Thanks to "siiky" for
> > reporting this.
>
> Thanks siiky and Felix. I've pushed the
> *facepalm* fixed a bug, created another... Ran the utf8 egg's tests, all
> passed.
>
> Thanks felix, and sorry about that.
There is no need to be sorry - I had the same situation myself in a different
context. Also, R7RS is not very explicit about inclusiveness of bounds (R5RS
is, but
R7RS
This patch addresses #1823, which was caused by an off-by-one error
in the check of the end-index, which is exclusive. Thanks to "siiky" for
reporting this.
felix
From 8e29a4332873ea4cbb98c8847bd5648033b79ae9 Mon Sep 17 00:00:00 2001
From: felix
Date: Mon, 15 Apr 2024 12:48:23 +0200
Subject:
Thanks! A signed off copy is attached (waiting for another chicken-hacker
to approve).
cheers,
felix
From 7c4e7e84ddcc20e262b1aa15eef25c8133f63a7e Mon Sep 17 00:00:00 2001
From: felix
Date: Mon, 11 Mar 2024 12:15:44 +0100
Subject: [PATCH] Because the `start1`/`start2`/`n` parameters were not
> Hi,
>
> here's a patch (against ^/release/5/matchable/trunk) to update the
> matchable egg to the upstream version at
> https://synthcode.com/scheme/match.scm
>
> The upstream match.scm requires (keyword?) which is where the diff to
> matchable.scm comes from.
>
> chicken-install -test is fine
Hi!
See commit message. Reported by "Reid" on IRC.
felix
From 7d5ff4dec308236c54f188689ed0d5e74de82a6b Mon Sep 17 00:00:00 2001
From: felix
Date: Sat, 27 Jan 2024 23:36:35 +0100
Subject: [PATCH] Including forms must preserve ##sys#current-source-filename
Found by "Reid": invocation of "k" in
Attached a patch fixing a wrong timeout-calculation/check, discovered by
"dzoe".
felix
From c581a08e3b1781840f39e63c2d2b986496912a50 Mon Sep 17 00:00:00 2001
From: felix
Date: Tue, 23 Jan 2024 13:36:59 +0100
Subject: [PATCH] make file-select actually reflect what it is supposed to do
(thanks
Currently "chicken-home" can be used to obtain the location for
sundry "data" files installed by eggs and usually required at runtime.
This location may need to be changed when installing eggs into
custom locations or when a CHICKEN installation via package
manager uses a non-writable directory.
This patch addresses the problem reported recently my Mario, regarding
failing compilation of http-client.
The problem was that compiler-syntax definitions changed the "override"
status and disabled the existing value binding.
felix
From d11d8636218104fa4a6d92bc21b5bc1e7b91f2b0 Mon Sep 17
> Hi,
>
> The attached patch adds errno to condition objects produced by
> procedures that change it.
>
Pushed!
felix
> Hi,
>
> The attached patch is a follow-up to the fix for
> http://bugs.call-cc.org/ticket/1753
>
> 2f6a72211e37 works around the problem by adding an underscore as a
> prefix to the cache metadata files (VERSION, TIMESTAMP and STATUS).
> While the new names tend to be a bit more unusual than the
> Hi,
>
> Attached is a patch to fix an issue (#1830) affecting
> create-temporary-{file,directory} in cases where the environment
> variables they use to determine the directory where temporary
> files/directories are created get changed.
>
> Please see the commit message and
> Yes, this is precisely my point - 'one or more'. The string-length with
> invalid embedded sequences is not guaranteed to be consistent, which seems
> like a problem. Doing a decode to ensure all points are valid - even if in
> the undefined sequences - seems to be a good idea to prevent
> Question: if there is no translation at all, won't the invalid chars cause
> issues with things like string-length and string-copy procs? That is, since
> the number of octets can't be correctly translated to a number of glyphs,
> there will be some unpleasant side effects.
Converting a
> From the unicode-transition page:
>
> The strategy that I favor in the moment is to handle all string data
> > injected into the system transparently, the actual bytes are unchanged and
> > unexpected UTF-8 bytes are decoded and marked as a U+DC80 - U+DCFF (low,
> > trailing) UTF-16 surrogate
> On Sun, Nov 12, 2023 at 01:45:06PM +0100, felix.winkelm...@bevuta.com wrote:
> > See commit message.
>
> Nice to make some progress on this!
>
> However, I tested the example given in the ticket:
>
> (define begin -)
> (begin 0 1) => 1 ;; expected: -1
>
> This still evaluates to 1.
>
See commit message.
cheers,
felix
From 5f98b32ec8103c5b6efed4da3301c1d02e29b202 Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 12 Nov 2023 13:39:10 +0100
Subject: [PATCH] Retain current identifier status as syntax or value binding
Currently, toplevel value- and macro-bindings for an
> Hi,
>
> The attached patches minimize the risk of reusing object files in the
> chicken-install cache by different, possibly incompatible, CHICKEN
> versions/builds.
>
> The first patch ("chicken-install: Reset egg cache when status file does
> not exist") deals with renaming of the so-called
The attached patch addresses an endless expander loop while compiling
the transducers egg. The egg uses unconvential (and only slightly legal)
alias identifiers that confuse the expander, combined with a recent
change in how it resolves macros in bodies. The problem was reported by
Mario and
> On Wed, Nov 08, 2023 at 02:59:17PM +0100, felix.winkelm...@bevuta.com wrote:
> > Attached is a patch to address #1492.
>
> Applied. Do we want to turn this into an error for CHICKEN 6?
> Warnings have a tendency of just scrolling by and getting lost in the
> noise of compiler output.
Thanks.
See commit message.
felix
From 9429d011b690372254bfc35ac6095c8a2dcd8c61 Mon Sep 17 00:00:00 2001
From: felix
Date: Fri, 10 Nov 2023 11:21:51 +0100
Subject: [PATCH] Resolve macro-aliases for static evaluation environments
(#1295)
When evaluating forms in a "static" environment, identifiers are
Attached is a patch to address #1492.
felix
From 37b8de2f956c36a311c5162dbdbc8af631a9bc59 Mon Sep 17 00:00:00 2001
From: felix
Date: Wed, 8 Nov 2023 14:52:15 +0100
Subject: [PATCH] Warn if processing egg property in wrong context (#1492)
---
egg-compile.scm | 17 +++--
1 file
> On Wed, Nov 08, 2023 at 12:34:23PM +0100, felix.winkelm...@bevuta.com wrote:
> > See commit message.
>
> Shouldn't we modify the test instead of dropping it?
>
> Something like this:
>
> (module m3 ()
> (import (rename scheme (define s:define)))
> (import (only (chicken base) assert))
>
See commit message.
felix
From bd0f5bc81207a3ec82995e13c8a470fc3ab9e1a0 Mon Sep 17 00:00:00 2001
From: felix
Date: Wed, 8 Nov 2023 12:26:38 +0100
Subject: [PATCH] Detect redefinitions of defining forms correctly (#1132)
The scanning for local definitions in ##sys#canonicalize-body used
what I
> Howdy,
>
> Thanks for all the work!
>
> Is it safe to install under the same prefix next to the regular C5
> install (using a "6" suffix or something)? E.g. will eggs be installed
> under $PREFIX/lib/chicken/12/ (rather than 11)?
>
That should be the case, yes. Note that this all is very
Hi!
I have recently put some effort into working towards support of full unicode
and
R7RS compliance, as preparatory work for the next major release of CHICKEN. See
http://wiki.call-cc.org/chicken-6-roadmap
for details and the current status, in particular with respect to
Hi, Pietro!
Very nice. I'm on the road right now, but will take a deeper look at
this in the next days. Thanks!
cheers,
felix
> I'd prefer if we could develop this a bit further to make the rename
> form accessible to module as well.
Sure. I personally never felt the need for rename on export and
wanted to add this just as a base to build R7RS support on.
Bindings and aliases are so easily done in Scheme that it
> Maybe this already works with the current patch, but can we support:
>
> (export (rename foo bar))
>
> As well as the version with the colon (suffix keyword notation) on the end of
> export?
> Seems like that would be best for symmetry with the import form.
>
> (Sorry, it’s just
> On Mon, Oct 02, 2023 at 06:31:44PM +0200, felix.winkelm...@bevuta.com wrote:
> > This patch adds a new special form to explicitly export renamed bindings
> > from a module:
> >
> > (export/rename (OLD NEW) ...)
>
> Why not add it to the regular "export" form? It's already extendable,
>
This patch adds a new special form to explicitly export renamed bindings
from a module:
(export/rename (OLD NEW) ...)
This is mainly useful for supporting R7RS renaming export specifiers (not
done yet).
I wanted first to apply the renamings when creating the module structure,
but it
> Yes, that's what I mean. It would be fine if foo/bar.sld and foo.bar.scm
> would accept either `library` or `define-library`.
>
You mean "module" or "define-library", I guess? One could make the
latter available by default. Depending on how we decide on default
semantics for syntax-rules,
> Hi all,
>
> the attached patch makes the `(or)` type specifier invalid, as opposed
> to being simplified to `*`.
> This is more consistent with the mathematical interpretation of an empty
> (sum) type being the bottom type having no inhabitants.
> This is very explicit in OCaml, for example,
> It certainly shouldn't be *, nor should it be an error... technically an
> empty union should be a null set, which would correspond to either a
> non-extant type or to no return/value at all...
Well, the problem is: there is no non-extant type, no "bottom": we simply use
the Scheme type
> I think making r7 syntax by default makes sense as does define- library.
> Using sld would be good if (foo bar) imported from foo/bar.sld and not
> foo.bar.scm.
>
How is supposed to be coded? Would that mean foo/bar.sld holds
a library definition of this sort:
(define-library (foo bar)
Hello!
John Cowan suggested to add R7RS support to the CHICKEN core
in the forthcoming version 6. It certainly is about time to
commit a bit more to R7RS (small), since it is, as a standard,
reasonably established now. The current mode of support as an
egg works quite well, but still feels a
> On Wed, Aug 16, 2023 at 05:25:45PM +0200, felix.winkelm...@bevuta.com wrote:
> > > Why are install-path and repo-path in chicken-install.scm still using
> > > destination-repository instead of effective-destination-repository?
> > > Those are the only places that still use it, aside from one in
> Why are install-path and repo-path in chicken-install.scm still using
> destination-repository instead of effective-destination-repository?
> Those are the only places that still use it, aside from one in
> chicken-status and chicken-uninstall.
The prefix variable is only used for designating
> I think here we're struggling with the atomicity of the garbage collector
> because the finaliser is special user code that executes inside the garbage
> collector's "transaction" and that code has all the power and capabilities
> of any other scheme code.
Finalizer code is in no way
> On Fri, Jul 21, 2023 at 03:54:41PM +0200, felix.winkelm...@bevuta.com wrote:
> > diff --git a/egg-compile.scm b/egg-compile.scm
> > index 99a94fe8..b14535da 100644
> > --- a/egg-compile.scm
> > +++ b/egg-compile.scm
> > @@ -412,7 +420,7 @@
> > (define (compile-common info walk)
> >
Hi!
In complex build environments it is sometimes desirable to overriding
where "chicken-install" places programs, include- and data files, for
example when packaging. Currently it is possible to set
CHICKEN_INSTALL_REPOSITORY
to set where extensions are placed and in combination with
> On Fri, Jul 07, 2023 at 10:43:29AM +0200, felix.winkelm...@bevuta.com wrote:
> > Here another attempt at a finalizer API, allowing adding
> > finalized objects to an existing finalizer after it was
> > created.
>
> Thanks, I've pushed both this and the srfi 18 changes.
> Should we tag a new
> Regarding the situation of the infrastructure:
>
> * call-cc.org's cache has been fixed (i.e., monocypher 4.0.1-0 has been
> removed, and 4.0.1 has been cached -- contents should be identical).
> monocypher can be installed from there.
>
> * kitten-techs' cache at the time of this writing
The attached patch fixes a problem with chicken-install that caused eggs
transmitted via HTTP to be rejected due to a malformed version number.
Specifically, "-" was not allowed inside version numbers, and the monocypher
egg seemed to be the first one using such a versioning scheme.
The patch
Pushed. I pushed another commit to handle bwp immediates
introduced during compilation, without this compiling the weak-pointer-test
failed for me.
felix
After thinking some more about this, I realize that your approach
(clearing weak ref's to finalized data) is the right thing, since
any other behaviour in the presence of multithreading leads to
disaster.
Let me elaborate.
Finalization is a time of reckoning, a purgatory where an object
> However, there's one more concern:
>
> > The potential use-after-free scenario can still happen if the object is
> > kept alive, regardless of how we handle weak refs, this is unavoidable
> > if we allow finalizers and keep the possibility of resurrection.
>
> I have thought about this a bit
> On Thu, Jul 06, 2023 at 09:05:03PM +0200, felix.winkelm...@bevuta.com wrote:
> > > This would be problematic if the finalizer has run and deleted the
> > > foreign object, while there are still weak references that hold onto
> > > the object. This has then become invalid/inconsistent.
> >
> > I
> While working on this, I also noticed a remaining bug in the weak locative
> handling: when a locative has already been cleared, it contains a NULL
> pointer, and we need to avoid dereferencing it on the next GC.
Thanks, pushed.
felix
Here another attempt at a finalizer API, allowing adding
finalized objects to an existing finalizer after it was
created.
felix
From 89b181be98685943425aae646ee724e9d59a2bec Mon Sep 17 00:00:00 2001
From: felix
Date: Fri, 7 Jul 2023 10:40:58 +0200
Subject: [PATCH] Added thread-safe finalization
> On Wed, Jul 05, 2023 at 03:28:54PM +0200, felix.winkelm...@bevuta.com wrote:
> > The first patch provides the event-queue mechanism and cleans up the
> > scheduler a bit (hiding internal variables while also exposing ##sys#...
> > procedures to access them). This also defines hooks that a
> Perhaps simply we can just return two values? The first a polling
> procedure and the second a procedure to add new objects to the
> finalizer? You can just receive the polling procedure in a
> single-value context and ignore the object-adder if you don't want
> to use it.
That was also my
> On Wed, Jul 05, 2023 at 03:28:54PM +0200, felix.winkelm...@bevuta.com wrote:
> > The first patch provides the event-queue mechanism and cleans up the
> > scheduler a bit (hiding internal variables while also exposing ##sys#...
> > procedures to access them). This also defines hooks that a
Reported by "siiky": numeric egg versions could result in failed
calls to "make-pathname".
felix
From d078a4249fb29cb981b5ea4771de1cbf151c8aed Mon Sep 17 00:00:00 2001
From: felix
Date: Wed, 5 Jul 2023 19:26:19 +0200
Subject: [PATCH] handle numeric version properly when constructing egg paths
Reported by "acdw": make "tail?" more robust. Also generalizes
it to accept all types of data, remove unneeded fast path expecting
proper list argument.
felix
From dfffba54fb25bec0faa80127ed43fa3fd7cd4541 Mon Sep 17 00:00:00 2001
From: felix
Date: Wed, 5 Jul 2023 19:25:04 +0200
Subject: [PATCH]
Hello!
Currently we have no thread-safe way of handling asynchronous events
like POSIX signals and finalization. In both situations, the signal
handler and finalization procedures are called in whatever thread
is currently executing, which is a source of potential deadlocks
in a multithreaded
> Hi there,
>
> The attached patch fixes a small but important oversight in
> get-call-chain. With this patch, the "trace" egg's tests pass again.
>
Pushed.
felix
> Hi all,
>
> I was checking the Salmonella results and it seems a good number of eggs
> are actually relying on chicken.compiler.support#read/source-info and
> therefore break with the current master:
> http://salmonella-linux-x86.call-cc.org/master/clang/linux/x86/2023/06/28/yesterday-diff/
>
>
> Hi all,
>
> Here's a patch to replace the locative table with the same approach we
> use for weak pair tracking. Not much to say, the idea is simple, the
> patch a bit bigger (because it rips out the locative table).
Thanks a lot, Peter! Signed off and pushed.
felix
Merged and pushed. Excellent work, as usual.
Please let me point out how extremely well structured and documented these
changes are. Well done, Peter.
cheers,
felix
> > As Peter remarks, this code is too hairy. I added a comment trying
> > to explain the reason for this.
>
> Thanks for adding a bit of explanation. Are the lists really that long
> though? I'd expect this syntax to be used only in user-typed literals,
> not in data to be read in.
I was
> Hi all,
>
> I noticed that the interpreter got quite a bit slower due to fetching
> the line number information for an expression when emitting info into
> the trace buffer. Attached is an additional patch to bring things back
> to our original performance by pre-fetching the line number info
Hi!
Attached a patch to fix some problems with the newly introduced
extension to SRFI-4 vector read syntax. "Siiky" pointed out a bogus
empty string comparison and further testing showed that empty strings
were not handled properly in certain situations.
As Peter remarks, this code is too hairy.
> On Wed, Jun 07, 2023 at 09:12:51PM +0200, felix.winkelm...@bevuta.com wrote:
> > This patch allows strings and chars in homogenous number vectors,
> > as suggested by klm at the meetup.
>
> Code is a bit hairy, but seems to work. Pushed!
>
Actually, too Hairy. As pointed out by "siiky", the
> Attached are 5 patches to add the weak pair support. I've also pushed
> this to the git repo under the "user-facing-weak-pairs" branch.
This branch has been merged into master. Thanks a lot for this excellent
piece of work, Peter!
cheers,
felix
Attached patch fixes a segfault when trying to describe a brokwn weak
ptr. I also added a clause in the case construct to dispatch on a
described value to catch unknown immediate values instead of crashing
in the locative test (which expects block values).
felix
From
Well done, Peter!
I will review the patches and do some tests and then we can decide when
to integrate this.
felix
This patch allows strings and chars in homogenous number vectors,
as suggested by klm at the meetup.
felix
From ce2026c3d7cb08d5f88d006cc13dfec3b1f3e4bd Mon Sep 17 00:00:00 2001
From: felix
Date: Wed, 7 Jun 2023 20:20:08 +0200
Subject: [PATCH] Allow string and character literals in SRFI-4
> On Tue, Jun 06, 2023 at 07:46:10PM +0200, felix.winkelm...@bevuta.com wrote:
> > > Do we even want to make a 5.4 release at all?
> >
> > I would suggest to add this for 5.4, for the reasons you
> > state. I also would be for making at least one minor release
> > before C6, as I doubt that we
> On Sat, Jun 03, 2023 at 11:12:40PM +0200, Peter Bex wrote:
> > Dear hackers,
> >
> > At the Village CHICKENs event, I gave a presentation about how we could
> > add "proper" support for weak pairs, so that they can be exposed to the
> > user. Right now we have half-baked support for weak pairs
Hi!
Kristian Lein-Mathisen suggested an extension to the bytevector syntax
for SRFI-4 and R7RS bytevectors (which becomes more relevant in the
forthcoming UTF-aware CHICKEN) which seems quite practical. I'd be
eager to know how useful other users consider this feature before I
submit a patch.
> Dear Maintainers,
> Attached you find a change-set adding the hyperbolic functions (sinh, cosh,
> tanh) and inverse hyperbolic functions (asking, cosh, atanh) to the included
> (chicken flonum) module. This implementations follows the trigonometric
> function using the math library calls. I
> Hi there,
>
> Earlier today I went in circles trying to figure out why a child process
> was only getting the basename of the executable in argv[0], rather than
> the pathname I was passing.
>
> Turns out we do that when building the arguments to execvp, but I don't
> think it's ideal, so here's
> Here's a patch that adds a .gitignore file at the root of the
> chicken-core repo, so that `git status` doesn't show generated files
> that are not supposed to be committed to the repo.
>
> It doesn't seem possible to ignore *.import.scm wholesale since a few of
> those files are committed:
>
>
> On Tue, Mar 14, 2023 at 08:43:52AM +0100, Peter Bex wrote:
> > On Tue, Mar 14, 2023 at 08:40:18AM +0100, felix.winkelm...@bevuta.com wrote:
> > > Backwards compatibility is from now on fucked anyway, so let's
> > > try to find somethin simple and sensible.
> >
> > Then we should do both. I.e.,
> Of course. In fact, I think it would make more sense to simply tell the
> runtime options parser to stop after the first non-"-:"-prefixed
> argument. That makes runtime argument stuffing harder and allows it
> to play nice with _any_ option parser, and makes the "--" behaviour
> automatically
> Perhaps the safest here is to stop processing after reading ":-"
> or some such (and discard it!) - that would be guaranteed to never
> pass through to the program anyway, because it might be a runtime
> option and already gets intercepted by the option parser.
>
As an afterthought: I find that
> On Mon, Mar 13, 2023 at 10:37:30AM +0100, felix.winkelm...@bevuta.com wrote:
> > Another problem with run-time option processing pointed out by
> > florz. This allows passing arguments that look like run-time
> > options, when preceded by "--".
>
> This needs more thought - simply adding "--" to
Another problem with run-time option processing pointed out by
florz. This allows passing arguments that look like run-time
options, when preceded by "--".
felix
From fae3f9ddeabccae4851ff451fb2aaf05a02e44e3 Mon Sep 17 00:00:00 2001
From: felix
Date: Mon, 13 Mar 2023 10:35:32 +0100
Subject:
As rightly pointed out by florz and others, the "b" (break on
repl) offers a potential security vulnerability by allowing
code from stdin to be interpreted. This patch simply removes
the option, as it doesn't seem to be widely used, anyway.
felix
From 2b34dfb2708b04bfdce0831afd2ec4c4d1eca0ff Mon
> Hi,
>
> Please find attached patches to [hopefully] improve the usability of
> chicken-install.
>
Pushed, thanks!
felix
See attached patch.
felix
From fc4b142bfd889e4c1b7157a7691836eeed344f7f Mon Sep 17 00:00:00 2001
From: Felix Winkelmann
Date: Fri, 3 Mar 2023 00:07:19 +0100
Subject: [PATCH] Added option to csc to disable runtime option processing
---
NEWS | 2 ++
chicken.h
Hi!
Originally reported by Mario, recently also noticed on #chicken.
See commit message, fixes #1684.
felix
From 9ce41a3a5601d3564c0aaa0c2fcf1a1c2a0e9066 Mon Sep 17 00:00:00 2001
From: felix
Date: Thu, 22 Dec 2022 22:05:01 +0100
Subject: [PATCH] Respect component-dependencies in build rules.
> Attached is a patch that hopefully improves the usability of
> chicken-install in "offline" mode (i.e., fetching eggs from a local
> directory instead of egg servers).
>
Pushed, thanks!
felix
Hello!
Vasilij found a security issue with the way egg-information
files are created during installation of an extension package.
Currently, escape characters in the .egg file may be used to
perform arbitrary OS command injection due to the method the
egg metadata is created and installed in the
The attached patch was contributed by Vassilij. See #1800.
felix
From f48e2f68037d36abd2628605dd8c906c5b106556 Mon Sep 17 00:00:00 2001
From: Vasilij Schneidermann
Date: Tue, 1 Nov 2022 20:23:59 +0100
Subject: [PATCH] Split up potentially long echo invocation on win32
Eggs with a very long
> On Mon, Oct 31, 2022 at 05:46:55PM +0100, felix.winkelm...@bevuta.com wrote:
> > Thanks, pushed. I had to hand-apply the patch as git-am didn't like it. I
> > also
> > fixed a scrutinizer warning.
>
> I suppose the warning was about target-librarian-options not being a
> list? Unfortunately,
> On Sun, Oct 30, 2022 at 02:46:49PM +0100, felix.winkelm...@bevuta.com wrote:
> > Another follow-up patch on the recent change of quoting in chicken-install,
> > which causes
> > chicken-do to always fire (and thus rebuilding any egg, regardless of
> > status).
>
> I noticed there were still
>
> It looks like that's actually a bug in the egg though - contrast to the
> srfi-19 egg which *does* work, it has (data srf-29-bundles (files ...))
> instead.
This has been fixed in the latest amb release (3.0.7).
>
> The attached patch fixes the double call to normalize-destination on the
>
in egg-compile.scm, as suggested by Peter.
felix
From bdf4990636d34bedfd3980f0c7cfdfbfdb0c1bcc Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 30 Oct 2022 14:44:09 +0100
Subject: [PATCH] replace redundant function, as suggested by sjamaan
---
egg-compile.scm | 46
See #1753, as reported by Kon. This will bust egg caches, but should otherwise
not cause any incompatibilities.
felix
From df1335eab5f8e317cb05b0f15595cf61cf0ff14e Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 30 Oct 2022 14:39:42 +0100
Subject: [PATCH] rename egg status files to avoid name
Another follow-up patch on the recent change of quoting in chicken-install,
which causes
chicken-do to always fire (and thus rebuilding any egg, regardless of status).
felix
From 942b63f2a08dad36a3d73a68a3bac43bf7469ab2 Mon Sep 17 00:00:00 2001
From: felix
Date: Sun, 30 Oct 2022 14:38:38 +0100
> On Mon, Oct 24, 2022 at 05:23:24PM +0200, felix.winkelm...@bevuta.com wrote:
> > As reported by Kon, our previous "fix" for shell argument quoting
> > exposed another bug, this is an attempt to improve on that.
>
> Thanks, pushed.
>
> Also, we forgot to look at Salmonella or we'd noticed:
>
> On 2022-08-18 10:23, Sandra Snan wrote:
> > Would you please add something like this to the pathname module?
> >
> > (define (absolute-pathname name)
> > (normalize-pathname
> >(if (absolute-pathname? name) name
> >(make-absolute-pathname (current-directory) name
> >
> >
As reported by Kon, our previous "fix" for shell argument quoting
exposed another bug, this is an attempt to improve on that.
felix
From b4b2561f4bdd13ce92fee6a877846f9ad521bde4 Mon Sep 17 00:00:00 2001
From: felix
Date: Mon, 24 Oct 2022 17:21:37 +0200
Subject: [PATCH] Fix double-quoting bug in
The attached patch addresses the broken semantics of -prelude/-postlude
in the compiler driver, as reported by sjamaan.
felix
From 8a457027563789e6dbedbc1c2045b66d37c36800 Mon Sep 17 00:00:00 2001
From: felix
Date: Mon, 24 Oct 2022 11:21:54 +0200
Subject: [PATCH] fix broken handling of
> On Fri, Oct 21, 2022 at 04:36:58PM +0200, felix.winkelm...@bevuta.com wrote:
> > See #1302.
>
> Why do we even attempt to detect whether to quote? That looks a bit
> brittle to me. It should be simpler to just always quote (e.g. using "qs"),
> like we do in other places, for example in
See #1302.
felix
From aca0348f06de8e61a93cf4203543d2465118d07e Mon Sep 17 00:00:00 2001
From: felix
Date: Fri, 21 Oct 2022 16:36:07 +0200
Subject: [PATCH] try to improve automated quoting/escaping in csc
See also #1302
Signed-off-by: felix
---
csc.scm | 9 +++--
1 file changed, 7
1 - 100 of 824 matches
Mail list logo
