cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | Matti: I made a bit of progress, the tests now only segfault towards the end
otisolsen70 has joined #pypy
derpydoo has quit [Quit: derpydoo]
habnabit_ has quit [Quit: ZNC -]
energizer has quit [Quit: ZNC 1.7.0+deb0+xenial1 -]
habnabit_ has joined #pypy
energizer has joined #pypy
Atque has joined #pypy
derpydoo has joined #pypy
epony has quit [Remote host closed the connection]
<arigato> cfbolz: just curious, you said in issue3825 it would be not that hard to allow monkay-patching PyFloatType.tp_repr? how?
<cfbolz> arigato: ah, not precise by patching the C struct
<cfbolz> but we could have a __pypy__ api if we *really* wanted
<cfbolz> not sure it's a good direction generally though :-/
<arigato> still, how exactly? it seems to me it would make all calls to repr() indirect
<cfbolz> arigato: we could allow heaptype __dict__ modification generally via that api
<arigato> but we're talking about PyFloat_Type, not a heaptype
<cfbolz> sorry, I meant builtin-types
<cfbolz> it would be efficient with the JIT, like method calls on user-defined classes are efficient (ie a quasi-immutable version)
<arigato> it might negate the efforts we spent making the non-jitted version fast, though
<cfbolz> (for a while we even had a translation option for generally allowing monkey-patching on all types)
<cfbolz> arigato: that's true, and indeed probably the real problem :-/
<cfbolz> anyway, I don't *want* to do that, it's a pretty obscure use case
<arigato> OK, I just wondered if I was missing something :-)
<cfbolz> arigato: yes, I probably only thought about the JIT, and not the careful caching of special methods
<cfbolz> arigato: I still think that if somebody wants an especially fast special-purpose float formatter, they should just call it explicitly
<arigato> yes
<cfbolz> arigato: thanks for looking at raise-in-thread-2 :-)
<cfbolz> Here are the slides about cpu emulation using PyPy that I used in a talk last week:
derpydoo has quit [Ping timeout: 268 seconds]
fuzzypixelz has joined #pypy
<fuzzypixelz> hello!
<fuzzypixelz> trying to run any RPython code from pypy, i.e. pypy/rpython/bin/rpython results in things like:
<fuzzypixelz> SyntaxError: Missing parentheses in call to 'print'. Did you mean 'print(...)'?
<fuzzypixelz> CPython and pypy give similar errors
<arigato> rpython is a sublanguage of python 2, not python 3
<fuzzypixelz> does pypy support python2? is there a way to enable that via commandline arguments?
<arigato> and you need to use python2 to run bin/rpython
<fuzzypixelz> my distro doesn't seem to ship python2 anymore
<arigato> yes, you can use pypy (there is a python2 and a python3 version of pypy)
<fuzzypixelz> meaning pypy 2.7?
<fuzzypixelz> or is python2 included in pypy 3.9
<arigato> yes, the "pypy2.7" column in
<fuzzypixelz> oh I have to download it okya
derpydoo has joined #pypy
<fuzzypixelz> It seems that RPython's is different from Python 2
<fuzzypixelz> In that it takes exactly 3 arguments
<fuzzypixelz> while Python 2 leaves the mode optional
<fuzzypixelz> this makes me wonder how do I lookup documentation for the RPython standard library?
<fuzzypixelz> even the order is different for RPython
<arigato> well, RPython is more or less documented at, but it's meant to be used by people that want to write some kind of interpreter, not as a general purpose programming language
<arigato> there are also alternatives to the standard library that is compatible with RPython, in the "rpython.rlib" package
<arigato> but RPython is supposed to be a sublanguage of Python in the sense that any RPython program should work when directly executed as Python
<arigato> so I'm not sure what you mean by "even the order is different", it shouldn't be
fuzzypixelz has quit [Remote host closed the connection]
fuzzypixelz has joined #pypy
fuzzypixelz has quit [Remote host closed the connection]
epony has joined #pypy
derpydoo has quit [Read error: Connection reset by peer]
otisolsen70 has quit [Quit: Leaving]
jcea has joined #pypy