On Thu, Aug 23, 2007 at 12:12:39PM +0700, Ivan Shmakov wrote:
SR But it's important for popular eggs to be kept in a working state,
SR and not change existing APIs in them when avoidable.
Could it be the reason to include version numbers into the .egg
names, so that, when
felix winkelmann wrote:
I agree with Benedikt that dependencies should be kept at a minimum.
It starts with simple sharing of code but quickly everything ends up in
a tangle of dependencies that no one can comprehend.
What's the alternative? Should tool implement its own args
documentation?
On 8/22/07, Ivan Shmakov [EMAIL PROTECTED] wrote:
It seems not too hard to implement dependency resolving in
software. Surely, it shouldn't be necessary to download all the
dependencies manually.
chicken-setup does that - if I install an egg that depends on another
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mea Maxima Culpa to Chicken Users.
My apologies for the sloppy release of the re-factored misc-extn
egg. Not only didn't I update the dependency chain in the
various .setup files, I managed to create an inconsistent repository.
However, there
i'd be happy to put the time in if we can discuss it a bit more. i already
have ~80% of the eggs installed locally so its to my benefit as well. :)
-elf
On Thu, 23 Aug 2007, felix winkelmann wrote:
Hello, everybody.
The time has come again, where I'm getting down on my knees
humbly
Hallo,
On 8/22/07, felix winkelmann [EMAIL PROTECTED] wrote:
I have experienced this problem several times myself. What usually
helps is reinstalling all eggs that use misc-extn. Is there unsafe code
in there?
Kon told me in private email to completely remove misc-extn and
reinstall.
On 8/23/07, felix winkelmann [EMAIL PROTECTED] wrote:
On 8/22/07, Sunnan [EMAIL PROTECTED] wrote:
Benedikt Rosenau wrote:
Anyway, I propose the following: please keep dependencies between
eggs small.
I disagree; sometimes, it seems better to split common code to libraries
than to have
Shawn Rutledge scripsit:
But it's important for popular eggs to be kept in a working state, and
not change existing APIs in them when avoidable.
In particular, there is no reason not to depend on any egg that implements
a SRFI or other external standard, since the interface is fixed.
(Of
Hey Kon,
I described my problem, plus an example, in this post:
http://groups.google.com/group/comp.lang.scheme/msg/19e37409eee0d7ab
I'm relatively new to syntax-case. How do I explicitly specify a literal?
Thanks,
Mark
On Aug 21, 2007, at 8:28 AM, [EMAIL PROTECTED] wrote:
Folks,
It
Hi Felix and folks,
On Thu, 23 Aug 2007 02:07:04 +0200 felix winkelmann [EMAIL PROTECTED] wrote:
The time has come again, where I'm getting down on my knees
humbly begging for help: keeping the egg repository in shape
currently takes too much of the little time I have. I want to get a new
Hello,
On Thu, Aug 23, 2007 at 02:00:07AM +0200, felix winkelmann wrote:
tool - srfi-37, args-doc
args-doc - srfi-37, srfi-95
srfi-95 - array-lib
array-lib - srfi-42, miscmacros, misc-extn
srfi-42 - syntax-case
This is insane.
It might be insane, but I don't know how you are going to get
For an interesting perspective on this issue (which could probably be
incorporated by minor changes in the egg system), you guys might have
a look at PLT's PLaneT server. You can find a design paper at
http://scheme2006.cs.uchicago.edu/04-matthews.pdf
and, of course, the PLaneT repository
Hi folks,
On my Chicken 2.5 instance, If one calls (gc) with no argument, a
minor GC is performed. The documentation on the wiki suggests that it
ought to perform a major GC, not a minor one. Is the documentation
incorrect, or is this a change in behaviour?
Graham
On 8/23/07, Sunnan [EMAIL PROTECTED] wrote:
felix winkelmann wrote:
I agree with Benedikt that dependencies should be kept at a minimum.
It starts with simple sharing of code but quickly everything ends up in
a tangle of dependencies that no one can comprehend.
What's the alternative?
On 8/23/07, Arto Bendiken [EMAIL PROTECTED] wrote:
I believe this is simply a case of a situation where more of the
generally useful stuff should be pushed down to Chicken's standard
library, whence all eggs could rely on that functionality always being
available (unless compiled out e.g.
On 8/23/07, Will M Farr [EMAIL PROTECTED] wrote:
For an interesting perspective on this issue (which could probably be
incorporated by minor changes in the egg system), you guys might have
a look at PLT's PLaneT server. You can find a design paper at
felix winkelmann scripsit:
Why not just keep things as they are?
Well, because Does anyone mind if I make backward incompatible changes
to the API of this egg? doesn't really scale well.
I have a very simple and easy proposal, purely social, no need for
technical changes:
If you need to make
On 8/24/07, John Cowan [EMAIL PROTECTED] wrote:
If you need to make backward-incompatible changes to the API of an egg,
make a new egg with a new name related to the old. Then persuade people
to change over to the new egg. When you decide to pull support for the
old egg, announce that in
On 8/23/07, felix winkelmann [EMAIL PROTECTED] wrote:
On 8/23/07, Graham Fawcett [EMAIL PROTECTED] wrote:
Hi folks,
On my Chicken 2.5 instance, If one calls (gc) with no argument, a
minor GC is performed. The documentation on the wiki suggests that it
ought to perform a major GC, not a
On 8/23/07, felix winkelmann [EMAIL PROTECTED] wrote:
On 8/23/07, Graham Fawcett [EMAIL PROTECTED] wrote:
On my Chicken 2.5 instance, If one calls (gc) with no argument, a
minor GC is performed. The documentation on the wiki suggests that it
ought to perform a major GC, not a minor one. Is
On 8/23/07, John Cowan [EMAIL PROTECTED] wrote:
If you need to make backward-incompatible changes to the API of an egg,
make a new egg with a new name related to the old. Then persuade people
This is similar to considering the major version number to be part of
the name at some level (like
Graham Fawcett scripsit:
If there are no objections, I'll modify the wiki, so that the last
sentence reads, An explicit #t argument will also cause all pending
finalizers to be executed.
Very well, but I believe this API is atrocious, and an excellent
case of why boolean arguments are a Bad
felix winkelmann [EMAIL PROTECTED] writes:
[...]
Syntax-case is low-level, srfi-42 and miscmacros are control
structures... This is part of what lisp is to me; layers upon layers
of code.
Right, this is also why all Lisp systems end up in large entangled
blobs that no one can build
23 matches
Mail list logo
