This is an emphatic vote to **not** get rid of property support in
RPython. We use this heavily to expose a clean API for describing ISAs in
Pydgin: https://github.com/cornell-brg/pydgin
I'd be happy to take a look when I have more time next week; I'll pop into
IRC around then to chat. Currentl
Exascale (super)computers are aiming for a performance target that exceeds
1 exaFLOPS, or 10**18 floating point ops per second. In the US this goal
usually comes associated with a power requirement as well, I think last I
heard the power goal was a cap of 20 megawatts (as proposed by the Dept. of
xpects a .dylib file on OSX, but
rffi.CExternVariable expects a .so file.
Creating a copy of the .dylib file so I have **both** a .so and .dylib file
makes this error go away; but I suspect internal state of the library would
not be consistent with two copies...
On Mon, Jun 22, 2015 at 11:17 AM, D
After a bit of a struggle I finally got RFFI working for a shared libary I
had compiled. I found a few strange discrepancies in the behavior of
ExternalCompilitionInfo on OSX I thought may benefit from fixes to make
behavior more consistent.
=== RPython Translation vs. Python Execution Strangeness
Hi all,
Thought I would chime in since this is also of interest to me. I have two
distinct projects related to hardware simulation, one of which is very well
suited towards the RPython toolchain (Pydgin), and another which is much
more closely related to MyHDL (PyMTL). Sarah kindly pointed out t
