Hi!
On 2014-12-26, Nathann Cohen nathann.co...@gmail.com wrote:
Don't forget the decref/incref stuff ! That's for Python's garbage
collector. Otherwise it will not know that the object is being used
and you will be in trouble !
Another hint: If P is a pointer to PyObject, then
objectP
does
Hello !
Another hint: If P is a pointer to PyObject, then
objectP
does already increase the reference count. So, no need to call Py(X)INCREF
in that case.
Oh, good to know. But then, would print (list my_list_pointer)[0]
do a incref followed by a decref ?
Thanks,
Nathann
--
You
Hi Daniel,
On 2014-12-26, Daniel Krenn kr...@aon.at wrote:
I'm writing code for a new ring and my element is derived from
RingElement and the parent has category Rings.
Where can I find the code used by __eq__ ? (I searched now for some
while, but wasn't able to find it). In particular I'm
Hi Dima,
On 2014-12-26, Dima Pasechnik dimp...@gmail.com wrote:
IMHO dev scripts should be retired.
Does anyone use them?
I found them quite practical, and you may recall from the discussions in
Paris that I'd like them to be extended so that they are also able to
send bug reports to the bug
I found them quite practical, and you may recall from the discussions in
Paris that I'd like them to be extended so that they are also able to
send bug reports to the bug trackers of Singular/Gap/..., so that there is
no need to google how to report bugs in Singular.
Nonetheless, I stopped
See http://trac.sagemath.org/ticket/17477
I made a little documentation for internals of the poset class. And
then noticed that __init__ already contains it...
So where should be documentation for things like be? Visible at html page
or not, visible to user by something like P.__init__? or
+1 for making it appear at the end of the module's doc. That will be more
visible than in the __init__ function or the main class itself, which may
appear at random places in the html page.
Nathann
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
Nathann, that's about git in developer docs, so that's not 100% off the thread
:-)
One thing that is confusing in the Git the hard way is that the
example of git fetch in
http://sagemath.org/doc/developer/manual_git.html#checking-out-tickets
does not show a line like
* [new branch]
Yo !
Nathann, that's about git in developer docs, so that's not 100% off the
thread :-)
Well, as long as we can close the question related to the removal of
the sage-dev scripts, I personally don't care what this thread
becomes. But I need to know what to do with that ! :-P
One thing that
On 2014-12-27, Nathann Cohen nathann.co...@gmail.com wrote:
Yo !
Nathann, that's about git in developer docs, so that's not 100% off the
thread :-)
Well, as long as we can close the question related to the removal of
the sage-dev scripts, I personally don't care what this thread
becomes.
Once again: whenever I do git fetch from trac I get a local branch
created on the spot:
Can you give us the command that you type that produces this result ?
Nathann
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group
On 2014-12-27, Nathann Cohen nathann.co...@gmail.com wrote:
Once again: whenever I do git fetch from trac I get a local branch
created on the spot:
Can you give us the command that you type that produces this result ?
I did give it here:
On 2014-12-27, Dima Pasechnik dimp...@gmail.com wrote:
On 2014-12-27, Nathann Cohen nathann.co...@gmail.com wrote:
Once again: whenever I do git fetch from trac I get a local branch
created on the spot:
Can you give us the command that you type that produces this result ?
I did give it
Yo !
I did give it here:
https://groups.google.com/d/msg/sage-devel/JtVWAdvw-3A/603M_PziLfUJ
(if it matters, my git version is 1.9.1)
Oh !!! That's because your git instal contains a
complete copy of the trac's git server. You've got ALL branches on
your computer. So when you
I'm in favor of removing the dev scripts eventually, but not right now.
There is still some useful functionality for importing old patches, and
maybe somebody uses them. The documentation should already be clear enough
that this is not the currently recommended way to use git. I'm fine with
On 2014-12-27, Nathann Cohen nathann.co...@gmail.com wrote:
Yo !
I did give it here:
https://groups.google.com/d/msg/sage-devel/JtVWAdvw-3A/603M_PziLfUJ
(if it matters, my git version is 1.9.1)
Oh !!! That's because your git instal contains a
complete copy of the trac's
I don't know how one can automatically maintain a mirror of git trac,
without running a special script, and I believe I don't do this.
I believe that it is what happens in your case, because that's the
default. If you want to check, you can git clone Sage again and
fetch a branch from there.
On 2014-12-27, Dima Pasechnik dimp...@gmail.com wrote:
On 2014-12-27, Nathann Cohen nathann.co...@gmail.com wrote:
Yo !
I did give it here:
https://groups.google.com/d/msg/sage-devel/JtVWAdvw-3A/603M_PziLfUJ
(if it matters, my git version is 1.9.1)
Oh !!! That's because
On 2014-12-27, Nathann Cohen nathann.co...@gmail.com wrote:
I don't know how one can automatically maintain a mirror of git trac,
without running a special script, and I believe I don't do this.
I believe that it is what happens in your case, because that's the
default.
Are you saying that
Are you saying that the default is to constantly pull the data from the
remote, in the background? Really?
Type git branch. If you see one thousand things you never fetched
from trac, that's a confirmation.
Could you point to documentation confirming this?
I do not think that it is written
On 2014-12-27, Nathann Cohen nathann.co...@gmail.com wrote:
Are you saying that the default is to constantly pull the data from the
remote, in the background? Really?
Type git branch. If you see one thousand things you never fetched
from trac, that's a confirmation.
Could you point to
Further, 'Git the hard way' should be consistent, but it
does not tell you about '--single-branch'.
Dima: If you want it to change, do something.
1) Write doc tickets
2) help me review mine.
well, before improving at this point, we need to dig up the truth :-)
I gave you two ways out:
1)
On Saturday, December 27, 2014 10:41:22 AM UTC+1, Simon King wrote:
[...] But I am not sure
if (listmy_list_pointer)[0] will work, it could be that the cython
compiler complains about accessing an item from a temporary variable.
There is no temporary involved, listmy_list_pointer is just
On Friday, December 26, 2014 9:07:06 PM UTC+1, Dima Pasechnik wrote:
On 2014-12-26, Volker Braun vbrau...@gmail.com javascript: wrote:
--=_Part_5531_1685050387.1419616059330
Content-Type: multipart/alternative;
boundary==_Part_5532_1775001320.1419616059330
I reglarly use the dev scripts. So i would really appreciate if they
remain.
But of course, if they are removed i will adapt to plain git or git trac.
But my personal preference is to keep them.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
I reglarly use the dev scripts. So i would really appreciate if they remain.
Oh. Well, the developer's manual advises you to NOT use them :-P
But of course, if they are removed i will adapt to plain git or git trac.
But my personal preference is to keep them.
Could you why you use them
On Saturday, December 27, 2014 1:22:29 PM UTC+1, Nathann Cohen wrote:
Type git branch. If you see one thousand things you never fetched
from trac, that's a confirmation.
The output of git branch will always only contain branches that you
created locally.
There is a slight difference
The output of git branch will always only contain branches that you
created locally.
Okay. Then Dima: instead of git branch try git branch -a.
It gives only two lines on my version, but my guess is that it will
take several screens for you.
Only because of the --single-branch flag.
Nathann
* Nathann Cohen nathann.co...@gmail.com [2014-12-26 19:37:55 +0530]:
1) should we keep the Sage dev scripts in Sage ?
I regularly use the dev scripts so I would prefer to keep them. I could
of course adapt to using git trac instead if they disappeared so this is
really only a preference.
julian
I regularly use the dev scripts so I would prefer to keep them. I could
of course adapt to using git trac instead if they disappeared so this is
really only a preference.
Okay. Do you have any objection to the removal of the documentation ?
We already advise people to not use them, and it
-a, --all
List both remote-tracking branches and local branches.
I of course agree that you can set git to not look at remote branches, but
as long as you don't explicitly ask for the list of remote branches they
are not shown in the output of git branch. And, regardless of
Could you why you use them instead of 'git trac' ? Is there something
that they do and that git trac can't do ?
As i said, it is just what i am used to. It is what i did learn to use in
the beginning, and up to now i didn't had any reason to stop using them. I
don't really know what
Sorry, it seems my message was interrupted.
If you want to remove the documentation about them from the developper
guide, it is ok with me.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails
If you want to remove the documentation about them from the developper
guide, it is ok with me.
Okay okay, fine. I think that I will do that then, unless somebody objects.
This way those who still use them can continue, and we hope that in
something like 6 months~1 year you will have switched
The branch is there, ready for a review:
http://trac.sagemath.org/ticket/17555
Nathann
--
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
Hey,
I'm writing code for a new ring and my element is derived from
RingElement and the parent has category Rings.
Where can I find the code used by __eq__ ? (I searched now for some
while, but wasn't able to find it). In particular I'm interested in the
part which uses the
Hey,
-1 as it is internal workings and would add useless information to the
average user. If you need to know those details, then you should be looking
at the file/code. IMO the public documentation should be about the
mathematical structure and how to use the class in Sage.
Best,
Travis
Yo !
-1 as it is internal workings and would add useless information to the
average user. If you need to know those details, then you should be looking
at the file/code. IMO the public documentation should be about the
mathematical structure and how to use the class in Sage.
Well, our
Well, our users can become developpers too. Plus we can show this in a
non-intrusive way. It is a bit hard to make all the doc clean when
it is just code.
That is few and far between, and putting it at the module or class levels
are quite intrusive.
Look at this: the doc is meant to
Hi Travis,
On 2014-12-27, Travis Scrimshaw tsc...@ucdavis.edu wrote:
See src/structure/element.pyx. You need to look for __cmp__ and
__richcmp__; the use of __eq__, __neq__, __le__ etc is deprecated in
Sage, if I understand correctly.
No, the opposite. the rich comparisons __eq__,
On Saturday, December 27, 2014 3:13:37 PM UTC-8, Simon King wrote:
That's exactly what I meant: The use of __eq__, __lt__, etc. is
deprecated in Sage, in favour of using __richcmp__ (of course __cmp__ is
a different thing).
There is no deprecating of __eq__ or __richcmp__. They appear in
That is few and far between, and putting it at the module or class levels
are quite intrusive.
In a section named technical details, you would find this intrusive ?
Having the background technical information
(especially that about design patterns used or easily deciphered from the
code)
If you're developing, you're...not...looking at the code? That's how I'm
interpreting your comments. I don't see how it is possible to develop
without looking at the code.
To reiterate, public documentation should be there for the user, internal
documentation (i.e. private methods) and
If you're developing, you're...not...looking at the code? That's how I'm
interpreting your comments. I don't see how it is possible to develop
without looking at the code.
To reiterate, public documentation should be there for the user, internal
documentation (i.e. private methods) and
There is still one possibility: Having a file for *only* internal
documentation or technical details. Then
http://www.sagemath.org/doc/reference/combinat/posets.html would contain
something like Implementation details as a list item.
Also some user might benefit from technical details. Some
45 matches
Mail list logo
