On 2017-09-11 19:04, Peter Bex wrote:
> Now, does anyone want to look at what to do with the documentation?
> The current "Types" manual page is quite well-written, but it's
> structured like a tutorial which makes it less suited for the
> reference manual style which we use for module
Hi Peter,
On 2017-09-10 17:33, Peter Bex wrote:
Here's a straightforward patch to move those two procedures from
library.scm to file.scm.
Applied, thanks.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
Thanks Felix, I've applied this.
Regarding srfi-1 and the other eggs with hand-rolled type files, is
there a way to install those files using the "official" egg API? I've
puzzled over this for a little while and AFAICT there's a way to put
files into the "bin", "share" and "include" directories,
Hi folks,
Here's a patch that creates the "chicken.type" module. It's pretty
straightforward, let me know if you have any questions.
Cheers,
Evan
>From e95e14a09488bc01d64720fa103525a90931e1bf Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Mon, 11 Sep
Hi folks,
Here's a very simple one, removing `any?` (since `constantly` can
provide the same thing easily enough).
Cheers,
Evan
>From 656304ec154886a967c57acd64e586a670f7568c Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Sun, 10 Sep 2017 13:02:11 +1200
Subjec
On 2017-09-09 11:17, Kooda wrote:
Well, actually, I’m not sure what makes more sense. I think it’s
strange that types and inline files are relative paths in the install
script while every other file is an absolute path.
The other thing I find strange, is that the doc says that the
(types-file)
Please ignore this patch, Kooda has pointed out that the current
behaviour makes more sense.
Sorry for the noise,
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Applied, thanks!
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
like (types-file "bar") in the egg file.
Cheers,
Evan
>From d95720caa4136ad0d9688d42366fe951a27175df Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Tue, 5 Sep 2017 23:01:08 +1200
Subject: [PATCH] Use name from egg file when installing types and inline files
Here is a small API change for the `current-directory` procedures, after
some discussion of the other patch on IRC. See the commit message for
rationale.
Cheers,
Evan
>From 2bfaabac15066834671d4121052ffeff1296e126 Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: F
Hi Peter,
As discussed on IRC, I've pruned this patch down to the parts that
refactor C_fchdir() on Windows and reduce the duplication of the
change-directory[*] procedures.
I've also removed the "define-unimplemented" form in posixwin.scm for
`change-directory*` (since it's implemented now,
Nice, this is a big win for not much new code. Applied.
Great work,
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Looks good, applied.
I agree about the slot procedures, it doesn't make much sense to move
those out of the library unit since almost everything relies on them. We
should probably just leave them there and add aliases in
"chicken.memory.representation" for the user to import.
Evan
To follow the patch applied earlier today.
I didn't notice that these types.db updates were missing from that
changeset until after it was already pushed, sorry about that.
Evan
>From d368c2b4c7195ce4b46af191de795d6e95d070d3 Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org
Applied, thanks Peter.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Yep, applied.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
. Here's a patch that kicks it
back out into just "chicken". It can move into "base" along with
everything else once we get to that.
Cheers,
Evan
>From 7f41f1d5b93b9cf4c0270d0e6b36ab30df77528a Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Wed, 9 Au
ten to yet?).
Cheers,
Evan
>From 8ba4d813fd20a7eb214e41fbfdf81674070ab91a Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Mon, 7 Aug 2017 21:38:58 +1200
Subject: [PATCH] Move `print-error-message' into (chicken condition)
---
chicken.condition.import.scm | 1 +
Looks good, applied to chicken-5.
As Felix says, I've left master alone.
Thanks much,
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
On 2017-08-03 19:23, felix.winkelm...@bevuta.com wrote:
Attached a patch that removes "system-information" and "get-host-name".
Applied, thanks Felix.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
Again per Felix and Peter's proposal. Note that this patch is based on
the one that moves 'quit' to chicken.repl (to avoid conflicts), so that
one will need to be applied first.
Cheers,
Evan
>From 446a0d7bbcdb25fbe7e527d29fcb625a8d54e845 Mon Sep 17 00:00:00 2001
From: Evan Hanson
Per Felix and Peter's recent proposal.
Cheers,
Evan
>From dfef43f14abd25e7fe60f4b2cca27f64ae01f653 Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Wed, 26 Jul 2017 16:47:58 +1200
Subject: [PATCH] Add chicken.blob module
---
README
Per Felix and Peter's recent proposal.
Cheers,
Evan
>From f71c345c32a965d98b103e70e68981848aef16dc Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Wed, 26 Jul 2017 08:17:47 +1200
Subject: [PATCH] Move `quit' into (chicken repl)
---
chicken.import.scm | 1 -
li
On 2017-07-25 14:10, felix.winkelm...@bevuta.com wrote:
Peter and me thought that we move "system-information" and "get-host-name"
into an egg, since they are not used in the core system. The suggested name
is "system-information".
+1, sounds good to me.
I guess the trickiest bit of moving
Another simple one. `create-directory` is pretty small and relies only
on "C_mkdir" (which is already in file.scm) as far as C functions go, so
it's easy to move.
Cheers,
Evan
>From 2f8fdf3f157ef82a892618e65ebd629214b28a8f Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@fo
Straightforward, finishes off "chicken.module".
Cheers,
Evan
>From 47280d5a93d160aaf71fc586cc313a78fe3eea8a Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Sun, 23 Jul 2017 23:08:19 +1200
Subject: [PATCH] Move `functor' and `define-interface' i
, attached.
Thanks for looking,
Evan
>From 642211f4cb98d4e73e0cb0d9ac4300fb63be1cd9 Mon Sep 17 00:00:00 2001
From: Evan Hanson <ev...@foldling.org>
Date: Sat, 15 Jul 2017 14:12:15 +1200
Subject: [PATCH] Fix repository searching for "-link" flag and associated
tests
The part o
Yep, pushed.
Cheers,
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
On 2017-07-18 8:30, Peter Bex wrote:
On Tue, Jul 18, 2017 at 09:55:21AM +1200, Evan Hanson wrote:
Regarding whether to namespace the core record types, I think we
probably _should_ do so, but it's not a priority. My attitude towards
wrapping the tags in a record type is similar; I'd be fine
Thanks Peter, I've applied this as it is. I agree with Lemon that we
should dry up the repeated naming logic, but for now I think we can live
with the duplication in order to keep things moving.
The patch wasn't quite careful enough with regards to bootstrapping,
however, and caused some
On 2017-07-17 9:43, felix.winkelm...@bevuta.com wrote:
On Mon, Jul 17, 2017 at 09:06:15AM +0200, Peter Bex wrote:
> Also, should we wait until 5.1 with this? Considering we've made so
> many changes already, it makes sense to let things settle before enabling
> these optimizations. That way,
Thanks folks, this is a very nice improvement.
I've applied a combination of these two patches that includes the
C_i_foreign_integer_argumentp case but leaves the fallback behaviour
alone. As Lemon says, this pass doesn't do unions so we can't "reduce"
r1 and instead just pass it through.
I
Clever!
Pushed, thanks Peter.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
On 2017-06-26 13:44, felix.winkelm...@bevuta.com wrote:
So I'd consider C_R_P of secondary importance in such a situation. We
can change the code in csc to respect the variable, but mostly it is
important to handle the target case
Too true. Here's an updated version of the third patch that
On 2017-07-04 17:11, megane wrote:
> The patch was for the 4.13 tarball.
>
> I'm installing the 5.0pre1 tarball and will post an updated patch.
Thanks megane.
> The question is do we want to drop the * export support from 5
> altogether.
I don't think we do. Let's not pursue anything like that
Hi Lemon,
You're right, that was certainly not intentional but that procedure does
my head in so I'm not a bit surprised.
I've opened #1384 since I'm not even sure the fixed behaviour is what we
really want in all situations, and there are a few other areas we could
try to simplify file
This was previously an internal procedure used variously within core,
but it's useful enough to promote to an official API. So, simplify its
interface (making it always return an SRE) and add it to the irregex
library's exports.
---
NEWS | 1 +
chicken-status.scm| 3 +-
Looks good, pushed. Thanks Peter!
On 2017-06-14 22:14, Peter Bex wrote:
What should we do with ##sys#glob->regex? I think it's useful
enough to expose to the user, which conveniently allows us to get
rid of the ##sys# prefix too. But in which unit does it belong
the most? Personally, I think
Excellent, pushed. Thank you Peter.
On 2017-06-25 16:20, Peter Bex wrote:
Note that I had to add (import scheme) to module.scm, which isn't
wrapped in a module yet, because otherwise I'd get an error about
`load' not being defined. This shouldn't be necessary, but probably
has to do with how
Applied.
Good stuff, thank you once again for the patch.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Pushed. I've also updated the wiki accordingly.
Cheers,
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Good catch, thanks Mario. Applied.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
On 2017-06-20 13:11, felix.winkelm...@bevuta.com wrote:
You seem to drop the reference to "destination-repository". Are you sure this is
right in the face of cross-compilation?
I think so. Or rather, this patch makes "-link" behave like "normal"
compilation in that it respects
Hi Peter,
This seems to fix the all of the compiler test hangs for me, so those on
MSYS2, "bare" MinGW (which was a slightly different error), and
miscellaneous 32-bit platforms. So, I think this does fix #1377 after
all.
That error case on unrecognised types is it a good change, too, it will
Hi Peter,
On 2017-06-18 15:08, Peter Bex wrote:
What's the reason you've only marked functor and define-interface as
TODO and not moved them yet? Are they problematic somehow?
Nope, I just didn't have time to finish and test those but figured the
diff was worth proposing as it was. I don't
This is the second half of 934eecc, re-applied. The symptom is the same
as in that commit (the static linking tests failing), and the fix is
also more or less the same (passing "-static -lchicken" and letting the
linker sort out the path to libchicken.a).
Fixes #1366.
---
csc.scm | 14
The part of the linking tests that was supposed to make sure the "-link"
flag picks up object files from the repository was broken, since the
reverser.o file that should have been *moved* into the test repository
was *copied* there. This meant that a reverser.o was left in the current
directory,
This is one half of 934eecc re-applied to fix a problem when running
`make check` without first running `make install`: when compiling and
executing use-square-functor.scm in the functor tests, the import
library for the "chicken" module wouldn't be found since it wasn't
present in the target
Hi folks,
Here's a small patch that puts `module-environment' into the eval
module. I propose this as an alternative to making `eval/meta` a public
API, which it feels like we were mostly doing just to make
"chicken.eval" export more than one thing. I think putting
`module-environment' there
This syntax-only library contains CHICKEN's "module language" and
currently contains: module, import[-*], export and reexport.
TODOs have been left in place to remind us to move `functor` and
`define-interface` into this module, as well.
---
chicken-syntax.scm | 2 +
expand.scm
Hi all,
Here's a patch that adds a "chicken.module" module according to some of
the discussion in the "Add unexport form to modules" thread, and from
the "undecided" section of c-l-r (which already proposed a lot of the
same changes, in fact).
The library is syntax-only and contains CHICKEN's
As of afd7867, we can make these values available to the other files
that need to use them without making them part of the chicken.export
module's public API by assigning directly to namespaced identifiers.
---
core.scm | 4 ++--
expand.scm | 17 +
2 files changed, 11
This deduplicates the import and export lists of the posix modules in
posix{unix,win}.scm, which are identical as of f4e53ff with the
exception of two extra imports needed on Windows for its implementations
of `process` and `file-mkstemp`.
These exceptions have been left in posixwin.scm as
Hey Peter,
On 2017-06-06 22:31, Peter Bex wrote:
> I noticed two problems after looking over the file-modification-time
> patches I recently submitted. [...] Attached are patches for this.
Seems sound, pushed.
> Strictly speaking, I suppose we should really add a new C_num_to_size_t
> or such,
Hi Peter,
Firstly, thank you for the writeup. It takes time and energy to consider
design issues like this, and your effort is appreciated.
On 2017-06-07 22:07, Peter Bex wrote:
> But my more immediate concern is with proliferation of the magic set of
> special forms that's always available in a
On 2017-06-05 12:11, Peter Bex wrote:
> On Mon, Jun 05, 2017 at 05:53:32PM +1200, Evan Hanson wrote:
> > On 2017-06-04 13:53, Peter Bex wrote:
> > > Regarding time specifically, there are not many stand-alone programs
> > > that will use this macro, I think. It's
Hey all,
On 2017-06-05 11:43, Peter Bex wrote:
> On Mon, Jun 05, 2017 at 06:09:54PM +1200, Evan Hanson wrote:
> > Is that right? Personally, I'd rather make (declare (hide ...)) simply
> > do the right thing -- the right thing being the behaviour you originally
> > expec
Hi megane,
On 2017-05-28 16:12, megane wrote:
> I was thinking maybe we could leave the declarations as they are and add
> an explicit counterpart for export. The implementation may be pretty
> easy to do by just updating the module export and what not lists. Maybe
> call the new syntax
Hey Peter,
On 2017-06-04 13:53, Peter Bex wrote:
> Regarding time specifically, there are not many stand-alone programs
> that will use this macro, I think. It's more a thing for benchmarks
> and such, so I'm not even sure it must be part of library. It probably
> was in there because the macro
Hi Peter,
Sorry for the delay, I should have responded earlier.
On 2017-06-03 15:07, Peter Bex wrote:
> On Wed, May 03, 2017 at 08:29:12AM +0200, Peter Bex wrote:
> > On Mon, May 01, 2017 at 06:02:51PM +1200, Evan Hanson wrote:
> > > Hi folks,
> > >
> > &
On 2017-05-31 11:29, felix.winkelm...@bevuta.com wrote:
> > 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
On 2017-05-31 12:19, felix.winkelm...@bevuta.com wrote:
> Ok, how about a new .egg extension property named "(modules NAME1 ...)"?
> Defaulting to one module (the extension name). Keeping the list empty
> ("(modules)") specifies an extension without modules.
I like this idea, flexible but with a
Applied.
Bit surprised at this one. How on earth did it hang around for so long?
Thanks for the fix, Peter.
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
Applied.
Thanks again Lemon, keep them coming.
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Good catch, thank you. I did look at those declarations, but didn't
rethink the symbol requirement.
I've applied this to both branches.
Cheers,
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
Applied, thanks.
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Pushed. That was a lot of code!
On 2017-05-19 16:09, Peter Bex wrote:
> After the next snapshot (pre2? rc1?), we can drop the matching C code.
Yeah, I'm gonna guess pre2. We're nowhere near RC territory yet, but we
try hard to make regular snapshots in the meantime.
Cheers,
Evan
On 2017-05-24 13:16, Peter Bex wrote:
> Both should use small-bignum?, and of course that means the bignum?
> check should be restored.
Cool, I've applied this with that change.
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers
Hi folks,
Good discussion, thank you Peter and Lemon for considering this.
> diff --git a/lfa2.scm b/lfa2.scm
> index 0fd4612..4c7ff84 100644
> --- a/lfa2.scm
> +++ b/lfa2.scm
> @@ -173,17 +173,14 @@
>;; a simplified variant of the one in scrutinizer.scm
>(cond ((string? lit)
Thank you both, these have been pushed.
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Hi Peter,
Nice work, this is a great idea.
I'm definitely in favor of a procedure like this, but I do have one
thought regarding the specifics: the procedure `condition->list` already
defines a convention of sorts for representing the constituent parts of
a condition as data, whereas this new
>
Date: Mon, 15 May 2017 20:14:42 +0200
Subject: [PATCH 1/2] Use the raw variable name in env lookups and errors
The current-environment and the macro-environment are alists whose keys
are the raw variable names.
Also, reword the error messages a little and add some unit tests.
Signed-o
This was only left in place to ease the transition from the "files" and
"posix" units to separate "file" and "file.posix" modules. Now that some
of the smoke has cleared from other refactoring, we can finish the
rename and drop files.scm.
---
README | 1 -
On 2017-05-19 11:20, Peter Bex wrote:
> I actually prefer using that hack of "internal" modules. Modules are a
> standard approach that users will already be familiar with, which means
> the barrier to entry should be slightly lower. And, also important, with
> modules you get an error when you
Hi Peter,
On 2017-05-07 21:45, Peter Bex wrote:
> The core-library-reorganization page has "(chicken condition)" under
> "undecided", but I think it's fine the way it is. The attached patches
> add this module.
These have been applied. Excellent work, it looks like these were tricky
changes.
>
These were only there for compatibility when bootstrapping from CHICKEN
4, to make any units that are run early in startup indicate that they'd
been loaded (this is done automatically for units compiled with 5.0.0).
Now that we have a snapshot release, these can go away.
---
From: LemonBoy <thatle...@gmail.com>
Previously, "install-inline-file" installed the inline file in place of
the types one, rather than to the correct path.
Also remove the executable bit when installing files that have no reason
to have it.
Signed-off-by: Evan Hanson <
Hi Lemonboy,
Looks good, thanks for that.
Here's a signed-off copy, could another hacker please have a look.
Cheers,
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Hi folks,
> If there are no objections, I'll update the development process wiki page
> accordingly and create a first snapshot from 38c4467f.
This has been done, and the first CHICKEN 5 snapshot is now available at:
http://code.call-cc.org/dev-snapshots/2017/05/16/chicken-5.0.0pre1.tar.gz
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 objections, I'll
This adds an "escape hatch" to variable resolution for namespaced
symbols (e.g. `foo#bar`), allowing them to be used across module
boundaries just like qualified symbols.
This is done by simple string scanning of the identifier's name, which
is emphatically not ideal as it means the compiler has
Hi Peter,
On 2017-05-13 11:58, Peter Bex wrote:
> Two quick questions: Given that C_namespaced_symbolp is inlineable and
> unsafe, shouldn't it be named C_u_i_namespaced_symbolp?
>
> And, given that it's inlineable, I think it would be better to put it in
> tweaks.scm (for example) as a
Hi Peter,
Looks good, applied.
Thanks for noticing that. I don't remember where that original list of
exports came from, but I'd always just assumed it was correct without
ever checking against the "real" API.
Best regards,
Evan
signature.asc
Description: PGP signature
---
tcp.scm | 152
1 file changed, 75 insertions(+), 77 deletions(-)
diff --git a/tcp.scm b/tcp.scm
index 8e3d0e4c..a806ac99 100644
--- a/tcp.scm
+++ b/tcp.scm
@@ -165,30 +165,28 @@ EOF
(define-foreign-variable _invalid_socket int
This adds an "escape hatch" to variable resolution for namespaced
symbols (e.g. `foo#bar`), allowing them to be used across module
boundaries just like qualified symbols.
This is done by simple string scanning of the identifier's name, which
is emphatically not ideal as it means the compiler has
---
continuation.scm | 4
1 file changed, 4 deletions(-)
diff --git a/continuation.scm b/continuation.scm
index e8cc4ff0..d1cb29de 100644
--- a/continuation.scm
+++ b/continuation.scm
@@ -30,10 +30,6 @@
(foreign-declare "#define C_direct_continuation(dummy) t1")
-;; XXX Is this still
Replace `##sys#read-string/port' and `##sys#read-string!/port', both of
which are defined in extras.scm but also used in srfi-4.scm, with
module-namespaced (but still internal) names.
Also, reshuffle their argument checks so that the internal procedures
trust their argument types and all the
Hi folks,
Here are a few patches that deal with symbols and namespaces.
The first changes the way explicitly-namespaced symbols are handled
(that is, symbols with a module name directly included, like "foo#bar"),
making them behave essentially like qualified symbols as far as variable
resolution
Hey Lemonboy,
On 2017-05-09 16:20, lemonboy wrote:
> since both `##sys#macro-environment` and `##sys#current-environment`
> are alists whose keys are unqualified symbol names it doesn't make
> sense to use `var` as lookup key since after the initial lookup of
> `var0` against the environment we
Hi Peter,
Again, I didn't test this patch, but the fact that it's working fine in
master speaks for itself.
Thanks for finding and porting this fix. Applied.
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Hi Peter,
I didn't bother to test this, because Windows. But, I believe you. :)
Oddly, I've never noticed this when installing under MinGW before. Maybe
there's a setting somewhere that controls the behaviour of XCOPY?
*shrug*
Pushed.
Evan
signature.asc
Description: PGP signature
Thanks folks, these have been applied.
Keep them coming, TheLemonMan, this is good stuff.
Cheers,
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
On 2017-05-06 11:03, Evan Hanson wrote:
> The procedure will probably be useful for some
Actually, will it? I'm having a hard time thinking of a good use case
for this, from a user's perspective. Can you think of one?
Evan
signature.asc
Description: PGP signat
Hi Peter,
On 2017-05-04 22:10, Peter Bex wrote:
> Nice, I've pushed this. I noticed that we still have "eval-handler",
> which wasn't in core-libraries-reorg AFAIK. I guess we need to keep
> that, and the only place that makes any sense for this would be in a
> "chicken.eval" module.
>
> If we
Oh, internal definitions...
Pushed. Thanks for investigating this issue when you noticed it.
Evan
signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
Hi Lemon,
Same for this one. Thanks and good find.
Evan
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers
On 2017-05-02 16:34, lemonboy wrote:
> Hello hackers,
> here's a small patch that fixes a small and harmless error.
Thanks Lemon! I've applied this directly since it's obviously correct.
Cheers,
Evan
___
Chicken-hackers mailing list
This reorganises things in eval.scm so that two sets of procedures,
those supporting `eval` and those dealing with code loading, can be
logically grouped, allowing us to create a new, self-contained
"chicken.load" module dedicated to the latter.
Most of this patch is just swapping two large hunks
Hi folks,
Here's a patch that creates the "chicken.load" module per the roadmap.
It's mostly just reorganising code in eval.scm and doesn't yet hide
`load` or `eval` from their respective modules, but it's a step. I tried
to find a way to move things around that kept the diff reasonably small.
---
chicken-install.scm | 8 +++-
chicken.import.scm | 1 -
library.scm | 16 +---
manual/Unit eval| 8
types.db| 1 -
5 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/chicken-install.scm b/chicken-install.scm
index
301 - 400 of 714 matches
Mail list logo
