Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 16 22:15
    Aaronontheweb synchronize #3889
  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3986
  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump NUnit from 3.6.1 to 3.12.0… (compare)

  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3985
  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump FsCheck.Xunit from 2.9.0 t… (compare)

  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3983
  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump ApprovalUtilities from 3.0… (compare)

  • Oct 16 21:00
    dependabot-preview[bot] edited #3985
  • Oct 16 21:00
    dependabot-preview[bot] edited #3986
  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3982
  • Oct 16 21:00
    dependabot-preview[bot] synchronize #3987
  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump FsPickler from 5.2.0 to 5.… (compare)

  • Oct 16 21:00

    dependabot-preview[bot] on nuget

    Bump LightningDB from 0.9.8 to … (compare)

  • Oct 16 21:00
    dependabot-preview[bot] edited #3982
  • Oct 16 21:00
    dependabot-preview[bot] edited #3983
  • Oct 16 21:00
    dependabot-preview[bot] edited #3987
  • Oct 16 20:59
    dependabot-preview[bot] edited #3982
  • Oct 16 20:59
    dependabot-preview[bot] edited #3985
  • Oct 16 20:59
    dependabot-preview[bot] edited #3987
  • Oct 16 20:59
    dependabot-preview[bot] edited #3986
Bartosz Sypytkowski
@Horusiath
(I'm talking about reentrancy right now)
Natan Vivo
@nvivo
yes, that's why reentrancy should be handled by message passing, not a custom mechanism on top of async/await
the reason async/await exists is just to make syncrhnous code non-blocking, it was never intended to create a notion of parallelism
IMO, there is no need to change that because Akka already supports PipeTo very well
Bartosz Sypytkowski
@Horusiath
while about your quote - persistent actors in fact stash incoming messages while in recovery phase, but this is destructive when used in some routing strategies
Natan Vivo
@nvivo
the quote is from Roland Kuhn, just to be clear
Bartosz Sypytkowski
@Horusiath
yep, I've read the thread ;)
Roger Johansson
@rogeralsing
I think our "Feasiblity" bouble is quite small here due to the implicit context. so that limits our options

Roger Just unlocked Pointy Haired Boss acheivement - posting nonsense venn diagrams

:)
Arjen Smits
@Danthar
lol
Maybe some UML diagrams would be better
:P
Roger Johansson
@rogeralsing
dude you have no idea how much UML I have done in my days :) spent a few years drawing sequence diagrams at my last job...
Arjen Smits
@Danthar
hehe
So should be no problem then!
^^
Roger Johansson
@rogeralsing
read the thread
Natan Vivo
@nvivo
Haha
Natan Vivo
@nvivo
was thinking about all of this ... one problem with "tasks" in c# is that it mixes the idea of a promise with the execution of code asyncrhonously
I heard a typesafe guy saying the same thing about java futures, so there is probably a performance reason there
if the future value was to be separated in an IPromise<T> for example, I guess async/await wouldn't be so mysterious
Stefan Sedich
@stefansedich
@rogeralsing decided to clean up the whole Event namespace.
I assume we have the R# rule for comment all protected/public? it really gets annoying for obvious methods. I have found myself hating myself :)
also there are one or two Obsolete still in Logging, is it safe for me to kill them now?
Natan Vivo
@nvivo
This message was deleted
Stefan Sedich
@stefansedich
I don't like seeing deleted messages :D
too curios
I wish they just removed it totally.
Natan Vivo
@nvivo
haha
it was the secret of the universe, life and everything
Stefan Sedich
@stefansedich
I knew it!
Natan Vivo
@nvivo
@rogeralsing just to get this out of the way, went digging into .net await just to see how it captures the context. as far as I can see, there is no difference between the way LogicalCallContext and SyncrhonizationContext flow between executions, except SyncContext is passed by reference and CallContext is cloned (so there is a little bit overhead there as you noticed), but CallContext always flows while SyncContext is optional. That means you're right in using that, there is no reason to try using a SyncrhonizationContext there.
jcwrequests
@jcwrequests
I thought everyone might like a distraction from the TPL discussion and might find thus post interesting. http://blogs.technet.com/b/server-cloud/archive/2015/04/08/microsoft-announces-new-container-technologies-for-the-next-generation-cloud.aspx
Natan Vivo
@nvivo
I found a smell on the actor task scheduler that may account for most problems that are showing, but I'm too tired to investigate today. Boils down to where CallContext is set and restored... I may take a look tomorrow.
Nikita Tsukanov
@kekekeks
@rogeralsing is #907 related only to TestKit? It might be fixed by a custom SynchronizationContext for tests, I think
At least ASP.NET uses SynchronizationContext for the same thing - to keep ThreadStatic ambient context
Roger Johansson
@rogeralsing
Yepp, testkit only
However, if i recall correctly, xunit 1.9 has its own synchronizationcontext (?) might be wrong but i think they do
Nikita Tsukanov
@kekekeks
Hm
Meh, it just wraps original one
Nikita Tsukanov
@kekekeks
@rogeralsing #912 - something like that
Nikita Tsukanov
@kekekeks
BTW, what happened with the build server? Don't see any alive agents here
Stefan Sedich
@stefansedich
After a bad day involving some idiot reversing into my motorbike and causing damage I finally receive my loot for my huge contribution to the CLR (remove a single commented out file).
Microsoft wins the code to loot stakes here.
Roger Johansson
@rogeralsing
Nice! it's like my contrib to NancyFx, removed 1 line
Stefan Sedich
@stefansedich
hahaha