cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | Matti: I made a bit of progress, the tests now only segfault towards the end
f4at has quit [Ping timeout: 246 seconds]
f4at has joined #pypy
<arigato> kurisu: hi
Guest96 has joined #pypy
<fijal> oh cool, now python comes with a TopoligicalSort of a graph as a builtin function
<fijal> wat
<arigato> google finds reference but never the docs
Guest96 has quit [Quit: Textual IRC Client: www.textualapp.com]
<arigato> ah, graphlib.TopologicalSorter
<fijal> seems like Raymond is having fun with "statistics" module too
<arigato> it's an addition to the standard library that makes sense to me. far more people need parallel topological sorting than, say, call C functions (note the mandatory ":-)" here)
<cfbolz> I merged a minimal version or record-known-result
<cfbolz> just checked, I've been working on this on and off since 2019 :-(
<cfbolz> some significant bits by Lin Cheng from Cornell in there too
<cfbolz> mattip: in the process I removed a total of 2 open branches ;-)
<arigato> so ``jit.record_exact_value(res < end, True)`` is the way to write an assert that the JITted code will assume passes?
<cfbolz> arigato: yes
<cfbolz> arigato: at least it can also be used for that
<arigato> cool
<cfbolz> originally it was actually used in an implementation that does value profiling on map fields and finds out that eg some field is always w_None
<cfbolz> arigato: there's a bunch of useful ideas for both, but I need to do those carefully
reneeontheweb has joined #pypy
<cfbolz> arigato: rbigint has a number of nice use cases for example
<arigato> what kind of problems are there?
<cfbolz> arigato: if you get it wrong it can really crash ;-)
<cfbolz> I got some index reasoning wrong on in unicodeobject.py for example
<cfbolz> I mean it's the same for elidable, right. but we have much more practice with that
greedom has joined #pypy
<fijal> cfbolz: can you use it for something like jit.record_exact_value(uni_str.index('foo-bar-baz'))?
<cfbolz> hm?
<cfbolz> I wanted to be able to use it to say that the byteindex that w_uni._utf8.find(w_otheruni._utf8) produces can be used to index into the unicode string
<cfbolz> but it turns out to be a mess
<cfbolz> and I need to do that super carefully
<cfbolz> fijal: is that what you mean?
<fijal> yeah
<cfbolz> fijal: yes, it's expressive enough
<cfbolz> just needs care ;-)
<fijal> yeah....
<cfbolz> All the static typing languages in rpython (the many hundreds) can also benefit, because you can say 'the types tell me that...' in the interpreter
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
jacob22 has quit [Quit: Konversation terminated!]
jacob22 has joined #pypy
f4at has quit [Ping timeout: 246 seconds]
f4at has joined #pypy
<fijal> cfbolz: ok, so I get the basics working with the changing of R+W to R+_X
<cfbolz> Impressive
<fijal> it's just obscure that you have to do it via vm_xxx functions
<fijal> but I wrote "a jit" in 20 lines of C
<fijal> did not get me any closer to understanding wtf is libffi doing I think
<fijal> ok, how do I package it into pypy....
<fijal> cfbolz: one of the finds is that we don't need to maintain our own freelist - seems like libffi does that on platforms where it makes sense
<fijal> this is dripping with sarcasm....
<cfbolz> Eh
<arigato> that comment may have been true 50 years ago
<arigato> ok maybe even 35!
<fijal> it's largely THE LAST way to do things
<fijal> this is scary....
<fijal> ok, I really don't get why apple advises people to do it the way they do
<arigato> oh yes, it's a good idea to return EAGAIN after the 4096's call to pthread_create(). No code will ever dynamically create and stop threads, ever
<fijal> bleh
<fijal> arigato: I mean, it's a HACK
<fijal> which probably should be use sparingly to start with :)
<fijal> I'm ok with it having weird static limitations
<fijal> arigato: ok, so those are 2 different ways how you can do JIT
<fijal> I'm kinda inclined to say that the second way (apple sanctioned way) is way worse
<arigato> why?
<fijal> because you have a global setting saying "now all the MAP_JIT pages are writable" or "now all the MAP_JIT pages are executable"
<fijal> *per thread*
<fijal> so one, if you happen to have two threads, it's a security issue (maybe not a big one)
<fijal> but two, we need to be very careful about getting the right set of circumstances, because if stuff can run in between that's bad?
<fijal> on the plus side, we largely can reuse the existing infrastructure, which is nice
<fijal> but yeah, the global setting seems scary
<fijal> yes, what about it?
<arigato> I've been explaining in detail there how to make sure nothing can run inbetween, to an OP that was mostly not listening to me
<arigato> now you're doing the same thing :-)
<fijal> heh
<fijal> do I have to read all his patches to know what are you talking about?
<arigato> no
<fijal> ok?
<fijal> I *know* nothing should run in between emitting the code
<fijal> it's still a reasonably inelegant solution?
<arigato> we already use @rgil.no_release_gil, which guarantees nothing can run
<fijal> right
<fijal> so you reckon it's fine to just have a context manager here?
<fijal> maybe we can have one wrapper that does both? @assembler_writer on a function
<arigato> as you feel like, but I'd go with just writing a few try:finally: and be done
<fijal> there is also sys_icache_invalidate
<arigato> call disable_protection() and reenable_protection(), and do whever you need to do inside
<arigato> maybe reenable_protection(address_range_that_was_modified)
<fijal> yeah
<arigato> or well, the sys_icache_invalidate can be done elsewhere
<arigato> we already need to do that for all non-x86 platforms
<arigato> I think in CodeBuf when we are done
<fijal> can you point me to one of those?
<arigato> clear_cache, in jit/backend/arm/codebuilder.py
<arigato> same in jit/backend/aarch64/codebuilder.py
<fijal> yeah
reneeontheweb has quit [Quit: Client closed]
<fijal> is there a way to see what commits modified a file?
<fijal> or do I have to go via blame route?
<fijal> arigato: ok, I have fun stuff now, I think....
<fijal> so gcref tracing patching is a bit dodgy
<fijal> yes, we need a plan for that - we have a gc table in the beginning of the machine code that either needs to live somewhere else or we need to make sure it's not being written to
<fijal> (or we disable and enable it per trace)
<fijal> I think the sanest way would be to call minor collect each time we write a GC table?
<fijal> I don't know
<fijal> right and that gets complex because nesting
<fijal> pom pom pom
zaytsev has quit [Quit: WeeChat 2.7.1]
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
<arigato> fijal: so it's put there because we want it to end up at a known offset from the machine code, so that machine code can load it with a specific relative instruction
<arigato> it's LDR_r_literal() in aarch64
<antocuni> fijal: it's probably late, but hg log /path/to/file shows only the commits which modified that file
Dejan has quit [Quit: Leaving]
greedom has quit [Remote host closed the connection]
tos9_ has joined #pypy
tos9_ is now known as Julian
Julian has quit [Quit: leaving]
Heston has joined #pypy
<Heston> hi guys, is there a way to enable cache for pypy3, like a .pyc file for cpython? And why does pypy have a flag to disable .pyc if pypy is generating machine code and not bytecode?