Parsing Delimiters (theory)

[MadGypsy]

OK, so I rewrote the overwrite system and it works fine, it's also 143 lines less code. I noticed an oversight. It's kind of a big deal (to me).

You actually cannot do this:

child[0]:"some text",
child[1]:"more text",
child[2]:50

And I thought "Why? Why does this refuse to cooperate when * works fine?"

*

child[0]:
{
    //something
}

Then it became very clear. "{" means object so when this is encountered an Object is created. "(" means Array and so an array is created when this delimiter is encountered. "]:" doesn't mean anything.

My current system splits at ":" so I end up with name:child[0] and value:{//stuff}. I then parse "[0]" out of the name and further parse the 0 (which is not always a 0) to gain the array index. That's all well and good, and as long as "]:" is followed by a "{" or "(" then everything works great. But in the case of child[0]:"something", my compiler is like "woah woah what the F is a " - I don't know what to do with any of this now, Imma just crash."

And in that my friends is a lesson on dependency. My compiler was dependent on this condition "]:" being followed by an "{" or "(". I did not intentionally build that dependency. It was inherent of adding features that weren't considered in the beginning. This becomes obvious, when I have to consider the catch 22 I am now in (this is where it gets real good)

I can break the dependency that is currently breaking everything and it will just move to a different function. I move it out of that function (as well) and it creates a whole new slew of problems that involve both functions. I have even been super crafty in how I wrote "the fix", by breaking 99% of the dependency these two functions have on each other and feeding them 2 different sets of data- everything works!!! EXCEPT the last little bit of { or ( not existing. I mean I have it working all the way to the very last line of the damn function and there is no way to change that line (or we start breaking more stuff).

So, what is my conclusion to this?

Well, we are talking about a functionality that I want in my script. So the importance factor is high, but the ability that I would lose by simply not worrying about this is very minimal.

In order to really fix this is going to take some complete Parser reconsideration, meaning rewriting huge chunks (?maybe all?) of it. That sounds like advancement. I like advancement. Let's do it! A rewrite it is. This is actually good. I have a lot of excellent code here that was never classed out and properly turned into packages. I also have 2 functions that have identical loop signatures with different directions in the loops. I could make that much more dynamic. The loops are to cycle through every single solitary child of every parent, no matter how many or what type of either.

So, that is basically the parser core right there. It's time to separate this stuff and build a machine vs the procedural monster I have built. I wouldn't go as far as to say I used spaghetti programming, but it is just one function followed by another til 1084 lines later. (just for the parser)

[MadGypsy]

I'm so close. overwrite[2] was the last damn array that needed to be parsed. If it would have cleared everything would have been solved. I did not do all that much rewriting after all. I thought about it all day and tried to look at it differently. This is the result. Which actually is much further than I was, but it's still a "horseshoe and hand grenades" situation.

Before, it would die at the last directive on filter[1], now it's failing at the very end of everything. Imma figure this out. Unfortunately, not tonight.

EDIT: I guess I should also point out that the line hilighted in grrr - is my engine spitting out everything that was left to parse after a duplicate parse error. In other words I have a spot in my code that says "if this value is the exact same as the last value that passed through here, quit and spit out what was being processed". I did this so I don't get stuck in an infinite loop. So the last line (the grr one) everything past the very first "overwrite[2]:" is the string that is being left over.

One thing is obvious, it is not catching and removing overwrite[2] from the main string to be parsed (although it removed it's value), which makes no sense.

However, we have clues. overwrite[2] is literally the last damn thing in the whole chunk so it is proceeded by a "}" that actually closes it's parent. I have that situation described in my code, but it is not working for some reason....

I know the problem. It's very clear now that I have said all of this. overwrite[2] is not proceeded by anything. I just gave away the answer. "}" belongs to overwrite[2]'s parent so (since the parent has already been parsed down to it's content) "}" doesn't exist.

My code should say "if we are in a condition where we are assigning a single non Array/Object value to an array position, search for the first occurrence of "}" ")" or "," - if an occurrence doesn't exist - grab everything that is left in the string"

I don't have time to test it, but I bet when I get home tonight and alter my script to search in this way, it's gonna jump to life.

[MadGypsy]

Alright, I am home, I have coffee, I have music and I have "fire" to whip this shit into submission. As usual I will simply edit this post as I go, throughout the night. Sorry to sort of SPAM it right off the top, but posting makes it real to me and gives me determination to take action (as opposed to just dreaming about this stuff).

EDIT 1:

Well one thing that I cannot argue with MH about is the complexity of text parsing. In the early stages of this project, it wasn't complex at all. At this point though, I actually have quite a bit of script features and getting them all to be coordinated is very complex.

I didn't just jump off the programming bus. I've been scripting for a long long time. So, I am not satisfied with any "patch work" in my code. If everything isn't acting with the whole as a member of the whole, then I am doing something sloppy. Currently, I do not have any slop in my code.

That is what makes this all so complex. I could patch this thing to death and get it to do whatever the hell I want (badly!). The complexity derives from saying "This is where X happens for everything else, so this is where X has to happen to this." No, carrying the mistakes to the next process and fixing them there.

The problem that my newest feature creates is now there is basically a third possibility, that does not fit into my true/false paradigm. The paradigm comes where true this is an array = make an array OR false this is an array = make an object. However, now I need false this is an Array or Object = don't make anything yet.

{screeee} woops, I forgot to mention that the edit to my last post^ was correct and that issue is resolved

{presses gas} So this is the new step, eliminate the true/false paradigm and potentially come up with a -1,0,1 situation. Before, 1 was array (true), 0 was Object (false) ..-1 will mean neither.

Please understand, if I am typing here and not showing success, then I am just as in the dark as you are as to what I'm about to write here.

...this is "thinking out loud" - it always leads to the fix. Every single time. This thread is proof.


EDIT 2:

Hmmm, I didn't do what I said above yet, well, cause it's only been like 3 minutes. Instead I changed it to true (make array) for the non-working portion - And It Worked! And thats a hack or some shit. It's great it worked, but the content here needs to be of the type * (that means wildcard). It will only remain a wildcard til the next function where it will be properly typed.

This is not the same thing as carrying mistakes over cause the bottom line is, the next function is where this is supposed to be typed. If I assign Object or Array it either does not work or works as a glitch. I have to use a wildcard so the next process won't treat it like a "boss" and allows it to be processed to it's proper type.

However, it was really nice to see it all jump to life again and know that what I said about typing and paradigms is correct. I even know how and where to fix it, I just need to think a little more on the exact method I would like to use. -1,0,1 is A solution, but so is myBoolean === null and a whole host of other possibilities.

* === is a comparison operator and it means "does this equal that in every possible way?" - "are these identical"? I would use the extra equal because technically null == false (is the same as but not identical), so null could get swallowed as a false.

EDIT 3:

OK yeah, I'm on this. I have figured out what I need to do and it's gonna be a bitch. The bitch part comes in by properly splicing content together based on comma count and out of order index possibilities. Actually, that's just the best I can explain it (currently). I get it in my head, but I don't have the words to express it plainly.

This one feature is a real pain in the ass.

min EDIT: woops spoke too soon, its not gonna be hard at all. I'll split() the string by "," into an array, splice() the new content into the proper position and then join() the array by "," back into a string. TaDaa! Perfect .content parsing of out of order individual array indexes. Imma go do that now.

FINAL EDIT:

Problem solved, the end, no doubt, smooth, clean, where it belongs, done. 12 minutes since last edit. I didn't type it at all, no wildcard, nothing. The type of content that I am dealing with does not get assigned anything til all of the parent Object/Arrays are built. This a hierarchical. Build the "container" types, then populate them. simple. Well in this case we had to go inside of a container type "early". So the stuff we are going to populate it with next, was "jumpin the fence".

I just set the absolute lowest restriction level. It used to be entire Array/Object types, now it goes as far as an inner array index, which is essentially also a container. So, yet again I did some stuff that I didn't even realize that I did.

I did it smooth too. Instead of letting it "jump the fence", I backed it up (lol).

It wanted to assign parent.child[index].content I played with the track and assigned all those .content to parent.child.content. So you see I backed it up to how I really process array content, with a .content field on the actual array (love associative arrays). Then process that content into array indexes. This approach I turned the value of an array index into a properly placed CSV in the actual array.content.

I told you. Every time. This time even lead to taking "forward" data and winding it back to original expected and properly indexed data, even if the data is received out of order. That's some shit.

> booleans cannot === null (learn something new everyday)
> I used the -1,0,1 method. Which is semi arbitrary, cause I could have picked any 3 whatevers (ABC, 9F2). -1,0,1 basically holds the same numerical meaning of what I am doing.

Imma go work on themes now. See ya tomorrow.

[MadGypsy]

Today is the day

Today is the day that I will add the last two features to my parser, that I have a current interest in. As it stands now these are my parser features:

1) preserves special characters and escaped quotes in strings
2) import external scripts
3) fully optimizes script before parsing
4) recognizes Object, Array, String, Boolean, Number and Image types
5) same-name support for recognized names (keywords)
6) uploads all images and overwrites it's url in the object with the actual image
7) overwrite data
assign array indexes directly

