tcepsa: (Cake)
Okay, I've managed to work out all of the major show-stoppers that I wrote about here and am moving on. That serial port not connecting problem? I had to give myself adequate permissions (or run PuTTY as root, hrm...) Not being able to compile? Apparently the latest version of avr-gcc doesn't support the straight-up Atmega328 anymore (or maybe that was never a real chip, or maybe it's fully compatible with the Atmega328p object file that one must now compile against). Fixed by telling it the compiler, "Heh, well, I know I said that I was using a 328, but what I meant was a 328p." (Yeah, super embarrassing. That compiler must think I'm a complete baka by now, considering the wacky stuff I keep asking it to do...)

Not able to use the native Arduino programming environment? Don't care! I have Emacs!
tcepsa: (Default)
Due the week after this coming Monday (i.e. ~10 days from now) a line-following Lego robot and an Arduino that will blink an LED in the Morse-code equivalent of whatever strings are sent to it.

It's gonna be a busy weekend!
tcepsa: (Computation Suspended)
I'm working on getting my Linux computer talking to a Lego Mindstorms NXT brick for my Real-Time Systems Development class, but I'm having a little bit of trouble getting over the final hurdle of actually being able to upload compiled code to it. In one of the howtos that I've sought out, I came across the following gem:

You MAY or MAY NOT have to reboot at this time, I cannot tell

See the full howto here
tcepsa: (Cake)
(Posted to the local Java Users Group mailing list. Reposted here for your edification, or at least hopefully enjoyment ^_^)

There are lots of reasons why polymorphism (one object being treated as a different kind of object) is a valuable thing to have in a programming language.

Centered around a certain clandestine theme... )
tcepsa: (Computation Suspended)
A little gem that [ profile] gipsieee pointed me to earlier this afternoon.

Don't Wake The Programmer

I never thought of programming like this before, but after thinking about it, and about how it works for me, holy crap he's exactly right! No wonder I get so irritable when I'm interrupted abruptly--or why I can handle little interruptions reasonably well, but as soon as it goes for more than a few minutes or takes a higher level of concentration, the dream falls apart.

It also explains why thinking about a problem that I'm trying to write code for and daydreaming feel so similar ^_^
tcepsa: (Cake)
This didn't actually happen to me at the time, but it would have been incredibly apropos of my mental soundtrack to be playing Weird Al's "Everything You Know Is Wrong" while I was trying to figure out why my Elevator Simulation Project (the last one for my C++ class) wasn't working:

Everything you know is wrong
Black is white
Up is down
And short is long
And everything you thought was just so important
Doesn't matter

Everything you know is wrong
Just forget the words and sing along
All you need to understand is
Everything you know is wrong!
tcepsa: (Computation Suspended)
I've discovered a situation that would be made significantly less cumbersome if I could have an array of function pointers, loop over the array, and only have to write the setup and teardown code once around the call to the current function being pointed to with the same arguments every time.

