At work I mostly program in Ruby, but our system (YaST) has a C/C++ part
too. So I get to debug C crashes infrequently enough to forget some
tricks. Here I write them down for the next time.

1. Contents and tl;dr

• $ ulimit -c unlimited so that a core dump is saved
• $ sudo coredumpctl dump -o core so that it is saved to a file
• $ gdb -c core is wrong, gdb program core is right
• (gdb) info sh mylib
• (gdb) select a stack frame before querying variables or macros
• $ CFLAGS="-g3 ..." for debugging macros

1. (Un)helpful crash dump

When Ruby crashes, it produces a very verbose dump of information. It is not
much helpful in our case:

$ rake run[fail]
/sbin/yast2 src/clients/fail.rb
/usr/lib64/ruby/vendor_ruby/2.5.0/yast/yast.rb:204: [BUG] Segmentation fault at 0x0000000000000008
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-gnu]

-- Control frame information -----------------------------------------------
c:0011 p:---- s:0066 e:000065 CFUNC  :call_yast_function
c:0010 p:0061 s:0058 e:000057 BLOCK  /usr/lib64/ruby/vendor_ruby/2.5.0/yast/yast.rb:204 [FINISH]
c:0009 p:0023 s:0054 e:000053 METHOD /local/home-mvidner/svn/yast/samba-server/src/clients/fail.rb:5
[...]
c:0002 p:0489 s:0011 E:000c18 EVAL   /usr/lib/YaST2/bin/y2start:58 [FINISH]
c:0001 p:0000 s:0003 E:001300 (none) [FINISH]

