2009/6/21 gsw <georgswe...@googlemail.com>: > > > > On 21 Jun., 08:28, Simon King <simon.k...@uni-jena.de> wrote: >> Dear all, >> >> athttp://groups.google.com/group/sage-support/browse_thread/thread/5343... >> I was asking about the apparently changed behaviour of "sage -t". >> Georg suggested to move the discussion to sage-devel, so, here it >> is... >> >> On 20 Jun., 22:10, gsw <georgswe...@googlemail.com> wrote: >> >> > On 20 Jun., 08:15, Simon King <simon.k...@uni-jena.de> wrote: >> > > Apparently the difference lies in Sage and not in my tests. I just >> > > tried again the exact setting in which testing my extension modules >> > > used to work -- now it fails, since "sage -t mtx.pyx" tries to compile >> > > mtx.pyx for whatever reason. >> > ... >> > If I understand it correctly, the doctesting mechanism was changed, to >> > be part of (or to make use of) the "load/attach" mechanism of Sage --- >> > so if you can successfully "load" foobar.pyx into Sage, you also >> > should be able to doctest it, with current Sage versions. But for most >> > stuff which is greater than one file, the current behaviour is worse >> > than it was before and is a regression IMHO. >> >> I agree. Source code is one thing, an importable module is a >> completely different thing. >> >> Moreover: *Why* would one like to use load/attach for doc testing? I >> mean, imaging a big chunk of code (in my case some 10,000 lines of >> code); why should one compile it just for doing doc tests? In >> particular, why *re-*compile it if the compilation of the code has >> been done before? >> >> > I could make doctesting my code (extension modules) work again in two >> > hours or so mainly by inserting some of these infamous "#clib ..." >> > "#cinclude ..." poor-man's pragmas I heartily dislike. >> >> This does not look like a convenient solution. >> >> > > Couldn't "sage -t" just take any text file, search for "sage:" prompts >> > > etc, and verify the output? >> >> ... as it used to do, IIRC ! >> >> > I didn't check it, but if you move all your doctests out of a *.pyx >> > file into another file --- say a *.py file with the necessary >> > "import"s --- then doctesting this new file should work fine. >> >> Sure, but it's clumsy. >> >> >> >> > > Another idea. >> >> > > Let "knight" be a (python) package or module. Is there a function >> > > (say, recursive_doc_test) in Sage that does the doc tests for "knight" >> > > and, recursively, for its contents (functions; classes; methods of >> > > these classes; other modules, if knight is a package; ...) and returns >> > > the results of the test as a string? I mean >> > > sage: import knight >> > > sage: recursive_doc_test(knight) >> > > 'The following items had faiilures: >> > > In knight.Ni.Shrubbery, l. 12: >> > > expected: >> > > "herring" >> > > got: >> > > nothing >> > > ...' >> >> > > The line number would refer to the 12th line in the doc string of the >> > > class knight.Ni.Shrubbery, say. >> >> I did something like that in sort of a quick hack. Also rather >> clumsy: >> - Recursively determine everything that is in some package/module/ >> class/type and retrieve the respective doc strings, so that in the end >> you have a dictionary of doc strings indexed by the fully qualified >> names of the things (classes, instances, functions, methods,...) they >> belong to. >> - For each single doc string, create a temporary file F.py. This file >> contains the doc string and no code, so that it can certainly be >> attached/loaded, and thus doc testing works for F.py. > > The "origonal" doc test module Sage builds upon already does exactly > that, IIRC. Remember, if you get doctest failures "...in > example_blah..." then this means that the doctest framework had had > built and tested one "example" file for each doc string. Also note > that the sequence this is done is *not* the sequence the docstrings > occur in the source file, but rather the examples are gone through _1, > _10, _11, .... _19, _2, _20, _21, _3, _4, _5, .. (if there are less > than 30) which already caused funny-to-debug failures. William has > introduced an option IIRC with which you can make this sequence random > (pseudo-random with a seed, so one might reproduce these sequences), > but this is not the main point here. > > The main point is that the "low-level" doc test framework already does > exactly what you did with your "sort of quick hack approach", so one > "only" needs to re-enable this behaviour in such a way that it works > again for 10000-lines external modules as before, but also still works > for these new examples which have caused the changes. > > In a ten-minute search I only found the following thread : > http://groups.google.com/group/sage-devel/browse_thread/thread/8da41d49ffe6c6d6# > > where e.g. Jason Grout posted: "+1 on making sage -t my_file.py work > with minimal hassle. " but I didn't get closer to who actually changed > the doctesting code and when. > I haven't done a search on trac yet. >
I did at the Sage Days 12 -- bug fix. I did this to fix several reported bugs, which making that change did. I guess one person's bug is another person's feature. Anyway, you guys (or whoever) should just make trac tickets and fix stuff. William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
