<Corbin>
I agree that a printable location would help. The main obstacle there is that Cammy programs don't have locations at all.
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
<cfbolz>
Corbin: why not?
<cfbolz>
Corbin: anyway, you can pretty-print the ast, that would also help
<Corbin>
I never bothered to define locations when I laid out the parser. I was *very* lazy.
greedom has joined #pypy
<cfbolz>
Corbin: so subclasses of Arrows are part of the program, and Elements are values that the program operates on?
<cfbolz>
anyway, I'd say having location printing would help you a whole lot
<cfbolz>
(also I can't deal with all the single letter varnames ;-( )
<Corbin>
Yeah, sorry.
<cfbolz>
Corbin: I think it's an interesting thing to think about, what are the actual loops in your programs? are there any?
<cfbolz>
eg the fold, that is a loop over the list, isn't it?
<Corbin>
Yeah, there's folds over lists, and primitive recursion over natural numbers. (I know primitive recursion is slow, and will eventually jet some common cases with special instructions.)
<cfbolz>
the fold_driver.jit_merge_point call is really in the wrong place then
<cfbolz>
it should be in the for loop
<cfbolz>
in Fold.run
<cfbolz>
that would turn it into an actual loop
<Corbin>
Oh, interesting.
<cfbolz>
PrimRec does that correctly
<Corbin>
I wonder why I did that. I'm guessing that the translation process broke if I inlined driveFold().
<cfbolz>
try and show me the error?
<cfbolz>
ah, I probably know
<cfbolz>
it can't deal with the for loop
<cfbolz>
you can get around that by saying reds='auto'
<cfbolz>
in the driver construction
<cfbolz>
the same is true for the sample_jitdriver, fwiw
<Corbin>
"[translation:ERROR] Exception: The variable self_0 of type <* GcStruct cammylib.arrows.Fold { super, inst__c, inst__n }> was not explicitly listed in _forcelink. This issue can be caused by a jitdriver.jit_merge_point() where some variable containing an int or str or instance is actually known to be constant, e.g. always 42."
<Corbin>
Trying again with autoreds.
<cfbolz>
Corbin: hm, wait
<cfbolz>
Corbin: the self should be a green variable
<cfbolz>
Corbin: can you tell me what an "H" is?
<cfbolz>
ah, I get it
<Corbin>
H is "hom"; it's a curried function which wants to be applied to a pair, but only the first value is available.
<cfbolz>
right
<cfbolz>
Corbin: so I wonder whether H.apply should promote self._f for calling "run" on it
<Corbin>
Ah, kind of a defunctionalization. Tricky.
<cfbolz>
wouldn't you expect that most call sites of an H call the same thing in practice?
<cfbolz>
we certainly do exactly this in say pycket
<cfbolz>
Corbin: I mean, there's an alternative point of view: in every "run" method, you should start with "promote(self)"
<cfbolz>
in order to execute self, the JIT should know what "self" is
<Corbin>
This all makes a lot of sense. I'll test it out and see what happens.
<cfbolz>
ok, final question tonight ;-)
<Corbin>
I think that the JIT translation has gotten far enough to say that it's gonna work. I added "self" to greens *and* changed reds to "auto".
<cfbolz>
cool :-)
<cfbolz>
Corbin: do it for the sample driver too
<cfbolz>
anyway, my question is why there are so many call_assemblers
<cfbolz>
what is the example program actually computing?
<Corbin>
The example program is computing the Burning Ship fractal. It should look like a trace of a Mandelbrot.
<cfbolz>
ok
<cfbolz>
yeah, some of the float operations appear further down in the trace
<cfbolz>
yeah, we need to get rid of the getfields (and I suspect we will lose some with the promotes that I mentioned)
<cfbolz>
and then later the call_assembler (maybe hard, bit unclear)
* cfbolz
zzzz
<Corbin>
Sweet, thanks. Many things to work on. Have a good night.
slav0nic has quit [Remote host closed the connection]
slav0nic has joined #pypy
slav0nic has quit [Remote host closed the connection]
slav0nic has joined #pypy
lritter has quit [Quit: Leaving]
otisolsen70 has quit [Quit: Leaving]
greedom has quit [Remote host closed the connection]