1,887,232 events, 1,044,112 push events, 1,547,939 commit messages, 90,599,734 characters
"7:05pm. http://www.fsharpreactivepatterns.com/
Oh, there are F# examples here. Great.
Ok, since I found this, let me just try out whether I can abort an actor.
https://alvinalexander.com/scala/how-to-stop-akka-actors-in-scala-gracefulstop-poisonpill/
This is the Scala version, but there are ways it seems...
There are several ways to stop Akka actors. The most common ways are to call system.stop(actorRef) at the ActorSystem level or context.stop(actorRef) from inside an actor.
There are other ways to stop an actor:
* Send the actor a PoisonPill message
* Program a gracefulStop
Ok...
open System
open Akka.FSharp
let myActor (mailbox: Actor<_>) =
let rec loop () = actor {
let! message = mailbox.Receive ()
// Handle message here
return! loop ()
}
loop ()
[<EntryPoint>]
let main argv =
let system = System.create "system" <| Configuration.load ()
let actorRef = spawn system "myActor" myActor
system.Stop(actorRef)
0
This typechecks. Good. I am set. The F# examples actually look quite nice unlike the C# ones.
Still, I am going to have to make sure that this frees up the resources in use.
open System
open Akka.FSharp
let myActor (mailbox: Actor<_>) =
use d = {new IDisposable with member _.Dispose() = printfn "Disposing"}
let rec loop () = actor {
let! message = mailbox.Receive ()
// Handle message here
return! loop ()
}
loop ()
[<EntryPoint>]
let main argv =
let system = System.create "system" <| Configuration.load ()
let actorRef = spawn system "myActor" myActor
system.Stop(actorRef)
Console.ReadKey()
0
Let me try this out.
..."Disposing" get printed. Hell yes.
...No this is not enough.
...Ah, crap Disposing gets triggered even if the actor dies.
Forget disposal. Can I terminate it in the middle even if its busy?
open System
open Akka.FSharp
let myActor (mailbox: Actor<_>) =
let rec loop () = actor {
let! message = mailbox.Receive ()
printfn "Received message: %s" message
while true do
printfn "..."
Threading.Thread.Sleep(1000)
return! loop ()
}
loop ()
[<EntryPoint>]
let main argv =
let system = System.create "system" <| Configuration.load ()
let actorRef = spawn system "myActor" myActor
actorRef.Tell("Hello",null)
Console.ReadKey()
system.Stop(actorRef)
printfn "Stopping..."
Console.ReadKey()
0
...
Received message: Hello
...
...
...
Stopping...
...
...
...
Unfortunately, not.
7:30pm. I kind of like the F# look and feel of things, but if this cannot work, nothing will. Actor systems cannot give me what I want. They are just more verbose versions of reactive combinators. But rather than coming to that conclussion now, I want to at least put in a full day of study into it first.
Rather than strictly having an async receive or not, what I could do is check for 1s whether a message has been received and then check the token and raise. That would do the trick.
http://fsprojects.github.io/Cricket/index.html
This is the FSharp.Actor Don Syme mentioned in a post 5 years ago.
https://github.com/akka/akka-meta/blob/master/ComparisonWithOrleans.md
The guiding question for Orleans is “what is the default behavior that is most natural and easy for non-experts?” The second question is then how the expert can make their own decision.
Akka’s guiding question is “what is the minimal abstraction that we can provide without compromises?” This means that “good default” for us is not driven by what users might expect, but what we think users will find most useful for reasoning about their program once they have understood the abstraction—familiarity is not a goal in itself.
I like the second philosophy better.
7:55pm. Ok, I have decided. Forget actors. They are not what I am looking for after all.
What I need to do is write my own receive methods if needed to cancel the threads.
Getting more familiar with cancellation will be my top priority.
8pm. Neither actors, nor processes are the key.
The cancelation tokens are. But I need to take heart and dive deeper into them. The time for that is not past 6pm like now. I need to do it when I am fresh.
It is no wonder I got impatient.
It is fine if I take a bunch of time for this. Just take it easy and focus on the task at hand tomorrow.
8:10pm. https://groups.google.com/forum/#!topic/fsharp-opensource/KW-jNu5h3_o
Sorry for being slightly off-topic, but I would like to share something I wish I discovered before: CML/Hopac.
Interesting thread.
https://github.com/Hopac/Hopac/blob/master/Docs/Programming.md
The syntax of this is just like F#.
...Ah, it is a Concurrent ML style library for F#.
8:25pm. This thing really does seem worth studying, but I really should leave it for later. Let me do that.
5/16/2020
7:45am. I am up.
8am. It is chilling time. I really was quite strained last night. As the entries say, my priority will be to study cancellation tokens more and implement my own cancellable receive methods in ZeroMQ.
My mental state really was not right during the second half. I was in a high energy state, but what I needed was a more explorative, low energy state to get through the hurdle in front of me. I am really proud of the Avalonia examples.
...Not a peep as expected on SO. Well, the code samples that I've pasted are nearly 200 lines, so I am not surprised people are not interested. That plus despite existing for years, Avalonia only had like 64 questions when I started. It is pretty much barren.
8:05am. What I want today is give my mind some time to recover from the excesses of the past two weeks. Sure, I'd rather it be like this than February-April, but I can't make this my standard pace.
So today I will have two goals:
-
Go with the cancellation token plan. Play more with them and ZeroMQ. Find out why cancelling that
Asyncreceive method causes the task to fault. Look at the source. Then fix the problem. Make a blocking receive that can be cancelled. -
Study the Hopac library.
https://github.com/Hopac/Hopac/blob/master/Docs/Programming.md
The stuff here is new to me, and I should be getting familiar with it.
8:10am. Forget actors. I always try to get into them, and I always find reasons why I do not need them. As an architecture, they do make more sense than using tasks for things, but somehow I am not actually held back by sitting on lesser fundamentals.
8:15am. Let me chill for a while and then I'll go through that guide. I've only skimmed it yesterday, but Hopac seems like my kind of thing. Really, there is so much to do. So much to study.
ZeroMQ, reactive combinators, Avalonia, .NET concurrency and networking, and now this. How long will it take me to master all of this? Definitely a few months at least. But I like this. I have a definite goal in front of me.
It is not like in February when I tried the ASP.NET book and had no idea what the Tic Tac Toe app did. I still don't by the way, even though it would be trivial for me to do that kind of program on my own now."
bunch of crap
Cleaned up a lot of shit, most notably in coresequencemanager (652 lines down to 267). Added comments to make future troubleshooting easier.
Added environments for missing levels.
Disabled environment changes for many indoor places to hopefully help with visibility (should especially help with night).
Removed unused code and files.
Removed a (now unused) package to save memory.
Added Breakin' Feds to the exceptions list, and removed White House from said list, be careful loading this with the mod active as you may have out of memory crashes.
Changed mask for ceiling detection to hopefully a more consistent one (thanks Hoxi).
Got the input search working. Fuck you input search.
sched/core: Implement new approach to scale select_idle_cpu()
Hackbench recently suffered a bunch of pain, first by commit:
4c77b18cf8b7 ("sched/fair: Make select_idle_cpu() more aggressive")
and then by commit:
c743f0a5c50f ("sched/fair, cpumask: Export for_each_cpu_wrap()")
which fixed a bug in the initial for_each_cpu_wrap() implementation that made select_idle_cpu() even more expensive. The bug was that it would skip over CPUs when bits were consequtive in the bitmask.
This however gave me an idea to fix select_idle_cpu(); where the old scheme was a cliff-edge throttle on idle scanning, this introduces a more gradual approach. Instead of stopping to scan entirely, we limit how many CPUs we scan.
Initial benchmarks show that it mostly recovers hackbench while not hurting anything else, except Mason's schbench, but not as bad as the old thing.
It also appears to recover the tbench high-end, which also suffered like hackbench.
Tested-by: Matt Fleming [email protected] Signed-off-by: Peter Zijlstra (Intel) [email protected] Cc: Chris Mason [email protected] Cc: Linus Torvalds [email protected] Cc: Mike Galbraith [email protected] Cc: Peter Zijlstra [email protected] Cc: Thomas Gleixner [email protected] Cc: [email protected] Cc: kitsunyan [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar [email protected] Signed-off-by: Raphiel Rollerscaperers [email protected]
"1:25pm. https://mangadex.org/chapter/793187/11
Rebuild World is something I'll look forward to from here. It has my interest now. I like its atmosphere.
2:15pm. Done with chores. Let me read another chapter or so of this and then I'll resume the Hopac guide.
2:55pm. That was fun. I'll leave the latest two for later. Let me resume the Hopac guide.
3:05pm.
let rec fib n = Job.delay <| fun () ->
if n < 2L then
Job.result n
else
fib (n-2L) <&> fib (n-1L) >>- fun (x, y) ->
x + y
let x = Diagnostics.Stopwatch.StartNew()
printfn "%i in %A" (run (fib 17L)) x.Elapsed
With fib 18L an exception gets thrown when using <&> so I can't really test the speedup compared to <*>.
The exception is so long that it does not fit in the terminal.
Let me do it in a debugger.
...Yeah, it is stack overflow. Ok.
3:10pm. I am still not sure what Delay exactly does. I guess I'll leave that for later.
3:15pm. Just why is VS still so bad at giving me the types of operators.
https://github.com/Hopac/Hopac/blob/master/Docs/Programming.md#programming-with-alternatives
Let me move to this section. I'll skim the merge sort stuff.
Since I am 2/3rds of the way in already let me get this. I'll also get something on .NET concurrency. I saw a book by Daffy namedropped in the past.
It is from 1999. That is pretty old.
There is a .NET concurrency book by Terrell.
Of the documentation you can find it is pretty shaky, however, for more information on APM, see Jeffery Richter's brilliant book CLR via C# or Joe Duffy's comprehensive Concurrent Programming on Windows.
So this is what it was.
...Ah, forget it. Let me just get the book by Terrell.
https://docs.microsoft.com/en-us/dotnet/standard/async
Here APM is mentioned, but that is legacy by now. Still, even though I have a grasp of the async monad, there are still rough spots so I'll keep Terrell's book as a reference.
I know nothing about this - well, apart to avoid it.
...Let me also get the book by Richter. It is 900 pages, so I am not going to be reading it, but I'll take a peek. Whether it be reactive combinators or channeling combinators, I want to know how to implement them under the hood. Just like I would not want to do UIs directly, so I would not use primitives directly, but for me to consider myself skilled, I should know to implement the abstractions I am using under the hood.
3:40pm. Damn, I got the .epub. I am not sure if the reader I am using is really shitty, but I haven't been able to find anything good for those. They are only suitable for fiction.
...Yeah, the PDF is much nicer. Well worth the extra hard drive space.
3:45pm. Judging by the TOC, I already know most of the stuff in it, but there is a bunch I might be interested in. I'll leave it for later. Let me get back to the Hopac guide. Let me get that out of the way first.
3:50pm. https://github.com/Hopac/Hopac/blob/master/Docs/Programming.md#choose-and-after
He'll sketch out a GUI example here. This stuff is interesting - it does feel more elegant than reactive combinators. Maybe I should be using this. Though I do not understand it well enough to determine whether they could be a wholesale replacement for reactive combinators.
4:10pm. https://www.demystifyfp.com/fsharp/blog/concurrent-programming-in-fsharp-using-hopac-part-1/ https://news.ycombinator.com/item?id=12571904
I am looking up some Hopac threads on HN. Interesting comments.
4:25pm. I am super distracted right now. I should not have gone for those books or looked at HN threads. I am just daydreaming now.
Focus me, focus. Finish the guide. There is like only a fifth left to go.
4:45pm. I am really skimming this last section. It feels like this part of the guide is going too fast for me. I really need a more in depth guide to this. I am not sure what to think about this.
let start = Job.delay <| fun () ->
let locks = Dictionary<int64, Queue<Ch<unit> * Alt<unit>>>()
let s = {unique = 0L; reqCh = Ch ()}
(Job.server << Job.forever)
(Ch.take s.reqCh >>= function
| Acquire (lock, replyCh, abortAlt) ->
match locks.TryGetValue lock with
| (true, pending) ->
pending.Enqueue (replyCh, abortAlt)
Job.unit ()
| _ ->
Alt.choose [Ch.give replyCh () ^-> fun () ->
locks.Add (lock, Queue<_>())
abortAlt]
| Release lock ->
match locks.TryGetValue lock with
| (true, pending) ->
let rec assign () =
if 0 = pending.Count then
locks.Remove lock |> ignore
Job.unit ()
else
let (replyCh, abortAlt) = pending.Dequeue ()
Alt.choose [Ch.give replyCh ()
abortAlt ^=> assign]
assign ()
| _ ->
// We just ignore the erroneous release request
Job.unit ()) >>-. sI really don't want to think about this right now. Let me finish the guide. I am satisfied with understanding the first half. I'll go for the Concurrent ML book next. It feels like this part is just covering it; like a proof that whatever the language can do, the F# library can do it as well. Because in isolation, the above example is just so poorly motivated.
4:55pm. The Hopac library is so extensive. It is a real hidden gem. Let me check out the book.
The guide was roughly 40-50 pages long, but the book is 325. So I'll take my time studying it.
5:10pm. Actually, it is interesting that Rx came 10 years after the work done on CML. I'd figured that Rx would have been simple to produce, but I guess not.
5:25pm. 19/325.
Interactive systems, such as graphical user interfaces and window managers, are the primary motivation of much of the work described in this book, and the author believes that they are one of the most important application areas for concurrent programming.
Interesting that he specifically singled out UIs. I was thinking that that Rx was a better fit, but who knows.
Well, I do not particularly mind sinking more time into this. My sense is that I'll continue using Rx, but I might as well get familiar with other options.
5:40pm. Let me take a break here. I am not done yet.
5:50pm. Let me resume. It is time for the last spurt. I'll do it for another 30m and then I'll call it a day. Since I am just reading books today, I am definitely not in the mood for an 8pm session.
5:55pm. 31/325. Maybe I should just stop now. I can't really properly focus on this. It is kind of boring, but I should really pay attention to it.
6pm. 32/325. Ah, so this is the producer consumer process. There were some wildly out of place functions in the F# Rx bindings that I had no idea what they were supposed to be doing.
...Well, this is just a brief description.
Let me stop here. I do not feel like going any further. I know I said I would do 30m, but forget that.
This is not like programming where I get into it. When I am in passive mode my limit is 6pm.
What I will do tomorrow is continue this book. Even if I have to skim it, I'll read it cover to cover to get a gist of it. Right now, I am still not sold on the utility of this versus Rx and I have so much on my plate, so I do not want to spend more than a few days on this.
I just want to learn enough to understand what it would be useful for."
Directory Fuckery To Make Shit Work Again
- TODO: god what a mess, look into node.js directory structure https://techsparx.com/nodejs/howto/express-folder-structure.html maybe
DataType foundations re-implemented. Can guess from this convoluted unclear non-unequivocal php scripter's fantasy the type of the data. I must say, that it's outrageously stupid, that with this control byte data type definition the scripters "designed" implicitly allows for two different ways of defining map types. One is [0b111X_XXXX] and the other is [0b000X_XXXX, 0b0000_0000], where both resolve to fantasy 7 with that fucking retarded logic, though are not equal.
Signed-off-by: Adam Rocska [email protected]
server,gossip/resolver,cli: gate the SRV lookups under a new flag
In v20.1 the bootstrap resolver code was changed to prefer SRV records, if present in DNS, to regular A/AAAA records.
This change turned out to be a bit too immature as multiple defects were found in succession:
- the code was improperly using records with port 0.
- it would crash if DNS was not available.
- it does not follow the regular SRV naming rules, where
a service should be named as
_svcname._tcp.xxxx. - it is not able to re-perform the SRV lookup after the node has started up, if it takes a while for the rest of the cluster to catch up.
Some of these issues have since been fixed, but others remain open.
In order to not let users experience trouble with this feature
until it matures a bit, this patch introduces a new CLI flag
--experimental-dns-srv which defaults to false.
Also this patch adds the missing test for the join resolution.
Release note (backward incompatible change): CockroachDB v20.1
introduced a new rule for the --join flag causing it to prefer SRV
records, if present in DNS, to look up the peer nodes to join. This
feature is experimental. However, it is also found to cause disruption
in in certain deployments. To reduce this disruption and UX surprise,
the feature is now gated behind a new command-line flag
--experimental-dns-srv which must now be explicitly passed to
cockroach start to enabled it.
Add imprint for idiots at T-Online
'Oh, we do not accept emails from you because you have no imprint' mother fuckers
add reason hello world fetching
- Great being forced to decode the api response
- Variants are a very expressive, love the exhaustive checks
- Reason's modules design is a blessing, wonder how private functions work.
- Don't like using callbacks nor promises. Should look for an effects library with the Task monad.
- Pattern matching is life, should probably implement this commit with typescript and then compare both
Added freeze event.
Its kinda shit with how its written? This may be a horrible horrible idea but yknow what it performs fine so far. Also added the relativeAllCOllumnMove thing which was neetded.
i hate my entire life because of this stupid mistakes
implemented me and Baddy's SEXY GENSEC NINJA REDUX!!!!!!
- the Gensec Ninjas have received a full facelift!!!! I don't quite remember the details but they look AWSOMESAWCE
- FUCK YOU, YOU'RE NOT GETTING SCREENSHOTS! LOOK AT THEM YOURSELF!
- added shotgun ninja, quintuple J.