2,461,195 events, 1,203,481 push events, 1,910,782 commit messages, 150,989,609 characters
Fucking bullshit literally no one wanted this shit in a scriptable object why wouldn't it just give you the fucking string so you can decide what to do with it this is why I hate fucking using other people's fucking libraries oh my god so much time wasted holy fuck
Revert "fuck you"
This reverts commit dc1dda6b0e928c034aa3273aa65855cf093c8fbf.
py-ipython: updated to 7.17.0
IPython 7.17 brings a couple of new improvements to API and a couple of user facing changes to make the terminal experience more user friendly.
:ghpull:12407 introduces the ability to pass extra argument to the IPython
debugger class; this is to help a new project from kmaork
(https://github.com/kmaork/madbg) to feature a fully remote debugger.
:ghpull:12410 finally remove support for 3.6, while the codebase is still
technically compatible; IPython will not install on Python 3.6.
lots of work on the debugger and hidden frames from @impact27 in
:ghpull:12437, :ghpull:12445, :ghpull:12460 and in particular
:ghpull:12453 which make the debug magic more robust at handling spaces.
Biggest API addition is code transformation which is done before code execution; IPython allows a number of hooks to catch non-valid Python syntax (magic, prompt stripping...etc). Transformers are usually called many time; typically:
- When trying to figure out whether the code is complete and valid (should we insert a new line or execute ?)
- During actual code execution pass before giving the code to Python's
exec.
This lead to issues when transformer might have had side effects; or do external queries. Starting with IPython 7.17 you can expect your transformer to be called less time.
Input transformers are now called only once in the execution path of
InteractiveShell, allowing to register transformer that potentially have side
effects (note that this is not recommended). Internal methods should_run_async, and
run_cell_async now take a recommended optional transformed_cell, and
preprocessing_exc_tuple parameters that will become mandatory at some point in
the future; that is to say cells need to be explicitly transformed to be valid
Python syntax ahead of trying to run them. :ghpull:12440;
input_transformers can now also have an attribute has_side_effects set
to True, when this attribute is present; this will prevent the transformers
from being ran when IPython is trying to guess whether the user input is
complete. Note that this may means you will need to explicitly execute in some
case where your transformations are now not ran; but will not affect users with
no custom extensions.
I've been doing a lot of back and forth in the PL thread. I love this sort of thing. I knew somebody would bring up Julia sooner or later. Hopefully the guy won't be too annoyed by my comments.
I mean, consider the context. Of course, some guy working on his own language would not have a high opinion of a rival language - that is why he is working on his own thing in the first place. But a lot of people reading this would be shocked that I actually think that and would consider me arrogant.
9:40am. Well, let me chill for a bit. I actually got up 40m ago and have been writing that post in this time.
10:20am. Ok, enough. I need to start. I am really good at wasting my time, I haven't even fininshed my morning reading and yet it is 10:20am.
How did it get to this considering I got up at 8:40?
Open the IDE.
type TopHigherOrder =
| HOUnion of int * TypeVar list * RawTExpr list
| HONominal of int * TypeVar list * RawTExpr
let top_higher_order (l : TopHigherOrder list) =Today my mission will be to get these out of the way.
10:30am. I am thinking. I actually do feel like doing programming now. Wasting time becomes tedious after a while.
Right...now...doing this function is not too hard especially since I have the needed validation functions. But besides this I have to also do proper processing of the bundle. Just plugging a TyHigherOrder into the type environment is not enough.
type HigherOrderCases =
| HOCUnion of (string * TT) list * Map<string,T>When I am doing unboxing, the TC will have to look into a dictionary of these. Let me do the nominal case as well. What is giving me trouble is the real nominal case. I just haven't decided that I want it to be yet.
type HigherOrderCases =
| HOCUnion of (string * TT) list * Map<string,T>
| HOCNominal of (string * TT) list * T
| HOCRealNominal of (string * TT) list * RawTExprI guess I will just do this then.
I'll figure out how to deal with real nominals when the time comes to work on the partial evaluator. In the top down segment trying to access them will be a type errors anyway.
let top_higher_order (l : TopHigherOrder list) =
()Now, let me start dealing with this. First I will plow all of these into the type map. Then I'll be able to validate and evaluate the cases.
11am.
let top_higher_order (l : TopHigherOrder list) (env : Env) =
let ty =
List.fold (fun s (HOUnion(name,i,vars,_) | HONominal(name,i,vars,_)) ->
let tt = List.foldBack (fun (_,x) s -> KindFun(x,s)) (typevars vars) KindStar
Map.add name (TyHigherOrder(i,tt)) s
) env.ty l
let env = {env with ty=ty}
()Mhhh...let me take a little break.
11:10am. Let me resume.
Now I have the env. What I have to do is validate and eval each of the cases now.
11:40am.
type TopHigherOrder =
| HOUnion of name: string * id: int * (string * TT) list * RawTExpr list
| HONominal of name: string * id: int * (string * TT) list * RawTExpr
type HigherOrderCases =
| HOCUnion of (string * TT) list * Map<string,T>
| HOCNominal of (string * TT) list * T
| HOCRealNominal of (string * TT) list * RawTExpr
let top_higher_order (l : TopHigherOrder list) hoc (env : Env) =
let env_ty =
List.fold (fun s (HOUnion(name,i,vars,_) | HONominal(name,i,vars,_)) ->
let tt = List.foldBack (fun (_,x) s -> KindFun(x,s)) vars KindStar
Map.add name (TyHigherOrder(i,tt)) s
) env.ty l
let errors = ResizeArray()
let hoc =
List.fold (fun hoc x ->
match x with
| HOUnion(_,i,vars,l) ->
let env_ty = add_vars env_ty vars
List.fold (fun cases expr ->
try assert_bound_vars env.term env_ty (Choice2Of2 expr)
match eval_no_term expr env_ty with
| TyPair(TySymbol x, b) -> Map.add x b cases
| _ -> errors.Add (ExpectedSymbolAsUnionKey (range_of_texpr expr)); cases
with :? TypeErrorException as x -> errors.Add(x.Data0); cases
) Map.empty l
|> fun l -> Map.add i (HOCUnion(vars,l)) hocYeah, this feels right.
11:45am. Let me take care of the nominals as well.
11:55am.
let eval_term expr env_ty =
let count_term = ref 0
eval (fun _ -> let i = !count_term in incr count_term; TyMetavar(i,KindStar)) expr env_ty, !count_termHere is the helper.
| HONominal(_,i,vars,expr) ->
let env_ty = add_vars env_ty vars
try assert_bound_vars env.term env_ty (Choice2Of2 expr)
let b, count_term = eval_term expr env_ty
let v = if 0 < count_term then HOCRealNominal(vars,expr) else HOCNominal(vars,b)
Map.add i v hoc
with :? TypeErrorException as x -> errors.Add(x.Data0); hocHere is the union case.
Now how about I finish this?
| TypeErrorArray of TypeError []I'll just throw this as an exception if there are any errors in the array.
12:10pm.
if 0 < errors.Count then raise (TypeErrorException (TypeErrors (errors |> Seq.toList)))You know what, I am doing this wrong after all.
type TypeError =
| ExpectedStartKind of TT
| KindError of TT * TT
| RecordKeyNotFound of string
| ExpectedSymbolAsRecordKey of T
| UnboundVariable of VariableBoundError
| ExpectedSymbolAsUnionKey
exception TypeErrorException of (Range * TypeError) listI should have just done this yesterday.
12:20pm. Ok, great. I converted everything to the new form.
if 0 < errors.Count then raise (TypeErrorException (errors |> Seq.toList))
hoc, {env with ty=env_ty}This feels much more natural now.
I am satisfied with how this all came out. This would have been a pain to do yesterday at 5pm.
12:25pm. I want to say that this is it for the type definitions, but I also need to deal with prototype declarations.
...When it comes to instances, I'll leave orphan checking for later.
I want to leave such considerations aside, until I get to dealing with separate files.
Actually, I'll just pass the file path into the function and check that way. Nevermind that for now.
12:30pm. I do not feel like prototypes right now. I'll deal with those after breakfast. After that, it will finally be time to start work on the unifier.
1:40pm. Done with breakfast. Let me slack for a while longer and I will start.
2:05pm. Let me start. Enough slacking. Forget that back and forth and clear your mind. Focus on the present. Bit by bit the language will get done. A bit by bit, I will find my real power.
1k games per second is nothing. When I scale this up to proper size, that is when I am going to get results.
The new wave of AI hardware will not be enough for the Singularity, but at least I will be able to stop acting from such a desparately low position. If I have good poker agents, at that point I will be able to think about making good agents for harder games. At the end of that journey lies the game of real life.
I just want to do it properly. I need to do all the steps in order. Only then will I be able to win in the way that I've envisioned.
Once I get my power, my rationality should return as well and this insanity will loosen.
Until then, my madness and my hate - is going straight into code. Right now I am powerless to do anything but program. I won't turn my back on it ever again. I will bring the project to its conclussion no matter how harsh the path might be.
2:15pm. Since I did unions and nominals, let me also deal with prototype definitions. That should not be too hard.
After that I will start thinking about typechecking terms.
| TopPrototype of Range * VarString * VarString * TypeVar list * RawTExpr2:20pm. Right...
Let me just do it.
2:25pm. I am trying to get my bearings.
let top_higher_order (l : TopHigherOrder list) hoc (env : Env) =
let env_ty =
List.fold (fun s (HOUnion(name,i,vars,_) | HONominal(name,i,vars,_)) ->
let tt = List.foldBack (fun (_,x) s -> KindFun(x,s)) vars KindStarThis is right. For a I forgot how to propagate the vars properly. I lost sense of the reasoning for what the type of the name should be.
2:35pm.
let top_prototype (r,name,a,b,expr) (env : Env) =
let tt = List.foldBack (fun (_,x) s -> KindFun(x,s)) b KindStar
let a = a,ttMy brain is still booting up. It is like my sense left me after I finished the previous parts.
2:50pm.
let top_prototype (name,a,b,expr) (env : Env) =
let tt = List.foldBack (fun (_,x) s -> KindFun(x,s)) b KindStar
let l = (a,tt) :: b
let env_ty = add_vars env.ty l
assert_bound_vars env.term env_ty (Choice2Of2 expr)
let body = eval_no_term expr env_ty |> List.foldBack (fun a b -> TyForall(a,b)) l
{env with term = Map.add name body env.term}I am taking a short breather here. Ughhh...I hadn't thought about this. Somehow I imagined there would be only forall for those outermost variables, but there is no way that will work.
2:55pm. Yeah, I am going to have to apply them separately which is fine.
I can tell already, the partial evaluator will turn out differently that I originally envisioned it, but that won't be a problem.
3:05pm. Do I need to do anything else in this function?
...Later, I will have to have some kind of set that keeps track of higher order types defined in the file as well as prototypes in order to be able of orphan instance checking, but nevermind that for now.
Excluding that, the above is complete. The prototype is just a type definition, so once I add it to the env, there is no difference between it and anything else.
3:15pm. Oh, I forgot to commit earlier it seems. Let me do it now.
This is the ideal spot to do it. What I will do then is step away from the screen for a while to think.
I think I have enough to start work on the unifier, but doing these two top statements has unbalanced me a little and I want to take some time to refocus. Right now I am distracted with thoughts of GADTs and such.
I think GADTs are not going to go into the language for seemingly trivial reasons. They would be easy to implement in the partial evaluator, but their connection to unification is just so confusing.
Their reasoning is perfectly clear in bottom-up mode, but in top down mode I am completely confused how to deal with them in patterns.
One idea that comes to my mind is compile the patterns to their peval form and then typecheck them, but I do not how to deal with that in the context of unification. If I was intending to use bidirectional typechecking I could do it without too much trouble, but unification is giving me trouble.
For example...
union T x =
| A: i32 :. T i32
| B: i32 :. T i64
inl f forall a. (x : T a) =
match a with
| (A: x | B: x) -> ... // What is a?
Trying to figure out a case like this just boggles my mind. You need some kind of forward mode (bottom-up) reasoning for this, but that is explicitly the thing unification is bad at.
3:30pm. Yeah, I can see a way to do GADTs, just not with unification. I think I'll put them into the 'too hard' pile along with higher ranked types."
"5:20pm. Yeah, I thought it would be this long.
The truth is I wanted to stay in bed longer and had to force myself up, and I'll go back after I put in a few words.
Basically, I've been a complete idiot.
union t x = A: () :. t i32
union tt x = B: () :. tt i64
inl f forall x. (a : t x) (b : tt x) =
match a,b with
| A: (), B: () -> ...
If this was Agda, this would have been an impossible case (because x cannot be both i32 and i64) and I could eliminate it right away.
Why am I an idiot? Because this whole time I've been thinking about GADTs I've been wracking my brains with the syntax over a few simple applications of GADTs. It actually completely slipped my mind to consider the above case. I thought it was just about hacking unification to get the right flow, but I've completely underestimated GADTs. In order to actually have them, I'd need the void type and dependent pattern matching.
This is way beyond what I bargained for. No way can I do this. Even if I did, how exactly would I handle the void cases on the bottom up side. What would such code compile to?
No, you can't integrate this with the bottom-up segment. I see now that having GADTs would fundamentally change the nature of the language, but all this time I've been thinking of them like just another feature. They are much further along the path to dependent types than I thought they were.
5:30pm. This happens to me sometimes. I think I am smart, but in hindsight it turns out I've been myopic. I solved half the problem on a few simple examples so I assumed I could do the rest with some effort, but the big picture escaped me.
5:35pm. Ok, now that I have firm reason to deny GADTs rather than just lack of time, this pretty much cements the kind of language Spiral v0.2 is going to be. I no longer have to make space in the attic for such a language feature and that lightens the load I am shouldering.
5:40pm. With this the design is complete. I can just go forward and make the perfect language for a human to use. I do not have to hesitate in embracing unification and global type inference. The combination of top down type inference and bottom up partial evaluation that I have is truly heaven sent. It won't be an easy target to hit even for langauges with more elaborate top-down type systems than Spiral.
5:50pm. Language design is a lot of stress isn't it?
I need some time to acclimate myself. I'll go to bed for a while longer to dwell on this and then wind off after that, but otherwise let me make this the last commit for the day. I will not be doing anymore programming today.
Tomorrow, hopefully I'll find the inspiration to start work on type inference for terms. After I do this, the language will be significantly closer to completeness."
I started the day by chasing the yesterday's graphical bug. I soon confirmed that it's indeed called "[Shadow Acne] (https://digitalrune.github.io/DigitalRune-Documentation/html/3f4d959e-9c98-4a97-8d85-7a73c26145d7.htm)" and can be pretty nasty. It seems that here finally we come to the point where the double precision arithmetic prevails over the floating point.
At the end, I cranked up the epsilon to 0.1f and moved on.
Another interesting bug that I found is however more mysterious. From time to time, the rendering freaks out completely and shows an outworldly bogus output:
I suspect that this has to do with the way random number generator operates, or something. Honestly, I have no idea about what's going on, and why is it sporadic. In any case, this project so far has gifted us a truly marvellous collection of graphical bugs.
Going back to shadow acne, after applying a different diffuse method ("True Lambertian Reflection"), I realized that it's still present there, maybe even clearer:
Everything became clear once I removed the diffusing at all:
It's not about the diffuse at all! We were somehow receiving data with a terrible precision. It wasn't sure if it was about float vs double anymore, but it kind of was the biggest offender so I dug deeper to investigate the bug.
Right now we are getting pure reflections and shadows by polling multiple levels of recursion depth. If I gradually increase it, we get the following progression:
![Effect of the recursion depth increase] (media/day38/depth-evolution.gif)
What we see here that yes, increasing depth does improve the visual fidelity of the output, but there's more to it. There's no difference between recursion depth 20 and 1000.
Next, what we see from this is, that the sky is reflected accurately, it's the normals of the sphere which are flat-shaded until they hit the next "tier". This may be explained in the following manner:
- We use truncation somewhere and information is lost
- The floating point precision is insufficient
- ???
I tried to visualize different information that I receive with the first hit (depth = 1). Seems in order, and I understood that this trail was fine. I had only one avenue remaining: the diffuse algorithm itself.
So, at the end, I realized that my random number generator was returning garbage. It was a truncation error, and by adding a couple assertions the problem was quickly identified and resolved. It was a fun journey.
On a completely unrelated note, I'll have to move to compute shaders on my graphics card, if I'm to continue this journey. Already now I'm only rendering in release mode, unless I want to wait for 15 seconds+ to draw a single frame.
Add pre_070 functions AND FIX RATING CALC FUNCTION ORDER!!
I confused the function for player overall with the score overall function. 🤦 But honestly, the naming is as confusing as it can get. "AggregateSkillsets" and "AggregateRatings". What he hell. There are chart and player skillsets, just like there are chrat and player ratings; they're two names for the same thing. Argh
2001: A Space Odyssey: A more working version
? Added instructions and game overs for clarity, which is fine and dandy.
? Added an invisible wall that stops the enemy tank from crossing toward you and thus potentially touching the monolith which it shouldn't do. Thought for some time about having this invisible wall be literally represented as a river, then realized it's a "watering hole" in the film/book, then realized that getting too literally with the scene was feeling pretty off, so went with the more metaphorical approach to the monolith as the giver of shooting/death.
? Some truly awful hard-coding of numbers present at the moment in part because you can't get the "center" of a set of tiles like the monolith, almost worth positioning a sprite in the same location or literally just using a sprite separate from the tile map? Why didn't I think of that already? Fuck.
? It basically works and basically makes sense.
? I fear there are looming bugs because of the crappy way I handle shooting now that I need to actually do something specific on player/enemy death. Makes me think I should invest in understanding some custom event dispatching, would probably be good to know in general.
Added a Buncha Shit
Fuck coding a dash mechanic, all my homies hate coding a dash mechanic