1,674,816 events, 933,445 push events, 1,311,086 commit messages, 77,621,524 characters
Added new convar for headshot damage on combine soldiers, so it's overrideable with console config. This fixes the annoying hardcoded headshot damange for soldiers! fuck yeah!
"8:50am. Let me chill for a while and I will start.
9:10am. I completely lack tension right now. Let me finish my morning reading and I'll put some words in.
9:50am. Let me start. It is time to get something done.
First of all, I need to wreck the parser. It is time that I start including the ranges of everything in the AST.
Right now, I actually feel strained because I do not have that. It should be an easy decision to just do that, but internally I am bemoaning the loss of modularity that will arise from that. If there is one thing I need to say to myself that would be - get over it.
9:50am. Hmmm, before I start, I do want to do one thing. I really miss having that last statement in a block error message.
let stmts = many1 (if_ (=) statement_parsers) .>>. ((if_ (<=) (skip_keyword SpecIn) >>. root_term) <|> if_ (=) next)I have to make this last part optional and then check for it.
10am.
| ExpectedExpression -> "A sequence of statements should end in an expression."Calling it a block would just cause confusion so I redid the error message.
let stmts =
many1 (if_ (=) (range statement_parsers)) .>>. opt ((if_ (<=) (skip_keyword SpecIn) >>. root_term) <|> if_ (=) next)
>>= fun (a,b) _ -> match b with Some b -> Ok(a,b) | None -> Error [List.last a |> fst, ExpectedExpression]
let expr = if_ (=) next |>> fun x -> [],x
(many1 (stmts <|> expr)
|>> fun x ->
List.foldBack (fun (stmts,expr) s ->
let process_statements s = List.foldBack (fun (_,a) b -> a b) stmts s
match s with
| ValueNone -> ValueSome (process_statements expr)
| ValueSome expr' -> ValueSome (process_statements (l PatE (unop ErrorNonUnit expr) expr'))
) x ValueNone |> ValueOption.get
) dLet me give this a try.
Yeah wonderful, it works.
10:05am. Now...
It is time for the second phase of the parser. I need to annotate the entire AST with the node ranges. I'll also draw out Apply and PairCreate as separate nodes since the typechecker will need to recognize them. Same for the if statement and maybe some other things. Regular Ops will not have a type inferred and will instead just return a metavariable.
10:10am. I'll do this thing properly and to the best of my ability.
Before I can even start on the next phase, I need to make sure that the parser sets up the AST in such a way that I have all the information that I need to operate on it.
This is something that has been causing me a lot of consternation, because I keep wanting to have the ranges, without actually having to do the work in the parser to get them. Back when I was just doing partial evaluation I managed to get away with this, but not anymore.
10:20am. There are a lot of technical challenges when it comes to the 'typechecking' phase, but for today I will just focus on setting up the AST.
Since I am done with the parser, I might as well do this. Once I get this out of the way, I will find it easier to think about the rest. Every time I do, I get distracted by my thoughts swarming to the subject of positional information.
10:25am. Ok, let me commit here and I'll start work."
Simply make the "FADE_OUT" music effect flag by default so more users experience the SMOOTH FADE OUT magic by accident and praise the based client.
updated button handlers advancedmode
it was a goddamn fucking mess so yeah, it's still not finished but it'll do for now
mm, fs: Add vm_ops->name as an alternative to arch_vma_name
arch_vma_name sucks. It's a silly hack, and it's annoying to implement correctly. In fact, AFAICS, even the straightforward x86 implementation is incorrect (I suspect that it breaks if the vdso mapping is split or gets remapped).
This adds a new vm_ops->name operation that can replace it. The followup patches will remove all uses of arch_vma_name on x86, fixing a couple of annoyances in the process.
Signed-off-by: Andy Lutomirski [email protected] Link: http://lkml.kernel.org/r/2eee21791bb36a0a408c5c2bdb382a9e6a41ca4a.1400538962.git.luto@amacapital.net Signed-off-by: H. Peter Anvin [email protected]
"2:20pm. I am halfway into vol 6 of the GGO novel and I really want to keep going, but let me pry myself off that so I can finish the parser redesign. I am having way too much fun with the novel.
2:25pm.
let record = range (curlies (sepBy ((record_var .>> skip_op ":") .>>. next) (skip_op ";"))) |>> fun (r,x) -> RawTRecord(r,Map.ofList x)Ah, damn. I need to do some duplicate checking here.
2:30pm.
let record =
range (curlies (sepBy ((record_var .>> skip_op ":") .>>. next) (skip_op ";")))
>>= fun (r,x) _ ->
let duplicates = ResizeArray()
let h = Collections.Generic.HashSet()
List.iter (fun (name,_) -> if h.Add name = false then duplicates.Add name) x
if 0 = duplicates.Count then Ok(RawTRecord(r,Map.ofList x))
else Error [r, DuplicateVarsInRecordType (Seq.toList duplicates)]2:35pm.
let parenths = rounds (next <|>% RawTB)I never thought about this before. Rather than writing unit here, why not in fact let the unit type be () on type level as well.
2:50pm. Oh, already done with root_type.
Next comes root_term.
3:10pm.
let case_if_then_else d =
let i = col d
let inline f' keyword = skip_keyword keyword >>. next
let inline f keyword = indent i (<=) (f' keyword)
(range (tuple4 (f' SpecIf) (f SpecThen) (many (f SpecElif .>>. f SpecThen)) (opt (f SpecElse)))
|>> fun (r,(cond,tr,elifs,fl)) ->
let fl =
List.foldBack (fun (cond,tr) fl ->
match fl with
| Some fl -> RawIf(range_combine (range_of_expr cond) (range_of_expr fl),cond,tr,fl) |> Some
| None ->
let r = range_of_expr tr
RawIf(range_combine (range_of_expr cond) r,cond,tr,RawB r) |> Some
) elifs fl
if' cond tr fl
) dAgh, this thing is giving me trouble.
3:15pm.
let case_if_then_else d =
let i = col d
let inline f' keyword = skip_keyword keyword >>. next
let inline f keyword = indent i (<=) (f' keyword)
(pipe4 (f' SpecIf) (f SpecThen) (many (f SpecElif .>>. f SpecThen)) (opt (f SpecElse))
(fun cond tr elifs fl ->
let f cond tr = function
| Some fl -> RawIf(range_combine (range_of_expr cond) (range_of_expr fl),cond,tr,fl)
| None -> let r = range_of_expr tr in RawIf(range_combine (range_of_expr cond) r,cond,tr,RawB r)
let fl = List.foldBack (fun (cond,tr) fl -> f cond tr fl |> Some) elifs fl
f cond tr fl)) dLet me just go with this.
...Am I wrong here? Should I not be doing these kinds of rewrites at all in the parsing stage even if it means doing more work on the other stages?
Should I have gone with the idea of making ranges composite?
Let me stop here just for a bit. Maybe I'll do a redesign...
3:50pm. Ok, I think I know what is an acceptable compromise.
| RawIfThenElse of Range * RawExpr * RawExpr * RawExpr
| RawIfThen of Range * RawExpr * RawExpr3:55pm.
let case_if_then_else d =
let i = col d
let inline f' keyword = skip_keyword keyword >>. next
let inline f keyword = indent i (<=) (f' keyword)
(pipe4 (f' SpecIf) (f SpecThen) (many (f SpecElif .>>. f SpecThen)) (opt (f SpecElse))
(fun cond tr elifs fl ->
let f cond tr = function
| Some fl -> RawIfThenElse(range_combine (range_of_expr cond) (range_of_expr fl),cond,tr,fl)
| None -> RawIfThen(range_combine (range_of_expr cond) (range_of_expr tr),cond,tr)
let fl = List.foldBack (fun (cond,tr) fl -> f cond tr fl |> Some) elifs fl
f cond tr fl)) dThis is not good enough though. I need proper ranges.
let case_if_then_else d =
let i = col d
let inline f' keyword = range (skip_keyword keyword >>. next)
let inline f keyword = indent i (<=) (f' keyword)
(pipe4 (f' SpecIf) (f SpecThen) (many (f SpecElif .>>. f SpecThen)) (opt (f SpecElse))
(fun cond tr elifs fl ->
let f cond tr = function
| Some fl -> fst fl, RawIfThenElse(range_combine (fst cond) (fst fl),snd cond,snd tr,snd fl)
| None -> fst tr, RawIfThen(range_combine (fst cond) (fst tr),snd cond,snd tr)
let fl = List.foldBack (fun (cond,tr) fl -> f cond tr fl |> Some) elifs fl
f cond tr fl)) dThis is better. Now the if statements will have proper ranges in them.
4:05pm. I am just getting lost in daydreams and brosing /pol/ now instead of programming.
But I am really not happy with this.
I do want the ability to freely rewrite instead of having to make things up when it comes to ranges. This is such an annoyance. This is what I was afraid of. Mentally I always fall aground on this issue. Once I start the typechecker, I will know how severe it is.
But it should be fine. This if statement thing is just particularly eggergious as an issue.
4:10pm. Forget this.
Let me finish the parser redesign and then I'll call it a day early.
| "`" -> type_expr d
| "``" -> (type_expr |>> unop TypeToVar) dThis one...should not be builtin.
4:55pm. Done with lunch. Let me resume. I am nearly done.
5:10pm. Now I find myself surfing /a/. Focus me, focus.
5:15pm. No, fuck! Fuck!!!
This is how I feel about today's redesign - it is shit!
5:55pm. It is done.
6pm. If what I had before I started this redesign was 8/10, after putting in the ranges it feels like it is 4/10 at best.
I am just just completely torn on this. I feel lost and adrift.
Today's session was awful. I forced myself to squeeze the code out and I completely ingored my inner voice just because I wanted to push things along. I hate it.
6:05pm. I mean, it just adding ranges to all the nodes. You would imagine this would be easy. But I also want to be free to do rewrites on the AST, and the decision what to do with ranges opens a hole in the story.
6:20pm. I am just dwelling on today's work. No, this is not the final version. I am going to have to redo it tomorrow using what I've done today as base.
The issue is that simply in too many places I am outright lying about the ranges. There are too many places where the rewrite might have made sense without the ranges, but now that this info needs to be there I am crossing a line. My entire being is against the design I've done today.
| RawIfThenElse of Range * RawExpr * RawExpr * RawExpr
| RawIfThen of Range * RawExpr * RawExprIf there is a radical decision I feel like I've made correctly, then that would be splitting the if statements into two. This is right.
6:30pm. I should be able to do this right.
It is simply unavoidable. If I actually want to be able to tell the user where the typechecking went wrong, I need to be prepared to do some extra work.
Whereas before a simple rewrite might have sufficed, now I will have to roll up my sleeves and do a bit repeat work simply for the sake of user experience.
I am going to go all over this tomorrow. I should be able to come to a more acceptable tradeoff thanks to today's experience. Today I just did not want to let lethargy stop me, but I need to do it properly next.
I have a good idea of how to fix the pain spots, but once more I need to give the parser the dedication it deserves. Today I barely payed attention to what I was doing."
0.19.9 (#43)
-
0.19.9
-
for fuck sake i hate this shit
Maybe we don't need unit tests here?
That sounds so incredibly foolish, but we've got a pretty thin client here with a deep dependency on an external API and is mostly front-end facing. Kind of a worst case scenario for unit testing, right? Maximum cost and minimum benefit. Unit tests on the design system and the API, for sure, but this part doesn't do much more than pass things along to one or the other. Still, I figure there will come a day when I regret this, but I'm also pretty sure it will be better to address that when that day comes and we know exactly the shape of the problem we're facing, than to spin my wheels a bunch right now trying to anticipate what those future gaps might be. Sorry, Future Jason, if I try to solve all of your problems you'll still be trying to get this damn thing out in the first place.
40.1. The Formidable v-model{Creating the search-bar Component}
Ya know what just occurred to me? We haven't talked at all about form elements yet! And what a wonderful coincidence! Because our next challenge is to add a search bar input to filter the product list. The search bar will, of course, contain some HTML. It will also need to manage the value of the search bar and help us know when we should filter the product list. That's enough that I think we should isolate this in a new component.
Creating the search-bar Component In components/, create a new file called search-bar.vue. Add the with
Some changes towards usability and stability WIP still
Main focus of this commit was at first, just to work on the Network.gd and make it as robust as possible. Altough it is not what happened as seen in this commit.
The Network code is not READY yet, i just copied and pasted the code from the docs, to make it easier to implement the code later on.
Now account caching is much better, if you login to another account it will automatically cache that account and you can refer back to login to it using the username...altough, if you didn't specify a username its a bit tricky yet, because there is no UI to actually tell what was the randomly generated username by nakama. Good enought for now, tho
The next step is just to make sure the code does not break easily with some tests, mainly Network wise.
Implement some simple UI components to display the accounts that are in Cache.
Implement some simple UI to display and access the Network API i made.
Not the best piece of code yet, but i'm pretty proud with the progress, because i know how things work for once in my life. I know its a bit messy, i might change it later, but so far i'm confident i can work this through.
Thank you God.
changed vpc command line
Fuck you I dont want vscode bullshit.