<xiangfu>
kristianpaul, much small then openwrt ben nanonote :)Â Â it's ~220M
<kristianpaul>
xiangfu: so problem is gone now?
<kristianpaul>
i'm wondering if you have to run xlcm again..
<xiangfu>
kristianpaul, not sure. wait for next trigger by cron job
<kristianpaul>
hum..
<kristianpaul>
cant you push it now? :)
<kristianpaul>
or too busy server?
<xiangfu>
now? that is bad. the build order is like openwrt-xburst, openwrt-milkymist, milkymist-firmware.
<kristianpaul>
he, i tought that
<kristianpaul>
no problem
<xiangfu>
may cause some problem. so wait is better maybe next 3 hours it will start build(there are errors on openwrt-xburst, so it will not build 36 hours :)
<kristianpaul>
hehe
<kristianpaul>
btw a grep sys_clk that match an (*) asterisk just in case timining is not met could be considered
<wpwrak>
speaking of easing access for developers, do we actually have any decent instructions for writing M1 patches/presets ? or is M1 really close enough to milkdrop that anything that works there works on M1 too, and vice versa ? (i'm still worming my way through the milkdrop instructions)
<lekernel>
yeah, verilator converts your verilog into a c++ model
<lekernel>
so VPI no longer makes sense there
<errordeveloper>
sure
<errordeveloper>
but as I said, I am working towords cross-tool framwork
<errordeveloper>
so you could do 'make USE=MyTool' on you project
<errordeveloper>
that's very quick explanation though
<errordeveloper>
I found hdlmake and boldport
<errordeveloper>
hdlmake is okay, but still very immature and after a discussion on their mailing list I somewhat figured that I'd rather roll my own framework
<lekernel>
hmm... why not try improving hdlmake instead?
<errordeveloper>
boldport looks kindda cool, but the author seems to have no intention to make it a command line tool or at least a gui
<lekernel>
I guess Tomasz would welcome your contributions :-)
<errordeveloper>
boldport is web-based ...
<lekernel>
plus hdlmake has a skilled user base already
<lekernel>
boldport is SaaS I wouldn't touch
<errordeveloper>
yeah ...
<lekernel>
I won't even discuss it :-)
<lekernel>
but hdlmake is nice and properly licensed
<errordeveloper>
sure
<errordeveloper>
well, I thought to kind of see how far I'll get and then backport into hdlmake
<lekernel>
hdlmake is used for some CERN projects
<errordeveloper>
and I didn't fill like learning python right now
<lekernel>
you should. python is one of the best languages out there.
<errordeveloper>
I'd do it in Ruby and then once I have a clear methodology I can see how to re-implement it in python
<errordeveloper>
that was an idea somewhere at the back of my mind
<errordeveloper>
well, hdlmake in it's current state needs a lot of refactoring
<errordeveloper>
which I couldn't take on with my little knowledge of python
<errordeveloper>
and the goddamn 'meaningful whitespaces
<errordeveloper>
'
<errordeveloper>
would kill me again!
<lekernel>
:-) I don't know why so many people dislike that idea
<lekernel>
I find it elegant
<errordeveloper>
it's not a bad thing, just gets me mad a little bit
<wpwrak>
lekernel: the whitespaces get inconvenient if you move around code for debugging. also, python has that unspeakably retarded requirement of continuing many lines with a backslash. that's perhaps the #1 weakness CPP inherited from the mainframe days, and i find it rather absurd that python kept that. even the bourne shell is a little smarter :)
<wpwrak>
(moving around code for debugging) e.g., add an if to skip a block or maybe add a print to check a variable. in C, i can put all these things in the first column, so they stick out and i won't forget to remove them when i'm done. in python, Guido doesn't trust me to have the moral strength to write clean code, so i'm forced to make even such very temporary constructs look "nice". and of course, that also makes is harder to spot them late
<wpwrak>
r, when the bug is dead and it's time to clean out the debugging stuff.
<mwalle>
wpwrak: most \ can be replaced with parenthesis, and most editors can indent blocks/lines :)
<mwalle>
if there are many backslashes for line contiuation, the code will need some refactoring imho :)
<mwalle>
and i like it that theres only one coding style :)
<wpwrak>
sometimes, others force long identifiers on you. then your lines overflow very quickly. also, the class - function - body structure means that almost all of your code is already two tab stops indented. so you lose one level of indentation to OO.
<wpwrak>
the uniform coding style is nice, though. i just wish a little more thought had gone into the scanner. you could have the "clean" and uniform style and a better syntax, without too much effort.
<wpwrak>
(\ -> parentheses) yes, but then your code gets less readable. lots of parentheses are fine for your Lithp machine, but for humans ?
<wpwrak>
(long identifiers) and sometimes you don't have a good alternative either. particularly if doing geometry. lots of things that need qualifiers. of course, you can just use x0, y2, a13, and so on, but that kinda defeats the purpose :)
<wpwrak>
(autoindent) yes, but that still hides your debugging code :) i _want_ it to stick out. forgetting anything from it is bad. and sometimes, you need lots of stuff scattered all over the place to track down a particularly pesky problem. and you want it there until after you've implemented and confirmed your fix.
<wpwrak>
of course, you rcs will tell you what changed, but you still need to decide which is debugging and which is fix, for they'll all look alike. making it easier to make mistakes is a bad idea in my opinion.