570 karma · joined June 25, 2012
The Donald Trump that your media reports on isn't the real Donald Trump, or at the very least the one his supporters see.
Example: Trump talks to a group of people who normally don't vote, and asks them to make an exception and vote this time, noting that this will be the last time he runs, and so they won't need to vote for him again. The media then takes "you won't need to vote for me again" out of context and uses it to claim that Trump will end elections in the US. People who only listen to the media see one thing, and his supporters (who are aware of the context) see another.
Lisp-style macros are actually difficult to write because of the infinite evaluation of the language. I was able to write a quasiquote package for myself to help with that that though.
If they're able to deliver what's in the email I'll be picking one up.
You can technically do it, but I don't it being worth the hassle.
If the future model is going to be anything, I suspect it'll be pay-to-join networks where it is primarily the users that are moderated instead of the content.
SpinalHDL has been very nice to use so far instead of Verilog: https://spinalhdl.github.io/SpinalDoc-RTD/master/index.html It even has simulation and formal verification workflows built in. In the simulation you can wiggle the bits on your ports using Scala, so you can code an emulation of any peripheral or the like that you want and have your design use it. (You can also do the same thing using C++ if you use Verilator directly instead.)
You can code a bridge between a serial port in your simulated design and a TCP port, and then write a second program to bridge a real serial port to a TCP port the same way. You can then write tools that connect to the TCP port and then use those same tools against both your simulated design and your design in hardware.
In short, you can define generic reusable flow constructs like stall and backpressure pipelines. You can then instantiate them and slot in your logic, and signals will be automatically pulled through the different stages and pipelines as needed. The example at this part of the video shows then how adding something can be a two line change when it would be hundreds of lines if you were working at the RTL level: https://youtu.be/hQ6HhOBHKy0?t=2581
I recently came across https://makerchip.com/, and the TL-Verilog language it supports looks useful for when you want to make a pipelined design later.
Having values and having your program phrased as transformations of values makes for straight forward, easily tested code. Provide inputs, assert outputs.
Asserting formatted output can also be really useful. A picture might be worth a thousand words, but when it comes to tests it can save you a thousand asserts. Writing those thousand asserts separately also would be so tedious that in practice you'd probably not write them all, leaving part of your output uncovered by tests.
When I wrote a LALR parser generator for fun, I added some code to print out a nicely formatted parsing table with debugging information. Besides being useful for debugging, it let me write simple yet powerful tests: I would feed the generator a grammar and then assert on the formatted parsing table. That made it easy to verify that I was asserting the right thing, and let me assert everything in one go.