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
marky1991 has joined #pypy
jcea has quit [Ping timeout: 245 seconds]
isuruf53 has joined #pypy
isuruf53 has left #pypy [#pypy]
isuruf has joined #pypy
marky1991 has quit [Remote host closed the connection]
<isuruf> After building pypy, how do I tell it to generate `pyc` and `pickle` files for the standard library
marky1991 has joined #pypy
DRMacIver has quit [Read error: Connection reset by peer]
DRMacIver has joined #pypy
jcea has joined #pypy
CrazyPython has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
CrazyPython has joined #pypy
jcea has quit [Quit: jcea]
CrazyPython has quit [Read error: Connection reset by peer]
marky1991 has quit [Read error: Connection reset by peer]
marky1991 has joined #pypy
CrazyPython has joined #pypy
CrazyPython has quit [Remote host closed the connection]
andi- has quit [Remote host closed the connection]
andi- has joined #pypy
oberstet has joined #pypy
hotpot33 has quit [Remote host closed the connection]
hotpot33 has joined #pypy
<mattip> isuruf: you should have a directory called lib-python/X where X is 2.7 on default for python2.7, and 3 on py3.6 for python 3.6
<mattip> those are the stdlib files
<isuruf> mattip, yes, but the pyc files are not generated
<isuruf> For packaging pypy in conda, I'd like to generate the pyc files, lib2to3 grammar pickle files, etc
<mattip> isuruf: there is "pypy -mcompileall"
dddddd has quit [Ping timeout: 260 seconds]
<isuruf> Thanks mattip
<isuruf> That generates the pyc files
<isuruf> cpython also generates some pickle files like `lib2to3/Grammar3.7.3.final.0.pickle`
<isuruf> Is there a similar command for generating these pickle files
<mattip> cpython does this for you?
<isuruf> Yes
<isuruf> `pypy3 -mcompileall` doesn't do it recursively
<isuruf> `.pyc` files are generated in `lib-python/3/`, but not in `lib-python/3/lib2to3`
<mattip> the best would be to find where cpython does this and copy that
* mattip grepping around cpython sources
<isuruf> Maybe it's because we are running `--pgo`
<isuruf> `-m test --pgo-extended`
<mattip> the command in CPython seems to be something like
<mattip> compileall.py -f -x "bad_coding|badsyntax|site-packages|py2_|lib2to3/tests|venv/scripts"
<mattip> -x excludes things
<mattip> , -f forces recompile
<isuruf> Thanks. That still doesn't generate the pickle files.
<isuruf> If I run `pypy3 -m test --pgo -j 8`, it does
<isuruf> even though that command itself fails
<mattip> that must run a test that imports something that builds the pickles
<isuruf> Yes
<isuruf> Is it normal for 23 tests to fail when I run the tests?
<mattip> probably http://buildbot.pypy.org/summary?branch=py3.6 shows a bunch of lib-python failures
<mattip> About the pickles: you might want to ask somewhere where more people are awake. This is a general python packaging question, not pypy specific
<isuruf> Agree
<mattip> or you could clean out the file, touch it to create an empty one, chmod to a-w, and see what test fails
<mattip> what *new* test fails
<isuruf> Clean out which file?
<mattip> lib2to3/Grammar3.7.3.final.0.pickle
[Arfrever] has quit [Quit: leaving]
<isuruf> I ran the tests on a clean installation. I can run the tests again to see if new tests fail
<mattip> the automatic change detection in buildbot didn't work, so I'm running latest nightly build on default by hand
[Arfrever] has joined #pypy
<mattip> hgpoller is polling the old repo
jvesely has joined #pypy
jvesely has quit [Client Quit]
jvesely has joined #pypy
jvesely has quit [Remote host closed the connection]
jvesely has joined #pypy
jvesely has quit [Client Quit]
jvesely has joined #pypy
jvesely has quit [Remote host closed the connection]
jvesely has joined #pypy
<cfbolz> mattip: but super cool that builds just work when you start them manually :-)
<mattip> it will be a bit of work to redo bbhook to get commits reported here and in mail
isuruf has quit [Remote host closed the connection]
<mattip> I think we should drop the mail reporting, people who want mails can subscribe to the repo, no?
<mattip> ... and if we have mail, do we really need IRC?
<mattip> maybe something to discuss at the sprint
<cfbolz> mattip: unfortunately I am one of the people who really love the mails 😅
<kenaan> mattip buildbot 22046f04c0a4 /: convert to heptapod
<mattip> ^^^ that was from the bitbucket repo, just checking it still works
<mattip> cfbolz: you can go to https://foss.heptapod.net/profile/emails and set a notification email,
<mattip> then go to https://foss.heptapod.net/pypy and at the top set "Global" preferences to "Watch"
<cfbolz> mattip: I don't think that includes commits though?
<mattip> cfbolz: dunno. Let's see what happens: I turned it on for myself
jvesely has quit [Read error: Connection reset by peer]
blueyed has quit [Ping timeout: 248 seconds]
blueyed has joined #pypy
<mattip> virtualenv is not copying the include directory, and not even making a symlink to it
<mattip> virtualenv==20.0.3
<mattip> gracinet: (for the logs) I started importing pypy/externals
oberstet_ has joined #pypy
oberstet has quit [Read error: Connection reset by peer]
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
__imp__ has joined #pypy
<__imp__> just to let you know, there is a small error in a code cffi documentation around overview subsection
<__imp__> assert str(pi_approximation).startswith("3.")
<__imp__> should read
<__imp__> assert str(approx).startswith("3.")
<__imp__> same 3 lines below.
<__imp__> just, making reference to an unexistent variable.
<arigato> __imp__: thanks!
<__imp__> funny thing: arigato says thanks
<arigato> :-)
<kenaan> arigo cffi/cffi 976b4a8b1c6b /doc/source/overview.rst: typo in overview code (thanks __imp__)
<__imp__> (assumming arigato is japanese word)
<__imp__> i'm still a bit confused between inline and out-line modes in cffi
<__imp__> could not understande the difference.
<__imp__> inline is when we declare C variables in python?
<__imp__> using ffi.new()?
<__imp__> and outline is when only calls to functions is done?
<__imp__> imp: hello me!
<arigato> (arigato is the japanese word but also a pun on my real username, which is "arigo")
<__imp__> imp is also a pun with my real name. Each letter is the initial of name and surnames.
<arigato> :-)
<arigato> inline vs out-of-line: in inline mode you call the cdef() from the same program
<arigato> so parsing the C-like code you pass in the cdef() occurs at runtime every time you execute your program
<arigato> in out-of-line mode, however, you move it to a separate script which you run once, and then it's done "more carefully" by invoking the real C compiler to check and fix your declarations (which can contain literally "...;" to mean "more stuff here")
<__imp__> right.
<arigato> (at least in the "out-of-line API mode"; there's also "out-of-line ABI mode" where the cdef() is in a separate script but still no C compiler is invoked, but that's rarely useful)
<__imp__> arigato: not being a moron, in overview documentation, the Simple Example (ABI Level, Inline).
<__imp__> it uses cdef to declare the function prototype
<arigato> mattip: in bitbucket, "Branch permissions", I think we can add a permissions "can't write" to the branch pattern "*", which should then match all branches
<__imp__> The same happens in Purely for performance (API Level, out-of-line)
<__imp__> where cdef is used in same way.
<arigato> yes
<__imp__> I still do not understand.
<__imp__> one says inline the other says outline.
<arigato> the difference is that one example has everything in one script, and the other has it in two scripts
<__imp__> hmm
<__imp__> oook
<__imp__> put in external file allows it to do more checks .
<arigato> yes
<__imp__> thanks.
<arigato> in fact, the "purely for performance" example shows ffibuilder.set_source()
<arigato> where you put real C code
<__imp__> yes.
<__imp__> my c code will be outside.
<arigato> then set_source() contains just a #include
<__imp__> in a full library that I want to make visible from python and write a simple wrapper to be available in python.
<arigato> like the previous example
<__imp__> thanks.
<__imp__> It's related to boltzmann machines.
<arigato> if you already have a compiled .so/.dll file, then it's the example "API Mode, calling the C standard library"
<arigato> whose title is maybe a bit confusing...
<__imp__> no. isn't a .so is a weirdo scientific C code
<mattip> arigato: will try. Don't forget to push to https://foss.heptapod.net/pypy/cffi (as well as)|(instead of) bitbucket
<arigato> mattip: yes
<arigato> mattip: I just pushed to bitbucket to try if it still works
<mattip> ok
<mattip> the transition to the new web-site should happen later today, so I will do one "everything is different" blog post if it succeeds
<arigato> (yes, a branch permission on the pattern ``*`` seems to work)
<kenaan> arigo cffi/cffi af4aa63d5fc8 /README.md: Last change on bitbucket
<mattip> if you are already there, could you do it for pypy/pypy as well?
<arigato> OK
<arigato> done
<__imp__> Is there an equivalent to CFFI to Fortran?
<__imp__> (otherwise I can easily rewrite bad fortran code in C ;-)
<arigato> not that I know of
<mattip> f2py wraps fortran source code into c-extension modules, which is a little different
<mattip> it is part of numpy
<mattip> cfbolz: the warmup change is 8fcba04d307f? Benchmarks reports must not be heavily slanted toward warmup time
<mattip> https://speed.pypy.org/changes/ (then click on benchmarker) is a bit meh
<__imp__> I'd like the embedding, is there any efforts to build a full binary from python code and dependencies?
<mattip> like nuitka?
<__imp__> mattip: dunno!
<__imp__> let me check
<__imp__> yes. Exactly!
<__imp__> wow. it's even faster.. than native Python code. I was expecting just some tricky bundle with the interpreter and libs.
<mattip> not as fast as PyPy or Numba for most things, but it is good for what it does
<__imp__> does pypy already supports numpy and the scientific stack?
<mattip> support - yes. It is not accelerated in any way, since we have to go through a C-API emulation layer
i9zO5AP has quit [Ping timeout: 265 seconds]
tsaka__ has joined #pypy
__imp__ has quit [Quit: WeeChat 2.3]
<arigato> cfbolz: re list resizing: maybe related to the fact that we resize also on pop() if there are savings? In the C# List<T> type for example, it never resizes down and you have to be explicit about it
<cfbolz> mattip: that's fine, most benchmarks cut off the first few iterations
<cfbolz> arigato: yes, I think so
<cfbolz> But anyway, in this case a linked list is perfectly reasonable
<arigato> yes
<Dejan> byebye bitbucket
<cfbolz> arigato: sadly I discovered that 25% of traced (pre optimization) operations are manipulating the value stack
<cfbolz> Of inlined frames
<arigato> not too surprizing
<mattip> arigato: if heptapod/pypy/cffi looks good, you may want to make it public
<cfbolz> arigato: it's partly that we use nice abstractions. Eg binary ops write the valuestackdepth 3 times (two pops, one push)
<cfbolz> Could be 1 instead
<arigato> mattip: ah thanks
<cfbolz> Will try to see whether doing it the ugly way helps
<arigato> cfbolz: note that in theory, a more aggressive translation-time optimizer could be run before making the jitcodes
<cfbolz> arigato: yes, I've been wondering about that too
<cfbolz> arigato: but removing setfields is kind of hard
<arigato> ah, I see
<arigato> yes, probably better to have an explicit interface different from PyFrame.push() and pop()
CrazyPython has joined #pypy
tsaka__ has quit [Ping timeout: 268 seconds]
tsaka__ has joined #pypy
tsaka__ has quit [Ping timeout: 268 seconds]
tsaka__ has joined #pypy
CrazyPython has quit [Ping timeout: 240 seconds]
tsaka__ has quit [Ping timeout: 260 seconds]
tsaka__ has joined #pypy
<Dejan> awesome
<ammar2> hmm, looks like a tikz without horrible syntax
<Dejan> I only know about TikZ (never used in my life), but I would say that TikZ can do much more
<Dejan> I think this project is focused on cloud arch diagrams
<mattip> CFFI extra tests are failing on default because we now install virtualenv>20, pip>20
<mattip> they no longer have hacks for PyPy, which is in and of itself a good thing,
<mattip> but now we need to more closely follow what CPython does in distutils
<mattip> which lead to this debug session, https://github.com/pypa/virtualenv/issues/1604
<mattip> and more than a little frustration
<mattip> where is cpython setting sys.real_prefix in a virtualenv?
<mattip> ahh, its if you activate a virtualenv
Dejan has quit [Quit: Leaving]
tsaka__ has quit [Ping timeout: 260 seconds]
Rhy0lite has joined #pypy
dddddd has joined #pypy
Dejan has joined #pypy
Smigwell has joined #pypy
bitbit has joined #pypy
<bitbit> Hi. is it possible to to run python3 code with pypy-stm?
flok has left #pypy [#pypy]
<Dejan> I think stm is a more/less dead project
<Dejan> some please correct me if i am wrong
<cfbolz> bitbit: not without work
<bitbit> oh thats too bad. I really wanted to try to run python on all cores (without having to write specialized code for multiprocessing)
<simpson> Oh, that's easier. Shard your work and use GNU Parallel. It's not fancy or pretty, but it'll put Python on every core.
<bitbit> simpson: !! I do recall now seeing some example using that
<Dejan> multiprocessing is simple, IMHO
<Dejan> even for someone like me who is more familiar with C/C++/D/Java than Python
<bitbit> thanks!
imp has quit [Quit: WeeChat 2.6]
marky1991 has quit [Ping timeout: 268 seconds]
marky1991 has joined #pypy
jvesely has joined #pypy
tsaka__ has joined #pypy
marky1991 has quit [Ping timeout: 268 seconds]
sp478477 has joined #pypy
marky1991 has joined #pypy
sp478477 has quit [Ping timeout: 240 seconds]
sp478477 has joined #pypy
<mattip> marmoute: I started an import about 8 hours ago and it isn't finished, can someone take a look?
tsaka__ has quit [Ping timeout: 272 seconds]
tsaka__ has joined #pypy
tsaka__ has quit [Ping timeout: 246 seconds]
tsaka__ has joined #pypy
i9zO5AP has joined #pypy
<marmoute> mattip: I'll pass the message to gracinet
<mattip> +1
tsaka__ has quit [Ping timeout: 272 seconds]
adamholmberg has joined #pypy
sp478477 has quit [Read error: Connection reset by peer]
<mattip> Draft blog post about the changes, comments welcome (even typo-corrections)
tsaka__ has joined #pypy
CrazyPython has joined #pypy
Ai9zO5AP has joined #pypy
i9zO5AP has quit [Ping timeout: 268 seconds]
bbot2 has quit [Quit: buildmaster reconfigured: bot disconnecting]
bbot2 has joined #pypy
marky1991 has quit [Ping timeout: 265 seconds]
adamholmberg has quit [Remote host closed the connection]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/5711 [ronan: force build, StringIO-perf]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/6787 [ronan: force build, StringIO-perf]
<bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8004 [ronan: force build, StringIO-perf]
<bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-32/builds/6970 [ronan: force build, StringIO-perf]
YannickJadoul has joined #pypy
adamholmberg has joined #pypy
adamholmberg has quit [Remote host closed the connection]
<bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8004 [ronan: force build, StringIO-perf]
<bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-32/builds/6970 [ronan: force build, StringIO-perf]
<cfbolz> mattip: reads really well! Small typo: an way -> a way
<mattip> fixing
Rhy0lite has quit [Quit: Leaving]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/6787 [ronan: force build, StringIO-perf]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/5711 [ronan: force build, StringIO-perf]
<mattip> hg heads default --template="{rev}\n" reports more than one head on default
<mattip> it seems pull request branches off default are counted as heads on default
<mattip> what would be the best way to get rid of them?
<mattip> (this causes the buildbot's mechanism for only triggering builds when needed to fail)
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
marky1991 has quit [Changing host]
marky1991 has joined #pypy
gracinet has joined #pypy
<arigato> "ah"
<arigato> I think we should install everywhere the evolve extension
<arigato> these alternate heads are on the same branch but different topic
<arigato> if you install hg-evolve then "hg up default" is not ambiguous again
<mattip> yes, but `hg heads default` shows topic branches, even with the extension
<arigato> ah
<mattip> so we would need to rewrite the buildbot HgPoller class to do `hg up; hg id -n` instead
<arigato> hum
<mattip> even on HEAD the buildbot code does `hg head default`
oberstet_ has quit [Remote host closed the connection]
<arigato> note that "hg log -r default" only shows one, so maybe: hg log -r default --template="{rev}\n"
<mattip> cool
oberstet has joined #pypy
<arigato> or hg log -r "branch(default)" maybe
<arigato> uh no
<mattip> `hg log -r 'heads(public() and branch(default)` says gracinet on mattermost
<arigato> ah yes, there should be only one public head
<arigato> fwiw I'm using a custom log format which clearly says "draft", so that's clear for me
<mattip> well, in theory that works. In practice it spits out closed branches
<arigato> ah
<arigato> I think "hg log -r default" should be reliable, because it should give the same rev as "hg up default" would
<arigato> at least, it should be if evolve is installed
marky1991 has quit [Ping timeout: 265 seconds]
<arigato> I'm kind of sure that at some point someone will mistakenly update to a draft of "default" and write changes to it and push the result
<arigato> thus not realizing he's pushing a random pull request
oberstet_ has joined #pypy
<arigato> the situation could be improved if "hg log" had a reasonable output by default, but it doesn't
oberstet has quit [Read error: Connection reset by peer]
<mattip> hg up default can give a topic branch without evolve?
<arigato> as far as I know, yes
<arigato> in fact, without evolve, "hg push" will never work
<arigato> I think?
<mattip> heh, the buildbot master does not have evolve, and `hg heads default` behaves well
<mattip> the problem is somewhere else for the buildbot hgpoller
<mattip> I didn't change the source url to heptapod till today, so it was polling the bitbucket instance
<arigato> well, "hg heads default" doesn't behave well: I bet the buildbot master just picks the first listed head
<marmoute> hg up default can give a topic branch without topic.
<arigato> so again if someone makes a PR then it's possible that the next nightly run will be on that PR, randomly
<mattip> so then I changed the README on bitbucket/pypy/pypy, hgpoller pulled the repo and got a head, then I changed the URL, it pulled and got another head. Truly two heads
<arigato> we need to carefully reconsider various things because this "all-PR-are-part-of-the-same-repo" is bound to create mistakes
<arigato> ...ah
<arigato> right, makes sense. need to "hg strip" that extra pointless head
<marmoute> We are planning to ship a "fix" for this shortly.
<mattip> someone a few days ago told me I could close it instead :)
<mattip> cd ../..
<mattip> marmoute: fix for which part?
marky1991 has joined #pypy
CrazyPython has quit [Remote host closed the connection]
CrazyPython has joined #pypy
<marmoute> mattip: things without topic enabled pulling changeset with topic (And getting confused by it)
CrazyPython has quit [Remote host closed the connection]
CrazyPython has joined #pypy
<mattip> right. So we are caught: if we enable topics in the HgPoller, we need to change the buildbot code, and if we don't we could end up building the wrong commit
CrazyPython has quit [Remote host closed the connection]
<mattip> no, sorry, brain fart. The buildbot only triggers a build, the buildslaves are the ones who pull, update, and build
CrazyPython has joined #pypy
CrazyPython has quit [Remote host closed the connection]
<mattip> so we need all the slaves to install evolve :(
CrazyPython has joined #pypy
<marmoute> mattip: What I am saying is that soon™, your hgpoller will simply not get the topic changesets, so you won't need to upgrade it.
<mattip> cool
oberstet_ has quit [Remote host closed the connection]
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
CrazyPython has quit [Ping timeout: 268 seconds]
<gracinet> mattip: but do you give the buildslaves the exact changeset hash to build ?
<mattip> usually (99.9%) we just give them a branch
<mattip> they pull and hg up
<gracinet> hg on the buildslaves look to be fairly recent (4.8, 5.2.1)
marky1991 has quit [Remote host closed the connection]
<mattip> depends, each slave is run by different people
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
<gracinet> looking at http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8004, I don't see where the pull/update happens
<gracinet> there's an update step but all it doesn is actually purge and log
<mattip> look again, in the middle
<mattip> hg --verbose pull https://foss.heptapod.net/pypy/pypy/
<mattip> then later
<mattip> hg --verbose update --clean --rev StringIO-perf
<gracinet> yes got it, it's a been drowned in the purging
<mattip> you never know when an overly verbose log will come in handy
<gracinet> I agree :-)
<mattip> gracinet: any news on the importers? at one repo per day we will be at this for a while
<gracinet> didn't check that yet
<gracinet> yes, it's annoying
<mattip> https://foss.heptapod.net/pypy/externals/import is still spinning, 13 hours later
<gracinet> for externals: "error applying bundle"
<mattip> ahh. So why does the UI show a spinner?
<gracinet> I don't know, it should in theory stop and at worst display an empty repo (that's what I often get) but not there
<gracinet> I'm gonna retry it and monitor the logs, and if needed I'll disable Bitbucket's clone bundle
<gracinet> don't move…
<mattip> gracinet: that repo is a bunch of binary blobs, with really no history. I can recreate it from zero if it is a problem
<gracinet> let's see what happens now first
<mattip> but I don't mind being your beta tester
<mattip> well, except when it's after midnight
* mattip zzz
<gracinet> I don't have access to externals
YannickJadoul has quit [Quit: Leaving]
<gracinet> ok we'll see tomorrow, but I'll be out of touch in the morning
<mattip> ??
<gracinet> though u were gone
<gracinet> I don't have it in my import list
<mattip> it showed up for me when I impersonated the importer ...
<gracinet> but that was with your bitbucket account
<mattip> when I look at the permissions for pypy/pypy and the permissions for pypy/externals, they seem the same
<mattip> on bitbucket
<gracinet> I've deactivated clonebundles, if you relaunch it, it could be better
<gracinet> or tomorrow afternoon if you prefer
<mattip> launched
<gracinet> initial pull is ok
<mattip> and done
<gracinet> yup
<gracinet> Bitbucket is serving corrupted clone bundls
<gracinet> that was the same with extradocs
<gracinet> I think I'm gonna leave the param to disable them in there
<mattip> ok, but the gui should indicate the process died, so there are at least two bugs
adamholmberg has joined #pypy
<gracinet> mattip, I agree, don't know when I can fix that, though (there's a pile of other stuff, including the webhook thing)
<mattip> no problem. I will leave some archival repos to be imported later
<mattip> we still have 100 days till the deadline
* mattip *really* zzz now
<gracinet> ok mattip, thanks for your patience and talk to you tomorrow
jcea has joined #pypy
Smigwell has left #pypy [#pypy]
Ai9zO5AP has quit [Quit: WeeChat 2.5]
rich has joined #pypy
rich has quit [Client Quit]
planrich has joined #pypy
planrich has quit [Client Quit]
plan_rich has joined #pypy
<plan_rich> well, planrich is the name of the account on heptapod...
gracinet has quit [Ping timeout: 272 seconds]