While superficially it might seem that my claim to have leveled up is inaccurate because I've been chucking around references to functions for years (primarily in Javascript callbacks), this is one of the first times I can think of needing them to do something proactive instead of reactive. But I'm constrained to programming in Java for this assignment (and it already had 20+ hours of work in it by the time that I'd realized I wanted function pointers) so I had to triplicate my code instead (once surrounding each of the three core function calls).

Still, I take it as an encouraging indicator of the direction in which my thinking is trending that I recognized that they _would_ have been useful here ^_^

(I probably could have done something approaching that with JUnit, but I would have had to split the code up in ways that seem awkward to me and may not have been familiar to the grader, and I wasn't up for that...)

(I also probably could have done something with aspect-oriented programming, but that would be getting WAY too involved for this project, especially since I'm relatively unfamiliar with that paradigm in general and its implementations in specific)
tcepsa: (JuggleGeese)
I'm really not supposed to stay up this late on a school night... except dammit, I needed to get the assignment done!

Frakking memoization. The worst part was that my implementation of it was such that the "optimization" actually caused a significantly higher processing time. Stupid graphs and their stupid paths anyway...

But I'm a better programmer for it. Proof that I'm learning in this class: by the time that I wrote the double-nested for loops to ensure that I wasn't letting false positives through, I was starting to suspect that I'd be looking at at least O(n^2) for it. Given that those are happening _inside_ another double-nested set of for loops, that should push the whole time up to, oh, about O(n^4) if I remember right.

SO VERY MUCH LESS THAN IDEAL. Fortunately the memoization part was for extra credit anyway, and I should still be able to score that with a slightly fancier version of the paragraph I just wrote. "I may be taking the Edison approach, but I'm learning! Also, optimization isn't always!"

PS Why am I doing so much algorithm work in a data structures class? ~wry grin~

PPS (Yes I realize that the only good way to appreciate these things is to use them to facilitate the construction of spiffy fast algorithms. And I do. ^_^)
tcepsa: (Computation Suspended)
I love computers. I especially like programming them, finding new and clever ways to make them do things. My favorite course in college was Introduction to Microcontrollers, in which we did all sorts of really fun things with an F1 board running a Motorola HC11; I really enjoyed playing around with the low-level stuff, knowing that this command was causing this particular bit to be set this particular way and having a very specific impact right down to the physical state of the board (it wasn't quite a butterfly, or a magnetized needle and a steady hand, but it felt like the next best thing). So now I'm trying to get an idea of what would be best for me to do to continue to pursue things in that direction and get paid for it. I figure the way I'm juggling my life right now, I could probably make the time to either focus more on keeping current with new technologies or pursue a higher degree, but probably not both.

[Poll #1198243]
tcepsa: (Inconceivable!)
Actually, at this point it has been somewhere between one year and two since I encountered the programming concept of "closures". When I first encountered closures it was in the context of Javascript, and someone had told me that I should be careful with the toolkit that I was using at the time (Dojo 0.42) because it apparently used them and they have a propensity for causing memory leaks. I did a little bit of exploring but was unable to come up with a satisfactory explanation of what they were or why they would have this effect. The result was that I had a sort of nebulous impression that a closure was something that happened--not something that was--when a newly created object ended up with a reference to one or more of the local variables back in the method that called it.

That was pretty much my understanding--and I knew it couldn't be right but at the same time I was keeping an eye on my memory usage and it didn't seem to be getting gobbled up too quickly, nor did it seem that it was never being released. So at the same time it wasn't really a pressing enough issue for me to pursue it terribly deeply. Then, last Autumn, I went to the No Fluff Just Stuff consortium and learned of a language called Groovy. One of the things that makes it so powerful is that it has fairly extensive support for these closure thingies. I got a slightly refined understanding of closures (at least Groovy closures) during the conference and figured that maybe they had decided to use the word (which I still thought was more of a verb) to refer to these somewhat magical functions that could be passed around like variables and have properties like objects and retained references to the local variables that were in scope when they were created.

And now today, about four months later, I was reading the appendix to this article and came across a parenthetical statement that finally tied everything together: "In OO languages, you can, to a limited extent, simulate a closure (a function that refers to variables defined in enclosing scopes) [...]"

It's like there's this lightbulb in my brain that I screwed in back when I first heard the term, and it's been sort of glowing dimly off a trickle current this whole time, and when I read that finally it flared into brilliance! It's called a closure because, for all practical purposes, it's enclosed!! And therefore it can see all of their variables! And furthermore it can screw up garbage collection because it has a reference back to the enclosing object and garbage collection only happens on objects that aren't being referenced by anything that is, or is being referred to by, something on the stack! It doesn't actually screw up garbage collection--GC continues to do its job just the way it is supposed to--but it can trip you up, and that's what they were talking about when I first heard the term.

EUREKA!!! ^_^

(while my understanding may still be less than complete, it is a quantum leap better than it had been before reading that sentence ~grin~)
tcepsa: (JuggleGeese)
Today has been a very good day at work so far; I've rewritten a portion of code that used a bunch of cumbersome "if" checks to take advantage of the fact that JavaScript supports try/catch blocks. Now I just do what I want to do, and if it doesn't work then I fix it and move on. The fun part is that they're nested three levels deep, but in pretty much all cases I can actually recover from whatever broke it, fix the thing that caused it to break, and move on. No more shall I be at the mercy of (this particular aspect of this particular set of) data architecture!

As it turns out, that was just an appetizer )


tcepsa: (Default)

April 2015

   12 34


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 26th, 2017 04:32 pm
Powered by Dreamwidth Studios