SimulaE Cartography Program - simulae-kaart.py

As a quick follow up to the previous entry regarding rooms being a void and not an object, I can happily announce that the first working alpha of simulae-kaart has been committed to code this evening.

The function of this bit of code is simple:  Produce the necessary wall/barrier objects needed to create the voidspaces we call rooms.

The current working codebase does the following already:

* Allow graphical design in a 2d environment utilising unicode representative tokens.

* Returns Multidimensional Lists designating literal start & end points of wall objects

* Allows for walls in traditional cardinal orientation (north-south, east-west, nw-se & ne-sw)

* Also allows for arbitrary wall/barrier positioning at any angle (true 360 degrees).

* Default scale based on cubic decimetres, variable scaling coming soon.

Upcoming functionality to be added:

- Auto population of a given map grid

- Auto insertion of portal objects inside any giveen barrier/wall object.

- Automatic map scaling down to the smallest micro and largest macro levels

Stay tuned for further information.  If anyone else is interested in signing up for future beta

testing, I can be reached at this domain, under the email account of eric. 

-e

Simulae3 Update: Room Object? What ever do you mean?

This is just a simple, quick update to let it be known that the issue pertaining to how to accurately represent a room in Simulae3 has been resolved.  I spent about an hour with a blank book of graph paper and pen poised in my hand and thought about the problem till the following realisation hit me:

Rooms are an abstract, a void.  They only exist as a concept without substance to us.  They are the empty space created by barriers, some of those barriers contain portal objects (e.g. windows, doors, openings).  It is using this logic that the next piece of Simulae3 can be designed.  

SimulaeKaart.py

A simple cartography-based program (kaart) being the word for map in Nederlands (Dutch).  Physical space will be represented in 10 centimeter square grids (though variable map design may be possible).  The whole point of this is that in the real world, we use GPS and surveying to accurately place physical locations, Simulae3 will be no different. 

The other quick note is that the concept of rooms are also knocked out in that a room knows not of its purpose, it is only by human reasoning and deduction that a particular enclosure/void/"room"'s purpose can be ascertained.  If you take an empty house with two rooms near the room with the stove and dishwasher, how does one know which is the dining room (if either).  One doesn't, one chooses to assign that role by the placement of the appropriate objects (appropriate to a dining room that is) within said void. 

Simply put, this conundrum has been resolved and the next phase of design and coding can continue.

Migraines: A common misunderstanding

Mi - graine: (n)

A headache characterized by throbbing head pain, often greater on one side; may be preceded by a warning (aura) and accompanied by nausea, vomiting, and sensitivity to light and sound; in rare cases, weakness, language problems, or other neurologic disorders are associated with migraine.

Over my years of coding I've endured what I thought were migraine headaches, not uncommon to those of us who spend waking moment after waking moment staring at multiple screens as part of both work and hobby.  I say "thought" because up until this past weekend, I was sure that the harsher headaches I had endured qualified as the infamous 'migraine' variety.   I was wrong.

On this past Saturday, I had the pleasure of seeing one of my best friends (and also my best man at my wedding) tie the knot with his sweetheart (both are coders by trade as a sidenote).  The day was perfect, the weather was wonderful (as it was an outdoor ceremony) and all was well in general.  I on the other hand aside from coping with sciatica down both sides of my body (a relapse of a previous L4/L5 left disc rotation), awoke with what I thought, was one of my annoying 'migraine' headaches.  I took Excedrin Migraine along with Vicodin for my other-pain and proceeded onto the wedding with my wife.  The headache didn't subside, regardless of a second round of 'migraine' strength medication.

