Hi,
Here are two patches[1][2] for both flexi-streams and hunchentoot. First patch makes flexi-streams to signal a condition when stream BOUND gets exceeded -- documentation and tests are included. Second one uses freshly introduced flexi-streams feature to limit the maximum request size.
The latter hunchentoot patch is not well tested, doesn't include any documentation, replaces (raw-post-data ...) call with (clear-input ...) to flush the input stream (thus, can have chunking and common lisp implementation/platform related problems). It appears to be working for me, I hope it would for you as well.
Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort.
Regards.
P.S. Enhancements are patched against the repositories located at http://bknr.net/svn/ediware address.
[1] http://www.students.itu.edu.tr/~yazicivo/tmp/flexi-streams-bound-invalidatio...
[2] http://www.students.itu.edu.tr/~yazicivo/tmp/hunchentoot-request-size-limit....
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI yazicivo@ttmail.com wrote:
Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
Hello everyone...
I would like to volunteer any amount of time needed to get Hans's changes folded into the main repository and/or get the development version moving forward and more accessible. I am working on a startup that is currently using hunchentoot and, as chance may have it, I am right about now going to be digging into hunchentoot and friends as part of a performance and understanding push.
Currently the BKNR repository is down, but once it gets back up I would like to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma and I invite anyone that wishes to help contribute to this effort.
I am most interested in figuring out and testing the performance characteristics of the libraries with respects to threading/non-threading, select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the time and effort to develop and test these different scenarios.
Thanks to everyone.
Peace, Will
On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI yazicivo@ttmail.com wrote:
Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi,
bknr.net was temporarily down due to a power failure at the data center. The machine is back up now.
What is the plan for the git repository? Why is it needed, what makes it useful? I'm aware of the "centralized maintenance" "problem" of Subversion, but as Hunchentoot is not going to convert into a community project (i.e. we'll review all patches that we accept into the repository that eventually becomes the release), I'm not sure how another level of indirection helps. It may be possible to convince us to switch to git if there is a good reason to do so, but that'd need some explanation.
-Hans
On Thu, Jan 29, 2009 at 18:28, William Halliburton whalliburton@gmail.com wrote:
Hello everyone...
I would like to volunteer any amount of time needed to get Hans's changes folded into the main repository and/or get the development version moving forward and more accessible. I am working on a startup that is currently using hunchentoot and, as chance may have it, I am right about now going to be digging into hunchentoot and friends as part of a performance and understanding push.
Currently the BKNR repository is down, but once it gets back up I would like to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma and I invite anyone that wishes to help contribute to this effort.
I am most interested in figuring out and testing the performance characteristics of the libraries with respects to threading/non-threading, select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the time and effort to develop and test these different scenarios.
Thanks to everyone.
Peace, Will
On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI yazicivo@ttmail.com wrote:
Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi Hans,
I wont be a fanboy here and express the benefits of git over svn, but the coolaid tasted great!
I figured from the gist of Edi's original post that there just isn't enough time (understandably) to move hunchentoot forward and I believe that garnering a little community support on this worthwhile, at least to me, project would be helped by converting it into a "community project", and a distributed decentralized development model should help in that regard.
Will
On Thu, Jan 29, 2009 at 2:27 PM, Hans Hübner hans.huebner@gmail.com wrote:
Hi,
bknr.net was temporarily down due to a power failure at the data center. The machine is back up now.
What is the plan for the git repository? Why is it needed, what makes it useful? I'm aware of the "centralized maintenance" "problem" of Subversion, but as Hunchentoot is not going to convert into a community project (i.e. we'll review all patches that we accept into the repository that eventually becomes the release), I'm not sure how another level of indirection helps. It may be possible to convince us to switch to git if there is a good reason to do so, but that'd need some explanation.
-Hans
On Thu, Jan 29, 2009 at 18:28, William Halliburton whalliburton@gmail.com wrote:
Hello everyone...
I would like to volunteer any amount of time needed to get Hans's changes folded into the main repository and/or get the development version moving forward and more accessible. I am working on a startup that is currently using hunchentoot and, as chance may have it, I am right about now going
to
be digging into hunchentoot and friends as part of a performance and understanding push.
Currently the BKNR repository is down, but once it gets back up I would
like
to set up a git repository of flexi-streams, hunchentoot, chunga, and
drakma
and I invite anyone that wishes to help contribute to this effort.
I am most interested in figuring out and testing the performance characteristics of the libraries with respects to
threading/non-threading,
select/epoll, and proxy/no-proxy on SBCL and am most willing to put in
the
time and effort to develop and test these different scenarios.
Thanks to everyone.
Peace, Will
On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI yazicivo@ttmail.com wrote:
Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
What is the plan for the git repository? Why is it needed, what makes it useful?
i find the following feature helpful (YMMV)
http://github.com/guides/pull-requests
it will be a helpful tool of using git to allow for easy forks and experimentation and easy cherry pick any changes made by other forks.
cmo-0
On Thu, Jan 29, 2009 at 11:27 PM, Hans Hübner hans.huebner@gmail.com wrote:
Hi,
bknr.net was temporarily down due to a power failure at the data center. The machine is back up now.
I'm aware of the "centralized maintenance" "problem" of
Subversion, but as Hunchentoot is not going to convert into a community project (i.e. we'll review all patches that we accept into the repository that eventually becomes the release), I'm not sure how another level of indirection helps. It may be possible to convince us to switch to git if there is a good reason to do so, but that'd need some explanation.
-Hans
On Thu, Jan 29, 2009 at 18:28, William Halliburton whalliburton@gmail.com wrote:
Hello everyone...
I would like to volunteer any amount of time needed to get Hans's changes folded into the main repository and/or get the development version moving forward and more accessible. I am working on a startup that is currently using hunchentoot and, as chance may have it, I am right about now going to be digging into hunchentoot and friends as part of a performance and understanding push.
Currently the BKNR repository is down, but once it gets back up I would like to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma and I invite anyone that wishes to help contribute to this effort.
I am most interested in figuring out and testing the performance characteristics of the libraries with respects to threading/non-threading, select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the time and effort to develop and test these different scenarios.
Thanks to everyone.
Peace, Will
On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI yazicivo@ttmail.com wrote:
Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
It would be, but (at the risk of being presumptuous) allowing for easy forks and experimentation is not the goal of the maintainers.
I could see that as being the goal of a person that wanted to fork the code and/or experiment. As Edi said, you have the freedom to fork..., or not.
Chris.
On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote:
What is the plan for the git repository? Why is it needed, what makes it useful?
i find the following feature helpful (YMMV)
http://github.com/guides/pull-requests
it will be a helpful tool of using git to allow for easy forks and experimentation and easy cherry pick any changes made by other forks.
cmo-0
On Thu, Jan 29, 2009 at 11:27 PM, Hans Hübner hans.huebner@gmail.com wrote:
Hi,
bknr.net was temporarily down due to a power failure at the data center. The machine is back up now.
I'm aware of the "centralized maintenance" "problem" of
Subversion, but as Hunchentoot is not going to convert into a community project (i.e. we'll review all patches that we accept into the repository that eventually becomes the release), I'm not sure how another level of indirection helps. It may be possible to convince us to switch to git if there is a good reason to do so, but that'd need some explanation.
-Hans
On Thu, Jan 29, 2009 at 18:28, William Halliburton whalliburton@gmail.com wrote:
Hello everyone...
I would like to volunteer any amount of time needed to get Hans's changes folded into the main repository and/or get the development version moving forward and more accessible. I am working on a startup that is currently using hunchentoot and, as chance may have it, I am right about now going to be digging into hunchentoot and friends as part of a performance and understanding push.
Currently the BKNR repository is down, but once it gets back up I would like to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma and I invite anyone that wishes to help contribute to this effort.
I am most interested in figuring out and testing the performance characteristics of the libraries with respects to threading/non- threading, select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the time and effort to develop and test these different scenarios.
Thanks to everyone.
Peace, Will
On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo@ttmail.com
wrote:
Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- It does not matter how fast your code is, if it does not work!
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Hi,
On 29-Jan-09, at 6:17 PM, Chris Van Dusen wrote:
It would be, but (at the risk of being presumptuous) allowing for easy forks and experimentation is not the goal of the maintainers.
I could see that as being the goal of a person that wanted to fork the code and/or experiment. As Edi said, you have the freedom to fork..., or not.
This 'fork' business when using git seems to be more due to github than git, and doesn't normally mean a forked project like, say, the Joomla/Mambo fork, or even the sbcl/cmucl fork. Github provides a bunch of tools that allow for core maintainers (e.g. Edi and Hans) to keep control of the code base but to have other people contribute (without worrying about things like commit privileges, and messed up patch files). This made a *huge* difference to the Rails project starting last April or so. These two links give more information along the lines of that on the page linked to by cmo-0:
http://github.com/guides/fork-a-project-and-submit-your-modifications http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch
And they give you shiny baubles like:
http://github.com/madrobby/scriptaculous/network
This is the arbitrarily chosen (near the top of the most-forked list with a few forks yet to be pulled) scrit.aculo.us project, 292 forks -- but still only one script.aculo.us :-)
I've been using github for my company and my personal work for about 10 months now. Works well for me. Big wins:
-- works off line -- branching and tagging easy and fast -- master branch can be 'rebased' into the branches, and the branches commited as though a single commit (you can, if you want, lose all those micro commits and sub-branches -- if you look at the github network/fork graph, each of the forks can be reduced into a single 'dot' on the master branch, or not). -- commits are orders of magnitude faster than SVN, at least for me.
I think git might make things easier for Edi and Hans at the cost of having to learn it. More importantly, things like Volkan's patch might be better tested or improved by having people contribute to the fork rather than the master branch. Keep this kind of thing out of their hair until it's more ready.
Cheers, Bob
Chris.
On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote:
What is the plan for the git repository? Why is it needed, what makes it useful?
i find the following feature helpful (YMMV)
http://github.com/guides/pull-requests
it will be a helpful tool of using git to allow for easy forks and experimentation and easy cherry pick any changes made by other forks.
cmo-0
On Thu, Jan 29, 2009 at 11:27 PM, Hans Hübner hans.huebner@gmail.com wrote:
Hi,
bknr.net was temporarily down due to a power failure at the data center. The machine is back up now.
I'm aware of the "centralized maintenance" "problem" of
Subversion, but as Hunchentoot is not going to convert into a community project (i.e. we'll review all patches that we accept into the repository that eventually becomes the release), I'm not sure how another level of indirection helps. It may be possible to convince us to switch to git if there is a good reason to do so, but that'd need some explanation.
-Hans
On Thu, Jan 29, 2009 at 18:28, William Halliburton whalliburton@gmail.com wrote:
Hello everyone...
I would like to volunteer any amount of time needed to get Hans's changes folded into the main repository and/or get the development version moving forward and more accessible. I am working on a startup that is currently using hunchentoot and, as chance may have it, I am right about now going to be digging into hunchentoot and friends as part of a performance and understanding push.
Currently the BKNR repository is down, but once it gets back up I would like to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma and I invite anyone that wishes to help contribute to this effort.
I am most interested in figuring out and testing the performance characteristics of the libraries with respects to threading/non- threading, select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the time and effort to develop and test these different scenarios.
Thanks to everyone.
Peace, Will
On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo@ttmail.com
wrote:
Thanks Hans Huebner for his kindly helps and Edi Weitz for his uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- It does not matter how fast your code is, if it does not work!
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
---- Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://www.recursive.ca/hutch
Yes! That the idea. Not to actually take any control away from the maintainers but to open up the field to branching and experimental work, while giving the maintainers the ability to easily cherry pick the desirable branches.
To me, that's *the* main difference in distributed rcs, you *pull* from other people, not *push* into a central repository.
On Thu, Jan 29, 2009 at 11:22 PM, Bob Hutchison hutch-lists@recursive.cawrote:
Hi,
On 29-Jan-09, at 6:17 PM, Chris Van Dusen wrote:
It would be, but (at the risk of being presumptuous) allowing for easy forks and experimentation is not the goal of the maintainers.
I could see that as being the goal of a person that wanted to fork the code and/or experiment. As Edi said, you have the freedom to fork..., or not.
This 'fork' business when using git seems to be more due to github than git, and doesn't normally mean a forked project like, say, the Joomla/Mambo fork, or even the sbcl/cmucl fork. Github provides a bunch of tools that allow for core maintainers (e.g. Edi and Hans) to keep control of the code base but to have other people contribute (without worrying about things like commit privileges, and messed up patch files). This made a *huge* difference to the Rails project starting last April or so. These two links give more information along the lines of that on the page linked to by cmo-0:
http://github.com/guides/fork-a-project-and-submit-your-modifications http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch
And they give you shiny baubles like:
http://github.com/madrobby/scriptaculous/network
This is the arbitrarily chosen (near the top of the most-forked list with a few forks yet to be pulled) scrit.aculo.us project, 292 forks -- but still only one script.aculo.us :-)
I've been using github for my company and my personal work for about 10 months now. Works well for me. Big wins:
-- works off line -- branching and tagging easy and fast -- master branch can be 'rebased' into the branches, and the branches commited as though a single commit (you can, if you want, lose all those micro commits and sub-branches -- if you look at the github network/fork graph, each of the forks can be reduced into a single 'dot' on the master branch, or not). -- commits are orders of magnitude faster than SVN, at least for me.
I think git might make things easier for Edi and Hans at the cost of having to learn it. More importantly, things like Volkan's patch might be better tested or improved by having people contribute to the fork rather than the master branch. Keep this kind of thing out of their hair until it's more ready.
Cheers, Bob
Chris.
On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote:
What is the plan for the git repository? Why is it needed, what makes it useful?
i find the following feature helpful (YMMV)
http://github.com/guides/pull-requests
it will be a helpful tool of using git to allow for easy forks and experimentation and easy cherry pick any changes made by other forks.
cmo-0
On Thu, Jan 29, 2009 at 11:27 PM, Hans Hübner hans.huebner@gmail.com wrote:
Hi,
bknr.net was temporarily down due to a power failure at the data center. The machine is back up now.
I'm aware of the "centralized maintenance" "problem" of
Subversion, but as Hunchentoot is not going to convert into a community project (i.e. we'll review all patches that we accept into the repository that eventually becomes the release), I'm not sure how another level of indirection helps. It may be possible to convince us to switch to git if there is a good reason to do so, but that'd need some explanation.
-Hans
On Thu, Jan 29, 2009 at 18:28, William Halliburton whalliburton@gmail.com wrote:
Hello everyone...
I would like to volunteer any amount of time needed to get Hans's changes folded into the main repository and/or get the development version moving forward and more accessible. I am working on a startup that is currently using hunchentoot and, as chance may have it, I am right about now going to be digging into hunchentoot and friends as part of a performance and understanding push.
Currently the BKNR repository is down, but once it gets back up I would like to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma and I invite anyone that wishes to help contribute to this effort.
I am most interested in figuring out and testing the performance characteristics of the libraries with respects to threading/non- threading, select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the time and effort to develop and test these different scenarios.
Thanks to everyone.
Peace, Will
On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo@ttmail.com > wrote:
> Thanks Hans Huebner for his kindly helps and Edi Weitz for his > uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- It does not matter how fast your code is, if it does not work!
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://www.recursive.ca/hutch
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Fri, Jan 30, 2009 at 07:06, William Halliburton whalliburton@gmail.com wrote:
Yes! That the idea. Not to actually take any control away from the maintainers but to open up the field to branching and experimental work, while giving the maintainers the ability to easily cherry pick the desirable branches.
To me, that's *the* main difference in distributed rcs, you *pull* from other people, not *push* into a central repository.
Right. Huchentoot (and Edi's libraries in general) follow a "push" development model, so a distributed rcs does not help. You can certainly create a fork that is using a different development model.
I'm a bit unsure that we're solving any problem with this discussion. As far as I can see, the current model does work. I would thus propose that we stick with it, as it guarantees a certain level of quality, documentation and bug fix throughput. Instead of discussing revision control systems, we should be discussing changes to Hunchentoot, and those are certainly not dependent on the version control system that is used.
As a start, someone could revise Volcan's patch, or come up with a proposal for event oriented processing or thread pools.
If we, at a later time, detect that Edi and I cannot handle the patch volume pushed to us, we can still reconsider.
-Hans
On Fri, Jan 30, 2009 at 08:49:30AM +0100, Hans Hübner wrote:
I'm a bit unsure that we're solving any problem with this discussion. As far as I can see, the current model does work. I would thus propose that we stick with it, as it guarantees a certain level of quality, documentation and bug fix throughput.
On frustrating aspect of the current state of development is that minor fixes to seemingly unrelated libraries do not get applied or rejected, but hang in limbo. (Why should Hunchentoot hold up Drakma changes?)
Zach
On Fri, Jan 30, 2009 at 10:39, Zach Beane xach@xach.com wrote:
On Fri, Jan 30, 2009 at 08:49:30AM +0100, Hans Hübner wrote:
I'm a bit unsure that we're solving any problem with this discussion. As far as I can see, the current model does work. I would thus propose that we stick with it, as it guarantees a certain level of quality, documentation and bug fix throughput.
On frustrating aspect of the current state of development is that minor fixes to seemingly unrelated libraries do not get applied or rejected, but hang in limbo. (Why should Hunchentoot hold up Drakma changes?)
I can agree with that, and as Edi described, there is a certain, singular cause for that, but said company seems to begin to move. It is fair to say that Edi has always been very diligent and prompt in fixing bugs in his libraries as long as he was the only one who had control over the source code. What we now need is a workable model to get the development process to move forward again without sacrificing the quality of both the source code and the documentation of Edi's software. If you want to check out something from a source code control system and work yourself through tests and sparse examples, there are other HTTP libraries that one can work with.
-Hans
On Fri, Jan 30, 2009 at 4:39 AM, Zach Beane xach@xach.com wrote:
Why should Hunchentoot hold up Drakma changes?
The dev version of Drakma is different from the release version and it depends on the dev version of Chunga which is incompatible with the released versions of Drakma and Hunchentoot. So, as I said earlier, all three libraries have to be updated at once. It is currently unfortunately not possible to apply "quick fixes" to one of them and I hate the situation as much as everyone else.
As Hans said, there has been some movement in the last days and we might see the light at the end of the tunnel soon.
Egads.
My comment was not to beat the dead horse of why Git will save the world, but that using any other version control other than what the project is currently using is a distraction from the goal(s) of the project itself. The Slime mailing list went through this same thing a while back, and I it never got resolved.
When I said "fork" I meant if you want to maintain the code under some version control, go right ahead, but don't clutter the mailing list with advocacy for version control. On the other hand, I guess I could go to the version control mailing lists and tell them that they should be using Hunchentoot for their projects' web site.
Chris.
On Jan 29, 2009, at 10:22 PM, Bob Hutchison wrote:
Hi,
On 29-Jan-09, at 6:17 PM, Chris Van Dusen wrote:
It would be, but (at the risk of being presumptuous) allowing for easy forks and experimentation is not the goal of the maintainers.
I could see that as being the goal of a person that wanted to fork the code and/or experiment. As Edi said, you have the freedom to fork..., or not.
This 'fork' business when using git seems to be more due to github than git, and doesn't normally mean a forked project like, say, the Joomla/Mambo fork, or even the sbcl/cmucl fork. Github provides a bunch of tools that allow for core maintainers (e.g. Edi and Hans) to keep control of the code base but to have other people contribute (without worrying about things like commit privileges, and messed up patch files). This made a *huge* difference to the Rails project starting last April or so. These two links give more information along the lines of that on the page linked to by cmo-0:
<http://github.com/guides/fork-a-project-and-submit-your- modifications> <http://railsontherun.com/2008/3/3/how-to-use-github-and-submit-a-patch
And they give you shiny baubles like:
http://github.com/madrobby/scriptaculous/network
This is the arbitrarily chosen (near the top of the most-forked list with a few forks yet to be pulled) scrit.aculo.us project, 292 forks -- but still only one script.aculo.us :-)
I've been using github for my company and my personal work for about 10 months now. Works well for me. Big wins:
-- works off line -- branching and tagging easy and fast -- master branch can be 'rebased' into the branches, and the branches commited as though a single commit (you can, if you want, lose all those micro commits and sub-branches -- if you look at the github network/fork graph, each of the forks can be reduced into a single 'dot' on the master branch, or not). -- commits are orders of magnitude faster than SVN, at least for me.
I think git might make things easier for Edi and Hans at the cost of having to learn it. More importantly, things like Volkan's patch might be better tested or improved by having people contribute to the fork rather than the master branch. Keep this kind of thing out of their hair until it's more ready.
Cheers, Bob
Chris.
On Jan 29, 2009, at 3:15 PM, Ala'a (cmo-0) wrote:
What is the plan for the git repository? Why is it needed, what makes it useful?
i find the following feature helpful (YMMV)
http://github.com/guides/pull-requests
it will be a helpful tool of using git to allow for easy forks and experimentation and easy cherry pick any changes made by other forks.
cmo-0
On Thu, Jan 29, 2009 at 11:27 PM, Hans Hübner hans.huebner@gmail.com wrote:
Hi,
bknr.net was temporarily down due to a power failure at the data center. The machine is back up now.
I'm aware of the "centralized maintenance" "problem" of
Subversion, but as Hunchentoot is not going to convert into a community project (i.e. we'll review all patches that we accept into the repository that eventually becomes the release), I'm not sure how another level of indirection helps. It may be possible to convince us to switch to git if there is a good reason to do so, but that'd need some explanation.
-Hans
On Thu, Jan 29, 2009 at 18:28, William Halliburton whalliburton@gmail.com wrote:
Hello everyone...
I would like to volunteer any amount of time needed to get Hans's changes folded into the main repository and/or get the development version moving forward and more accessible. I am working on a startup that is currently using hunchentoot and, as chance may have it, I am right about now going to be digging into hunchentoot and friends as part of a performance and understanding push.
Currently the BKNR repository is down, but once it gets back up I would like to set up a git repository of flexi-streams, hunchentoot, chunga, and drakma and I invite anyone that wishes to help contribute to this effort.
I am most interested in figuring out and testing the performance characteristics of the libraries with respects to threading/non- threading, select/epoll, and proxy/no-proxy on SBCL and am most willing to put in the time and effort to develop and test these different scenarios.
Thanks to everyone.
Peace, Will
On Thu, Jan 29, 2009 at 7:52 AM, Edi Weitz edi@agharta.de wrote:
On Wed, Jan 21, 2009 at 11:22 AM, Volkan YAZICI <yazicivo@ttmail.com > wrote:
> Thanks Hans Huebner for his kindly helps and Edi Weitz for his > uninterest in any effort.
Volkan,
If you think you're somehow entitled to an immediate reply or any action from me just because you sent a patch that is "not well tested" and "doesn't include any documentation", you're obviously living on a different planet or at least you don't know what it means to have a job and a family in addition to taking care of more than a dozen open source libraries in your spare time. I might look at these patches if and when I find the time to work on Hunchentoot again or I might not. If that's not acceptable to you, the license on all of my libs always allows you to fork them and basically do with them whatever you want.
For those of you who wonder why Hunchentoot and some other libraries have been in limbo for quite some time now, here's a quick explanation: A company paid Hans to make a couple of additions to Hunchentoot which are now in the bknr.net repository. I also worked on this a bit in my spare time and added some code, mainly for performance improvements. The good thing is that due to Hans' work the development version is much improved in several aspects over the current release. The bad thing is that due to Hans' and my changes the dev versions of Hunchentoot, Chunga, and Drakma have to be released together, because they are mutually incompatible with the released versions. And, for them to become acceptable (for me) release versions, there's a certain amount of clean-up and documentation needed that still has to be done.
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do. /Maybe/, this will happen in the future (paid or unpaid), or maybe there'll at some point just be another Hunchentoot release based on 0.15.7 and the dev changes will be lost. Until then, I think the current release isn't perfect, but certainly something that can be used (and is used) without significant problems.
Cheers, Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-- It does not matter how fast your code is, if it does not work!
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://www.recursive.ca/hutch
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Am 01.02.2009 um 05:06 schrieb Chris Van Dusen:
Egads.
My comment was not to beat the dead horse of why Git will save the world, but that using any other version control other than what the project is currently using is a distraction from the goal(s) of the project itself. The Slime mailing list went through this same thing a while back, and I it never got resolved.
When I said "fork" I meant if you want to maintain the code under some version control, go right ahead, but don't clutter the mailing list with advocacy for version control. On the other hand, I guess I could go to the version control mailing lists and tell them that they should be using Hunchentoot for their projects' web site.
Well said!
actually my experience is, that a well done distributed version control system should allow anyone to track a central CVS/SVN repository WITHOUT urging the developers to change their ways. If the release is done, the question may rise up again.
I fully understand Hans and Edi, that they want to get their project done their styles. Complete new features or major changes in project infrastructure are just unnecessary distractions. We as a community can help best by testing of whats there, reporting bugs or suggesting/ doing improvements in style and function. If help comes back as a patch it should be well tested, documented and in the sense of what the dev-branch tries to fix (no completely new things).
just my € 0.02
ciao, Jochen
-- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9 , 90408 Nuremberg
Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83
mailto:info@crispylogics.com http://www.crispylogics.com
On Sun, Feb 1, 2009 at 5:25 AM, Jochen Schmidt jsc@crispylogics.com wrote:
just my € 0.02
Well spent... :)
Thanks, Edi.
Egads is right.
I never intended to start such a discussion was not asking the maintainers to switch version control systems, just that I was about to set up a git repo to help in collaboration and anyone else interested in hacking on the devel version in that manner was happily invited.
Very easy to then push any collaborative patches back upstream.
Anyhow, I'll sink back into obscurity until I have some real code contributions.
Will
On Sun, Feb 1, 2009 at 5:25 AM, Jochen Schmidt jsc@crispylogics.com wrote:
Am 01.02.2009 um 05:06 schrieb Chris Van Dusen:
Egads.
My comment was not to beat the dead horse of why Git will save the world, but that using any other version control other than what the project is currently using is a distraction from the goal(s) of the project itself. The Slime mailing list went through this same thing a while back, and I it never got resolved.
When I said "fork" I meant if you want to maintain the code under some version control, go right ahead, but don't clutter the mailing list with advocacy for version control. On the other hand, I guess I could go to the version control mailing lists and tell them that they should be using Hunchentoot for their projects' web site.
Well said!
actually my experience is, that a well done distributed version control system should allow anyone to track a central CVS/SVN repository WITHOUT urging the developers to change their ways. If the release is done, the question may rise up again.
I fully understand Hans and Edi, that they want to get their project done their styles. Complete new features or major changes in project infrastructure are just unnecessary distractions. We as a community can help best by testing of whats there, reporting bugs or suggesting/ doing improvements in style and function. If help comes back as a patch it should be well tested, documented and in the sense of what the dev-branch tries to fix (no completely new things).
just my € 0.02
ciao, Jochen
-- Jochen Schmidt CRISPYLOGICS Uhlandstr. 9 , 90408 Nuremberg
Fon +49 (0)911 517 999 82 Fax +49 (0)911 517 999 83
mailto:info@crispylogics.com http://www.crispylogics.com
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Edi Weitz wrote:
Now, the deal with the afore-mentioned company was that they would pay Hans and me to do this clean-up and integration work so that we once again have "official" release versions that are feature-wise in sync with the current dev versions. This hasn't happened so far, and right now I fail to see why I should spend a significant amount of my spare time to do this clean-up work when I have more interesting things to do.
I haven't worked a lot on the dev version yet, but I have been planning to give it a spin for some time. (believe I read somewhere that the dev version would allow hunchentoot to run as an I/O multiplexer like select, epoll, etc., right?)
I also happen to have lots of spare time right now, and am willing to spend some of it on cleanup, documentation, etc. of the dev version, if possible. Any pointers or helpful hints on where to start?
Chaitanya
On Thu, Jan 29, 2009 at 2:04 PM, Chaitanya Gupta mail@chaitanyagupta.com wrote:
I haven't worked a lot on the dev version yet, but I have been planning to give it a spin for some time. (believe I read somewhere that the dev version would allow hunchentoot to run as an I/O multiplexer like select, epoll, etc., right?)
Not out of the box, but the new infrastructure should in theory allow that.
I also happen to have lots of spare time right now, and am willing to spend some of it on cleanup, documentation, etc. of the dev version, if possible. Any pointers or helpful hints on where to start?
One part of the work would be to look at all of the docstrings and to check if they still describe what the functions are actually doing. Another part would be to go over the HTML documentation and refactor it to explain the new infrastructure. I'm afraid the latter part can probably only be done by Hans and me as we're not even sure that the infrastructure will stay the way it is now. (It will likely be very similar to the current version, but there might be new names and some other reshuffling.)
Thanks to you and William for offering your help, but I'm not sure if having you working on the documentation would really buy us much right now. I'm pretty anal about this and I'd probably go over all of it once again anyway... :)
What is always helpful is more people testing the dev version, playing with it and finding and reporting bugs - as long as you don't expect an immediate reply or fix. You can be sure that all issues will be taken care of eventually. RSN...
Thanks, Edi.
-
Ala'a (cmo-0) -
Bob Hutchison -
Chaitanya Gupta -
Chris Van Dusen -
Edi Weitz -
Hans Hübner -
Jochen Schmidt -
Volkan YAZICI -
William Halliburton -
Zach Beane