greedom has quit [Remote host closed the connection]
epony has quit [Ping timeout: 240 seconds]
lritter has quit [Ping timeout: 250 seconds]
epony has joined #pypy
the_drow has joined #pypy
njs has left #pypy [Leaving]
the_drow has quit [Quit: Client limit exceeded: 20000]
Atque has joined #pypy
Atque has quit [Quit: ...]
Atque has joined #pypy
<Cheery>
ok. By adding rules I can adjust what things are duals and what are not.
<Cheery>
It's not ideal and means I eventually succumb further into having a logic programming implementation in my runtime.
<Cheery>
heck it's probably more useful than the language I'm implementing.
<Cheery>
main (↓a) (→ a)
<Cheery>
defines a program entry point that immediately quits.
<Cheery>
the (↓a) sends message to say everything went nice.
<Cheery>
the (→ a) terminates the expression and sends unit message.
<Cheery>
name4 (c;z) (x ⊓ y → c) x=z ⊓ y=z
<Cheery>
here we got (x ⊓ y → c) x=z ⊓ y=z which delivers a choice, that's a dual to sending a message.
<Cheery>
then it terminates both options into an axiom.
otisolsen70 has joined #pypy
jacob22 has joined #pypy
jacob22 has quit [Ping timeout: 245 seconds]
slav0nic has joined #pypy
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
<ctismer_>
cfbolz: About speed: There is a growing tendency to use type hints in Python code. The Mypyc compiler uses that, and there is quite some speed, although PyPy is much better.
<ctismer_>
cfbolz: Would it make sense to use info from type hints as an option in PyPy, too? This way perhaps the startup time of PyPy could be improved.
<ctismer_>
More importantly, I'm a bit unhappy with the decision of Python to ignore type hints, and the need to consult Mypy to check validity. Maybe this could be an automatic check in PyPy?
<cfbolz>
ctismer_: all but the simplest type hints are hard to check though
ctismer_ is now known as ctismer
<ctismer>
cfbolz: Well, Pypyc does that already. If they are trustable checked, already, is it still complex to use the hints?
<cfbolz>
ctismer: the problem is that the types the JIT has are very different from the types that mypy understands
<cfbolz>
Apart from very simple ones like int and float
<cfbolz>
(even int is different, because pypy needs to know 'int that fits into a word'
<cfbolz>
)
<ctismer>
cfbolz: Ah! So that would be again a translation process for itself.
<ctismer>
`> even int...`: I understand, wrong language, actually 🙃
<cfbolz>
ctismer: and we have a lot of really weird 'types' that say stuff like 'the globals of this module didn't change since last time'
<ctismer>
cfbolz: So improving startup-time would be more about caching this info across program runs.
<cfbolz>
ctismer: yes, that's one approach (difficult)
<cfbolz>
The other approach is to make our interpreter faster
<cfbolz>
(currently sometimes 2x slower than cpython)
<ctismer>
cfbolz: what! And CPython is getting really a bit faster over time (new opcodes, caching, ...)
<cfbolz>
ctismer: we'll see how fast they get. It's tough work
greedom has quit [Remote host closed the connection]
greedom has joined #pypy
<ctismer>
cfbolz: interesting is also the PEP 554 (a bit stalled now) and the per-interpreter GIL work.
<cfbolz>
ctismer: there's also the new nogil fork
<ctismer>
cfbolz: Again? (I know Greg Stein's hack 20 years ago). I thought that would give crazy trashing because of the refcounting bottleneck, or id there a workaround?
<cfbolz>
ctismer: yes, they have a real clever biased locking implementation
<Corbin>
Kind of. Tuples won't work; they're fixed-size heterogenous rows, not arrays. You can make an instance field which points to an immutable list; RPython will use flow analysis to prove that the list isn't mutated elsewhere.
<Corbin>
Specifically, if you have a class with a field .foo which should point to an immutable list, then add `_immutable_fields_ = "foo[*]",` to the class fields.