The first lesson to be learned here is that Excedrin Migraine (I'm pretty sure any over the counter "migraine" medication as well) , while great for 'bad' headaches, is lightweight against 'textbook' migraines (more on this later).  

     After the wedding was over and we made the drive home (hellish for me as my headache seems to have grown from annoyance to throbbing), I started to feel dizzy with a bit of nausea, yet did not succumb to an involuntary protein spill thankfully.  I ended up retiring fairly early figuring that my 'migraine' was just particularly bad and was exacerbated by the fact that our table at the reception was next to the live band.

     Sunday morning arrived and that horrible headache was still present.  I took two vicodin and several aspirin in the hopes that it would finally kill the beast within but it was all for naught as much to my dismay, the headache only soldiered on.   I spent much of the day in a narcotic (vicodin) induced stopor in an attempt to mask the pain which was at this point pressing heavily on my head, and would remain this way the rest of the day into the evening when I retired early in an attempt to once again let tomorrow come without the now 36 hour headache.  Little did I know that this was about to get worse, much worse. 

     Memorial Day arrived, complete with plans to go to my in-laws for a barbeque and family goodness.  04:00 on the clock and I arose from my sleep to the udder shock that the pain was not only existant, but worse.  I quickly (well, as quickly as I could) went downstairs to take three Advil (I was now out of Excedrin Migraine), and then return to bed, hoping this was finally the end.  The time was 08:00 according to the clock and I was expected to rise.  Problems.  The headache was still there, and it was rather angry with me.  Outside of glancing to see that it indeed was 08:00, I had to keep my eyes shut, the dizzy feelings, nausea and pain from the light (through the blinds, mind you) was unbearable.  It felt as if my head had been mounted between the the grips on a vise.  I at this point, took the decidedly un-male action and asked my lovely wife (and child) to get me to the Doylestown Hospital Emergency Room.  Something was obviously wrong and I was quite worried, not to mention blinded by the pain.  

     After what seemed like an hour (when in reality it was half of that), I entered the ER and was promptly thrown in a wheelchair, tagged and admitted to ER room #5.  At this point the pain caused me to writhe in pain in my open-backed hospital gown in my new metal bed.  Another 10 minutes came and went, along with an increase in the pain until one of the nice ER nurses (and a doctor I believe) tapped my arm to place an IV line, which was utilised shortly thereafter to inject a medication (a narcotic of which I'd never heard) that immediately overpowered the pain with a feeling of numbness.  This enabled me to speak somewhat lucidly to several nurses as well as a doctor about all of the aforementioned backstory leading up to this point.  

     First comes the catscan at this point to check for abnormalities.  None found.  Then the blood tests, no oddities either.  ER Doctor then comes to the conclusion that a LP (Lumbar Puncture) was the next logical step.  I consented, though it was not to be, after a considerable number of jabs and sharp pains, said doctor gave up and contacted a Neurologist who would come in later to do said LP.  

     The pain started to return and I was given another dose of said magic narcotic.  All remained well for another 90 minutes or so (at this point, I've been in ER room #5 for approximately 6 hours).   During this time the Neurologist arrived and I spoke with him and allow him to have a crack at a lumbar puncture.  Needless to say he was an expert at this procedure and was able to withdrawal 4 vials of the clear cerebrospinal fluid from my spinal column.  He then surreptitiously disappeared for what seemed like hours.  

    It was at this point, my pain surprisingly started to return, first on the right side of my head, but then started to migrate over to my left side as well.  The pain became so severe that I could tell that the lights were on in the next room over (separated by a curtain), even though I had a folded over pillow case upon my eyes, with my hand over that.  The lights in my room had been out since my arrival as they were painful, even with my eyes shut.  I felt as if I were going to tear the metal sides of my bed clear off.  I suffered like this for another 60 or so minutes as we were awaiting the results of the spinal fluid from the lumbar puncture, and it was already stated that I was given an extraordinarily large amount of narcotics already and they worried about providing anymore until they knew more about the cause of my pain.

     After all was said and done, I was told that this whole episode of the worst head pain in my life, was a 'real' migraine.  I was told that they would provide me some additional medication intravenously before being discharged which would 'kill the headache' this time.  I was also being given more subscriptions, one for vicodin (as if I didn't have enough for my back pain, which I already try to avoid using), but a medication which i had never heard of before, specifically meant to stop migraines at their onset.  That final migraine killing injection came, along with a complimentary spewing of my stomach contents shortly thereafter and I was on my way to being released.  I was informed by the doctors that there were a few things I could do to keep migraines at bay aside from the medication provided.  

"Caffeine, Caffeine, Lots of Fluids, and of course, more Caffeine."

     I'm thankful to all of the wonderful nurses, doctors and specialists who provided help to me after suffering what ultimately will be remembered and hereafter referenced by me as the 60-hour migraine.  I will never use the term "migraine" mistakenly to mean a "severe" or "bad" headache as they not only aren't in the same ballpark, they're not in the same league, region or country.  

     I decided to share this with everyone in the coding community because I'm sadly sure that this will happen (if it hasn't already happened to some of you) again, and to others.  I hope that having read this, those who find themselves suffering one of these 16 tonne behemoths will not wait an exorbitante amount of time before doing exactly that which I did, contact professional medical help as quickly as possible.  No one should have to suffer that kind of pain any longer than it takes to realise what said pain was; that being a 'real' migraine.  

     Wishing everyone good health.

Eric

Simulae3: A Testament to Socratic Design.

Socratic Method: the pedagogical technique of asking leading questions to stimulate rational thinking and illuminate ideas.

When I first started working on SimulaE (long before it was even referred to by the aforementioned name), it was a solo project.  This isn't to say that I haven't written all of the code from day one to this very moment, because I have.  I can however say that the design portion of its various incarnations wouldn't have evolved in the manner which they did were it not for the diligent use of the Socratic Method.  

My earliest versions of designing the Simulae virtual world simulation suite of libraries and what not were designed and written by me in response to the original interactive fiction/text adventure engines, then consequentially MUDs (Multi User Dungeons).   The proof of concept of building a better designed mousetrap was simple enough to bring to fruition.  This took place over years, dependent upon my free time and interest in furthering what was simply a flight of fancy for me from my programming youth and Zork playing escapades. 

What really became apparent was when I worked for another company and had the pleasure to work with a very intelligent individual by the name of Tim.  He is a systems/network administrator as well as a capable coder though the latter is not his primary goal, nor role professionally.  

Tim was interested in my Simulae project and as such I found a kindred spirit through whom I could interact by applying the aforementioned Socratic Method.  Through a constant back and forth barrage of theories and examples along with postulates about the hows and why virtual components modeled after reality need to be viewed in a certain light, we would come up with a whole new understanding about the direction of the project.  

It was during this time initially working together that the present tense English Parser component (parser.py) came to be realised and produced.  It took a total of seven point-releases to go from simple noun verb understanding to parsing complex compound sentences with a massive understanding of 45,000 adjectives, 9,500 verbs and multitudes on various parts of English speech.  This series of productive success if anything re-enforced the validity of this methodology in the realm of software design. 

It is now though, with this in mind that I have taken utilising this method to the next level and enacting it with completely uninvolved individuals (uninvolved in the sense of the projects topic and internals).  In the past several days Simulae3 has emerged from the bowels of my TextMate application.  The code is simple, shorter and far more capable than any previous incarnation and things are moving forward at a great clip.  

This brings me to the current point of interest and a call for assistance for anyone willing to get into sometimes heated dialogue about object models.  The object model system is based around the three basic SimulaeObject types.  The only piece of the puzzle still causing an issue is the matter of Portal Objects (entranceways between other container type objects.)  

For the sake of argument, just look at it this way:  A room is a container, that leads from one room to other rooms of 'greater' building enclosure.  A set of lips in a Mobile Object (hereafter MOB) (e.g. 'actor' in OO/UML terminology) is simply a Portal Object to the mouth of said MOB.  A window is simply a portal between the outside 'container' object (in this case a root SimulaeObject), and the room in which our Actor/MOB would be in (to see said POB destination from said perspective).  

I need others with whom I would be able to work out ideas so that this conundrum can be resolved and the next phase of Simulae can come about for code release and testing.  If anyone is interested, contact me at this domain via my email address: eric

I am going to finish on that note being that due to medical reasons dealing with my sciatica, I ingested a full dosage of two Vicodin tablets (as per my primary physician), and as such I'm getting ready to crash hard.   I hope to hear from some of you in the hopes of moving forward, but I'd like for Tim to give me a call in any case so that I we can bounce some ideas back and forth on these issues.

SimulaE - Model Update

I've made mention of my virtual world simulation project on multiple blog entries, most recently related to Ruby and making a rewrite of the existing engine in said language to test out its applicability (the language not the simulation), which by the way I found to be the lesser language for this kind of application, but I'm not saying anything about the language as a whole.  Either way, onto SimulaE, which after all is what this post is about today.

I have been rattling my brains (and occasionally those of my friends) regarding the basic SimulaE Object model, which up to this point has served its purpose.  Though the time has come for it to evolve.  It can implemented in a simpler manner and I have known this in my mind all along though it hasn't been an issue in the process of designing the parser which has for the most part been satisfactorily completed. Now that my focus has returned to the object model, I feel it a fine time to share that update thus far.  Comments are always welcome and most are appreciated.  

The fault before was that I broke the objects into the wrong sub classes.  Originally I had the parent Object class,  and subclasses for Room objects, Exist Objects and Person Objects.  This is a horrible idea and leads to unnecessary complexity.  

The newest model:

Object (super class)

MovableObject (isa Object)

PortalObject (isa Object, isnota MovableObject)

PortalObjects, hereafter POB are a much more dynamic version of the previous "room" objects.   A POB behaves in the following manner(s):

1. Object(s) enter into the object containing said portal.

2. Exits an object when contained therein.

3. Can exit (when specified) to a specific object, though by default exists to the parent container object.

If a MovableObject, hereafter MOB, is not contained within the same container as the POB, POB leads into the container.  

If the MOB is contained within the same container as the POB, POB leads out of the container.

By working in this manner, we ensure that the simulation object model more closely mimics the real world, whilst still allowing for exceptions to transpire for non-real world based applications of this group of models as well as anything they may be working on at CERN in Switzerland which breaks our current understanding of physics. 

I haven't had time to implement this new set of models yet, but as I write that code, I will be posting the revised Python source.

Quick Django Tip: Dynamic Application Object Retrieval

In my recent django adventures I needed to introduce site-wide search functionality and in the process of doing so, encountered a small roadblock towards doing so.  Apparently due to the nature of Django's API for db interaction (as of the last stable release version), there is a limitation as to the use of python variables in API calls.  I found this to be a hinderance, but only for so long.  

The follow code snippet was something I whipped together which by utilising Python's 'eval' built-in, overcame the aforementioned limitation regarding the API's ability to interpolate native Python (e.g. non-django explicit) varaibles.

Things to know to understand the following example:  

 search_input is a list of cleaned and pre-processed user-driven terms, split into separate expressions, (e.g. ["dynamic langauge", "agile", "programming", "paradigm"]). 

 search_schema is a dictionary in which the key is the django model/class through whose objects we are attempting to search, and the value is a list of specific model attributes to attempt said search.  (e.g.   User_Profile : ['firstname' , 'lastname', 'address_1', 'bio_info', 'favourite_books'])

container_xref is a simple alias mapping for the actual django application names to our internal references inside this search code base.  Obviously this whole bit could be written without said setup, but for readability given the scope of the actual application involved, and the fact that I was not searching simply a few static fields in one django application, but several dozen fields through about two dozen separate applications, this container_xref dict was appropriate.   It is through this mapping dict which we place any matched object results (so as to not waste any additional space via unnecessary list initialisations.) for eventual results generation.

Note: the key "total_results" in the container_xref was a simple means of keeping track of overall search matches, rather than relying upon the Django templating engine (view) from doing work responsible from the processing (controller) perspective.  In retrospect, there are better ways this could have been handled, and in future point revisions, this will be addressed.

------

for search_string in search_input:

  for application in search_schema.keys():

    for attribute in search_schema[application]:

code_to_eval = "%s.objects.filter( %s__icontains='%s' ).order_by('-id')" %       

                     (str(application), str(attribute), str(search_string))

        try:

          eval_results = eval(code_to_eval)

          for eval_result in eval_results:

            if eval_result not in container_xref[application]:

              container_xref[application].append(eval_result)

              container_xref['total_results'] += 1

        except Exception:

    ### Case specific exception handler types, assignments and resultant actions 

          ### specific to each application in which the above is implemented, go here.

-----

As can be seen from the above, simple inline substitution proceeded by evaluation of said string results in post-compilation dynamic search functionalities within django, addressing simple problems one might run into with the existing API which will most likely be addressed in future versions.  

Your results may vary.

Eric

Ruby: Somehow I overlooked this Gem of a Language

About 5 years ago I started looking into a language that prior to it's "Rails" fame, was lesser known and even lesser utilised.  I tried it a bit and found it leaving me wanting more.  I've kept tabs on it over the years, reading the tutorials and writing several quasi-AI experimental applications for my SimulaE research, but I ended up being enticed by Python, a language which I stand by, including the wonderful (but until recently unused by me) framework Django (Python's Rail's equivalent, focused on Publishing).   

I've programmed professionally using Python for several contracts/years now and find it quite enjoyable.  In fact, I'm currently coding specifically in Python for Inkedmagonline.com, but that doesn't mean that I don't continue my personal exploration and education for both personal and professional reasons.  I decided to re-experience Ruby by picking up the hallowed PickAxe book and giving it another honest chance.  I'm glad I did.  

I believe that Python, and the values espoused in Tim Peter's "De Zen van Python" (The Zen of Python) (my copy just happens to be in Dutch, otherwise I'd post it for others) have helped me to look at Ruby in a different light.  There are some key differences in the two languages, but I can see now the inherent power in Ruby that I was overlooking before.  In fact, some of those key pieces, syntactically as they were which make Ruby so enticing this time around are the very same 'features' I feel are missing in Python.  It only took me working in an environment with situations where said language features would prove the best solution to the problem(s) on hand for me to realise it.

I am not going to spend time detailing all of the specifics, though I may mention one or two nonetheless.  I'm more so bringing this point up so that others might be reminded that giving something new a single chance might be to your own disadvantage.  After all, I didn't like Python the first time I tried it either.  I think it is partially a matter of how we grow as developers that allow us to know what we're missing, that same spark of realisation that gives us the "a ha" of relief when we find it hiding in a new language, programming methodology, etc.  

What brought me back to looking into Ruby a second time is of all things, Smalltalk.  The whole "everything is an object" concept is nothing new to me, or to programming languages.  However in dynamic strongly typed languages, it is.  More importantly is manner of how even rudimentary objects such as integers, floats and strings are treated in Ruby.  They have methods which can be both called using the standard instance.methodname call format, and have their standard methods overridden.  The second being something far more wonky and kludgy in Python (and a non-option in perl).  

The fact that key methods are instance based such as "len" or "length" for example makes a world of difference for consistency.  It speaks to the overall design that "Matz" (Yukihiro Matsumoto creator of Ruby) had in mind during the planning phase.  In Python, a language in which everything is truly an object as well, this starts to get rather confusing.  While Python does treat every integer and string as an object, it mixes the traditional functional paradigm for calling items such as 'len' so that to find the value of 'a', one would type len(a), as opposed to the more object based a.len ..  This seems counter-intuitive and quite frankly a real surprise when you look at the overall design of Python.

I'm not ripping on Python as I do wholeheartedly enjoy the language, I'm just starting to feel aches and pains over decisions which are ingrained into the language, as well as not being seen as an issue or being addressed in py3k (or Python 3000/Python v3.0) as it were.  I just think that my eyes have been opened to Ruby again and I like what I'm seeing.  I am actively looking to find a future professionally as it were utilising it as nothing beats having fun while accomplishing what one would hope accounts to 'great' things.  We'll see what the future holds.

Next Step:  Migrate my SimulaE virtual world/real model object simulation from Python into Ruby as a test run.  Lather, rinse, repeat and then see what the side-by-side comparison's look like.

Until next time...