Peter, thank you very much for always kindly answering my silly questions.
This info helps me a lot to understand more the chicken core. As time is
limited, I have to finish an egg first, implement the new wiki style
secondly and in third place start looking into core seriously.
But just to
On Mon, Jul 07, 2014 at 09:50:57AM -0300, Arthur Maciel wrote:
Peter, thank you very much for always kindly answering my silly questions.
This info helps me a lot to understand more the chicken core. As time is
limited, I have to finish an egg first, implement the new wiki style
secondly and
Am 05.07.2014 23:31, schrieb Felix Winkelmann:
Finalizers have an impact on every GC, as every GC may free memory at
any time. What may be possible is to register finalizers only when it
is known that the associated data is not held in global variables. But
I'm not sure if it isn't in the end
Now with correct subject. Sorry.
Date: Sat, 05 Jul 2014 23:31:18 +0200 (CEST)
From: Felix Winkelmann felix.winkelm...@bevuta.com
More documentation for internals, even comments will do.
Well, that can be done. External documentation will quickly get out of
sync, but comments shouldn't be a
I also started a stub wiki page about chicken.h (
https://wiki.call-cc.org/notes-on-chicken.h), but I agree that commenting
its source code is a much better solution.
Best wishes,
Arthur
2014-07-06 17:02 GMT-03:00 Arthur Maciel arthurmac...@gmail.com:
Now with correct subject. Sorry.
Date:
From: Oleg Kolosov bazur...@gmail.com
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Thu, 03 Jul 2014 01:33:25 +0400
On 06/28/14 00:38, Felix Winkelmann wrote:
Sounds like candidates for lolevel subset APIs. There are also a room
for leveraging Chicken close relationship with C when
+1 …
Am 03.07.2014 20:23, schrieb Aleksej Saushev:
In general, CMake doesn't solve any real problem of Make. In some aspects
it is a step back even. CMake is mostly equivalent to Make + some autotools.
Plus: this mixing of make's job with the configuration management is
what I perceive as
Oleg Kolosov bazur...@gmail.com writes:
On 06/29/14 13:57, Jörg F. Wittenberger wrote:
I'm even a fan of not depending on cmake at all. Instead I'd favor a
pure Scheme based make process. However I found the plt make macro a
little cumbersome to use, and hard to express generation of and
Besides weird and clumsy syntax CMake has one great advantage over herds
of others so-called build systems (waf, scons, gyp ... put your name
here) - cross compilation, and being a packager, you should be aware of
that. CMake has indeed decent support of it. And this point gives CMake
100
From: Yaroslav Tsarko eriktsa...@googlemail.com
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Thu, 03 Jul 2014 12:14:10 +0400
Besides weird and clumsy syntax CMake has one great advantage over
herds of others so-called build systems (waf, scons, gyp ... put
your name here) - cross
(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
SET(CMAKE_FIND_ROOT_PATH path-to-mingw32 )
On 03.07.2014 16:05, Felix Winkelmann wrote:
From: Yaroslav Tsarko eriktsa...@googlemail.com
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Thu, 03 Jul 2014 12:14:10 +0400
Besides weird and clumsy syntax
From: Yaroslav Tsarko eriktsa...@googlemail.com
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Thu, 03 Jul 2014 16:37:33 +0400
Sure. First, please take a look at the following CMake wiki page:
http://www.cmake.org/Wiki/CMake_Cross_Compiling.
In addition to that many CMake commands
Yaroslav Tsarko eriktsa...@googlemail.com writes:
Sure. First, please take a look at the following CMake wiki
page: http://www.cmake.org/Wiki/CMake_Cross_Compiling.
In addition to that many CMake commands already know how to
properly work in cross-compilation mode (for example:
find_library
On 06/28/14 00:38, Felix Winkelmann wrote:
Sounds like candidates for lolevel subset APIs. There are also a room
for leveraging Chicken close relationship with C when optimizing code.
We have some bottlenecks where Scheme is too high level but using its
C API directly is too troublesome. It
On 06/29/14 13:57, Jörg F. Wittenberger wrote:
OK, since Peter mentioned me…
Am 28.06.2014 12:40, schrieb Peter Bex:
On Sat, Jun 28, 2014 at 12:18:24AM +0400, Oleg Kolosov wrote:
Looks like it is mostly setup api that pulls POSIX. Making it optional
along with csc and friends will allow us
On Tue, Jul 01, 2014 at 12:15:47AM +0200, Felix Winkelmann wrote:
Hm. You mean invoking the entry-point of a library unit should
register a feature of the same name?
Or something else, I'm not sure what exactly. I think conflating
features with module names is asking for trouble down the line.
Hm. You mean invoking the entry-point of a library unit should
register a feature of the same name?
Or something else, I'm not sure what exactly. I think conflating
features with module names is asking for trouble down the line.
If nothing else, we could prefix it, like for example
On 2014-06-30 12:58, Felix Winkelmann wrote:
Excellent! Evan, would you mind writing a wiki-page for the egg?
Perhaps based on the r7rs-tasks page?
Certainly.
The thing about define-values is related to not being able to handle
extended (DSSSL) lambda-lists, is that correct? If yes, we can
From: Evan Hanson ev...@foldling.org
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Thu, 26 Jun 2014 11:49:01 -0700
On 2014-06-26 16:29, Peter Bex wrote:
BTW, what's the status of that egg? The last time I looked it seemed
to be basically complete. Or is there still anything missing
Ah, now I understand. That's due to register-feature, right?
This may be the case, I think (I'm too lazy to check right now, but
features are used for this, at least for the core library units)
Would it be enough to simply always register the library as being
loaded in case of static
OK, since Peter mentioned me…
Am 28.06.2014 12:40, schrieb Peter Bex:
On Sat, Jun 28, 2014 at 12:18:24AM +0400, Oleg Kolosov wrote:
Looks like it is mostly setup api that pulls POSIX. Making it optional
along with csc and friends will allow us to strip the core much more.
And they are hard to
From: Peter Bex peter@xs4all.nl
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Sun, 29 Jun 2014 17:55:10 +0200
On Sat, Jun 28, 2014 at 05:39:35PM +0200, Felix Winkelmann wrote:
I'm not convinced we need separate loading and importing either, as long
as it doesn't interfere
On Sun, Jun 29, 2014 at 08:34:24PM +0200, Felix Winkelmann wrote:
As far as I understand, if you statically link a program which contains
a (use foo) clause, you can link it together with foo.a, and it won't
try to load anything dynamically. Is that correct?
No, it will try to load
On Fri, Jun 27, 2014 at 04:41:07PM +0200, Felix Winkelmann wrote:
I would propose something like this:
- identify stuff that's not used in core and move that to eggs, for example:
memory-mapped files
binary-search (this screams out to be implemented as a functor)
queues
... much
On Fri, Jun 27, 2014 at 11:10:39PM +0400, Oleg Kolosov wrote:
On 06/26/14 16:33, Peter Bex wrote:
I mean an option to compile like: internally convert (module name
exports) to (declare name), hook import somehow into this for rename
and such, issue warnings for names still unresolved but just
On Sat, Jun 28, 2014 at 12:18:24AM +0400, Oleg Kolosov wrote:
Looks like it is mostly setup api that pulls POSIX. Making it optional
along with csc and friends will allow us to strip the core much more.
And they are hard to port to Windows (native) anyway.
If I understand correctly, you
I'm not convinced we need separate loading and importing either, as long
as it doesn't interfere with separate compilation. Right now everyone
always ends up doing (use ...) anyway. Perhaps Felix can show us an
example where only an import (no loading of code) is useful, or otherwise
how
Depending on how large the subset of procedures is we could perhaps pull
a simplified version of them into core and optimise that to hell, and
excise the slow remaining crap from core and move it to an egg (we
already have some duplication like foldl vs fold and string-intersperse
vs
On Thu, Jun 26, 2014 at 03:56:47PM +0200, Felix Winkelmann wrote:
The compiler and egg-setup stuff need a number of srfi-1/13/14
primitives, and the core tarball should be self-contained, so I see not
much chance to eggify more of the base system.
Depending on how large the subset of
On 2014-06-26 16:29, Peter Bex wrote:
BTW, what's the status of that egg? The last time I looked it seemed
to be basically complete. Or is there still anything missing? (I know
there are some rough edges, and obscure warnings, but does it
basically work?)
I've asked Seth and he said
Peter Bex scripsit:
It's not 100% separate, the (begin ...) form allows embedded Scheme forms.
Yes. As a matter of style, that's meant to be used in situations like
this:
(define library (foo)
...
(cond-expand
((library (scheme complex))
(import (only (scheme complex) real-part
Evan Hanson scripsit:
There's not much that's obviously missing anymore, it's mostly rough
edges as you said. The list at https://wiki.call-cc.org/r7rs-tasks#todo
is up to date.
I've added a few things there. The only substantive point is that after
doing (use r7rs) in the REPL, the (scheme
On 06/19/14 23:27, Peter Bex wrote:
On Thu, Jun 19, 2014 at 09:13:01PM +0200, Felix Winkelmann wrote:
A few remarks:
- Modules are a namespace-specific concept, units are a
loading/linking concept. Are you really comparing these here?
Well, kind of. Let me tip-toe around the definitions
Oleg Kolosov scripsit:
What do you think about Chibi Scheme approach
(http://synthcode.com/scheme/chibi/#h2_ModuleSystem)? Providing module
definitions separately, avoids aforementioned issues nicely, and,
coupled with an option to ignore everything as proposed above will allow
incremental
On Thu, Jun 19, 2014 at 11:36:58PM +0200, Kristian Lein-Mathisen wrote:
Thanks so much for looking into this, and fixing it, Peter! This is
probably the only patch on chicken-hackers I'll ever understand :) I should
have thought about using DEBUGBUILD myself. I'll see if I can be of more
use
Ah, I did not get that quick (use ports) workaround. That'll do!
Thanks,
K.
On Fri, Jun 20, 2014 at 8:22 AM, Peter Bex peter@xs4all.nl wrote:
On Thu, Jun 19, 2014 at 11:36:58PM +0200, Kristian Lein-Mathisen wrote:
Thanks so much for looking into this, and fixing it, Peter! This is
Hi all,
Here's a pretty simple patch for #1133. It segfaults with a regular
build, but a DEBUGBUILD says exactly what's wrong:
Error: unbound variable: make-input-port
Call history:
foo.scm:2: tcp-listen
foo.scm:2: tcp-accept --
The problem got
Peter Bex scripsit:
I've replaced extras by ports to fix the dependency stuff. I think it's
time we started making a more concrete plan on how to make the core
system use proper modules instead of units, while still maintaining
separate compilation of course!
Amen. Units are really a
Peter Bex peter@xs4all.nl writes:
Hi all,
Here's a pretty simple patch for #1133. It segfaults with a regular
build, but a DEBUGBUILD says exactly what's wrong:
Pushed, thanks.
Christian
___
Chicken-hackers mailing list
I've replaced extras by ports to fix the dependency stuff. I think it's
time we started making a more concrete plan on how to make the core
system use proper modules instead of units, while still maintaining
separate compilation of course! If we use modules, this kind of bug
will be easily
On Thu, Jun 19, 2014 at 09:13:01PM +0200, Felix Winkelmann wrote:
A few remarks:
Hi Felix,
Thanks for replying!
- Modules are a namespace-specific concept, units are a
loading/linking concept. Are you really comparing these here?
Well, kind of. Let me tip-toe around the definitions to
Well, kind of. Let me tip-toe around the definitions to clarify:
Currently units are used in core to define dependencies, which is one
of the things that modules are used for as well. And as we saw in
this ticket and the other one there are some problems which can be
detected in dependencies
Thanks so much for looking into this, and fixing it, Peter! This is
probably the only patch on chicken-hackers I'll ever understand :) I should
have thought about using DEBUGBUILD myself. I'll see if I can be of more
use next time!
We are depending on this fix for our systems in prod. Will there
43 matches
Mail list logo
