cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
todda7 has joined #pypy
<arigato> cfbolz: I can try to help if you like, I've got a working 32-bit environment on Linux
oberstet has joined #pypy
<cfbolz> arigato: I got it now
<cfbolz> It was a comedy of errors, no real problem
<cfbolz> I hadn't realized that the tracer stores doubles as long longs
<cfbolz> (sometimes)
<arigato> right
<cfbolz> arigato: confusingly enough, ConstFloat.fromfloat(longlong) actually works, just gives you a result you don't want
<arigato> ah
<cfbolz> Which is what I did
<cfbolz> arigato: anyway, none of this has anything to do with the real work of the branch, which just seems to work
<arigato> cool
<cfbolz> arigato: at some point I'd like your input on the open-ended-traces branch
<cfbolz> the motivation is that sometimes there is really code (eg auto-generated) that is veeeery long, without inlining
<cfbolz> so that means we try to trace it infinitly often, and always abort
<cfbolz> the branch detects that, and cuts such traces arbitrarily with a guard that always fails instead
<arigato> ah, and then you can trace a bit later from that failing guard and progress in this way?
<cfbolz> yes
<cfbolz> that's the idea
<arigato> why didn't we have that idea before? :-)
<arigato> isn't it reasonable to just do that whenever we see a trace too long, instead of aborting?
<cfbolz> arigato: I don't know, I think then you might really inline too much
<arigato> ah yes
<arigato> sorry, of course
<cfbolz> no worries, I had to page back in a lot of this info too ;-)
<cfbolz> arigato: the bad news is, there is a segfault in the bug reporters proprietary example program, that I can't debug :-/
* cfbolz looks for the issue
<arigato> good luck. I would have told "we can't debug then sorry"
<cfbolz> I don't know, I kind of agree
<cfbolz> but I also want the branch to land
<cfbolz> arigato: anyway, thanks for the cross-check that the idea sounds good a priori :-)
<arigato> :-)
mwhudson has quit [Quit: No Ping reply in 180 seconds.]
mwhudson has joined #pypy
gef_ has joined #pypy
gef__ has joined #pypy
gef has quit [Ping timeout: 252 seconds]
gef_ has quit [Ping timeout: 268 seconds]
marcel88 has joined #pypy
marcel88 has quit [Client Quit]
marcel42 has joined #pypy
gef has joined #pypy
marcel422 has joined #pypy
marcel422 has quit [Client Quit]
gef__ has quit [Ping timeout: 240 seconds]
marcel422 has joined #pypy
<marcel422> Hi. I am just starting with pypy and tried to run my python application with pypy. There is one problem I cannot fix: pypy fails to import my local packages. I use pypy 7.3.4 (which is python 3.7.10). Everything works perfectly when I use python 3.7.10 with cpython. In my main file I do "from parser import Parser", where "parser" is a local python package and with pypy I get "ImportError: cannot import name 'Parser'". I would be so ha
<marcel422> f someone knows how to fix this.
marcel42 has quit [Quit: Connection closed]
<marcel422> @arigato: No. The package failing to import is not a dependency. It is a local package inside my project.
<arigato> but "parser" is also the name of a standard module, so I think the error is that pypy is finding the standard module, which doesn't have a Parser class in it
<marcel422> @arigato. Oh. So you mean just changing the name of my parser package would fix it?
<arigato> likely. but it's strange that your package hides the standard module on CPython but not on PyPy
<marcel422> @arigato. Thank you so much. It works. Yes indeed. I was didn't think about this possibility at all as it worked just fine with CPython
<arigato> it's even a built-in module (not just a standard module) in CPython, I thought these were not shadowable
<arigato> I cannot make "import parser" find a local package in CPython 3.7
<arigato> it always finds the built-in module for me
<arigato> ah, found a different machine with a different OS where "parser" is not a built-in but standard module---and there, you can
<arigato> so the complete answer is that what you did works with *some* installations of CPython but not others
<cfbolz> 🎉
<fijal> hah
<fijal> great
<marcel422> @arigato. Never ever would I have fixed this without your answer ^^ - thanks
<arigato> you're welcome. the hint was the error message that said "cannot find name xyz inside module 'parser'", i.e. "I could import a module 'parser' but it looks like it's not the right one"
lritter has joined #pypy
marcel422 has left #pypy [#pypy]
<ctismer> Hi @arigato here is Chris.
<ctismer> @arigato I am maintaining PySide6, and I'm wondering (again) what it would take to support PyPy.
<arigato> hi!
<arigato> how are you?
<ctismer> I am fine so far. Living near Kiel now, in Schönberg, <5 km to the beach, happily married.
<ctismer> I still like PyPy very much, while making my living from work for Qt Company.
<ctismer> all ok with you as well, I hope?
mattip_away has joined #pypy
mattip_away has quit [Remote host closed the connection]
oberstet has quit [Quit: Leaving]
<cfbolz> ctismer: hey Christian!
jcea has joined #pypy
lritter has quit [Ping timeout: 240 seconds]
<ctismer> cfbolz: Hi Carl!
<cfbolz> ctismer: pyside would be cool, but probably also a ton of work :-(
todda7 has quit [Ping timeout: 252 seconds]
todda7 has joined #pypy
kanaka has joined #pypy
kanaka has quit [Changing host]
kanaka has joined #pypy