Over the last few weeks I noticed this site becoming steadily slower. Turns out I had an unusual amount of requests for /xmlrpc.php.. which in turn caused the server to use up all it’s http processes answering bogus rpc queries for ping backs and whatnot that the nice script kiddies all over the world are trying to exploit I guess.
So… took care of that. Hopefully things are back to normal. I’ll have to go back and re-evaluate if I actually want any of that functionality I guess.
So the last project I worked on at work required some hardware enclosures, handles and a couple odds and ends that we decided to design ourselves and 3D print. So lucky me, I’ve entered the 3D printing arena. Been having enough fun doing it that I’ve started offering printing services to the local market.
Contact me directly for 3d printing services.
This is definitely one I know the masses are waiting to find out how to do. 🙂
So you are simulating a verilog design with Verilator and you want to output part of your design data to a file in binary format. (Example you’re outputting an image.)
So lets say you want to do this:
fd=$fopen("somefile.dat", "wb");
$fwrite ( fd, "%c", data );
And you expect a file with binary data but instead you get a text file.
Well in Verilator you can embed c statements. So you can do this instead:
$c( "fwrite( (void*) &", data,", 1, 1, (FILE*)", fd, ");" );
There. Fixed.
Ok so I’ve been using Python for a long time and have written a lot of lines of Python code. But this one is pretty simple and I’m kind of embarrassed that somehow I didn’t know about it.
In the past, I’ve used sys.stdout when I wanted to print multiple things on one line, e.g., you want to print periods to show progress.
import sys
for i in range (10):
sys.stdout.write ( "%d.." % i )
I also knew you could use print with more than one item.
print 1,2,3, "Hi"
But the other day I inadvertently found that you can continue to print on one line if you just leave the trailing comma….
for i in range(10):
print "%d.." % i, # no newline appended
print # add a newline after the loop.
And who cares you say??? Well now I don’t have to import sys and use sys.stdout when a simple print can do just fine 🙂
So I got a c++11 book. I’ve been following a few of the language differences and features for a while, but I decided to break down and actually understand it all. I decided to have some fun with lambdas today. Lambdas are a very useful language feature that lots of dynamic languages have (JavaScript, Python, <insert your favorite there is plenty>). For some additional readying you might read about Closures and Functors.
Anyway, so here you go:
Basic syntax
[...] {...} // simplest form
// or showing all the optional arguments
[...] (...) mutable throwSpec -> retType {...}
What does that all mean?
The brackets are a parameter list of values you can pass in for usage in the lambda from the context in which the lambda is being created. You could pass in local variables or this for instance. You can pass by a value or reference. Unlike other languages, if you pass by reference and the value is deleted, your lambda might have unexpected results or crash.
The parenthesis are the parameters you pass in when you call the lambda. Declared like a parameter list for any other function. auto is nice but if you need the type (like to return a lambda from a function) you can use the functional header.
Example:
#include
#include
using namespace std;
function getTheLambda()
{
int x=7;
// will return an undefined value because x is going to be removed from
// the stack when this function exits.
return [&x] (int a, int b) { return x+a+b; };
}
int main(int argc, char* argv[])
{
auto m = [] (int y) { cout << "lamda value: " << y << endl; };
// call it
m(3);
auto l=getTheLambda();
cout << "Lambda Result: " << l(1,2) << endl;
return 0;
}
For me it printed:
./test
lamda value: 3
Lambda Result: 32770
If you change the first lamba in the function to "x" instead of "&x" you'll get the expected result of 10.
I can't wait to pass a lambda to a thread and use it as some type of callback!
I had these files with very very long lines of text on each line. It was paragraphs worth of words but not word wrapped. These files were stored in a git repository. Now and then, someone would change a word. Diff with line based output was difficult to find what actually changed.
I figured there must be a way to see just the words. A little searching around the docs and I found it.
> git diff --word-diff=color
Perfect. I still got ling scrolling lines though. You can override that with your $GIT_PAGER variable or I just piped the output manually for a one time fix:
> git diff --word-diff=color | less -r
Much easier to see the changes!
