Re: [sage-devel] The future of polybori
Right, we started with boost-python to have a language to play with. There was no standalone cython in the first and c++ had not been so well supported by cython then. So, boost was the rapid way to get a small OSS with few dependencies. However, the middle-end ;-) is flexible, so the bindings could easily be replaced, which had been done for Sage then. Partially to avoid shipping boost-python and for performace reasons as far as I recall. Nowadays a fork could soley rely on cython, I guess. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Sunday 14 Jun 2015 17:21:21 R. Andrew Ohana wrote: I think the main reason why Sage has its own Cython bindings is mainly historical -- they existed before polybori added their own python bindings. It would probably be a better idea to use polybori's own bindings in Sage -- it makes no sense trying to maintain two sets of python bindings. That's not how I remember it (but my memory might not serve me right): As far as I know PolyBoRi always had Python bindings, but we wanted something in Cython so it integrates nicely with the rest of Sage. Also, we wanted tight integration (coercion, inheritance, etc.) some of which should now be easier due to changes to the Sage code base (e.g. mathematical hierarchy and inheritance were decoupled). I agree with the sentiment, though, and the plan: it would entail ripping the Cython bindings out and refactoring the Sage specific parts. Cheers, Martin -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
@Andrew Sorry, your Cudd sources are fine, I misunderstood some commit message. About naming: I personally would prefer BRiAl, it was on my shortlist for naming the new project 9 years ago. You are free to use it. @Martin: Thank you for your emergency call at your Blog! Its nice to see that people care about our previous work. Best regards, Alexander -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Sat, Jun 13, 2015 at 5:21 AM, 'Martin Albrecht' via sage-devel sage-devel@googlegroups.com wrote: Hi all, On Saturday 13 Jun 2015 10:41:15 Francois Bissey wrote: I think Andrew has already done quite a bit of the porting to autotools and some python 3 fixes. But neither he or I want to be a maintainer - at least for the long term. ah, sorry that I missed that. Great! How about this: 1. We create an organisation on GitHub PolyBoRi3 2. We move Andrew's current version over there I can do this. I might also rebase a few of the commits while doing so (to ease the review process), and probably rename it to BRiAl as per Alexander's suggestion. 3. I volunteer to be *a* maintainer, help would greatly be appreciated I can add you to the github organization as an owner when I make it. I envision that it would be good to split PolyBoRi up roughly as follows to make maintenance simpler (please do tell me if this is silly). This way we keep dependencies of Sage as external dependencies and don't have to suck large parts into the Sage library proper: - polybori-core (libpolybori, Cudd, groebner (?)) the C++ stuff that doesn't involve python at all. This would be a standard package in Sage (hopefully) and autotoolised. The autotoolisation of this stuff is basically done. Mainly the testsuite needs to be included. - polybori-python-binding-boost (PyPolyBoRi) the C++ boost stuff which does the Python bindings. This is not used by Sage - I believe - so we don't care much. Autotoolised, but not a priority, because Sage has its own Cython bindings reimplementing this stuff. I think the main reason why Sage has its own Cython bindings is mainly historical -- they existed before polybori added their own python bindings. It would probably be a better idea to use polybori's own bindings in Sage -- it makes no sense trying to maintain two sets of python bindings. - polybori-python The Python stuff which can be managed by distutils or whatever the kids are using now. This could in principle be an optional package, but I guess it might as well be standard given that's pure python and relatively small. Cheers, Martin -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
Your plan does look good to me Martin. Just note it wont be trivial. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On 13/06/2015, at 22:00, 'Martin Albrecht' via sage-devel sage-devel@googlegroups.com wrote: Hi all, On Friday 12 Jun 2015 13:45:05 R. Andrew Ohana wrote: What about this: Now: We work on making polybori an optional package in sage. * At least going by this thread, the number of people who use polybori in Sage is small enough for it to make sense to have polybori as an optional package. I know I might be outvoted and I haven't volunteered to just do the work, but I very much disagree with this. Dropping PolyBoRi as a default package makes Sage *a lot* less useful for me. Why does this need to happen now? Because it is a major blocker to getting sage ported to python 3.x. That’s currently the only dependency that doesn’t build with python 3.x. This is also the only thing using scons another currently python2 only thing that we very much want to ditch. François -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Saturday 13 Jun 2015 10:08:32 Francois Bissey wrote: On 13/06/2015, at 22:00, 'Martin Albrecht' via sage-devel sage-devel@googlegroups.com wrote: Hi all, On Friday 12 Jun 2015 13:45:05 R. Andrew Ohana wrote: What about this: Now: We work on making polybori an optional package in sage. * At least going by this thread, the number of people who use polybori in Sage is small enough for it to make sense to have polybori as an optional package. I know I might be outvoted and I haven't volunteered to just do the work, but I very much disagree with this. Dropping PolyBoRi as a default package makes Sage *a lot* less useful for me. Why does this need to happen now? Because it is a major blocker to getting sage ported to python 3.x. That’s currently the only dependency that doesn’t build with python 3.x. This is also the only thing using scons another currently python2 only thing that we very much want to ditch. Okay, so the problem is that the Sage library cannot be ported to Python 3 unless PolyBoRi is? That makes sense. As a corollary this would also mean that making PolyBoRi an optional package would mean to drop it entirely as it wouldn't work as soon as the transition to Python 3 is here (?) Cheers, Martin -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
I am pretty much with Martin here (although i guess he uses polybory far more often than i do). I don't know much about autotools, but i can try to give a small hand on that and the python3 part. I hope with the arrival of July i will have some spare time for that. I am also considering attending to the following Sage days in August. If somebody else is interested in that, we could try to work on that there. El sábado, 13 de junio de 2015, 12:27:36 (UTC+2), Martin Albrecht escribió: Hi all, FYI, I put this out. Let's see if there *are* other users besides me: https://martinralbrecht.wordpress.com/2015/06/13/polybori-is-dead-it-needs-your-help/ Cheers, Martin On Saturday 13 Jun 2015 11:00:16 Martin Albrecht wrote: Hi all, On Friday 12 Jun 2015 13:45:05 R. Andrew Ohana wrote: What about this: Now: We work on making polybori an optional package in sage. * At least going by this thread, the number of people who use polybori in Sage is small enough for it to make sense to have polybori as an optional package. I know I might be outvoted and I haven't volunteered to just do the work, but I very much disagree with this. Dropping PolyBoRi as a default package makes Sage *a lot* less useful for me. Why does this need to happen now? * (I looked into this before I did the autotoolization) It shouldn't take too much work to optionalize polybori -- the main effort will be its uses in the crypto code. * Polybori is the sole dependency of Sage that doesn't at least build against python 3 -- getting past this last major hurdle will make it much easier to work on porting the actual sage library to python 3. Future: The Singular team or whoever dedicates the time to maintain a sequel to polybori. * This will be required once we stop supporting python 2 in the very distant future (at least after 2020, which is the EOL for python 2). Martin -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinr...@jabber.ccc.de javascript: .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
Hi all, On Friday 12 Jun 2015 13:45:05 R. Andrew Ohana wrote: What about this: Now: We work on making polybori an optional package in sage. * At least going by this thread, the number of people who use polybori in Sage is small enough for it to make sense to have polybori as an optional package. I know I might be outvoted and I haven't volunteered to just do the work, but I very much disagree with this. Dropping PolyBoRi as a default package makes Sage *a lot* less useful for me. Why does this need to happen now? * (I looked into this before I did the autotoolization) It shouldn't take too much work to optionalize polybori -- the main effort will be its uses in the crypto code. * Polybori is the sole dependency of Sage that doesn't at least build against python 3 -- getting past this last major hurdle will make it much easier to work on porting the actual sage library to python 3. Future: The Singular team or whoever dedicates the time to maintain a sequel to polybori. * This will be required once we stop supporting python 2 in the very distant future (at least after 2020, which is the EOL for python 2). Martin -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
Hi all, FYI, I put this out. Let's see if there *are* other users besides me: https://martinralbrecht.wordpress.com/2015/06/13/polybori-is-dead-it-needs-your-help/ Cheers, Martin On Saturday 13 Jun 2015 11:00:16 Martin Albrecht wrote: Hi all, On Friday 12 Jun 2015 13:45:05 R. Andrew Ohana wrote: What about this: Now: We work on making polybori an optional package in sage. * At least going by this thread, the number of people who use polybori in Sage is small enough for it to make sense to have polybori as an optional package. I know I might be outvoted and I haven't volunteered to just do the work, but I very much disagree with this. Dropping PolyBoRi as a default package makes Sage *a lot* less useful for me. Why does this need to happen now? * (I looked into this before I did the autotoolization) It shouldn't take too much work to optionalize polybori -- the main effort will be its uses in the crypto code. * Polybori is the sole dependency of Sage that doesn't at least build against python 3 -- getting past this last major hurdle will make it much easier to work on porting the actual sage library to python 3. Future: The Singular team or whoever dedicates the time to maintain a sequel to polybori. * This will be required once we stop supporting python 2 in the very distant future (at least after 2020, which is the EOL for python 2). Martin -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On 13/06/2015, at 22:30, 'Martin Albrecht' via sage-devel sage-devel@googlegroups.com wrote: On Saturday 13 Jun 2015 10:08:32 Francois Bissey wrote: On 13/06/2015, at 22:00, 'Martin Albrecht' via sage-devel sage-devel@googlegroups.com wrote: Hi all, On Friday 12 Jun 2015 13:45:05 R. Andrew Ohana wrote: What about this: Now: We work on making polybori an optional package in sage. * At least going by this thread, the number of people who use polybori in Sage is small enough for it to make sense to have polybori as an optional package. I know I might be outvoted and I haven't volunteered to just do the work, but I very much disagree with this. Dropping PolyBoRi as a default package makes Sage *a lot* less useful for me. Why does this need to happen now? Because it is a major blocker to getting sage ported to python 3.x. That’s currently the only dependency that doesn’t build with python 3.x. This is also the only thing using scons another currently python2 only thing that we very much want to ditch. Okay, so the problem is that the Sage library cannot be ported to Python 3 unless PolyBoRi is? That makes sense. As a corollary this would also mean that making PolyBoRi an optional package would mean to drop it entirely as it wouldn't work as soon as the transition to Python 3 is here (?) I am not sure we will just transition to python 3.x and just drop python 2.7. There will probably be a period where we work on both python 3.x and 2.7. Of course 3.x will get more and more attention over time. But while sage is buildable with python 2.7, polybori could be used with it. I think Andrew has already done quite a bit of the porting to autotools and some python 3 fixes. But neither he or I want to be a maintainer - at least for the long term. François -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
Hi all, On Saturday 13 Jun 2015 10:41:15 Francois Bissey wrote: I think Andrew has already done quite a bit of the porting to autotools and some python 3 fixes. But neither he or I want to be a maintainer - at least for the long term. ah, sorry that I missed that. Great! How about this: 1. We create an organisation on GitHub PolyBoRi3 2. We move Andrew's current version over there 3. I volunteer to be *a* maintainer, help would greatly be appreciated I envision that it would be good to split PolyBoRi up roughly as follows to make maintenance simpler (please do tell me if this is silly). This way we keep dependencies of Sage as external dependencies and don't have to suck large parts into the Sage library proper: - polybori-core (libpolybori, Cudd, groebner (?)) the C++ stuff that doesn't involve python at all. This would be a standard package in Sage (hopefully) and autotoolised. - polybori-python-binding-boost (PyPolyBoRi) the C++ boost stuff which does the Python bindings. This is not used by Sage - I believe - so we don't care much. Autotoolised, but not a priority, because Sage has its own Cython bindings reimplementing this stuff. - polybori-python The Python stuff which can be managed by distutils or whatever the kids are using now. This could in principle be an optional package, but I guess it might as well be standard given that's pure python and relatively small. Cheers, Martin -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [sage-devel] The future of polybori
I started talking to some people from the symbolic computation community to discuss options (e.g. if someone wants to take over maintenance). Hence, don't rush to a conclusion please, I'd really like to keep PolyBoRi around somehow but don't want to be (sole) maintainer. Cheers, Martin On Thursday 11 Jun 2015 20:45:41 William Stein wrote: On Thursday, June 11, 2015, Ralf Stephan gtrw...@gmail.com wrote: So folks, be careful when you fork---you might end up as maintainer. Good point. I think we should either 1. Remove polybori or 2. Have a specific person (or persons) step up to be maintainer. I'm fine with either option. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to sage-devel@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Friday, June 12, 2015, 'Martin Albrecht' via sage-devel sage-devel@googlegroups.com wrote: I started talking to some people from the symbolic computation community to discuss options (e.g. if someone wants to take over maintenance). Hence, don't rush to a conclusion please, I'd really like to keep PolyBoRi around somehow but don't want to be (sole) maintainer. Thanks!! Cheers, Martin On Thursday 11 Jun 2015 20:45:41 William Stein wrote: On Thursday, June 11, 2015, Ralf Stephan gtrw...@gmail.com javascript:; wrote: So folks, be careful when you fork---you might end up as maintainer. Good point. I think we should either 1. Remove polybori or 2. Have a specific person (or persons) step up to be maintainer. I'm fine with either option. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com javascript:; javascript:;. To post to this group, send email to sage-devel@googlegroups.com javascript:; javascript:;. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de javascript:; .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to sage-devel@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- Sent from my massive iPhone 6 plus. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
Hi, so, the Singular team *wants* to keep PolyBoRi alive, but it's currently not clear if and when they *can* devote resources to it. This will be clarified over the next few months it seems. Cheers, Martin On Friday 12 Jun 2015 10:14:53 Martin Albrecht wrote: I started talking to some people from the symbolic computation community to discuss options (e.g. if someone wants to take over maintenance). Hence, don't rush to a conclusion please, I'd really like to keep PolyBoRi around somehow but don't want to be (sole) maintainer. Cheers, Martin On Thursday 11 Jun 2015 20:45:41 William Stein wrote: On Thursday, June 11, 2015, Ralf Stephan gtrw...@gmail.com wrote: So folks, be careful when you fork---you might end up as maintainer. Good point. I think we should either 1. Remove polybori or 2. Have a specific person (or persons) step up to be maintainer. I'm fine with either option. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to sage-devel@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On 2015-06-12 14:34, 'Martin Albrecht' via sage-devel wrote: Hi, so, the Singular team *wants* to keep PolyBoRi alive, but it's currently not clear if and when they *can* devote resources to it. This will be clarified over the next few months it seems. Doesn't OpenDreamKit help with this? -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Thu, Jun 11, 2015 at 2:42 PM, Alexander Dreyer jan.alexander.dre...@gmail.com wrote: From my point of view a fork - or better call it sequel - would be the best. Unfortunately, all original developers like me went to industrial positions, which are completely unrelated to PolyBoRi or any kind of algebraic software. Meanwhile, family and the new jobs don't leave us time to work on pet projects. So, the real active branch is the ohanar github repository. At that repository, I already see great work in autotools support. I would adopt this for sure if I ever get the chance to get back to work on PolyBoRi. For the unlikely case of sudden freetime I would rather contribute to the new project than trying to resurrect the old one. ;-) However, to avoid confusion, you should rename your fork. Use TOSSFKAP or BRiAl or whatever you like to distinuish the projects. Yes, I agree, I just didn't have a good name. Do you have a particular favorite (and we could just use that). Also, I have to note, that in the autotools branch some headers from original Cudd were reintroduced. Which ones exactly? I exported the mercurial repository into git and double checked the files, but didn't notice any new headers. This might be a problem since some were intentionally left out due to unclear licenses. This had been suggested by the debian people some time ago. Best regards and good luck, Alexander -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Fri, Jun 12, 2015 at 5:34 AM, 'Martin Albrecht' via sage-devel sage-devel@googlegroups.com wrote: Hi, so, the Singular team *wants* to keep PolyBoRi alive, but it's currently not clear if and when they *can* devote resources to it. This will be clarified over the next few months it seems. What about this: Now: We work on making polybori an optional package in sage. * At least going by this thread, the number of people who use polybori in Sage is small enough for it to make sense to have polybori as an optional package. * (I looked into this before I did the autotoolization) It shouldn't take too much work to optionalize polybori -- the main effort will be its uses in the crypto code. * Polybori is the sole dependency of Sage that doesn't at least build against python 3 -- getting past this last major hurdle will make it much easier to work on porting the actual sage library to python 3. Future: The Singular team or whoever dedicates the time to maintain a sequel to polybori. * This will be required once we stop supporting python 2 in the very distant future (at least after 2020, which is the EOL for python 2). Cheers, Martin On Friday 12 Jun 2015 10:14:53 Martin Albrecht wrote: I started talking to some people from the symbolic computation community to discuss options (e.g. if someone wants to take over maintenance). Hence, don't rush to a conclusion please, I'd really like to keep PolyBoRi around somehow but don't want to be (sole) maintainer. Cheers, Martin On Thursday 11 Jun 2015 20:45:41 William Stein wrote: On Thursday, June 11, 2015, Ralf Stephan gtrw...@gmail.com wrote: So folks, be careful when you fork---you might end up as maintainer. Good point. I think we should either 1. Remove polybori or 2. Have a specific person (or persons) step up to be maintainer. I'm fine with either option. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to sage-devel@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- .www: https://martinralbrecht.wordpress.com .pgp: 40BC 7F0D 724B 4AB1 CC98 4014 A040 043C 6532 AFB4 .xmpp: martinralbre...@jabber.ccc.de .twitter: https://twitter.com/martinralbrecht .keybase: https://keybase.io/martinralbrecht -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
On Thursday, June 11, 2015 at 12:11:34 PM UTC-7, William wrote: On Thu, Jun 11, 2015 at 11:55 AM, Francesco Biscani blues...@gmail.com javascript: wrote: On 11 June 2015 at 20:13, Travis Scrimshaw tsc...@ucdavis.edu javascript: wrote: Difficult-to-dechiper can be considered a pro by bigger businesses with proprietry software to help prevent reverse-engineering (although from what I've been told, they typically run it through a scrambler before compiling the code for release). Not sure what you mean by that. I have worked in the past for a multinational company (100k employees) on software which costs hundreds of thousands of dollars per license, and never heard of that. I am not an assembly guy but I would think that the binary of a non-trivial software is already scrambled well enough (especially in release mode where the compiler is gonna pull all sorts of tricks for optimisation). I think it's now something the compilers do automatically, in particular in release mode, because, as you said, it does all sorts of crazy optimizations. It was something my (old school) C++ programmer professor told me once. It's officially called The Wolfram Language [1] beating out [2] many other options such as Wolframese, Wolframic, Wolframian, Wolframish or Wolframaic, perhaps Wolfese, Wolfic or Wolfish, Wolfian or Wolfan or Wolfatic, ,the exotic Wolfari or Wolfala? Wolvese or Wolvic? WolframCode or WolframScript—or Wolfcode or Wolfscript—but these sound either too obscure or too lightweight. Then there’s the somewhat inelegantWolframLang, or it shorter forms WolfLang and WolfLan, which sound too much like Wolfgang. Then there are names like WolframX and WolfX, but it’s not clear the “X” adds much. Adding X makes it look cool. Same with a Z. Oh, should we change our name to SageX, SageZ, Zage, Sag3, S4ge 54g3, S4g3, Z4g3, Sag3M4th, or (really FTW and the 1337): 54g3|\/|4+|-| Then, Stephen and Al Gore can fight over who invented what. Wouldn't that be an inconvienent truth.. Best, Travis -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
Hi all, I use it. Not as much as I used to (my research moved on) but it would be rather if it was gone. I also know that some people in my field use it, i.e. the BooleanPolynomialRing. If that was gone, we'd go from okay-ish to hell-ish for computing with an object which quite naturally arises in crypto and related fields. I'm also up for helping out with maintenance: 1. We adopt the route that we took with Pynac (as a fork of Ginac). Our fork might in the future become tightly coupled with Sage, but we maintain it as a separate package outside of Sage. 2. We make a minimal fork, only include the minimal changes necessary to build polybori without scons. If more substantive changes are needed, we include those in the Sage library. Being ignorant of some of the issues around Pynac, (1) would allow us to attract outside contributions more easily. Not sure how realistic that is, though. I'll point some of the usual suspects to this thread, let's see what happens. Cheers, Martin On Wednesday 10 Jun 2015 19:39:11 William Stein wrote: Hi, Can somebody (say at least 3-5 people) who actually *use* polybori on a somewhat regular basis make some supporting remarks?I personally have used polybori for anything, nor do I really know of anybody else who has. If there aren't at least a few people who use it regularly, then we should consider making it an optional package. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
Or at least it is not hard to write modern C++ that is very difficult for others to work on. Isn't it true for most languages? I have seen nested list comprehension one-liners in Python that make my skin crawl. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
(off topic) Re: [sage-devel] The future of polybori
(off topic) On Thu, Jun 11, 2015 at 8:58 AM, Francesco Biscani bluesca...@gmail.com wrote: Or at least it is not hard to write modern C++ that is very difficult for others to work on. Isn't it true for most languages? In my opinion, absolutely unequivocally not.Each programming languages has a huge range of pros and cons. Each programming language (and standard library) is good at expressing certain things and bad at others. Ability to easily write very difficult-to-decipher code is something C/C++ is better at than some other languages such as Python. I'm sure that anybody who has really learned a few very different programming languages well (having written and worked on a few tens of thousands of lines of code in each) would agree. In my mind I do not view Python is the best programming language for everything any more than I view my impact driver as the best tool in my toolshed for everything. (Though impact drivers are pretty awesome.) William I have seen nested list comprehension one-liners in Python that make my skin crawl. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Wednesday, June 10, 2015 at 11:12:53 PM UTC-5, William wrote: Even if you know C++ well, it is a much more difficult language than Python. Or at least it is not hard to write modern C++ that is very difficult for others to work on. To be fair, I recall people complaining that pre-modern C++ was difficult to work on (not just I). :-) john perry -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
Difficult-to-dechiper can be considered a pro by bigger businesses with proprietry software to help prevent reverse-engineering (although from what I've been told, they typically run it through a scrambler before compiling the code for release). However, from my experience, it is the quality of the code, comments, and documentation that determines the readability of the code, not so much the language. That's not to say some languages don't make it really difficult; specifically the non-standard/joke/developed-by-a-guy-with-too-much-ego *coughmathmaticacough* language, but these are relatively rare in practice. In short, I agree with William. Best, Travis On Thursday, June 11, 2015 at 9:51:00 AM UTC-7, William wrote: (off topic) On Thu, Jun 11, 2015 at 8:58 AM, Francesco Biscani blues...@gmail.com javascript: wrote: Or at least it is not hard to write modern C++ that is very difficult for others to work on. Isn't it true for most languages? In my opinion, absolutely unequivocally not.Each programming languages has a huge range of pros and cons. Each programming language (and standard library) is good at expressing certain things and bad at others. Ability to easily write very difficult-to-decipher code is something C/C++ is better at than some other languages such as Python. I'm sure that anybody who has really learned a few very different programming languages well (having written and worked on a few tens of thousands of lines of code in each) would agree. In my mind I do not view Python is the best programming language for everything any more than I view my impact driver as the best tool in my toolshed for everything. (Though impact drivers are pretty awesome.) William I have seen nested list comprehension one-liners in Python that make my skin crawl. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com javascript:. To post to this group, send email to sage-...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
I agree partially about your best programming language statement: there are languages which are useful for very few things - see Fortran - while others have broader applicability. With C++ one can do well and comfortably enough scientific computing, system programming, graphics, and a host of other things. It does not have to be a zero sum game. Regarding the difficulty of deciphering, I guess it is in the eye of the beholder. Try explaining metaclasses, decorators, __new__() overloading or the method resolution order for multiple inheritance in Python to someone who makes a living doing embedded programming in C :) Python certainly has a lower barrier of entry than many other languages, but any sufficiently complicated language will look alien once you get off the beaten path. This is especially true when a language evolves; you mentioned modern C++ in an earlier mail, and it is true that it will look alien to most people who learned '90s style C++. On the other hand, it allows you to do things that no other language can, so I am not sure it is fair to say it is difficult to decipher - it is just an entirely different thing. Anyway, sorry for the rambling :) Francesco. On 11 June 2015 at 18:50, William Stein wst...@gmail.com wrote: (off topic) On Thu, Jun 11, 2015 at 8:58 AM, Francesco Biscani bluesca...@gmail.com wrote: Or at least it is not hard to write modern C++ that is very difficult for others to work on. Isn't it true for most languages? In my opinion, absolutely unequivocally not.Each programming languages has a huge range of pros and cons. Each programming language (and standard library) is good at expressing certain things and bad at others. Ability to easily write very difficult-to-decipher code is something C/C++ is better at than some other languages such as Python. I'm sure that anybody who has really learned a few very different programming languages well (having written and worked on a few tens of thousands of lines of code in each) would agree. In my mind I do not view Python is the best programming language for everything any more than I view my impact driver as the best tool in my toolshed for everything. (Though impact drivers are pretty awesome.) William I have seen nested list comprehension one-liners in Python that make my skin crawl. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
On 11 June 2015 at 20:13, Travis Scrimshaw tsc...@ucdavis.edu wrote: Difficult-to-dechiper can be considered a pro by bigger businesses with proprietry software to help prevent reverse-engineering (although from what I've been told, they typically run it through a scrambler before compiling the code for release). Not sure what you mean by that. I have worked in the past for a multinational company (100k employees) on software which costs hundreds of thousands of dollars per license, and never heard of that. I am not an assembly guy but I would think that the binary of a non-trivial software is already scrambled well enough (especially in release mode where the compiler is gonna pull all sorts of tricks for optimisation). However, from my experience, it is the quality of the code, comments, and documentation that determines the readability of the code, not so much the language. That's not to say some languages don't make it really difficult; specifically the non-standard/joke/developed-by-a-guy-with-too-much-ego *coughmathmaticacough* language, but these are relatively rare in practice. I agree with you. I would not even consider Mathematica (or Wolfram code, or whatever it is called nowadays) a proper language. Cheers, Francesco. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
On 06/11/2015 02:55 PM, Francesco Biscani wrote: Not sure what you mean by that. I have worked in the past for a multinational company (100k employees) on software which costs hundreds of thousands of dollars per license, and never heard of that. I am not an assembly guy but I would think that the binary of a non-trivial software is already scrambled well enough (especially in release mode where the compiler is gonna pull all sorts of tricks for optimisation). It's a much bigger issue for scripting and byte-code languages. See e.g. http://en.wikipedia.org/wiki/List_of_obfuscators_for_.NET -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
On Thu, Jun 11, 2015 at 11:55 AM, Francesco Biscani bluesca...@gmail.com wrote: On 11 June 2015 at 20:13, Travis Scrimshaw tsc...@ucdavis.edu wrote: Difficult-to-dechiper can be considered a pro by bigger businesses with proprietry software to help prevent reverse-engineering (although from what I've been told, they typically run it through a scrambler before compiling the code for release). Not sure what you mean by that. I have worked in the past for a multinational company (100k employees) on software which costs hundreds of thousands of dollars per license, and never heard of that. I am not an assembly guy but I would think that the binary of a non-trivial software is already scrambled well enough (especially in release mode where the compiler is gonna pull all sorts of tricks for optimisation). However, from my experience, it is the quality of the code, comments, and documentation that determines the readability of the code, not so much the language. That's not to say some languages don't make it really difficult; specifically the non-standard/joke/developed-by-a-guy-with-too-much-ego *coughmathmaticacough* language, but these are relatively rare in practice. I agree with you. I would not even consider Mathematica (or Wolfram code, or whatever it is called nowadays) a proper language. It's officially called The Wolfram Language [1] beating out [2] many other options such as Wolframese, Wolframic, Wolframian, Wolframish or Wolframaic, perhaps Wolfese, Wolfic or Wolfish, Wolfian or Wolfan or Wolfatic, ,the exotic Wolfari or Wolfala? Wolvese or Wolvic? WolframCode or WolframScript—or Wolfcode or Wolfscript—but these sound either too obscure or too lightweight. Then there’s the somewhat inelegantWolframLang, or it shorter forms WolfLang and WolfLan, which sound too much like Wolfgang. Then there are names like WolframX and WolfX, but it’s not clear the “X” adds much. Same with WolframQ or WolframL. There’s also WolframPlus (Wolfram+),WolframStar (Wolfram*) or WolframDot. Or Wolfram1 (when’s 2?), WolframCore(remember core memory?) or WolframBase. There are also Greek-letter suffixes, Wolfram|Alpha-style, like Wolfram Omega or Wolfram Lambda (“wolf”, “ram” and “lamb”: too many animals!). Or one could go shorter, like the W Language... [1] http://en.wikipedia.org/wiki/Wolfram_Language [2] http://blog.stephenwolfram.com/2013/02/what-should-we-call-the-language-of-mathematica/ Cheers, Francesco. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
From my point of view a fork - or better call it sequel - would be the best. Unfortunately, all original developers like me went to industrial positions, which are completely unrelated to PolyBoRi or any kind of algebraic software. Meanwhile, family and the new jobs don't leave us time to work on pet projects. So, the real active branch is the ohanar github repository. At that repository, I already see great work in autotools support. I would adopt this for sure if I ever get the chance to get back to work on PolyBoRi. For the unlikely case of sudden freetime I would rather contribute to the new project than trying to resurrect the old one. ;-) However, to avoid confusion, you should rename your fork. Use TOSSFKAP or BRiAl or whatever you like to distinuish the projects. Also, I have to note, that in the autotools branch some headers from original Cudd were reintroduced. This might be a problem since some were intentionally left out due to unclear licenses. This had been suggested by the debian people some time ago. Best regards and good luck, Alexander -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
Bravo, that was pretty good :) On 11 June 2015 at 21:10, William Stein wst...@gmail.com wrote: On Thu, Jun 11, 2015 at 11:55 AM, Francesco Biscani bluesca...@gmail.com wrote: On 11 June 2015 at 20:13, Travis Scrimshaw tsc...@ucdavis.edu wrote: Difficult-to-dechiper can be considered a pro by bigger businesses with proprietry software to help prevent reverse-engineering (although from what I've been told, they typically run it through a scrambler before compiling the code for release). Not sure what you mean by that. I have worked in the past for a multinational company (100k employees) on software which costs hundreds of thousands of dollars per license, and never heard of that. I am not an assembly guy but I would think that the binary of a non-trivial software is already scrambled well enough (especially in release mode where the compiler is gonna pull all sorts of tricks for optimisation). However, from my experience, it is the quality of the code, comments, and documentation that determines the readability of the code, not so much the language. That's not to say some languages don't make it really difficult; specifically the non-standard/joke/developed-by-a-guy-with-too-much-ego *coughmathmaticacough* language, but these are relatively rare in practice. I agree with you. I would not even consider Mathematica (or Wolfram code, or whatever it is called nowadays) a proper language. It's officially called The Wolfram Language [1] beating out [2] many other options such as Wolframese, Wolframic, Wolframian, Wolframish or Wolframaic, perhaps Wolfese, Wolfic or Wolfish, Wolfian or Wolfan or Wolfatic, ,the exotic Wolfari or Wolfala? Wolvese or Wolvic? WolframCode or WolframScript—or Wolfcode or Wolfscript—but these sound either too obscure or too lightweight. Then there’s the somewhat inelegantWolframLang, or it shorter forms WolfLang and WolfLan, which sound too much like Wolfgang. Then there are names like WolframX and WolfX, but it’s not clear the “X” adds much. Same with WolframQ or WolframL. There’s also WolframPlus (Wolfram+),WolframStar (Wolfram*) or WolframDot. Or Wolfram1 (when’s 2?), WolframCore(remember core memory?) or WolframBase. There are also Greek-letter suffixes, Wolfram|Alpha-style, like Wolfram Omega or Wolfram Lambda (“wolf”, “ram” and “lamb”: too many animals!). Or one could go shorter, like the W Language... [1] http://en.wikipedia.org/wiki/Wolfram_Language [2] http://blog.stephenwolfram.com/2013/02/what-should-we-call-the-language-of-mathematica/ Cheers, Francesco. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
On 11 Jun 2015 20:10, William Stein wst...@gmail.com wrote: It's officially called The Wolfram Language [1] beating out [2] many It would never surprise me is it was renamed to the Stephen Wolfram Language. Dave. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: (off topic) Re: [sage-devel] The future of polybori
Wow, is that some top-shelf navel lint. Perhaps we should call the language WolframWolframWolfram, or WWW for short. Then, Stephen and Al Gore can fight over who invented what. On Thu, Jun 11, 2015 at 1:28 PM, Dr. David Kirkby (Kirkby Microwave Ltd) drkir...@kirkbymicrowave.co.uk wrote: On 11 Jun 2015 20:10, William Stein wst...@gmail.com wrote: It's officially called The Wolfram Language [1] beating out [2] many It would never surprise me is it was renamed to the Stephen Wolfram Language. Dave. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
PS: Perhaps I should admit that PolyBoRi is dead. It's a hard year: Spock, Winnetou, Dracula - and now PolyBoRi - died. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
So folks, be careful when you fork---you might end up as maintainer. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Thursday, June 11, 2015, Ralf Stephan gtrw...@gmail.com wrote: So folks, be careful when you fork---you might end up as maintainer. Good point. I think we should either 1. Remove polybori or 2. Have a specific person (or persons) step up to be maintainer. I'm fine with either option. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to sage-devel@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- Sent from my massive iPhone 6 plus. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
I have absolutely nothing invested in this, but I am curious about whether bringing (as much as possible of) polybori into the Sage library or extcode-successor or something would help people revivify the project? I don't know how many people there are out there who would be potentially interested, whether or not it is a separate package. The Pynac difficulties are indeed worth mentioning - and note that Ginac does have a live, if not extremely active, upstream. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Wed, Jun 10, 2015 at 6:40 PM, François Bissey francois.bis...@canterbury.ac.nz wrote: Hi all, over at http://trac.sagemath.org/ticket/18437 we have some heated debate about what to do about polybori. Let me summarize the situation. * at this moment polybori is dead upstream * polybori is the last package using scons * is one of the last packages, if not the last, not ready for python 3.x * polybori is actually python wrapper over another package called CUDD which is included in polybori and scons-ified. This is a off, polybori is its own c++ library -- cudd is merely a dependency (and polybori doesn't even use much of it). It is true that polybori ships its own version of cudd (almost certainly because cudd's build system is atrocious). There is a strong debate about what to do about the situation. * fork upstream and keep it as a separate package but no one really wants to be the maintainer. I think Jeroen and I agree that we need to fork polybori -- the debate is more in the details. * autotool CUDD (Andrew Ohanar prodded upstream to see if they would be willing to adopt any autotooling we provide without answer so far) Upstream cudd has gotten back to me now, they are apparently planning a new release sometime this summer which uses autotools for its build system. and move the python binding in sage itself making its maintenance a shared task amongst sage dev. CUDD would become a standard package to replace polybori. Note it is currently shipped inside polybori so it is not something new. * Hybrid in between those two. More details on the ticket. I would very much would go with autotooling CUDD and move the wrapper. The fork of polybori would also move to autotool as its build system at this stage. Because of strong opinions on the ticket and the burden of the various options, Jeroen pointed out that we should get some kind of consensus here before moving forward. So we would very much want to hear from other devs on what to do with polybori. Francois -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. The main debate is around what we should do with the python bindings for polybori. From the ticket: As I see it there are three routes we could go with polybori: 1. We adopt the route that we took with Pynac (as a fork of Ginac). Our fork might in the future become tightly coupled with Sage, but we maintain it as a separate package outside of Sage. 2. We make a minimal fork, only include the minimal changes necessary to build polybori without scons. If more substantive changes are needed, we include those in the Sage library. 3. A hybrid approach: maintain a minimal fork, and a maintain a set of patches for more substantive changes. I would personally vote for 1 or 2, and very much against 3. Some pros and cons of the various proposals I mentioned: Pros of 1: - We already have pursed this model with Pynac. - It allows us to modify the c++ code in polybori if we need to. Cons of 1: - Maintenance of Pynac has lapsed as people have gotten busy. - (From Jeroen) It isn't held to the same standard as our normal review process for Sage. Pros of 2: - It distributes the burden of maintenance across the whole Sage community (in particular, it is easier for a Sage contributor to work on) - Polybori's bindings does things a bit differently if it is in a Sage environment (we included polybori before it had python bindings) Con of 3: - Maintaining patches is more work than maintaining a forked version of the code (especially when upstream is dead). If anybody has any better suggestions or thoughts on the matter, I would be very open to hear them. For what its worth, the hard part of making the autotools based build system is done (at least for the components of polybori that Sage uses). At this point it is mainly a matter of how we want to deal with the python bindings, which will need to be updated to work with python 3. -- Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
I thought I was going to misrepresent stuff, but may be not to that extent. If we fork polybori I do not see the point of patching it for sage on top of the fork. (3) is very much out as far as I am concerned. François On 11/06/2015, at 14:08, R. Andrew Ohana andrew.oh...@gmail.com wrote: On Wed, Jun 10, 2015 at 6:40 PM, François Bissey francois.bis...@canterbury.ac.nz wrote: Hi all, over at http://trac.sagemath.org/ticket/18437 we have some heated debate about what to do about polybori. Let me summarize the situation. * at this moment polybori is dead upstream * polybori is the last package using scons * is one of the last packages, if not the last, not ready for python 3.x * polybori is actually python wrapper over another package called CUDD which is included in polybori and scons-ified. This is a off, polybori is its own c++ library -- cudd is merely a dependency (and polybori doesn't even use much of it). It is true that polybori ships its own version of cudd (almost certainly because cudd's build system is atrocious). There is a strong debate about what to do about the situation. * fork upstream and keep it as a separate package but no one really wants to be the maintainer. I think Jeroen and I agree that we need to fork polybori -- the debate is more in the details. * autotool CUDD (Andrew Ohanar prodded upstream to see if they would be willing to adopt any autotooling we provide without answer so far) Upstream cudd has gotten back to me now, they are apparently planning a new release sometime this summer which uses autotools for its build system. and move the python binding in sage itself making its maintenance a shared task amongst sage dev. CUDD would become a standard package to replace polybori. Note it is currently shipped inside polybori so it is not something new. * Hybrid in between those two. More details on the ticket. I would very much would go with autotooling CUDD and move the wrapper. The fork of polybori would also move to autotool as its build system at this stage. Because of strong opinions on the ticket and the burden of the various options, Jeroen pointed out that we should get some kind of consensus here before moving forward. So we would very much want to hear from other devs on what to do with polybori. Francois -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. The main debate is around what we should do with the python bindings for polybori. From the ticket: As I see it there are three routes we could go with polybori: • We adopt the route that we took with Pynac (as a fork of Ginac). Our fork might in the future become tightly coupled with Sage, but we maintain it as a separate package outside of Sage. • We make a minimal fork, only include the minimal changes necessary to build polybori without scons. If more substantive changes are needed, we include those in the Sage library. • A hybrid approach: maintain a minimal fork, and a maintain a set of patches for more substantive changes. I would personally vote for 1 or 2, and very much against 3. Some pros and cons of the various proposals I mentioned: Pros of 1: • We already have pursed this model with Pynac. • It allows us to modify the c++ code in polybori if we need to. Cons of 1: • Maintenance of Pynac has lapsed as people have gotten busy. • (From Jeroen) It isn't held to the same standard as our normal review process for Sage. Pros of 2: • It distributes the burden of maintenance across the whole Sage community (in particular, it is easier for a Sage contributor to work on) • Polybori's bindings does things a bit differently if it is in a Sage environment (we included polybori before it had python bindings) Con of 3: • Maintaining patches is more work than maintaining a forked version of the code (especially when upstream is dead). If anybody has any better suggestions or thoughts on the matter, I would be very open to hear them. For what its worth, the hard part of making the autotools based build system is done (at least for the components of polybori that Sage uses). At this point it is mainly a matter of how we want to deal with the python bindings, which will need to be updated to work with python 3. -- Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: [sage-devel] The future of polybori
On 06/11/15 14:39, William Stein wrote: I could easily imagine Andrew and Francois and Jereon are all dutifully imagining that I know all kinds of Polybori enthusiasts and there are good reasons that Polybori really must be really well supported in Sage. However, it turns out this at least isn't clear to me. I wouldn't make that assumption. One of potential problem is that polybori has small tentacles in other part of sage (crypto) besides rings/polynomials and surgery to remove it or make it optional won't be painless. We may be relying on polybori much more than it appears on the surface. Francois -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
On Wednesday, June 10, 2015, Ralf Stephan gtrw...@gmail.com wrote: There is not much difference between 1 and 2 because, while there is no review mechanism for Pynac admin commits on github, it's on trac instead. And the real problem is always the language barrier: adding C++ to an already huge skillset is too much for many authors and most reviewers, regardless of if a package is patched or a patch to a package is patched. Even if you know C++ well, it is a much more difficult language than Python. Or at least it is not hard to write modern C++ that is very difficult for others to work on. Regards, -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to sage-devel@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- Sent from my massive iPhone 6 plus. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
Hi, Can somebody (say at least 3-5 people) who actually *use* polybori on a somewhat regular basis make some supporting remarks?I personally have used polybori for anything, nor do I really know of anybody else who has. If there aren't at least a few people who use it regularly, then we should consider making it an optional package. I looked for a minute or two at https://groups.google.com/forum/#!searchin/sage-support/polybori but what I saw was about troubles arising from trying to build Polybori, not from people actually using it. I could easily imagine Andrew and Francois and Jereon are all dutifully imagining that I know all kinds of Polybori enthusiasts and there are good reasons that Polybori really must be really well supported in Sage. However, it turns out this at least isn't clear to me. -- William On Wed, Jun 10, 2015 at 7:16 PM, Francois Bissey francois.bis...@canterbury.ac.nz wrote: I thought I was going to misrepresent stuff, but may be not to that extent. If we fork polybori I do not see the point of patching it for sage on top of the fork. (3) is very much out as far as I am concerned. François On 11/06/2015, at 14:08, R. Andrew Ohana andrew.oh...@gmail.com wrote: On Wed, Jun 10, 2015 at 6:40 PM, François Bissey francois.bis...@canterbury.ac.nz wrote: Hi all, over at http://trac.sagemath.org/ticket/18437 we have some heated debate about what to do about polybori. Let me summarize the situation. * at this moment polybori is dead upstream * polybori is the last package using scons * is one of the last packages, if not the last, not ready for python 3.x * polybori is actually python wrapper over another package called CUDD which is included in polybori and scons-ified. This is a off, polybori is its own c++ library -- cudd is merely a dependency (and polybori doesn't even use much of it). It is true that polybori ships its own version of cudd (almost certainly because cudd's build system is atrocious). There is a strong debate about what to do about the situation. * fork upstream and keep it as a separate package but no one really wants to be the maintainer. I think Jeroen and I agree that we need to fork polybori -- the debate is more in the details. * autotool CUDD (Andrew Ohanar prodded upstream to see if they would be willing to adopt any autotooling we provide without answer so far) Upstream cudd has gotten back to me now, they are apparently planning a new release sometime this summer which uses autotools for its build system. and move the python binding in sage itself making its maintenance a shared task amongst sage dev. CUDD would become a standard package to replace polybori. Note it is currently shipped inside polybori so it is not something new. * Hybrid in between those two. More details on the ticket. I would very much would go with autotooling CUDD and move the wrapper. The fork of polybori would also move to autotool as its build system at this stage. Because of strong opinions on the ticket and the burden of the various options, Jeroen pointed out that we should get some kind of consensus here before moving forward. So we would very much want to hear from other devs on what to do with polybori. Francois -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. The main debate is around what we should do with the python bindings for polybori. From the ticket: As I see it there are three routes we could go with polybori: • We adopt the route that we took with Pynac (as a fork of Ginac). Our fork might in the future become tightly coupled with Sage, but we maintain it as a separate package outside of Sage. • We make a minimal fork, only include the minimal changes necessary to build polybori without scons. If more substantive changes are needed, we include those in the Sage library. • A hybrid approach: maintain a minimal fork, and a maintain a set of patches for more substantive changes. I would personally vote for 1 or 2, and very much against 3. Some pros and cons of the various proposals I mentioned: Pros of 1: • We already have pursed this model with Pynac. • It allows us to modify the c++ code in polybori if we need to. Cons of 1: • Maintenance of Pynac has lapsed as people have gotten busy. • (From Jeroen) It isn't held to the same standard as our normal review process for Sage. Pros of 2: • It distributes the burden of maintenance across the whole Sage community (in particular, it is easier for a Sage contributor to work on) •
Re: [sage-devel] The future of polybori
On Wednesday, June 10, 2015, François Bissey francois.bis...@canterbury.ac.nz wrote: On 06/11/15 14:39, William Stein wrote: I could easily imagine Andrew and Francois and Jereon are all dutifully imagining that I know all kinds of Polybori enthusiasts and there are good reasons that Polybori really must be really well supported in Sage. However, it turns out this at least isn't clear to me. I wouldn't make that assumption. One of potential problem is that polybori has small tentacles in other part of sage (crypto) besides rings/polynomials and surgery to remove it or make it optional won't be painless. Good question. That functionality would just become optional though the Cython build dependency issue could make it hard. We may be relying on polybori much more than it appears on the surface. Francois -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- Sent from my massive iPhone 6 plus. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] The future of polybori
There is not much difference between 1 and 2 because, while there is no review mechanism for Pynac admin commits on github, it's on trac instead. And the real problem is always the language barrier: adding C++ to an already huge skillset is too much for many authors and most reviewers, regardless of if a package is patched or a patch to a package is patched. Regards, -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
