From: Stephan F. <def...@go...> - 2013-08-15 19:28:03
|
doubt that was meant to be a personal mail, so here it is: -------- Original Message -------- Subject: Version numbers, Windows, and The Kitten of Death. Date: Thu, 15 Aug 2013 14:09:47 -0500 From: ra...@ra... Reply-To: ra...@ra... To: Stephan Frank <def...@go...> Hi, According to sbcl.org, 1.1.8 is supported on Windows, at least for X86. This is in contrast to many previous versions which were marked as 'port in progress'. Does anyone think it may be time to remove the 'Kitten of Death' warning from X86 Windows builds? Among other things, it would make --noinform work properly. Neil Gilmore ra...@ra... |
From: Paul K. <pv...@pv...> - 2013-08-19 14:24:09
|
Stephan Frank wrote: > -------- Original Message -------- > Subject: Version numbers, Windows, and The Kitten of Death. > Date: Thu, 15 Aug 2013 14:09:47 -0500 > From: ra...@ra... > Reply-To: ra...@ra... > To: Stephan Frank<def...@go...> > > Hi, > > According to sbcl.org, 1.1.8 is supported on Windows, at least for X86. > This is in contrast to many previous versions which were marked as 'port > in progress'. > > Does anyone think it may be time to remove the 'Kitten of Death' warning > from X86 Windows builds? Among other things, it would make --noinform work > properly. David, Alastair, other people who use the port: what do you think? Paul Khuong |
From: Stas B. <sta...@gm...> - 2013-08-19 14:30:49
|
Paul Khuong <pv...@pv...> writes: > Stephan Frank wrote: >> -------- Original Message -------- >> Subject: Version numbers, Windows, and The Kitten of Death. >> Date: Thu, 15 Aug 2013 14:09:47 -0500 >> From: ra...@ra... >> Reply-To: ra...@ra... >> To: Stephan Frank<def...@go...> >> >> Hi, >> >> According to sbcl.org, 1.1.8 is supported on Windows, at least for X86. >> This is in contrast to many previous versions which were marked as 'port >> in progress'. >> >> Does anyone think it may be time to remove the 'Kitten of Death' warning >> from X86 Windows builds? Among other things, it would make --noinform work >> properly. > > David, Alastair, other people who use the port: what do you think? Maybe if the half of the tests weren't marked as failing and another half wasn't failing or hanging. -- With best regards, Stas. |
From: Paul K. <pv...@pv...> - 2013-08-19 14:33:10
|
Stas Boukarev wrote: > Maybe if the half of the tests weren't marked as failing and another > half wasn't failing or hanging. It seems to me a port is either in progress or feline-free. So, shall we mark the windows port as still in progress for the foreseeable future? Paul Khuong |
From: David L. <da...@li...> - 2013-08-19 18:05:49
|
Quoting Paul Khuong (pv...@pv...): > Stas Boukarev wrote: > > Maybe if the half of the tests weren't marked as failing and another > > half wasn't failing or hanging. > > It seems to me a port is either in progress or feline-free. So, shall > we mark the windows port as still in progress for the foreseeable > future? My thinking was always that the Windows port had a few fundamental issues indicating that it was not finished. That is why I was in support of any messages (including cute ones) explaining the situation to users. Those issues have been fixed since then. What remains is a distinct lack of maintainers and users actively working to guard against regressions. But other exotic platforms are in the same boat as Windows in that regard, are those are not inflicted with felines. Had I gotten around to it, I would have removed the infamous message earlier this year, and I still suggest doing it. Regarding the platform table, I see no big reason why Windows x86 and x86-64 should be labelled differently. Or if the thinking is that neither of them is fully supported, I would raise the question why MacOS is marked as supported, when it is also affected by deep issues in how we are using the operating system. d. |
From: Gabriel D. R. <gd...@in...> - 2013-08-19 18:51:37
|
On Mon, Aug 19, 2013 at 12:32 PM, David Lichteblau <da...@li...> wrote: > What remains is a distinct lack of maintainers and users actively > working to guard against regressions. But other exotic platforms are in > the same boat as Windows in that regard, are those are not inflicted > with felines. Agreed. It is time for the message to go. It is a service to the SBCL Windows user community, and to SBCL's professionalism itself. -- Gaby |
From: Bart B. <00...@gm...> - 2013-08-20 06:08:42
|
Are the people in favor of removing the message running the test suite on windows? Every time I try, I get random failures, either lockups or "Program has stopped working, exception code: c0000005" popups. I tried running the tests a few times on 1.1.10.16-9460379 x86, on 64-bit windows 7 home premium sp1, and got 5 crashes and 13 lockups out of 17 runs. I built using msys shell, gcc 4.6.1 from mingw, and both sbcl 1.0.55.7.mswinmt.1185-d20ec0c (64 bit), and 1.1.8 (32 bit). Copying the files from the 1.1.8 binary installer on sbcl.org into current source tree and running tests with that also locked up, on same system as previous tests as well as another machine with same OS. (filed a bug at https://bugs.launchpad.net/sbcl/+bug/1214255 with more details about where it was failing) If people are reliably finishing the test suite on windows, which windows version, compiler, build tools, etc are you using? |
From: Gabriel D. R. <gd...@in...> - 2013-08-20 07:04:03
|
On Tue, Aug 20, 2013 at 1:08 AM, Bart Botta <00...@gm...> wrote: > Are the people in favor of removing the message running the test suite on > windows? Every time I try, I get random failures, either lockups or "Program > has stopped working, exception code: c0000005" popups. And what exactly does that message change to that? -- Gaby |
From: Bart B. <00...@gm...> - 2013-08-20 07:21:28
|
On Tue, Aug 20, 2013 at 2:03 AM, Gabriel Dos Reis < gd...@in...> wrote: > On Tue, Aug 20, 2013 at 1:08 AM, Bart Botta <00...@gm...> wrote: > > Are the people in favor of removing the message running the test suite on > > windows? > > And what exactly does that message change to that? > Not sure what you are asking, but reading what I wrote again, it might be unclear also. I was asking if the people in favor of removing the 'kitten of death' message have run the test suite. Unless other people are having better luck with the tests than I am, I'd say inability to finish the test suite seems more like "in progress"/"kitten of death" than "finished"/"supported". |
From: Gabriel D. R. <gd...@in...> - 2013-08-20 07:35:09
|
On Tue, Aug 20, 2013 at 2:21 AM, Bart Botta <00...@gm...> wrote: > On Tue, Aug 20, 2013 at 2:03 AM, Gabriel Dos Reis > <gd...@in...> wrote: >> >> On Tue, Aug 20, 2013 at 1:08 AM, Bart Botta <00...@gm...> wrote: >> > Are the people in favor of removing the message running the test suite >> > on >> > windows? > > >> >> And what exactly does that message change to that? > > > Not sure what you are asking, but reading what I wrote again, it might be > unclear also. I was asking if the people in favor of removing the 'kitten of > death' message have run the test suite. I have. The question I asked is whether printing that message changes anything practically useful to the outcome of the testsuites. Currently, it just sounds like a recurring theme to remove a banner that does not reflect the level of professionalism, maturity, and excellency of SBCL developers. It may look cute the first time, but it is tiresome the second time, and downright rude the third time. If you do insist that it is useful to *you*, would you be OK with an option for displaying it? If it isn't useful to you, why do you insist to jam it on the throats of those who are tired of it? Remember that despite the failing testsuites, these users are still *using* SBCL and they find it useful -- except the banner. If they weren't using it, they wouldn't be reporting the annoyance in the first place. -- Gaby |
From: Bart B. <00...@gm...> - 2013-08-20 07:47:55
|
On Tue, Aug 20, 2013 at 2:34 AM, Gabriel Dos Reis < gd...@in...> wrote: > I have. The question I asked is whether printing that message changes > anything practically useful to the outcome of the testsuites. > OK, I see what you meant now. I don't personally have any preference for that specific message being there or not, I was more responding to the "in-progress or not" part of the discussion. I probably should have replied to a different message rather than just whatever was at the end of the thread, sorry for the confusion. |
From: Christophe R. <cs...@ca...> - 2013-08-20 09:29:36
|
[ I don't have a particularly strong feeling about messages, though I myself do not plan to act to remove any messages on platforms I don't use. However... ] Gabriel Dos Reis <gd...@in...> writes: > professionalism This word could be taken in many ways -- but on at least two levels it seems that a professional treatment of SBCL maintenance is currently substantially lacking: there are currently no individuals or organizations advertising that they are available for professional support or development, and (probably relatedly) there are, as far as I'm aware, no organizations wishing to engage such professional support. > Remember that despite the failing testsuites, these users are still > *using* SBCL and they find it useful -- except the banner. If they > weren't using it, they wouldn't be reporting the annoyance in the > first place. The annoyance, historically, has served two purposes: one, to provide an unmistakable warning that things might not be as stable as they might be on this particular platform; two, as a mechanism to force users who are annoyed by the message to rebuild the system, which provides a minimum of quality assurance on the platform they are going to be developing on. While the first purpose is perhaps less appropriate given David's feeling that there was now nothing fundamentally wrong about the port (even if the details aren't quite there yet), the second purpose is still valid: while people aren't reporting (and, ideally, fixing) test suite problems, a mechanism to encourage users into the thought process of maintainers is still justifiable. I see my "job" (ha, professionalism) in this context not so much as a maintenance programmer or release engineer, but as community sustainer: clearly, people come and go from their SBCL involvement (and I am no exception in this respect) and so I think it's important to broaden the pool of SBCL users who can transition into SBCL developers. If not by an obnoxious message (and I agree that it doesn't seem to be achieving a fantastic conversion rate), then how? Cheers, Christophe |
From: Gabriel D. R. <gd...@in...> - 2013-08-20 09:55:54
|
On Tue, Aug 20, 2013 at 4:29 AM, Christophe Rhodes <cs...@ca...> wrote: […] >> Remember that despite the failing testsuites, these users are still >> *using* SBCL and they find it useful -- except the banner. If they >> weren't using it, they wouldn't be reporting the annoyance in the >> first place. > > The annoyance, historically, has served two purposes: one, to provide an > unmistakable warning that things might not be as stable as they might be > on this particular platform; two, as a mechanism to force users who are > annoyed by the message to rebuild the system, which provides a minimum > of quality assurance on the platform they are going to be developing > on. While the first purpose is perhaps less appropriate given David's > feeling that there was now nothing fundamentally wrong about the port > (even if the details aren't quite there yet), the second purpose is > still valid: while people aren't reporting (and, ideally, fixing) test > suite problems, a mechanism to encourage users into the thought process > of maintainers is still justifiable. > > I see my "job" (ha, professionalism) in this context not so much as a > maintenance programmer or release engineer, but as community sustainer: > clearly, people come and go from their SBCL involvement (and I am no > exception in this respect) and so I think it's important to broaden the > pool of SBCL users who can transition into SBCL developers. If not by > an obnoxious message (and I agree that it doesn't seem to be achieving > a fantastic conversion rate), then how? You can catch more flies with honey than with vinegar. For OpenAxiom purposes for instance, I've considered several times to switch to using SBCL on Windows but never implemented that choice despite the recent excellent improvements (thanks by the way!) A key part of that decision is that I just don't think it is appropriate for me to subject OpenAxiom users to that kind of message. The message plays into a certain stereotype that I don't believe was intended by SBCL developers. No SBCL port is perfect, free of bugs or annoyances; but it appears to be that the Windows port is unnecessarily stigmatized in a way that does not appear to magically improve it. -- Gaby |
From: Christophe R. <cs...@ca...> - 2013-08-20 10:52:28
|
Gabriel Dos Reis <gd...@in...> writes: > You can catch more flies with honey than with vinegar. Well, maybe, but I don't want a deluge of flies either. > For OpenAxiom purposes for instance, I've considered several times to switch > to using SBCL on Windows but never implemented that choice despite > the recent excellent improvements (thanks by the way!) A key part of that > decision is that I just don't think it is appropriate for me to subject > OpenAxiom users to that kind of message. Well, this is (it seems to me) exactly the case that the message is designed to arrange. While it might be nice if SBCL, through OpenAxiom, gained a number of users, on Windows there's some chance that this would be a support headache, with OpenAxiom users encountering difficulties, and becoming frustrated with SBCL developers when they are not rapidly responsive to their problems. If, nevertheless, you as OpenAxiom maintainer think that SBCL is best for your users, you can take this responsibility upon yourself by distributing a modified SBCL (with the offending message patched out). But then the responsibility to handle the bug reports of OpenAxiom users would clearly be yours -- and while I'm sure the SBCL developers would want to help to the best of their ability, it is a question of responsibility, and communicating that responsibility downstream effectively. Maybe another way of looking at it is that we as volunteers can carefully protect our "professionalism", such as it is, by limiting the demands placed on us. > The message plays into a certain stereotype that I don't believe was > intended by SBCL developers. Well, I think that many things were intended, but I obviously don't know what stereotype you're referring to. For what it's worth, thinking of "SBCL developers" as a monolithic bloc is probably a mistake, and certainly I don't think that SBCL developers in general are attempting to be bland corporate software engineers. Cheers, Christophe |
From: Gabriel D. R. <gd...@in...> - 2013-08-20 11:15:32
|
On Tue, Aug 20, 2013 at 5:52 AM, Christophe Rhodes <cs...@ca...> wrote: > Gabriel Dos Reis <gd...@in...> writes: > >> You can catch more flies with honey than with vinegar. > > Well, maybe, but I don't want a deluge of flies either. > >> For OpenAxiom purposes for instance, I've considered several times to switch >> to using SBCL on Windows but never implemented that choice despite >> the recent excellent improvements (thanks by the way!) A key part of that >> decision is that I just don't think it is appropriate for me to subject >> OpenAxiom users to that kind of message. > > Well, this is (it seems to me) exactly the case that the message is > designed to arrange. While it might be nice if SBCL, through OpenAxiom, > gained a number of users, on Windows there's some chance that this > would be a support headache, with OpenAxiom users encountering > difficulties, and becoming frustrated with SBCL developers when they are > not rapidly responsive to their problems. Hmm, I am not quite sure what you're saying here. That you wouldn't want to have too many SBCL users on Windows that use SBCL-applications? > If, nevertheless, you as OpenAxiom maintainer think that SBCL is best > for your users, you can take this responsibility upon yourself by > distributing a modified SBCL (with the offending message patched out). > But then the responsibility to handle the bug reports of OpenAxiom users > would clearly be yours -- and while I'm sure the SBCL developers would > want to help to the best of their ability, it is a question of > responsibility, and communicating that responsibility downstream > effectively. That is indeed a possibility. When I said I've considered switching to SBCL as the Lisp system, I didn't elaborate on the alternatives and why. On most linux systems, SBCL is the default. I like consistency in dealing with bug reports, so I figured defaulting Windows build to SBCL will increase that. The alternative I've are GCL and Clozure CL. > > Maybe another way of looking at it is that we as volunteers can > carefully protect our "professionalism", such as it is, by limiting the > demands placed on us. Aha; it could be argued that such protection could be better articulated by saying it in plain language than through an obnoxious message :-) >> The message plays into a certain stereotype that I don't believe was >> intended by SBCL developers. > > Well, I think that many things were intended, but I obviously don't know > what stereotype you're referring to. For what it's worth, thinking of > "SBCL developers" as a monolithic bloc is probably a mistake, and > certainly I don't think that SBCL developers in general are attempting > to be bland corporate software engineers. Thank you for your input. I have a better understanding of the philosophy behind this. > > Cheers, > > Christophe |
From: Paul K. <pv...@pv...> - 2013-08-20 12:06:14
|
Christophe Rhodes wrote: > [ I don't have a particularly strong feeling about messages, though I > myself do not plan to act to remove any messages on platforms I don't > use. However... ] Same, but with an emphasis on *remove*. > Gabriel Dos Reis<gd...@in...> writes: >> Remember that despite the failing testsuites, these users are still >> *using* SBCL and they find it useful -- except the banner. If they >> weren't using it, they wouldn't be reporting the annoyance in the >> first place. > > The annoyance, historically, has served two purposes: one, to provide an > unmistakable warning that things might not be as stable as they might be > on this particular platform; two, as a mechanism to force users who are > annoyed by the message to rebuild the system, which provides a minimum > of quality assurance on the platform they are going to be developing > on. While the first purpose is perhaps less appropriate given David's > feeling that there was now nothing fundamentally wrong about the port > (even if the details aren't quite there yet), the second purpose is > still valid: while people aren't reporting (and, ideally, fixing) test > suite problems, a mechanism to encourage users into the thought process > of maintainers is still justifiable. I think it's important to remember the kind of issues that we had when we initially released versions with the CATS message: the initial thread on the win32 port would sometimes return to the C runtime, something that should never happen. I don't remember anyone reporting that they've seen the "CATS ARE NICE." message in a long while, and David's more informed opinion points in the same direction. I also understand that the Windows ports seem particularly weak: their threads are untrustworthy, but there's no way to disable threads either, and the situation is worsened by the fact that few people think of Windows/x86oids as niche platforms. It seems to me the discussion between supporters and opponents of the cats "warning" is running on two parallel tracks: some would like a warning to remain, while others would prefer the "Kitten of Death" message, in all its whimsicality, opacity and compulsoriness to go away. What do you think of: 1. removing the cat messages; 2. replacing the "CATS ARE NICE." lossage with a more informative string; 3. adding a warning in print_banner to the effect that the Windows port may be useful, but is definitely fragile -- one might even add an explicit ask for involvement in development/testing; 4. considering a similar note on other platforms that are the object of less maintenance and testing? In terms of visibility, the only difference between that proposal and the current situation is that the banner can be disabled with --noinform. I'm with Christophe, in that I don't think it's ideal to have a deluge of new users expecting a solid product when we don't have the developers (or even development machines) to respond to bug reports. However, if a project like OpenAxiom ever releases cores with --noinform, I hope it's clear that the onus will be on them to primarily support their end users, even if they hit issues in our code. I would certainly wonder how an inexperienced end-user goes from running Open Axiom to reporting a bug to SBCL, in the absence of the bootup banner (and its associated warning). Paul Khuong |
From: Christophe R. <cs...@ca...> - 2013-08-20 12:58:34
|
Paul Khuong <pv...@pv...> writes: > It seems to me the discussion between supporters and opponents of the > cats "warning" is running on two parallel tracks: some would like a > warning to remain, while others would prefer the "Kitten of Death" > message, in all its whimsicality, opacity and compulsoriness to go away. > What do you think of: > 1. removing the cat messages; > 2. replacing the "CATS ARE NICE." lossage with a more informative string; > 3. adding a warning in print_banner to the effect that the Windows port > may be useful, but is definitely fragile -- one might even add an > explicit ask for involvement in development/testing; > 4. considering a similar note on other platforms that are the object of > less maintenance and testing? Fine with me, though I think Windows is particularly problematic for us in its combination of general development culture, SBCL development manpower and empirical SBCL bug count. For example, I'm sure that our HPPA/Linux port is so riddled with bugs that it isn't close to building any more, but on the other hand anyone trying to run a lisp product on HPPA/Linux is already in the category of either knowing what they are doing or expecting to have to work hard. I think that (justifiably) Windows developers are more used to having things that work with relatively few problems, and just get on and use the things, and I don't think that SBCL is in that category. I won't try to argue for whimsy; arguably SBCL is a teenager now, and should instead be emitting messages that ooze Angst and emotional vulnerability rather than F&SF-parody-homage, and allowing the user to specify that they do not need the message (through --noinform) is perfectly reasonable. I'm on holiday, but I plan to go through the release motions nevertheless, freezing in the next day or two. I'll happily wait for a patch along the above lines -- go on, surprise me :-) Cheers, Christophe |
From: Gabriel D. R. <gd...@in...> - 2013-08-20 15:45:24
|
On Tue, Aug 20, 2013 at 7:06 AM, Paul Khuong <pv...@pv...> wrote: > Christophe Rhodes wrote: >> [ I don't have a particularly strong feeling about messages, though I >> myself do not plan to act to remove any messages on platforms I don't >> use. However... ] > > Same, but with an emphasis on *remove*. > >> Gabriel Dos Reis<gd...@in...> writes: >>> Remember that despite the failing testsuites, these users are still >>> *using* SBCL and they find it useful -- except the banner. If they >>> weren't using it, they wouldn't be reporting the annoyance in the >>> first place. >> >> The annoyance, historically, has served two purposes: one, to provide an >> unmistakable warning that things might not be as stable as they might be >> on this particular platform; two, as a mechanism to force users who are >> annoyed by the message to rebuild the system, which provides a minimum >> of quality assurance on the platform they are going to be developing >> on. While the first purpose is perhaps less appropriate given David's >> feeling that there was now nothing fundamentally wrong about the port >> (even if the details aren't quite there yet), the second purpose is >> still valid: while people aren't reporting (and, ideally, fixing) test >> suite problems, a mechanism to encourage users into the thought process >> of maintainers is still justifiable. > > I think it's important to remember the kind of issues that we had when > we initially released versions with the CATS message: the initial thread > on the win32 port would sometimes return to the C runtime, something > that should never happen. I don't remember anyone reporting that they've > seen the "CATS ARE NICE." message in a long while, and David's more > informed opinion points in the same direction. > > I also understand that the Windows ports seem particularly weak: their > threads are untrustworthy, but there's no way to disable threads either, > and the situation is worsened by the fact that few people think of > Windows/x86oids as niche platforms. > > It seems to me the discussion between supporters and opponents of the > cats "warning" is running on two parallel tracks: some would like a > warning to remain, while others would prefer the "Kitten of Death" > message, in all its whimsicality, opacity and compulsoriness to go away. > What do you think of: > 1. removing the cat messages; > 2. replacing the "CATS ARE NICE." lossage with a more informative string; > 3. adding a warning in print_banner to the effect that the Windows port > may be useful, but is definitely fragile -- one might even add an > explicit ask for involvement in development/testing; > 4. considering a similar note on other platforms that are the object of > less maintenance and testing? > > In terms of visibility, the only difference between that proposal and > the current situation is that the banner can be disabled with > --noinform. I'm with Christophe, in that I don't think it's ideal to > have a deluge of new users expecting a solid product when we don't have > the developers (or even development machines) to respond to bug reports. > However, if a project like OpenAxiom ever releases cores with > --noinform, I hope it's clear that the onus will be on them to primarily > support their end users, even if they hit issues in our code. I would > certainly wonder how an inexperienced end-user goes from running Open > Axiom to reporting a bug to SBCL, in the absence of the bootup banner > (and its associated warning). > > Paul Khuong Hi Paul, This proposal makes the most sense to me, and reminds me of why I decided to make SBCL the default Lisp system of OpenAxiom :-) Thanks! -- Gaby |
From: <ra...@ra...> - 2013-08-20 16:00:48
|
>> I see my "job" (ha, professionalism) in this context not so much as a >> maintenance programmer or release engineer, but as community sustainer: >> clearly, people come and go from their SBCL involvement (and I am no >> exception in this respect) and so I think it's important to broaden the >> pool of SBCL users who can transition into SBCL developers. If not by >> an obnoxious message (and I agree that it doesn't seem to be achieving >> a fantastic conversion rate), then how? By growing the number of SBCL users. In this case the number of SBCL users on Windows. It's been my experience that there's little way to improve the percentage of users who become developers. That stays fairly constant. Actually, the percentage seems to go down for widely-used projects, though the number of developers goes up. Casting a wide net catches more fish. And a good way to do that is by providing at least a base level of usability that people find useful. You're more likely to convert a user (like me) to a developer if they're using the project anyway. In my case, the kitten of death limits SBCL's usefulness to me. The people who I write software for are non-technical people using Windows. They don't want to see the kitten of death. They don't get it, and couldn't do anything about it if they did. They certainly don't want restarts. Pascal's The Human Consequences of Dynamic Typing example, to them, is code that sucks. The SBCL maintainers' users may be guys like me, but I have my own users to provide for. I can certainly develop applications in SBCL that only I use, and I will probably continue to do so. But the kitten makes it politically difficult to develop applications that I give to others. And yes, my users will complain to me even if it's a problem with SBCL. That's always been true, regardless of the development tools any developer uses. Anton et al. have make very real progress in Windows support (thanks!). Just the ability to have foreign threads call back into SBCL (a feature I was told years ago couldn't be done) has made some of my home projects possible in SBCL. Threading works decently for at least trivial cases. I get dropped into ldb with the gc invariant lost a lot less than I used to (usually during heavily CFFI code that's being run and re-run and re-run again). In this way, Anton and his compatiots have gone a long way to attract SBCL users on Windows. The company I work for has already invested resources in some open source projects that we find useful. But those projects were useful to us prior to committing resources to their improvement. Neil Gilmore ra...@ra... |
From: Christophe R. <cs...@ca...> - 2013-08-20 17:28:01
|
ra...@ra... writes: > In my case, the kitten of death limits SBCL's usefulness to me. The people > who I write software for are non-technical people using Windows. They > don't want to see the kitten of death. They don't get it, and couldn't do > anything about it if they did. They certainly don't want restarts. > Pascal's The Human Consequences of Dynamic Typing example, to them, is > code that sucks. The SBCL maintainers' users may be guys like me, but I > have my own users to provide for. I can certainly develop applications in > SBCL that only I use, and I will probably continue to do so. But the > kitten makes it politically difficult to develop applications that I give > to others. And yes, my users will complain to me even if it's a problem > with SBCL. That's always been true, regardless of the development tools > any developer uses. OK, so let me try to understand this: you have the opportunity to write applications for others, using SBCL. Presumably you distribute binaries to them -- I can't imagine that the kinds of non-technical users you describe are assembling their own components (but maybe I am wrong). And yet: SBCL's utility is limited to you by a line in the SBCL source with essentially no function that is trivial to patch out? As for growing the pool of potential but lowering the ratio of developers: I agree with this in principle, but in this case it seems to me to be problematic, because the effective ratio of active maintainers of SBCL on Windows is already zero. Cheers, Christophe |
From: Gabriel D. R. <gd...@in...> - 2013-08-20 18:58:23
|
On Tue, Aug 20, 2013 at 12:27 PM, Christophe Rhodes <cs...@ca...> wrote: > OK, so let me try to understand this: you have the opportunity to write > applications for others, using SBCL. Presumably you distribute binaries > to them -- I can't imagine that the kinds of non-technical users you > describe are assembling their own components (but maybe I am wrong). > And yet: SBCL's utility is limited to you by a line in the SBCL source > with essentially no function that is trivial to patch out? I'd bet you are familiar with this: the number of lines or the number of characters that piece of code is made of is not necessarily a reliable measure of its usefulness. In the case of OpenAxiom, I've already explained this. SBCL is the default Lisp system for OpenAxiom on GNU/Linux systems. I can't make it the default on Windows -- where we actually have lot of users, but most of whom non-Lisp technical users -- in most part because of this unhelpful message. -- Gaby |
From: Christophe R. <cs...@ca...> - 2013-08-20 20:44:17
|
Gabriel Dos Reis <gd...@in...> writes: > In the case of OpenAxiom, I've already explained this. SBCL is > the default Lisp system for OpenAxiom on GNU/Linux systems. > I can't make it the default on Windows -- where we actually have lot > of users, but most of whom non-Lisp technical users -- in most > part because of this unhelpful message. But in the case of OpenAxiom, you (apparently, according to your website), are distributing source, which you expect your users to compile with the lisp implementation of their choice. If I go to <http://www.open-axiom.org/download.html>, I find only source distributions, not binaries, and the INSTALL instructions inform the prospective users that they must have a Lisp system already installed in order to build OpenAxiom itself. In the message of Neil Gilmore that I was replying to, he alluded to non-technical users for whom he was developing software, which (I presume) would be delivered in binary form. I understand your case, where you require your users to install a Lisp system from upstream on their own; I am trying to understand his case, where (again, I presume) the distribution is in binary form, and where the modification of the system to remove any message would need to be done only on the developer's system. Cheers, Christophe |
From: Gabriel D. R. <gd...@in...> - 2013-08-20 23:10:19
|
On Tue, Aug 20, 2013 at 3:44 PM, Christophe Rhodes <cs...@ca...> wrote: > Gabriel Dos Reis <gd...@in...> writes: > >> In the case of OpenAxiom, I've already explained this. SBCL is >> the default Lisp system for OpenAxiom on GNU/Linux systems. >> I can't make it the default on Windows -- where we actually have lot >> of users, but most of whom non-Lisp technical users -- in most >> part because of this unhelpful message. > > But in the case of OpenAxiom, you (apparently, according to your > website), are distributing source, which you expect your users to > compile with the lisp implementation of their choice. If I go to > <http://www.open-axiom.org/download.html>, I find only source > distributions, not binaries, and the INSTALL instructions inform the > prospective users that they must have a Lisp system already installed in > order to build OpenAxiom itself. For Windows (mostly XP and 7), I distribute binaries. The sources are there for any adventurous Windows user. > > In the message of Neil Gilmore that I was replying to, he alluded to > non-technical users for whom he was developing software, which (I > presume) would be delivered in binary form. I understand your case, > where you require your users to install a Lisp system from upstream on > their own; I am trying to understand his case, where (again, I presume) > the distribution is in binary form, and where the modification of the > system to remove any message would need to be done only on the > developer's system. > > Cheers, > > Christophe |
From: Paul K. <pv...@pv...> - 2013-08-21 04:04:59
|
Paul Khuong wrote: > Christophe Rhodes wrote: >> [ I don't have a particularly strong feeling about messages, though I >> myself do not plan to act to remove any messages on platforms I don't >> use. However... ] > > Same, but with an emphasis on *remove*. [...] > What do you think of: > 1. removing the cat messages; > 2. replacing the "CATS ARE NICE." lossage with a more informative string; > 3. adding a warning in print_banner to the effect that the Windows port > may be useful, but is definitely fragile -- one might even add an > explicit ask for involvement in development/testing; > 4. considering a similar note on other platforms that are the object of > less maintenance and testing? 1-3 are implemented as of b7d22de (Replace the Kitten of Death message with a warning in the banner). I hope this satisfies everyone. Paul Khuong |
From: Gabriel D. R. <gd...@in...> - 2013-08-21 05:59:05
|
On Tue, Aug 20, 2013 at 11:04 PM, Paul Khuong <pv...@pv...> wrote: > Paul Khuong wrote: >> Christophe Rhodes wrote: >>> [ I don't have a particularly strong feeling about messages, though I >>> myself do not plan to act to remove any messages on platforms I don't >>> use. However... ] >> >> Same, but with an emphasis on *remove*. > > [...] > >> What do you think of: >> 1. removing the cat messages; >> 2. replacing the "CATS ARE NICE." lossage with a more informative string; >> 3. adding a warning in print_banner to the effect that the Windows port >> may be useful, but is definitely fragile -- one might even add an >> explicit ask for involvement in development/testing; >> 4. considering a similar note on other platforms that are the object of >> less maintenance and testing? > > 1-3 are implemented as of b7d22de (Replace the Kitten of Death message > with a warning in the banner). I hope this satisfies everyone. Thank you very much, Paul! -- Gaby |