2,512,222 events, 1,234,623 push events, 1,973,700 commit messages, 151,428,125 characters
Basic, landing page, menus, Layout
In this version, the website is not yet complete. But you can see the basic outline is now created. The main landing page, the main menus, social media icons, some flat ui elements. It's not mobile friendly yet. We'll work on that later. I could have used some external css library, it would save me a lot of time of course. But I want to make this particular website without relying on any external resources.
fixed stupid ass autoformatter and removed it entirely, fixing all my goddamn problems
website: Fix style in 0.9.2 release notes
This fixes fixes the style so the paragraph is not dedented and the next item is not shown in the same line.
The first issue is "fixed" by just making it one paragraph, as no other alternatives were found that worked correctly in hugo 0.57.0 (didn't explored ugly hacks like manually indent, etc.).
The second issue (item in the wrong line) was reproduced locally with hugo 0.57.0. It didn't happen with other newer hugo versions (tested, several >= 0.62.2), however this way is rendered correcly on new and old hugo versions.
This was tested with hugo 0.57.0 that seems to render locally as the website looks like (black horrible thing rendered when written like this and properly includes the site header logo). Some other changes might be required if the site is using another hugo version.
Fixes: #548
website: Fix style in 0.9.2 release notes
This commit fixes the style so the paragraph is not dedented and the next item is not shown in the same line.
The first issue is "fixed" by just making it one paragraph, as no other alternatives were found that worked correctly in hugo 0.57.0 (didn't explored ugly hacks like manually indent, etc.).
The second issue (item in the wrong line) was reproduced locally with hugo 0.57.0. It didn't happen with other newer hugo versions (tested several >= 0.62.2 versions), however this patch is rendered correcly on new and old hugo versions.
This patch was tested with hugo 0.57.0 that seems to render locally as the website looks like (black horrible thing rendered when written like this and properly includes the site header logo). Some other changes might be required if the site is using another hugo version.
Fixes: #548
website: Fix style in 0.9.2 release notes
This commit fixes the style so the paragraph is not dedented and the next item is not shown in the same line.
The first issue is "fixed" by just making it one paragraph, as no other alternatives were found that worked correctly in hugo 0.57.0 (didn't explored ugly hacks like manually indent, etc.).
The second issue (item in the wrong line) was reproduced locally with hugo 0.57.0. It didn't happen with other newer hugo versions (tested several >= 0.62.2 versions), however this patch is rendered correcly on new and old hugo versions.
This patch was tested with hugo 0.57.0 that seems to render locally as the website looks like (black horrible thing rendered when written like this1 and properly includes the site header logo). Some other changes might be required if the site is using another hugo version.
Fixes: #548
Implement UCS
- Also fixed an issue with the collision detection where it didn't take the segment length into account so any paths that would eventually intersect if they continued were marked invalid
- Changed the graph build to be less idiotic (now finds neighbors of each point in turn instead of doing weird tree-like things)
- Love it when things work
website: Fix style in 0.9.2 release notes
This commit fixes the style so the paragraph is not dedented and the next item is not shown in the same line.
The first issue is "fixed" by just making it one paragraph, as no other alternatives were found that worked correctly in hugo 0.57.0 (didn't explored ugly hacks like manually indent, etc.).
The second issue (item in the wrong line) was reproduced locally with hugo 0.57.0. It didn't happen with other newer hugo versions (tested several >= 0.62.2 versions), however this patch is rendered correcly on new and old hugo versions.
This patch was tested with hugo 0.57.0, as this was the only version I found to render the site locally as similar as possible to the current website. In particular, it renders the site with the horrible black thing rendered when written like this1, and properly includes the site header logo (is not shown with newer hugo versions). However, some other changes might be required if the production site is rendered using another hugo version.
Fixes: #548
Add clean script.
Yesterday I experienced much pain with something getting wonky in either the build or the node_modules, spending time debugging it when it could have been solved with a clean + npm install + rebuild. (=_=)
Cobbduceus: (Baby) C2 Additions (Rhig,Troph) and Changes (Helbital) (#49356)
It's the year of the rat sisters, and now it's time to cut out those pesky C3s in your life!
Why It's Good For The Game
Rhig and Troph are no brainers considering they're on the same level of ease2make as the C2s and have no downside. They will still be good but they have some C2 component now. Kinda minor compared to the others but I'll see how it plays out. Changelog
🆑 balance: Helbital now is more simple to use and is based off not crit/softcrit/hardcrit. You want to be in hardcrit for the best brute healing. tweak: Troph has now been converted into a C2 with tweaks, now named Probital. Same recipe. Downside is stamina damage tweak: Rhig has now been converted into a C2 with tweaks, now named Hercuri. Same Recipe. Downside is it can cool to dangerous levels. /🆑
Debugging
Fix issue with things not rendering it... why would you set a hard limit to rendering in stuff at a close distance. I understanding not rending something off screen... BUT NOT HALF THE MAP HALF THE MAP COULD BE IN VIEW.... god sean why do you copy off of a template without really reading through what every section does... Its bad ehough its a pandemic but the fact you don't read THE CODE YOU COPY ON THE INTERNET
Sorry had to get that out. Future sean I hope you enjoy this little rant of mine. 3/22/2020
fixes #20 (not is an amazing way yet, we would love to support more character sets)
"4:40pm. I am back. Those chores will be finished for a decent while with this. But it is just as well that I had to do them today. My mind is operating on overdrive. I've figured out how to implement pure properly.
I was thinking of the representation of nominal types during peval incorrectly which manifested as myopia.
Here is what I need to do.
inl pure forall (m : * -> *) a. (x : a) : m a = !!!InterfaceGet(`(m a), .pure) x
That's it. Previously I was too obsessed about having an explicit tag in the object, but the typechecker can in fact pass the relevant types on its own. And this will work.
This is absolutely wonderful!
I can do it with this.
4:50pm. You know, just like OO languages have static and member methods, it might be a good idea to make that distinction here. It would be really annoying to treat everything explicitly and have to pass in objects twice.
...Hmmm...no actually maybe I am thinking about this wrong.
For any kind of interface, the thing that is really important is that the first parameter appears in the body somewhere.
interface type interface_name class arg1 arg2 : forall x. class arg1 x -> class arg1 arg2
This is fine, but...
interface type interface_name class arg1 arg2 : arg1 -> arg2
This would not be fine as class is nowhere used. As long as class appears (and is well-typed/fully applied) I have what I need to fetch the interface instance. It does not have to appear as an argument, it can just as well be the return type.
Yeah, this is it.
x # .show
I forgot one issue with this. Interface definitions from different packages might end up colliding. Rather than implement pure explicitly like the above, what I should do is definie it naturally like...
interface type pure m a : a -> m a
This is absolutely perfect.
5:10pm. There is one snag with this...
interface type interface_name class arg1 arg2 : forall x. class arg1 x -> class arg1 arg2
Let me go back to this previous definition.
5:15pm. Hmmm, what if one of the arguments does not show up?
interface type interface_name class arg1 arg2 : forall x. class arg1 x -> class arg1 x
Like the arg2 for example.
For the sake of sanity I've completely gotten rid of the typeclass view and went to the interface view simply because all the parameters would be there in that case.
If you are always applying a member method, then supplying all the type arguments becomes quite easy.
5:20pm. Though the above is written like so, the interface arguments still need to be passed so the right interpretation is this...
interface type interface_name forall class arg1 arg2 x. class arg1 x -> class arg1 x
Just like with function, you would not allow forall arguments that are not in the body, so what I should do here is make such type signatures invalid in interfaces as well.
And that will resolve all the issues that I had with getting the interfaces instances. I won't need to apply them directly to the object.
5:25pm. The differences between interfaces and typeclasses is that...
interface type interface_name class arg1 arg2 : forall x. class arg1 x -> class arg1 x
Here class arg1 arg2 is always some kind of nominal type. With typeclasses, there isn't such a restriction - admittedly my familiarity with them is so low that there might be one. With typeclasses - class might be some class, arg1 might be another unrelated to it and so on. With interfaces, I am guaranteeing that arg1 and arg2 are the type arguments of class.
And this will make everything much more sane. I absolutely have no idea how I would do typeclass search with multiple independent type arguments.
Well, it might be possible, but I'd need to do a linear search for sure. Add functional dependencies to the mix and I would have hell fitting all the language constraints together.
Forget that. There is a far simpler and better solution.
Now...I think I have a Scala book somewhere. I really should take a look at how it does it. I never actually learned it properly when I studied it years ago. When I last did Scala seriously, the fact that I would end up working on a language was the furthest thing from my mind.
Yeah, I have FP in Scala from 3.5 years ago. Let me go for it.
6:15pm. Done with lunch. Let me put some more time into the book and then I will call it a day.
6:50pm. https://docs.scala-lang.org/overviews/scala-book/methods-first-look.html
The Scala docs are much more to the point than that book. I should be able to figure out soon enough how it does the monad magic.
7:10pm.
trait Monad[F[_]] extends Functor[F] {
def unit[A](a: => A): F[A]
def flatMap[A,B](ma: F[A])(f: A => F[B]): F[B]
def map[A,B](ma: F[A])(f: A => B): F[B] =
flatMap(ma)(a => unit(f(a)))
def map2[A,B,C](ma: F[A], mb: F[B])(f: (A, B) => C): F[C] =
flatMap(ma)(a => map(mb)(b => f(a, b)))
Since there is no way to use this directly in the way I imagine, it has to be using some kind of implicit. Most likely that is the case. Forget Scala. What I will be doing will be my own invention after all.
Let me close for the day here.
I am actually quite happy how today went. Today I pretty much resolved all the design issues around typeclasses and transformed them into something sensible.
Typeclasses were actually one of the part of the language I was actually anxious of as I did not have a clear cut view of how they should be done or how they should integrate with the rest of the language features. With the thinking I've done today, the fog has completely cleared to me and all I have to do is implement it.
7:15pm. There is still a little bit more left of the design work, but with this the main obstacle will really be editor support. Once I clear that hurdle the typechecker will be laid bare before me. Once I finish that I will complete the language and try what I did in 2018 again, except this time much better.
Tomorrow, I will try and keep today's flame going as I study that VS Code project. I am going to follow the lead that I have to its conclusion. I truly believe that user experience (especially my own) should take precedence over everything. This time I will spare no effort in order to put that into proper order.
If needed I will put as much effort into this as I have into partial evaluation. I will get this done to my satisfaction even if I have to put an entire year of effort into it. Rewriting that big library is nothing."
"9:30am. I am up. I did not get good enough sleep. It was not as bad as two days ago, but still it was not optimal.
During the night I had a lot of inspiration. Remember row polymorphism?
I've been trying to come up with rules to make it viable. The exclusive union rules are incoherent, and while I think that normal union rules could work I am not comfortable with leaving record removal off the table. Also I am uncomfortable with passing unused arguments through join points, this would be the case if I added some kind of row polymorphism to the language. Spiral's records aren't heap allocated, and there is a very real runtime expense with passing unused stuff through join points.
But no matter what, for the language to be complete, I really need to have good capability to manipulate records. And I've figured it out.
9:35am. One of the more mindblowing features in F# are its casting capabilities. It is possible to write x :> _ (upcast) and x :?> _ (downcast with a check at runtime). The type arguments in wildcards will get automatically inferred by the type inference algorithm.
So what if I could write something like this in Spiral...
x :> {a : _; b : _}
What this would do is remove all the fields from the record, but a and b.
So...
{a: 1; b: 2} :> {a : i32; b : i32} // returns {a: 1; b: 2}
{a: 1; b: 2; c: 3} :> {a : i32; b : i32} // returns {a: 1; b: 2}
{a: 1; b: 2; c: 3; d: 4} :> {a : i32; b : i32} // returns {a: 1; b: 2}
{a: 1} :> {a : i32; b : i32} // type error - missing b
{a: 1; b: ""; c: 3} :> {a : i32; b : i32} // type error - b has type string while it should be i32
9:40am. I am going to put this into the language, including constraints so that this could be done generically.
Then suppose I have a function like...
let f ({a b} : {a : i32; b : i32}) = {c=a+b}
In the top-down segments to apply this I would need a record of exactly {a b} with no extra fields. In fact, if no type annotation is given I intend to have the first pattern match determine the full shape, meaning...
let f {a b} = {c=a+b : i32}
...would get inferred to the same type. This is far better than F# which requires annotations everywhere.
But because it requires exact fields that gives me a problem.
Suppose I have a record like this...
let r = {q=""; w='n'; e=0f32; a=1; b=2}
To apply f I would have to clean it up by hand.
f {a=r.a; b=r.b}
This is the only option in langs like F#. Alternatively, with record downcasting I could do...
f (r :> _)
In order to avoid having to write r :> _ constantly, I will introduce the # unary operator that does the same thing.
f #r
This is quite nice isn't it?
Even though this is not row polymorphism, the code is quite generic. If I went back and added some extra fields like...
let r = {z="qwe"; x="asd"; q=""; w='n'; e=0f32; a=1; b=2}
...the code elsewhere would require no adjustment.
In F#, I would have to go around adjusting type signatures.
There is even more to this.
let f {a b} = {c=a+b : i32}
The reason why I want row polymorphism is to allow updating and removing record fields dynamically at compile time. Purescript was a disappointment in that regard.
I want complete flexibility when it comes to records. I want to be able to dynamically chain functions that add fields to a record.
let r = {z="qwe"; x="asd"; q=""; w='n'; e=0f32; a=1; b=2}
let f {a b} = {c=a+b : i32}
let {c} = f #r
{r with c}
If multiple fields need to be updated, rather than just c...
let r = {z="qwe"; x="asd"; q=""; w='n'; e=0f32; a=1; b=2}
let f {a b} = {c=a+b : i32; d=a-b : i32; e=a*b : i32}
let {c d e} = f #r
{r with c d e}
...things would get tedious proportionally to the number of fields that need to be updated.
What I would like is to write the record union.
a \/ b
That is - add all the fields in record b to record a. This would allow me to rewrite...
let {c d e} = f #r
{r with c d e}
...as...
r \/ f #r
10:05am. It is possible to go even further. Note that abstractly f is a function a -> b where a and b are both records. When that is the case I should be able to pipe it.
let (|>#) r f = r \/ f #r
let r = {z="qwe"; x="asd"; q=""; w='n'; e=0f32; a=1; b=2}
let f {a b} = {c=a+b : i32; d=a-b : i32; e=a*b : i32}
let f {q w} = {qq=q,q; ww=w,w}
r
|># f // adds c, d, e
|># g // adds qq, ww
Pretty neat. I often thinking of the GVGAI rewrite from 2016, and how helpful it would have been to be able to dynamically add record fields. In bottom-up Spiral this is easy, but in top-down this would require some more work.
10:15am. As I mentioned in order to support this kind of programming generically, I am going to add two constraints...
let (|>#) r f = // forall a b c d. a :> b, a / c ~> d => a -> (b -> c) -> d r / f #r
At the type level a :> b is the record downcast constraint, and a \/ c is the record union constraint. ~> is the generic dependent constraint operator - meaning once the stuff on the left is evaled, unify it with the right.
10:20am. The language of constraints is really the language of miracles.
With this, I am all set as far as records are concerned.
I've been thinking...
forall a b c d [a :> b, a \/ c ~> d]. a -> (b -> c) -> d
I am going to move constraints into the forall. That will clean them up a little. I am not comfortable with Haskell's syntax here. It looks nice, but => would require lookahead which I do not like. So some kind of non-lookahead syntax would be more appropriate. Since I might end up using [] in patterns, it would be better to just move it to the left side into the foralls. That is where constraints should have been from the start anyway.
In Haskell, the constraints are always typeclass constraints and are actual arguments passed at runtime, but in Spiral they are an entirely different thing. They are wholly resolved at compile time.
10:25am. I've also been thinking about optimization for interfaces. For quick lookup, all the nominal types I am going to put into one big array and then do a binary search to find the interface being looked up.
10:35am. I am actually pretty excited about this. Once I put in all the ideas that I have, Spiral is going to be a truly first rate language.
I've even been thinking what will come beyond v0.2.
I think that would be dynamic evaluation, similar to VM languages like C# and Java. The reason for that would be scalability. Having to peval everything on every would be very expensive for large programs.
10:40am. But I'll leave that sort of thing for the agents to deal with.
The way things are going, when v0.2 comes out, it will be pretty much perfect language for machine learning. And not the old and busted deep learning, but the thing that will come after it.
10:55am. I am still thinking about it. Eventually this surge will leave me, and I'll be able to unwind.
I've been expending a lot of brainpower over the past few days on these design issues.
11am. I know need to stop and get back to editor support, but these ideas are just so good that I cannot help but to fall in love with them. I want to indulge myself.
I am really enjoying myself here even though it is strenuous.
11:05am. I won't set any goal for today. I do not want to force myself to study editor support when these ideas that are coming to me now will be the backbone of the new Spiral.
I should just do what I want for today.
Usually I would have started the day with my morning reading, but let do that now."
TV, Halftime Shows, and the Big Game
Whether or not you like football, the Super Bowl is a spectacle. There's drama in the form of blowouts, comebacks, and controversy in the games themselves. There are the ridiculously expensive ads, some hilarious, others gut-wrenching, thought-provoking, and weird. The half-time shows with the biggest musicians in the world, sometimes riding giant mechanical tigers or leaping from the roof of the stadium. And in this project, you will find out how some of the elements of this show interact with each other. You will answer questions like:
What are the most extreme game outcomes? How does the game affect television viewership? How have viewership, TV ratings, and ad cost evolved over time? Who are the most prolific musicians in terms of halftime show performances? This project gives you an opportunity to apply the skills from Intermediate Python for Data Science.
The dataset used in this project was scraped and polished from Wikipedia. It is made up of three CSV files, one with game data, one with TV data, and one with halftime musician data for all 52 Super Bowls through 2018.
fix iommu
fuck you qualcomm, xiaomi Why does this work? Because LPAE64 pagetable conversion fails(like with arm-smmu). Force LPAE32 pagetable mode. Might use arm-smmu with LPAE32 when i can maibe idk lol.
Signed-off-by: rupansh [email protected]
HACK: pretend like klog is glog
After a bout of desparation, this is the solution that is needed. Glog doesn't expose the endpoints that klog does, including overriding the flags However, one needs to override the flags to be able to make it so logs aren't written to /tmp All of the k8s code still expects glog to be there, so we can't just use klog in cri-o and be okay.
instead, what we need to do is fork klog, and manually change the package name to glog. This is horrible, gross, and hacky, but the nature of software deprecation leaves us no other choice.
Signed-off-by: Peter Hunt [email protected]
Wrap wx.html2.WebView as WebViewer
Nicely hides the html2 import ugliness and can abstract away some annoyances (e.g. disabling the forward / back buttons, turning file paths into 'file:' URLs, etc.).
Had to do the reload button using a really ugly hack. Also, until we're on wx4, everything but the doc browser will have a single annoying 'about:blank' entry in its history (the doc browser takes long enough to load that it doesn't happen there). On wx4, we can clean those entries out of the history manually.
Note: I switched StartURL for webbrowser.open - didn't want gui to import windows.py, that sounded like a really weird dependency.
importer: Quote filenames with spaces for tmpfiles.d
This way we handle filenames with spaces in /var in general,
like /var/app/foo bar, but also the special /opt/foo bar
translation bits.
I saw this bug and thought "oh that'd be easy". But hoo boy
did it take me down a rat's nest. The first thing was verifying
that systemd-tmpfiles supports any kind of quotation/escaping; it does.
The next thing was figuring out exactly what the syntax for that
is and how it works, as it's obviously not widely used.
Writing tests for this ended up being a painful exercise because
of the multiple levels of shell script, e.g. our build_rpm shell
script ends up being inlined into RPM specs, which then interprets
again...and not to mention the usual annoying issues with ssh
eating quotes.
Anyways, all that and: Closes: coreos/rpm-ostree#2029
"11:10am. It seems yesterday's commit push did not go through. I've been having connection issues lately for some reason. Probably because everyone being at home due to Corona is causing the network to overload.
11:55am. https://kavon.farvard.in/papers/pldi20-stacks.pdf From folklore to fact: Comparing implementations of stacks and continuations
I am reading this paper at the moment. The issue with what to do with stacks I first ran into the old ML papers by Appel.
12:55pm. Done with breakfast. Let me clack for longer today.
1:55pm. Done with chores. It was freezing outside today. Glad I am back in here.
2pm. https://varkor.github.io/blog/2019/03/28/idiomatic-monads-in-rust.html "Monads (and, more generally, constructs known as “higher kinded types”) are a tool for high-level abstraction in programming languages1. Historically, there has been a lot of debate inside (and outside) the Rust community about whether monads would be a useful abstraction to have in the language. I’m not concerned with that here. You see, there’s a problem with talking about whether monads would be useful or not, and it’s this: there are a large number of design challenges to overcome to have any hope of implementing them at all — to the best of my knowledge, there currently exists no realistic (that is, practical) design for monads in Rust. In fact, there are so many obstacles that some people express doubt that it’s even possible."
I thought that Rust had monads, that is why I decided to Google it. But I forgot that it does not have HKTs. Well, it is not like I am familiar with it at all.
2:15pm. I am still thinking about interfaces - in particular my thoughts are veering in the direction of how the whole would look if I had to pass type arguments at runtime, but I think at this point I am mostly done with the design. It is good to skim things until I am sure, but I think I should be ready to resume properly tomorrow.
2:30pm. https://www.youtube.com/watch?v=i-ArbE0bEQQ Frank Klepacki & The Tiberian Sons LIVE: OFFICIAL Multi-cam Full Show
Youtube recommended me something good. The intro to this video made me realize that I forgot how cool the installation for the original C&C was. Also I had no idea Klepacki actually had a band.
2:35pm. Ok, first that issue I opened for reason-vscode. I can assume I won't get an answer. Half the open issues never got a response by the look of it.
I'll be on my own with this plugin. There is no helping it, I am just going to be satisfied with highlighting and getting a general overview of it.
Either way, it does not seem I will be getting too much out of my plugin studies.
2:40pm. Instead what I have to do is follow that lead I had with the VS Code project. My intuition is finally starting to work with that thing, so hopefully that should lead me to the solution.
Now since this fever of the mind starting to leave me, how about I do some studying?
I feel like the Reason plugin right now. Admittedly, the VS Code project would be more constructive, but I want to do my passess on the reason project rather than have it linger on the back of my mind.
2:50pm.
"reason_language_server.build_system_override_by_root": {}
I do not know what to put into here to override the startup for the project. Nevermind.
3pm.
let set0 h key value ~eq ~hash =
let h_buckets = C.buckets h in
let buckets_len = A.length h_buckets in
let i = (hash key) land (buckets_len - 1) in
let l = A.getUnsafe h_buckets i in
(match C.toOpt l with
| None ->
(A.setUnsafe h_buckets i
(C.return (N.bucket ~key ~value ~next:C.emptyOpt));
C.sizeSet h ((C.size h) + 1))
| Some bucket ->
if replaceInBucket ~eq key value bucket
then
(A.setUnsafe h_buckets i (C.return (N.bucket ~key ~value ~next:l));
C.sizeSet h ((C.size h) + 1)));
if (C.size h) > (buckets_len lsl 1) then resize ~hash h
Right now I am looking at the standard library inside the project, rather than the plugin stuff proper.
I really would need editor support for this kind of thing.
Admittedly, this kind of code is much more my thing, but I am just so much limited without editor feedback.
let mapper =
{
Ast_mapper.default_mapper with
expr= fun self e ->
let loc = e.pexp_loc in
begin match e.pexp_desc with
| Pexp_apply({pexp_desc=Pexp_ident {txt = Lident "|."; _}; _}, [Nolabel, obj_arg; Nolabel, fn]) ->
let new_obj_arg = self.expr self obj_arg in
begin match fn with
| {pexp_desc = Pexp_apply (fn, args); pexp_loc; _} ->
let fn = self.expr self fn in
let args = List.map (fun (lab,exp) -> lab, self.expr self exp ) args in
{ Parsetree.pexp_desc = Pexp_apply(fn, (Nolabel, new_obj_arg) :: args);
pexp_attributes = [];
pexp_loc = pexp_loc}
| {pexp_desc = Pexp_construct (lident, None); pexp_loc; _} ->
{ Parsetree.pexp_desc = Pexp_construct(lident, (Some new_obj_arg));
pexp_attributes = [];
pexp_loc = pexp_loc}
| _ -> Exp.apply ~loc (self.expr self fn) [Nolabel, new_obj_arg]
end
| _ -> Ast_mapper.default_mapper.expr self e
end
}
How does this PPX stuff work in Ocaml?
3:50pm. The reason why I am studying the Reason project is because I do not really think I am going to get much out of it, but need a basic grasp, if nothing but to have the courage to give up on it. For the VS Code one I need my full focus as it will be my main line.
3:55pm.
let%try file = getModule(moduleName) |> RResult.orError("Cannot get module " ++ moduleName);
What are these let%try statements?
Holy shit is the connection crap today. Let me see if fiddling with the router does anything.
4:05pm. Finally.
https://github.com/reasonml-labs/bs-let
I those weird lets are really monadic extensions.
https://github.com/jaredly/let-anything
Oh, jaredly was the one who coined these.
https://github.com/reasonml-labs/bs-let "A Note about Windows Currently this project only precomiles binaries for linux and OS X according to the needs of existing maintainers. If you're a Windows user and would like to use this PPX, We'd love a pull-request that moves the project from Travis to Azure Pipelines and builds for all three platforms."
Hmmm...does this have anything to do with the project not being able to load? It does do some PPX stuff.
4:25pm. My focus is low. I need to get this thing going.
4:40pm. editor_extensions has the actual Vs Code client parts. This is something I should study.
5:15pm. Done with lunch. Let me resume this for another hour.
5:20pm.
public attribute(): schema.Rule {
return {
begin: seq(
capture(Token.LEFT_SQUARE_BRACKET),
many(set(Class.space)),
capture(this.ops(`${Token.COMMERCIAL_AT}{1,3}`)),
),
end: Token.RIGHT_SQUARE_BRACKET,
beginCaptures: {
1: { name: Scope.TERM_CONSTRUCTOR() },
2: { name: Scope.STYLE_OPERATOR() },
},
endCaptures: {
0: { name: Scope.TERM_CONSTRUCTOR() },
},
patterns: [include(this.attributePayload)],
};
}
I am looking at the TS files and damn is this shitty DSL convoluted.
5:20pm. Just this shitty syntax highlighting is 2x longer than Spiral's entire parser.
Well, just highlighting the keywords should not be too difficult to start with.
6:10pm. Ok, I am done with the Reason plugin. I can only do a rough skim now. I am really getting only 20% of that I could had I had access to the editor, so I won't bother too much. I had complained that the VS Code project reimplements stuff that should be in the standard library. This thing it seems just pastes it wholesale.
For from being simple, the Reason plugin is mind bogglingly complex.
6:15pm. All this complexity is a good lesson to me. When it comes to language work, it seems all the good programmers do the stuff under the hood, the type system and the syntax, and leave the editor support to the janitor working there. This is what happens when a language is made with editor support as only an afterthought.
I am going to rate this 3/10, but it is an uncertain score. If I get an answer from the author and get editor support to work with this project I'll re-evaluate it then.
6:20pm. I'll close for the day here as my mind is so strained that it feels feverish.
Tomorrow, I am going to focus on the points where the VS Code language project interacts with the editor itself. That should give me a lot of insight.
Out of the past 6 weeks, I've pretty much wasted 4. Looking at other people's code is such a waste of time.
In the next week I am going to try and wrap up my studies, so I can actually begin work on the server. I want a starting template done before I start work on the typechecker.
If possible, rather than Reason, I am going to check out Fable and see how it does. Since I am doing everything else in F#, it makes sense to do the same with the client as well. I certainly do not want to be doing it in TS. And I won't be doing it in a pure language like Purescript. That only leaves Reason and Fable.
If the reason-vscode was a bastion of clarity and worked properly (in the editor support sense,) I would have picked Reason for the Spiral language client, but now I am not sure that I want this anymore."
BAIN conflict refactoring, some fixups
Mopy/bash/bosh/bain.py: bain: Refactor getConflictReport, split into methods
Useful for #450, we now no longer have to crawl our way through the string but can directly use the in-memory conflict objects. An exemplary lesson in why one should never only expose a string, otherwise its format becomes API.
Threw in docstrings everywhere as well, otherwise this might actually be a negative line diff.
Mopy/bash/basher/installer_links.py: Drop unneeded remaps assignments
resetAllEspmNames() already does what we want. No need for this weird, encapsulation-breaking logic.
Mopy/bash/bosh/converter.py: Hacky fix for BCFs crashing with subarchives
When you have e.g. a 7z file inside a 7z file, even if the file gets removed in the BAINification, the BCF creation process would crash. This is a very hacky temp fix, the real fix is probably to pass a valid crc_installer to that method.
Mopy/bash/bosh/cosaves.py: cosaves: Fix crash when reading ARVR
God I'm stupid, forgot to move the self.elements initialization before the self.key_type initialization which uses self.elements.
Under #437, #450.
Add fomod installer support
Option types are not validated - contradicting group and option types should be undefined behaviour. However, to simplify, option type always wins the conflict and we deliver a warning if needed.
As an example, in a SelectAll group a NotUsable option would not be selected.
Remove fomod metadata handling
Rework fomod installer backend
Changed:
- User's choices are now "saved" when going to previous pages
- Folders to install are now properly merged based on priority
- Omitted destination attributes in file/folder tags are now properly handled.
TODO:
- Update tests in test_bash repo
- Add some inline documentation
This must go into the final commit message:
Ignored tags:
- moduleImage
- fommDependency
Ignored attributes:
- position, colour - [moduleName]
- alwaysInstall, installIfUsable - [file, folder]
Note:
Rework exe-based game detection logic FFF fomods
@@ -64,3 +64,3 @@ def init(self, parent_window, installer, page_size, pos): data_path = bass.dirs["mods"]
-
ver = env.get_file_version(bass.dirs["app"].join(bush.game.exe).s)
-
ver = env.get_file_version(bass.dirs["app"].join(bush.game.launch_exe).s) game_ver = u".".join([unicode(i) for i in ver])
Some wx cleanup in gui fomods
Cache images it does speedup loading them
(although that's probably due to my using balt.Image)
FFF couple typos
FileInfo(object): -> _FomodFileInfo(object): FFF WIP
Infernio: Updated for 'Rework game version calculation'
SSS Improve FOMOD installer link name
Should be FOMOD or FOMod, not Fomod. Also added three dots, since that link opens an interactive dialog.
SSS to be squashed into the final FOMOD commit
_text = _(u'FOMOD Installer...') class variable SSS
No need to override init
Remove some leftover debug prints
Replace PageInfo with OrderedDict
Std lib is better. Port of GandaG/pyfomod@547494309
Add some docs to the fomod backend
Update for recent merges
FFF A bunch of FOMOD hacks
I hadn't actually realised just how broken the wizard/FOMOD interaction is up until I just now got a really cryptic error message from a wizard. Just some examples:
- SelectSubPackage didn't work properly when the package had an fomod, because fomods do not populate Installer.espmMap, which wizards use to detect what subpackages and plugins are available.
- The same goes for SelectPlugin, all deselect variants, SelectAll, etc. Probably for loops with SubPackages as well.
- I screwed up my earlier fix. While it no longer crashed, it made wizards (with or without FOMODs) unable to select the last subpackage. But see above, wizards with FOMODs had a hard time with that anyways ;)
- The result of applying a wizard and an FOMOD is well-defined (the FOMOD always wins because it short-circuits refreshDataSizeCrc), but it looked really confusing in the GUI. Still possible to create manually by checking both the fomod subpackage and other subpackages, but wizards and FOMODs will now uncheck the other so WB at least no longer produces this weird state.
Threw in some tiny refactorings in belt (yay, two bolt.cmp_'s gone!)
SSS Rework FOMOD GUI
Depends on 190-de-wx-pt1, rewrites most of the GUI to use the wrappers instead. Drops a whole bunch of wx usages, which is nice. RadioButton needs wrapping, see all the ugly hacks at the bottom of gui_fomod. Also, the design that uses dict of wx objects to store group objects has to go, it's fundamentally hacky and very fragile - e.g. imagine if the wx guys decided to add slots to their objects.
Also contains a bunch of fixes and misc improvements, e.g. user-facing strings have been made translatable, some bugs that were carried over from belt have been fixed, and the 'Back' button no longer works on the first page.
Note the glaring TODOs - this is a straight up port of the original GUI, but we currently don't have a way to change fonts, which the original GUI relied on to differentiate its components. I added some HBoxedLayouts as an alternative, which works fine for the main FOMOD dialog and may even be an improvement in terms of visual clarity, but doesn't help at all with the results screen, which is now an unreadable mess.
Infernio: Updated for wrapped WizardDialog, gave fomods their own stored size, updated for default_* -> item_*.
Utumno: fomod_gui: comments to docstrings
Co-authored-by: MrD [email protected]
FFF fix FOMOD fileDependency evaluation
Wasn't taking ghosts into account and, more importantly, was passing strings to the LO API, which expects paths. As a result, every file was either missing or inactive.
Also went ahead and swapped all usages of bolt.Path for bolt.GPath.
FFF fix FOMOD PNGs
I could swear I commited this to nightly long ago, along with the main pngcrush work, but it seems to have gotten lost somewhere along the way. So here's a better version, that refactors the two nearly identical methods.
Update
- Crab Helmet now only boosts stats by 10.
- Removed all the ashes you get from killing vendors (i.e. Karla's Ashes).
- Way of White now an Offerings shop.
- Vinheim Scholars now get Crystal Fragments as their covenant material.
- Chaos Servants now get Fire Seeds as their covenant material.
- Pilgrims of Dark now gets Abyssal Fragments as their covenant material.
- Way of White now gets Holy Fragments as their covenant material.
- Greirat no longer has the pillage quest. Instead his inventory unlocks after killing the Curse-rotted Greatwood, and then Pontiff Sulyvahn.
- Orbeck now gets Pestilent Mist after you kill Oceiros.
- Orbeck will no longer leave when you buy all his spells.
- Irina now progresses towards the Light ending of her quest if you form a covenant with her (Way of White). If not, she gets the Dark ending.
- Reduced the number of added enemies in base playthrough, moved some into NG+ only.
- Fixed Pyromancer's Parting Flame not ascending correctly.
working on navigation instead
can now navigate
navigation is still nasty, but it looks a lot better
have the background going and the xwing is the ebon hawk now
mainly working on constant data, about to work on procedurally generating the platform stuff
some annoying things that I can't figure out why it's not working
can move now
the lines can be drawn
have a good line that start, going to do procedural stuff again
terrain generation works
safe zones are now generateable but don't have lines connecting to and from it, that'll be tomorrows problem
safezone is somewhat done, need to have safezones on left side and rightside
a whole lot nicer. the safezones are split into both sides now
lander updates
added some node real quick
more linting stuff added
even more linting
thrust y works now
still don't know why it's move in x AND y, but you know, idk
accidentally didn't add this rpeviously, just a removal of a console.log statement
bit of shiftyness, honestly the timing is what sucks here
I don't even know
can move, constants need to change though
stuff
the lander can rotate and the fuel drops
lots of coolors
collision detection is a thing now
the intersection is nicer and will say if you win by satsifying conditions AND putting you in the safe zone
can have custom controls
customizing controls is possible now
can have a single sz now
multiple levels exist now
need countdown and particles and sound
the countdown can be done'
countdown works on win too
angle is now seen in decimal
high scores are tracked
can now essentially pause a game
lots of thrust sounds
one could say this is 'pleasing' sounds
the controls persist
eslinting done
working on particles, but it's late as h*cc
particles draw at the center of the eh
real close to thrust working
burst system works
thrust sound stops upon lack of fuel
particles kind of sort of work, just not in the correct direction
the thrust is underneath the ship, but I still need to get the sin/cos working