1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
(use-modules (chickadee)
(chickadee graphics text)
(chickadee math vector)
(chickadee scripting))
(define start-time 0.0)
(define avg-frame-time 16.0)
(define stats-text "")
(define stats-position (vec2 4.0 704.0))
(define position (vec2 140.0 0.0))
(define text
"This is the \"Are you tired of *this*?\" part of the infomercial. Read the next few paragraphs
and picture me, in black and white, struggling to hold a large stack of boxes, all labeled
\"software.\" I continue struggling to balance the boxes as you read. When you've reached the last
paragraph of the section, I fall over, the boxes land on top of me and all over the floor, I'm
covered in spaghetti, and in an exasperated voice I shout \"There's gotta be a better way!\"
When setting up a new computer for software development, I want to go from `git clone` to `make` in
as little time as possible (adjust that for your VCS and build system of choice.) In the old days,
this meant manually installing the dependencies through the distro package manager. If things are
organized, the project README will have a list of what is needed and it's not so bad. If things are
less organized, it's a cycle of installing packages and running `./configure` or whatever until it
succeeds. Hopefully none of the dependencies are too new to be found in the distro. And when
working on multiple projects, hopefully there's no conflicts between the dependencies required for
each of them, because your development environment is the entire system and there's no way to
isolate different projects from each other.
Of course, different programming languages provide their own sets of tools for managing multiple
projects. Python has virtualenv, Ruby has rvm and bundler, Node has nvm and npm, etc. But their
domain is restricted to only the dependencies for that language and their runtimes. A system
package manager is needed to bootstrap their use.
Nowadays it's \"just use Docker.\" Docker's take is that all this package management stuff is just
too complicated. Instead, just create a disk image per project that encapsulates this hodgepodge of
package managers and bespoke, artisinal, small-batch builds that gets run in isolation via Linux
namespace magic. It works, of course, but I think Dockerfiles are clunky and the rather extreme
level of isolation is usually unnecessary and makes things overly complicated for projects that need
to interact with, say, the windowing system of the host computer. A lot of people are happy with
Docker, though. Maybe you are, too. That's fine!
What I really want to say is \"Computer, provision a development environment containing Guile 3,
SDL2, make, and texinfo!\" and have Majel Barrett-Roddenberry tell me that all of those things have
been made available to me on my host system. No container, no virtual machine. It shouldn't matter
if I have Guile 2 installed system-wide, Guile 3 should still be what's used in the context of the
project. This is how Guix works and it's very good and cool and I'm going to tell you all about how
I use it."
;; "The quick brown fox jumps over the lazy dog.\nFive hexing wizard bots jump quickly."
)
(define (stats-message)
(format #f "fps: ~1,2f"
(/ 1.0 avg-frame-time)))
(define (load)
(script
(forever
(sleep 60)
(set! stats-text (stats-message)))))
(define (draw alpha)
(draw-text text position)
(draw-text stats-text stats-position)
(let ((current-time (elapsed-time)))
(set! avg-frame-time
(+ (* (- current-time start-time) 0.1)
(* avg-frame-time 0.9)))
(set! start-time current-time)))
(define (update dt)
(update-agenda 1))
(define (key-press key modifiers repeat?)
(when (eq? key 'q)
(abort-game)))
(run-game #:draw draw
#:key-press key-press
#:load load
#:update update
#:window-title "text rendering"
#:window-width 1280
#:window-height 720)
|
