kivikakk.ee

Sada päeva

Yesterday was our 100th day in Estonia. Taking a little bit of stock of what we’ve managed:

  • Visited the 4 largest cities in the country.
  • Rented an apartment in the biggest one!
  • Furnished what the apartment didn’t come with.
  • Shipped our things from Australia. (Maybe a month off those arriving.)
  • Got our motorcycles; put 900km on each.
  • Got medium-term visa for A, and long-term one applied for.
  • Got our medications prescribed locally.
  • Financial/bureaucratic overhead.
  • Changed my name and got new ID.
  • Got onto a good family doctor’s list.
  • Kept in touch with families and psychologists.
  • Vaccinations.
  • Saw the border.
  • Went to a cat café.
  • Went to sauna.
  • Concluded jaanipäev with clothes smelling deeply of bonfire.
  • Went to a live show (Estonian).
  • Went to a live show (non-Estonian).
  • Walked about 500km.
  • Taken a lot of public transport.
  • Met a range of people.
  • Spoken quite a bit of Estonian.
  • Kept up with projects.
  • Finished a diary!
  • Grew a lot.

Python still surprises

After the better part of 20 years working with Python, it still managed to surprise me today.

I’m so used to languages treating x += y et al. as pure sugar for x = x + y that it skipped my mind that some don’t.

I’m not surprised that you can override them separately in some languages (e.g. I simply assume this to be the case in C++, and on checking it turns out to be true — but that seems fair enough given the scope of the language), but I really am so accustomed to them being only sugar in Ruby that I assumed the same would hold, at least in effect, in Python.

Thus my surprise on some_list += x modifying some_list in place (unlike some_list = some_list + x), but once observed, I realised there’d be a separately-overridden operator function — namely __iadd__ — and so I figured it “had” to be that way.

Or did it? I then found myself assuming it’s because these operators can’t actually reassign the receiver, but in fact they can and do: the return value is what’s assigned to the LHS. So it’s just a matter of convention.

sint

Notes.app, kell 08:03:

my new theory is that satan Crept into this world through signed integers

zxxrtl

I’ve been getting back into using CXXRTL and Zig together, so I’ve extracted and rendered somewhat reusable the bindings I made to use them together!

zxxrtl uses CXXRTL’s C API to provide a somewhat idiomatic way to access, manipulate, and respond to events happening in the design. Its README covers the setup — it’s a bit involved as it’s necessarily something of a build system, but once you’re done it’s good to go and flexible enough to be instrumented from a higher build system.

I’m going to paste the example usage here; this doesn’t use the Sample API for edge detection, and just drives the simulation while optionally recording VCD:

const Cxxrtl = @import("zxxrtl");

// Initialise the design.
const cxxrtl = Cxxrtl.init();

// Optionally start recording VCD. Assume `vcd_out` is `?[]const u8` representing an
// optional output filename.
var vcd: ?Cxxrtl.Vcd = null;
if (vcd_out != null) vcd = Cxxrtl.Vcd.init(cxxrtl);

defer {
    if (vcd) |*vcdh| vcdh.deinit();
    cxxrtl.deinit();
}

// Get handles to the clock and reset lines.
const clk = cxxrtl.get(bool, "clk");
const rst = cxxrtl.get(bool, "rst");  // These are of type `Cxxrtl.Object(bool)`.

// Reset for a tick.
rst.next(true);

clk.next(false);
cxxrtl.step();
if (vcd) |*vcdh| vcdh.sample();

clk.next(true);
cxxrtl.step();
if (vcd) |*vcdh| vcdh.sample();

rst.next(false);

// Play out 10 cycles.
for (0..10) |_| {
    clk.next(false);
    cxxrtl.step();
    if (vcd) |*vcdh| vcdh.sample();

    clk.next(true);
    cxxrtl.step();
    if (vcd) |*vcdh| vcdh.sample();
}

if (vcd) |*vcdh| {
    // Assume `alloc` exists.
    const buffer = try vcdh.read(alloc);
    defer alloc.free(buffer);

    var file = try std.fs.cwd().createFile(vcd_out.?, .{});
    defer file.close();

    try file.writeAll(buffer);
}

Hopefully this is useful to someone else!

Täna

Täna oli saunapäev. ^_^