<whitequark>
it may not have been there when migen was conceived, too
<rqou>
quite possibly
<rqou>
it's pretty funny how i'm working on an hdl tool but i don't even know any hdls that well :P
<rqou>
welcome to $FANCY_SCHOOL, where they teach you all the theory and the details are all "you can figure it out on your own"
<rqou>
it sucks how we still don't have any good common HDL IRs
<rqou>
no, "some ad-hoc but mostly-agreed-upon subset of verilog" isn't an IR
<nats`>
<whitequark> nats`: um, no, you don't understand how migen works <= for me it's a lib like system C
<nats`>
and it generates verilog from a subset of python using that lib
<whitequark>
nats`: it's not
<nats`>
ah ?
<whitequark>
it's *specifically* not
<whitequark>
it's silly to use deep embedding for anything that isn't lisp because the ast of the host language is a poor choice for an abstract representation of the embedded language, except in very rare cases
<rqou>
what about scala/chisel?
* rqou
hasn't used that either despite it being a $FANCY_SCHOOL project
<nats`>
so what is migen
<nats`>
it is described as a python module
<whitequark>
rqou: the only times i ever heard about scala is when it involved some indescribable type system horrors
<whitequark>
and i'm strongly of the opinion of "when it hurts, maybe you should stop doing that"
<whitequark>
i have no other opinion on that
<rqou>
you don't want SKI calculus implemented in your type system? :P
<rqou>
hey, rust also has an undecidable type system i heard
<whitequark>
who cares about decidability?
<whitequark>
in scala it's a libs issue
<rqou>
it'd be nice if your compiler could always definitively accept/reject your program
<whitequark>
nats`: you describe a circuit using python code, somewhat like a flowgraph
<whitequark>
rqou: rust has a recursion limit
<whitequark>
so it will definitely reject your program past some point
<rqou>
that barely counts i guess
<rqou>
in that case so does scala's compiler and c++ compilers
<whitequark>
yes
<whitequark>
i have no problems with undecidability. undecidability is useful. decidability is not obviously useful in general
<rqou>
in my very very limited playing with scala i didn't encounter any weird type system issues
<rqou>
but then i wasn't really making use of any collections
<rqou>
in general i find JVM languages a pain to deal with
<whitequark>
jvm is pretty sweet
<rqou>
even getting a nontrivial project to compile without blindly throwing everything in eclipse and hitting build is hard
<whitequark>
it has a usable profiler and debugger, it's pretty fast
<whitequark>
python has none of those
<whitequark>
hope you like sticking print()s everywhere
<rqou>
when i needed "debugging" and speed i would use ipython notebook + numpy
<rqou>
i've never really needed a profiler
<rqou>
in the (probably insufficiently complicated) projects i've worked on "thinking about it" was a far better optimization technique than "use a profiler"
<rqou>
actually that's not completely true
<whitequark>
"i've never really needed a profiler" um
<rqou>
i've done "profiling" with the "GPIO_PIN = 1; do_stuff(); GPIO_PIN = 0;" technique on a microcontroller
<whitequark>
i mean sure if you've never wrote real code that would influence your choice of languages
<whitequark>
even if you exclusively work with batch jobs, at some point they get too slow.
<rqou>
i mean, i did mention that i've used numpy when i had to crunch a lot of data
<rqou>
usually if the program was still too slow the only workable optimization technique was to get out the whiteboard/scratch paper and mathematically simplify what was being calculated
<rqou>
(in case you can't tell, this was also homework :P )
<rqou>
i really haven't written software that is a "real product"
<rqou>
i've written a lot of code for my own learning/experimenting/hacking and for homework
<rqou>
but never really anything that other people had to use
<whitequark>
a profiler is one of those things that you never know you need until you do, and then it's indispensable
<whitequark>
i'm about to write a profiler for artiq...
<whitequark>
(the firmware)
<rqou>
does "GPIO_PIN = 1; do_stuff(); GPIO_PIN = 0;" not count?
<whitequark>
(though it may be useful for kernels too)
<whitequark>
not really, you want a sampling callstack profiler usually
<rqou>
artiq uses a soft-cpu, right?
<whitequark>
sure
<rqou>
can't you easily implement a sampling profiler that just dumps PC into a block ram?
<whitequark>
no? that doesn't give you the callstack
<rqou>
ah you actually want the full callstack
<whitequark>
it's also completely unnecessary, a timer interrupt works just as well and is less effort
<rqou>
unless you somehow have heisenbugs that are affected by the presence of the timer interrupt? :P
<whitequark>
I can implement an interrupt-based sampling profiler in probably less time that xilinx tooling runs once