Filter results for “Dev”:
Toughness
Just bugs labeled...
-
Right now Marionette just sends stderr/stdout to /dev/null. It should at least put it in a log somewhere or have a cmdline option to change that behavior.
-
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.
-
Our last dev update happened [in February] (http://www.unknown-horizons.org/devblog/category/1/114/Main-Development/). --- Hi, as you should have been already noticed there happened a lot of things regarding the hosting and administration of the different services we use. Happily we had also some time left to tweak some old code and create some existing new features, improving the game experience. ThePawnBreak spent his spare time to create a settings widget to dynamically set up your favorite hotkeys and actions. It is now possible to set up to 2 different hotkeys for a provided action, like taking screenshots. Manual editing of your settings file is not necessary anymore, which makes the process very comfortable. [screenshot here] He also successfully tackled several problems with our scenario gui and fixed a few other annoyances on the way. In particular, you now can confirm many menus using your Enter key where previously clicking on an OK button was required. Thanks for your great work again! `... to be continued` `Something about loading screen messages now being human-readable (with two pics below)` For our packagers out there: Unknown Horizons now uses `/usr/bin/env python2` as default hashbang. If your distribution or platform does not provide this, you may want to overwrite that change in your packages. More details: [PEP 394] (http://www.python.org/dev/peps/pep-0394/) `Something about short- and longer-term future plans (black death, datacollect?, overlays)`
-
I think this is caused by #3301. The [Windows implementation of find_cmd](https://github.com/ipython/ipython/blob/master/IPython/utils/_process_win32.py#L74) expects a command name without an extension, but the test now uses 'python.exe'. I think that 'python.exe' is a valid command on Windows, so I think we should modify `find_cmd` to allow passing a command with an extension. Alternatively, we could modify the test to strip the extension. ``` ====================================================================== ERROR: Make sure we find sys.exectable for python. ---------------------------------------------------------------------- Traceback (most recent call last): File "S:\Users\slave\Jenkins\shiningpanda\jobs\d5f643a2\virtualenvs\ff035a1d\lib\site-packages\nose\case.py", line 197, in runTest self.test(*self.arg) File "S:\Users\slave\Jenkins\shiningpanda\jobs\d5f643a2\virtualenvs\ff035a1d\lib\site-packages\ipython-1.0.dev-py2.7.egg\IPython\utils\tests\test_process.py", line 36, in test_find_cmd_python nt.assert_equal(find_cmd(python), sys.executable) File "S:\Users\slave\Jenkins\shiningpanda\jobs\d5f643a2\virtualenvs\ff035a1d\lib\site-packages\ipython-1.0.dev-py2.7.egg\IPython\utils\process.py", line 67, in find_cmd raise FindCmdError('command could not be found: %s' % cmd) FindCmdError: command could not be found: python.exe ```
-
Our install docs now only describe how to set up new-style configman apps: http://socorro.readthedocs.org/en/latest/installation.html Vagrant should do this as well. Upsides are that we can get a full working stack without needing hbase, and we'll match the install docs. Only downside I can think of is that it is unlike what we run in dev/stage/prod, so it'll make it hard to test e.g. PHP changes. However, I think it's appropriate to get things working in vagrant first before we roll out changes to those environments.
-
· link
This issue is to document the defaultTest parameter to unittest.main(): http://docs.python.org/dev/library/unittest.html#unittest.main Note that it is not enough simply to say that *defaultTest* is a "default test name or iterable of test names." The documentation should also say when *defaultTest* is used based on the value of the *module* and *argv* arguments, etc. This issue is an offshoot of issue 15132.
-
· link
http://melange-dev-hrd.appspot.com/gci/org/application/edit/google/gci2011?validated# with program admin rights gives you an orange "looking for google summer of code?" link on the upper right.
-
· link
The character / is disallowed in a host expression in a CSP policy (per the CSP spec). For example, with this directive : style-src 'self' http://example.com https://foo-dev.example.com/; foo-dev.example.com won't be added as an allowed source, and loading a CSS file from it will be denied. This is a pretty easy mistake to make as I saw today. Right now we just do a CSPDebug() if there's an invalid character, see http://mxr.mozilla.org/mozilla-central/source/content/base/src/CSPUtils.jsm#1318 There's lots of CSPDebug level output and it's easy to miss this message when you're trying to see why your policy doesn't work, I found today. After some discussion with Sid and Tanvi, it would be nice to make these a CSPWarning() - but not a CSPError() as the spec dictates if a host is invalid, it's dropped and the rest of the valid hosts are kept and CSP processing continues. This seems like a good first bug. I would suggest in addition to the CSPDebug() call that's there, doing a CSPWarning() if the last character of the rejected CSP source is a slash, saying that host <hostname-ending-in-slash> will be ignored, due to its ending with a slash.
-
· link
Does the devguide document the benchmarking suite anywhere? I can't see it anywhere in the index on http://docs.python.org/devguide/ and google doesn't seem to show anything. suggested content: * how to run the benchmarks for a Python 2 implementation * how to run the benchmarks for a Python 3 implementation Sorry if it exists and I missed it
-
· link
see http://dev.w3.org/html5/spec/origin-0.html#sandboxed-automatic-features-browsing-context-flag according to Microsoft's test suite[1], webkit has not implemented this either the spec mentions autoplaying video and automatically focusing on a text box - Microsoft has also decided that refresh via <meta> should also be blocked in this case i'd like to fix these in a followup to the initial iframe sandbox work (bug 341604) landing, after discussion on whether we really want to do this and if so, which pieces of it (and if we can think of anything else we'd like to block that's an "automatic feature") [1] http://samples.msdn.microsoft.com/ietestcenter/#html5Sandbox
