A Personal Note - CS50 Class

[luserdroog]

I've signed up for a local meetup pursuing Harvard's CS50 curriculum, sponsored by a non-profit called LaunchCode run by the owner of Square to boost his hometown's profile. So this may impact my productivity with xpost in the near future. We start with Scratch, which I don't expect to pose too much of a challenge, cuz I think I'm a smarty-pants, and then we turn to C. hee hee.

 

So I predict that the hard part for me will be in week 4 or 5 when we leave C behind and go on to other stuff. sniff sniff.

 

But they keep saying (and my investigations bear this out), it's the "other stuff" that's a marketable skillset. javascript (ick) php (ewwww) java (sigh, okaaaay). And the buzzword in the room was 'Ruby' which will not be part of the course.

 

But but but C! The Universal! The "substratem"! The hackability!

And: 'Arthur C. Clarke: Postscript is the future of words on paper.'

You don't argue with that dude!

 

But of course that's baloney. Screaming at shadows is not a viable solution.

 

So wish me luck. The cheese is: anyone who completes the course gets a job. A paying job, in a probationary paired-programming arrangement.

 

-Josh (droog)

 

[luserdroog]

Well, homework's done for this week.

These are pretty abominable, the ball one less than the kitty:

 

ball strikes string:

http://scratch.mit.edu/projects/16661085/

 

skipping kitty:

http://scratch.mit.edu/projects/16660180/

 

And I peeked at next week and it's printing triangles of hashes:

   *

  **

 ***

****

So, I need to try not to get bored before it supposedly "shifts gears".

I've got Max Agoston's tome of graphics algorithms on order (for "reals" now, used an expired card somehow at first). With that, I should be able to implement eofill and eoclip, and conforming fill and clip operators.

 

 

[luserdroog]

Ok. So, here's what happened. I did three weeks of homework the first night, and then I cleaned-up my Utah teapot challenge and posted that. And then I polished up my teapot code and posted that.

 

And then I had a fun honeymoon with APL. And wrote two drafts of an interpreter based on an obfuscated original source. But it was never able to do much with the teapot data.

 

So, now I'm back to xpost, and sadly, the efforts that might lead to moneymaking is not the fun NeWS stuff that I want to do, but filling-in out the level 1 behavior and making a decent start on level 2 stuff. In a few details, we're still at sub-level-1.

 

A supportive effort is continuing the untangling of intermodular dependencies and migrating more source files to the library, in a strict hierarchy of dependencies (no circles).

 

A third front is more considerations of the API. I've written a sample program xpost_client.c to see what it would look like. Exporting the raster data is something I need to figure out, somehow. It's locked up in a private data structure. A related issue is the semantics of showpage. For an external program generating pages of a document, it is not appropriate for showpage to wait for a newline on stdin. It needs a mode where xpost_run() returns with a code indicating that the executing context may be continued to produce subsequent pages. So I think the API needs a context handle of some sort, in case it wants to run multiple interpreters "in parallel" or some such.

 

... and now I've got segfaults when quitting after running dancingmen.ps. So I've got to debug, ack!  edit: added argument checks and error returns and now we get an ERR log message instead of a crash. So, that's better.