dang, that's a lot. I'm sure non-programmers reading this may not see the potential of those features, so I'm just gonna tell ya. You can do an ass-load with just those features.

The 2 features I am going to add today are:

1) extend targeted data
2) theme support

This will absolutely and finally wrap up this version of my parser. After today I will be working solely on the client side of all of this, until I have 1 completed and properly functioning app.

However, my parser will still not be "complete". Once I get an app out of the way. I am going to go back to my parser and add these features.

1) conditional support (functions)
2) php/javascript connections

Then I will start writing a bunch of php/javascript "plug-ins". One feature my xml engine had that I really liked was the ability to override almost the entire engine with javascript. This is a cool feature cause, lets consider something:

You want to make an app but you don't want to learn a bunch of xxon. You could use xxon solely to get a (ex) video component on the stage and then use html/css/javascript to build all the controls externally.

I hope people are starting to see how all of this is not some nutty waste of time, but actually is shaping up to be a powerful multimedia engine. Honestly, right now, I'm just following the flow of "generic" flash functionality, but Imma say this now and mean it in droves: This WILL be a 3D engine before this is all over. As a matter of fact it will be a pretty lavish 3d engine in some senses. I don't believe I can pull off Darkplaces grade eye-candy, but I can do other things that I have not seen in any engine.

