On Feb 13, 2008 1:00 AM, Leonardo Valeri Manera
[EMAIL PROTECTED] wrote:
Since you're talking of doing work on the wiki and svn and whatnot
during the hackaton and after, how about setting in hooks so you can
setup a feed for egg updates later on?
Shouldn't be a big deal. The egg-post-commit
On Feb 12, 2008 7:16 PM, Peter Bex [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 11:10:28AM -0600, Ozzi wrote:
This is perhaps a different concern, but I wonder if there would be value in
designating certain eggs as part of Chicken, and holding these eggs to a
stricter standard of
On Feb 13, 2008 4:46 AM, John Cowan [EMAIL PROTECTED] wrote:
Ivan Raikov scripsit:
There is no such thing as a standard library for Scheme, other
than what is defined in the R5RS standard.
True for R5RS Scheme. But for Chicken in particular, the units are
de facto a standard library,
On Wed, Feb 13, 2008 at 09:18:20AM +0100, felix winkelmann wrote:
I like the idea of being able to put the documentation into the code;
something like Doxygen is needed for Scheme. I think it's not the
first time such an idea has been proposed, but I don't know much about
what has been
On Feb 12, 2008 10:16 PM, Shawn Rutledge [EMAIL PROTECTED] wrote:
On Feb 12, 2008 10:13 AM, Tobia Conforto [EMAIL PROTECTED] wrote:
My idea is to devise a smart document format, preferably s-expr
based (maybe SSAX-based if nothing better comes to mind) and convert
every piece of Chicken API
On Feb 13, 2008 9:44 AM, Peter Bex [EMAIL PROTECTED] wrote:
Docs are hard to maintain and code is hard to maintain when you stick them
all in one big pile.
Absolutely.
Besides, all these doc overhauls just eat up developer time...
That's why there shouldn't be all these doc overhauls,
the POST method does not do what would normally be expected, in many cases.
i am proposing to keep the first two args (request/request-server and args)
and to keyword the rest, as well as adding an additional new arg for
type (eg xml, form-urlencoded, multipart, etc). it seems from the code
Yes, I've submitted the Portfile patch to MacPorts. Here is the
ticket: http://trac.macosforge.org/projects/macports/ticket/14302 .
On Feb 8, 2008 7:48 PM, Ivan Raikov [EMAIL PROTECTED] wrote:
Hello,
I have tested and committed your patch to rules.make, thanks. Would
you like to submit
and for using Chicken on small devices this is a great selling point!
cheers,
John.
On 13/02/2008, felix winkelmann [EMAIL PROTECTED] wrote:
Chicken is oriented towards being minimal and to externalize all
extra functionality. What's included in the base system is only the
stuff that is
Well, the Debian egg packages can be easily converted to RPM by the
alien program, but there might be slight differences in how each RPM
distribution does its library version numbering. E.g. the estraier egg
depends on libestraier8 package in Debian, but that could be named
something completely
At Tue, 12 Feb 2008 22:46:54 -0500,
John Cowan wrote:
I'd rather see units and eggs treated as on a par, and the distinction
drawn between community-supported, author-supported, and unsupported
packages.
This might work, but isn't it hard to say something is community-supported?
How about
oh, also, i didnt say no-one was using the other args, only that no eggs
depended on more than two args. not many eggs use http-client directly, most
use the server. one of the things im working on needs the client to have
certain functionality atm, though, so at least some of the extra args
Hi,
I'm one of the guy who messed up the http-client.
If nobody else is using other than two args,
why don't we make it much simpler (http:POST req args)
without keywords?
A user who wants to customize POST method could do so using http:send-request.
--daishi
At Wed, 13 Feb 2008 01:41:52 -0800
heh, erm, well, i didnt hear from anyone for a few hours, so i already
committed the changes. apologies. theyre documented (poorly) on the wiki,
and the code should be mostly self-explanatory. theres some new methods for
modifying request-attributes too.
-elf
On Wed, 13 Feb 2008, Daishi
Well, of cource we can remain keyword args.
In any case, since we are changing the signature,
we can't care about the backward compatibility with more than two args.
Where can I look at the new code?
I tried to svn up now, only giving me of version 2.1.
--daishi
At Wed, 13 Feb 2008 06:13:43
apologies. i can revert if desired. i just had a large block of code that
was breaking due to the prior implementations assumptions.
-elf
On Wed, 13 Feb 2008, felix winkelmann wrote:
On Feb 13, 2008 3:12 PM, Elf [EMAIL PROTECTED] wrote:
heh, erm, well, i didnt hear from anyone for a few
On Feb 13, 2008 3:12 PM, Elf [EMAIL PROTECTED] wrote:
heh, erm, well, i didnt hear from anyone for a few hours, so i already
committed the changes. apologies. theyre documented (poorly) on the wiki,
and the code should be mostly self-explanatory. theres some new methods for
modifying
On Thu, 14 Feb 2008, Daishi Kato wrote:
Wow, it looks nice.
I'm not sure about the type specified is only meaning-full
if the content-type was empty. A user might expect the type
to be overwritten.
i didnt think it would be very common for people to be explicitly creating
the content-type
On Feb 13, 2008 10:41 AM, Elf [EMAIL PROTECTED] wrote:
It would be nice if the handling of Connection: close
is consistent with http:POST and http:GET.
how is it inconsistent? http posts should close connect afterwards, its not
a continuable operation, from my understandings.
That's
ah, apologies, then. i will fix it if desired.
i do notice that the default protocol version (at least for http:POST) is
1.0, however. (actually, theres no way through just a call to http:POST
to use anything BUT 1.0, since it seems to be the default in http:request,
and theres no arg for
Wow, it looks nice.
I'm not sure about the type specified is only meaning-full
if the content-type was empty. A user might expect the type
to be overwritten.
It would be nice if the handling of Connection: close
is consistent with http:POST and http:GET.
BTW, is the old place
its in the repo at
https://galinha.ucpel.tche.br/svn/chicken-eggs/release/3/http/trunk
or should be at least.
and if youre using chicken v3, it should be avilable via regular
chicken-setup within an hour or so, i think.
-elf
On Wed, 13 Feb 2008, Daishi Kato wrote:
Well, of cource we can
snip
Hm, probably.
I was thinking of reusing http:request object,
which would be used both for http:GET and http:POST, for example.
It would be nice if the handling of Connection: close
is consistent with http:POST and http:GET.
oh, i added a utility procedure to take care of those sorts
On Feb 13, 2008 4:19 PM, Elf [EMAIL PROTECTED] wrote:
apologies. i can revert if desired. i just had a large block of code that
was breaking due to the prior implementations assumptions.
I just mean that it's pointless to ask, if you don't give everybody
a chance to react. I'm not grumbling,
On Wed, 13 Feb 2008, Graham Fawcett wrote:
On Feb 13, 2008 11:05 AM, Elf [EMAIL PROTECTED] wrote:
Here, http:POST overwrite Connection header in req.
I guess correct behavior is of http:GET,
because with HTTP/1.1 the absence of the Connection header
means keep-alive.
a
Oh, or are you saying
snip
When you've forgotten more than you remember, you know you have arrived. ;-)
If you have some ice cream, I will give it to you.
If you have no ice cream, I will take it away from you.
-- an ice cream koan
The take-home point, I think, is that implementing a protocol
On Feb 13, 2008 12:17 PM, Elf [EMAIL PROTECTED] wrote:
Right. It takes a lot more work to write a correct HTTP 1.1 client;
there are many new issues that are considered MUSTs in RFC-speak:
307 redirects, transfer encoding, etc.
hm, this is offtopic of course, but methinks it would be
On Feb 13, 2008 1:18 AM, felix winkelmann [EMAIL PROTECTED] wrote:
In my experience separating the documentation from the code leads
in the end to more consistent information. I've seen too much doxygen
generated documentation heaps with no obvious start or beginning.
Well that's not the
On Feb 13, 2008 1:44 AM, Peter Bex [EMAIL PROTECTED] wrote:
Another problem of 'rdoc-like' documentation is that you end up having to
wade through piles and piles of documentation in the code when you're
looking for something. Just look at the Rails code, some classes start
with several
On Wed, 13 Feb 2008, Graham Fawcett wrote:
On Feb 13, 2008 12:45 PM, Elf [EMAIL PROTECTED] wrote:
aye, i wasnt trying to say or imply that we should be concerned with a
full-fledged 1.1 client, i just wanted to know if there are problems with
the changes i made this morning :)
Nope,
On Feb 13, 2008 12:45 PM, Elf [EMAIL PROTECTED] wrote:
aye, i wasnt trying to say or imply that we should be concerned with a
full-fledged 1.1 client, i just wanted to know if there are problems with
the changes i made this morning :)
Nope, personally I don't mind the change.
G
(Where the
On Wed, 13 Feb 2008, Shawn Rutledge wrote:
snip
That's why there shouldn't be all these doc overhauls, there should
be just one, resulting in proper documentation.
It's better to work smart, not hard. That means start by building the
tools, to minimize the tedium. A good example (outside
On Feb 13, 2008 12:04 PM, Elf [EMAIL PROTECTED] wrote:
not always true. tex was better before the cycle of 'continuous
improvements',
The early development was before my time, but I don't think TeX
emerged fully-formed. Knuth came up with that version scheme where he
adds digits to pi for
On Wed, 13 Feb 2008, Shawn Rutledge wrote:
snip
All I'm hoping for as a starting point is a way to write parseable
comments that can be converted into API docs. The other stuff can be
added later; a be-all documentation system cannot be expected to
emerge fully formed either. I will always
Sorry to interrupt this rather high-level discussion on semantics and
stuffs with another of my pedestrian concerns, but when you do all
this wonderful work, could you be a little more specific as to what
license the eggs are under?
For 98% I can tell from looking inside the doc page, but for a
At Wed, 13 Feb 2008 08:05:45 -0800 (PST),
Elf wrote:
oh, i added a utility procedure to take care of those sorts of cases. if
youre reusing a connect, you can now do
(http:request-attribute-add! reqobj attribname val) , which will either
add the attrib if its not there or change the
heya.
to the best of my knowledge most of the currently maintained eggs are BSD
licenced, not (L)GPLvN (except for Ivan's). since theyve mostly been
ported from elsewhere, or are library bindings, it should be fairly easy
to see the dates of creation or what the licence of the bound lib
snip
OK, since I need partial support for HTTP/1.1,
plase do either the followings:
a) modify http:POST so that Connection: close is added
only if the req is string.
what if i do a protocol-version check before adding the conenction close, so
as to preserve proper behaviour under 1.0 ? ie,
the v3 repo should now reflect the change (no Connection:close for 1.1)
-elf
On Thu, 14 Feb 2008, Daishi Kato wrote:
At Wed, 13 Feb 2008 08:05:45 -0800 (PST),
Elf wrote:
oh, i added a utility procedure to take care of those sorts of cases. if
youre reusing a connect, you can now do
Elf, do you mind not spreading incorrect information?
$ find . -wholename '*/trunk/*.meta' -exec grep GPL '{}' ';' | wc -l
43
$ find . -wholename '*/trunk/*.meta' -exec grep MIT '{}' ';' | wc -l
22
$ find . -wholename '*/trunk/*.meta' -exec grep SRFI '{}' ';' | wc -l
13
$ find . -wholename
i was only referring to currently maintained eggs, as i stated in the post,
and only to those with (L)GPL licensing. all i SAID was that most
currently maintained eggs are released under BSD, and how to find the
licence revision for the LGPL eggs that have been ported from elsewhere.
the
Well, it is simply not true. Source code with a non-BSD license that
gets imported as an egg does not magically become BSD-licensed. There
are also many eggs that are actively in use that are not licensed
under the BSD. For example, most of the prerequisites of svnwiki are
licensed under the
Ivan == Ivan Raikov [EMAIL PROTECTED] writes:
Ivan Well, it is simply not true. Source code with a non-BSD
Ivan license that gets imported as an egg does not magically
Ivan become BSD-licensed. There are also many eggs that are
Ivan actively in use that are not licensed under
On 14/02/2008, Ivan Raikov [EMAIL PROTECTED] wrote:
By the way, if the egg licenses are an issue for any distribution,
then one might consider the Debian approach -- if the license for a
particular package is incompatible with Debian, in many cases this is
dealt with by approaching the
a general question for the public, as this is the second time in three days
where this has happened:
when did 'most' start meaning 'all'? i missed that communique.
-elf
On Thu, 14 Feb 2008, Ivan Raikov wrote:
Well, it is simply not true. Source code with a non-BSD license that
gets
On Feb 13, 2008 8:46 PM, Leonardo Valeri Manera
[EMAIL PROTECTED] wrote:
We don't have license limitations on gentoo, but I still have to
specify what license each package is under... since we're on the
subject, exactly what version of the LGPL are 'awk' and 'make' under?
They are under the
We don't have license limitations on gentoo, but I still have to
specify what license each package is under... since we're on the
subject, exactly what version of the LGPL are 'awk' and 'make' under?
for make, whatever version of lgpl was active in 2002, like it says on the
webpage (or would
i didnt say ANYTHING about how anything SHOULD be, at any point.
brief synopsis:
leonardo asked about which licence versions were associated with eggs,
focusing primarily on the gpled eggs in the repo, and asked about how to
obtain information relating to versions where it wasnt obvious.
i
One of the aspects of Chicken that appeals to me is the relative
freedom we have in contributing eggs. The lack of strict requirements
about license, documentation, etc., perhaps mirrors the minimalistic
nature of Scheme itself (or R5RS, I should say). When somebody starts
making statements
On Feb 13, 2008 9:01 PM, Elf [EMAIL PROTECTED] wrote:
On Wed, 13 Feb 2008, Graham Fawcett wrote:
On Feb 13, 2008 8:46 PM, Leonardo Valeri Manera
[EMAIL PROTECTED] wrote:
We don't have license limitations on gentoo, but I still have to
specify what license each package is under... since
On 14/02/2008, Graham Fawcett [EMAIL PROTECTED] wrote:
On Feb 13, 2008 8:46 PM, Leonardo Valeri Manera
[EMAIL PROTECTED] wrote:
We don't have license limitations on gentoo, but I still have to
specify what license each package is under... since we're on the
subject, exactly what version of
On Wed, 13 Feb 2008, Graham Fawcett wrote:
On Feb 13, 2008 8:46 PM, Leonardo Valeri Manera
[EMAIL PROTECTED] wrote:
We don't have license limitations on gentoo, but I still have to
specify what license each package is under... since we're on the
subject, exactly what version of the LGPL are
Then I don't understand what you mean by the peculiar phrase
currently maintained. There are many eggs in the Chicken repository
that work perfectly fine and are not BSD licensed. If one of those is
discovered to have become broken because of changes in the core
Chicken functionality, then it
Hi all,
I still think focusing on documentation is still a good idea for a
Hackathon goal, even if it has proven divisive. While I certainly have
opinions on the subject, I'd like to propose a compromise to keep us
moving forward.
1. Our primary focus is on updating documentation where
That's true, I should have said that the different licenses might
become an issue if you are distributing several eggs together. Though
I am not overly worried about GPL violations in distributions
of machine-generated C code, so that might be a sensible exception
clause to add GPLed eggs.
Ivan Raikov scripsit:
The inconsistent licenses for the
eggs don't matter with Chicken, because the Chicken itself is not
distributed together with any eggs, but this might become an issue for
a Linux distribution.
Not only that, but if you want to deliver an application in C form,
you have
Elf scripsit:
to the best of my knowledge most of the currently maintained eggs are BSD
licenced, not (L)GPLvN (except for Ivan's). since theyve mostly been
ported from elsewhere, or are library bindings, it should be fairly easy
to see the dates of creation or what the licence of the bound
actually, at least by my understanding, GPL in this case is particularly
interesting legally. while the 'do linked GPL libs make the linked programs
derivative works' question is still unknown, this is an instance of GPL'ed
libs being linked in only explicitly by the user so when one uses
On Thu, Feb 14, 2008 at 5:25 AM, Mark Fredrickson
[EMAIL PROTECTED] wrote:
Hi all,
I still think focusing on documentation is still a good idea for a
Hackathon goal, even if it has proven divisive. While I certainly have
opinions on the subject, I'd like to propose a compromise to keep us
59 matches
Mail list logo
