Jonathan Perkin @jperkin@bsd.network

One of my next #running goals is a sub 1:30 Half Marathon, after setting a 1:37 PB in September.

Today I thought I'd head to the track and see how long I could sustain 4:15/km pace which is what I'll need to achieve that time.

Managed around 13km before my legs gave up, but at least I know what I need to work on now!

https://www.strava.com/activities/8078521826

Today's fun, trawling through the tty(4) differences across the BSDs trying to fix reads >1024 characters from serial devices.

Have solved the problem on NetBSD using TIOCSQSIZE so mdata-get now works correctly, FreeBSD/OpenBSD do not have that though so a fix remains elusive...

Experimenting with judicious use of CONFIG_SITE to speed up single-threaded configure scripts, along with a performance fix in libtool to avoid erroneously calling print(1) when using bash (should be using printf builtin).

Bootstrap time before:

real 10:42.158064138
user 7:54.072542389
sys 5:38.494943161

After:

real 5:14.636518760
user 5:09.415220572
sys 3:09.766759640

I'll take that!

Current coffee: San Ceyatano, Colombia (Caturra, EA washed decaf).

Nicely balanced with some milk, though still figuring out the best brew temperature. One day I'll add a PID and make that side of things a whole lot easier.

Latte art is a lot more consistent these days too, might be time to try some other designs.

Updated MySQL to 8.0.31 in pkgsrc, and took the opportunity to clear up some cruft that has been cargo-culted since the 3.23.x days. Felt good!

Pretty sure nobody is building MySQL 8.0 on IRIX5, though with pkgsrc you never know!

I recently made pkgsrc/mk 2x faster.

One of the more interesting parts of this work uses what bmake(1) refers to as the "loop expansion mechanism from OSF Development Environment (ODE) make".

By far the biggest win when it comes to speeding up make infrastructure is reducing the number of fork+exec. With make, it's very easy to invoke a huge number of wasted shell processes, for example:

target:
this runs a new shell
this forks another shell
yep, more shells

An easy fix for simple targets like this is to just use continuation lines:

target:
this runs a new shell; \
but this does not; \
nor this; woo, faster

However, in the pkgsrc mk infrastructure we have a few sections where we loop over a variable which may contain over 100 items, doing something like:

.for tool in ${TOOLS}
do-something ${tool}
do-another ${tool}
.endfor

Looks innocuous, but you can very quickly end up with many hundreds of new shells, and a significant performance impact, especially on systems with expensive forks.

The ODE loop expansion mechanism allows us to instead write:

${TOOLS:@tool@
do-something ${tool}; \
do-another ${tool};
@}

which expands inline into a single sequence of commands to run in the current shell.

Using dtrace(1) to record execs, I measured a reduction from 2391 to just 791 when building a simple package such as pkgtools/url2pkg, and a corresponding 2x reduction in build time.

When building packages on slow systems such as NetBSD/68k, that can reduce bulk build times by weeks!

Here's a patch that adds Godeps support to #pkgsrc, along with influxdb as an example package that uses it.

https://github.com/joyent/pkgsrc/commit/dc13448b9448dc4d895b1f29fa4a08f4f4c6ab52

Comments welcome. I'd be especially interested to know if there are Godeps examples that do _not_ use GitHub as the distfile location. So far all of the influxdb dependencies either use GitHub directly or redirect there via meta tags.

Pleased to finally get a working #pkgsrc #macOS Snow Leopard 32-bit bulk build running again, after switching to GCC 4.9 as the base compiler. The native 4.2 was just too old to build modern software.

Over 15,000 packages, which is a pretty good result: https://us-east.manta.joyent.com/pkgsrc/public/reports/Darwin/trunk/i386/20180801.2216/meta/report.html

Binary bootstrap kit available as always here: https://pkgsrc.joyent.com/install-on-osx/

Some cool storm clouds passing through earlier.

First time over 19,000 packages for #pkgsrc on #illumos

http://us-east.manta.joyent.com/pkgsrc/public/reports/upstream-trunk64/20180808.0210/meta/report.html

Really happy with that, especially as it's with GCC 7.2.0 with various Spectre mitigation options enabled. Plus -msave-args!

Looking good for switching over from GCC 4.9 in our 2018Q3 release.

First post, or something. This Mastodon thing could be interesting if it gains enough traction.

One initial noob question, using the web interface, can I make the Home pane wider?

The default is cripplingly small, making it hard to read posts.

Unpinning other stuff just leaves large amounts of wasted screen estate.

I will mostly be posting about #pkgsrc so if that's of interest to you then follow along, otherwise it's likely to be pretty dull!