Imagine if you could skin models with movies. Sounds crazy? Doesn't make sense? HAH! You know all those console panels in Quake? Imagine if you could walk up to one and actually use it. Press a button, video playing right there on the console. Now, I say Quake, but this has nothing to do with Quake. It's a relative example. I have other "out of the box" ideas that I haven't personally seen in other engines, that will give my engine alternate points of interest.

NOTE: I do want to make it possible to "remake" Quake in my engine (which will be a total pain in the ass for the remaker, cause they will literally have to remake the entire thing), but Quake is not a focus of mine in general.

---

I will be making NO edits to this post. I say this because I believe that there are a handful of people that "check" this thread for edits, throughout the night. I will save you some time. My next "edit" will be a new post telling you what you could already guess - I have finished (with a healthy dose of rambling of course )

aside: I consider myself to be a "mad scientist" (lol). When I drop the lever and bring Frankensteins monster (adam) to life, I'm gonna look up at the ceiling and laugh like a mad scientist too... (hah). Maybe I will even scream "It's alive...It's aliiiive!" - because I can.

[MadGypsy]

Nope, this is not an "update". I just realized that I stopped posting images of the features in action. The below is primarily self explanatory. The AS3 script that I included is the guts of my "rollback" code. Simple and correct every time.

Even though it is relative. I actually only included it because I could fit the whole thing in the empty area that the rest created. My "pride" in that bit of script does not come from it being "revolutionary" or anything. The pride comes from one second thinking like: "Crap, so I can count the delimiters....[more way too complicated bullshit]" to "pop, pop, pop..done". And it was awesome cause I just automatically knew. My mind was on a whole nother level and SLAM..ANSWERS..GET 'ER DONE. hah



for those that don't know: The trace() lines get sent to my output panel. They aren't actually doing anything parse-wise. Basically, those are a few sentences from the story of my parse.

EDIT: By the time I come out with a usable product, all of you will already know how to code in it

[MadGypsy]

Apparently, yesterday was not the day to finish the parser, but some really good stuff still happened. My image import was lacking one feature "What do I do if the url is wrong or the image does not exist?" - this is what my parser would have been asking me if I created either of those situations.

The fix was uber simple. I already had a spot where success/fail events were called upon the image loading. I never told it what to do on a fail though. It goes like:

if (image failed to load)
{
    make a new bitmap with these (20,20,false,0xaa0000) properties; // width,height,transparent,fillcolor
    push this bitmap into the imageArray[loadCount];
    ++loadCount;
}

