You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
(8) |
Mar
(11) |
Apr
(22) |
May
(7) |
Jun
(13) |
Jul
(39) |
Aug
(13) |
Sep
(9) |
Oct
(6) |
Nov
(4) |
Dec
(12) |
2003 |
Jan
(3) |
Feb
(10) |
Mar
|
Apr
(26) |
May
(5) |
Jun
|
Jul
|
Aug
(9) |
Sep
(14) |
Oct
(5) |
Nov
(16) |
Dec
(21) |
2004 |
Jan
(19) |
Feb
(23) |
Mar
(2) |
Apr
|
May
(2) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(5) |
2005 |
Jan
(3) |
Feb
(10) |
Mar
(9) |
Apr
(3) |
May
(3) |
Jun
(4) |
Jul
(15) |
Aug
(3) |
Sep
|
Oct
(11) |
Nov
(1) |
Dec
(1) |
2006 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
(4) |
Oct
(16) |
Nov
(18) |
Dec
(2) |
2007 |
Jan
(4) |
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(31) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(16) |
Aug
(11) |
Sep
(18) |
Oct
(12) |
Nov
(14) |
Dec
(34) |
2009 |
Jan
(4) |
Feb
(16) |
Mar
(8) |
Apr
(19) |
May
(39) |
Jun
(22) |
Jul
(28) |
Aug
(8) |
Sep
(4) |
Oct
|
Nov
|
Dec
(9) |
2010 |
Jan
(9) |
Feb
(8) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(34) |
2013 |
Jan
(3) |
Feb
|
Mar
(10) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
|
Dec
|
From: Dave C. <dav...@ge...> - 2018-10-23 02:53:18
|
Hi Rudi, Sounds good, I will aim to lodge the new Merge Request by next week. We've already missed the October Quicklisp anyway, but I'd like to get updated paserve into the next one for sure. Thanks, Dave P.S. It looks like ke...@ro... isn't getting delivered - could remove that address from the portableaseve mailing list? On Fri, Oct 19, 2018 at 10:13 AM Rudi Schlatte <ru...@co...> wrote: > Hi Dave, I think your approach (both aserve.asd and paserve.asd in > portable allegroserve, with warnings when trying to load aserve.asd) is the > right one, and I’ll happily merge pull requests in that direction. We > might consider giving a fixed timeframe (“will be removed in 1 month and > point to zaserve in 2 months”) in the warning, if you feel up to committing > to such a timeframe. > > Rudi > > On 18 Oct 2018, at 17:24, Dave Cooper <dav...@ge...> wrote: > > > Hi Rudi, > > Thanks for your feedback. The thing is, I think the main issue here is the > ASDF system name "aserve" (which serves as a unique identifier for > Quicklisp as well) rather than the Lisp package name(s). > > I don't think there will be a use-case for having both zaserve and > paserve loaded at the same time into the same Lisp image, so I think > package names can and should remain as-is. Recall that aserve defines three > package names: net.aserve (with functions such as start, shutdown, and > various publish* functions), net.aserve.client (with functions such as > do-http-request), and net.html.generator with all the HTML-generating > macros (even though most people -- speaking for myself at least -- use > cl-who instead these days for that kind of stuff). My proposal is > certainly not to change these package names to net.zaserve and > net.zaserve.client in the new zaserve system nor net.paserve and > net.paserve.client in the old paserve system. > > So the only changes contemplated here for paserve are: > > 1. Change its aserve.asd to paserve.asd > > 2. In that file, change `defsystem aserve` to `defsystem paserve` (in two > places - one for the real system definition and the other for the "dummy" > system which just requires native :aserve when running on Allegro). > > Given this, I think your idea of staggered approach still makes sense. > Applying the concept to system name rather than package names, how about > the following: > > 1. We add paserve.asd, while keeping the aserve.asd for the time being (so > both systems will be available in Quicklisp for the time being). > > 2. For aserve.asd only, we print warnings at strategic places (maybe both > at system load time and when starting the server) indicating that "The ASDF > system name may be changing to "paserve" in the future" and "Please also > consider the new "zaserve (available for CCL and SBCL now, and welcoming > ports for other implementations)" > > 3. At the same time, the new zaserve will hopefully get added to Quicklisp > as well. > > So for an interim period at least, there will be "aserve" "paserve" and > "zaserve" all available in Quicklisp. > > After a few months, we can revisit the whole situation and decide how to > proceed from there... > > If this sounds acceptable, I'll go ahead and update my pull request > accordingly. > > Please advise, > > Dave > > > 1. paserve keeps the aserve package and adds the paserve package, adds >> documentation saying “please adapt your defpackage forms”; possibly also >> adds a runtime warning when calling some choice function (e.g., >> (aserve:start) instead of (paserve:start)) >> >> 2. After n quicklisp releases (for sufficiently small amounts of n) >> paserve stops defining the aserve package; zaserve picks it up either >> immediately or after 1-2 release cycles. >> >> I’m happy to accept a pull request implementing 1. immediately, since >> it’s not a breaking change for anyone. I’ll also happily accept a pull >> request implementing 2. some time afterwards, and hand over the aserve >> package name to its rightful home :) >> >> Rudi >> >> > > -- My Best, Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979 |
From: Rudi S. <ru...@co...> - 2018-10-19 14:13:36
|
Hi Dave, I think your approach (both aserve.asd and paserve.asd in portable allegroserve, with warnings when trying to load aserve.asd) is the right one, and I’ll happily merge pull requests in that direction. We might consider giving a fixed timeframe (“will be removed in 1 month and point to zaserve in 2 months”) in the warning, if you feel up to committing to such a timeframe. Rudi > On 18 Oct 2018, at 17:24, Dave Cooper <dav...@ge...> wrote: > > > Hi Rudi, > > Thanks for your feedback. The thing is, I think the main issue here is the ASDF system name "aserve" (which serves as a unique identifier for Quicklisp as well) rather than the Lisp package name(s). > > I don't think there will be a use-case for having both zaserve and paserve loaded at the same time into the same Lisp image, so I think package names can and should remain as-is. Recall that aserve defines three package names: net.aserve (with functions such as start, shutdown, and various publish* functions), net.aserve.client (with functions such as do-http-request), and net.html.generator with all the HTML-generating macros (even though most people -- speaking for myself at least -- use cl-who instead these days for that kind of stuff). My proposal is certainly not to change these package names to net.zaserve and net.zaserve.client in the new zaserve system nor net.paserve and net.paserve.client in the old paserve system. > > So the only changes contemplated here for paserve are: > > 1. Change its aserve.asd to paserve.asd > > 2. In that file, change `defsystem aserve` to `defsystem paserve` (in two places - one for the real system definition and the other for the "dummy" system which just requires native :aserve when running on Allegro). > > Given this, I think your idea of staggered approach still makes sense. Applying the concept to system name rather than package names, how about the following: > > 1. We add paserve.asd, while keeping the aserve.asd for the time being (so both systems will be available in Quicklisp for the time being). > > 2. For aserve.asd only, we print warnings at strategic places (maybe both at system load time and when starting the server) indicating that "The ASDF system name may be changing to "paserve" in the future" and "Please also consider the new "zaserve (available for CCL and SBCL now, and welcoming ports for other implementations)" > > 3. At the same time, the new zaserve will hopefully get added to Quicklisp as well. > > So for an interim period at least, there will be "aserve" "paserve" and "zaserve" all available in Quicklisp. > > After a few months, we can revisit the whole situation and decide how to proceed from there... > > If this sounds acceptable, I'll go ahead and update my pull request accordingly. > > Please advise, > > Dave > > > 1. paserve keeps the aserve package and adds the paserve package, adds documentation saying “please adapt your defpackage forms”; possibly also adds a runtime warning when calling some choice function (e.g., (aserve:start) instead of (paserve:start)) > > 2. After n quicklisp releases (for sufficiently small amounts of n) paserve stops defining the aserve package; zaserve picks it up either immediately or after 1-2 release cycles. > > I’m happy to accept a pull request implementing 1. immediately, since it’s not a breaking change for anyone. I’ll also happily accept a pull request implementing 2. some time afterwards, and hand over the aserve package name to its rightful home :) > > Rudi > > |
From: Dave C. <dav...@ge...> - 2018-10-18 15:24:41
|
Hi Rudi, Thanks for your feedback. The thing is, I think the main issue here is the ASDF system name "aserve" (which serves as a unique identifier for Quicklisp as well) rather than the Lisp package name(s). I don't think there will be a use-case for having both zaserve and paserve loaded at the same time into the same Lisp image, so I think package names can and should remain as-is. Recall that aserve defines three package names: net.aserve (with functions such as start, shutdown, and various publish* functions), net.aserve.client (with functions such as do-http-request), and net.html.generator with all the HTML-generating macros (even though most people -- speaking for myself at least -- use cl-who instead these days for that kind of stuff). My proposal is certainly not to change these package names to net.zaserve and net.zaserve.client in the new zaserve system nor net.paserve and net.paserve.client in the old paserve system. So the only changes contemplated here for paserve are: 1. Change its aserve.asd to paserve.asd 2. In that file, change `defsystem aserve` to `defsystem paserve` (in two places - one for the real system definition and the other for the "dummy" system which just requires native :aserve when running on Allegro). Given this, I think your idea of staggered approach still makes sense. Applying the concept to system name rather than package names, how about the following: 1. We add paserve.asd, while keeping the aserve.asd for the time being (so both systems will be available in Quicklisp for the time being). 2. For aserve.asd only, we print warnings at strategic places (maybe both at system load time and when starting the server) indicating that "The ASDF system name may be changing to "paserve" in the future" and "Please also consider the new "zaserve (available for CCL and SBCL now, and welcoming ports for other implementations)" 3. At the same time, the new zaserve will hopefully get added to Quicklisp as well. So for an interim period at least, there will be "aserve" "paserve" and "zaserve" all available in Quicklisp. After a few months, we can revisit the whole situation and decide how to proceed from there... If this sounds acceptable, I'll go ahead and update my pull request accordingly. Please advise, Dave 1. paserve keeps the aserve package and adds the paserve package, adds > documentation saying “please adapt your defpackage forms”; possibly also > adds a runtime warning when calling some choice function (e.g., > (aserve:start) instead of (paserve:start)) > > 2. After n quicklisp releases (for sufficiently small amounts of n) > paserve stops defining the aserve package; zaserve picks it up either > immediately or after 1-2 release cycles. > > I’m happy to accept a pull request implementing 1. immediately, since it’s > not a breaking change for anyone. I’ll also happily accept a pull request > implementing 2. some time afterwards, and hand over the aserve package name > to its rightful home :) > > Rudi > > |
From: Rudi S. <ru...@co...> - 2018-10-18 10:26:47
|
Hi, I agree with all the arguments, especially the contradicting ones :) Maybe we could go for a staggered approach? Something like 1. paserve keeps the aserve package and adds the paserve package, adds documentation saying “please adapt your defpackage forms”; possibly also adds a runtime warning when calling some choice function (e.g., (aserve:start) instead of (paserve:start)) 2. After n quicklisp releases (for sufficiently small amounts of n) paserve stops defining the aserve package; zaserve picks it up either immediately or after 1-2 release cycles. I’m happy to accept a pull request implementing 1. immediately, since it’s not a breaking change for anyone. I’ll also happily accept a pull request implementing 2. some time afterwards, and hand over the aserve package name to its rightful home :) Rudi > On 17 Oct 2018, at 23:55, Dave Cooper <dav...@ge...> wrote: > > > Dear all, > > Sorry for all the noise today, but after some discussion on freenode on #lisp and #quicklisp, it seems there's some hesitation all around to rename legacy aserve to paserve right at this juncture. I've submitted a quicklisp-projects Issue here: > > https://github.com/quicklisp/quicklisp-projects/issues/1575 <https://github.com/quicklisp/quicklisp-projects/issues/1575> > > where I'm requesting to add the fresh Allegroserve fork, but with its ASDF system renamed to "zaserve," at least for the time being. > > Legacy PortableAllegroserve maintainers, please take your time and think over how you'd feel about renaming that one to "paserve" at some point. We know there are only a few quicklisp-registered projects which depend on aserve, but Zach B. has some reservations that there may be silent users who will experience sudden breakage if we just pull the rug out from under them like this (and I don't disagree). > > Also, zaserve only supports two platforms at present (CCL and SBCL), and your paserve still (to some extent) supports LW and maybe one or two others as well. So especially LispWorks users might be affected by a sudden name change (of course we'd encourage them to contribute a port of zacl to LW so that zaserve can start supporting that as well). > > Anyway, I'll leave the merge request in place for now, but it's up to you when and whether to accept it. If you like, I could update it for now to revert the ASDF system name change, but still give the message, alerting especially CCL and SBCL users that they might consider trying zaserve (and inviting other platforms to look into contributing a zacl port). > > Thanks for your patience with all my false starts, > > Dave > > > > > > > > > > > > > > On Wed, Oct 17, 2018 at 2:41 PM Dave Cooper <dav...@ge... <mailto:dav...@ge...>> wrote: > > Ok the Merge Request is there, at https://sourceforge.net/p/portableaserve/git/ci/master/tree/ <https://sourceforge.net/p/portableaserve/git/ci/master/tree/>. > > Please let me know if any questions/concerns. > > > > > -- > My Best, > > Dave Cooper, david.cooper@gen.works > genworks.com <http://genworks.com/>, gendl.org <http://gendl.org/> > +1 248-330-2979 > |
From: Dave C. <dav...@ge...> - 2018-10-17 21:55:39
|
Dear all, Sorry for all the noise today, but after some discussion on freenode on #lisp and #quicklisp, it seems there's some hesitation all around to rename legacy aserve to paserve right at this juncture. I've submitted a quicklisp-projects Issue here: https://github.com/quicklisp/quicklisp-projects/issues/1575 where I'm requesting to add the fresh Allegroserve fork, but with its ASDF system renamed to "zaserve," at least for the time being. Legacy PortableAllegroserve maintainers, please take your time and think over how you'd feel about renaming that one to "paserve" at some point. We know there are only a few quicklisp-registered projects which depend on aserve, but Zach B. has some reservations that there may be silent users who will experience sudden breakage if we just pull the rug out from under them like this (and I don't disagree). Also, zaserve only supports two platforms at present (CCL and SBCL), and your paserve still (to some extent) supports LW and maybe one or two others as well. So especially LispWorks users might be affected by a sudden name change (of course we'd encourage them to contribute a port of zacl to LW so that zaserve can start supporting that as well). Anyway, I'll leave the merge request in place for now, but it's up to you when and whether to accept it. If you like, I could update it for now to revert the ASDF system name change, but still give the message, alerting especially CCL and SBCL users that they might consider trying zaserve (and inviting other platforms to look into contributing a zacl port). Thanks for your patience with all my false starts, Dave On Wed, Oct 17, 2018 at 2:41 PM Dave Cooper <dav...@ge...> wrote: > > Ok the Merge Request is there, at > https://sourceforge.net/p/portableaserve/git/ci/master/tree/. > > Please let me know if any questions/concerns. > > > -- My Best, Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979 |
From: Dave C. <dav...@ge...> - 2018-10-17 19:06:46
|
Ok the Merge Request is there, at https://sourceforge.net/p/portableaserve/git/ci/master/tree/. Please let me know if any questions/concerns. |
From: Dave C. <dav...@ge...> - 2018-10-17 18:04:48
|
Dear all, This has obviously fallen through the cracks again for over a year. We've simply had other priorities than sorting out our open-source stuff, but it's getting ridiculous that Gendl hasn't been updated in Quicklisp for a couple years -- we either need to pull it out of Quicklisp or get it updatable, and I'd far prefer the latter. So, I'm back on the case now. I just forked the Sourceforge portableaserve repo, will change the name and maybe add a few other documentations/messages, then will do a Merge Request. After that I'll be working on a pull request with a few updates for Zacl, and getting current official Allegroserve into a state where Zach will accept it for Quicklisp. At least at the beginning, official Allegroserve will still need a few tweaks to work with Zacl and Quicklisp (I started maintaining a fork here: https://github.com/genworks/aserve which I'll ask Zach to bring into Quicklisp after I clean it up a bit more). After things are stabilized I plan to submit pull requests to the official franzinc aserve on github, assuming they're willing to accept them, with an aim of eventually getting to where Zach will be able to pull official aserve from Franz for Quicklisp. Regarding filing bug reports with the below-listed projects -- Rudi, would you like to take that on? I'm willing to do it as well, but for the next couple days I plan to be working on the other stuff... Here's what depends on the "aserve" system: > (ql:who-depends-on "aserve") ("cl-geocode" "gwl" "html-sugar" "leech" "racer" "rss" "webactions" "wuwei") cl-geocode is from e40 on github, gwl is part of gendl, html-sugar is from Walter Pelissero, leech is from bknr, rss is from Kevin Rosenberg, webactions is part of paserve, and wuwei is from mtravers on github. On Thu, Sep 14, 2017 at 5:16 AM Rudi Schlatte <ru...@co...> wrote: > > On 12 Sep 2017, at 16:35, Dave Cooper <dav...@ge...> wrote: > > > > On Fri, Dec 9, 2016 at 11:12 AM, Zach Beane <xa...@xa...> wrote: > >> Here's what depends on the "aserve" system: >> >> > (ql:who-depends-on "aserve") >> ("cl-geocode" "gwl" "html-sugar" "leech" "racer" "rss" "webactions" >> "wuwei") >> >> cl-geocode is from e40 on github, gwl is part of gendl, html-sugar is >> from Walter Pelissero, leech is from bknr, rss is from Kevin Rosenberg, >> webactions is part of paserve, and wuwei is from mtravers on github. >> >> > > So in order to change the name, I'm assuming we'll have to get concurrence > from these projects? > > Sorry for the long delay, I will start reaching out to them. I'll report > here when I get responses or if I have trouble contacting any of them. > > > Hi Dave, thanks for keeping this matter alive. I propose to change the > system name for aserve at the start of the next quicklisp interval and file > bug reports / patches against these systems, then they have a month to > adapt. In case there’s too much breakage, there’s always the possibility > of reverting the changes before Zach cuts the next release. > > Rudi > > -- My Best, Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979 |
From: Zach B. <xa...@xa...> - 2017-09-14 17:49:32
|
For a timeframe, Quicklisp's next update will be at the end of September, and there will be an announcement on Planet Lisp and the Quicklisp blog. Zach On Thu, Sep 14, 2017 at 5:16 AM, Rudi Schlatte <ru...@co...> wrote: > > On 12 Sep 2017, at 16:35, Dave Cooper <dav...@ge...> wrote: > > > > On Fri, Dec 9, 2016 at 11:12 AM, Zach Beane <xa...@xa...> wrote: > >> Here's what depends on the "aserve" system: >> >> > (ql:who-depends-on "aserve") >> ("cl-geocode" "gwl" "html-sugar" "leech" "racer" "rss" "webactions" >> "wuwei") >> >> cl-geocode is from e40 on github, gwl is part of gendl, html-sugar is >> from Walter Pelissero, leech is from bknr, rss is from Kevin Rosenberg, >> webactions is part of paserve, and wuwei is from mtravers on github. >> >> > > So in order to change the name, I'm assuming we'll have to get concurrence > from these projects? > > Sorry for the long delay, I will start reaching out to them. I'll report > here when I get responses or if I have trouble contacting any of them. > > > Hi Dave, thanks for keeping this matter alive. I propose to change the > system name for aserve at the start of the next quicklisp interval and file > bug reports / patches against these systems, then they have a month to > adapt. In case there’s too much breakage, there’s always the possibility > of reverting the changes before Zach cuts the next release. > > Rudi > > |
From: Rudi S. <ru...@co...> - 2017-09-14 09:38:30
|
> On 12 Sep 2017, at 16:35, Dave Cooper <dav...@ge...> wrote: > > > > On Fri, Dec 9, 2016 at 11:12 AM, Zach Beane <xa...@xa... <mailto:xa...@xa...>> wrote: > Here's what depends on the "aserve" system: > > > (ql:who-depends-on "aserve") > ("cl-geocode" "gwl" "html-sugar" "leech" "racer" "rss" "webactions" "wuwei") > > cl-geocode is from e40 on github, gwl is part of gendl, html-sugar is from Walter Pelissero, leech is from bknr, rss is from Kevin Rosenberg, webactions is part of paserve, and wuwei is from mtravers on github. > > > > So in order to change the name, I'm assuming we'll have to get concurrence from these projects? > > Sorry for the long delay, I will start reaching out to them. I'll report here when I get responses or if I have trouble contacting any of them. Hi Dave, thanks for keeping this matter alive. I propose to change the system name for aserve at the start of the next quicklisp interval and file bug reports / patches against these systems, then they have a month to adapt. In case there’s too much breakage, there’s always the possibility of reverting the changes before Zach cuts the next release. Rudi |
From: Dave C. <dav...@ge...> - 2017-09-12 14:57:24
|
On Fri, Dec 9, 2016 at 11:12 AM, Zach Beane <xa...@xa...> wrote: > Here's what depends on the "aserve" system: > > > (ql:who-depends-on "aserve") > ("cl-geocode" "gwl" "html-sugar" "leech" "racer" "rss" "webactions" > "wuwei") > > cl-geocode is from e40 on github, gwl is part of gendl, html-sugar is from > Walter Pelissero, leech is from bknr, rss is from Kevin Rosenberg, > webactions is part of paserve, and wuwei is from mtravers on github. > > So in order to change the name, I'm assuming we'll have to get concurrence from these projects? Sorry for the long delay, I will start reaching out to them. I'll report here when I get responses or if I have trouble contacting any of them. Regards, Dave > Zach > > On Thu, Dec 8, 2016 at 7:37 AM, Rudi Schlatte <ru...@co...> wrote: > >> I’m not against this change. Zach, can you estimate the impact from the >> POV of Quicklisp? >> >> Rudi >> >> On 8 Dec 2016, at 04:41, Dave Cooper <dav...@ge...> wrote: >> >> >> Dear Rudi, portableaserve maintainers & users, >> >> >> >>> In general, I’m all in favor of using common (and maintained) portable >>> libraries and removing as much stuff from acl-compat as possible. :) >> >> >> >> A new compatibility layer, "zacl," has been developed which can play a >> similar role to acl-compat, and is targeted toward current "original" >> AllegroServe (1.3.42): >> >> https://gitlab.common-lisp.net/zbeane/zacl >> >> zacl has initially targeted CCL, and it has been tested (albeit lightly) >> CCL. An effort to port to other CLs is ongoing. >> >> For purposes of allowing zacl, original AllegroServe, and >> portableallegroserve all to co-exist in Quicklisp, would you guys mind >> changing the system name in portableallegroserve from "aserve" to "paserve" >> ? Zacl is currently working with a very lightly tweaked current version of >> aserve (details in the README of the above gitlab project). The idea is to >> minimize (ideally completely eliminate) any need for changes to original >> aserve and have it work with zacl. >> >> So for all this to work smoothly within Quicklisp, Quicklisp will have to >> start carrying a mirror as close as possible (or identical) to original >> aserve, and that means claiming back the system name "aserve." (I know it >> wasn't in Quicklisp first, but it was published with the asdf system name >> "aserve" first). >> >> At the risk of being presumptuous, I've attached a patch which effects >> this change. >> >> >> -- >> My Best, >> >> Dave Cooper, david.cooper@gen.works >> genworks.com, gendl.org >> +1 248-330-2979 >> >> <rename-system-to-paserve.patch> >> >> >> > -- My Best, Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979 |
From: Zach B. <xa...@xa...> - 2016-12-09 16:39:40
|
Here's what depends on the "aserve" system: > (ql:who-depends-on "aserve") ("cl-geocode" "gwl" "html-sugar" "leech" "racer" "rss" "webactions" "wuwei") cl-geocode is from e40 on github, gwl is part of gendl, html-sugar is from Walter Pelissero, leech is from bknr, rss is from Kevin Rosenberg, webactions is part of paserve, and wuwei is from mtravers on github. Zach On Thu, Dec 8, 2016 at 7:37 AM, Rudi Schlatte <ru...@co...> wrote: > I’m not against this change. Zach, can you estimate the impact from the > POV of Quicklisp? > > Rudi > > On 8 Dec 2016, at 04:41, Dave Cooper <dav...@ge...> wrote: > > > Dear Rudi, portableaserve maintainers & users, > > > >> In general, I’m all in favor of using common (and maintained) portable >> libraries and removing as much stuff from acl-compat as possible. :) > > > > A new compatibility layer, "zacl," has been developed which can play a > similar role to acl-compat, and is targeted toward current "original" > AllegroServe (1.3.42): > > https://gitlab.common-lisp.net/zbeane/zacl > > zacl has initially targeted CCL, and it has been tested (albeit lightly) > CCL. An effort to port to other CLs is ongoing. > > For purposes of allowing zacl, original AllegroServe, and > portableallegroserve all to co-exist in Quicklisp, would you guys mind > changing the system name in portableallegroserve from "aserve" to "paserve" > ? Zacl is currently working with a very lightly tweaked current version of > aserve (details in the README of the above gitlab project). The idea is to > minimize (ideally completely eliminate) any need for changes to original > aserve and have it work with zacl. > > So for all this to work smoothly within Quicklisp, Quicklisp will have to > start carrying a mirror as close as possible (or identical) to original > aserve, and that means claiming back the system name "aserve." (I know it > wasn't in Quicklisp first, but it was published with the asdf system name > "aserve" first). > > At the risk of being presumptuous, I've attached a patch which effects > this change. > > > -- > My Best, > > Dave Cooper, david.cooper@gen.works > genworks.com, gendl.org > +1 248-330-2979 > > <rename-system-to-paserve.patch> > > > |
From: Rudi S. <ru...@co...> - 2016-12-08 12:56:18
|
I’m not against this change. Zach, can you estimate the impact from the POV of Quicklisp? Rudi > On 8 Dec 2016, at 04:41, Dave Cooper <dav...@ge...> wrote: > > > Dear Rudi, portableaserve maintainers & users, > > > In general, I’m all in favor of using common (and maintained) portable libraries and removing as much stuff from acl-compat as possible. :) > > > A new compatibility layer, "zacl," has been developed which can play a similar role to acl-compat, and is targeted toward current "original" AllegroServe (1.3.42): > > https://gitlab.common-lisp.net/zbeane/zacl <https://gitlab.common-lisp.net/zbeane/zacl> > > zacl has initially targeted CCL, and it has been tested (albeit lightly) CCL. An effort to port to other CLs is ongoing. > > For purposes of allowing zacl, original AllegroServe, and portableallegroserve all to co-exist in Quicklisp, would you guys mind changing the system name in portableallegroserve from "aserve" to "paserve" ? Zacl is currently working with a very lightly tweaked current version of aserve (details in the README of the above gitlab project). The idea is to minimize (ideally completely eliminate) any need for changes to original aserve and have it work with zacl. > > So for all this to work smoothly within Quicklisp, Quicklisp will have to start carrying a mirror as close as possible (or identical) to original aserve, and that means claiming back the system name "aserve." (I know it wasn't in Quicklisp first, but it was published with the asdf system name "aserve" first). > > At the risk of being presumptuous, I've attached a patch which effects this change. > > > -- > My Best, > > Dave Cooper, david.cooper@gen.works > genworks.com <http://genworks.com/>, gendl.org <http://gendl.org/> > +1 248-330-2979 > > <rename-system-to-paserve.patch> |
From: Dave C. <dav...@ge...> - 2016-12-08 04:13:48
|
Dear Rudi, portableaserve maintainers & users, > In general, I’m all in favor of using common (and maintained) portable > libraries and removing as much stuff from acl-compat as possible. :) A new compatibility layer, "zacl," has been developed which can play a similar role to acl-compat, and is targeted toward current "original" AllegroServe (1.3.42): https://gitlab.common-lisp.net/zbeane/zacl zacl has initially targeted CCL, and it has been tested (albeit lightly) CCL. An effort to port to other CLs is ongoing. For purposes of allowing zacl, original AllegroServe, and portableallegroserve all to co-exist in Quicklisp, would you guys mind changing the system name in portableallegroserve from "aserve" to "paserve" ? Zacl is currently working with a very lightly tweaked current version of aserve (details in the README of the above gitlab project). The idea is to minimize (ideally completely eliminate) any need for changes to original aserve and have it work with zacl. So for all this to work smoothly within Quicklisp, Quicklisp will have to start carrying a mirror as close as possible (or identical) to original aserve, and that means claiming back the system name "aserve." (I know it wasn't in Quicklisp first, but it was published with the asdf system name "aserve" first). At the risk of being presumptuous, I've attached a patch which effects this change. -- My Best, Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979 |
From: Rudi S. <ru...@co...> - 2015-10-20 10:18:07
|
> On Oct 20, 2015, at 03:24, Dave Cooper <dav...@ge...> wrote: > > > Dear All, > > Has anyone looked at adding ipv6 support for portableaserve? > > I have to educate myself a bit more on ipv6 - for example I am not even sure if that is something which would be explicitly added at the paserve level, or would it be at a lower level i.e. the acl-compat.socket level? > > My intuition tells me that the aserve code itself shouldn't have to be touched much (if at all) but the acl-compat.socket code would have to be enhanced to take advantage of ipv6 capabilities in any supported CL implementations which indeed support ipv6 (which I think includes most of them, these days). > > At that point one has to ask -- wouldn't it then be high time to re-implement acl-compat.socket on top of usockets? That should make acl-compat.socket into a mighty thin layer. At that point, the ipv6 support would just depend on usockets's ipv6 support, which appears to be coming along (finished for SBCL and CCL and "in progress" for the rest). > > The reason this is becoming an issue (for me, at least) is I have run into some http client code which assumes, if a host resolves to an ipv6 address, that all services will work through ipv6 (even if the host also happens to resolve to an ipv4 address) -- this is the case these days for example with "localhost" on MacOS Yosemite, where the localhost has both an ipv4 and ipv6 entry in /etc/hosts. My hunch is as well that not much modification should be needed; the main part of aserve deals with streams, not with network addresses. Maybe there’s some code in the logging layer(s) that expects ipv4 addresses. In general, I’m all in favor of using common (and maintained) portable libraries and removing as much stuff from acl-compat as possible. :) Rudi |
From: Dave C. <dav...@ge...> - 2015-10-20 01:24:20
|
There doesn't seem to be an overriding reason to move it at this point, so the path of least resistance is to leave it where it is on Sourceforge. On Tue, Jun 2, 2015 at 11:22 AM, Mike Travers <mt...@hy...> wrote: > I don't do much with portable aserve these days, so I don't care very > strongly one way or the other. But my mild preference would be to keep the > code on github which is where most open source code lives these days. > > It seems like you should ask the original authors at Franz what they > think. My contribution was a couple of bug fixes. > > > > On Mon, Jun 1, 2015 at 6:56 PM, Dave Cooper <dav...@ge...> > wrote: > >> >> Hi Rudi, Mike, >> >> How would you feel about moving it to common-lisp.net? >> >> Regards, >> >> Dave >> >> >> ---------- Forwarded message ---------- >> From: Vebjorn Ljosa <ve...@lj...> >> Date: Mon, Jun 1, 2015 at 7:11 AM >> Subject: Re: [Portableaserve-discuss] Time to move to common-lisp.net? >> To: Dave Cooper <dav...@ge...> >> Cc: por...@li... >> >> >> On Sun, May 31, 2015 at 10:07 PM, Dave Cooper <dav...@ge...> >> wrote: >> > What with all the questionable activities out of sourceforge lately, and >> > resurrection of common-lisp.net, how do people feel about migrating >> > portableallegroserve to common-lisp.net? >> >> No objections—but I haven't touched portableallegroserve for a decade, >> so my opinion doesn't matter. >> >> Vebjorn >> >> >> >> -- >> My Best, >> >> Dave Cooper >> genworks.com, gendl.org >> +1 248-330-2979 >> >> > -- My Best, Dave Cooper genworks.com, gendl.org +1 248-330-2979 |
From: Dave C. <dav...@ge...> - 2015-10-20 01:24:08
|
Dear All, Has anyone looked at adding ipv6 support for portableaserve? I have to educate myself a bit more on ipv6 - for example I am not even sure if that is something which would be explicitly added at the paserve level, or would it be at a lower level i.e. the acl-compat.socket level? My intuition tells me that the aserve code itself shouldn't have to be touched much (if at all) but the acl-compat.socket code would have to be enhanced to take advantage of ipv6 capabilities in any supported CL implementations which indeed support ipv6 (which I think includes most of them, these days). At that point one has to ask -- wouldn't it then be high time to re-implement acl-compat.socket on top of usockets? That should make acl-compat.socket into a mighty thin layer. At that point, the ipv6 support would just depend on usockets's ipv6 support, which appears to be coming along (finished for SBCL and CCL and "in progress" for the rest). The reason this is becoming an issue (for me, at least) is I have run into some http client code which assumes, if a host resolves to an ipv6 address, that all services will work through ipv6 (even if the host also happens to resolve to an ipv4 address) -- this is the case these days for example with "localhost" on MacOS Yosemite, where the localhost has both an ipv4 and ipv6 entry in /etc/hosts. -- My Best, Dave Cooper genworks.com, gendl.org +1 248-330-2979 |
From: Vebjorn L. <ve...@lj...> - 2015-06-01 11:41:00
|
On Sun, May 31, 2015 at 10:07 PM, Dave Cooper <dav...@ge...> wrote: > What with all the questionable activities out of sourceforge lately, and > resurrection of common-lisp.net, how do people feel about migrating > portableallegroserve to common-lisp.net? No objections—but I haven't touched portableallegroserve for a decade, so my opinion doesn't matter. Vebjorn |
From: Dave C. <dav...@ge...> - 2015-06-01 02:35:48
|
What with all the questionable activities out of sourceforge lately, and resurrection of common-lisp.net, how do people feel about migrating portableallegroserve to common-lisp.net? -- My Best, Dave Cooper genworks.com, gendl.org +1 248-330-2979 |
From: Rudolf S. <ru...@co...> - 2013-03-24 07:48:36
|
On Mar 22, 2013, at 00:36, Dave Cooper <dav...@ge...> wrote: > > Hi Rudi, > > Not sure how this has been slipping through... (a one-line fix in acl-compat/packages.lisp for LispWorks). > > Thanks for the tip about "git format-patch" - i'm starting to get more comfortable with git so I will probably start sending git-flavored patches at some point, and will to ahead and ask for commit access to portableaserve sooner or later. Thanks, applied. One nice thing about git format-patch is that it preserves author information, and that you can send large changes as a sequence of patches. If you want to prettify local changes before sending them upstream, check out the wonders of "git rebase -i" - it lets you clean up these awkward "implement x - implement y - oops, add forgotten detail in x" sequences before anyone else gets to see them. Rudi |
From: Rudolf S. <ru...@co...> - 2013-03-09 09:02:14
|
On Mar 9, 2013, at 01:13, Dave Cooper <dav...@ge...> wrote: > > Here is a patch to go at the toplevel portableaserve-git: > > Copying from my addition to the Changelog: > > > 2014-03-09 Dave Cooper <dav...@ge...> > * libs/: removed, because asdf is available on all currently > supported platforms and other libs are available through Quicklisp > * acl-compat/acl-compat.asd: removed :depends-on :asdf-utils for > CCL. > * acl-compat/mcl/acl-excl.lisp: replaced (asdf-utils:split-string > ...) with (cl-ppcre:split "\\s" ...). > * as mentioned by Rudi in a message to the mailing list, large > swaths of acl-compat stuff is ripe to be replaced by stuff from > Quicklisp these days. > * Updated the README.cmucl to remove outdated asdf info. Thanks, applied. Nuking libs/ had been on my to-do list already. Rudi |
From: Dave C. <dav...@ge...> - 2013-03-05 14:03:47
|
Thank you! I just tested on ACL, CCL, and SBCL, all looks good so far... On Tue, Mar 5, 2013 at 5:02 AM, Rudolf Schlatte <ru...@co...> wrote: > > On Mar 4, 2013, at 23:54, Dave Cooper <dav...@ge...> wrote: > > > > > Hi Rudi, > > > > Here is an updated patch to be applied to current portableaserve > sourceforge git repo. > > Thanks, merged (with bits of your mail as explanation in the commit > message). Completely untested; let me know if I screwed up. > > Rudi > > > -- My Best, Dave Cooper, Genworks Support dav...@ge..., dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699 |
From: Rudolf S. <ru...@co...> - 2013-03-05 10:02:21
|
On Mar 4, 2013, at 23:54, Dave Cooper <dav...@ge...> wrote: > > Hi Rudi, > > Here is an updated patch to be applied to current portableaserve sourceforge git repo. Thanks, merged (with bits of your mail as explanation in the commit message). Completely untested; let me know if I screwed up. Rudi |
From: Kevin R. <ke...@ro...> - 2013-03-01 21:57:23
|
On Mar 1, 2013, at 2:10 AM, Rudolf Schlatte <ru...@co...> wrote: > (I've run out of steam a little wrt working on paserve because of a new job etc., but I'm happy to merge fixes and will eventually return to it.) You've had more steam that me! Nice work on your patches to catch up a bit to upstream's allegroserve. |
From: Rudolf S. <ru...@co...> - 2013-03-01 20:59:39
|
On Mar 1, 2013, at 05:38, Dave Cooper <dav...@ge...> wrote: > > Hi Rudi, > > Can you apply this patch to portableallegroserve/aserve/ ? > > The little "hack" which loads original-aserve for #+allegro was breaking with the latest ASDF 2.31.4 (soon to be ASDF3). This patch appears to correct the problem. Thanks, applied. (I've run out of steam a little wrt working on paserve because of a new job etc., but I'm happy to merge fixes and will eventually return to it.) Rudi |
From: Dave C. <dav...@ge...> - 2013-03-01 11:55:45
|
On Thu, Feb 28, 2013 at 8:29 PM, Anton Vodonosov <avo...@ya...>wrote: > > http://common-lisp.net/project/cl-test-grid/asdf/asdf-diff-20.html > > ACL shows new problem with portableaserve and via it with all genworks-gdl > systems. > The error: No defined method for ASDF/ACTION:PERFORM oncompiling > #<ORIGINAL-ASERVE "aserve" "dummy"> > This is fixed by adding an empty method as follows to aserve.asd: ;;; #+allegro (defmethod asdf:perform ((op asdf:compile-op) (c original-aserve))) ;;; I will get a patch to Rudi Schlatte for updating of the portableaserve on sourceforge (this is the one used by Quicklisp). -- My Best, Dave Cooper, Genworks Support dav...@ge..., dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699 |