So, I can't debug for shiat, but I've chosen to become a computer science major...

I apparently either can't apply the same logic in "the stove hurts, so I won't press my hand down on one" to daily life, or I just hate myself more than I'll ever hate anything else. The latter is a justifiable conclusion in any case.

99 little bugs in the code
99 little bugs in the code
take one down, patch it around...

127 little bugs in the code...

Here was the last "line" of code that I wrote in the course of my day. This was what we refer to as a "One-Liner" or, a "one line FOR loop".

F I=1:0 Q:'$O(^AUPNPAT("D",I)) S J=I S I=$O(^AUPNPAT("D",I)) S X=$O(^AUPNPAT("D",J,0)) I X S Y=$O(^AUPNPAT("D",J,X)) I (Y)&&(X'=Y) S COUNT=COUNT+1 W "DUPLICATE FOUND. MRN '"_J_"' IS HELD BY '"_$P(^DPT(X,0),U,1)_"' AND '"_$P(^DPT(Y,0),U,1)_"'",

I basically wrote it to prove a point.

I'll stick with Perl and Java, thank you.

I like that a lot of the more popular languages are C-like. If you know the syntax of one, you can pick up the syntax of another pretty easily.

There are the outliers though... like FORTRAN. *shudders*

Very very cool! What's the application for?

It reminds me of the old TradeWars 2002 game from (way) back in the day. Ever play that one?

I had once upon a time ran a BBS, and that game, of course, was added first and foremost. When you first initialized the game, it would procedurally build a random galaxy which was essentially sectors that were linked together. So every TW2002 game was different. On top of that, I believe the players could build planets, but I can't recall 100% if that is the case.

I miss the old BBS days. Those were good times, yes'er'ee...

Ah yes BBS days. I remember wasting many, many hours on ISCABBS.

The script above is basically for a Star Trek RP game. We call it a "sim", but it's more or less collaborative fanfiction. (Though with unique characters and etc.) When there's need for a planetary system either as a function of plot, or for a character background, we can hit a button and generate one.

Never did play Tradewars; I didn't get into that type of game until WAY late. Played a few MUDs and the like in the late 90s.

Dude, I have boxes of AD&D stuff. 1st Ed stuff from my father-in-law, too. He played with his Army buddies in the late 70s. Quite a bit Forgotten Realms, Dragon Mountain, Underdark box set, and literally a tote full of modules.

MUDs were different, from what I remember... I never really saw a connection to D&D, except just as another way to RP/Adventure. Though I must confess, I didn't do a lot in the way of MUDing anyway... at the time, Talkers were more my speed.

Phew! What a day....what a day.

Spent the morning teaching the self some basic winsock programming with the goal being to write a TCP/IP interface into a MUMPS box so that I can create Windows applications that can access that data. In that endeavor, I was successful.

The rest of the day was spent WTF'ing over what happens to those packets once they make it into the database. I've gone back and forth over what to do once I can get data into and out of the system. At first I figured I would use the existing XWB framework (RPC and M2M Brokers) developed by the VA in the 90's, since it works and has a lot of features. However, those were developed to target Delphi API's, so I may spend more time recreating the wheel there so that I can utilize it in C++. So the other option is create my own broker, from the ground up. It'll be the YAM Broker (Yet Another MUMPS Broker), utilizing YAMB for a namespace. The problem there is that I may spend a lot of time recreating the wheel in regards to packet and data manipulation. So there is the dilemma.

A few more steps before I can start work on my PACS....

And I really don't want to use the BMX brokers. Writing SQL calls to access a MUMPS DB is beyond ridiculous and shows how little the application developers that I am working with actually know. "Eww...I don't want to learn MUMPS...I was to use SQL and VB to develop enterprise level healthcare applications.... " Flipping pansies, can't even statically link a library to an executable. Ugh..I hate knowing more than the clowns that get paid 4x my wage yet couldn't code a "Hello World" if it wasn't drag and drop.....

Beer. Must.....find....beer....



.....and pizza!

10 Print "Hello World!"
20 Goto 10

f i=99:-1:1 w !,i," bottle",$S(i=1:"",1:"s"), " of beer on the wall, ",i," bottle",$S(i=1:"",1:"s")," of beer.",!,"Take one down, pass it around, ", i-1," bottle",$S(i=2:"",1:"s")," of beer on the wall.",!


That's my "status" message on Lync (@ work)

Made awesome progress today! I came up with another idea this morning for interfacing into this system. Create a client and a server application. The server executable of course would reside on a MUMPS server. Client and server obviously communicate, and then there is a command in MUMPS that can be run to execute and external command on the host, including the ability to pass arguments and return values to the code. Simply loop this and check for incoming messages every x number of seconds. Take the message as input into the MUMPS code, and pass the return values back. I've written this code to do a byte-wise compare of two files....

Then I got to work, and tried one of the existing methods and made some mad progress. I managed to successfully connect, pass the system login message, and authenticate with my credentials into the server. There I stopped because the encryption isn't adding up, so until I can decode that piece, there I stay.

However, now that I really hash out my first idea, that really seems to be a lot cleaner and may be much easier to implement. Using TCP in and out of this system is ugly at best, and requires a lot of mapping of decimal to octal and weird format of characters in specific sequences. There also seems to be a lot of arbitrary numbers that don't seem to make much sense.

I almost forgot, in order to make part deux happen today, I ended up writing a quick application to basically listen for incoming connections and display all data. Pretty cool. I'll need that ability when I really get elbows deep into HL7 programming, which isn't far off. I'll be writing an interface real soon and saving $30,000 which is what they would have paid a contractor to do it.

Actual development is awesome. Dealing with people that say "it doesn't work" isn't.

O.o *boggles*

I could recognize some of that. I'm just a lowly hobbyist over here.

Well, I know my skill level is nowhere near yours; I'd probably take one look at what you're doing and...



I mean, I've done file handlers, I've manipulated data... but once you get into specific protocols/resources, then it's beyond me.