cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "the modern world where network packets and compiler optimizations are effectively hostile"
<kenaan>
arigo default 8fcad79f230c /: Merged in smihnea/pypy_nopax/nopax (pull request #551) Adding nopax option for system that use PaX
jwhisnant has quit [Ping timeout: 246 seconds]
<kenaan>
arigo default 3c1c88df6ea9 /lib_pypy/_tkinter/tklib_build.py: Minor tweaks, be more explicit about the fact that if we don't really find anything we'll fall back to ``linklibs=[...
<cfbolz>
arigato: thanks, and sorry for being pushy
catalinif has joined #pypy
jwhisnant has joined #pypy
<kenaan>
arigo py3.5 ca4d0c90f5a1 /lib_pypy/_cffi_ssl/_cffi_src/openssl/x509_vfy.py: Issue #2605 Support for libressl 2.5.4
<fijal>
arigato: I have an afternoon booked for looking at vr sketch
<cfbolz>
:-)
<fijal>
but we should maybe look at travel details
rokujyouhitoma has joined #pypy
<arigato>
...right
<arigato>
fijal: and good morning too
<fijal>
:-)
<fijal>
how's your post-conference status?
rokujyouhitoma has quit [Ping timeout: 255 seconds]
<arigato>
zzzzrmf?
<fijal>
hehe
<catalinif>
hello, I'm working to 2387 issue, after adding support lot long double I made a test for long double precision. When I ran my test I got a crash in pypy, investigating I saw in push_arg_as_ffiptr function that an assert is triggered for float and double data type. Any idea why those data types are not accepted?
<arigato>
catalinif: look at the caller, it's likely checking for the type
<arigato>
something like "it's not a float and it's not a double, so I'm going to call push_arg_as_ffiptr() as the generic fallback"
<catalinif>
so you are saying that before calling push_arg_as_ffiptr() a float or double data types check is made right
<magniff_>
Sup everyone) Does this make sense to add eventually rpython/jit/backend/cuda backend? Sure this one is expected to work in tandem with general CPU.
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
<realitix>
hey arigato. I don't understand why the binary operation you pointed is not working the same with C or Python
<arigato>
catalinif: yes
<catalinif>
and then why the assert from push_arg_as_ffiptr() is able to see those values as float or double ?
<LarstiQ>
magniff_: how would that work?
<magniff_>
I can imagine somewhat like system level decorator - if decorated function can be proved in runtime to be map/reduce like this cuda backend would be used.
marr has joined #pypy
<magniff_>
This is just a little fantasy of mine, that why I am asking about sanity :)
<antocuni>
magniff_: this sounds like something which can be done even outside pypy
<magniff_>
what do you mean exactly?
<antocuni>
something like numba, basically
<antocuni>
but maybe I didn't understand correctly what you proposed to do. A code example would be a good start
<arigato>
catalinif: a "long double" is not a "float" or a "double"
<magniff_>
Antonio, no you got me right. Does numba plays with PyPy nicely?
<antocuni>
no idea, but I doubt it. But this doesn't mean that it's not possible to write a numba-like library which DOES play nicely with pypy
<arigato>
realitix: "1 << 31" in C returns an "int", so the result is casted to a C "int"
<antocuni>
e.g. you could have a library which generates C and/or assembly code on the fly and the calls it through cffi
<antocuni>
this would play nicely with pypy
<realitix>
arigato, is it possible to manage this difference ?
<magniff_>
ok, thanks
<antocuni>
realitix: (note that I don't know what you are talking about exactly) you might be interested in __pypy__.intop.int_lshift
<arigato>
antocuni: no, we're talking about cffi supporting "1 << 31"
<realitix>
yes
<antocuni>
ah ok sorry
<magniff_>
antocuni, great phd btw :) Really enjoyed yours and Carl`s one.
<antocuni>
thanks :)
<magniff_>
Carl was very excited to have at least one reader, that is cute.
<LarstiQ>
well, phds aren't read that much
<antocuni>
yeah, same here. I think you are the first one who tells me to have read mine :)
cstratak has joined #pypy
rokujyouhitoma has joined #pypy
rokujyouhitoma has quit [Ping timeout: 240 seconds]
tilgovi has quit [Ping timeout: 246 seconds]
<cfbolz>
catalinif: I think what you need to do is convert the rpython double to a long double before passing it to rffi
jcea has joined #pypy
<arigato>
cfbolz: I think the goal is to avoid any conversion to "double"
lapinot has quit [Ping timeout: 240 seconds]
<arigato>
I may be missing details though
<arigato>
or even more than details :-)
cstratak has quit [Quit: Leaving]
<cfbolz>
arigato: I am probably missing details too, but I think the current exception is the simple case, where a normal python float is passed to a function expecting long double
cstratak has joined #pypy
<arigato>
ah
<cfbolz>
And that conversion needs to happen somewhere, maybe in rlib
<arigato>
seems that FuncPtr.push_arg() needs to be passed a rarithmetic.r_float() is the type is 'float'
<arigato>
so in the same way, we should pass it a rarithmetic.r_longfloat() for 'long double'
<arigato>
sorry, that's rarithmetic.r_singlefloat() instead of rarithmetic.r_float()
<cfbolz>
Yes
<arigato>
search for _singlefloat() in pypy/module/_rawffi/alt/type_converter.py
<arigato>
unsure why it doesn't end in "self.error()" so far
<arigato>
...ah, that's because pull request #555 already adds a case for "elif w_ffitype.is_longdouble():"
<arigato>
but then calls self._float(), which is supposed to work with "double", not "long double"
<cfbolz>
Right
<cfbolz>
catalinif: ^^
<arigato>
so you need to add "def _longfloat(self...)" here, and a "handle_longfloat()" method, which needs implementation in both interp_funcptr.py and interp_struct.py
<danieljabailey>
I translated pypy twice with two different --gc options, but the resulting executables I get are identical. What am I doing wrong?
inad922 has joined #pypy
<arigato>
danieljabailey: if you get byte-for-byte identical executables, then they *are* the same. even translating twice with the exact same options doesn't give a byte-for-byte identical result
<njs>
you could not support long double, that's a pretty reasonable position to take too :-)
<arigato>
njs: that's the position we took since forever about ctypes, yes
<danieljabailey>
arigato: oh, is there a timestamp in the executable or something?
ronan has joined #pypy
<arigato>
danieljabailey: I think so, yes, but more importantly it depends on random details that change
<arigato>
also, I'm assuming you mean "libpypy-c.so"
<danieljabailey>
Ah, no pypy-c
<arigato>
that's a 8KB wrapper
<danieljabailey>
ah
<danieljabailey>
okay, I get it
rokujyouhitoma has joined #pypy
rokujyouhitoma has quit [Ping timeout: 258 seconds]
antocuni has quit [Ping timeout: 255 seconds]
chaoflow has joined #pypy
chaoflow has quit [Client Quit]
nimaje1 has joined #pypy
nimaje1 is now known as nimaje
nimaje has quit [Killed (orwell.freenode.net (Nickname regained by services))]
rokujyouhitoma has joined #pypy
rokujyouhitoma has quit [Ping timeout: 260 seconds]
<tos9>
nimaje: Would be useless except that they remembered to include Mathematica support, thank goodness.
<nimaje>
well, as they don't do "crazy" stuff there is no support for lisp like print and no print statment like in py2 :)
<tos9>
they probably aren't including support for languages that are EOL'ed
<magniff_>
This must be something obvious, but I am struggling - I am trying to use from rpython.rlib.rsre.rpy import get_code function and it fails in translation time with UnionError...
<magniff_>
I am calling get_code(r"hello world")
<magniff_>
but this is exactly what shown in corresponding tests
<ronan>
magniff_: pastebin the translation error please
<arigato>
magniff_: ah, no, this is not rpython
<magniff_>
whaaaa?)
<arigato>
rpython.rlib.rsre.rpy/ is explicitly not RPython
<arigato>
in rpython programs you can only use rpython.rlib.rsre.rsre_*
<arigato>
which assume that you have an already-compiled regexp
<arigato>
we didn't rewrite any regexp compiler, so it exists only as pure python code
<magniff_>
hooho
<magniff_>
soo, currently it should be compatible with python 3.5 sre bytecode, right?
<arigato>
I think so, and that's an extension of 2.7 sre bytecode
<magniff_>
oh god
<magniff_>
why you guys just didnt rewrite regex engine to something less... retarded I guess)
<magniff_>
sre is horrible
<arigato>
it's just a special case to the general question "why do we rewrite Python instead of something less horribly complicated"
<magniff_>
lol
<arigato>
"rsre" is actually better than CPython's, though, while being compatible
<magniff_>
does it have pathologies like (a+)+b
<magniff_>
I bet it does
<arigato>
(not counting the fact that it is jitting, it has a better complexity in some cases, and is cleaner imho)
<arigato>
the known incompatibilities are very, very, very obscure
<arigato>
but exist
<magniff_>
would it make sense to expose rsre as a shared lib to make it available to cpython?
<fijal>
magniff_:I heavily doubt they would accept it in core
<kenaan>
arigo default c40c4fbf020e /rpython/rlib/rsre/rpy/_sre.py: Mention that you can't compile new regexps in an RPython program, you can only use precompiled ones
<magniff_>
I mean as a installable stuff from pypi
<fijal>
I don't know, maybe
<magniff_>
surely one could use standard sre_parse, sre_compile from stdlib to build actual bytecode and rsre.match as a backend
<magniff_>
even though all this backtraking business is a complete mess it might be a good idea to use jitted regex runtime from cpython
<arigato>
maybe as a generally useful C library, to which you'd build a cffi interface for cpython
<magniff_>
yes
<arigato>
this library would be rather big, as it would include the complete jit and gc
<magniff_>
i am ok with that
<arigato>
well, then you can try, I suppose
<magniff_>
thanks for your bless, master))
<arigato>
though my first guess is that "pcre" is better if you want a C library with a JIT
<arigato>
(but of course it's not exactly 100% compatible)
<magniff_>
i am considering dfa implementation for future
<magniff_>
it doesnt struggle with exponential complexity
<magniff_>
as backtrakers do
<arigato>
right, but note that it's unlikely we can *ever* change to a DFA implementation for CPython or PyPy's "re"
<arigato>
because it's almost impossible to obtain the same results for match.groups(), for example
<magniff_>
yes, yet it might be way better choice in some specific applications like tokenization
<magniff_>
it is extremely inefficient with current sre
<magniff_>
O(#_of_tokens) * len_of_input
<arigato>
right, but in these specific cases, people use other libraries that exist and aren't compatible
<magniff_>
so I would be nice to have it as a installable stuff
<magniff_>
sure
aboudreault_ has joined #pypy
rokujyouhitoma has joined #pypy
rokujyouhitoma has quit [Ping timeout: 246 seconds]
dmalcolm has quit [Remote host closed the connection]
ronan has quit [Ping timeout: 260 seconds]
vkirilichev has quit [Remote host closed the connection]
vkirilichev has joined #pypy
ronan has joined #pypy
vkirilichev has quit [Ping timeout: 246 seconds]
arigato has quit [Quit: Leaving]
ronan has quit [Ping timeout: 260 seconds]
ronan has joined #pypy
dmalcolm has joined #pypy
magniff_ has quit [Ping timeout: 260 seconds]
<kenaan>
rlamy multiphase e2b16d8ae93f /pypy/module/cpyext/test/: rename _testmultiphase to multiphase2, to avoid confusion with the CPython extension _testmultiphase
antocuni has quit [Ping timeout: 260 seconds]
forgottenone has joined #pypy
TheAdversary has joined #pypy
rokujyouhitoma has joined #pypy
rokujyouhitoma has quit [Ping timeout: 260 seconds]
inad922 has joined #pypy
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
inad922 has quit [Ping timeout: 240 seconds]
adamholmberg has quit [Ping timeout: 248 seconds]
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
tilgovi has joined #pypy
adamholmberg has joined #pypy
realitix has quit [Ping timeout: 255 seconds]
asmeurer__ has joined #pypy
vkirilichev has joined #pypy
vkirilichev has quit [Remote host closed the connection]