2,496,372 events, 1,252,905 push events, 2,023,202 commit messages, 152,656,292 characters
Evil hack to work around SDL bug 4700.
Check if we're in the requested mode after the fullscreen window was
created. If not: Try to switch again in the requested mode by calling
SDL_SetWindowDisplayMode(). If that's successfull set the new window
size with SDL_SetWindowSize(). That shouldn't be necessary, at least to
SDLs crappy doku, but without the subsequent SDL_GetWindowDisplayMode()
call fails with 'Invalid Window'. Use that call to check if we're now
in the requested mode. If yes, process. If not abort and trigger the
fallback magic. It'll set r_mode 4 and vid_fullscreen 0.
Caveat: In the worst case this will switch the display mode 3 times. To create the window, to work around the bug and to set a refresh rate. No problem for flat panels, but my unforgotten Trinitron CRT would have cried in pain.
Several fixes for wxPython 3.0.2.0
These are the backwards-compatible fixes from the 15-wx3-upgrade branch that did not introduce any complex behavior changes (e.g. no pngcrush).
Fix for crashing Colors dialog
Same problem as in 360a516. Need to check if this is wx3-only or if it's needed in Phoenix as well. Also need to think about wrapping ComboBox in the wx-begone branch to fix this in a non-hacky way, no GUI component should ever hard-crash the application if it's not used correctly :P
Fix mod checker crashing when closed and reopened
Was caused by Link.Frame.modChecker never being unset - there was even a TODO for it in the code.
Fix focus not being lost on TextCtrls
This is precisely the reason why my new event framework Skip()'s by default. Not skipping by default is incredibly toxic and makes it really easy to create incredibly strange behavior.
Enough ranting - the problem was that several text fields weren't losing focus anymore. Easiest to reproduce with the ones on the Mods tab. Made editing them almost impossible since wx had to idea what to do with the cursor when multiple text fields were active at the same time.
Delay progress dialog when unpacking to project
Under wx3, it would shove itself over any warning messages / rename dialogs we showed. This wasn't really a problem, since the user could just move the progress dialog out of the way, but it was annoying. This is a fairly painless fix that just asks the questions first and then creates the progress dialog.
Clean up some outdated wx usages
Minor step towards Phoenix compatibility.
Co-authored-by: MrD [email protected]
SEVERAL mask sprite fixes (#48744)
- society moment
god im so funny
- do you apes not know what consistency means?
seriously who the fuck made these sprites
feat(java11): allow conditionally turning on the cross-compiler plugin
The cross-compiler plugin requires a little additional setup (you have to set
the JDK_18 environment variable to point at a Java 1.8 JDK) but it fixes an
issue with Groovy and Kotlin compilation, where it prevents you from calling
Java 11 APIs when cross-compiling to Java 8. (For javac, you just have to say
--release 8, but setting it up for Groovy and Kotlin is more complicated.)
The Netflix Nebula plugin turns this on automatically, but only for "candidate" builds, which is why my Java 11 merges succeeded with container builds and PR GHA builds, but failed with the Debian builds and post-merge GHA builds. (It failed because we didn't have "JDK_18" set.) So at first I was annoyed about that because it's going to be a bit of a pain to configure (you'll see soon enough), but then when I looked into it more I realized it's a pretty helpful plugin, so I decided to embrace it.
I don't think we want to enable this all the time, or else developers will also have to set that variable (which is why it's only enabled for the "candidate" target). But I would like to turn it on for container and PR builds.
Squashed commit of the following:
commit f58a8c46e0fef0aa516f8c4349437d5f85df511a Author: Sam Tay [email protected] Date: Fri Mar 20 00:43:02 2020 -0700
Easier display toggle
commit e3306baa6a467f3f3a25357d77849e77f869882e Author: Sam Tay [email protected] Date: Fri Mar 20 00:42:46 2020 -0700
Update xmonad layouts
commit 68004ad1e5c35bccd29f4f01970b086b0df2ad81 Author: Sam Tay [email protected] Date: Fri Mar 20 00:42:13 2020 -0700
Haskell formatting config
commit 4c04015bcdf4336e3717413901a9a055ef23aab4 Author: Sam Tay [email protected] Date: Sat Mar 7 17:26:15 2020 -0800
Holy crap, resizable secondary panes
How the hell did I not know about this..
commit a4b254e2562e7401c6ef4401ea8622f234405681 Author: Sam Tay [email protected] Date: Thu Feb 20 11:11:38 2020 -0800
Fix highlighting in jekyll posts
commit 7127b3056317a873cdef70b037f8daeea85a6083 Author: Sam Tay [email protected] Date: Thu Feb 20 11:10:41 2020 -0800
Add terminalizer config
commit 8666e61cb5335b5bdddbf667db1eb8eed6d221c9 Author: Sam Tay [email protected] Date: Thu Feb 20 11:09:57 2020 -0800
Use pulseaudio to squeeze sound out of shit speakers
commit 177a6d8c4b197a4e43aec66d889563dc319516d4 Author: Sam Tay [email protected] Date: Thu Feb 20 11:09:26 2020 -0800
Fix carrot symbols in nerdtree
commit 5c0fe2899c46a04056eba0bb0d99aa9221427614 Author: Sam Tay [email protected] Date: Sun Feb 9 12:52:53 2020 -0800
Fix highlighting of diagrams within latex
commit f175fc57e090f8b707804f1217e072e4f6c4864d Author: Sam Tay [email protected] Date: Fri Feb 7 09:50:09 2020 -0800
Update vim-latex compilation, wm, PATH mgmt
Completado registrar turno
Morty: I can’t fucking do this anymore!
Rick: That was seriously fucked up. We almost died.
Morty: So you agree?
Rick: Fuck yes! That w... T-This was insane! That was pure luck. I was not in control of that situation at all.
Morty: (continues crying)
Rick: (notices his hands shaking) Look at this, Morty. Look at my fucking hand. Look at this shit.
Morty: Why do you... Keep doing this to us?!
Rick: I don’t know, Morty. Maybe I hate myself, maybe I think I deserve to die. I-I-I-I don’t I don’t know!
Hello there. Yeah, you. If you're reading this, remember that you are amazing. You're good enough, you're strong enough, and gosh diddly darn it, people like you. Peace out, bruddah.
Moved the “clu.typespace” inline tests to a “main.py” file
... The reason for this is: the setup we’re using with nox to
detect and run all the inline tests constructs commands of the
form:
$ python -m clu.module.name
... using the “clu.exporting.path_to_dotpath(…)” function to change
a modules’ file path into the dotted module name that’s used in
that command there.† The problem, then, is “path_to_dotpath(…)”
special-cases “init.py” and “main.py” files, converting
paths that terminate in these filenames into the name of the
enclosing module, e.g. “clu/config/init.py” will get turned
into just “clu.config”. In 99.9999% of cases, this is what you
want. But what I just found out is: doing the python -m thing
with a dotpath that resolves to a package – that is to say, a
directory – tries to load and execute a “main.py” file from
that directory, NOT an “init.py” file. There is even some
kind of specialized error message your Python executable will
spit back at you if you try to do python -m package.dotpath
when a “main.py” file isn’t found therein.
... SO ANYWAY. tl;dr there is now a “clu/typespace/main.py” file
that contains the “inline” tests that were formerly inlined in
the “clu/typespace/init.py”, and the latter does a wacky
little import do-si-do in its “if name == "main"” bit to
pull in and run those tests. Which, notably, aren’t “inline” any
longer. What to call them, “out of line”? “offline”? “ingrown”?
I am open to suggestions.
... And so yeah while the current setup works, as far it goes with
both running nox and ⌘-R’ing the “init.py” file in TextMate
it would not at all be too forward to call this arrangement a
ridiculous Rube Goldberg nonsensical misdirection. So maybe I
will change this shit at some point, or maybe I will leave it
be. We shall see doggie, indeed yes.
† – that’s an oversimplification – while “path_to_dotpath(…)” is at the heart of this transformation, it actually involves a bunch of moving parts; those who are curious should have a look at these parts of CLU for the deets:
* “clu.fs.filesystem.Directory.importables(…)”, a method
which itself relies on:
* the “suffix_searcher(…)” and “re_excluder(…)” functions,
found in “clu.fs.misc”;
* “clu.exporting.path_to_dotpath(…)”, as mentioned – this
function is used sparingly, but everywhere it is used is
like some super-crucial shit;
* everything in “clu.all”: “import_all_modules(…)”, its
sister function “import_clu_modules()”, and the function
whose heuristics sniff out inline tests – appropriately
named “inline_tests(…)”
* the nox configuration file, “noxfile.py”, which you’ll
find in the project root, q.v. https://git.io/JvSpx sub.
Added more tests but disabled them. Mvc doesnt seem to work, stacktrace is absolutely NOT helpful. I fucking hate my life.
"9:05am. I am up. I'll leave the chapter of Asuka that finally came out and everything else for later.
During the night, I've been thinking about reactive programming. I understand async/await. I understand message passing.
But something finally occurred to me - I actually do not understand observables.
I thought I did, but a more accurate view would be that I only understand it when it acts functional. I finally realized that given Observable and Observer I do not know how to actually implement the functionality with just that. Not to mention, the functionality frequently goes beyond functional with observables.
9:10am. OnNext, OnComplete and OnError really does have a lot of similarity to the CPS stuff I am familiar with, but how is it supposed to be composed? They all end in unit.
9:15am. ...I've been too arrogant. This stuff seemed simple, but I've underestimated it and overestimated my capacity to understand it.
I think for once, the reason why I could not make use of this years ago is because I am lacking low level understanding.
Programming Reactive Extensions and Linq "Pro Reactive Extensions and LINQ is a deep dive into the next important technology for .NET developers: Reactive Extensions. This in-depth tutorial goes beyond what is available anywhere else to teach how to write WPF, Silverlight, and Windows Phone applications using the Reactive Extensions (Rx) to handle events and asynchronous method calls."
Let me get this book for later.
9:20am. Am I in agreement with myself that this is worth studying? Yes. Then I am going to do it.
I'll leave Spiral aside for the time being. The editor support for it will happen when all the fundamentals are in place. I've spat on Dirk's work, but even if I finish studying the project, it is not like I know how to significantly improve on it. Svelte is great - it is the final destination when all of this has been abstracted into a good syntax, but I need to know what goes under the hood here and how to make good use of it.
Reactive extensions are actually fairly new technology now that I think about it. A near decade is nothing.
9:25am. It is really difficult to know what is a vital skill and what is not. Sometime my intuition is right, but sometimes like now it does not fire at all and I have to reason it out.
Let me finally start going through the IntroToRx book.
9:40am.
let map f (x : IObservable<_>) =
{new IObservable<_> with
member this.Subscribe(y) =
x.Subscribe(fun v -> y.OnNext (f v))
}
This is not from the book, I am just doing some exploratory programming on my own.
The signature here matches now.
Actually aren't I quite familiar with this?
IObservable is just a function that takes a callback with 3 branches. This is something I am well familiar from monadic CPS and when I was doing parser combinators in Spiral. If anything, I seem to be confused by the fact that I am always passing in OnNext only.
The only really novel thing is that subscribe return an IDisposable and the OnComplete branch. Those two are new elements.
Ok, so maybe I do understand how to implement this. While I was in bed, I wasn't even sure how map would go.
9:45am. Let me get back to the book. I understand at least half of the low level aspects of this now.
10am.
result.Subscribe(printfn "%i", (fun (x : Exception) -> printfn "Error %A." x),fun _ -> printfn "Completed.") |> ignore
I tried raising an error in one of the Observables, but it is not getting caught and rerouted. I have no idea. I guess the book will clear this up.
static void Main(string[] args)
{
var subject = new Subject<string>();
WriteSequenceToConsole(subject);
subject.OnNext("a");
subject.OnNext("b");
subject.OnNext("c");
Console.ReadKey();
}
//Takes an IObservable<string> as its parameter.
//Subject<string> implements this interface.
static void WriteSequenceToConsole(IObservable<string> sequence)
{
//The next two lines are equivalent.
//sequence.Subscribe(value=>Console.WriteLine(value));
sequence.Subscribe(Console.WriteLine);
}
This is interesting. I need to keep in mind that I can just subscribe to standard IO streams.
10:05am.
public void ReplaySubjectWindowExample()
{
var window = TimeSpan.FromMilliseconds(150);
var subject = new ReplaySubject<string>(window);
subject.OnNext("w");
Thread.Sleep(TimeSpan.FromMilliseconds(100));
subject.OnNext("x");
Thread.Sleep(TimeSpan.FromMilliseconds(100));
subject.OnNext("y");
subject.Subscribe(Console.WriteLine);
subject.OnNext("z");
}
Ok, I am into this now. This stuff could be quite useful.
10:20am.
let r = Subject.replay
r.OnNext(1)
r.OnNext(2)
r.Subscribe(printfn "%i").Dispose()
r.OnNext(3)
r.OnNext(4)
r.Subscribe(printfn "%i").Dispose()
r.OnCompleted()
Am playing with this. If r.OnCompleted is called in the middle, and the Subject is subscribed to again then what will happen is that only the stuff in the buffer will get replayed. Interesting.
Ok, I am definitely getting a sense for this. I have a good idea how to implement all of this, though no doubt there is some threading stuff being done under the hood that I am not aware of. It might be good idea when all this is done to actually take a dive into that.
10:30am.
Each of these overloads allows you to pass various combinations of delegates that you want executed for each of the notifications an IObservable<T> instance could produce. A key point to note is that if you use an overload that does not specify a delegate for the OnError notification, any OnError notifications will be re-thrown as an exception. Considering that the error could be raised at any time, this can make debugging quite difficult. It is normally best to use an overload that specifies a delegate to cater for OnError notifications.
Huh, so it is supposed to be caught? Why is my own thing not catching it then?
10:35am.
let input =
Observable.range 0 10
|> Observable.choose (fun x -> failwith "error"; Some x)
input.Subscribe(printfn "%i", (fun (x : Exception) -> printfn "Error %A." x),fun _ -> printfn "Completed.") |> ignore
Ah, I get it. If I raise this error in choose it dies, but if I do it in filter then it gets caught.
10:40am.
let input =
{new IObservable<_> with
member t.Subscribe x = x.OnNext(1); {new IDisposable with member t.Dispose() = ()}
}
|> Observable.choose (fun x -> failwith "error"; Some x)
input.Subscribe(printfn "%i", (fun (x : Exception) -> printfn "Error %A." x),fun _ -> printfn "Completed.") |> ignore
Oh the choose here also has the right behavior.
It seems what I've run into is a library bug.
...No actually, when I open FSharp.Control.Reactive the behavior does not change.
How strange.
This might be worth opening an issue about. Let me do it.
11am. I've opened issue 131 on the FSharp.Control.Reactive repo.
This distracted me. Let me get on with the book.
11:05am. "So we can see that you can use the IDisposable interface for more than just common use of deterministically releasing unmanaged resources. It is a useful tool for managing lifetime or scope of anything; from a stopwatch timer, to the current color of the console text, to the subscription to a sequence of notifications."
I should keep this in mind.
11:15am. I am done with part 1.
https://hillelwayne.com/post/influential-dead-languages/
I'll leave this article for later.
http://introtorx.com/Content/v1.0.10621.0/04_CreatingObservableSequences.html
Usually, I would dive into the chapter immediately, but I am going to stop for breakfast here. No doubt, I have to do the chores early today."
Bug 24123: Fix import of UTF-8 encoded MARC21 MARCXML using bulkmarcimport (elastic only)
If elastic is used as search engine, the bulkmarcimport.pl will not handle correctly UTF-8 encoded MARCXML
Koha::SearchEngine::Search->new uses a require statement to load the correct Search module. This is done l.257 of bulkmarcimport.pl: 257 my $searcher = Koha::SearchEngine::Search->new
Koha::SearchEngine::Elasticsearch::Search will use MARC::File::XML, and so resets the arguments set before:
216 $MARC::File::XML::_load_args{BinaryEncoding} = 'utf-8';
220 $MARC::File::XML::_load_args{RecordFormat} = $recordformat;
An easy (but dirty) fix could be to move the declaration of my $searcher before in the script. The tricky (but correct) fix would be to remove the long standing "ugly hack follows" comment.
This patch is the easy, and dirty, fix
Test plan: Use the command line tool to import MARXCML records that contains unicode characters into Koha
Something like misc/migration_tools/bulkmarcimport.pl -biblios -file record.marcxml -m=MARCXML
Without this patch you will notice that unicode characters will not be displayed correctly
Signed-off-by: Michal Denar [email protected] Signed-off-by: Tomas Cohen Arazi [email protected] Signed-off-by: Martin Renvoize [email protected]
Signed-off-by: Joy Nelson [email protected]
“clu.importing.ProxyModule” is now a “generic template type” ... to wit, you don’t simply inherit from ProxyModule – you do it like this:
class MyProxy(ProxyModule[Module]):
# …etc
.... where the “Module” type parameter is something you got from calling “clu.importing.initialize_types(…)”, as in:
Module, Finder, Loader = initialize_types(APPNAME)
... which why? Why would anyone do that? Because this way, the definition of ProxyModule can exist in “clu.importing” in a totally concrete way – independent of you the CLU user and whatever and however you might choose to define your own apps’ specific ModuleBase types. You can then import, “specialize” and use “clu.importing.ProxyModule” with ease, and we don’t have to add more crapola to the PolymerType registry or the type-initialization system or any of that other stuff.
... Furthermore, we can proceed to use this strategem for future generic class-module types – or perhaps, if need be, generic module finders or loaders – for a totally forward-compatible class-module typology that isn’t reliant on subclassing things (which that is one of CLU’s blemishes, the fact that currently its users are asked to arbitrarily subclass a lot of shit). As they say on Mandalore, this is the way.
... And if I may add a personal note here – I am fucking shocked and amazed that this whole “generic template type” trick is something that actually works – and that it did so on more or less the first serious go-around. It is totally both a wicked abuse of the “typing” modules’ new reserved dunder-methods, but also a total sweet embrace of same. Seriously I cannot believe this shit at all dogg, yeah!
feat(java11): allow conditionally turning on the cross-compiler plugin (#110)
The cross-compiler plugin requires a little additional setup (you have to set
the JDK_18 environment variable to point at a Java 1.8 JDK) but it fixes an
issue with Groovy and Kotlin compilation, where it prevents you from calling
Java 11 APIs when cross-compiling to Java 8. (For javac, you just have to say
--release 8, but setting it up for Groovy and Kotlin is more complicated.)
The Netflix Nebula plugin turns this on automatically, but only for "candidate" builds, which is why my Java 11 merges succeeded with container builds and PR GHA builds, but failed with the Debian builds and post-merge GHA builds. (It failed because we didn't have "JDK_18" set.) So at first I was annoyed about that because it's going to be a bit of a pain to configure (you'll see soon enough), but then when I looked into it more I realized it's a pretty helpful plugin, so I decided to embrace it.
I don't think we want to enable this all the time, or else developers will also have to set that variable (which is why it's only enabled for the "candidate" target). But I would like to turn it on for container and PR builds.
Updates rune sprites slightly
gives an actual sprite for the adamantine rune and use rewind to cut on some useless sprite animation. My sprites are still god awful though sorry
Many Chanegs -- See Description
I went and revamped a bunch of shit.
-
I ran Black on the file
-
Twitch updated their API so I implemented a new library to interact with Twitch and be a drop in replacmeent for the old twitch function.
-
VC Naming -- similarly to the the shrink command, there is a set command. This lets users add strings to the channel name so statically named channels dont need to exist.
-
Fixed 1 small bug within shrink. Edge case happens when user sets the channel before a restart and leaves after meaning they arent in the cache and the channel isn't reset.
-
Added an automatic message poster thing called "lfg_channel_informer". Main use case was to post a message in our LFG channels but not flood it. This is done by posting every 2 mins but only actually sending if the last 15 messages dont contain our message to post meaning this is posted every 15 messages at minimum.
-
Refactored how we save our data during a reboot.
-
Added in inv and lfg commands pulled from apex bot. These tie into the set command as well for better lfg overall.
-
Added in some tweaks to Response. Can now schedule a message and its reply be deleted after a period of time.
-
Added in mod commands removesettable and makesettable to tie into set command to automatically expand the misc category based on whats needed
-
Bug fixes I cant remember, im sure. The Diff is fucked cause black so this wrap up will be incomplete
Completed 66 Mitchell Johnstone
Quarantine baby! Oh yeah. Day 9 of being stuck in my room, and honestly it's getting better. If only I actually had wifi, since 67 involves a downloaded txt file. anyways, for this problem, I had some trouble to start out with, but once I found the correct approach it was fairly straightforward. I originally started tackling this problem with a brute force to solve for the smallest x for each D by incrementing x and checking if it would work. While x increased fast, and i got rid of about 3/4 of the possible D values, it eventually platued and I couldn't make it any more efficient. After trying similar ideas, but using y and D for my incremented variables, I needed another way to do this. After looking up what the equation was, it turns out that minimal x was related to the square root of D using the convergences of the infinite continued fractions of the square root of D. Since 64 and 65 involved generating the pattern for the continued fraction and solving the convergence for the continued fraction, respectively, I used ideas from both to get a program that worked efficiently at the end. One hell of a beast, but tamed once I learned.
All the best, MJ
Reproducibility (#1027)
- Add stack.yaml.lock and commit cabal files
By comitting stack.yaml.lock our build plan is fully reproducible. We've had several cases where people could not reproduce a build on develop before either due to cabal revisions or due to people accidentally touching snapshot files. stack.yaml.lock is a fixed build plan with hashes derived from your snapshots and stack.yaml
See https://github.com/commercialhaskell/stack/blob/master/doc/lock_files.md for more info
We also commit the cabal files. Not committing them also reduces reproducibility and the Stack people admit this now as well https://tech.fpcomplete.com/blog/storing-generated-cabal-files In the next stack release generating them will be the default.
- Create a new snapshot that pins correct version of hsaml2
Also pin correct version of saml2-web-sso
I took the liberty to move away from our system of having snapshots in
./snapshots/*.yaml and have new snapshots refer to previous ones. This
was a workaround for getting better caching in Stack 1.0 which is
simply not needed anymore. We have a new single wire-snapshot.yaml
file which you are always free to modify. Because Stack 2.0 uses
content-addressed storage, making changes to this file will still cause
most packages to be re-used.
With Stack 2.0 and the introduction of pantry, there is no semantic
difference anymore between extra-deps in your stack.yaml and custom
snapshots. We could thus fold everything into a single stack.yaml and
keep the same benefits.
However custom snapshot format format gives you a bit more control (you
can for example also remove packages from a snapshot, which is not
possible in stack.yaml)
Source
So we can just have one single wire-snapshot.yaml
where we define external deps (and fold all the changes of all our
snapshots into that single file). We do not have to make
distinctions anymore between "Things that change often go into
stack.yaml and things that change seldom go into snapshot.yaml" as
under the hood they're all the same build and caching mechanism now.
We also do not have to worry about not editing this file anymore. They
don't have to be treated as immutable as before. So no need to create a
blah-2.0.yaml referring to blah-1.0.yaml to work around the fact
that stack doesn't refetch snapshots after edited. From Stack
documentation
They are assumed to be mutable, so you are free to modify it. We detect that the snapshot has changed by hashing the contents of the involved files, and using it to identify the snapshot internally. It is often reasonably efficient to modify a custom snapshot, due to stack sharing snapshot packages whenever possible.
We keep the ./snapshots folder for now; as our snapshots do not refer to themselves by relative path but by absolute URL which mentions the branch name and github repository. This is a bit of a shame as this means we can never remove them as this will break older builds :(
I do not know how much we care that old builds keep working, but having them work by promising some url to a mutable artifact stays around was never very good for reproducibility so maybe we should not care.. However; lets break this in a different PR after heavy discussion :)
- Move away from snapshots completely
We fold everything into stack.yaml
I really do not see any difference anymore, and with pantry this change should be completely safe to make. We can now freely change stack.yaml and get the same caching guarantees as before. (That is; if we have a cache from a previous build that share 95% of the dependencies with the new stack.yaml, then CI will just gladly pick this up due to how Pantry works)
Again as noted before, what to do with the old 'snapshots/' folder I do not know yet. We need to keep it around to keep old builds working as they refer to it not by commit id but by 'develop' branch which is a moving target.
- Ignore bounds for some dependencies
We were already doing this implicitly because we used custom snapshot before. Now we have to do it explicitly.
For good records, I attached the bounds issues to this commit. Note that at least multihash is maintained by ourselves. we should thus be able to solve the bounds issues for it
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for HaskellNet-0.5.1: mime-mail-0.5.0 from stack configuration does not match >=0.4.7 && <0.5 (latest matching version is 0.4.14) needed due to brig-1.35.0 -> HaskellNet-0.5.1
In the dependencies for HaskellNet-SSL-0.3.4.1: connection-0.3.1 from stack configuration does not match >=0.2.7 && <0.3 (latest matching version is 0.2.8) needed due to brig-1.35.0 -> HaskellNet-SSL-0.3.4.1
In the dependencies for bloodhound-0.16.0.0: containers-0.6.0.1 from stack configuration does not match >=0.5.0.0 && <0.6 (latest matching version is 0.5.11.0) http-client-0.6.4 from stack configuration does not match >=0.4.30 && <0.6 (latest matching version is 0.5.14) needed due to brig-1.35.0 -> bloodhound-0.16.0.0
In the dependencies for multihash-0.1.6: base-4.12.0.0 from stack configuration does not match >=4.7 && <4.12 (latest matching version is 4.11.1.0) needed due to brig-1.35.0 -> multihash-0.1.6
In the dependencies for stm-hamt-1.2.0.4: primitive-0.6.4.0 from stack configuration does not match >=0.7 && <0.8 (latest matching version is 0.7.0.1) primitive-extras-0.7.1.1 from stack configuration does not match >=0.8 && <0.9 (latest matching version is 0.8) needed due to spar-0.1 -> stm-hamt-1.2.0.4
Find My Friends …
New "Find My Friends"-Icon for the Bridge-App. Designed with Love, based on the old Icon for iOS 6 …
Merge branch 'temp-unfuck-selectmusic' of github.com:fieoner/simply-love-sm5 into temp-unfuck-selectmusic
update 💩 💩 💩 :fuck: :FUCK!!!!: :slipping into darkness:
"1:20pm. Done with breakfast and chores.
https://youtu.be/sZsJyCyGBSI Sakeru Gumi series
This was hilarious.
1:30pm. Let me leave the rest for later. Time to get back into the book. I understand observables 80% now. The way they work is standard FP fare. No problem for me at all.
Oh, the F# library of it has monadic builders.
Ok, finally found it.
let input =
Observable.single 1
|> Observable.map (fun x -> failwith "error"; x)
It is fucking single. I've been trying constant, yield, return to no avail.
1:40pm. Hmmm, the Internet just gave out. I was going to adjust that issue, but nevermind.
There is something I need to know. If one subscriber raises an error, is the Observable still valid for others to subscribe on?
let input =
let mutable b = true
Observable.single 1
|> Observable.map (fun x -> if b then b <- false; failwith "error" else x)
input.Subscribe(printfn "%i", (fun (x : Exception) -> printfn "Error %A." x),fun _ -> printfn "Completed.").Dispose()
input.Subscribe(printfn "%i", (fun (x : Exception) -> printfn "Error %A." x),fun _ -> printfn "Completed.").Dispose()
input.Subscribe(printfn "%i", (fun (x : Exception) -> printfn "Error %A." x),fun _ -> printfn "Completed.").Dispose()
Yeah, just the first one raises an error. The rest print 1 and "Completed.".
Ok, good.
1:50pm. The internet is still not back...let me check it out.
2:10pm.
open System.Reactive.Linq
open System.Reactive.Disposables
open FSharp.Control.Reactive
In addition to the F# stuff, it is good to open the Linq as well.
2:25pm.
"Infinite and arbitrary length sequences can be very useful. First we will look at some that come with Rx and then consider how we can generalize the creation of infinite observable sequences."
Never used them much personally.
2:35pm.
"As an exercise, write your own Range factory method using Observable.Generate."
Let me give it a try.
let range from to' =
Observable.generate from (fun x -> x <= to') ((+) 1) id
Yeah, this works. Nice.
2:55pm.
Using this overload, and specifically the extra timeSelector argument, we can produce our own implementation of Observable.Timer and in turn, Observable.Interval.
public static IObservable<long> Timer(TimeSpan dueTime)
{
return Observable.Generate(
0l,
i => i < 1,
i => i + 1,
i => i,
i => dueTime);
}
What the hell? Let me play with this a bit.
let obs =
Observable.generateTimeSpan 0 (fun x -> x < 10) ((+) 1) id (fun x -> TimeSpan.FromSeconds(0.3 * float (x + 1)))
obs.Subscribe(printfn "%i", (fun (x : Exception) -> printfn "Error %A." x),fun _ -> printfn "Completed.") |> ignore
Console.ReadKey()
Yeah, this does what I think it would.
3:10pm.
//Activated delegate is EventHandler
var appActivated = Observable.FromEventPattern(
h => Application.Current.Activated += h,
h => Application.Current.Activated -= h);
//PropertyChanged is PropertyChangedEventHandler
var propChanged = Observable.FromEventPattern
<PropertyChangedEventHandler, PropertyChangedEventArgs>(
handler => handler.Invoke,
h => this.PropertyChanged += h,
h => this.PropertyChanged -= h);
//FirstChanceException is EventHandler<FirstChanceExceptionEventArgs>
var firstChanceException = Observable.FromEventPattern<FirstChanceExceptionEventArgs>(
h => AppDomain.CurrentDomain.FirstChanceException += h,
h => AppDomain.CurrentDomain.FirstChanceException -= h);
Hmmm, I am not sure where Application resides.
https://docs.microsoft.com/en-us/dotnet/api/system.windows.application?view=netframework-4.8
Ah, it is probably in WPF.
3:20pm.
//Example code only
public static IObservable<T> ToObservable<T>(this IEnumerable<T> source)
{
return Observable.Create<T>(o =>
{
foreach (var item in source)
{
o.OnNext(item);
}
//Incorrect disposal pattern
return Disposable.Empty;
});
}
I do not understand why this disposal pattern is incorrect. I mean what is there to dispose here? The source? That can't be it.
3:25pm. Ah, maybe a problem is that the source could be infinite? But that seems like a separate concern from disposal...
Well, it would be a problem if one called subscribe on this only to have it diverge. So this code is obvious troublesome from that perspective.
I am not sure how I would do this properly. Wrap it in an async? That could work, but I am not sure where to catch the exceptions in that case. Would it be fine to have them flow out of the async block? Probably not.
let q =
async {printfn "Hello from async."; Threading.Thread.Sleep(5000)}
|> Async.StartImmediate
printfn "I am here."
No, this gets executed on the main thread. It is not good.
let obs =
Observable.generateTimeSpan 0 (fun x -> x < 10) ((+) 1) id (fun x -> TimeSpan.FromSeconds(0.3 * float (x + 1)))
obs.Subscribe(printfn "%i", (fun (x : Exception) -> printfn "Error %A." x),fun _ -> printfn "Completed.") |> ignore
let q =
async {printfn "Hello from async."; Threading.Thread.Sleep(5000)}
|> Async.StartImmediate
printfn "I am here."
Console.ReadKey()
The way to get real asynchrony would be to use another observable.
...I have no idea what the right way to do this would be. Nevermind that for now.
3:45pm. http://introtorx.com/Content/v1.0.10621.0/05_Filtering.html
Let me stop here for a bit. I need a break. Towards the end of the last chapter there was some outdated stuff that I cannot find analogues in the current version. It does not matter.
4:25pm. Let me resume. 1.5 hour left to go in the day, and I want to go through at least one other chapter.
As one might expect, there are methods to turn properties and events into Observables.
4:40pm. Er, focus me, focus. I can slack later. Right now I still have some steam left.
4:55pm.
let obs = Observable.ofSeq [|1;2;3;4;1;1;2;3;5|]
let obs2 = obs |> Observable.distinct
obs.Subscribe(printfn "%i",printfn "%A",fun _ -> printfn "Completed.")
obs2.Subscribe(printfn "obs2 %i",printfn "%A",fun _ -> printfn "Completed ob2.")
Ah, whops, I forgot that subscribe is in fact synchronous.
This executes obs and then obs2.
open System
open System.Reactive.Linq
open System.Reactive.Disposables
open FSharp.Control.Reactive
let sub = Subject.broadcast
let observable = sub |> Observable.distinct
sub.Subscribe(printfn "%i",printfn "%A",fun _ -> printfn "Completed.")
observable.Subscribe(printfn "obs2 %i",printfn "%A",fun _ -> printfn "Completed ob2.")
sub.OnNext(1)
sub.OnNext(2)
sub.OnNext(3)
sub.OnNext(1)
sub.OnNext(1)
sub.OnNext(2)
sub.OnNext(4)
sub.OnCompleted()
This does the same thing as in the example.
5:05pm. I am distracted. Rather than reading the book, I am thinking of how interfaces should be implemented in Spiral.
There is some nuance, but it is nothing too complicated. I can take care of it.
I've decided to reserve {| ... |} syntax for them, similar to records. They are quite similar to records in fact, except more efficient when being boxed.
Unlike in F#, I won't give their types a name directly, instead I will leave the nominals their usual role. That is the best way.
5:15pm. Interfaces are one of the rare good ideas in OO, and I should definitely put them in.
Agh, but that is just more work. Well, I'll see how it goes.
Mastering reactive programming and using those newfound skills to do editor support is what I need to focus on.
5:20pm. Yeah, as fun as thinking about this is, how about I resume the chapter?
5:25pm. Ahhhh...
The way I did loops was all wrong!
Rather than from: near_to: by:, I should have done from: near_to: up: and from: near_to: down:.
Why did this only occur to me now? Because I started off with Spiral's records! They were such an anti-pattern that I would not have dared to do this.
Also, what I should do is make the loops parameters unsigned. That way there is no possibility of passing in a value in the wrong direction in as would be in by:.
Yeah, this is it!
...I will also name integral and float constraints int, uint, float respectively. num for their union.
That is great.
5:30pm. Let me resume the book again.
More than anything I need to learn how to do UIs. I really won't be able to go much further as a programmer without mastering reactivity.
I am definitely going to be looking under the hood of the Rx library when all this is done. There are so many methods in that library, and studying them will give me clues for how I could have done that poker game in a reactive fashion.
5:40pm.
var subject = new Subject<int>();
subject
.SkipLast(2)
.Subscribe(Console.WriteLine, () => Console.WriteLine("Completed"));
Console.WriteLine("Pushing 1");
subject.OnNext(1);
Console.WriteLine("Pushing 2");
subject.OnNext(2);
Console.WriteLine("Pushing 3");
subject.OnNext(3);
Console.WriteLine("Pushing 4");
subject.OnNext(4);
Console.WriteLine("Completing");
subject.OnCompleted();
This was supposed to be TakeLast(2). Should I send the error? No, it is way too late for that.
5:50pm. http://introtorx.com/Content/v1.0.10621.0/06_Inspection.html
Let me finally move to this chapter.
6:05pm. http://introtorx.com/Content/v1.0.10621.0/07_Aggregation.html
Do I feel like reading this as well?
Well, why not.
6:45pm. Done with lunch.
I'll leave the chapter for tomorrow after all.
So far the book is pretty decent. After I am done, I think it will definitely serve as a good backing as I dive into those WPF libraries. A though is occurring to me - am I sure that ReactiveUI is not just a cross platform wrapper for UIs? It might turn out in the end and that it is not doing much reactive stuff on its own, over what is provided by Rx. This might make what I am learning now over more valuable than expected.
Well, either way, I will want to master this. Even though I won't be doing desktop UIs using WPF or ReactiveUI after this, the design of the UI library should give me hints about how the language plugin should be done. I am pretty sure by now - if one wants to do a language plugin, there is no point in looking at others for examples of how this should be done.
6:50pm. I am out."
Fixed database writting.
I'm gonna be comepletely honest with you here, I don't actually remember what was wrong but that's what my problem was last night and it works now so that's cool. That's only partially a lie.
The problem seemed to be my code writting to the database. That wasn't the case. It WAS writing to the database, it wasn't reading the database correctly though. I forgot to run a lookup in the database which was the issue. Everything after that was pretty simple.
I have changed my attack vector (aka how I want to achieve this) and I have gone for the route that involes the least amount of fiddling with SQLite which should actually be fastest. Currently, since there are 22 toggleable features, RomeBot has a string of 22 1s added to the database. In future, RomeBot will allow for updating the database, this will probably be automatic but I have created a placeholder command for the time being called !updateServer, this may end up remaining to allow the user to manually update their listing in the database.
Due to my switch in how I want to achieve feature control, I have removed almost everything I did last night. While this wasn't fun to do, it was required to ensure I don't just hack together a solution.
As always, I am trying to make this as easy as possible to host on your own. As a result, everything currently configures on its own, I hope this will continue to be the way things are handled.
Thursday 2020-03-26 18:32:04 by [email protected]
In this life I'm insanely lonely. Please decorate my life with love.
Add files via upload
Hey,
I'm a Single Girl. ..Need a partner...
Obviously real.. No drama, no fake,,,
I'm .. wanna fuck.. contact Here: https://goo.gl/Z2tePD
confirm your mail and Give me screenshot and give your usar name so i think you real .
My usar id : HotSexy739
ktl's fixes, actually done because I'm a goddamn idiot
shitcode
Run closed structured ice shelf simulation with Kh=1e-3m^2/s for 1hr
Run a closed structured ice shelf simulation with Kh = 1e-3 m^2/s and Kv = 1e^-4m^2/s with a timestep of 600 seconds. The melt param also used gamma function of u fric based on the constants given in Jenkins et al 2010.
On 8 cores this took a few minutes to run 1 hour of simulation.
The density solution seems stable. There is a very thin low density diffusing out from the top boundary which is the fresh cold water generated by melting. There are no cells/stripes forming in the density fields which happened before the dg advection fixes.
The temperature and salinity fields do have discontinuities between cells. This means the meltrate oscillates rapidly along the ice shelf base. This is seen in Ben's FRISP results.
The velocity field also seems stable. The flow is clockwise with very thin positive x component velocity along the ice shelf base. The y velocities are also positive along the ice shelf base but they are columns of alterning positive and negative velocity order 1e-6m/s. Not sure if these will disappear as the simulation progresses. The overturning cells don't seem to be the same as before the dg advection fixes.
Prior to this I ran with Srestore 34.41 so that there was still a 0.01 PSU difference between the initial conditions and the forcing. This still ran but in a closed box it shouldn't be needed because there water can't flow in or out. The melting density structure was just superimposed on the initial vertical density front seen in the no melting simulations.
I had also been running a longer version of the 5day simulation in an open box that is forced by higher salinity values outside the domain. I haven't looked at these yet but the simulation got to 17.5 days before I accidentally crashed it by renaming the output folder.
Stephan found that the funny density stripes in the topright corner of the no melting simulation is probably due to the slope limiters preventing a baroclinic instability from forming. Need to talk with Stephan to work out if this is a bad thing.
Matt emphasised that I need to compare early spinup with the spinup of MITgcm. If you don't look at the first timesteps then possibly you are missing important and sometimes weird results generated by the model.
To do:
-
Look at the long no melting simulation. Have the cells disappeared? Has the density front reached the grounding line?
-
Send Matt and Stephan the new melting simulation pictures
-
Run melt simulation for longer to compare with MITgcm.
but....
I've realised there is a bit of a problem because the melt param in MITgcm for the gamma(u*) is actually from the Holland and Jenkins 1999 paper which defines gammaT = u* / (Gamma_turb + Gamma_mole)
where the Gamma_turb also depends on u*.
I've tracked down where the maths in holland and jenkins 1999 appears in MITgcm. The code is all in shelfice_thermodynamics and the constants are mostly in shelfice_readparms, though some are calculated in shelfice_thermodynamics. This is written in my notebook and will sort out a more permanent notes tomorrow.
So for the comparison with MITgcm there are three options:
-
keep current our gamma(u* ) based on Jenkins et al 2010 and then change line 0453 and 0455 in shelfice_thermodynamics to something like: gammaT = GammaT u* where GammaT is the constant in Jenkins et al 2010. Is this all I would have to do? This seems very risky.
-
write equations for holland and jenkins 1999 u* parameterisation so that I can directly compare with the MITgcm friction velocity run which presumably has been tested thoroughly... This should be less risky than tweaking MITgcm but still could make mistakes.
-
run melt with constant gammaT and compare with constant gammaT MITgcm since these are already set to the same values in both codes. This seems like the least risky as I have already run MITgcm in this setting for the high K=2m^2/s case.
-
So this evening will set off constant gammaT run for 12 hours outputing every timestep 600s.
-
run constant gammaT for 300 days output every 12 hours. (hopefully it will reach a steady state within about 100 days...) if tomorrow is running ok maybe restart from a checkpoint and decrease output frequency.
-
tomorrow run necessary mitgcm simulations. What should i do about timestep? should i try MITgcm with a timestep of 600s... or leave at 30s specified by Ben?
-
tomorrow start thinking about writing the other code for fric melt param
-
if all is going well add in coriolis
-
turn off slope limiters and investigate baroclinic instability. Do we also see this in the melt runs?
-
work out what the averaging for u* and T,s fields is. pretty sure they refer to horizontal averaging in the comments...
MAINTAINERS: fix bad file pattern
Testing 'parse-maintainers' due to the previous commit shows a bad file pattern for the "TI VPE/CAL DRIVERS" entry in the MAINTAINERS file.
There's also a lot of mis-ordered entries, but I'm still a bit nervous about the inevitable and annoying merge problems it would probably cause to fix them up.
The MAINTAINERS file is one of my least favorite files due to being huge and centralized, but fixing it is also horribly painful for that reason.
Signed-off-by: Linus Torvalds [email protected]
Added setup script for Possess Block
It's a humongous pain to set up. Like, absolutely horrible. Nothing about it works like you would expect. Truly terrible setup experience, 0/10. So it's been changed.