From: 73budden . <bud...@gm...> - 2017-11-14 19:26:09
|
Hi all! It looks like I have a draft of changes to SBCL which resolve that "cons integer" issue: (defparameter *g* (cons 1 2)) (defun g () (setf (car *g*) 'a)) (defun f (x) (when (typep x '(cons fixnum)) (g) (if (typep x '(cons fixnum)) "Still cons fixnum!" "Not cons fixnum"))) (f *g*) ==> "Still cons fixnum!" ; in my branch is would be "Not cons fixnum" My SBCL repo is here: https://github.com/budden/sbclt/tree/safer-type-derivation-kind-of-works goals of the project are here: https://github.com/budden/sbclt/blob/safer-type-derivation-kind-of-works/README.sbclt Tests are kept separatedly for now, look here: https://bitbucket.org/budden/sbcl-strict-type-check/src/8e81344afb62b999f0bfce49d3530c5caf205c4c/typep-never-changes-p-tests-2.lisp?at=safer-type-derivation-kind-of-works&fileviewer=file-view-default sh run-tests.sh passes except one (not very important) test. Also it is possible to build SBCL using this patched SBCL as a bootstrapping CL implementation. I think this is not that bad, but for nor now it is only a prototype. More work is required. Nevertheless I announce my project now in case someone wants to contribute :) Comments are welcome also. WBR, Budden |
From: Stas B. <sta...@gm...> - 2017-11-14 20:35:36
|
New goal: make your own mailing list and discuss it there, not on sbcl-devel@. Bonus goal: choose a different name for the fork. On Tue, Nov 14, 2017 at 10:26 PM 73budden . <bud...@gm...> wrote: > Hi all! > > It looks like I have a draft of changes to SBCL which resolve that > "cons integer" issue: > > (defparameter *g* (cons 1 2)) > (defun g () (setf (car *g*) 'a)) > > (defun f (x) > (when (typep x '(cons fixnum)) > (g) > (if (typep x '(cons fixnum)) > "Still cons fixnum!" > "Not cons fixnum"))) > (f *g*) ==> "Still cons fixnum!" ; in my branch is would be "Not cons > fixnum" > > My SBCL repo is here: > > https://github.com/budden/sbclt/tree/safer-type-derivation-kind-of-works > > goals of the project are here: > > > https://github.com/budden/sbclt/blob/safer-type-derivation-kind-of-works/README.sbclt > > Tests are kept separatedly for now, look here: > > > https://bitbucket.org/budden/sbcl-strict-type-check/src/8e81344afb62b999f0bfce49d3530c5caf205c4c/typep-never-changes-p-tests-2.lisp?at=safer-type-derivation-kind-of-works&fileviewer=file-view-default > > sh run-tests.sh passes except one (not very important) test. Also it > is possible to build SBCL using this patched SBCL as a bootstrapping > CL implementation. I think this is not that bad, but for nor now it is > only a prototype. More work is required. > > Nevertheless I announce my project now in case someone wants to contribute > :) > Comments are welcome also. > > WBR, Budden > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: 73budden . <bud...@gm...> - 2017-11-14 22:01:51
|
My announce consists of several parts. Obviously, some of them are out of scope of sbcl-devel and I'm wont' discuss them here any more. But the main result so far is a fix of a specific generic (all platform) bug in SBCL. Can you please clarify if sbcl-devel is a proper place to discuss bugs in SBCL and fixes for them or not. 2017-11-14 23:35 GMT+03:00, Stas Boukarev <sta...@gm...>: > New goal: make your own mailing list and discuss it there, not on > sbcl-devel@. > Bonus goal: choose a different name for the fork. > > On Tue, Nov 14, 2017 at 10:26 PM 73budden . <bud...@gm...> wrote: > >> Hi all! >> >> It looks like I have a draft of changes to SBCL which resolve that >> "cons integer" issue: >> >> (defparameter *g* (cons 1 2)) >> (defun g () (setf (car *g*) 'a)) >> >> (defun f (x) >> (when (typep x '(cons fixnum)) >> (g) >> (if (typep x '(cons fixnum)) >> "Still cons fixnum!" >> "Not cons fixnum"))) >> (f *g*) ==> "Still cons fixnum!" ; in my branch is would be "Not cons >> fixnum" >> >> My SBCL repo is here: >> >> https://github.com/budden/sbclt/tree/safer-type-derivation-kind-of-works >> >> goals of the project are here: >> >> >> https://github.com/budden/sbclt/blob/safer-type-derivation-kind-of-works/README.sbclt >> >> Tests are kept separatedly for now, look here: >> >> >> https://bitbucket.org/budden/sbcl-strict-type-check/src/8e81344afb62b999f0bfce49d3530c5caf205c4c/typep-never-changes-p-tests-2.lisp?at=safer-type-derivation-kind-of-works&fileviewer=file-view-default >> >> sh run-tests.sh passes except one (not very important) test. Also it >> is possible to build SBCL using this patched SBCL as a bootstrapping >> CL implementation. I think this is not that bad, but for nor now it is >> only a prototype. More work is required. >> >> Nevertheless I announce my project now in case someone wants to >> contribute >> :) >> Comments are welcome also. >> >> WBR, Budden >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Sbcl-devel mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> > |
From: James Y K. <fo...@fu...> - 2017-11-16 15:31:40
|
As you might recall, I had encouraged them to send patches resolving that issue to this list. And in response to the first such patch, you tell them to go away. Please don't do that, it's quite rude and unnecessary. Do you not consider the incorrect type derivation of (cons integer) to be a bug? It seems pretty obviously a bug to me. On Tue, November 14, 2017 3:35 pm, Stas Boukarev wrote: > New goal: make your own mailing list and discuss it there, not on > sbcl-devel@. > Bonus goal: choose a different name for the fork. > > On Tue, Nov 14, 2017 at 10:26 PM 73budden . <bud...@gm...> wrote: > >> Hi all! >> >> It looks like I have a draft of changes to SBCL which resolve that >> "cons integer" issue: >> >> (defparameter *g* (cons 1 2)) >> (defun g () (setf (car *g*) 'a)) >> >> (defun f (x) >> (when (typep x '(cons fixnum)) >> (g) >> (if (typep x '(cons fixnum)) >> "Still cons fixnum!" >> "Not cons fixnum"))) >> (f *g*) ==> "Still cons fixnum!" ; in my branch is would be "Not cons >> fixnum" >> >> My SBCL repo is here: >> >> https://github.com/budden/sbclt/tree/safer-type-derivation-kind-of-works >> >> goals of the project are here: >> >> >> https://github.com/budden/sbclt/blob/safer-type-derivation-kind-of-works/README.sbclt >> >> Tests are kept separatedly for now, look here: >> >> >> https://bitbucket.org/budden/sbcl-strict-type-check/src/8e81344afb62b999f0bfce49d3530c5caf205c4c/typep-never-changes-p-tests-2.lisp?at=safer-type-derivation-kind-of-works&fileviewer=file-view-default >> >> sh run-tests.sh passes except one (not very important) test. Also it >> is possible to build SBCL using this patched SBCL as a bootstrapping >> CL implementation. I think this is not that bad, but for nor now it is >> only a prototype. More work is required. >> >> Nevertheless I announce my project now in case someone wants to >> contribute >> :) >> Comments are welcome also. >> >> WBR, Budden >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Sbcl-devel mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! > http://sdm.link/slashdot_______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Stas B. <sta...@gm...> - 2017-11-16 15:34:57
|
If someone decides to fork something, it's their deal. Doesn't mean there will be any help from the original project. I don't recall any bug reports about type derivation. On Thu, Nov 16, 2017 at 6:31 PM James Y Knight <fo...@fu...> wrote: > As you might recall, I had encouraged them to send patches resolving that > issue to this list. And in response to the first such patch, you tell them > to go away. Please don't do that, it's quite rude and unnecessary. > > Do you not consider the incorrect type derivation of (cons integer) to be > a bug? It seems pretty obviously a bug to me. > > > On Tue, November 14, 2017 3:35 pm, Stas Boukarev wrote: > > New goal: make your own mailing list and discuss it there, not on > > sbcl-devel@. > > Bonus goal: choose a different name for the fork. > > > > On Tue, Nov 14, 2017 at 10:26 PM 73budden . <bud...@gm...> wrote: > > > >> Hi all! > >> > >> It looks like I have a draft of changes to SBCL which resolve that > >> "cons integer" issue: > >> > >> (defparameter *g* (cons 1 2)) > >> (defun g () (setf (car *g*) 'a)) > >> > >> (defun f (x) > >> (when (typep x '(cons fixnum)) > >> (g) > >> (if (typep x '(cons fixnum)) > >> "Still cons fixnum!" > >> "Not cons fixnum"))) > >> (f *g*) ==> "Still cons fixnum!" ; in my branch is would be "Not cons > >> fixnum" > >> > >> My SBCL repo is here: > >> > >> > https://github.com/budden/sbclt/tree/safer-type-derivation-kind-of-works > >> > >> goals of the project are here: > >> > >> > >> > https://github.com/budden/sbclt/blob/safer-type-derivation-kind-of-works/README.sbclt > >> > >> Tests are kept separatedly for now, look here: > >> > >> > >> > https://bitbucket.org/budden/sbcl-strict-type-check/src/8e81344afb62b999f0bfce49d3530c5caf205c4c/typep-never-changes-p-tests-2.lisp?at=safer-type-derivation-kind-of-works&fileviewer=file-view-default > >> > >> sh run-tests.sh passes except one (not very important) test. Also it > >> is possible to build SBCL using this patched SBCL as a bootstrapping > >> CL implementation. I think this is not that bad, but for nor now it is > >> only a prototype. More work is required. > >> > >> Nevertheless I announce my project now in case someone wants to > >> contribute > >> :) > >> Comments are welcome also. > >> > >> WBR, Budden > >> > >> > >> > ------------------------------------------------------------------------------ > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> _______________________________________________ > >> Sbcl-devel mailing list > >> Sbc...@li... > >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel > >> > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! > > http://sdm.link/slashdot_______________________________________________ > > Sbcl-devel mailing list > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > > > > |
From: James Y K. <fo...@fu...> - 2017-11-16 16:08:24
|
The code demonstrating the bug is literally right there in the email...and was discussed previously here as well. And just because someone wants to try out some ideas which the original project has said it doesn't want to integrate doesn't mean you need to dismiss all their attempts at contributing back OTHER things. Why be a jerk about it? On Thu, November 16, 2017 10:34 am, Stas Boukarev wrote: > If someone decides to fork something, it's their deal. Doesn't mean there > will be any help from the original project. > I don't recall any bug reports about type derivation. > > On Thu, Nov 16, 2017 at 6:31 PM James Y Knight <fo...@fu...> wrote: > >> As you might recall, I had encouraged them to send patches resolving >> that >> issue to this list. And in response to the first such patch, you tell >> them >> to go away. Please don't do that, it's quite rude and unnecessary. >> >> Do you not consider the incorrect type derivation of (cons integer) to >> be >> a bug? It seems pretty obviously a bug to me. >> >> >> On Tue, November 14, 2017 3:35 pm, Stas Boukarev wrote: >> > New goal: make your own mailing list and discuss it there, not on >> > sbcl-devel@. >> > Bonus goal: choose a different name for the fork. >> > >> > On Tue, Nov 14, 2017 at 10:26 PM 73budden . <bud...@gm...> >> wrote: >> > >> >> Hi all! >> >> >> >> It looks like I have a draft of changes to SBCL which resolve that >> >> "cons integer" issue: >> >> >> >> (defparameter *g* (cons 1 2)) >> >> (defun g () (setf (car *g*) 'a)) >> >> >> >> (defun f (x) >> >> (when (typep x '(cons fixnum)) >> >> (g) >> >> (if (typep x '(cons fixnum)) >> >> "Still cons fixnum!" >> >> "Not cons fixnum"))) >> >> (f *g*) ==> "Still cons fixnum!" ; in my branch is would be "Not cons >> >> fixnum" >> >> >> >> My SBCL repo is here: >> >> >> >> >> https://github.com/budden/sbclt/tree/safer-type-derivation-kind-of-works >> >> >> >> goals of the project are here: >> >> >> >> >> >> >> https://github.com/budden/sbclt/blob/safer-type-derivation-kind-of-works/README.sbclt >> >> >> >> Tests are kept separatedly for now, look here: >> >> >> >> >> >> >> https://bitbucket.org/budden/sbcl-strict-type-check/src/8e81344afb62b999f0bfce49d3530c5caf205c4c/typep-never-changes-p-tests-2.lisp?at=safer-type-derivation-kind-of-works&fileviewer=file-view-default >> >> >> >> sh run-tests.sh passes except one (not very important) test. Also it >> >> is possible to build SBCL using this patched SBCL as a bootstrapping >> >> CL implementation. I think this is not that bad, but for nor now it >> is >> >> only a prototype. More work is required. >> >> >> >> Nevertheless I announce my project now in case someone wants to >> >> contribute >> >> :) >> >> Comments are welcome also. >> >> >> >> WBR, Budden >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> _______________________________________________ >> >> Sbcl-devel mailing list >> >> Sbc...@li... >> >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> >> >> > >> ------------------------------------------------------------------------------ >> > Check out the vibrant tech community on one of the world's most >> > engaging tech sites, Slashdot.org! >> > http://sdm.link/slashdot_______________________________________________ >> > Sbcl-devel mailing list >> > Sbc...@li... >> > https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> > >> >> >> > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! > http://sdm.link/slashdot_______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Stas B. <sta...@gm...> - 2017-11-16 16:14:18
|
If you want a bug report to be noticed do not bundle it with an announcement of a fork. And I can dismiss anything I please. On Thu, Nov 16, 2017 at 7:08 PM James Y Knight <fo...@fu...> wrote: > The code demonstrating the bug is literally right there in the email...and > was discussed previously here as well. > > And just because someone wants to try out some ideas which the original > project has said it doesn't want to integrate doesn't mean you need to > dismiss all their attempts at contributing back OTHER things. > > Why be a jerk about it? > > On Thu, November 16, 2017 10:34 am, Stas Boukarev wrote: > > If someone decides to fork something, it's their deal. Doesn't mean there > > will be any help from the original project. > > I don't recall any bug reports about type derivation. > > > > On Thu, Nov 16, 2017 at 6:31 PM James Y Knight <fo...@fu...> wrote: > > > >> As you might recall, I had encouraged them to send patches resolving > >> that > >> issue to this list. And in response to the first such patch, you tell > >> them > >> to go away. Please don't do that, it's quite rude and unnecessary. > >> > >> Do you not consider the incorrect type derivation of (cons integer) to > >> be > >> a bug? It seems pretty obviously a bug to me. > >> > >> > >> On Tue, November 14, 2017 3:35 pm, Stas Boukarev wrote: > >> > New goal: make your own mailing list and discuss it there, not on > >> > sbcl-devel@. > >> > Bonus goal: choose a different name for the fork. > >> > > >> > On Tue, Nov 14, 2017 at 10:26 PM 73budden . <bud...@gm...> > >> wrote: > >> > > >> >> Hi all! > >> >> > >> >> It looks like I have a draft of changes to SBCL which resolve that > >> >> "cons integer" issue: > >> >> > >> >> (defparameter *g* (cons 1 2)) > >> >> (defun g () (setf (car *g*) 'a)) > >> >> > >> >> (defun f (x) > >> >> (when (typep x '(cons fixnum)) > >> >> (g) > >> >> (if (typep x '(cons fixnum)) > >> >> "Still cons fixnum!" > >> >> "Not cons fixnum"))) > >> >> (f *g*) ==> "Still cons fixnum!" ; in my branch is would be "Not cons > >> >> fixnum" > >> >> > >> >> My SBCL repo is here: > >> >> > >> >> > >> > https://github.com/budden/sbclt/tree/safer-type-derivation-kind-of-works > >> >> > >> >> goals of the project are here: > >> >> > >> >> > >> >> > >> > https://github.com/budden/sbclt/blob/safer-type-derivation-kind-of-works/README.sbclt > >> >> > >> >> Tests are kept separatedly for now, look here: > >> >> > >> >> > >> >> > >> > https://bitbucket.org/budden/sbcl-strict-type-check/src/8e81344afb62b999f0bfce49d3530c5caf205c4c/typep-never-changes-p-tests-2.lisp?at=safer-type-derivation-kind-of-works&fileviewer=file-view-default > >> >> > >> >> sh run-tests.sh passes except one (not very important) test. Also it > >> >> is possible to build SBCL using this patched SBCL as a bootstrapping > >> >> CL implementation. I think this is not that bad, but for nor now it > >> is > >> >> only a prototype. More work is required. > >> >> > >> >> Nevertheless I announce my project now in case someone wants to > >> >> contribute > >> >> :) > >> >> Comments are welcome also. > >> >> > >> >> WBR, Budden > >> >> > >> >> > >> >> > >> > ------------------------------------------------------------------------------ > >> >> Check out the vibrant tech community on one of the world's most > >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> >> _______________________________________________ > >> >> Sbcl-devel mailing list > >> >> Sbc...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel > >> >> > >> > > >> > ------------------------------------------------------------------------------ > >> > Check out the vibrant tech community on one of the world's most > >> > engaging tech sites, Slashdot.org! > >> > > http://sdm.link/slashdot_______________________________________________ > >> > Sbcl-devel mailing list > >> > Sbc...@li... > >> > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > >> > > >> > >> > >> > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! > > http://sdm.link/slashdot_______________________________________________ > > Sbcl-devel mailing list > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > > > > |
From: 73budden . <bud...@gm...> - 2017-11-16 16:39:06
|
> If you want a bug report to be noticed do not bundle it with an announcement of a fork. Obviously, that is only a necessary, but not a sufficient condition, because this bug was already reported on this list before. https://sourceforge.net/p/sbcl/mailman/message/36075455/ |
From: Stas B. <sta...@gm...> - 2017-11-16 16:47:37
|
A snippet buried deep in some email chain is also a good recipe for a report to be never noticed and forgotten. On Thu, Nov 16, 2017 at 7:38 PM 73budden . <bud...@gm...> wrote: > > If you want a bug report to be noticed do not bundle it with an > announcement of a fork. > Obviously, that is only a necessary, but not a sufficient condition, > because this bug was already reported on this list before. > > https://sourceforge.net/p/sbcl/mailman/message/36075455/ > |
From: Stas B. <sta...@gm...> - 2017-11-16 16:50:44
|
Filed under https://bugs.launchpad.net/sbcl/+bug/1732737 On Thu, Nov 16, 2017 at 7:47 PM Stas Boukarev <sta...@gm...> wrote: > A snippet buried deep in some email chain is also a good recipe for a > report to be never noticed and forgotten. > > On Thu, Nov 16, 2017 at 7:38 PM 73budden . <bud...@gm...> wrote: > >> > If you want a bug report to be noticed do not bundle it with an >> announcement of a fork. >> Obviously, that is only a necessary, but not a sufficient condition, >> because this bug was already reported on this list before. >> >> https://sourceforge.net/p/sbcl/mailman/message/36075455/ >> > |
From: Christophe R. <cs...@ca...> - 2017-11-21 10:44:11
|
Stas Boukarev <sta...@gm...> writes: > And I can dismiss anything I please. You can of course dismiss anything you like in your own mind. Please don't make this mailing list an unwelcoming place for discussions about different approaches, different takes, different features, different viewpoints. A large part of SBCL's early development happened with extremely friendly and supportive discussion with CMUCL's maintainers and users; the SBCL project as it is owes them thanks, and I would be sad if a similar spirit of openness weren't available to the next generation of lisp developers. Christophe |
From: Stas B. <sta...@gm...> - 2017-11-21 11:55:17
|
Well, each new project needs a mailing list and a catchy name, which was my suggestion. Granted, that's not an all embracing welcome. But if someone goes straight to forking without submitting patches and getting them discussed or rejected, and declares divergent goals like disabling structure redefinition and only supporting linux, it's evident that there's no desire for collaboration. Which is fine, just that it should use its own resources as well. We're not using cmucl-imp@, after all. On Tue, Nov 21, 2017 at 1:44 PM Christophe Rhodes <cs...@ca...> wrote: > Stas Boukarev <sta...@gm...> writes: > > > And I can dismiss anything I please. > > You can of course dismiss anything you like in your own mind. Please > don't make this mailing list an unwelcoming place for discussions about > different approaches, different takes, different features, different > viewpoints. > > A large part of SBCL's early development happened with extremely > friendly and supportive discussion with CMUCL's maintainers and users; > the SBCL project as it is owes them thanks, and I would be sad if a > similar spirit of openness weren't available to the next generation of > lisp developers. > > Christophe > |
From: 73budden . <bud...@gm...> - 2017-11-21 16:18:49
|
Thanks Christophe! My fork is not so "straight". One can take a look at bugs affecting me https://bugs.launchpad.net/~budden73/+affectingbugs and see that of those only one was fixed. Some of those bugs are severe. One was initially called "hang running thread.impure backtrace test", but Stas renamed it to "Consing inside without-gcing on sb-safepoint" which sound quite innocent simply because no one understands what does it mean. AFAIR I encountered consequences of this bug when (room) turned out to be not thread-safe for me. This bug is more than 2 years old. Bug currently being discussed was also distorted when reported by Stas. Complete test case was posted to this mailing list twice, but Stas replaced it with the code which shows no error. Also the name was chosen to be unclear. To sum up, this bug report is not a proper bug report at all: https://bugs.launchpad.net/sbcl/+bug/1732737 I'm sorry, but I can't believe this distortion was without a purpose. I have no idea what was the actual reason of the distortion, but it smells. Hence I reported the bug again as https://bugs.launchpad.net/sbcl/+bug/1733622 Also Stas ignored that I'm not asking for help, but instead I'm giving a help: I have a draft for the fix. Any review of the fix is welcome but not necessary. Observing SBCL development for some years, I noticed the following issues: - no alpha-beta-release cycle. Good for development, bad for users. - no stated goals and roadmap - some "high priority" bugs hanging for 7 years, meanwhile some minor improvements like "gc is now 5% faster" are released - ignoring many initiatives from newcomers (e.g. recent wine patch suggested, my patch for finding the source of encapsulation) - serious bugs are hidden under names expressed in technical terms which can be understood by experts only, their priority is lowered and it looks like no one is going to fix them - infriendly treatment of list visitors - no commercial support In this case one can conclude that it is unclear where SBCL goes, and that the team is not willing to collaborate (it is quite unfair to put this blame on me). So, if I want changes, the only reliable option is "fork and do it yourself". Even then, I sorted my goals in such a way that SBCL team can pull my code if it finds it suitable. WBR, Budden 2017-11-21 14:55 GMT+03:00, Stas Boukarev <sta...@gm...>: > Well, each new project needs a mailing list and a catchy name, which was my > suggestion. > Granted, that's not an all embracing welcome. > But if someone goes straight to forking without submitting patches and > getting them discussed or rejected, and declares divergent goals like > disabling structure redefinition and only supporting linux, it's evident > that there's no desire for collaboration. Which is fine, just that it > should use its own resources as well. We're not using cmucl-imp@, after > all. > > On Tue, Nov 21, 2017 at 1:44 PM Christophe Rhodes <cs...@ca...> wrote: > >> Stas Boukarev <sta...@gm...> writes: >> >> > And I can dismiss anything I please. >> >> You can of course dismiss anything you like in your own mind. Please >> don't make this mailing list an unwelcoming place for discussions about >> different approaches, different takes, different features, different >> viewpoints. >> >> A large part of SBCL's early development happened with extremely >> friendly and supportive discussion with CMUCL's maintainers and users; >> the SBCL project as it is owes them thanks, and I would be sad if a >> similar spirit of openness weren't available to the next generation of >> lisp developers. >> >> Christophe >> > |
From: Stas B. <sta...@gm...> - 2017-11-21 16:50:46
|
I have reviewed your changes and while they do fix the bug, they do it by crippling type derivation. The ticket I opened shows the path to the right fix, adjusting the way lvar-conservative-type works, since it already handles (let ((x (the (cons fixnum fixnum) (cons a b)))) (setf (car x) c) (+ (car x) (cdr x))) just needs more smarts. And SBCL has no goal, it's not an organization. Accusing people who volunteer their time of not to attending to the issues you care about is not fair. On Tue, Nov 21, 2017 at 7:18 PM 73budden . <bud...@gm...> wrote: > Thanks Christophe! > > My fork is not so "straight". > > One can take a look at bugs affecting me > https://bugs.launchpad.net/~budden73/+affectingbugs and see that of > those only one was fixed. > > Some of those bugs are severe. > > One was initially called "hang running thread.impure backtrace test", > but Stas renamed it to "Consing inside without-gcing on sb-safepoint" > which sound quite innocent simply because no one understands what does > it mean. AFAIR I encountered consequences of this bug when (room) > turned out to be not thread-safe for me. This bug is more than 2 years > old. > > Bug currently being discussed was also distorted when reported by > Stas. Complete test case was posted to this mailing list twice, but > Stas replaced it with the code which shows no error. Also the name was > chosen to be unclear. To sum up, this bug report is not a proper bug > report at all: https://bugs.launchpad.net/sbcl/+bug/1732737 > > I'm sorry, but I can't believe this distortion was without a purpose. > I have no idea what was the actual reason of the distortion, but it > smells. > > Hence I reported the bug again as > https://bugs.launchpad.net/sbcl/+bug/1733622 > > Also Stas ignored that I'm not asking for help, but instead I'm giving > a help: I have a draft for the fix. Any review of the fix is welcome > but not necessary. > > Observing SBCL development for some years, I noticed the following issues: > - no alpha-beta-release cycle. Good for development, bad for users. > - no stated goals and roadmap > - some "high priority" bugs hanging for 7 years, meanwhile some minor > improvements like "gc is now 5% faster" are released > - ignoring many initiatives from newcomers (e.g. recent wine patch > suggested, my patch for finding the source of encapsulation) > - serious bugs are hidden under names expressed in technical terms > which can be understood by experts only, their priority is lowered and > it looks like no one is going to fix them > - infriendly treatment of list visitors > - no commercial support > > In this case one can conclude that it is unclear where SBCL goes, and > that the team is not willing to collaborate (it is quite unfair to put > this blame on me). So, if I want changes, the only reliable option is > "fork and do it yourself". Even then, I sorted my goals in such a way > that SBCL team can pull my code if it finds it suitable. > > WBR, Budden > > > > 2017-11-21 14:55 GMT+03:00, Stas Boukarev <sta...@gm...>: > > Well, each new project needs a mailing list and a catchy name, which was > my > > suggestion. > > Granted, that's not an all embracing welcome. > > But if someone goes straight to forking without submitting patches and > > getting them discussed or rejected, and declares divergent goals like > > disabling structure redefinition and only supporting linux, it's evident > > that there's no desire for collaboration. Which is fine, just that it > > should use its own resources as well. We're not using cmucl-imp@, after > > all. > > > > On Tue, Nov 21, 2017 at 1:44 PM Christophe Rhodes <cs...@ca...> > wrote: > > > >> Stas Boukarev <sta...@gm...> writes: > >> > >> > And I can dismiss anything I please. > >> > >> You can of course dismiss anything you like in your own mind. Please > >> don't make this mailing list an unwelcoming place for discussions about > >> different approaches, different takes, different features, different > >> viewpoints. > >> > >> A large part of SBCL's early development happened with extremely > >> friendly and supportive discussion with CMUCL's maintainers and users; > >> the SBCL project as it is owes them thanks, and I would be sad if a > >> similar spirit of openness weren't available to the next generation of > >> lisp developers. > >> > >> Christophe > >> > > > |
From: 73budden . <bud...@gm...> - 2017-11-28 18:53:21
|
Hi! > they do it by crippling type derivation. Unless you define what does "crippling" exactly mean here, I can't comment the essense of what you say. What I can say is that one can't derive or propagate types like (cons integer) to any other moment of time, so I cut it to "cons". So I cut (cons integer) to simply cons whenever type is transferred to other node or referred by other node. Maybe sometimes I cut (cons integer) to cons when destination node is simultaneous with source one - I don't know. Anyway, for me, emitting correct code is always more preferrable than "too smart" type inference which causes the code to be wrong. > adjusting the way lvar-conservative-type works I guess no. It didn't work until I made some changes in compiler/constraint.lisp, but if you try and win - you're welcome. 2017-11-21 19:50 GMT+03:00, Stas Boukarev <sta...@gm...>: > I have reviewed your changes and while they do fix the bug, they do it by > crippling type derivation. > The ticket I opened shows the path to the right fix, adjusting the > way lvar-conservative-type works, > since it already handles > (let ((x (the (cons fixnum fixnum) (cons a b)))) > (setf (car x) c) > (+ (car x) (cdr x))) > just needs more smarts. > > And SBCL has no goal, it's not an organization. > Accusing people who volunteer their time of not to attending to the issues > you care about is not fair. > > On Tue, Nov 21, 2017 at 7:18 PM 73budden . <bud...@gm...> wrote: > >> Thanks Christophe! >> >> My fork is not so "straight". >> >> One can take a look at bugs affecting me >> https://bugs.launchpad.net/~budden73/+affectingbugs and see that of >> those only one was fixed. >> >> Some of those bugs are severe. >> >> One was initially called "hang running thread.impure backtrace test", >> but Stas renamed it to "Consing inside without-gcing on sb-safepoint" >> which sound quite innocent simply because no one understands what does >> it mean. AFAIR I encountered consequences of this bug when (room) >> turned out to be not thread-safe for me. This bug is more than 2 years >> old. >> >> Bug currently being discussed was also distorted when reported by >> Stas. Complete test case was posted to this mailing list twice, but >> Stas replaced it with the code which shows no error. Also the name was >> chosen to be unclear. To sum up, this bug report is not a proper bug >> report at all: https://bugs.launchpad.net/sbcl/+bug/1732737 >> >> I'm sorry, but I can't believe this distortion was without a purpose. >> I have no idea what was the actual reason of the distortion, but it >> smells. >> >> Hence I reported the bug again as >> https://bugs.launchpad.net/sbcl/+bug/1733622 >> >> Also Stas ignored that I'm not asking for help, but instead I'm giving >> a help: I have a draft for the fix. Any review of the fix is welcome >> but not necessary. >> >> Observing SBCL development for some years, I noticed the following >> issues: >> - no alpha-beta-release cycle. Good for development, bad for users. >> - no stated goals and roadmap >> - some "high priority" bugs hanging for 7 years, meanwhile some minor >> improvements like "gc is now 5% faster" are released >> - ignoring many initiatives from newcomers (e.g. recent wine patch >> suggested, my patch for finding the source of encapsulation) >> - serious bugs are hidden under names expressed in technical terms >> which can be understood by experts only, their priority is lowered and >> it looks like no one is going to fix them >> - infriendly treatment of list visitors >> - no commercial support >> >> In this case one can conclude that it is unclear where SBCL goes, and >> that the team is not willing to collaborate (it is quite unfair to put >> this blame on me). So, if I want changes, the only reliable option is >> "fork and do it yourself". Even then, I sorted my goals in such a way >> that SBCL team can pull my code if it finds it suitable. >> >> WBR, Budden >> >> >> >> 2017-11-21 14:55 GMT+03:00, Stas Boukarev <sta...@gm...>: >> > Well, each new project needs a mailing list and a catchy name, which >> > was >> my >> > suggestion. >> > Granted, that's not an all embracing welcome. >> > But if someone goes straight to forking without submitting patches and >> > getting them discussed or rejected, and declares divergent goals like >> > disabling structure redefinition and only supporting linux, it's >> > evident >> > that there's no desire for collaboration. Which is fine, just that it >> > should use its own resources as well. We're not using cmucl-imp@, after >> > all. >> > >> > On Tue, Nov 21, 2017 at 1:44 PM Christophe Rhodes <cs...@ca...> >> wrote: >> > >> >> Stas Boukarev <sta...@gm...> writes: >> >> >> >> > And I can dismiss anything I please. >> >> >> >> You can of course dismiss anything you like in your own mind. Please >> >> don't make this mailing list an unwelcoming place for discussions >> >> about >> >> different approaches, different takes, different features, different >> >> viewpoints. >> >> >> >> A large part of SBCL's early development happened with extremely >> >> friendly and supportive discussion with CMUCL's maintainers and users; >> >> the SBCL project as it is owes them thanks, and I would be sad if a >> >> similar spirit of openness weren't available to the next generation of >> >> lisp developers. >> >> >> >> Christophe >> >> >> > >> > |