arigato 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 | mac OS and Fedora are not Windows
danieljabailey has quit [Quit: ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in]
shodan45 has quit [Quit: No Ping reply in 180 seconds.]
shodan45 has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
Cld has quit [Ping timeout: 272 seconds]
jcea has quit [Quit: jcea]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
_whitelogger has joined #pypy
xcm has quit [Remote host closed the connection]
dddddd has quit [Remote host closed the connection]
xcm has joined #pypy
cody has joined #pypy
cody is now known as Guest5593
Guest5593 is now known as codypiersall
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
Garen has quit [Read error: Connection reset by peer]
Garen has joined #pypy
danieljabailey has joined #pypy
codypiersall has quit [Ping timeout: 256 seconds]
illume has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
Garen has quit [Read error: Connection reset by peer]
Garen has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
Garen_ has joined #pypy
Garen has quit [Ping timeout: 268 seconds]
Garen_ has quit [Remote host closed the connection]
Garen has joined #pypy
fryguybo1 has joined #pypy
fryguybob has quit [Ping timeout: 250 seconds]
beystef has joined #pypy
speeder39_ has quit [Quit: Connection closed for inactivity]
beystef has quit [Quit: beystef]
oberstet has joined #pypy
Ai9zO5AP has joined #pypy
<arigato> mattip: I still need to look at the test_pypy_c failures (I'll look in the py3.6 branch)
<cfbolz> good morning!
* cfbolz needs to look at some tests failures too
<arigato> morning!
<mattip> thanks. There are some unicode test failures as well, and I am trying to minimize the difference between the branches
<cfbolz> right
<cfbolz> mattip: I am looking at some performance numbers for the utf-8 work
<cfbolz> basically indexing is 5x slower, everything else faster
<arigato> kind of expected
<cfbolz> right
<cfbolz> arigato: computing the index storage is cheap, btw!
<arigato> cool!
<cfbolz> "decode" + computing the index storage is still cheaper than a decode to ucs4
<arigato> right
irclogs_io_bot has quit [Remote host closed the connection]
<cfbolz> (depending a bit on what chars there are in the string)
<arigato> ideally the JIT should fuse decode-from-utf8 with compute-index-storage, for example
<arigato> to make it even faster
<cfbolz> arigato: in our miracle world or rewrites, you mean? :-)
<arigato> yes :-)
<cfbolz> will think about it some more
<kenaan> arigo default 991f167e4663 /pypy/module/pypyjit/test_pypy_c/test_string.py: fix test
irclogs_io_bot has joined #pypy
<cfbolz> seems I broke pickling of unicode iterators (obviously)
<cfbolz> and it's not tested (obviously)
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
illume has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ambv has joined #pypy
<ambv> Ohai.
<cfbolz> ambv: hey!
<cfbolz> how are you?
<ambv> Pretty well, the renovation is nearly done (two more weeks until totally finished).
<ambv> And you?
<cfbolz> cool
<cfbolz> ok, got a bit of a cold
<cfbolz> also, pickling is annoying ;-)
<kenaan> cfbolz py3.6 e93780665de6 /pypy/objspace/std/: fix setstate on unicode iters
<ambv> @cfbolz: annoying? which part? :>
<cfbolz> all good, just broke unpickling of unicode iterators
<cfbolz> but fixed again
<cfbolz> arigato: are you also fixing the cffi test failures on trunk?
<kenaan> cfbolz default 666d447ee17b /pypy/module/pypyjit/test_pypy_c/test_string.py: try to fix the test_pypy_c failures on 32bit
<arigato> pf sorry
<cfbolz> :-)
<kenaan> arigo default ccd4a4363d59 /lib_pypy/cffi.egg-info/PKG-INFO: sorry, fix
<cfbolz> that should make linux64 on trunk green again
<arigato> looking at some of the pypyjit/test_pypy_c failures on py3.6...
<arigato> I think the new ones are probably just of the kind "we no longer produce the dummy getfield_gc_r which was anyway removed by the jit backend because its result is never used"
<cfbolz> arigato: yes, but not all
<cfbolz> arigato: eg the max one seems to be "range now returns an iterator, so stuff happens differently"
<arigato> yes, I'm talking about the failures newer than the 11th feb
<cfbolz> ah, ok
<cfbolz> sorry
<arigato> of course it doesn't mean I should ignore the other failures :-)
<cfbolz> :-)
<cfbolz> I can try to fix some too
<arigato> cool
<kenaan> arigo py3.6 1a39bb272421 /pypy/module/pypyjit/test_pypy_c/test_instance.py: We no longer get the dummy getfield_gc_r
Zaab1t has joined #pypy
<kenaan> arigo py3.6 c2f51a1cf58c /pypy/module/pypyjit/test_pypy_c/test_string.py: Fix for test_decode_ascii after the utf8 merge
illume has joined #pypy
<cfbolz> pypy is really good at this ;-)
<mattip> don't we just JIT it all away?
<cfbolz> yes
<mattip> (it is something used to micro-profile changes by rhettinger, recently came up on the cython mailing list)
<cfbolz> it's a bad benchmark, imo
<mattip> what would be better? They are measuring exactly what they want to measure for their purposes
<kenaan> arigo py3.6 53322e432860 /pypy/module/pypyjit/test_pypy_c/: The dummy_get_utf8? line is now not needed any more. Keep it around in the tests for future reference just in case w...
<cfbolz> mattip: yes, sorry, it's useful in exactly the context of cpython
<cfbolz> even for cython it's starting to be misleading
illume has quit [Quit: Textual IRC Client: www.textualapp.com]
<mattip> right
<kenaan> arigo py3.6 7c0f6e15febc /pypy/module/pypyjit/test_pypy_c/test_call.py: Goes with 53322e432860
<kenaan> cfbolz py3.6 f648c40320e6 /pypy/module/pypyjit/test_pypy_c/test_00_model.py: fix raises
<cfbolz> arigato: test_kwargs_virtual3 shows a real problem I think
<cfbolz> basically BUILD_CONST_KEY_MAP is not optimized much yet
<kenaan> arigo py3.6 6ae608ba39ef /pypy/module/pypyjit/test_pypy_c/test_containers.py: fix the first part of this test (only, for now)
<ambv> gotta go fetch some furniture. we'll be back later today.
ambv has quit [Quit: Textual IRC Client: www.textualapp.com]
<arigato> so the problem is that with the old BUILD_MAP, it would see the keys are completely constant, but not with BUILD_CONST_KEY_MAP?
<arigato> right, the first line in the opcode is space.fixedview(self.popvalue())
<cfbolz> yes
<cfbolz> I am not quite sure why the immutable[*]ness of the tuple content is lost
<cfbolz> we would fix this by using space.getitem, in any case
<cfbolz> arigato: should I?
<arigato> ah no
<arigato> space.fixedview on a tuple should just be "return self.wrappeditems", seen by the jit
<cfbolz> it does
<arigato> ah but yes, this looses the info in the class W_TupleObject about _immutable_fields_ = ['wrappeditems[*]']
<cfbolz> yes, because it gets passed through fixedview, which doesn't always return an immutable list
<cfbolz> bit annoying
<arigato> yes
<cfbolz> arigato: so, space.getitem?
<arigato> yes, this would fix it here
<arigato> ideally we should fix it for all space.fixedview() calls...
<cfbolz> arigato: I can't think of an easy general fix. we would have to track immutableness dynamically in the jit
tazle_ has quit [Quit: leaving]
tazle has joined #pypy
<arigato> which path of fixedview() can return a mutable but fixed-size list?
<cfbolz> arigato: fixedview works on applevel lists (makes a copy)
<arigato> yes, which means fixedview itself returns a never-mutated rpython list, no?
<cfbolz> hm
<cfbolz> arigato: unless one caller of fixedview mutates stuff, which would be a problem anyway
<cfbolz> arigato: do we have a make_sure_not_mutated thing?
<arigato> ah right
<arigato> but likely, _unpackiterable_known_length_jitlook() for example fills a list from [None]*length, item by item
<arigato> this means the annotator can't figure out that the result is not mutated any more
<arigato> I think
<cfbolz> plausible
<arigato> no, there is no make_sure_not_mutated()
<cfbolz> so we are a bit stuck
<arigato> maybe we could have such a function, which would be annotated like a "lst[:]" and return a new list object, but be rtyped as a no-op
<arigato> so that the annotation "not mutable" only propagates to the result, not to the argument
<cfbolz> right
<cfbolz> anyway, this is a bit cannons and sparrows (is that a thing in english?)
<arigato> yeah
<arigato> it's true that we might have fixedview() used a lot but probably not often on tuples that are constant
<cfbolz> right
<arigato> at this point you could even rewrite the BUILD_CONST_KEY_MAP with "assert isinstance(w_tup, W_AbstractTupleObject)" and call w_tup.getitem(i) directly, maybe
<cfbolz> since nowadays we don't care about objspace separation much anymore anyway?
<cfbolz> (I tend to agree, fwiw)
<cfbolz> ok, will do it
lritter has joined #pypy
Zaab1t has quit [Quit: bye bye friends]
<arigato> cool
<cfbolz> arigato: I guess I should use space.interp_w instead of assert, to fail nicely for the people that build weird code objects
<kenaan> cfbolz py3.6 2e21aa817a15 /pypy/interpreter/pyopcode.py: make BUILD_CONST_KEY_MAP JIT-friendly
<arigato> right
<kenaan> cfbolz py3.6 9f1fd685935c /pypy/module/pypyjit/test_pypy_c/test_misc.py: this is an improvement
<cfbolz> arigato: I am doing the cffi jit test next
<cfbolz> it's not about cffi
<arigato> I'm not sure I understand this test_ffi
<arigato> bdbe0dc2c7be sounds suspicious
<arigato> though of course the problem might be more than I was not available for comments at this time
oberstet has quit [Quit: Leaving]
<cfbolz> arigato: ah, I see
<cfbolz> k, so we are already substantially different than default :-(
<cfbolz> then I am maybe not going to look at it now ;-)
xorAxAx has quit [Ping timeout: 240 seconds]
xorAxAx has joined #pypy
<cfbolz> arigato: I see a lot of this: +4397: p339 = getfield_gc_r(ConstPtr(ptr338), descr=<FieldP pypy.objspace.std.unicodeobject.W_UnicodeObject.inst__utf8 8>)
<cfbolz> :-(
<arigato> still?
<arigato> the question is if the p339 is used anywhere
<arigato> if it isn't, then you should see that this line is +4397 and the next line also +4397
<arigato> i.e. no code was generated
<cfbolz> sorry, sorry, false alarme
<cfbolz> was using the wrong executable
<cfbolz> phew
<arigato> :-)
<arigato> I've tracked down the extra mess shown in bdbe0dc2c7be, to the branch memory-accounting
<arigato> which adds a "can do anything at all" logic in backendopt/writeanalyze for gc_add_memory_pressure
<cfbolz> ah
<cfbolz> is that needed?
<arigato> I'm still trying to understand the message of 4038d01ba9e9
<cfbolz> yes
<arigato> OK I may have understood it as meaning "the problem is that when we allocate an object, we initialize the field 'special_memory_pressure' to zero; but later we might call gc_add_memory_pressure, which would put a non-zero value; without the change in 4038d01ba9e9, the initialization to zero might be moved after the gc_add_memory_pressure"
<cfbolz> ok, but then saying "it can mutate anything" is a bit extreme, also I would have liked a unit test really :-(
<arigato> yes, I'm still running the jit tests to see if any fails
<arigato> I think that's why the test_pypy_c shows all these getfield(const)/guard_value again
<arigato> because we added a gc_add_memory_pressure in the loop
<cfbolz> arigato: you are talking about test_ffi right?
<cfbolz> or more generally
<arigato> yes, test_ffi
<cfbolz> yes, plausible
* cfbolz is digging trough the new importing and space bootstrapping instead
<arigato> the whole missing optimization is only to support the gc 'get_stats(TOTAL_MEMORY_PRESSURE)'
<arigato> or the whole branch, as far as I can tell
<cfbolz> arigato: right
<arigato> maybe we can ask around if someone ever used one particular line of what gc.get_stats() prints?
dddddd has joined #pypy
<cfbolz> arigato: is that only about stats?
<arigato> also I'm not too confident about (i.e. there are no tests for) the fact that we don't put an extra field 'special_memory_pressure' on W_Root, which would be globally bad
<cfbolz> Yes, why is there no _attrs_ on W_Root any more
<arigato> no, I mean, it's a field added by rtyping independently of any _attrs_
<cfbolz> Hrm
<arigato> (there is __slots__ on W_Root)
<Ninpo> Pleased to report no performance regressions on my tool between py3.5 7.1 alpha and py3.6 7.1 alpha...and my now native async generator and async list comprehensions work just fine
<Ninpo> :bigthumbsup:
<cfbolz> arigato: I forgot, does the annotator look at slots?
<arigato> cfbolz: yes
<cfbolz> OK
<mattip> Ninpo: it would be nice to write up your experience in a blog post
<Ninpo> mattip: I intend to, however I've more pressing things on my list atm. As soon as I get the opportunity I will
<mattip> cool, thanks
<cfbolz> arigato: quiz, why is this a useful commit: https://www.irccloud.com/pastebin/XfbzHS09/
<arigato> unsure
<arigato> this makes the builtin __import__ variable, but why is that always a good thing?
<cfbolz> no, it makes it *not* variable
<cfbolz> the del always removes everything in the dict
<cfbolz> so why do we need the second setdictvalue? because otherwise the lazy loading mixedmodule stuff breaks weirdly :-(
<cfbolz> (I mean, that's why we need the *first* setdictvalue)
<arigato> ah, there is already another __import__
<cfbolz> yes
<cfbolz> from __builtin__.__init__
<arigato> that's very strange indeed
<arigato> so I can get bad over-jitting if I replace "global x; x=something_new" with "global x; del x; x=something_new"?
<cfbolz> I suppose
<cfbolz> it will just never jit then, because of the ever changing versions, I think
xcm has quit [Remote host closed the connection]
<arigato> but then that's a (minor) bug, which if fixed would make the hack of https://www.irccloud.com/pastebin/XfbzHS09/ stop working
<cfbolz> arigato: should I add an internal interface instaed?
<arigato> guess so
xcm has joined #pypy
<cfbolz> ok
<cfbolz> my time is up for today, will continue later
mattip_ has joined #pypy
<mattip> cfbolz: there is a mixup of index and byteindex in the stopping condition of the iteratorobject.py for unicode objects
<mattip> in 637f18678c1c
<arigato> mattip: I think it's fine? w_seq._length is the length in characters
<mattip> ahh, right, then something else is screwed up with a newtext somewhere
<mattip> or somehow w_seq._length is getting set to the byte length
siddhesh has joined #pypy
<cfbolz> mattip: is pickle involved?
<mattip> no, it's somehow oefmt
<mattip> but newtext checks the value, so it must be something else
<cfbolz> mattip: which test it showing the problem?
<mattip> the intobject failures, but only after I fix something else
<mattip> I'll keep digging, it will turn up
jcea has joined #pypy
<cfbolz> OK
<mattip> the problem was in interpreter/error.py when using '%R' or '%S', it calculated the utf8 length
<mattip> ... and there used to be a test for untranslated space.newtext(s, lgt) to verify lgt, but I removed it to speed up tests
<arigato> mattip: if the test is written as "assert len(bytestring.decode('utf8')) == length" then it shouldn't have too much of an performance impact
<mattip> +1
<mattip> it used to go through rutf8, your suggestion is much better
<arigato> it can go into W_UnicodeObject.__init__, too
<arigato> right, I remember
<mattip> it actually was in W_UnicodeObject.__init__, removed in baef7e3e3ac0
siddhesh has quit [Ping timeout: 246 seconds]
Zaab1t has joined #pypy
Zaab1t has quit [Client Quit]
<kenaan> stian py3-bigint-to-int d84813084f47 /: Branch to experiement with making bigints into ints whenever they fit
<kenaan> stian py3-bigint-to-int 517a32bab8f7 /pypy/objspace/std/: Code and test for most ops
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<kenaan> stian py3-bigint-to-int daa9f9b2439b /pypy/objspace/std/longobject.py: More ops
<cfbolz> We should tell Stian to test his work properly from the start
* LarstiQ tries to complete stian with irssi and fails
Ai9zO5AP has quit [Ping timeout: 245 seconds]
<kenaan> stian py3-bigint-to-int 521850d02e44 /pypy/objspace/std/test/test_longobject.py: Add tests for more ops
siddhesh has joined #pypy
mattip_ has quit [Quit: Connection closed for inactivity]
<cfbolz> Cool :-)
<arigato> well, we should warn him though
<arigato> he's about to write a large patch out of which only a fraction is clearly beneficial
* arigato comments on issue #2888
<mattip> <spam>
<kenaan> mattip py3.6 395bf13f5d16 /pypy/interpreter/unicodehelper.py: merge default into branch
<kenaan> mattip py3.6 6bfc3b49077d /pypy/interpreter/: fix merge, tests
<kenaan> mattip py3.6 74fc16b2e4b5 /pypy/: make utf8_encode_utf_8 non-recursive, and pass surrogate pairs to error handler
<kenaan> mattip default 7693e4a720ad /pypy/objspace/std/unicodeobject.py: partially restore test removed in baef7e3e3ac0
<kenaan> mattip py3.6 3f907d46d82c /pypy/: merge heads
<kenaan> mattip py3.6 a2c4c9f78c7a /pypy/interpreter/error.py: use lenght in codepoints not utf8
<kenaan> mattip py3.6 393374a59e39 /pypy/objspace/std/test/test_intobject.py: fix test
<kenaan> mattip py3.6 51e9bde8332f /pypy/objspace/std/intobject.py: turn UnicodeError while converting to decimal into ValueError, correct message
<kenaan> mattip py3.6 813c99f810ac /pypy/interpreter/unicodehelper.py: collect surrogate pairs for error
<kenaan> mattip py3.6 c3304e7116ad /: merge default into branch
<kenaan> mattip py3.6 8fb002913c55 /pypy/interpreter/error.py: fix error exposed by 7693e4a720ad
<kenaan> mattip py3.6 21f7cebd010e /pypy/interpreter/unicodehelper.py: fix translation
<mattip> </spam>
<Ninpo> Is there a feed or something I can watch/be notified of updates to py3.6 branch?
<cfbolz> Ninpo: eh, there are a ton such updates every day
<Ninpo> I'll keep an eye on the nightly build dir then, if something builds happily there I can see what changed :)
<mattip> Ninpo: I would expect for the next while most of it will be cleanups to get tests to pass cleanly
<Ninpo> Nice :)
<cfbolz> Plus I hope to land the json stuff eventually
<mattip> the only big thing in the pipeline that I know about is some json improvement, but it will take a while
<Ninpo> ooh I'm working with json for my results. Would you be fixing how long it takes to serialise out to disk by any chance?
<cfbolz> Ninpo: no, only the deserializer for now, sorry
<Ninpo> no worries :)
<Ninpo> I'm working around that at the moment with a normal file write(json.dumps(payload, separators=(",", ":")))
<Ninpo> json.dump is sloooow for large files
<LarstiQ> oh, you're saying json.dump() is slower than file.write(json.dumps())?
<Ninpo> yes by a lot. Reading back over bugs.python it's because json.dump() writes "line by line"
<Ninpo> Actually thinking about it, I can't remember if I tried it with pypy
<Ninpo> Definitely sucked with cpython and there's a WONFIX on it
<Ninpo> WONTFIX*
<cfbolz> Pypy's json.dump(s) is probably not very fast either
<arigato> WONTFIX in cpython? no clue why
<Ninpo> Oh I meant to ask the other day and apologies if I am oversimplifying it, but would it be a lot of work for someone (say, me) to adapt this for CFFI so it runs better in pypy? https://github.com/PyMySQL/mysqlclient-python/blob/master/MySQLdb/_mysql.c
<arigato> google around for "mysql-cffi" first
<Ninpo> huh, found something, doesn't appear to have been touched for 6 years though
siddhesh has quit [Ping timeout: 245 seconds]
<arigato> ah, well at least it's a starting point
<Ninpo> ya
<Ninpo> Thanks for the tip :)
<gsnedders> Ninpo: do you happen to have the CPython json.dump bug to hand?
<Ninpo> I can search my history, one sec
<gsnedders> thx!
<fijal> :-(
<Ninpo> arigato: aww, looks like that mysql-cffi thing was intended but never done. no commits, no branches, just the initial fork
<Ninpo> Nothing done toward the cffi thing
<mjacob> now that default is merged directly from default into py3.6, we should close py3.5, right?
<kenaan> stian py3-bigint-to-int 4e3d4c68bcde /pypy/objspace/std/: Reduce this to int_mod and int_and ops for now.
_stian has joined #pypy
_stian has left #pypy [#pypy]
__stian has joined #pypy
<cfbolz> __stian: hey :-)
<ronan> huh, 1d688af446c2 prevents -A cpyext tests from running on CPython?!
<__stian> cfbolz: Hey, long time
<ronan> mjacob: yes, I guess, though we might want to leave it open in case we want to backport bug fixes
siddhesh has joined #pypy
<mjacob> ronan: shouldn’t we use the release branch for it?
<ronan> mjacob: yes, that makes more sense
<siddhesh> Hello, I'm looking to set up a buildbot slave on an aarch64 vm. It will run only the own and rpython builders now (I reckon these do not need a functional JIT) and once the arm64 port is complete, I'll add the JIT builder too. Who can I send the settings to add to the master config so that my slave can login? Thanks!
<siddhesh> I'll also send out a patch to add the remaining aarch64 slave and builder settings to the buildbot.
<cfbolz> siddhesh: talk to fijal and maybe mattip
<fijal> siddhesh: hey, I'm doing the arm64 port, but not the buildbot, ask mattip
Zaab1t has joined #pypy
<fijal> siddhesh: ok, I'll do it
<siddhesh> cfbolz, thanks
<fijal> siddhesh: I think it's a bit early to run a buildbot though (it'll mostly just fail)
<siddhesh> fijal, I was thinking of running it off trunk, not the WIP branch. Just to get that task out of the way for me.
<fijal> that works I guess
<fijal> let's setup a buildbot that will not run automatically
<siddhesh> fijal, OK, so only under the ForceScheduler; I'll update my patch.
<fijal> siddhesh: can we deal with it tomorrow or Wednesday though?
<siddhesh> Should I send you an email with the slavename/password?
<siddhesh> fijal, oh sure, that works for me.
<fijal> please, fijall@gmail.com
<siddhesh> No rush at all; thanks!
<mattip> siddhesh: would it be possible to set up a 32bit chroot build slave as well?
<siddhesh> mattip, I'll have to check if the CPU I have access to can do aarch32. If it can, I'll try to set one up.
<ronan> arigato: what's the point of spaceconfig["objspace.std.withspecialisedtuple"] = True in 1d688af446c2?
<ronan> it seems it's not required
<fijal> siddhesh: I think it's enough to set up 32bit chroot on arm64?
<siddhesh> fijal, Not all aarch64 cpus support the aarch32 instructions. I think only some of the stock cpus have that support.
<siddhesh> I believe the a53 and a72 have them. I'll just have to double check to see if the core I'm running on has the support. If we do then we can do this no problem.
<siddhesh> A bunch of the custom cores (falkor, thunderx2, etc.) don't support the 32-bit ISA at all.
<siddhesh> ok, it's a cortex-a72. I think I can set up a 32-bit chroot on it.
kanaka has joined #pypy
kanaka has quit [Changing host]
kanaka has joined #pypy
* siddhesh out for the day o/
siddhesh has quit [Remote host closed the connection]
<arigato> ronan: spaceconfig["objspace.std.withspecialisedtuple"] = True is required because by adding it a test was failing
<arigato> and it was a real failure
<arigato> in general it's a good idea to add it because it makes more kinds of tuples available for testing parts of tupleobject.py and sequenceobject.py
<ronan> well, it causes all -A tests to be skipped on CPython...
<arigato> "ah"
<arigato> sorry about that
<arigato> unsure what to do
<ronan> it's probably fixable, but test support code is a mess
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<cfbolz> Yes, hidehiko has also supervised the work on the RPython erlang that existed a while ago
marky1991 has joined #pypy
marky1991 has quit [Ping timeout: 255 seconds]
<ronan> pfff... cpyext test break if more than one space object is used
<mattip> ronan: I consider it somewhat a miracle that you can run -A tests on cpyext, but it is a very useful miracle
<mattip> and pretty amazing that you can test untranslated mixing C
Taggnostr has quit [Remote host closed the connection]
Taggnostr has joined #pypy
<fijal> mattip: I keep being amazed by the JIT backend tests too
Zaab1t has quit [Quit: bye bye friends]
Gremico has joined #pypy
<Gremico> I am using compile(tmpdir="tests") to try and have cffi compile the code into a folder, however when i do this i get a file not found error. Am i missing something?
<Gremico> I found a solution by specifying a relative path in my set_source.
fling has quit [Ping timeout: 258 seconds]
lritter has quit [Ping timeout: 268 seconds]
<Ninpo> How do I fix cffi putting compiled libs into project_root/src/lib.so instead of project_root/src/package_name/lib.so ?
<arigato> Ninpo: use ffibuilder.set_source('package_name.lib', ...)
<Ninpo> oh in the script I import in setup.py?
<arigato> wherever you use ffi{builder}.set_source() right now?
<arigato> I hope you're not using ffi.verify() because that's deprecated since ages
<Ninpo> bang thanks arigato
<Ninpo> No I'm not
<Ninpo> I meant in the script I import into setup.py :)
<Ninpo> and yes, that was the place to do it
<Ninpo> Thank you :)
<arigato> welcome
agronholm has quit [Ping timeout: 240 seconds]
agronholm has joined #pypy
<kenaan> cfbolz py3.6 f87194e4cc02 /pypy/module/pypyjit/test_pypy_c/test_globals.py: another dead getfield_gc_r
<kenaan> cfbolz py3.6 b7b3ef736a84 /pypy/: make sure __import__ is not stored in a celldict cell, otherwise local imports are really slow
kipras has joined #pypy
glyph has quit [Quit: End of line.]
glyph has joined #pypy
fling has joined #pypy
fling is now known as Guest482
ronan has quit [Ping timeout: 250 seconds]
ronan has joined #pypy
dvxr has joined #pypy
dvxr has quit [Quit: Page closed]