fijal

56 ms·

571.
by fijal 15y ago
Not sure about you, but I would be happy to not have USA values anything near my countries in Europe.
572.
by fijal 15y ago
Did you notice how men in suits are left and right but not in the middle?
573.
by fijal 15y ago
Seen everything but topless models here.
574.
by fijal 15y ago
For what is worth, the "Before git and mercurial, merging was a nightmare in most monolithic source control systems" seems like a heavy misconception for me. How many people actually tried? The pypy project was using heavy branching and mer
575.
by fijal 15y ago
As you might know, we disagree with Travis when it comes to timelines. C API is not really useful without CPython C API and we're trying hard to make pypy interoperate with C. Look for f2pypy for an example.
576.
by fijal 15y ago
Yes, 3+ hours sounds incorrect. Also, it's not like KDE builds in 15 minutes either. I don't see how a long build time makes the project immature, feel free to suggest the connection.
577.
by fijal 15y ago
Note that as PyPy we deliberately don't take part in the language design discussions. We won't implement the array infix operator precisely because other people make those decisions.
578.
by fijal 15y ago
There are two blog posts as of why: http://morepypy.blogspot.com/2011/05/numpy-in-pypy-status-an... http://morepypy.blogspot.com/2011/05/numpy-follow-up.html It's not possible to do cool stuff with reusing - like parallelizing expressio
579.
by fijal 15y ago
It does implement lazy evaluation of array expressions and JIT to compile it on the fly to assembler. Having an assembler generator that's not too bad helps immensely with such efforts
580.
by fijal 15y ago
This does not cover PyPy and under PyPy behavior of those methods will be Very different.
581.
by fijal 15y ago
https://bitbucket.org/alex_gaynor/pypy-postgresql/overview unfortunately a fork (a well maintained one at least)
582.
by fijal 15y ago
Two answers really: * sharing memory - sometimes you have lots of immutable data, like modules, graphs, whatnot. Yes, there is copy-on-write and no, it doesn't work well on any python implementation out there. Also sometimes it's mostly-imm
583.
by fijal 15y ago
For what is worth, most "performance" idioms are anti-idioms on PyPy. Especially those: sum = 0 for d in data: sum += d product = 1 for d in data: product *= d Are much faster than reduce/map equivalents. The zip/di
584.
by fijal 15y ago
I just counted everything including stdlib and whatnot (all that comes in the checkout). "Rubinius is still implemented more in Ruby than any other implementation out there." well that's probably true, but not really useful. If all ruby imp
585.
by fijal 15y ago
According to my very unscientific measurements (I didn't bother looking which files are potentially auto generated), I got: 182kloc of C (.c files) 110kloc of c++ (.h + .cpp files) 558kloc of ruby (.rb files) That puts C/C++ at r
586.
by fijal 15y ago
Provided you assume those effects are linear, then yes. There is however no evidence for that.
587.
by fijal 16y ago
That's just plane gay...
588.
by fijal 16y ago
Last time PyPy got money from google was spring 2009. They can still ask PyPy developers to do stuff :)
589.
by fijal 17y ago
Benchmark sources are here: http://codespeak.net/svn/pypy/benchmarks/
590.
by fijal 17y ago
The reason why PyPy dropped llvm as an assembler backend is because llvm is a pain to deploy and use. We have an undergoing llvm backend, but there is a bit of unadressed issues and someone might want to take a look at it ( http://codespeak