Filters:
Languages
Projects
Toughness
Just bugs labeled...
Expand all
Collapse all
-
The ODE docstrings (i.e., the stuff at http://docs.sympy.org/dev/modules/solvers/ode.html) has a lot of math in it, but the math is all written in text. We should write it using LaTeX, and wrap it with backticks (like `x \neq 0`). That way, it will render nicely in Sphinx. For people who read the text version, I think the pretty printing in the doctests should be enough.
-
· link
IPython13.2: Launching a cluster configured for SGE use caused a type error stating that you cannot apply a regular expression to a byte sequence (that apparently was the result of some shell level command). Unfortunately, the exact message got lost. Workaround: Change ib/python3.3/site-packages/ipython-0.13.2-py3.3.egg/IPython/parallel/apps/launcher.py a follows: def parse_job_id(self, output): """Take the output of the submit command and return the job id.""" output=output.decode('UTF8') ... I guess that python3.3 issues like these lurk in many places where the result of a shell command (usually a byte string) is combined somehow with a python3.3 (unicode) string. Georg
-
> @@ -542,7 +542,11 @@ def test_1st_homogeneous_coeff_ode_check3(): > # (False, x*(log(exp(-LambertW(C1*x))) + LambertW(C1*x))*exp(-LambertW(C1*x) + 1)) > eq3 = f(x) + (x*log(f(x)/x) - 2*x)*diff(f(x),x) > sol3 = Eq(f(x), x*exp(1 - LambertW(C1*x))) > - assert checkodesol(eq3, sol3, solve_for_func=False)[0] > + assert checkodesol(eq3, sol3, solve_for_func=True)[0] > + # and without an assumption about x and f(x), the implicit form doesn't resolve, either: > + # (False, (log(f(x)/x) + log(x/f(x)))*f(x)) So checkodesol() needs to be more aggressive, since dsolve() obtains these logarithms by calling logcombine(force=True). An expand with force=True should be used on expressions being tested or else (as shown above) terms which should go to zero, don't: >>> log(f(x)/x) + log(x/f(x)) log(f(x)/x) + log(x/f(x)) >>> _.expand(force=True) 0
-
· link
The lack of a word wrap implementation other than greedyWrap makes it difficult to convey useful information in usage.Options.longdesc. Specifically it eats single newlines and indentation whitespace. I think a more ideal alternative implementation would: 1. only wraps lines that are longer than the specified width 1. only eat new lines in the absence of beginning whitespace 1. support two spaces at the end of sentences
-
· link
The empty path '' is considered as an acceptable path in os.path.join, and works as a neutral prefix: print os.path.join('','aaa') ===> aaa which seems rather natural. But it raises an exception when used as a parameter to os.listdir. Logically, it should then list the current directory. (the alternative would be to raise an exception when os.path.join gets an empty argument). The inconsistency became clear to me when I had to write the following function : def listdirs(path,flist): # Appends to "flist" all paths to files that # start with "path". Argument "path" can be empty string ''. if path=='' : localist=os.listdir('.') else : localist=os.listdir(path) for f in localist : p=os.path.join(path,f) flist.append(p) if os.path.isdir(p) : listdirs(p,flist) return flist The conditionnal is needed only to avoid the exception, while the code is unique afterwards. This is related to Issue818059, but I did not see how that issue was resolved. Furthermore, the case of the empty path as argument to os.listdir should be documented in http://docs.python.org/2/library/os.html
-
multiprocessing.cpu_count() implementation should be made available in the os module, where it belongs.
-
When (at least sometimes) exceptions occur during shutdown, warnings like the following appear: Exception TypeError: "'NoneType' object is not callable" in ignored This is apparently meant to be read as Exception <<TypeError: "'NoneType' object is not callable" in ...>> [was] ignored instead of, for instance Exception TypeError: "'NoneType' object is not callable" in ignored Even when parsed correctly, it is a bit mysterious (who/what ignored the exception?) to one not in the know and has generated more than one python-list thread. Suggestion (from John Machin): reword to something like Shutdown ignored this exception: TypeError: "'NoneType' object is not callable" This would tell people that they might need to find out more about the shutdown process. Would it be permissible to change this in 3.1?
-
{{{ #!rst We need RTL (right-to-left) language support in MediaGoblin. Presumably this requires: - Pushing a variable into the general template context specifying whether the current language is LTR or RTL - Making an RTL stylesheet - ... other things? I'm assigning Osama Khalid to this ticket. Osama, you don't have to do this necessarily, but at least please give advice on what needs to be done (you can unassign yourself then if you like). }}}
-
· link
The OS X linker now understands -R, but distutils continues to pass the wrong flags back in distutils.unixccompiler.runtime_library_dir_option(). I'm checking with the Apple folks as to exactly what the right flag is.
-
· link
To reproduce in master: 1. Have "normal" computer hardware. Instead of a Core i7 with a solid-state drive, use a Core 2 Duo with a regular hard disk drive. However, the issue will still be noticeable even on the super-fast computer, just a little bit less so. We can't expect users to be running brand new computers bought last month, we should expect them to run machines that are five years old. 2. Have a project file with a bunch of clips in the timeline. Texture (from http://jeff.ecchi.ca/public/sample-pitivi-projects/ ) can be a good test case. 3. In ~/.cache/pitivi, rename or delete the "thumbs" folder. 4. Load the project. Result: - Project loading takes a LOT longer than before. It used to be nearly instantaneous before the implementation of the clutter timeline and new thumbnailer. - Extremely sluggish/non-responsive UI during (and after) project loading. You will feel it, guaranteed. On a Thinkpad X61, the system load goes to 14 when trying to load the “Texture” sample project. Yet, as far as we have been told, we are not blocking on I/O anymore (in theory), so maybe we are now starving the CPU by doing too much work at once and at the wrong time, preventing the UI from having enough ressources to be reactive. Would be nice to do profiling to be sure. The current thumbnailer implementation does two things: - It generates thumbnails for the visible portion of clips in the timeline, in higher priority - It does background processing to process the parts that are not currently visible Potential avenues to investigate or solve the problem: - Defer work to when nothing else is happening. Thumbnailing should never happen while we're loading a project, playing or rendering. Be able to pause and resume background thumbnailing. - Do less concurrent work. Throttle the background thumbnailing with a scheduler? Depending on the number of available CPU threads/cores. Maybe always try to leave one core free, especially if the pitivi window is not the focus (ie the user is doing something else)? Or, more simply, instead of processing all clips at the same time, perhaps limit to processing only one clip at a time for the background queue? - Previously, it committed (writes the clip's thumbnail cache sqlite file to disk) for every single thumbnail in the clip, which quickly destroyed performance by saturating with unnecessary I/O. The current implementation now commits only once the clip has been entirely processed, which is lighter in terms of I/O but also a bit overzealous, in the sense that it would be sufficient to commit using a timer (ex: every 30 seconds or when the clip processing completes, whichever comes first). Otherwise, if you try to thumbnail a clip that is two hours long, nothing will ever get written to disk until it has been thumbnailed entirely (which can take hours) Somewhat related (or perhaps to be obsoleted): https://bugzilla.gnome.org/show_bug.cgi?id=591427#c21
