Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 20:47
    IgorFedchenko commented #4085
  • 20:46
    IgorFedchenko commented #4085
  • 15:09
    IgorFedchenko commented #4085
  • 11:24
    Kenji-Tanaka commented #3887
  • 10:45
    nagytech edited #4086
  • 10:45
    nagytech synchronize #4086
  • 10:43
    nagytech opened #4086
  • 09:00
    Horusiath commented #4077
  • 06:31
    Aaronontheweb commented #4085
  • 06:28
    Aaronontheweb commented #4085
  • 06:24
    Aaronontheweb commented #4085
  • Dec 07 11:49
    IgorFedchenko commented #4085
  • Dec 07 10:31
    IgorFedchenko commented #4085
  • Dec 07 08:36
    IgorFedchenko commented #4085
  • Dec 06 20:57
    IgorFedchenko commented #4085
  • Dec 06 20:32
    IgorFedchenko commented #4085
  • Dec 06 20:01
    IgorFedchenko commented #4085
  • Dec 06 19:55
    IgorFedchenko commented #4085
  • Dec 06 16:22
    Aaronontheweb labeled #3997
  • Dec 06 16:22
    Aaronontheweb closed #3997
Aaron Stannard
@Aaronontheweb
@haighis is there anything else I need to do for Travis-CI support?
Geert Van Laethem
@GeertVL
Ok I jump into the code. Tx mate
Aaron Stannard
@Aaronontheweb
you're welcome
Kamil Wojciechowski
@aph5nt
Hi, i have got one question. Is it possible to distinguish when a persisten view is restoring its state and then its receiving new events ?
in my case, the persistance view is responsible for sending messages to a signalR actor
i dont want to spam UI with signalR messages while view will be rebuilding its state
Bartosz Sypytkowski
@Horusiath
@aph5nt I guess you're not talking about standard C# API?
Kamil Wojciechowski
@aph5nt
right, forgot to mention
F# api :D
but atm it does not make any difference for me, it can be about C# api
Bartosz Sypytkowski
@Horusiath
hmm, actually it's not possible for persistent views. What you call receiving new events and restoring the state is undistinguishable in their case. You could use their properties however.
Kamil Wojciechowski
@aph5nt
yhm, oki
Bartosz Sypytkowski
@Horusiath
sorry my mistake
there is no such property
Bartosz Sypytkowski
@Horusiath
in C# you have a property IsPersistent which can be used to identify if message has come from journal or not, but in general there is no such concept like receiving new events in views, because they are always recovering from journal (even on updates)
Anthony Brown
@bruinbrown
Is it possible to run the tests for just one project?
Aaron Stannard
@Aaronontheweb
@bruinbrown on the commandline?
or in visual studio?
and are these the multi-node tests or the full-blown ones?
err, the "normal" ones rather
Anthony Brown
@bruinbrown
Either, xunit needing a VS package for a test runner seems a bit wat, I was wondering if there was anything in the build script to run it
Aaron Stannard
@Aaronontheweb
@bruinbrown not offhand - but I'd accept a PR for the FAKE script to make that easier
need to help out our friends on Mono, right? ;)
@rogeralsing btw, got some love from Vaugh Vernon today: https://twitter.com/VaughnVernon/status/632235346588143617
Roger Johansson
@rogeralsing
oh, nice!
Aaron Stannard
@Aaronontheweb
I want to read his book
Andrew Skotzko
@skotzko
that is awesome
@rogeralsing saw your msg from earlier. currently, ready label is the issues assigned for the next release (corresponds to that column in waffle)
Roger Johansson
@rogeralsing
ah ok
Roger Johansson
@rogeralsing
@Horusiath I've made some fixes to Migrant, now its "just" 5 times slower than Json.NET.. but its a lott better than those 24 times difference that it was at first
Bartosz Sypytkowski
@Horusiath
if you can make it 5x faster in hour of work, I feel a little afraid what you end up with on Monday :p
I've almost finished with the event adapters for akka.persistence, but I'm missing some of the HOCON methods, that are present in the JVM version
Roger Johansson
@rogeralsing
Ok, any specifics ? Ill try to add them
Bartosz Sypytkowski
@Horusiath
can we somehow achieve behavior similar to this? ConfigObject.unwrapped
actual line of Scala code I need to translate is config.getConfig(path).root.unwrapped
ok, sorry I see it in our impl :P
Roger Johansson
@rogeralsing
var unwrapped = ConfigurationFactory.ParseString(hocon).Root.GetObject().Unwrapped;
its a bit hidden :)
and do note, that the values, that is, strings and arrays and such, are still HoconValues that you have to do .GetString or GetInt on.. Im not sure if that is the case in the scala version
Bartosz Sypytkowski
@Horusiath
test suite will show ;>
Roger Johansson
@rogeralsing
The way that Akka handles serialization is really stupid, first of all, it always requires a byte array result, even if the backing serializer can write directly to a stream. and secondly, we always serialize individual messages, there is no way to do batch serialization.
Bartosz Sypytkowski
@Horusiath
there are many lessons to be learned
Roger Johansson
@rogeralsing
turns out that when using batch serialization, migrant is 4 times faster than json.net, but we cannot leverage that due to how jvm Akka handles serialzation
Bartosz Sypytkowski
@Horusiath
hmm, but this could be potentially used in one case in persistence (and maybe in remote)
Arjen Smits
@Danthar
@rogeralsing wouldn't sending multiple messages in one batch, cause a conceptual disconnect higher up the stack? Cause instead of sending 1 messages your sending multiple messages. So wouldn't that also force you to change the way how message delivery guarantee's are handled ? (not conceptually perhaps, but technically)
Aaron Stannard
@Aaronontheweb
@Danthar is correct - it may be less performant to do things 1 at time at the framework level, but it makes it easier to have guarantees all the way down the stack
Roger Johansson
@rogeralsing
@Horusiath got Migrant down to 3 times slower than json.net.. sent them a PR for that
if we can get it to twice as slow, I think we should give it a go
Bartosz Sypytkowski
@Horusiath
agree
Bartosz Sypytkowski
@Horusiath
I'm finishing porting event adapters