5 ms·
This may seem strange to you, but this is actually the way many lisp systems (and other image-based development systems, like Smalltalk) work. I build software
by tumba 10y ago
This may seem strange to you, but this is actually the way many lisp systems (and other image-based development systems, like Smalltalk) work.
I build software using the commercial develop environment Allegro Common Lisp and an image dump is precisely the way I deliver software. The ultimate deliverable is an executable that loads the image and launches the main execution thread.
- weavie 10y agoThis works really well for us. To load up our web server takes a while due to having to load up caches etc.. so we tend to do all that once, dump the image and deploy it - cache already primed. It had an even bigger advantage for me today. Due to some git shenanigans I somehow managed to wipe out a few days of work. No idea how... Almost resigning myself to having to recode the whole lot I just remembered that I had built an image to test just prior to attempting to check in. Clozure CL saves the source code of each function in the image. I was able to probe the image and pull out all the source code that I had just lost, saving myself a few days of tedious recoding! Not a recommended use of images - but it sure saved my butt today!
- gkop 10y ago> Due to some git shenanigans I somehow managed to wipe out a few days of work. What happened??
- weavie 10y agoI actually have no idea. I had a lot of unchecked work - about a weeks worth. (I know, I should not have let it go that far.. it was just one of those tasks that just seemed to get bigger and bigger.) It was time to check in, so I went through file by file staging it all (using Magit). I then decided to do some more testing. Built a lisp image. Then I became distracted, started thinking about home time etc... so my recollection of what I did is a little hazy. I think I saw I had some changes that I wasn't wanting to commit and test. So I think I stashed them. Then probably surfed hacker news or something.. When I got back to things I suddenly noticed that none of my changes were there any more. Nothing was staged, nothing was stashed. It was all gone. I spent a few hours looking around for it but all to no avail. It is the second time I have lost work by misusing git. I think the other time I was messing with rebasing and branching and all my work disappeared. I do really need to learn how to use git properly. But in the meantime I am not taking any more chances. I have set up a zone on our internal SmartOS server which uses ZFS. An hourly cron job on my machine rsyncs my source directory to the zone and then creates a ZFS snapshot. So, hopefully no matter how badly I use git now I will never be able to lose more than about an hours worth of work.
- gkop 10y agoThanks for the explanation! I am not a heavy user of git stash, so not sure if git reflog could have helped you, but I am grateful that somebody steered me toward git reflog early in my learning git. With reflog and frequent commits, it's very hard to lose work, short of deleting the entire project or its .git/ directory. rsync+ZFS also sounds like nice combo for running around git in order to prevent future mistakes destroying work.
- cesarb 10y ago> so I went through file by file staging it all When you stage a file in git, what it actually does is to create in its object database a blob with the contents of the staged file, and then it points the corresponding entry in the working tree index to the blob's hash. The blob object is only removed during the periodic garbage collection, and only after a configurable period of time since its creation has passed. Therefore, once you stage a change, git will keep a copy of it for at least two weeks unless configured otherwise. Even if nothing points to it anymore (due to, for instance, an errant git reset --hard), there are ways to find its object hash (something like git fsck --unreachable, or even a ls -lR in the object database directory), and once you have the hash, you can use git cat-file to retrieve its contents.
- gknoy 10y agoRecovering from a lisp image is pretty darned cool. :D > I had a lot of unchecked work - about a weeks worth > ... It is the second time I have lost work by misusing git I realize this is _off topic_, but one thing that helps me a lot is making regular small commits (that describe some small idea of the change), and then rebase them later once I get all the linting / tests fixed. (Obviously not on master ;)) It's easy to go too-granular here, but it's very handy to be able to reorder the commits, or squash "fixup" commits, to make things easier to review. I spend more time rebasing than I probably need to, but on the other hand I've never lost work. ;) For example (adapted from a PR I was working on this morning ;)) git commit -m "Add Clone Foo feature" git commit -m "Reorganize tests" git commit -m "Fix indentation" git commit -m "Add generator for Baz items" git commit -m "Add test of Clone Foo feature" git commit -m "fixup linting in application" git commit -m "fixup test linting" git commit -m "fix Foo test to use correct selector" git rebase --interactive master # reorder fixup commits, squash them together with the things they fix You can always rebase and squish all of these down into one commit later before you make your pull request (or, leave them as-is if your team is OK with un-squished PRs).
- na85 10y agoWhat sort of software do you develop? By that I mean what field are you in? Not a lot of commercial lisp projects make the news that I read.