itamarst has quit [Quit: Connection closed for inactivity]
<mjacob>
In RPython, if `s` is annotated as a constant string, is `len(s)` supposed to be annotated as a constant integer?
<cfbolz>
it should be, yes
<uau>
Is there any reasonably well-performing way to get a 2D (or more) array of integers in PyPy? Or is just using [[0]*x for i in range(y)] the only practical answer?
<LarstiQ>
I'd assume using an array or other direct memory access might work well too?
<LarstiQ>
but the pattern of flat storage with computed index in any case
jcea has joined #pypy
itamarst has joined #pypy
<mjacob>
I’m trying to debug a translation failure with --revdb in the py3.11 branch: https://bpa.st/FCCQ
<mjacob>
s_old = SomeString(const='Object is not writable.', no_nul=True) comes from OperationError.get_w_value calling newtext
<mjacob>
s_value = SomeString() comes from (pypy.interpreter.unicodehelper:62)fsdecode calling newtext
<mjacob>
oefmt() is specialized for 'Object is not writable.'
<mjacob>
(not sure whether the oefmt specialization is relevent here, though)
<mjacob>
What seems to happen is that the is_annotation_constant() call in newtext() is annotated to return constant True while the annotator only knows about the constant string argument. Later, the annotator sees more arguments are generalizes the string parameter. But when the is_annotation_constant() call is re-annotated, it’s already too late. Because constant True and constant False don’t merge, it crashes.
<mjacob>
newtext() has the @specialize.arg_or_var(1, 2) decorator. But in our cases, the parameter 2 is not constant, so we hit the variable case.
Julian has joined #pypy
<ronan>
mjacob: the problem is that the first call to newtext() has constant s but variable lgt so the specializer returns the variable graph, and then is_annotation_constant(s) gets annotated as constant True, which then causes the crash as soon as you reannotate newtext() with a variable s.
<ronan>
really the issue is that is_annotation_constant() breaks the abstract interpretation model
<mjacob>
ronan: Yes, it seems like is_annotation_constant() doesn't mix well with @specialize.arg_or_var() with multiple args.
<mjacob>
Any idea how to fix the issue?
<ronan>
the easy one is not to pass lgt to _newtext_memo() so we can specialize only on s. Since it's a memo, passing lgt doesn't save anything at runtime and prevents using pre-built objects in some (or many?) cases
<ronan>
hmm, I would have thought the annotator already knew about the len of const strings
<ronan>
but maybe it's only done in the rtyper
Julian has quit [Ping timeout: 276 seconds]
<korvo>
No, they're disconnected. I was bitten by a nearby crash recently; I didn't save the backtrace, though. The solution was to lift the len() up one closure, which I guess led to it being computed before use.
<mjacob>
cfbolz: bf3f9e5a65f80205d78d428a10511c69bf216f10 broke translation. Should I revert?
Dejan has joined #pypy
<cfbolz>
mjacob: argh, seems some kind of weird limitation of the rpython peg parser
<cfbolz>
mjacob: please do, otherwise I'll fix it tomorrow morning
<mjacob>
Done, as I wanted to refrain from analyzing the generated code. :)
<cfbolz>
I want to refrain from that too
<cfbolz>
mjacob: https://bpa.st/QHJA that looks sensible, and together with a test should just go on main?
<mjacob>
cfbolz: It seems very ad-hoc. I mean, why not add it for lists etc. as well?
<mjacob>
But then we might end up duplicating things that are handled by rtyper already.
<cfbolz>
because we do a lot of meta-programming with constant strings already, it's a very natural addition imo
Dejan has quit [Remote host closed the connection]