<j4at>
^ that's incorrect I used d.append which doesn't multiply the elements by 2
<j4at>
it's actually slower than []*n
* cfbolz
does admin now
<j4at>
I tried the nightly build with objectlist and got same results 18 secs/36 secs
<j4at>
for int list comprehension is faster 1.6 secs /1.3 secs
Atque has quit [Ping timeout: 268 seconds]
j4at has quit [Ping timeout: 255 seconds]
j4at has joined #pypy
<j4at>
The problem in the jit is my guess I tried more expensive int functions and mine is always faster.
j4at has quit [Read error: Connection reset by peer]
j4at has joined #pypy
<j4at>
ops was using the older build. in the nightly version int lists list comprehension is always same or faster than map. But that doesn't mean there is no problems because int list comprehension in the nightly build is as fast as map in the old build. which is not even optimised for this specific task. for object lists map is always x2 faster.
j4at has quit []
j4at has joined #pypy
<j4at>
Well using an actual int list instead of range is slower using list comprehension https://codeshare.io/qP9D8x
j4at has quit []
Atque has joined #pypy
jcea has joined #pypy
reneeontheweb has joined #pypy
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
reneeontheweb has quit [Quit: Client closed]
j4at has joined #pypy
j4at has quit [Read error: Connection reset by peer]
jcea has quit [Ping timeout: 260 seconds]
j4at has joined #pypy
<j4at>
cfbolz: After thinking about it. Mine is not really safe, in case of exceptions or mutable object getting changed(it's still same speed with tuples tho) That's maybe why the object list is a lot slower because the jit doesn't know what *2 does. Closed the issue.
j4at has quit []
Atque has quit [Remote host closed the connection]
<mattip>
how does pyenv pull it in, does it use our tarball or some other package?
<hexology>
yep, it says x86_64 but uname says arm64
<hexology>
good question about pyenv. presumably the tarball but i'm not sure
<hexology>
is the arm64/m1 build process the same? if so, it should be trivial to update the homebrew formula accordingly
<mattip>
yes, it is all the same
<hexology>
i'm less confident about pyenv... i just took a look at the source code for pyenv-install and python-build, but it's all a giant bash script
<hexology>
would take a while to figure out where anything is
<mattip>
:shrug:
<hexology>
maybe if you post this news in their issue tracker a maintainer will be able to quickly update it
<mattip>
probably would want to wait for an official release, maybe in a month or two
<hexology>
yeah they don't support master/head/trunk releases anyway
<hexology>
that's definitely beyond my knowledge i'm afraid
<mattip>
ok
<hexology>
is that even useful? unless it bundles idle etc like the cpython installer does. i guess it can't hurt to have, but i wouldn't expect high download stats for it either.
<hexology>
i suspect that most pypy installations on macos are either docker, pyenv, homebrew, or some less popular package manager like nix or macports
<mattip>
dunno. we get very little feedback about what is useful and what is not
<hexology>
has pypy received any interest/feedback from industry recently? i'd sooner expect that something like an official pypy docker base image would be more beneficial for industry adoption
<hexology>
where is the section w/ installation instructions?
<hexology>
i'd echo the support for keeping macports & homebrew up-to-date, as well as binary signing, and my own suggestion above for an official docker base image
<mattip>
There are actually two documentation web sites, the Homebrew link in the download instructions is at
<hexology>
i guess it makes sense, nowadays a lot of binary wheels for scientific packages are available on pypi, but perhaps not with arm64 support
<hexology>
was binary singing ever taken care of? i agree w/ the poster who suggested that people would be happy to contribute towards the $100 fee
<mattip>
it is the easiest way to get binary wheels for PyPy, since they rebuild _everything_ from source
<mattip>
conda-forge provides a one-point-of-distribution way to build the packages, as long as the builds succeed
<hexology>
conda is quite a heroic effort, it's a shame their reputation is so mixed (perhaps because their parent company doesn't do a good job of communication)
<hexology>
and conda-forge is a bit weird because it's hard to know who is actually involved in or backing the project
<hexology>
the website uses git/github and the dev docs use hg/heptapod? that's interesting
<mattip>
as for pypy;s version control: the main project uses mercurial
<mattip>
but some things are easier on git, like github pages: heptapod (the friendly gitlab fork that supports mercurial) does not have anything similar
<mattip>
as for binary signing: the problem is not the $100, it is finding someone to create the package to be signed
<mattip>
can we just sign a tarball, or does it need to be a pkg file
<mgorny>
you should really be recommending Gentoo ;-)
* mgorny
hides
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
<hexology>
mattip: i think the issue is the compiled executable itself