Ivan Shmakov schrieb:
>> 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 L
> 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 o
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 B
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 (lik
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 mino
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 ma
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
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 mak
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 minor one. Is the documentation
> incorrect, or is thi
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
>
> http://scheme2006.cs.uchicago.edu/0
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.
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 alternat
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
__
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 a
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 g
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 n
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,
>>
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 cour
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
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
reinst
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 begging
-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
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
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? Sh
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,
25 matches
Mail list logo
