2,570,111 events, 1,356,480 push events, 2,104,999 commit messages, 153,544,361 characters
Update application_controller.rb
stupid heckin Google spreadsheets being annoying as shit
Better amp control
Introduce a class to encapsulate comms with the amp. Prefer 12V trigger for power on/off vs IR power toggle.
The yamaha 12V trigger is a fucking pain in the ass. It requires the source to be set to main direct for both triggering off and it is really finicky about how quickly trigger on can be issued after trigger off. It will ignore trigger on if it comes in, based on my experiments, less than ~700ms after the trigger off.
"8:35am. I am groggy as hell, but finally I am up early for once. Let me do my usual morning reading and I'll start once I dust off the cobwebs.
9am. Ok, I am recovering slowly. Let me read Hellrage and then I'll start.
9:15am. Let me start.
Time to finish that chapter.
9:35am. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/elm/project-structure
I just skimmed the previous chapter. I do not really have to understand how Elmish works in depth right now or how to use it. What I am really interested in is in fact this. How do you get Fable to compiler switch between compiling to the browser and Node. If I can figure that out I'll also know to how to target VS Code extensions.
Let me stop here for a bit though first. I need a short break.
10:15am.
let delayedDispatch = async {
let! msg = operation
dispatch msg
}
Async.StartImmediate delayedDispatch
Ok, let me stop for a moment here. Does this really launch tasks asynchronously. What the hell? I need to figure it out.
open System
async {
printfn "Start 1."
do Threading.Thread.Sleep(1000)
printfn "Done 1."
} |> Async.Start
async {
printfn "Start 2."
do Threading.Thread.Sleep(1000)
printfn "Done 2."
} |> Async.Start
The way to run an async operation asynchronously is Async.Start. Async.StartImmediate does it synchronously as I well know. Why does the JS code get async behavior in that case? Bizarre.
...Maybe Async.sleep is run asynchronously even when the rest is sync?
async {
printfn "Start 1."
do! Async.Sleep(1000)
printfn "Done 1."
} |> Async.StartImmediate
async {
printfn "Start 2."
do! Async.Sleep(1000)
printfn "Done 2."
} |> Async.StartImmediate
Start 1.
Start 2.
val it : unit = ()
> Done 1.
Done 2.
Motherfucker. That really was it. You got me good.
It just goes to show that I do not really understand Async that well. Not as well as I thought I did anyway. I've been thinking of getting that .NET concurrency book, but I'll leave that for some other time.
I am happy at only being able to use it well right now.
10:30am.
type Msg =
// messages for Operation 1 -> might fail
| StartOperationOne
| FinishOperationOneSuccessfully of ResultOfOne
| FinishOperationOneWithError of exn
This is the same form as observables.
10:40am. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/commands/recursive-updates
I am really skimming through this. I'll be aiming to go through the entire part 3 before breakfast. I do not want to spend too much time on this. A single day should be enough to get through the entire book at this rate.
11:05am. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/commands/xhr-elmish
Enough, let me just skip to the next chapter. I am not even reading things at this point.
11:10am. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/dev-flow/
Let me just move to the last chapter. The rest is something I would be interested in if I were doing webdev with Fable, but I just want to do compiler plugins.
Let me go through this chapter and then I'll look into setting up a project.
11:20am. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/dev-flow/webpack-mode
I really like how ReasonML will clean up the code and produce readable JS. So far Fable was not good in that regard.
11:30am. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/dev-flow/compiler-directives
The tedium of this is killing me. Let me stop here so I can have breakfast. I'll deal with this properly today. Tonight I slept well, but I got up too early and now I am yawning here."
player: do not fall back to a default track with explicit selections
Consider e.g. --aid=2 with a file that has only 1 track. Then it would fall back to selecting track 1. Stop doing this. If no matching track is found, this will not select any track now.
Note that the fingerprint stuff (track_layout_hash in the source) prevents softens the impact of this change. Without the fingerprint, playing a dual-audio file with the second track selected, and then a single-audio file, would play the second file without audio. But the fingerprint resets it due to differences in the track list.
Try to exhaustively document this and tricky interactions between the other features. What a damn mess, I think it's simply cursed. Of course it's still my fault.
See: #7608
FS20G15-41-43: Fully finished (IT WAS A FUCKING SPELLING ERROR, I FUCKING HATE MY LIFE)
Implicit constructors. Have I gone too far?!
protected readonly Mutable _turns = 30;
It has a certain purity to it.
But maybe all these implicit operators are just too sketchy. They cut a bit of code but maybe make things harder to understand later? I could see just using a Value as an int in a bunch of places because it makes it easy, but then you use it in a context that expects object, and the magical unwrap doesn't happen and all hell breaks loose. Thoughts?
"12:35pm. Let me do the chores. I do not know why I got up earlier today. In the end I have more time to just slack.
I certainly do not feel like reading the book, what I really want to do is start work on the plugins.
2:10pm. I am back. Yeah, there are any number of excuses as to why I do not feel like doing this, and yet I must. If I cannot spend the next 4 hours usefully, I'll spend them uselessly.
2:45pm. I cooled down a little. Let me start for real.
3:05pm. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/dev-flow/configuration-variables
I think that only now is my focus starting to go up. Yeah, this is good. It might be the case that I will learn something today after all. Today proves it though...there was absolutely no need for me to get up earlier. That sort of thing only works when you have a goal firmly in mind and a backlog of work.
When you need to creatively explore, hurrying will only work against you.
3:10pm. https://zaid-ajaj.github.io/the-elmish-book/#/chapters/dev-flow/hot-module-replacement
Let me give this a shot. This seems pretty cool.
...Actually, I do not feel like it. Let me leave it for later.
I'll pick it up when I need to. What I really need is to figure out how different browser envs work.
Let me finish the book in the next hour or so and then I'll ask on SO about how to configure that VS Code starter project.
http://kcieslak.io/Creating-VS-Code-plugins-with-F-and-Fable https://blog.nojaf.com/2018/12/17/writing-a-vscode-extension-with-fable-2-1/
Oh there is a bunch on this out there. I am in luck.
3:20pm.
"This module has one function: Image.load which is basically an alias for importDefault function coming from the Fable.Core.JsInterop namespace. The function importDefault is the equivalent of require in Javascript and depending on what you are importing, it can return different things, that is why I made a specialized module dedicated to loading images. This is also the reason why the function returns string: it is the modified path of the imported image."
That importDefault will no doubt play a part in doing VS Code plugins.
3:30pm. I started reading /r/programming posts. Focus me, focus.
3:35pm. "Other side-effectful modules can be those that add missing APIs into the page, also known as *polyfilling."
So that is what polyfilling means.
https://zaid-ajaj.github.io/the-elmish-book/#/chapters/dev-flow/introducing-femto
I'll have to keep this chapter in mind.
3:40pm. Done with the book. It had some interesting stuff, but it is besides the point for me. Once again...
http://kcieslak.io/Creating-VS-Code-plugins-with-F-and-Fable https://blog.nojaf.com/2018/12/17/writing-a-vscode-extension-with-fable-2-1/
Let me take a look at the two links starting with the last one.
This is what I should be doing. My mind is 100% focused on just getting through the hello world hurdle. Once I get through that, I can start figuring out the rest and hopefully doing some real work.
3:55pm.
import { toConsole, printf } from "./fable-library.2.5.1/String";
export function hello(name) {
const clo1 = toConsole(printf("Hello %s"));
clo1(name);
}
Ah, it is possible to get Fable to output readable code if you do not use webpack.
4pm.
module AdventExtension.Extension
let activate _ =
printfn "Fable extension is activated!"
This is great. Things are going swimmingly. Let me take a short break here.
4:20pm. Let me resume. First let figure out how to get watch to work, after that come the VS Code APIs. After I have I will have everything I need to make my own plugin.
4:35pm.
"activationEvents": [
"*"
],
I get the cannot use the import statement outside of a module error.
4:30pm. dotnet tool install —tool-path “.paket” Paket —add-source https://api.nuget.org/v3/index.json
The installation instruction for Paket here are not working for me at all.
Agh, I did not see the PS> prefix. Let me try this in Powershell.
4:35pm.
PS E:\Webdev\Fable\fable-markdown-extension> dotnet tool install --tool-path ".paket" Paket --add-source https://api.nuget.org/v3/index.json
Unrecognized command or argument '.paket'
Unrecognized command or argument 'Paket'
Unrecognized command or argument '--add-source'
Unrecognized command or argument 'https://api.nuget.org/v3/index.json'
Usage: dotnet tool install [options] <PACKAGE_ID>
Arguments:
<PACKAGE_ID> The NuGet Package Id of the tool to install.
Options:
-g, --global Install the tool for the current user.
--local Install the tool and add to the local tool manifest (default).
--tool-path <PATH> The directory where the tool will be installed. The directory will be created if it does not exist.
--version <VERSION> The version of the tool package to install.
--configfile <FILE> The NuGet configuration file to use.
--tool-manifest <PATH> Path to the manifest file.
--add-source <SOURCE> Add an additional NuGet package source to use during installation.
--framework <FRAMEWORK> The target framework to install the tool for.
--disable-parallel Prevent restoring multiple projects in parallel.
--ignore-failed-sources Treat package source failures as warnings.
--no-cache Do not cache packages and http requests.
--interactive Allows the command to stop and wait for user input or action (for
example to complete authentication).
-h, --help Show command line help.
-v, --verbosity <LEVEL> Set the MSBuild verbosity level. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic].
4:40pm. dotnet tool install --tool-path 'paket'
Unrecognized command or argument 'paket'
I have no idea. No matter what I do, I can't seem to pass the --tool-path option properly.
What the hell. Let me take a look at the Paket site.
https://fsprojects.github.io/Paket/get-started.html
Let me try following the stuff here. If it creates the .paket dir then I will know it works.
4:45pm. Well, it added something similar. There really is a shitload of stuff to configure by hand here isn't there?
https://fsprojects.github.io/Paket/learn-how-to-use-paket.html#Updating-packages
If you want to check if your dependencies have updates you can run the paket outdated command:
`dotnet paket outdated`
Or if you're not using .NET Core:
`.paket/paket.exe outdated`
Ah, I see.
5pm. Why is Ionide so unresponsive when it comes to moving files?
E:/Webdev/Fable/fable-markdown-extension/paket-files/nojaf/fable-jest/fable/Exports.fs(26,54): (26,61) error FSHARP: The type 'Promise' is not defined in 'Fable.Import.JS'. (code 39)
E:/Webdev/Fable/fable-markdown-extension/paket-files/nojaf/fable-jest/fable/Exports.fs(35,56): (35,63) error FSHARP: The type 'Promise' is not defined in 'Fable.Import.JS'. (code 39)
I am getting this retarded errors when trying to compile.
[<Global("it")>]
let itAsync(msg: string) (f: unit -> Fable.Import.JS.Promise<'T>):unit = jsNative
[<Global("test")>]
let testAsync(msg: string) (f: unit -> Fable.Import.JS.Promise<'T>):unit = jsNative
This is what you get when you link to custom Github files.
5:05pm. This tutorial is rather strenuous. It is really annoying when I get bombarded will a lot of new tools all at once, but I think I get most of this.
Let me just read the second half of the tutorial without necessarily following along. At least I now know enough to set up the hello world project.
5:10pm.
# nuget Fable.Import.Jest // Use when ready for Fable2
github nojaf/fable-jest:fable2 fable/Bindings.fs
github nojaf/fable-jest:fable2 fable/Exports.fs
github nojaf/fable-jest:fable2 fable/Matchers.fs
Hmmm, let me uncomment nuget Fable.Import.Jest. I'll get rid of those bindings as well. And the references file should be in the project directory.
5:15pm. Now that I've done that, I am getting a ton of type errors, no doubt because of the dependencies.
...I have no idea. There is so much stuff here. Let me just read the whole things as planned. My attempt at fixing it just screwed everything up. I am going to have to do everything from scratch. Maybe I'll use that tool from the Elmish book. It really sucks that I have to juggle both npm and Nuget bindings.
paket did not even do things correctly in the first place.
5:20pm. "I found that there are TypeScript bindings on npm. With ts2fable I cooked up some minimal F# bindings which we can use."
I was wondering whether this exists and it turns out it does.
5:30pm. https://www.nuget.org/packages/Fable.Import.VSCode/
Oh, I can try adding the package directly to the reference. It has been 3 years since the bindings have been updated though. This might be something to watch out for.
5:30pm. Ok...
Let me get rid of this project. For the day, let me at least do the hello world. I'll go at it from the start.
5:55pm.
window.showInformationMessage("Hello World!",box)
Wow, the type I get in Intellisense for this does not make sense at all. Also why does this need two arguments. The JS version is clearly fine with just one.
6pm.
module FableVSCodeHelloWorld
open Fable.Import.vscode
let activate (ctx : ExtensionContext) =
printfn """Congratulations, your extension "fable-vscode-helloworld" is now active!"""
commands.registerCommand("extension.helloWorld", fun _ ->
window.showInformationMessage("Hello World!",null)
null
)
|> ctx.subscriptions.Add
let deactivate () = ()
This really took a while somehow. Let me give it a try. I have no idea what those obj types are supposed to be, but it can't be anything good.
"Command 'Hello World' resulted in an error (Running the contributed command: 'extension.helloWorld' failed.)"
Let me see the produced code.
"use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
exports.activate = activate;
exports.deactivate = deactivate;
var _String = require("./fable-library.2.5.1/String");
var _vscode = require("vscode");
function activate(ctx) {
(0, _String.toConsole)((0, _String.printf)("Congratulations, your extension \"fable-vscode-helloworld\" is now active!"));
const arg00 = _vscode.commands.registerCommand("extension.helloWorld", function (_arg1) {
_vscode.window.showInformationMessage("Hello World!", ...null);
return null;
});
const objectArg = ctx.subscriptions;
void objectArg.push(arg00);
}
function deactivate() {}
Maybe I should not be returning that null. But what else do I return then?
_vscode.window.showInformationMessage("Hello World!", ...null);
What is this ...null here? Is that fine?
6:05pm. That was the problem.
6:10pm.
module FableVSCodeHelloWorld
open Fable.Import.vscode
let activate (ctx : ExtensionContext) =
printfn """Congratulations, your extension "fable-vscode-helloworld" is now active!"""
commands.registerCommand("extension.helloWorld", fun _ ->
let _ = window.showInformationMessage("Hello World!",[||])
null
)
|> ctx.subscriptions.Add
let deactivate () = ()
My goal for the day was to get the hello world to work. And I succeeded at that. Great.
With this many setup steps, no way could I have done it on my own. If nojaf did not write down what to do, I'd have to ask around for how to get this to work.
One thing I am wondering about is where is Nuget putting its packages?
https://stackoverflow.com/questions/7018913/where-does-nuget-put-the-dll
.NET CORE
In .NET Core nuget packages are now stored in a global location, by default:
C:\Users\[User]\.nuget\packages
Additionally, the packages.config was removed with references now being stored using the <PackageReference> element in the .csproj file
Seems simple enough. Let me check it out.
c:\Users\Marko\.nuget\packages\fable.import.vscode\0.1.2\
Yeah, it is here.
I am fine with this. It is not like I need them to be in the local directory.
6:20pm. Great. I cleared the first hurdle. It took some time, but this could have been a lot more annoying than it had been.
Tomorrow, I am going to try translating that first example to Fable.
I really enjoyed playing with reactive extensions, so this should be relatively fun as well. Today and yesterday I might have spent a bunch of time reading the documentation and that book, but it was not a waste. It is never too smart of an idea to just jump in blind. I put in just the ideal amount of effort.
Even though I am pained that I could not program and instead I just had my face against the grindstone today, I am going to go at it in full force tomorrow.
6:30pm. I've really wasted way too much time in the jungle back in February and March. April is turning out pretty good so far.
I am going to go through my training, and then get to work on the Spiral project once more.
I've been putting on some airs about employability in my last review. Though it is true, I have of course no intention of aiming for a job. But aiming for passing the interview is another thing. I am going to have to get my hands on those chips and that means putting whatever social skills I have to good use. Well, I should clear that hurdle somehow when it comes to it.
I am really quite close - maybe a month or two of training away from being 100% effective as a professional programmer.
In my mind, Spiral is done. I just have to implement it, and that won't be too hard or take too long. It is this losey gosey UI stuff that I need to mop up and I am halfway done. Once I have the power to do this, I'll have the power to do anything.
Just like I've won the rematch against UIs with the Lithe POC, once I complete Spiral I will return where I was in 2018 and this time I am going to do it properly.
That exploration idea that I wrote in January 2019 is not a bad direction to go in. If I cannot get 1 model to be stable, maybe a group of a 1000 of them will do the trick. I can't really test this on the GPU, but neurochips will allow me this. Better hardware and better algorithms will come to me.
Till then, I will do what I can. Before the battle is when the conditions for victory are set."
Final update before im putting it on main
And now, the end is near And so I face the final curtain My friends, I'll say it clear I'll state my case of which I'm certain I've lived a life that's full I traveled each and every highway But more, much more than this I did it my way Regrets, I've had a few But then again, too few to mention I did what I had to do And saw it through without exemption I planned each chartered course Each careful step along the byway But more, much more than this I did it my way Yes, there were times, I'm sure you knew When I bit off more than I could chew But through it all, when there was doubt I ate it up and spit it out I faced it all and I stood tall And did it my way I've loved, laughed and cried I've had my fill, my share of loosing And now, as tears subside I find it all so amusing To think I did all that And may I say, not in a shy way Oh no, no, not me I did it my way For what is a man, what has he got If not himself then he has not To say all the things he truly feels And not the words of one who kneels The record shows, I took the blows But I did it my way
Corrected cases 20, 21 and 54
Father and grandfather excusively take remain (aasba) in addition of his prescripted share in presence of female offspring and abcence of male offspring Siter take remain (aasba) in precense of daugther but not in precense of wife, so removed wife in sister aasba condition Same with paternal sister
Update contact.html
Me stupida idiota, wrong file edited for a fuck sake 👎
Emit multiple packages in codegen tests. Exericse as plugins.
Using golang's plugin feature, we can... well, do this.
To date, testing codegen has involved running the "test" in the gen package to get it to emit code; and then switching to the emitted package and manually running the tests there.
Now, running go test in the gen package is sufficient to do
everything: both the generation, and the result compiling,
and we can even write tests against the interfaces and run those,
all in one step.
There's also lots of stuff that becomes possible now that we can easily generate multiple separate packages with various codegen outputs:
- Overall: everything is granular. We can test selections of things, rather than needing to have everything fall into place at once.
- Generally more organized results.
- We can more easily inspect the size of generated code.
- We can more easily inspect the size of the compiled result of gen! (Okay, not really. I'm seeing a '.so' file that's 4MB is coming out from 200sloc of "String". I don't think that's exactly informative. Some constant factor is thoroughly obscuring the data of interest. Nice idea in theory though, and maybe we'll get there later.)
- We can diff the generated type for variations in adjunct config! (Probably not something that will end up tested, but neat to be able to do during dev.)
Doing this with go plugins seemed like the neatest way to do this. It's certainly not the only way, though. And in particular, I will confess that this will probably make developing from a windows host pretty painful: go plugins aren't supported on windows. Mind, this doesn't mean you can't use codegen or its results on windows. It just means the tests won't work. So, someone doing development on the codegen itself would have to wait for the CI server to run the tests on their behalf. Hopefully this is survivable.
(There's also a fun wee wiggle in that loading a plugin has the requirement that it be built with the same "runtime". The definition of "runtime" here happens to include whether or not things have been built in "race" mode. So, the '-race' flag disappears from our CI config file in this diff; otherwise, CI will get the (rather confusing) error "plugin was built with a different version of package runtime". This isn't really worrying to ditch, though. I'm... not even sure why the '-race' was in our CI script in the first place. Must've arrived via cargo cult; we don't have any concurrency in this library.)
An alternative way to go about all this would be to have the tests for
gen invoke go test (rather than go build in plugin mode) on each of
the generated packages. It strikes me as similar but worse.
We still have to invoke the go tools from inside the test;
we'd have more work to do to either copy tests into the gen'd package
or else generate calls back to the parent package for test functions
(which still have to be written against interfaces, so that they can
compile even when the gen isn't done, as it indeed isn't when you
freshly check out the repo -- exact same as with the plugin approach);
and in exchange for the extra work, we get markedly worse output
('go test' doesn't nest nicely, afaict), and we can't separate the
compiling of the generated code from the evaluation of tests on it,
and we'd have no possibility of passing information via closures should
we wish to develop table-driven tests where this would be useful.
tl;dr: Highest cost, uglier, and worse.
No matter which way we go about this, there is a speed trade-off. Invoking the compiler per package adds at least a half second of time for each package, in practice. Worth it, though.
And on the off chance that this plugin approach does burn later, and we do want to switch to child process 'go test' invocations... the good news is: we shouldn't actually have to rewrite very much. The everything-starts-from-NodeStyle-and-tests-against-Node work is exactly the same for making the plugin approach work, and will trivially pivot to working fine in for child 'go test' approaches, should we find it necessary to do so in the future. So! With our butts covered: a plugin'ing we shall go!
Some of the code here still needs cleanup; this is a proof of concept checkpointing commit. (The real thing probably won't have such function names as "TestFancier".) But, we do get to see here: plugins work; more than one in the process works; and they work even when the same type names are in the generated packages. All good.
Try using 'go test' subprocesses instead.
In the parent commit, we tried using plugins. Turns out there's one big, big drawback to plugins. Building one invokes 'gcc'. Works; as long as you... have gcc, and don't mind that having that as a dependency that you now have to track and potentially worry about. I don't consider that minor.
So, okay. What's using 'go test' child invocations look like?
Well, bad. It looks... bad.
The output is a mess. Every child process starts its output as if its a top level thing. Why this happens is perfectly understandable and hard to be mad at, but nonetheless the result is maddeningly illegible. Cleaning this up might be possible, but will require some additional effort to be invested.
There's some more irritating problems than that, though. Notice the entirely new package that's sprouted.
Not being able to use closures in the test assertions is unfortunate.
Having to put the test assertions in entirely different files than their setup... now that's really painful.
(And yeah, sure, we can move the setup out to another package, too. It's not pleasing, though. Then what of the test is actually in the package it's testing? The entrypoint? So then, I'd end up editting the test setup and assertions in one package (but running tests on that package would actually no-op; syke!) and then have to switch to the other package to actually run it? There's no angle this can be sliced that results in any sort of nice.)
Flags like '-v' aren't inherited now, either. Hooray. We could try to hack that in, I suppose. Detect '-test.v' arg. But it's just another thing that needs patching up to be shipshape.
Speaking of which, '-run' arg isn't even remotely manageable without massive effort. The thing can contain regexps, for goodness sake -- how can we possibly semantically modify those for passdown?
I'm not sure where to go with this. Depending on gcc in tests is undesirable. But all these other effects from trying to use 'go test' this way seem even more undesirable.