Posts

Showing posts with the label python

My New Favorite Phone Game: termux

 A lot of people when bored pull out their phone and play games.  Games just don't do it for me for some reason.  I mean, I played chess for a while, and recently I tried Shoot Bubble and 5 Dice (generic Yahtzee), but for some reason I always forget I even have them available and I end up just scrolling Twitter :-/  My feed is pretty good, if someone gets overly political or negative (usually its a combination of the two) I block them, but stuff still leaks in.  Usually if Twitter is holding my attention for a long time it's because it's making me angry.  I don't like that.  I think I've found a better solution for when I'm bored and pull out my phone: termux . Termux is a linux command-line environment for Android.  It's a kinda like wsl (or cygwin if you are old like me) or Terminal.app, but for your phone.  It's almost linux but not quite.  Normally I find that very frustrating, especially if I'm trying to get real work done (you may ...

How To Retroactively Annex Files Already in a Git Repo

UPDATE : With current versions of git, I no longer recommend git annex or git LFS unless you really need to store your large files on a separate server from your git repository. Just add your large files to git like any other file and when you clone, you can avoid downloading the full repository history with git clone --filter=blob:none and use git as normal. Table of Contents How To Retroactively Annex Files Already in a Git Repo First Tries: filter-branch, filter-repo Success with git rebase –interactive Added binary files Deleted binary files Modified binary files Moved binary files Dealing with Tags Clean Up and Results How To Retroactively Annex Files Already in a Git Repo In my last post I talked about how surprisingly easy it is to use git annex to manage your large binary files (or even small ones). In this post, I'm going to show how hard it is to go back and fix the mistake you made when you decided not to learn and use git annex at the start of your p...

Environment Manager for More than Just Python

This whole virtualenv thing is pretty cool, but it has always seemed too specific to Python for me. Let me see if I can explain. At first I had no use for virtualenv whatsoever, I could just sudo apt-get install python-whatever and get what I needed. As my distro got older and I didn't want to update my whole system, I started using virtualenv and pip to install and manage python packages instead of apt. It's great, except that the postgresql packages that came with my distro were getting crusty too. Because postgresql is not a python package, I get no help from virtualenv. Does anyone else have this problem? How do you deal with it? This reminds me of a very old problem from the chip design (EDA, ASIC design, whatever you want to call it) world. To design chips you buy licenses for expensive simulators and synthesis tools, and those tools are constantly being revved, fixing old bugs, introducing new features, and unfortunately, introducing new bugs. Because of that...

New Build Tool: fabricate.py

I stumbled onto a new build tool today: fabricate . I can't believe how cool it is, and that nobody has thought of it before (OK, actually, one person did , but still!). You give it a command, and it runs the command with strace and looks for all the files the command reads and produces and uses those as the command's dependencies and outputs, respectively. The next time you run the command with fabricate, if the outputs don't exist or the dependencies have changed it re-runs the command, otherwise, it doesn't. In other words, it does all the work that you normally would try and do with make, automatically. Another cool thing about this is that it will work with anything. You don't have to write builders for it like you would for scons (another tool I looked at for a bit). I spent some time trying to get scons to run modelsim compiles and simulations for me, and it was way too hard to make it work. I just tried fabricate with a small modelsim job and it ...

Carefully Upgrading to Django 1.0

I’m a little behind, but I finally upgraded my family website to Django 1.0 . First of all, I wanted to keep the main site running my older version of django from subversion while having 1.0 installed and being used by the development version. First I added the old install to my apache configuration’s PythonPath. Here’s the diff: - PythonPath "['/home/bryan/web/murdockfamily'] + sys.path" + PythonPath "['/home/bryan/web/django_src', '/home/bryan/web/murdockfamily'] + sys.path" Then I deleted the symlinks to that django install from any site-packages locations: sudo rm /usr/lib/python2.4/site-packages/django /usr/lib/python2.5/site-packages/django /usr/local/lib/python2.5/site-packages/django Then reloaded apache: sudo /etc/init.d/apache2 reload And it seemed to still work. Next I untarred Django 1.0, and installed it: tar -zxvf /home/bryan/downloads/Django-1.0.tar.gz cd Django-1.0 python setup.py build sudo python s...

Python For "One-Hour" Scripts

I wrote a "quick" script at work yesterday. I always have to put "quick" in quotes when I do this. I try to be good and write code to automate repetitive tasks that I do. Many others have advocated this and I find it to be very good advice, especially if you are a programmer. For me it usually happens like this: I'm doing something repetitive or tedious and I think, hey, I could spend an hour and write a script to do this. Over my career I've used Perl, shell scripts, and Python to do this. In that order. Yes, I learned Perl before I learned shell scripting (bash and korn shell on HP-UX), and no, Python hasn't completely replaced shell scripting, but I've all but abandoned Perl (and for my real firmware work I program in C++, just so you know). Whenever this happens it always takes more than an hour to write one of these "one-hour scipts." Yes, I'll confess. Sometimes much longer. With Perl most tasks would only require a f...