Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 22 13:32
    niemyjski commented #66
  • Jun 22 13:31
    niemyjski commented #76
  • Jun 22 13:31
    niemyjski closed #76
  • Jun 22 13:30
    niemyjski closed #94
  • Jun 22 13:30
    niemyjski commented #94
  • Jun 22 13:30
    niemyjski commented #89
  • Jun 22 13:29

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jun 22 13:28
    dependabot[bot] commented #101
  • Jun 22 13:28
    niemyjski closed #101
  • Jun 22 13:28

    niemyjski on workspaces

    (compare)

  • Jun 22 13:28
    niemyjski closed #95
  • Jun 17 19:32
    mpawelski commented #31
  • Jun 17 13:46
    niemyjski commented #31
  • Jun 17 12:35
    dependabot[bot] labeled #101
  • Jun 17 12:35
    dependabot[bot] opened #101
  • Jun 17 12:35

    dependabot[bot] on npm_and_yarn

    Bump postcss from 7.0.35 to 7.0… (compare)

  • Jun 16 21:57
    mpawelski commented #31
  • Jun 16 14:14

    niemyjski on v2.0.0-alpha3

    (compare)

  • Jun 16 12:35
    niemyjski transferred #211
  • Jun 16 07:59
    1301536601 commented #211
Sander Rijken
@srijken
and then you figured it out :)
Blake Niemyjski
@niemyjski
yeah
Eric J. Smith
@ejsmith
we should use the timer pattern that we are using in the in memory queues and other things from foundatio
where the timer only fires exactly when it needs to.
Blake Niemyjski
@niemyjski
eh
once every 60 seconds
not really worried about that...
Sander Rijken
@srijken
and the only thing it does is try to dequeue an event
Blake Niemyjski
@niemyjski
ooh crap just thought of something
Sander Rijken
@srijken
it’s not doing a ton of work
Blake Niemyjski
@niemyjski
if we are waiting 60 seconds
then shutting down randomly
become a bigger issue
as you just lost a minute of data
Sander Rijken
@srijken
other thing.. I think .Send() needs to be wrapped in a try{} catch{}?
Eric J. Smith
@ejsmith
it should send before dispose
which will put them in the queue
if they have persistent queues… they will be saved.
Sander Rijken
@srijken
you don’t want exceptions to break out of the timer event.. it’ll crash the app hard
Eric J. Smith
@ejsmith
yeah
we have to be super careful to not crash people’s apps. :-)
Blake Niemyjski
@niemyjski
no
they are in memory queues inside of the plugin
and will sit there for up to 1 minute
Eric J. Smith
@ejsmith
yes, I know… but dispose gets called.
Sander Rijken
@srijken
yeah but if you send it from the dispose, you can send it earlier
Blake Niemyjski
@niemyjski
hmm
Eric J. Smith
@ejsmith
it needs to submit any pending in the dispose
Blake Niemyjski
@niemyjski
yeah
Sander Rijken
@srijken
except when dispose doesn’t get called..
Blake Niemyjski
@niemyjski
good call
Sander Rijken
@srijken
but then it just sucks anyway
Eric J. Smith
@ejsmith
in that case we are screwed anyway
Blake Niemyjski
@niemyjski
but will dispose actually get called on shutdown
might be wayyyyy too late
Eric J. Smith
@ejsmith
I think it will be ok… but try it.
and it would be nice if we did a quick benchmark on calling gethashcode on complex events.
Sander Rijken
@srijken
we also need to add that to the testcase to make sure it even works :D
Eric J. Smith
@ejsmith
because there are discussions about making architectural decisions based on this being expensive and I don’t believe in making architectural decisions based on milliseconds. :-)
Sander Rijken
@srijken
and without measuring in the first place
Blake Niemyjski
@niemyjski
yeah
Eric J. Smith
@ejsmith
exactly
Blake Niemyjski
@niemyjski
I’ll add a test to the master branch
and then pull it into this one
I’ll make that a toodo
Sander Rijken
@srijken
ex collegue used to do that.. optimize for optimal reuse (and then it doesn’t get reused), and for optimal speed, when speed isn’t the issue there
Blake Niemyjski
@niemyjski
yeah
I know
I’ll write a test and add some good test cases
Sander Rijken
@srijken
especially the first thing leads to code more complex than necessary