-- Ruby level backtrace information ----------------------------------------
/usr/lib/YaST2/bin/y2start:58:in `<main>'
/usr/lib64/ruby/vendor_ruby/2.5.0/yast/wfm.rb:195:in `CallFunction'
[...]
/usr/lib64/ruby/vendor_ruby/2.5.0/yast/yast.rb:204:in `call_yast_function'

-- Machine register context ------------------------------------------------
 RIP: 0x00007fa423bf9677 RBP: 0x00007fff30f5ff20 RSP: 0x00007fff30f5fe10
[...]
 R14: 0x00007fff30f5ff48 R15: 0x00007fff30f5fe10 EFL: 0x0000000000010202

-- C level backtrace information -------------------------------------------
/usr/lib64/libruby2.5.so.2.5(rb_print_backtrace+0x15) [0x7fa428543f15]
/usr/lib64/libruby2.5.so.2.5(0x1c814c) [0x7fa42854414c]
/usr/lib64/libruby2.5.so.2.5(0x93e44) [0x7fa42840fe44]
/usr/lib64/libruby2.5.so.2.5(0x158eb2) [0x7fa4284d4eb2]
/lib64/libc.so.6(0x7fa427ff8160) [0x7fa427ff8160]
/usr/lib64/YaST2/plugin/libpy2lang0_ruby.so(_ZN5YRuby9callInnerENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_7YCPList8constPtrI4TypeS8_E+0x4c7) [0x7fa423bf9677]
[...]
/usr/bin/ruby.ruby2.5(_start+0x2a) [0x40086a]

-- Other runtime information -----------------------------------------------

* Loaded script: /usr/lib/YaST2/bin/y2start

* Loaded features:

    0 enumerator.so
    1 thread.rb
    2 rational.so
    3 complex.so
    4 /usr/lib64/ruby/2.5.0/x86_64-linux-gnu/enc/encdb.so
[...]
   87 /usr/lib64/ruby/vendor_ruby/2.5.0/yast/y2start_helpers.rb
   88 /local/home-mvidner/svn/yast/samba-server/src/modules/Fail.rb

* Process memory map:

00400000-00401000 r-xp 00000000 08:01 7766                               /usr/bin/ruby.ruby2.5
[...]
7fa42363b000-7fa42365c000 r--s 00000000 08:01 6998                       /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
[...]
7fa428a5f000-7fa428a60000 rw-p 00026000 08:01 1310795                    /lib64/ld-2.26.so
7fa428a60000-7fa428a61000 rw-p 00000000 00:00 0 
7fff30767000-7fff30f66000 rw-p 00000000 00:00 0                          [stack]
7fff30ff1000-7fff30ff4000 r--p 00000000 00:00 0                          [vvar]
7fff30ff4000-7fff30ff6000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

/sbin/yast2: line 455: 25102 Aborted                 (core dumped) $ybindir/y2start $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS

1. "(core dumped)" is lying

It means to say: Per /usr/lib/sysctl.d/50-coredump.conf the core has been sent
to /usr/lib/systemd/systemd-coredump which obeyed "ulimit -c 0" and did not
save it.
So let's

• use the ulimit -c unlimited command (bash shell builtin, actually)
• Let it crash again
• sudo coredumpctl dump -o core

Also note that without the dump subcommand, the core dump will be deleted
after a day. (Why?)

(To avoid systemd-coredump, you can use
sudo /usr/sbin/sysctl kernel.core_pattern="core.%p"; thanks lslezak)

1. gdb -c core is not useful without the executable

When we do that, the backtrace is very unhelpful:

(gdb) bt
#0  0x00007eff7d0140e0 in ?? ()
#1  0x0000000000000400 in ?? ()
#2  0xffffffffffffffff in ?? ()
#3  0xffffffffffffffff in ?? ()
#4  0xffffffffffffffff in ?? ()
#5  0xffffffffffffffff in ?? ()
#6  0xffffffffffffffff in ?? ()
#7  0xffffffffffffffff in ?? ()
#8  0xffffffffffffffff in ?? ()
#9  0xffffffffffffffff in ?? ()
#10 0xffffffffffffffff in ?? ()
#11 0xffffffffffffffff in ?? ()
#12 0xffffffffffffffff in ?? ()
#13 0xffffffffffffffff in ?? ()
#14 0x0000000000000000 in ?? ()

For some reason, gdb will not load the executable file even though it is named
in the core file. Do it by hand:

1. gdb program core

$ gdb /usr/bin/ruby.ruby2.5 core

[... lots of text that we'll get back to in the next section ...]
(gdb) bt
#0  0x00007eff7d0140e0 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007eff7d01579f in __GI_abort () at abort.c:100
#2  0x00007eff7d42be51 in die () at error.c:552
#3  0x00007eff7d42be51 in rb_bug_context (ctx=ctx@entry=0xcebac0, fmt=fmt@entry=0x7eff7d5925c4 "Segmentation fault at %p") at error.c:582
#4  0x00007eff7d4f0eb2 in sigsegv (sig=11, info=0xcebbf0, ctx=0xcebac0) at signal.c:928
#5  0x00007eff7d014160 in <signal handler called> () at /lib64/libc.so.6
#6  0x00007eff78c15677 in YRuby::callInner(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, YCPList, constPtr<Type, Type>) () at /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
#7  0x00007eff78c19d80 in Y2RubyFunction::evaluateCall() () at /usr/lib64/YaST2/plugin/libpy2lang_ruby.so

Note that the frames 0 to 4 show the source code locations (file name and line
number) as well as the argument names and values. It's because gdb has found
the debugging information for glibc and the Ruby library:

(gdb) info sh libc
From                To                  Syms Read   Shared Object Library
0x00007eff7cffe770  0x00007eff7d14365c  Yes         /lib64/libc.so.6
0x00007eff7c981cd0  0x00007eff7c9895e8  Yes         /lib64/libcrypt.so.1
0x00007eff73c256f0  0x00007eff73c27007  Yes (*)     /usr/lib64/libcap.so.2
0x00007eff6972ca10  0x00007eff69731b65  Yes         /usr/lib64/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so
(*): Shared library is missing debugging information.
(gdb) info sh ruby
From                To                  Syms Read   Shared Object Library
0x00007eff7d3c73c0  0x00007eff7d566ea8  Yes         /usr/lib64/libruby2.5.so.2.5
0x00007eff7c433850  0x00007eff7c4344c0  Yes (*)     /usr/lib64/ruby/2.5.0/x86_64-linux-gnu/enc/encdb.so
[...]
0x00007eff7b9ec2c0  0x00007eff7b9f4cb0  Yes (*)     /usr/lib64/ruby/vendor_ruby/2.5.0/x86_64-linux-gnu/yastx.so
0x00007eff78c0fc00  0x00007eff78c1e740  Yes (*)     /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
0x00007eff789f82a0  0x00007eff78a001a5  Yes (*)     /usr/lib64/ruby/vendor_ruby/2.5.0/x86_64-linux-gnu/yast/builtinx.so
(*): Shared library is missing debugging information.

info sh is short for info sharedlibrary. If you omit the library name filter, the
length of the list will easily obscure the "(*)" footnote.

1. Add debuginfo

On openSUSE (and SUSE Linux Enterprise), the debugging symbols are in separate
RPM packages:

zypper in yast2-ruby-bindings-debug{info,source}

Or take the hint from the gdb message that we omitted in the previous section:

Missing separate debuginfo for /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
Try: zypper install -C "debuginfo(build-id)=8c6a1d943255c6f935e029140e75b49b1b7c22fb"

After restarting gdb:

(gdb) bt
[...]
#5  0x00007eff7d014160 in <signal handler called> () at /lib64/libc.so.6
#6  0x00007eff78c15677 in rb_array_len (a=8) at /usr/include/ruby-2.5.0/ruby/ruby.h:2057
#7  0x00007eff78c15677 in YRuby::callInner(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, YCPList, constPtr<Type, Type>) (this=this@entry=0xfefcc0, module_name=..., function=..., argList=..., wanted_result_type=...) at /usr/src/debug/yast2-ruby-bindings-4.0.6-lp150.1.1.x86_64/src/binary/YRuby.cc:220
[...]

In frame #6, rb_array_len (a=8), is the a argument equal to nil?
Let's check:

(gdb) p Qnil
No symbol "Qnil" in current context.

That's misleading! Although Qnil is defined in a header, and you've been
taught to prefer static const int to macros because of macros being
"global", they are in fact not as much global as for gdb to see them now. We
have to select a frame to have a context of a compilation unit.

(gdb) f 6
#6  rb_array_len (a=8) at /usr/include/ruby-2.5.0/ruby/ruby.h:2057
2057        return (RBASIC(a)->flags & RARRAY_EMBED_FLAG) ?
(gdb) p Qnil
No symbol "Qnil" in current context.

WTF?! Well, having debugging information loaded is not enough, the debuginfo
must have an elevated level that includes the macros.

1. Debuginfo with macros

Instead of the -g flag to gcc, I had to specify -g3 in CFLAGS and
rebuild and reinstall. After that, finally:

(gdb) f 6
#6  rb_array_len (a=8) at /usr/include/ruby-2.5.0/ruby/ruby.h:2057
2057        return (RBASIC(a)->flags & RARRAY_EMBED_FLAG) ?
(gdb) p Qnil
$1 = 8
(gdb) f 7
#7  YRuby::callInner (this=this@entry=0xfefcc0, module_name=..., function=..., argList=..., wanted_result_type=...) at /usr/src/debug/yast2-ruby-bindings-4.0.6-lp150.1.1.x86_64/src/binary/YRuby.cc:220
220         VALUE backtrace = RARRAY_LEN(trace)>0 ? rb_ary_entry(trace, 0) : rb_str_new2("Unknown");

So a = 8 and Qnil is 8, so we have confirmed that the trace array being
nil is causing the crash.

(For the record, this is bsc#1119690.)

Since a few days ago, librsvg's library implementation is almost 100% Rust code. Paolo Borelli's and Carlos Martín Nieto's latest commits made it possible.

What does "almost 100% Rust code" mean here?

• The C code no longer has struct fields that refer to the library's real work. The only field in RsvgHandlePrivate is an opaque pointer to a Rust-side structure. All the rest of the library's data lives in Rust structs.

• The public API is implemented in C, but it is just stubs that immediately call into Rust functions. For example:

gboolean
rsvg_handle_render_cairo_sub (RsvgHandle * handle, cairo_t * cr, const char *id)
{
    g_return_val_if_fail (RSVG_IS_HANDLE (handle), FALSE);
    g_return_val_if_fail (cr != NULL, FALSE);

    return rsvg_handle_rust_render_cairo_sub (handle, cr, id);
}

• The GObject boilerplate and supporting code is still in C: rsvg_handle_class_init and set_property and friends.

• All the high-level tests are still done in C.

• The gdk-pixbuf loader for SVG files is done in C.

Someone posted a chart on Reddit about the rustification of librsvg, comparing lines of code in each language vs. time.

Rustifying the remaining C code

There is only a handful of very small functions from the public API still implemented in C, and I am converting them one by one to Rust. These are just helper functions built on top of other public API that does the real work.

Converting the gdk-pixbuf loader to Rust seems like writing a little glue code for the loadable module; the actual loading is just a couple of calls to librsvg's API.

Rsvg-rs in rsvg?

Converting the tests to Rust... ideally this would use the rsvg-rs bindings; for example, it is what I already use for rsvg-bench, a benchmarking program for librsvg.

I have an unfinished branch to merge the rsvg-rs repository into librsvg's own repository. This is because...

1. Librsvg builds its library, librsvg.so
2. Gobject-introspection runs on librsvg.so and the source code, and produces librsvg.gir
3. Rsvg-rs's build system calls gir on librsvg.gir to generate the Rust binding's code.

As you can imagine, doing all of this with Autotools is... rather convoluted. It gives me a lot of anxiety to think that there is also an unfinished branch to port the build system to Meson, where probably doing the .so→.gir→rs chain would be easier, but who knows. Help in this area is much appreciated!

An alternative?

Rustified tests could, of course, call the C API of librsvg by hand, in unsafe code. This may not be idiomatic, but sounds like it could be done relatively quickly.

Future work

There are two options to get rid of all the C code in the library, and just leave C header files for public consumption:

1. Do the GObject implementation in Rust, using Sebastian Dröge's work from GStreamer to do this easily.

2. Work on making gnome-class powerful enough to implement the librsvg API directly, and in an ABI-compatible fashion to what there is right now.

The second case will probably build upon the first one, since one of my plans for gnome-class is to make it generate code that uses Sebastian's, instead of generating all the GObject boilerplate by hand.

Chafa (github) started out as a small piece of supporting code for an obscure personal project I may announce at some indefinite point in the future. Then I decided to release it as a tongue-in-cheek thing for the VT100 anniversary last year, and, well… it gathered a bit of steam.

Chafa 1.0

Since I'm not one to leave well enough alone, I packaged it up over the holidays for the 1.0 release. It brings a pile of improvements, e.g. new symbol ranges like ASCII and Braille, better image preprocessing and a new --fill option for halftone/dithering. It's also, like, real fast now, and the build is much less brittle.

Big thanks to everyone who contributed to this release: Adam Borowski, Felix Yan, Lajos Papp, Mo Zhou, Ricardo Arguello, Robert-André Mauchin, @dcb314 and @medusacle.

You'll find packages out there for Arch, Debian, Fedora, Gentoo and Ubuntu now; check your repositories. Extra big thanks to the package maintainers.

As the post title implies, I think Chafa is now the least bad tool in this tiny but tradition-rich niche. So what's so not-quite-terrible about it?

Only the best for your aixterm

If you've been around text terminals for a while, you'll know what this means:

Up until fairly recently, the most colorful terminal applications would operate within the confines of some variant of the above palette, and many still do. It's a nice and distinct (not to mention cheerful) set of colors, but it's not a great match for most image material you'll come across, which makes legible Chafa output a challenge. And that is precisely why I had to try (here with a nice woodblock print):

The top left image is the best reproduction you can get with Chafa using a modern 24-bit color terminal emulator (in this case, GNOME Terminal) at 60 characters wide. At top right is the 16-color mapping you get without applying any tricks; this is pretty close to the mark given the muted moonlight colors of the input image, but it doesn't make good use of our palette, nor does it convey the essence of the scene very well. Blue sky, rolling hills, green grass. A shady waterfront pavilion. Given our limitations, the output will look nothing like the original anyway, so we're better off trying to capture the gist of it.

We do this simply by cranking up the contrast and saturation to levels where our cheerful old palette can do a decent job (bottom left). Chafa no longer relies on ImageMagick for this, so it's available in the library API, and integer-only math makes it performant enough to run in real time on animations and video (more on this in a later post, perhaps).

It gets even better if you do color assignment in DIN99d space (bottom right), but that's way slow, so you have to explicitly enable it.

No ANSI? No problem

You can generate varied output without any color codes at all. The above examples also demonstrate use of the --fg option, which, along with --bg, exists to tell Chafa what your terminal's default colors look like so it can target those, but is equally useful for tweaking monochrome output thresholds.

So if for some reason your terminal can't handle ANSI or you still have one of those warm & fuzzy monochrome tubes sitting around, we've got you covered. Or break out your civil rights-era dot-matrix printer and make some precision banners to hang in your lab!

You might have heard that openSUSE’s board elections are underway for three open seats to be filled. I’ve been thinking about running for board for a while and now it seems to be the right time to step up.

The following text is a plain, unedited copy of my application.

Introduction, Biography and Contributions

My name is Vinzenz Vietzke but sticking with the much short “vinz” or “vinzv” is what I prefer. I’m 34 years, live in a small town in southern Germany. Like most German Linux users around my age I made my first steps with S.u.S.E. back in the late 90s. Over the years I moved across various distributions and contributed to quite a few of them in different ways. My day job is product management and marketing at Linux hardware vendor TUXEDO Computers.

openSUSE and TUXEDO

Starting with just one laptop running openSUSE we at TUXEDO now offer around 20 different models plus a wide range of desktop PCs all with Leap 15 pre-installed. Customers also get free lifetime support for their preinstalled system. Therefore of course our free phone/email tech support team need to be trained for openSUSE as well. For this whole project I was and still am in charge as the tech and project lead so to say to “bring” openSUSE on TUXEDO’s computers. I got in touch with oS, worked out how and when we get everything done.

In addition to technical affairs I’m the pushing person at TUXEDO Computers to make our company step up supporting openSUSE. As a result since October 2018 we are officially sponsoring the openSUSE project. We offer any of our models as demo and workshop devices at no cost and take care for the logistics and event booth support. Furthermore we’re sponsoring oSC19 in Nuremberg with demo and install fest machines.

Of course these things are mainly financial efforts and company internal projects. But yet to get openSUSE a wider reception there needs to be someone coordinating, pushing and taking care. That’s why I call my contributions to openSUSE mostly “meta contributions”.

i18n

Besides the TUXEDO stuff which is partly paid and partly free time efforts I’m coordinating translation teams of upstream Xfce, actively translating openSUSE and quite a lot of other projects. For details please check my profiles at Crowdin, Gnome, Transifex as well as my personal website.

Aims/Goals

Like every volunteer-run project openSUSE has it’s issues to tackle. Most of them are obvious and already under work: consolidating web appearances, cleaning the wiki, sorting out the communication infrastructure and possible extensions to it. I don’t think there’s anything further needed to push these things besides time. The board has done a really awesome job in the past on these things and surely will in the future.

Major and Minor Issues

One of the major issues I experience is public reception like in how openSUSE as a distribution is seen. When people talk about openSUSE they’re mostly telling from their experiences they made (literally!) a decade ago. You ran into some YaST issues in 2011 and this is why you stopped recommending openSUSE and you never ever re-thought your opinion? Jeez. These memories need to get overhauled and put into correct contexts. Most of them are prejudices anyway.

On the other side people who have heard about Linux but hardly any knowledge mostly equate one specific distribution with Linux. Though it’s not technically correct end-users do this – which is fine. But they don’t equate it with openSUSE and that is shame. oS really has come a long way and is easy to install, to run and to use. People just need to know about and this is where the prejudices mentioned earlier come into play. The “tech guy” inside a circle of friends is some multiplier and needs to be convinced that openSUSE is something he totally can recommend in good conscience.

Role of the board

From my perspective the board has two main roles: First and foremost it is some kind of service provider. It serves the whole project as contact point for questions, projects coordination and pointing in directions etc. This is crucial for the whole openSUSE project and should never be changed but merely extended if possible.

The second role might be named as “ideas sparking pot”. Most ideas coming from the community are of a technical nature which is entirely logical. Just sometimes there are things that the whole project would benefit from but no one sees them or has time to do so. This is where the board could jump in throwing sparks and giving input from someone being able to take a step back for viewing the bigger picture.

My role in this board team would both being approachable and helpful for part one. But also to give thoughts and ideas when needed, especially in the second part mentioned.

Why you should vote for me?

I’ve been into Linux and open source communities for about 10 years now. Though I’m not a long term contributor for openSUSE I know how “things work” in such a big, diverse project and how to handle this stuff. If you want to get someone with no “Geeko glasses” on you should vote for me. Not that being deeply inside openSUSE’s community is a bad thing! But I can bring in new perspectives, most of them related to end-users, Windows-ditchers and curious but not tech-savvy people. I both understand developers and tech people on the one hand as well as people who are buying Linux preinstalled hardware with little will to tinker around. This way I act as some proxy between those worlds which in the end might be good for everyone involved.

Conclusion

As elaborated above my main goal boils down to people thinking of easy but powerful Linux when they hear openSUSE. The project in total is big and strong enough to really serve as “the makers’ choice for sysadmins, developers and desktop users” – all of them!

Ask me anything

If you made it this far – thanks for your time and interest. For any questions, comments or disagreements feel free to contact me. I appreciate any of it via:

• Email
• XMPP
• IRC (user: vinzv)

Dos mesitas de noche:

• Parte 1: Preparar las piezas
• Parte 2: Marcar las patas
• Parte 3: Los cajones

En la parte 1 preparé la madera para todas las piezas principales de las mesitas de noche / burós. Esto es lo que voy a construir:

Siempre me da nervios que las patas sean tan delgadas que no vayan a aguantar las cajas/espigas a 90° que las unen a los travesaños y a los faldones. Hice un dibujito a escala 1:1 de los ensambles, para ver dónde debían quedar, y para convencerme a mí mismo de que en efecto las patas son suficientemente anchas.

Aquí, los travesaños están a 90° uno del otro y se encuentran con un corte a 45° en las espigas. Todas las medidas las determina el ancho del formón, en este caso, ¼ de pulgada. ¿Por qué pulgadas? Porque las herramientas que tengo así vienen. No me importa mucho la medida numérica de las piezas, pues las marcas que hago en las piezas de madera no son con regla con numeritos, sino que se hacen a partir de un escantillón.

El dichoso escantillón

Una forma muy conveniente de marcar la madera es poner cada pieza sobre un dibujo a escala 1:1 y luego hacer las marcas, en vez de hacerse bolas con una regla con numeritos. Pero para evitarse tener dibujos tan grandes, para piezas no muy complicadas como ésta, se puede hacer un escantillón con una tira de madera: es una guía a escala 1:1 que contiene todas las medidas importantes de la pieza. El escantillón se pone junto a cada pieza y se usa para marcar directo en la pieza, sin andar midiendo con regla. Así no hay errores de medición.

Una de las caras de la tira de madera se usa para marcar las dimensiones verticales, y otra cara para las horizontales. Por ejemplo, aquí transfiero las posiciones horizontales de dónde van las espigas con respecto a las patas:

Cada marca se hace con cuchillo sobre la esquina de la tira de madera. Además, cada marca se pinta con lápiz para poder verla fácilmente, o para hacerle anotaciones y saber cuál es cuál.

Luego, marco todo el ancho del buró en esa cara de la tirita de madera: las dos patas a 40cm una de la otra, y cada pata con su espiga para el travesaño o el faldón.

En la foto siguiente sólo salen esas marcas de una de las patas, y el centro horizontal del buró — que luego me servirá para ubicar la jaladera del cajón.

De igual manera, en otra de las caras del escantillón pongo las dimensiones verticales: la altura final de las patas, y las posiciones del travesaño inferior, el travesaño debajo del cajón y los faldones.

Marcar los travesaños

Aquí es donde el escantillón entra en acción. El chiste es marcar todas las piezas iguales al mismo tiempo, para minimizar errores. Aquí tengo prensados todos los travesaños. Transfiero las marcas del largo total de los travesaños y la posición de las espigas. Para transferir la posición, el cuchillo de marcar se hace entrar en la marca que había en el escantillón, y esto hace que también quede marcada la esquina de una de las piezas.

Se pone el cuchillo de marcar en una de las ranuritas de las marcas, se hace coincidir la escuadra con el cuchillo, y se marcan todas las piezas de un jalón:

Por ahora, lo único que hay que cortar es el largo final de los travesaños. Muevo con cuidado las prensas para no desalinear los travesaños y los serrucho todos de un jalón para que queden idénticos:

Marcar las patas

De igual manera, hay que marcar las patas en su dimensión vertical, es decir, a lo largo. Aquí está la parte interesante del escantillón para las patas:

Se transfieren las marcas...

... se marcan las patas al mismo tiempo con escuadra y cuchillo. Aquí lo hice de cuatro en cuatro, porque es para lo que alcanza mi escuadrita.

Así quedan marcadas todas las patas perfectamente iguales.

¿Cómo distinguimos las patas?

Las patas izquierdas y derechas son imágenes de espejo entre sí, pues el buró es simétrico. Pero las patas traseras y delanteras no lo son: cada pata trasera une dos faldones, pero cada pata delantera une un faldón y el travesaño del cajón.

Para no hacerse bolas, se dibujan triángulos en el extremo de cada juego de patas. La mesita número 1 tiene un triángulo sencillo, y la mesita número 2 tiene un triángulo con líneas dobles:

Así, si las patas se desacomodan, podemos volver a orientarlas armando el triángulo.

Extender las marcas alrededor de las patas

Al marcar todas las patas al mismo tiempo, sólo quedo marcada una de las caras. Sin embargo, se requieren las mismas marcas en una de las caras adyacentes. Hay que tomar cada pata y transferir cada marca de forma individual. Se puede hacer así, o volviendo a prensar todas las patas según lo requieren.

Marcas con el gramil

Ahora hay que poner la posición de las espigas. Se puede ajustar el gramil junto al escantillón, o transferir las medidas al gramil con una regla; aquí hice lo segundo a partir del escantillón. La separación entre las puntas del gramil es de ¼", igual que el ancho del formón:

Ahora se marca cada pata con el gramil, en el área de cada espiga. Como la espiga no está centrada en ancho de la pata, tuve que tener cuidado de hacer las marcas con respecto a la cara exterior, pues así estaba puesto el gramil.

Así se ven las puntas del gramil al hacer las marcas:

Este proceso se lleva un buen tiempo; son 44 espigas que hay que marcar. Al final verifiqué que en efecto hubiera puesto todas las marcas en donde deben ir; es fácil confundirse y marcar con respecto a la cara incorrecta.

Cortar las cajas con el formón

Ahora hay que cortar las cajas donde van a ir las espigas. Puse cinta azul en el formón para marcar la profundidad máxima a la que debe llegar.

Hay varias técnicas para formonear cajas. Me gusta la de comenzar un corte en V al centro de la caja, con el formón inclinado, ir haciendo la V más grande hacia los extremos.

El último corte en cada extremo es con el formón vertical, para definir la pared de la caja.

Luego hay que batallar un rato con el formón para sacar la basurita.

Las cajas donde van las espigas de los travesaños se encuentran entre sí; es un túnel en la madera en forma de L. Aquí se puede ver el formón desde el otro lado.

Aquí hay un video de cómo corté una caja.

Y bien, fueron dos sesiones a lo largo de dos días de cortar y cortar cajas. Son 44 entre las dos mesitas:

En la parte 1 preparé la madera para todas las piezas principales de las mesitas de noche / burós. Esto es lo que voy a construir:

Siempre me da nervios que las patas sean tan delgadas que no vayan a aguantar las cajas/espigas a 90° que las unen a los travesaños y a los faldones. Hice un dibujito a escala 1:1 de los ensambles, para ver dónde debían quedar, y para convencerme a mí mismo de que en efecto las patas son suficientemente anchas.

Aquí, los travesaños están a 90° uno del otro y se encuentran con un corte a 45° en las espigas. Todas las medidas las determina el ancho del formón, en este caso, ¼ de pulgada. ¿Por qué pulgadas? Porque las herramientas que tengo así vienen. No me importa mucho la medida numérica de las piezas, pues las marcas que hago en las piezas de madera no son con regla con numeritos, sino que se hacen a partir de un escantillón.

El dichoso escantillón

Una forma muy conveniente de marcar la madera es poner cada pieza sobre un dibujo a escala 1:1 y luego hacer las marcas, en vez de hacerse bolas con una regla con numeritos. Pero para evitarse tener dibujos tan grandes, para piezas no muy complicadas como ésta, se puede hacer un escantillón con una tira de madera: es una guía a escala 1:1 que contiene todas las medidas importantes de la pieza. El escantillón se pone junto a cada pieza y se usa para marcar directo en la pieza, sin andar midiendo con regla. Así no hay errores de medición.

Una de las caras de la tira de madera se usa para marcar las dimensiones verticales, y otra cara para las horizontales. Por ejemplo, aquí transfiero las posiciones horizontales de dónde van las espigas con respecto a las patas:

Cada marca se hace con cuchillo sobre la esquina de la tira de madera. Además, cada marca se pinta con lápiz para poder verla fácilmente, o para hacerle anotaciones y saber cuál es cuál.

Luego, marco todo el ancho del buró en esa cara de la tirita de madera: las dos patas a 40cm una de la otra, y cada pata con su espiga para el travesaño o el faldón.

En la foto siguiente sólo salen esas marcas de una de las patas, y el centro horizontal del buró — que luego me servirá para ubicar la jaladera del cajón.

De igual manera, en otra de las caras del escantillón pongo las dimensiones verticales: la altura final de las patas, y las posiciones del travesaño inferior, el travesaño debajo del cajón y los faldones.

Marcar los travesaños

Aquí es donde el escantillón entra en acción. El chiste es marcar todas las piezas iguales al mismo tiempo, para minimizar errores. Aquí tengo prensados todos los travesaños. Transfiero las marcas del largo total de los travesaños y la posición de las espigas. Para transferir la posición, el cuchillo de marcar se hace entrar en la marca que había en el escantillón, y esto hace que también quede marcada la esquina de una de las piezas.

Se pone el cuchillo de marcar en una de las ranuritas de las marcas, se hace coincidir la escuadra con el cuchillo, y se marcan todas las piezas de un jalón:

Por ahora, lo único que hay que cortar es el largo final de los travesaños. Muevo con cuidado las prensas para no desalinear los travesaños y los serrucho todos de un jalón para que queden idénticos:

Marcar las patas

De igual manera, hay que marcar las patas en su dimensión vertical, es decir, a lo largo. Aquí está la parte interesante del escantillón para las patas:

Se transfieren las marcas...

... se marcan las patas al mismo tiempo con escuadra y cuchillo. Aquí lo hice de cuatro en cuatro, porque es para lo que alcanza mi escuadrita.

Así quedan marcadas todas las patas perfectamente iguales.

¿Cómo distinguimos las patas?

Las patas izquierdas y derechas son imágenes de espejo entre sí, pues el buró es simétrico. Pero las patas traseras y delanteras no lo son: cada pata trasera une dos faldones, pero cada pata delantera une un faldón y el travesaño del cajón.

Para no hacerse bolas, se dibujan triángulos en el extremo de cada juego de patas. La mesita número 1 tiene un triángulo sencillo, y la mesita número 2 tiene un triángulo con líneas dobles:

Así, si las patas se desacomodan, podemos volver a orientarlas armando el triángulo.

Extender las marcas alrededor de las patas

Al marcar todas las patas al mismo tiempo, sólo quedo marcada una de las caras. Sin embargo, se requieren las mismas marcas en una de las caras adyacentes. Hay que tomar cada pata y transferir cada marca de forma individual. Se puede hacer así, o volviendo a prensar todas las patas según lo requieren.

Marcas con el gramil

Ahora hay que poner la posición de las espigas. Se puede ajustar el gramil junto al escantillón, o transferir las medidas al gramil con una regla; aquí hice lo segundo a partir del escantillón. La separación entre las puntas del gramil es de ¼", igual que el ancho del formón:

Ahora se marca cada pata con el gramil, en el área de cada espiga. Como la espiga no está centrada en ancho de la pata, tuve que tener cuidado de hacer las marcas con respecto a la cara exterior, pues así estaba puesto el gramil.

Así se ven las puntas del gramil al hacer las marcas:

Este proceso se lleva un buen tiempo; son 44 espigas que hay que marcar. Al final verifiqué que en efecto hubiera puesto todas las marcas en donde deben ir; es fácil confundirse y marcar con respecto a la cara incorrecta.

Cortar las cajas con el formón

Ahora hay que cortar las cajas donde van a ir las espigas. Puse cinta azul en el formón para marcar la profundidad máxima a la que debe llegar.

Hay varias técnicas para formonear cajas. Me gusta la de comenzar un corte en V al centro de la caja, con el formón inclinado, ir haciendo la V más grande hacia los extremos.

El último corte en cada extremo es con el formón vertical, para definir la pared de la caja.

Luego hay que batallar un rato con el formón para sacar la basurita.

Las cajas donde van las espigas de los travesaños se encuentran entre sí; es un túnel en la madera en forma de L. Aquí se puede ver el formón desde el otro lado.

Aquí hay un video de cómo corté una caja.

Y bien, fueron dos sesiones a lo largo de dos días de cortar y cortar cajas. Son 44 entre las dos mesitas: