WorldSpawn official WIP thread

[MadGypsy]

Maaan, I'm still not ready to hit this BytesKey stuff yet. I thought I had all this "T, V" stuff figured out but, it seems like there is still a little mystery to it. I decided to run through the Key abstract real quick and get rid of all the dynamics, replacing them with unknown<0> (ie T). I thought it was going to be straight forward and work but, of course it broke everything. The thing is, all I did, essentially, was reuse the concept that I used for @:from. @:from worked, why is cascading the concept throughout the script broken? This is what I need to learn. Haxe has a super poor information base so, as usual, I will have to use observation to figure this out.

That's cool. That's how I figured out 99% of this shit in the first place so, it's just more of the same. I'll tell ya, there is nothing more fun than figuring out a language with very little more than a slew of possible syntax to work with ::mega-sarc::. However, I am no dummy, the best way to figure this shit out is with some tester script that doesn't really do jack shit and the only results I want are an absence of errors.

[MadGypsy]

crazy. I can't get a simple <V> to work but this nonsense works perfect. I was hoping it wouldn't work so I could get some errors that might actually learn me summin.


However, there is a little to be learned from this. Apparently anything you put in an unknown has instant meaning. This is evidenced by A and then immediately using A in the V type constraint. If I omit the first A it says that the second A was not defined. Also (not pictured) by using array in the V type constraint, apparently dynamic inherits arrays properties (at least within the function). This was evidenced because length is not a property on dynamic but, when attempting to return c.length where c = a Dynamic the result was null instead of some "property length not found on type Dynamic" error.

In all honesty, none of the languages that I know have the option of using a capital letter to represent an unknown type and if any of them do, I never got that far so, this is a bit foreign to me. I'm trying to wrap my head around it but, it all seems to be willy-nilly. Almost like you just make up some crazy shit and hope it works. Surely there is some structure to this that I simply am not seeing yet.

[MadGypsy]

I think I have just about figured this out. I know this much. I have pieces of my Key abstract working with unknowns and type constraints. I also have some complex type constraints that are far less complex than what I was initially trying but cover all the bases.

here's a for instance


//error: unable to do something blah blah blah type V
<A, B, VDynamic, Array<B>, IMap<A, B>)>
This is because Array and IMap can Monomorph with Dynamic but they can't Monomorph with each other.

//works perfect for ALL Arrays, ALL IMaps and Dynamic
<A, VDynamic, Iterable<A>)>
This is because Array and IMap can monomorph with Dynamic and Iterable

MONOMORPH - the one word answer to all of my questions

The trick is to constrain to types that are SUPER basic so more advanced types qualify as a possible type for the constraint. This may seem just a little confusing because Dynamic is not an Iterable. Array and IMap qualify as a Dynamic and an Iterable but Dynamic (as an object) does not. It's a burp, Dynamic is everything even if it isn't BUT

This would not qualify because typed as dynamic or not this is an Int and Int can't Monomorph with an Iterable
var iynamic = 1;

this however is a Dynamic that is a Dynamic and will monomorph with anything.
var objynamic = {...stuff...}

Confusing, I know. Welcome to my fucked up world where words mean what you think they do unless they don't.

Mark my words, No new Tax... oops, I mean, I just about have this unknown/constraint shit licked.

note:
@var iynamic = 1;

Technically, all that does is make sure you will hate yourself later cause, even though that is typed as Dynamic it won't be Dynamic after you make it equal 1. It won't be Dynamic after you make it equal anything (except an object). Let's say you did the above and later in your code did this

i = "whatever"

All that accomplished was making sure the compiler wont check it and as soon as your compiled app hits the reassignment your app will die a horrible death and never tell you why. Let's be very confusingly clear, Dynamic is everything and it is also only ONE thing. This is because

var iynamic = 1
gets compiled to
var iynamic<Int> = 1
as soon as the compiler hits that 1 assignment.

Dynamic<Int> != Dynamic any more than pants pockets = pants
In the end there is only one Dynamic (objects)

