Spent about 2 hours tonight, mostly reading make files. I think I’ve read all of the bsd.port* makefiles in /usr/share/mk and /usr/ports/Mk. Along with most of /usr/ports/Tools/* and a ton of stuff in /usr/share/mk/. While there is a lot of leg-work there as far as ports goes it doesn’t seem to be as complicated as I would have thought.

Made some changes to the prototype for the dialog to handle our way to ‘make config’ but it’s to late to work on it further on it. I need to set it up to store what options have been checked / unchecked so they can be used to get things set up to run make.

if I didn’t have the small problem of getting up for work tomorrow I’d have that done tonight…

So far, work on this program has been fairly easy, the main problems I am anticipating is sorting out the final-form of the main GUI. I’ve been using the 2nd style that I posted awhile back, for the prototype but I can still replace it with another quite easy once the rest of the work is done.

I may have 0 formal education when it comes to Computers or Programming. But I am accustomed to doing things the way I am doing them now. Namely trying to implement things in as small and manageable sections as possible; where each section only handles as much as necessary and relies on as little as possible out-side of it’s related code. I like it when things can be tested as stand-alone as possible and then modified/rewritten as part of the larger program. You could say I’m not a fan of 10,000 line monolithic modules that do their job plus everything but recreate emacs lol.

I test the sections making sure that it does what I need it to. Then experiment with it to see how it reacts, and incorporate it into the rest of the project based on what was learned from that prototype. This is just the way I like to tackle the problem of writing a program.

I’m more used to dealing with C and a mess of .c/.h files but python is quite nice. And it has allowed me to spend most of my time concentrating on building a working program, solving the problems not tinkering around with GDB or malloc() more then thinking about how to best make stuff work.

I hate debuggers… But some times they are necessary. My favorite method of coping with some thing that doesn’t work as anticipated is go back to the code and apply brain power. Why doesn’t it work and why does it do what it does instead? Although I must admit GDB is invaluable when needed. But I’ve rarely needed to use a debugger outside of C and C++, and even then usually to track down a stray pointer or get a backtrace.