On Fri, 24 Aug 2007 15:57:32 -0400 John Cowan <[EMAIL PROTECTED]> wrote:
> Mario Domenech Goulart scripsit:
>
> > Now we have all of them: http://g3pd.ucpel.tche.br/~mario/egg-deps
>
> I don't think it's useful to have more
> than one arrow between any two eggs. Look at
> http://g3pd.ucpel.tche
Mario Domenech Goulart scripsit:
> Now we have all of them: http://g3pd.ucpel.tche.br/~mario/egg-deps
I don't think it's useful to have more
than one arrow between any two eggs. Look at
http://g3pd.ucpel.tche.br/~mario/egg-deps/scheme-dissect.png for an
example of Op Art.
--
Barry gules and ar
Hi folks,
On 22 Aug 2007 22:14:23 -0300 Mario Domenech Goulart <[EMAIL PROTECTED]> wrote:
> http://g3pd.ucpel.tche.br/~mario/egg-deps/
>
> I'm getting an error while generating the graphs for all the eggs,
> that's why not all of them are showed there. I'll try to fix it
> tomorrow.
Now we hav
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
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/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, 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
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
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
-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,
> "SR" == Shawn Rutledge <[EMAIL PROTECTED]> writes:
[...]
SR> I think code reuse is generally a good thing. As long as there is
SR> no circular dependency, what's wrong with depending on a few eggs?
SR> It's better than rewriting the parts you need, right? (and if your
SR> few dependen
Nice graphs! I was thinking the same thing (but of course, wouldn't
have gotten around to actually doing it).
I think code reuse is generally a good thing. As long as there is no
circular dependency, what's wrong with depending on a few eggs? It's
better than rewriting the parts you need, right
On Thu, 23 Aug 2007 10:05:33 +0900 Ivan Raikov <[EMAIL PROTECTED]> wrote:
> Good point. Also, the command-line nest-tool could probably be
> extended to print a GraphViz (or VCG) representation of the egg
> dependencies, using the format-graph egg. Do you want to add that
> functionality? I will
Good point. Also, the command-line nest-tool could probably be
extended to print a GraphViz (or VCG) representation of the egg
dependencies, using the format-graph egg. Do you want to add that
functionality? I will be more than happy to help with the graph stuff,
though it should be pretty simpl
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 duplication. Dependencies can be hell, but so can d
On Wed, Aug 22, 2007 at 08:41:10AM +0200, Sunnan 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 duplication. Dependencies can be hell, but so can duplication.
De
Hi,
On Wed, 22 Aug 2007 15:50:49 +0900 Ivan Raikov <[EMAIL PROTECTED]> wrote:
> Another solution would be to modify salmonella to construct a
> dependency graph for all eggs and issue a warning for each dependency
> cycle detected. The graph-cycles egg documentation has an example on
> how to b
On Wed, Aug 22, 2007 at 09:16:17AM +0200, Sunnan wrote:
> Ivan Raikov wrote:
> > Another solution would be to modify salmonella to construct a
> > dependency graph for all eggs and issue a warning for each dependency
> > cycle detected.
> That would detect the problems, but wouldn't really solve
Oops, you are right, I was thinking about detection, not prevention
or resolution.
-Ivan
Sunnan <[EMAIL PROTECTED]> writes:
> Ivan Raikov wrote:
>> Another solution would be to modify salmonella to construct a
>> dependency graph for all eggs and issue a warning for each dependency
>> cy
Ivan Raikov wrote:
Another solution would be to modify salmonella to construct a
dependency graph for all eggs and issue a warning for each dependency
cycle detected.
That would detect the problems, but wouldn't really solve them.
___
Chicken-user
Another solution would be to modify salmonella to construct a
dependency graph for all eggs and issue a warning for each dependency
cycle detected. The graph-cycles egg documentation has an example on
how to build a dependency graph, and enumerate all cycles in it.
-Ivan
Sunnan <[EMAIL P
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 duplication. Dependencies can be hell, but so can duplication.
Further, no mutual dependencies (A needs
Hallo,
On 8/21/07, Benedikt Rosenau <[EMAIL PROTECTED]> wrote:
>
> Today, I ran an upgrade because 'chicken-meta-setup check'
> showed new eggs. However after installing the new tinyclos,
> misc-extn, and lookup-table eggs, a new check with
> chicken-meta-setup failed because that crashes.
>
Hello,
Today, I ran an upgrade because 'chicken-meta-setup check'
showed new eggs. However after installing the new tinyclos,
misc-extn, and lookup-table eggs, a new check with
chicken-meta-setup failed because that crashes.
Further, chicken-setup on logging fails because it requires
uri, and se
33 matches
Mail list logo