This way, there is no crash. Later when that image is called it will be an ugly 20x20 red square, which will let the developer know "go check your url in the script and in actuality". Ya see? Maybe I will develop this potential further in the future.

I also realized that I forgot to add an existing feature in my features list #6 (keeping them in order)

1) preserves special characters and escaped quotes in strings
2) import external scripts
3) fully optimizes script before parsing
4) recognizes Object, Array, String, Boolean, Number and Image types
5) same-name support for recognized names (keywords)
6) dynamic accessible name reference created upon script compile, of every immediate child name of every parent, on said parent.
6.5) dynamic accessible name reference cleared of compile option names as soon as they are processed (clean house of overwrite,extend,etc)
7) uploads all images and replaces it's url in the object with the actual image
overwrite data
9) assign array indexes directly
10) image load failures will not crash script

I did more than that but it doesn't belong in the feature list. I spoke of making my "core processor" more dynamic and removing some repetition. I did that. I added 24 lines of code and erased 207 lines of code. I still haven't classed any of this out. It's probably good. Every time I think I have written it as short and clean as I can, I see how I can optimize even more. I'd rather class all of this out after I have the tightest script that I can conceive.

I have to say, even after removing 200+ lines of code I am still just under 1000 lines of script. So this seems to be more like, how many features can I pack into 1000 lines.

That being said. My "core process" is currently handling overwrites and images, but I am about to stick extend and theme in it too.

wait....that's the same thing. extend/theme. psssh. wow the only difference here is an extend would be written on the same level that it has to effect, whereas a theme would be a completely alternate object that can be appended anywhere. So essentially the difference is local/global. Hmmm, that may actually be enough reason for me to make both. I might as well anyway. Now that the "core process" is fully dynamic, the only task becomes feeding it the proper information.

Searching the entire Object and traversing every single child is

a doddle

EDIT: dang this stuff adds up quick. I started only posting the parser features but there are engine features too:

display
  1) images
    1a) rotation, UV, XY, width, height and alpha
  2) "shaders"
    2a) solid/gradient fills
    2b) fill ratios, rotation, UV, XY, width, height and alpha
  3) text
    3a) font, size, designation, htmlText, letter-spacing, margin
    3b) background, background color, border, border color, font color
filters
  1) Drop Shadow
    1a) rotation, blurXY, distance, quality, inner/outer/knockout, color, strength
  2) Bevel
    2a) rotation, blurXY, distance, quality, inner/outer/knockout, color, strength

I guarantee you I didn't name all the Na's and Nb's. I wrote that from memory and my memory also remembers that I'm forgetting a bunch. That's the gist.

[MadGypsy]

A Parsable Mosaic

This post is going to be a bit different. Below is an image of my xxon and the compiled results. Nothing too different about that. Although, even lower is the entire "story" of that parse as written by my parser.

There is a bit of a convention to my output. XXONParser.somefunction(//values) means that "someFunction" within the class XXONParser has just been called anew. The values area is the actual signature of that function within my parser. When you see someFunction: that means that that is the function that is performing the current operation. There are NO mistakes. if you see names switch "suddenly" that really means that now it's using that function.

I know my "app" is nonsensical. The point was to quickly utilize all of the current script features. I am also aware that the history of a parse is incredibly repetitive and boring. The point is for those that have an interest in what is happening at each point to have the complete algorithm spelled out for them in human readable terms.

It is also proof of how this picks xxon apart like a sniper.



EDIT: way too long to post, I had to add the .txt as an attachment. I also had to zip it.

[MadGypsy]

Sorry to double post, but if I add edits to the above post, then I will have a bunch of unrelated data between explaining the download and the actual download, cause the attachment will always be at the very bottom.

That being said, I have a healthy dose of something else to talk about. I have given much thought to the extend process. This process would be used if you want to take an element that you already created and add some functionality to it. In order for extensions to work properly you have to define a target to apply the extension to. In "homage" to Quake I actually designated these fields as .target on the extension and .targetName on the object to be extended.

However, what you write in these fields becomes a whole nother animal. targetName actually is very simple. Just give it some unique name. target on the other hand becomes a whole new method of parsing, because I have to write something of meaning and then interpret it.

lets consider this

parent:
{
    display:
    {
        type:"TextObj",
        targetName:"myText",
        properties:
        {
            background:false
        }
        //more code
    }
    extend:
    {
        target:$display[myText].properties,
        size:50
    }
}

This is a brief illustration of how I see it in my mind. Since "myText" is not actually a child of display, using dot syntax to dignify it would be "wrong", but I have to have some short way of saying "get the display object with the targetName myText".

You may notice that I go even further though. properties is a child of display. So, to use dot syntax is appropriate. The theory behind this is to first find the unique parent you want to effect and then dot syntax your way to the actual child you want to extend. My current illustration assumes to add size:50 to display.properties, followed by that entire instance of extend being destroyed as it's contents have been processed and it is now useless.

In a sense I have not even begun to implement this feature. I do have some areas of the overall script primed for its inclusion, but not even a trace statement has been filled in. Sometimes, staring at the walls in complete silence is more productive than chasing an unfinished idea around your code.

---

Speaking of priming the script for future inclusions - I did just that for utilizing the php GD library. This area also doesn't even have so much as a trace statement, but these little primers will save me time later, cause I have already figured out exactly where the code needs to go. I guess I have spent a couple of days setting up the "battlefield" and maybe even making some of my armies more organized.

I am almost prepared to strike.

EDIT:

See, this is why I think about stuff for a while. .targetName is actually a real field (in flash) that can be applied to display objects, for the exact same use as my method above. Now, for the extends method, this really doesn't have any implication. The point of the parser is to send a completely compiled Object to the engine. So, extend is just another step in making that object complete and is "too far down the food chain" to matter yet. When we get to the engine side though, this field will be applied directly to the display object. That means that (ex) $display[myText] starts out referring to a spot in a data object and ends up properly referring to the actual display object. because:

display[targetName] is legit to refer to display objects

So this changes everything. In creating the extend feature, I create the access method to every object on the stage. Humph. This just broke down the walls and made it possible for my script to directly effect things on the stage...later. Later, meaning after something has happened. I would have had this feature anyway, but it would have worked much differently. This shortened it up real nice. Before, I would have had to assign everything off the top to each object as it is encountered and the STAGE would understand what to do with it. Stage, meaning that technically my Object has "lost possession of the ball" and flash will now treat everything like a "static" element.

The new way allows me to pick up or drop the ball all that I like. Since I am also allowing the ability to dot syntax into properties, I am a math EVAL style parser away from performing math operations on them.

display[myObject].xstageWidth - display[myObject].width)/2

Now we are talking about some real power. What if you had 100 displays that you wanted shown in a 10x10 grid, with 4 pixels of padding on every side? Ya see? Before things would be manipulated by events that were assigned to them in the very beginning. Some things are simply not events. What if you have a recommended screen resolution for your app and you want to perform a check to assure that the users resolution is compatible? The users resolution is not an event, it's a condition. Now an event can be fired upon some condition being met, because I can go get the thing I want to effect, by name, anytime.

This also means that you can change the thing that gets effected based on other conditions that were not presented by an event.

In a more layman term:

Say you were building a video game and you wanted a different enemy explosion based on what type of bullet it gets hit with. Before, you would of had to make one big element (and more tech stuff). The "new" way would allow you to simply "overwirte" an object at the last second with a pre-cached image that coincides with the one you want to display for that type of death. Instead of a bunch of enemies floating around with all this invisible junk attached to them and that junk also being duplicates. You would have virtually empty enemies that display a reference on impact.

That is some serious optimization. Now, how close am I to being that far? Pssh, let's see..all I have to do is finish the targetName system and write an entire EVAL style math parser that recognizes keywords.

Uh, yeah, I'll have it done after lunch tomorrow o.O

to clarify: I am far far far from having my system this awesome. It took me over a month to parse the crap out of a string - ?now I have to parse that string into math...that really maths?

ya, Imma definitely need some time to think about that one. Not to mention the crossover problems. Like:

() = array, but it doesn't equal that in math. Hmmm, although an array might be a damn good way to store those equations. Do each array index, reassigning the product to the index, then follow the conventional math flow for the remaining content. Hmmm, maybe I can build a math EVAL. My targetName system will handle the "keywords", arrays for the groups...

I still need time to really consider all the implications, but for now, lets say that this is "turned on".

[MadGypsy]

Gameplan



I know my chart is crazy but bare with me, it's pretty easy.

