#4238: [with patch, positive review] option to create local .so file for .spyx
modules
----------------------------+-----------------------------------------------
Reporter: robertwb | Owner: was
Type: defect | Status: new
Priority: major | Milestone: sage-3.1.3
Component: user interface | Resolution:
Keywords: |
----------------------------+-----------------------------------------------
Changes (by GeorgSWeber):
* summary: [with patch, needs review] option to create local .so file
for .spyx modules => [with patch, positive
review] option to create local .so file for
.spyx modules
Comment:
First and foremost: I do give this patch a positive review, get this code
in!
But the only reason is that it is the first new code in the
spyx/load/attach for quite some time. This area is in a sorrow state,
several tickets are open addressing different symptoms of the same cause:
It's all still nothing but a quick and dirty hack.
We will have problems with this new patch, consider the following
scenario:
Two files foo.spyx and bar.sage, where bar.sage imports sth from foo.spyx.
1. User creates local foo.so
2. User is happy, until he needs in bar.sage a change in sth
3. User attaches foo.spyx and develops the needed change
4. User exits Sage
5. User reenters Sage
6. User loads bar.sage and wonders why the hell sth displays the old
behaviour ...
Of course "User" forgot" to re-create the local foo.so, so the old one was
taken.
But it is counter-intuitive that anyone should have to remember to do that
manually, since the Sage had all information it needed to update the local
foo.so itself!
In spite of this patch being so error-prone, without doing small steps in
at least some patches, it seems that nothing would move here. So again,
positive review.
At last for the question of a "new global function":
Well, the Right Thing (TM) to do here would be to introduce proper
dependency handling in the load/attach code, probably best done with the
help of a tool like Scons. Then, using attach/load just like one does
right now, "behind the scenes" there would happen a bit more magic. To the
end that whenever the sourcecode of some .spyx and anything else didn't
change, a respective .so would already exist and be used (which is quick,
as desired); and whenever the sourcecode --- or some other dependency of
the .spyx, like e.g. a C library! --- did change, everything needed would
happen automatically.
So, in an ideal world, the question about "global function or not" should
be utterly superfluous. This problem "always long starting times due to
recompilation done every time" just wouldn't exist!
But we live in a real world, with limited resources ...
So let's add just another hack that at least relieves some of the pain for
some of us.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/4238#comment:4>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
