<rjo>
sb0: for __all__/_ i would just be consistent. my personal preference is __all__ everywhere because i find the large amount of _ everywhere more irritating than a few namespace mangling lines at the top of the file.
<rjo>
if i understand this right, in the new simulator you are doing yields for reads and writes. why is that better than sim.read()/sim.write() or dut_proxy.read()/write()? semantically to me the inly difference is the contro flow/stack. with the generators the simulator is in charge while otherwise the simulator is called back.
<sb0>
rjo, there is no difference between calls and yields for reads and writes. but the yield comes useful when waiting for a clock cycle, and I'm simply using the same mechanism instead of having to pass a simulator context into the generators
<rjo>
but with the current "yield None" i can only wait for the default clock signal, right?
<cr1901_modern>
sb0: Anything equivalent to the do_simulation or gen_simulation in the current simulator?
<sb0>
yield None can be aliased to "yield Wait(Clock())"
<sb0>
yes
<cr1901_modern>
just make those methods and run_simulation will autodetect them?
<sb0>
simulation methods are decoupled from Module now
<sb0>
you only pass them to the simulator
<cr1901_modern>
okay, that's what I thought. I'll think of something so my files aren't cluttered with do_sim() functions
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
<rjo>
sb0: is the proxy object gone?
<sb0>
yes
<sb0>
too many problems with it
<rjo>
good.
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
<sb0>
f = open("/tmp/simserial", "w")
<sb0>
f.write(os.ttyname(s))
<sb0>
f.close()
<sb0>
....
<sb0>
oooh and another factory function
<sb0>
_florent_, would you mind maintaining the verilator stuff in a separate repository? I'm just going to make the misoc cores flexible enough that it can be done that way ...
<cr1901_modern>
sb0: So, has your faith in other's coding habits decreased steadily over the years, or were there a few particularly horrific events that shaped your outlook?
<sb0>
it's not just a coding habit, factory functions break inheritance, issubclass(), class.method, etc.
<sb0>
and the other bit of code is non portable and non reentrant
<cr1901_modern>
But if you follow GoF religiously, inheritance is bad!11
<sb0>
GoF?
<cr1901_modern>
Gang of Four Design Patterns
<acathla>
religion is bad too
<cr1901_modern>
acathla: Not being terribly serious, although I do like factories. sb0 as a point as well.
fengling has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
<whitequark>
inheritance is stupid to use so widely but everyone else in python isn't going to stop just because i don't like it
<whitequark>
when in rome, etc
<sb0>
"so widely"?
<sb0>
actually, I'm not a huge fan of inheritance either...
<whitequark>
there are a few useful patterns that are near impossible to replicate without inheritance
<sb0>
but it has its uses and should not be broken
<sb0>
yes
<whitequark>
e.g. UI widgets and visitor
<whitequark>
but for everything else you're better with ADTs
<whitequark>
better off*
<whitequark>
OCaml is a very interesting case study on this. the O in OCaml is "object oriented"; people usually assume this is some big thing but actually most OCaml code uses absolutely none object-oriented features
<whitequark>
and apart from the two I mentioned, and excluding type system tricks, I don't think I've seen it used at all
<whitequark>
while we're at it, I would like to take a moment to regret how objects and classes are understood as two parts of the same thing whereas in reality they are almost unrelated
<cr1901_modern>
Classes are a contract that certain operations are available, and objects implement said contract?
<whitequark>
no
<whitequark>
object types are such a contract
<whitequark>
it is perfectly reasonable to have object types without having classes at all
<cr1901_modern>
fair enough... reminds me of a Lisp example where cons is implemented in multiple ways. The cons object will get the information you need when passed into cdr/car, but the way to get this information between implementations is vastly different.
<whitequark>
no, not really, python just conflates classes and object types
fengling has joined #m-labs
<cr1901_modern>
sb0: Have you tested using a clock domain not called "sys" yet in simulation? My simulation's entering an infinite loop if I do.
<cr1901_modern>
whitequark: "no, not really?" Is my example in general poor, or is the "vastly different" part inaccurate?
<rohitksingh>
Hello everyone! A rookie here. I'm just starting with misoc and noticed classes named "_CRG" inherited from "module" class, present inside 'target' files. What does it stand for? From its contents, I can see its mostly clock related...any pointers would be of help, thanks!
<sb0>
whitequark, can we move libunwind under m-labs on github?
<sb0>
rohitksingh, Clock and Reset Generator
<rohitksingh>
sb0: hi! and thanks! :)
<sb0>
whitequark, or are you merging your modifications upstream? should we use upstream then?
<whitequark>
cr1901_modern: the difference between classes and object types is not an implementation detail
<cr1901_modern>
Ack. I'll find something re: ADTs to read up on and see if I can't understand it (again).
<cr1901_modern>
Also note to self: The new Simulator as a clocks input argument. Failure to fill that out appropriately causes bad things to happen.
<cr1901_modern>
has*
<sb0>
cr1901_modern, how did you crash it?
<cr1901_modern>
Forgot to fill in the clocks input argument to Simulator with the clock domain name and period
<sb0>
the default is a single sys clock.
<cr1901_modern>
yes, and I have a module which can either be tied to the sys clock divided by some factor, or an external clock. So I made a whole new clock domain.
<cr1901_modern>
Filled out the generator with {"rx" : test_rx(m)}, but let clocks take the default argument. So rx never elapsed :P
<sb0>
ah. can you send a patch so that it does some sanity checking on that and throws eg a valuerror exception?
<sb0>
should be clocks.keys == generators.keys
<cr1901_modern>
Will do. I have a todo list of patches I need to send you, btw, so I'll get on those today.
<cr1901_modern>
I feel bad that I keep breaking Migen these past few days lol
rohitksingh has quit [Ping timeout: 260 seconds]
antgreen` has quit [Ping timeout: 260 seconds]
<cr1901_modern>
sb0: When creating an FSM, if using NextState within If statements no longer supported?
<cr1901_modern>
erm, nevermind, cannot duplicate what I just saw o.0;
<cr1901_modern>
(Can duplicate. According to structure.py, line 434, If statements require input arguments of the _Statement class, but NextState does not inherit from _Statement)
<cr1901_modern>
Is this intentional?
<sb0>
no
<cr1901_modern>
Will it break anything to make NextState inherit from _Statement?
<GitHub139>
[migen] sbourdeauducq pushed 1 new commit to new: http://git.io/vn6qV
<GitHub139>
migen/new 33f344b Sebastien Bourdeauducq: fsm: NextState and NextValue should derive from _Statement
travis-ci has joined #m-labs
<travis-ci>
m-labs/migen#108 (new - 33f344b : Sebastien Bourdeauducq): The build passed.