Type Inference - it can be your buddy or your greatest enemy. It all depends on how much you suck at programming.

[MadGypsy]

Totally licked this crap. The "tricky" thing is, when you use these super basic types and then dump a more complex valid type in, for the life of the function it does not recognize the full type. It only recognizes the properties of the basic type. I actually did better than I ever knew in creating my Key abstract because regardless of type it was already pretty unified so, I just needed to create a typedef for the couple little properties that I was using in the function and voila... unknown and constraints are my bitch.

ALSO abstracts are my bitch. The cherry has been fully popped. It's really not that complicated. It was just complicated when I had no data to go on and had to figure out what the hell was actually happening. I figured it out.

---

Here's a little explanation of some kind about something

Iterable<T> shares 2 properties with IMap and Array. When an IMap or Array gets dumped in where an Iterable<T> is constraining ONLY the 2 fields that Iterable<T> possesses are available, this even goes down to stuff like using Array indexes (not available) BUT there is nothing stopping me from

case IsArray:
var temp:Array<T> = cast TheConstrainedArg<T>;

and voila, I get my entire array back to work with while maintaining the fact that the initial constrained argument can accept some things but, it can't accept everything (Dynamic). And that's really the point here... to have some versatility without opening up the flood gates to a whole bunch of shit that isnt even a valid value for my system. Also instead of always returning Array<Dynamic> because I don't know what type of values an array will contain I can "unknown" it and maintain a much more strict typing system when it all boils down. It's just way better, period.

I do not regret, at all, spending so much time on this. I've just upped my programming skills significantly and added a whole new arsenal of possibilities to my cache.

[MadGypsy]

lol this has to be some bullshit. I have as many guests as the amount of pages I just read in my thread. There are 38 pages in this thread. I started on page 38 and worked backwards to page 7. Thirty-eight minus the 6 pages I did not read is 32 and I have exactly that many guests. Not to mention, I have been here 6 years and I pay LOTS of attention to the number of people viewing my stuff. When I was writing entirely quake related material I believe the highest number I ever saw was 14 but, I ramble on about type constraints in Haxe and now I have 32 viewers? Pbbbt, there is some kind of bullshit. Those are not real people.

Methinks this site has some kind of "follow-bot" to make it seem like pages are garnering attention. I've wondered this before.

[Spike]

187 online users. and here I was thinking quake was dead...

[MadGypsy]

@spike

lol. You are being sarcastic, right? I don't know if I'm wrong or not about this "follow-bot" thing but, if I am right, maybe most of those users were generated by page visits. It may be interesting to note that 187 users online is a number that is almost static for central time early AM hours.

Don't worry, Gypsy P.I. is on the case...lmao.

[Spike]

311 right now.

[MadGypsy]

This was the hardest and most important function to get to work and the thing is, it shouldn't. This function calls itself recursively and keeps reassigning itself the next value in the route til it gets to the end of the route and bubbles all the way up to the initial call with the value. The thing is, the value is almost never unifiable with iterable<a>. The final value is never set in a another recursion of this function so, that explains why it isn't throwing errors for calling the function (ex with an Int) BUT the return value is of V which was monomorphed with iterable<a>. This tells me that unknowns as returned values are not considered monomorphs. They are considered "possibles" cause ex: Int is not an iterable<a> but, it is a dynamic



This simple test proves that the return value is not losing it's type and/or being cast as an iterable. "new thing" is definitely a String and 7 is definitely an Int. I could run through every type but, there is no reason to think Float and Bool won't work. Those are the only 2 other base types that do not qualify as an iterable<a>. Also, if I remember correctly Int is an implicit cast of Float and Bool is an implicit cast of Int (deep in the @:coreAPI) so, hypothetically testing int sorta-kinda covers float and bool.



edit: ya know, even though this is supposedly better (because it is more locked down) I like my old code better. I need to get used to how junky this shit seems to me. It's a lot of hubbub to stop problems I wasn't even having. Do you know what my "huge" gain is from all of this? Let's say you tried to dump in a Vector3D (which isn't currently supported) instead of everything just breaking silently you would get an error that says "parseExpression.V expects Iterable.A". Yippee Doodle Doo. The even dumber thing is, YOU can't stick ANYTHING in in the first place. re: private static function. This is an internal process that is delegated by more internal processes. So really my "huge" gain is if I wanted to extend this it would give ME errors that remind me I need to extend the monomorph. Do you really think I'm going to forget that after all of this? Learning all of this stuff is useful but, I don't think it's useful here. I'm going back to my unconstrained way and I'll leave the constrained copy laying around if I ever decide to change my mind. This would be very useful if my abstract was an @:multiType that @:from/@:to different classes based on the type of unknown. That's how Map works. Let's say you Map<String, Dynamic>, that would technically be a StringMap<Dynamic> and having all these constraints would make more sense because the unknowns/constraints would be part of public methods.

[MadGypsy]

I was digging in the haxe api learning things by simply looking at the actual haxe source and I ended up in the Map class for a minute. I decided to go look at the classes that Map gets converted to (based on it's unknowns). A quick glance and I was reminded that I was confused about something. None of the functions in any of the core map classes have a body.

IntMap, StringMap, ObjectMap, EnumMap and every other Map have all the same functions but none of them have a body. The Map<K,V> abstract has all the same functions, plus a few extras for @:arrayAccess/@:to/@:from and all of them have a body but primarily the bodies are nothing but this.sameFunc().

So if nothing has a damn body and the one thing that does have a body is just calling back to it's bodiless version in whichever underlying class it gets converted to, how the hell does it do it anything?

I found the answer.

All of the Map classes (StringMap, IntMap, etc) are "extern class". I didn't know what that meant but I know extern means external so, I started digging way deep in the haxe API. I have a directory structure on my computer like

haxe
....lib
........cpp
........cs
........flash
........python
........php
........etc.....

in all of those language folders is a _std folder. In every one of those _std folders I found a haxe folder and inside every one of those haxe folders I found a new version of all the various Map classes.

This is like compiler conditions on steroids. By observation, you make an extern, mirror it's namespace in every language you want to use and then write the class anew in the language of the folder you are in (but with an .hx extension). Also every new version has to start with @:coreAPI.

There are a good number of languages that I could totally use this method with. I can't think of anything where I would need to go this deep but if I ever do it's nice to know that I've made all the connections.

There are so many layers to this language. These people are geniuses.

[MadGypsy]

I've pretty much always used my technical posts regarding whatever I am working on as a sort of sounding board. What I mean is, by writing this stuff out in a way that is meant to be understandable (readable as paragraphs) I sort of solidify it. It becomes "transparent" to me. I often have ideas that I do not fully understand and "talking them out" makes them happen.

I recently decided that the best way to key objects is to invent better objects. The possibilities of a JSON object were basically the extent. That is definitely true if you are getting the object from JSON. I created HXON. It's strong typed JSON.

json
"object":{"name":"a string value"}

hxon
object<StringMap<String>>:{name:"a string value"}

more complex example:

data:"some data",
entity<Dynamic>:{
	props<Dynamic>:{
		health:200,
		shield:200,
		weapons<Array<String>>:[
			"rifle",
			"pistol\""
		]
	}
},
thing<Dynamic>:{
	other<Array<String>>:["one","two","three"]
}

The problem with regular objects is that they do not enforce strict typing. If I went as simple as reading the types from the above script and simply assigning them as that type to some field in a dynamic, it would not suffice. Sure the value would initially be correct but you could assign anything you imagine in it's place and it would just do it.

...more on that in a minute

Enums in Haxe are allowed to have a value (sort of)

enum Sample_e {
Container(src:String);
Value;
}

var samp:Sample_e = Container("{...}");

switch(samp){
case Container(src): // do stuff with src
case Value: //satisfy all conditions
}

In that Enum, src was specifically typed as a string and type checking is definitely going to complain if I try to put something other than a string in Container(src). With that info and the other info about type checking being a problem in objects we...

enum ValueType_e
{
	HxInt		(src:Null<Int>);
	HxUInt		(src:Null<UInt>);
	HxBool		(src:Null<Bool>);
	HxFloat		(src:Null<Float>);
	HxString	(src:Null<String>);
	HxDynamic	(src:Null<Dynamic>);
	HxArray		(src:Array<Null<Value>>);
	HxIntMap	(src:Map<Int, Null<Value>>);
	HxStringMap	(src:Map<String, Null<Value>>);
}

The result is an enum value system that is strict typed. Now the concept is to have an object that only consists of ValueType_e values and have key access reroute to the src property of the current ValueType_e.

You may wonder what happens when you reach a ValueType of type object (hence reverting back to a type checking problem). Every single solitary value within whatever kind of hxon conglomeration you could imagine is technically ValueType_e and every value will be read and written through the current, and already decided, ValueType_e for any given key/index. This means even arrays, maps, everything will have to have their key access rerouted to the ValueType_e src

[MadGypsy]

I'm waiting for something to compile so I'll take this moment to add something to my last post. Although it may seem like I am still messing with keying objects, I'm actually not. I stated in an earlier thread that I wanted to make it possible to create a template for bytes to be written into. IN order to do that I, of course, need to create a template system. The current Hxon notation is a very slight deviation from that. In Hxon I am allowing values to be assigned in the script. For the bytes template it will be identical minus values. So...

if this is hxon
<Dynamic>{
name<String>:"Michael",
age<Int>:42
}

this would be the bytes template
<Dynamic>{
name<String16>,
age<Int8>
}

and the name "Michael" and age 42 would be read from some bytestream based on other conditions and factors that are not necessarily directly in the template.

All that being said, The object that the bytes become would be reflected as hxon. So, I'm not really still messing with keys. I'm upgrading the entire idea to be more useful and accurate. The keying of all this is little more than an afterthought when placed in contrast to all the other goals.

[ijazz]

Yeah are you writing this with Vulkan graphics?
I am not really familiar with code(QC is just the beginning)

[MadGypsy]

@vulkan

No.

I have a HaXe game engine that is about 80% complete (opengl/directx) but, all of my current focus is related to contributing to HaXe directly. I've written a number of multi-platform API's for HaXe. My focus is to make them definitive. I'm spending a lot of time on Objects because they could be better but, also because, the more I mess with Objects the stronger of a HaXe programmer I'm becoming. Really, I'm becoming a stronger programmer period. HaXe utilizes language constructs from a bunch of different languages. It becomes exponential at some point.

@QC is just the beginning.

Learn the hell out of it. Don't just learn how to program in QC. Learn how QC programmers program with QC. It is almost 100% possible to write HaXe verbatim to ActionScript3. There can be just this little bitty difference between those 2 languages. I program in AS3 like a pro AS3 programmer. This is because I didn't just study AS3. I also studied AS3 programmers. Now, I approach HaXe like a HaXe programmer. I could just barely change my AS3 and I would be missing like 30% of the Haxe language possibilities. What I am trying to tell you is, It is mildly complicated to learn a language; it is substantially harder to learn how to program like a pro in that language (any). Any time you spend looking at really good code and recognizing why it is good is time well spent.

[MadGypsy]

My little idea of making objects out of enums wasn't a bad one. It was a terrible one. I got all of my goals with this idea to work flawlessly. I however, completely overlooked something so simple that I am embarrassed to even identify it. That's pretty bad. Y'all know I don't hold jack shit (in/back), no matter what it is.

Anyway, I'm not too concerned. This idea plus the object key system I already have gave me an idea about how I can sort of merge the 2 ideas (leaning more toward the "old" way) and very probably get the results I want ~ a fully typed and compile time type-checked and dead code elimination-friendly keyable object that can technically be any container type due to a broad unification.

I have a bunch of that ending description done. It's the type-checking part and dead code elimination parts that are missing. I believe solving the type checking part will auto-fix the dead code elimination. I may be wrong but, it's definitely true that DCE skips objects because the values are not strictly typed so, it at least isn't crazy to believe that fixing strict types will have some impact on DCE.