PURPLE: Merely illustrates that I'm importing that file.
BLUE: illustrates that overwrite arrays can effect anything in their parent and anything within those parents.
RED: is to show where my names are coming from. Dot syntax does work here, but there are a bunch of conditions that I still haven't accommodated for. However, I did accommodate for this condition: $display[some_display].filters[0]
GREEN: points out where these objects actually end up

I'm not gonna lie, there is a lot more to do with this. This is almost like a proof of concept. You can currently append to any object or object being stored in an array index. You cannot append to an array directly (yet).

I spent a little extra time on the extend search system, this will eventually be made more dynamic and become the default ($display[targetName].property style) search system - carrying over to finding the actual display objects later.

I think I am going to take all of my free time tomorrow and just make this better.

EDIT: I just realized that I probably should have done it the other way around put the filters in extend, leaving all the actual textfield stuff where it belongs. This would have made more sense to illustrate my extension and its purpose. I was honestly just happy that it worked.

EDIT: Hmmm. I just realized something. My overwrite feature is semi-useless. Say I made one object class that i want to use over and over. Let's also say that it is a textfield. Let's finally say that the text overwrite token is %0.

Do you see the problem here? What if I want more than one instance of the textbox to say 2 different things, on the same level? It's impossible (this way) , both textfields would be assigned the value of overwrite[0].

That's OK, I've already solved this problem, right before I realized it existed. The same target/targetName system that I use for extend can now be used to make overwrites specific.

Which will in turn make my code a couple of hundred line shorter, because the extend function just became the extend/overwrite function. Although, it's just going to go right back up, cause the extend function needs to be expanded.

lol

See what I'm saying? It's like, how many features can I pack into 1000 lines. Apparently quite a few.

[MadGypsy]

Ok, I have thought about the overwrite/extend system heavily. It seems that in order for me to combine the 2 systems, I have to change the way I do overwrites. My target system is implemented within an object, because after all, where am I going to put a target field on an array? Array.target - that isn't going to work. My arrays have the power to be treated like objects but my system suppresses that functionality (on purpose). I'll go into great length as to exactly why at the bottom of this post*

So, the new overwrite system needs to work with the same signature as extend.

extend

extend:
{
    target:$display[targetName].optional[0].optional,
    //all the data that is to be included in the extension of a remote object
}

old overwrite

overwrite(value,value,value,as many as you want)

new overwrite

overwrite:
{
    target:$display[targetName].optional[0].optional,
    data:(value,value,value,as many values as you want)
}

or

overwrite:
{
    target:$display[targetName].optional[0].optional,
    data[0]:value,
    data[1]:value,
    data[2]:value,
    data[3]:as many values as you want
}

This also means that now overwrite will have to be a same-name, so an array of overwrite objects can be used to overwrite different specific content. Really, i'm just "ho-humming" along here, cause none of what I just said is any kind of mystery or problem. This post stands more as FYI than me thinking my way through a problem.

* Why I suppressed named content on ultimate Array objects.

This was something that I realized right off the bat of starting this project. I am going to try and describe it to you in the most complicated way possible. When I say code/script, I mean for the language I am programming in (AS3 ie...not xxon) from here on out, for this *'d portion.

Every single bit of code that I import is a class, those classes may also import or extend other classes. Lets consider a 3d map. You start with a cube, you then hollow it out and you have a room. Well, for examples sake lets say that room extends cube. It uses all of the properties of cube, but it has the added feature that it is actually many cubes.

Well, Object is one of the base classes for Array. So Array extends Object. Which makes perfect sense cause Array can do everything that Object can do, but it can also index it's children.

In my system Object is considered a parent with named children and an array is considered a parent with indexed children. These stark differences are there because I need to be able to know what type of content I am processing. If it's an array I can cycle through it's indexes. If it's an Object I can cycle through it's .names array. If I was treating arrays to their full potential (ie allowing them the power of an Object) I would have no easy way to determine how to process the contents.

Let me show you an example of inheritance

x = new Array();
if(x is Object)
{
    //do something
}

The above code sets x to be an Array and then checks to see if it is an Object. Since Array extends the Object class, this expression will evaluate to true and run the code. This is "bad". Obviously, I am checking for an Object cause I don't want an Array.

This is where II have to go to the very root of things and get some real answers

x = new Array();
if(getQualifiedClassName(x) == "Object")
{
    //do something
}

I have checks like this all throughout my script and since I know that an object has names and an array has indexes. I can process the code with great precision and optimization.

I do however, take advantage of the Objectness of an Array, heavily, throughout my parser script. I don't allow xxon users to have them, but they are key in assembling an array from a string.

EDIT: You know what "gets me off" about all of this? I am just making all of this up. Before people that are used to my lil jokes get confused, I do not mean this is fake. It is very real and a hell of a lot of work. I mean that I just "decided" to create an entire language and engine out of the blue and I didn't even sit down for 5 seconds and plan any of this stuff out.

Well, maybe that is somewhat untrue. I plan in reverse. I make a bunch of stuff, realize how I can make it more and then "plan" on how the hell I'm gonna get it into the script professionally. But to claim any kind of actual planning went on would be ridiculous, cause I still don't even know what the hell I'm making. I have ideas on some of what, whatever this is, can do.

And that's great! How far in left field do you have to be to say:

"Imma make the hell out of some crap that I haven't even figured out. It's gonna be real complicated, whatever it is. I will start from scratch and build every bit of this anonymous thing and devote all of my free time to the creation of it."

Never ever let it be said that I don't believe in me. I even believe in me when I don't even know what I'm trying to do and apparently absurdity and complexity aren't even considered.

EDIT:

Wow, this was a bit of a mindfuck. I mentally went through the entire process again. My new conclusion is to turn overwrite and extend into one object. So I am back at implement. As a matter of fact I almost right back at the first overwrite/extend method. However, this time there is a big difference. I can target any object that I want directly. Now my compiler isn't searching everything under the sun til it finds overwritable or extendable data. So I can actually get rid of the extend command.

My new and hopefully final decision is to use this pattern

implement:
{
    target:$display[targetName],

    overwrite:(value,value,value),

    //"extra" data
    properties:
    {
        color:0x000000,
        width:200,
        height:200,
        x:10,
        y:10
    }
}

This is how it will work. Seek will look for an implement object, upon finding one it will parse its target field to the proper object.property. If an overwrite array is present it will overwrite all the appropriate data. If anything else is present it will get appended as a child of the target.

This will allow the ability to isolate a main parent, extend that parent on the "top level" and overwrite data on any and every descendent. Simply excluding an overwrite array or "extra data" will exclude whether or not it bothers to overwrite or extend. Voila, extend command is useless, "extension" is implied by the presence of "extra data" within the implement object.

Now I am back to overwrite not being a sameName (which is good*) and extend not even existing (which is good*). Unfortunately, implement will have to be a same name (which is bad*)

*up until now, sameNames only consisted of "engine commands", now it has 1 "compiler command" in it. I mean, this is probably nothing and maybe the sameNames array will eventually see a lot of this. However, overwrite is a compiler command and is "hidden" from the sameNames array. import is a compiler command and it is also hidden. Hmmm, maybe I need to think about this more...this may be nothing or it may be a huge headache. I'd like to know before I start making changes.

pssh: well, for one, it's been in the Array this whole time. I guess I never took it out from the first time I was using it. And for two, it's not going to effect it at all. All same names does is tell my compiler to turn the object into a nameless object on an array index of an Array of the same name (lol,true story), so,it's jus gonna be and do exactly what i need.

[MadGypsy]

OK, I have totally done exactly what I said above



this image uses the same colors (except purple) and the colors have the same meaning as the last image I posted. The difference here is the organization, specificity and method of my overwrite/extend.

You may notice that in this example I made the implication sensical. We have a display of type TextObject that is having it's native properties overwritten and then the entire element gets extended with effects (filters). This iis a shining example of what I set out to do with overwrite and extend.

Since you can have as many implements as you want and each one can have a separate target, you can keep calling up the same "pre-made" xxon element and duplicate it with different values. Now we are starting to get somewhere.

I still need to work on the part of the script that does the actual extending, but for all intents and purposes, this is the method and it is solid. Speaking of solid, how do I know it is solid? It hasn't even been an hour since I invented it, how do I know it is solid? My trace statements (my attachment a few posts up, as an example). Trace statements are a story I have written that gets echoed out as the parser rolls along. Much of the data that the trace spits out is dynamic. So, I don't only have my lil story saying "Now I'm doing this and checking for this.." I also have actual data "and it equals this...".

