In my experience, a small SSD becomes a bit of a bother though (when you inevitably start to run out of space on it) so consider investing in something at least 256 GB IMO. It won't be as cheap, but it should be twice as useful.

Append:

I finally figured out the main cause of memory leaks in my "falling block" clone.

diff --git a/main.c b/main.c
index 1d24935..b02a1ae 100644
--- a/main.c
+++ b/main.c
@@ -323,8 +323,10 @@ static void apply_movements(GAME_STATE * S) {
         LINKED_LIST * collisions = NULL;
 
         if(!detect_collisions(S, piece, &collisions) || collisions) {
-            while(collisions != NULL) {
-                COLLISION * collision = collisions->data;
+            LINKED_LIST * it = collisions;
+
+            while(it != NULL) {
+                COLLISION * collision = it->data;
 
                 print_collision(collision);
 
@@ -334,7 +336,7 @@ static void apply_movements(GAME_STATE * S) {
                     S->respawn = 1;
                 }
 
-                collisions = collisions->next;
+                it = it->next;
             }
 
             list_destroy(&collisions,

I was iterating over my collisions list to print them out (diagnostics) and to check if a new piece needs to respawn. The result is that by the time I got around to list_destroy() to free up the memory, the pointer was pointing to NULL because it was the end of the list... By using an iterator variable to step through the list that problem is solved and both the list and the collisions in the list get cleaned up properly.

However, I still have some leaks reported by valgrind.

 HEAP SUMMARY:
     in use at exit: 229,801 bytes in 1,958 blocks
   total heap usage: 44,855 allocs, 42,897 frees, 18,449,114 bytes allocated

 9 bytes in 1 blocks are definitely lost in loss record 7 of 1,522
    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x5F0DC17: _XlcDefaultMapModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x5F0DFE5: XSetLocaleModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x50F0DCF: x_keyboard_init (xkeyboard.c:760)
    by 0x50F0DCF: xkeybd_init_keyboard (xkeyboard.c:929)
    by 0x50AD3E9: al_install_keyboard (keybdnu.c:129)
    by 0x402D10: initialize (in /mnt/data/home/bambams/src/tetrist/game)
    by 0x401919: main (in /mnt/data/home/bambams/src/tetrist/game)

 32 bytes in 1 blocks are definitely lost in loss record 487 of 1,522
    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x5739889: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
    by 0x50EFF09: _al_xglx_config_create_context (xglx_config.c:570)
    by 0x50EC41C: xdpy_create_display_locked (xdisplay.c:438)
    by 0x50ECBF2: xdpy_create_display (xdisplay.c:583)
    by 0x50A67D4: al_create_display (display.c:53)
    by 0x402D30: initialize (in /mnt/data/home/bambams/src/tetrist/game)
    by 0x401919: main (in /mnt/data/home/bambams/src/tetrist/game)

 496 (48 direct, 448 indirect) bytes in 2 blocks are definitely lost in loss record 1,499 of 1,522
    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0xA8BC2B9: ??? (in /usr/lib/x86_64-linux-gnu/dri/r600_dri.so)
    by 0x5110A32: _al_ogl_lock_region_new (ogl_lock.c:136)
    by 0x509144E: al_lock_bitmap_region (bitmap_lock.c:108)
    by 0x50915A7: al_lock_bitmap (bitmap_lock.c:129)
    by 0x5090288: transfer_bitmap_data (bitmap.c:579)
    by 0x5090288: al_clone_bitmap (bitmap.c:675)
    by 0x5093887: al_convert_bitmap (bitmap_type.c:177)
    by 0x5093DEA: _al_convert_to_memory_bitmap (bitmap_type.c:313)
    by 0x50EA9D7: convert_display_bitmaps_to_memory_bitmap (xdisplay.c:598)
    by 0x50EA9D7: xdpy_destroy_display (xdisplay.c:719)
    by 0x402681: deinitialize (in /mnt/data/home/bambams/src/tetrist/game)
    by 0x401A8A: main (in /mnt/data/home/bambams/src/tetrist/game)

 1,688 (136 direct, 1,552 indirect) bytes in 1 blocks are definitely lost in loss record 1,509 of 1,522
    at 0x4C2FD5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x5F041FC: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x5F04770: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x5F0604E: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x5F0687B: _XlcCreateLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x5F2768F: _XlcUtf8Loader (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x5F0DE4D: _XOpenLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x5F0DF87: _XlcCurrentLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x5F0DFBD: XSetLocaleModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
    by 0x50F0DCF: x_keyboard_init (xkeyboard.c:760)
    by 0x50F0DCF: xkeybd_init_keyboard (xkeyboard.c:929)
    by 0x50AD3E9: al_install_keyboard (keybdnu.c:129)
    by 0x402D10: initialize (in /mnt/data/home/bambams/src/tetrist/game)

 3,528 (400 direct, 3,128 indirect) bytes in 1 blocks are definitely lost in loss record 1,513 of 1,522
    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x5763A50: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
    by 0x573938C: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
    by 0x5739968: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
    by 0x50EFF09: _al_xglx_config_create_context (xglx_config.c:570)
    by 0x50EC41C: xdpy_create_display_locked (xdisplay.c:438)
    by 0x50ECBF2: xdpy_create_display (xdisplay.c:583)
    by 0x50A67D4: al_create_display (display.c:53)
    by 0x402D30: initialize (in /mnt/data/home/bambams/src/tetrist/game)
    by 0x401919: main (in /mnt/data/home/bambams/src/tetrist/game)

 LEAK SUMMARY:
    definitely lost: 625 bytes in 6 blocks
    indirectly lost: 5,128 bytes in 54 blocks
      possibly lost: 0 bytes in 0 blocks
    still reachable: 224,048 bytes in 1,898 blocks
         suppressed: 0 bytes in 0 blocks
 Reachable blocks (those to which a pointer was found) are not shown.
 To see them, rerun with: --leak-check=full --show-leak-kinds=all

 For counts of detected and suppressed errors, rerun with: -v
 ERROR SUMMARY: 359 errors from 8 contexts (suppressed: 0 from 0)

These all appear to be inside Allegro though which has me confused. I think I'm doing a decent job of cleaning up Allegro at the end of the program. I even tried adding al_uninstall_system() just to see if that would make a difference, but it didn't.. Is this a bug in Allegro or a bug in my program? :-/

OS. DEFINITELY.

Then put a couple games you want really fast at the time and swap them out as necessary.

Get a 256 GB or larger or you'll be sad. Because 128 GB gets eaten up almost IMMEDIATELY by the P.O.S. that is Windows 10. It keeps every VERSION of every driver it ever downloaded and if you delete them manually, it corrupts windows. (Don't forget >2GB for Candy Crush that you never asked for!)

SSD's may be faster, but one thing bothers me about them, and it is relatively minor, depending on how paranoid you are. And that is that you cannot run a program to erase old data from the drive, you know, to make certain it is really deleted like you can on standard HDDs.

If you're not worried about someone running software to recover your deleted files, than, no problem. I don't tend to worry about those sorts of things. Personally, I am happy with my standard HDD, it's cheaper and bigger.

The data erasing software is pretty good. It just doesn't work on an SDD due to how they save files.

I had a friend give me two systems with two hard drives. I have software that can recover files from a formatted drive and I couldn't get ANYTHING off of his drives, he was pretty through. It actually made me laugh at the time as he knew what I was like and that i could recover it. It showed me that the software for erasing was pretty good at what it does.

In another system I got, the drives were formatted and just a fresh OS was installed. I was able to recover most of their personal photos and what type of porn they liked to browse for. (I erased it all later, I just like to see what all I can recover, and this is OLD software that I use, like, 15 years old or more)

There is no try. Do or do not. Put the OS on the SSD. It will make your computer super fast at boot, and runtime. Do NOT put a swap file on the SSD it will shred your SSD.

Last thing you want is your OS responsive!

When I ran Valgrind to try and find my Allegro + DAllegro, D program, it was firing off like over a million events and stopped after that. Before my app loaded. It was during the Allegro "start an initial window and then close it." part.

Don't know if it's only on Linux, in Allegro, DAllegro, or a driver problem as the call stack goes all the way into the graphics driver. No idea.

I've had these for years on Linux with C/C++. I've tracked them a bit and got the impression that it was neither my nor Allegro's fault.

More so I want for the VM to keep track of where a particular function definition came from. E.g., foo.lisp:3,4. And it should be smart enough to scan the file again to find it even if the file has changed, but the hint would be enough so it didn't have to scan the entire source tree again. Once it found the function it would overwrite it with the newly defined function from the REPL, and then finish off the file with the remaining contents (effectively editing the function in-place). If this worked automatically then you wouldn't even need to touch the source files during your hacking session. You could just redefine functions and have them automatically persist in your source code. The only time you'd have to touch the files is when you wanted to refactor them somehow. The REPL could even have a function for sending a function to a file, and if the function didn't exist in the file yet, it'll be appended and remembered from then on. Smells like productivity.

I just remembered that Emacs basically allows you evaluate Lisp expressions under the cursor using a command. So in Emacs you kind of sort of don't have this problem because you can just evaluate the code in the REPL directly from the file. However, I can't get by using Emacs for every long because I find it's too cluttered and my Vim-fingers inevitably do something not supported by Evil-mode (or else I learn of an Emacs command that no longer works because I've overridden it with Evil-mode). In any case, I think that having editor integration can be a solution to help with it. If your REPL can be integrated into your editor then it can be made more easy I think. Sort of like an IDE, except without a damn mouse.

I don't know what started me down that rabbit hole, I but saw that on my feed on Youtube a while back.

One of the main things I've taken away from that (aside from the fact that I could never do it, but I think I understand it) is this:

2 TB SSD for $500 (USD probably). That is a bit expensive, but not as expensive as I might have imagined it.

{"name":"1m20tf.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/6\/766c0551542ac1385ce85d3b8451fcdc.jpg","w":504,"h":500,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/6\/766c0551542ac1385ce85d3b8451fcdc"}

[bamccaig]

For those that know how to pick a lock, it doesn't quite work that way. Funny nevertheless.