https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • hmm, not familiar with those, what api?
    a
    hmm, not familiar with those, what api?
  • well, you would probably have to roll out your own, but, my basic understanding of this app is its going to make 20 requests to a url (with a change in some param) and process the data?
    b
    well, you would probably have to roll out your own, but, my basic understanding of this app is its going to make 20 requests to a url (with a change in some param) and process the data?
  • yeah
    a
    yeah
  • so i would have a queue / pool... you kick off, say 3, request, when they finish they call a "processData", at the end of that processData it calls a "checkQueue" which would kick of another...
    b
    so i would have a queue / pool... you kick off, say 3, request, when they finish they call a "processData", at the end of that processData it calls a "checkQueue" which would kick of another...
  • ahh, i'm basically doing that already
    a
    ahh, i'm basically doing that already
  • the next result can't be requested until the previous requested has returned a result
    a
    the next result can't be requested until the previous requested has returned a result
  • but you are doing something in a timer, which i dont quite understand
    b
    but you are doing something in a timer, which i dont quite understand
  • ahh, i get what you're saying, you're saying do it as a response to a successful result rather than "keep checking" for a successful result
    a
    ahh, i get what you're saying, you're saying do it as a response to a successful result rather than "keep checking" for a successful result
  • exactly, the "done" (of the http) is what kicks off the next, not a timer checking
    b
    exactly, the "done" (of the http) is what kicks off the next, not a timer checking
  • cool! i'll try that!
    a
    cool! i'll try that!
  • thanks!
    a
    thanks!
  • np - ill knock up a simple example tomorrow if you dont get anywhere - mainly just to make sure there isnt threading issues introduced by core/http
    b
    np - ill knock up a simple example tomorrow if you dont get anywhere - mainly just to make sure there isnt threading issues introduced by core/http
  • a

    https://cdn.discordapp.com/attachments/565569107701923852/1094721849646133408/image.png▾

  • i get rid of timers and the app is angry 😄
    a
    i get rid of timers and the app is angry 😄
  • ahh, it is unhappy with my use of timer.delay elsewhere
    a
    ahh, it is unhappy with my use of timer.delay elsewhere
  • <@385014891750096896> to follow up from yesterday, i got rid of timers and the app seems to just get "stuck" for no "obvious" reason
    a
    @bright-gpu-74537 to follow up from yesterday, i got rid of timers and the app seems to just get "stuck" for no "obvious" reason
  • I'm not sure if its due to threads but tracing everything, it all seems correct
    a
    I'm not sure if its due to threads but tracing everything, it all seems correct
  • interestingly, moving the app to something like kha and it crashes
    a
    interestingly, moving the app to something like kha and it crashes
  • Oh interesting, on hashlink the app blocks but it doesn't stop working
    a
    Oh interesting, on hashlink the app blocks but it doesn't stop working
  • if a timer is async and i call a sync http request in it - shouldn't that be non-blocking?
    a
    if a timer is async and i call a sync http request in it - shouldn't that be non-blocking?
  • The HaxeUI core's code for *Button.onMouseUp* contains a commented ``event.cancel();``. Is it remains of a debugging session, or maybe old code not removed ? I'm asking in case it's a bug and buttons are supposed to cancel the clicking event :P
    e
    The HaxeUI core's code for Button.onMouseUp contains a commented ``event.cancel();``. Is it remains of a debugging session, or maybe old code not removed ? I'm asking in case it's a bug and buttons are supposed to cancel the clicking event :P
  • ahhh, dang, yeah
    a
    ahhh, dang, yeah
  • awkward situation where every target breaks differently but none of them have the behaviour
    a
    awkward situation where every target breaks differently but none of them have the behaviour
  • im actually finding something really interesting with haxe http: ive setup a request queue and it _always_ pauses on the 8th request and hangs... debugging it now, but its really hard to grep the code
    b
    im actually finding something really interesting with haxe http: ive setup a request queue and it always pauses on the 8th request and hangs... debugging it now, but its really hard to grep the code
  • that is pretty much *exactly* what was happening to me
    a
    that is pretty much exactly what was happening to me
  • it was freezing on the 4th request
    a
    it was freezing on the 4th request
  • its something to do with the socket i think
    b
    its something to do with the socket i think
  • i get the request data but for some reason it just "stops" after that point, no obvious reason for the issue
    a
    i get the request data but for some reason it just "stops" after that point, no obvious reason for the issue
  • Sure, thank you !
    e
    Sure, thank you !
  • it might be worth mentioning that *some* of the data can be read, it just silently gets stuck at some point
    a
    it might be worth mentioning that some of the data can be read, it just silently gets stuck at some point
1...162816291630...1687Latest