This allows me to literally profile the behavior of my parser upon every step of the procedure. If something is not going right (or even if it is going right) I can find it quickly. This is also how I make major advancements/changes so fast. Think about it, I posted the last edit of the last post like 4 hours ago, I went and ate dinner and stared at the wall for a hour, then I come back with exactly what I said. This wasn't some minor change either.

Taking the time to write a book in my script has paid off greatly.

Arggh a stupid catch22. My method still is not right. The targetName is static on the damn element, meaning every....blah I'm not explaining all of this. lol

it's stuck in a catch22, that's all that needs to be said for now. I am really blown away as to how I am going to get around this one. This is gonna take a seriously ingenious solution.

[damage_inc]

Dude... this is thee most advanced "Hello World" coding I have ever seen!!!

Do you have cvars in a console as well! "sv_MadGypsy.Exit.Catch22 1"
Jus' teasin' Keep on keeping on,
- damage_

[MadGypsy]

Dude... this is thee most advanced "Hello World" coding I have ever seen!!!

Yeah, my code really isn't geared to these lil' simple things. All this advancement in the code is going to equal a lot more efficient programming structure for big programs. I am really pushing for the ability to duplicate code that can be overwritten and/or extended, while at the same time providing a robust (yet understandable) syntax.

[Syluxguy28O3]

complexity=imagination

[MadGypsy]

Well, I certainly have a lot of imagination, but I would bypass the complexity if it was possible.

I know that I practically SPAM this thread. This is because of the complexity. One little feature that seems like no big deal, turns into hours of me staring at the walls and running the entire program in my head, over and over, trying to mentally catch any snag that the new feature may encounter.

It's very hard to keep all of this in my head, so I make frequent and never ending updates all along the way, right here.

My last feature was working great, til I realized the catch 22 I created. I have since liberated the code of that catch 22, but I broke a bunch of stuff in the process. And after all isn't that what a catch 22 is, no way to really fix something without breaking it?

So, now I'm sitting on the most advanced version of my parser, in a broken form. {shrugs} I'll have it back up and running before the end of the night (probably). And when I do, it will be on like Donkey Kong cause (as I stated in an earlier post) this is the last parser feature that I am concerned with, for now. So once I get over this last little hump, it will be on to extending the engine and producing some real-world results (ie - not Hello World).

I decided against themes. It's not that I don't want them or can't make them, I feel like at this point they are absolutely unnecessary and my time could be better spent pushing the engine forward. I have this bad habit of trying to build "version 10" on the first build. I could spend the rest of my life and never get past the parser, like that. So, fix the parser to work with all of the current features and move on to the engine without looking back for a long while.


EDIT
Figured it out. My engine wasn't actually broke. As it turns out you cant do this:

child[0]:10,
child[1]:10,
child[2]:80

What did I just do that I cant do (yet)? 10, & 10, - There must be a global replace somewhere in that chunk of code. It's finding 10, and replacing all the 10, 's. I haven't actually checked the code yet, but I am positive this is the case, cause I changed one 10, to 10.0, and all of a sudden everything worked. Tricky oversight indeed, but I still only give this puzzle a 4 (out of 10). I was a bit disappointed that it wasn't something huge.

There's a little lesson for any budding programmers that may read this. Look at how huge my problem seemed and look at what it turned out to be. I've been doing this long enough to consider those off the wall possibilities. That's something you can only gain through experience though. Years and years and years of finding fuck-ups.

Imma go fix it.

EDIT

Well, I think I finally figured out what I want to turn my tech into. Unfortunately, I can't tell you what it is, cause, it 100% doesn't exist yet, so I'd have to kill ya' as soon as I tell ya'. I also have a very long way to go. So long, as a matter-of-fact that, if I said what my idea was, people would never take me serious that I actually intend to build all of it by myself.

I'm not listening to those people.

EDIT

Everything is completely fixed, but I was wrong about the reason. Do you remember a gazillion posts back where I said that I wrote a condition to stop infinite loops from happening if you make a script error? (probably not) - Well, the condition was - if this value = last value STOP. Hah, well, ya see, 10 is the same thing as 10. Now I know that looks identical to you, but to me that is an x and y coordinate.

I simply changed the chunk that it compares to be a snapshot of the whole current object being processed, nobody will be sending 2 identical one of those in in a row. It's actually impossible (unless you type something wrong - is what I meant).