From: Erik H. <eh...@gm...> - 2009-02-09 19:19:05
|
Hi Mark, While this was true last weekend, I don't have a problem compiling the come below today: (defun fail () (min 1 2 3)) (compile 'fail) --> NIL (fail) --> 1 Are you sure you're using the most recent there is? Bye, Erik. On Mon, Feb 9, 2009 at 8:29 AM, armedbear <arm...@co...> wrote: > #46: Compilation failure from several numeric arguments to MIN > ----------------------+----------------------------------------------------- > Reporter: mevenson | Owner: ehuselmann > Type: defect | Status: new > Priority: major | Milestone: unscheduled > Component: compiler | Version: 1.0 > Keywords: | > ----------------------+----------------------------------------------------- > After the recent (JAN/FEB) changes to the compiler to support numeric > types more efficiently, the following code fails to compile: > {{{ > (defun fail () > (min 1 2 3)) > }}} > > with a Failed AVER: "NIL" arising out of COMPILE-FORMS-AND-MAYBE-EMIT- > CLEAR_VALUES failing to parse its arguments correctly. > > -- > Ticket URL: <http://127.0.0.1:8000/armedbear/ticket/46> > armedbear <http://common-lisp.net/project/armedbear> > armedbear > _______________________________________________ > armedbear-ticket mailing list > arm...@co... > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-ticket > |
From: Mark E. <ev...@pa...> - 2009-02-10 06:45:11
|
Ville Voutilainen wrote: […] > This works for me, our svn trunk on linux. I guess it's been fixed > after the ticket's been > created, but not quickly enough. :D Confirmed as fixed in r11651. Not quickly enough? What's better than having a bug fixed as it is being filed? Darn good service, in my opinion… Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2009-02-10 07:21:12
|
On Tue, Feb 10, 2009 at 8:45 AM, Mark Evenson <ev...@pa...> wrote: >> This works for me, our svn trunk on linux. I guess it's been fixed >> after the ticket's been >> created, but not quickly enough. :D > Not quickly enough? What's better than having a bug fixed as it is being > filed? Darn good service, in my opinion… Well, since you ask, we'd provide an even better service if we'd avoid these regressions to begin with. After all, we have enough regression tests, so it's just a matter of running them and checking the results before committing. |
From: Erik H. <eh...@gm...> - 2009-02-10 08:13:15
|
On Tue, Feb 10, 2009 at 8:21 AM, Ville Voutilainen <vil...@gm...> wrote: > On Tue, Feb 10, 2009 at 8:45 AM, Mark Evenson <ev...@pa...> wrote: >>> This works for me, our svn trunk on linux. I guess it's been fixed >>> after the ticket's been >>> created, but not quickly enough. :D >> Not quickly enough? What's better than having a bug fixed as it is being >> filed? Darn good service, in my opinion… > > Well, since you ask, we'd provide an even better service if we'd avoid these > regressions to begin with. After all, we have enough regression tests, > so it's just a matter of running them and checking the results before > committing. Mea culpa... I'm sorry, every now and then I run the tests while committing, especially late at night. The next morning I usually find that - indeed - nothing was broken. Unfortunately, with the p2-min/max inlining commit, this was not the case. Bye, Erik. |
From: Mark E. <ev...@pa...> - 2009-02-10 08:34:09
|
Erik Huelsmann wrote: […] >> Well, since you ask, we'd provide an even better service if we'd avoid these >> regressions to begin with. After all, we have enough regression tests, >> so it's just a matter of running them and checking the results before >> committing. > > Mea culpa... > > I'm sorry, every now and then I run the tests while committing, > especially late at night. The next morning I usually find that - > indeed - nothing was broken. Unfortunately, with the p2-min/max > inlining commit, this was not the case. […] A good solution might be some sort of "continuous build server" that would watch the SVN tree, build the tree, run the tests, then publish the results. In Java-land, the current fashion for such software is probably exemplified by Hudson. Perhaps we could get some sort of server space "donated" by someone. I've managed to get the ANSI tests and the ABCL internal tests invokable via Ant at this point, with the cl-bench the next test that I need to tackle. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." |
From: Ville V. <vil...@gm...> - 2009-02-10 08:43:24
|
> Erik Huelsmann wrote: >>> Well, since you ask, we'd provide an even better service if we'd avoid >>> these >>> regressions to begin with. After all, we have enough regression tests, >> Mea culpa... It's not a big problem, this is the svn HEAD and such breakage is bound to happen. We could try and adopt a "ask questions first, file tickets later"-policy too. > A good solution might be some sort of "continuous build server" that would > watch the SVN tree, build the tree, run the tests, then publish the results. > In Java-land, the current fashion for such software is probably exemplified > by Hudson. Perhaps we could get some sort of server space "donated" by > someone. Some people also use CruiseControl, AFAIK. Hmm, maybe I should ask my company (1) if they're willing to provide such a build service. In the mean time, other possibilities for this should definitely be investigated, the company bureaucracy takes its time. There's also some amount of risk involved if such a build service is hosted by any company, but it's one option. (1) my employer states that they're willing to provide "environments and infrastructure" for open-source projects participated in by employees. The exact meaning of that is not very clearly defined, as it's a work-in-progress, but I'd think a nightly build service would fit into that description. |
From: Erik H. <eh...@gm...> - 2009-02-10 10:50:21
|
On Tue, Feb 10, 2009 at 9:43 AM, Ville Voutilainen <vil...@gm...> wrote: >> Erik Huelsmann wrote: >>>> Well, since you ask, we'd provide an even better service if we'd avoid >>>> these >>>> regressions to begin with. After all, we have enough regression tests, >>> Mea culpa... > > It's not a big problem, this is the svn HEAD and such breakage is > bound to happen. While breakage is to be expected when doing larger-impact changes (like the stuff where I have started inline support for float and double Java types), I'm quite a bit ashamed with the (min 1 2 3) breakage, because it was something too simple. > We could try and adopt a "ask questions first, file tickets later"-policy too. I think that would be a good idea: only we can file tickets anyway. >> A good solution might be some sort of "continuous build server" that would >> watch the SVN tree, build the tree, run the tests, then publish the results. >> In Java-land, the current fashion for such software is probably exemplified >> by Hudson. Perhaps we could get some sort of server space "donated" by >> someone. I have a VPS at tech.coop, but it's already running a testing server. It also has too little memory (128MB) to run anything Java based. Upgrading the account doesn't cost much, but the charge is monthly... If anybody wants to sponsor the additional charge (ca 30 CAD [a little bit less than 20 EUR], I think for an upgrade to 512MB). > Some people also use CruiseControl, AFAIK. Hmm, maybe I should ask my > company (1) if they're willing to provide such a build service. In the mean time, > other possibilities for this should definitely be investigated, the company bureaucracy > takes its time. > There's also some amount of risk involved if such a build service is > hosted by any company, but it's one option. True, but as long as we have a copy of the configuration files, I don't see much problems with it: we should be able to relocate the service anywhere quite quickly.. > (1) my employer states that they're willing to provide "environments > and infrastructure" > for open-source projects participated in by employees. The exact > meaning of that is not very clearly defined, as it's a work-in-progress, but I'd think a > nightly build service would fit into that description. Although bureaucracy usually is a bit slow, I don't think that - when being offered - we shouldn't give it a try: We currently don't have anything and - at least I - don't have other options. However, since your company already sponsors your hardware, I'll post separately on the subject of sponsoring our project. Especially if we're going to see commercial users, I think it's only fair to ask for something back which will benefit our productivity or the larger community in general. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2009-02-10 11:19:40
|
On Tue, Feb 10, 2009 at 12:50 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >>> A good solution might be some sort of "continuous build server" that would > I have a VPS at tech.coop, but it's already running a testing server. Does common-lisp.net have any facilities for this? Or sourceforge? |
From: Erik H. <eh...@gm...> - 2009-02-10 12:44:21
|
On Tue, Feb 10, 2009 at 12:19 PM, Ville Voutilainen <vil...@gm...> wrote: > On Tue, Feb 10, 2009 at 12:50 PM, Erik Huelsmann <eh...@gm...> wrote: >>>> A good solution might be some sort of "continuous build server" that would >> I have a VPS at tech.coop, but it's already running a testing server. > > Does common-lisp.net have any facilities for this? Or sourceforge? Common-lisp.net doesn't (at this point); Sourceforge does, although I have no idea how much memory we're allowed to use - or how to get an account, for that matter. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2009-02-09 19:39:45
|
On Mon, Feb 9, 2009 at 9:19 PM, Erik Huelsmann <eh...@gm...> wrote: > Hi Mark, > While this was true last weekend, I don't have a problem compiling the > come below today: > (defun fail () (min 1 2 3)) > (compile 'fail) > --> NIL > (fail) > --> 1 This works for me, our svn trunk on linux. I guess it's been fixed after the ticket's been created, but not quickly enough. :D |