https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    thats fine with me 😅
  • p
    Just need to get all the libraries to move to 
    Run.hx
    and move haxelib away from Neko. Fun fact: the haxelib server still requires Haxe 3
  • b
    We need a better option than Run.hx, there is a very noticeable compilation delay when moving a library from neko to eval (not to mention that haxe compiler updates might break compilation and prevent people just trying to run the library script)
  • b
    *Not so fun fact
  • p
    run.hl
    then. > haxe compiler updates might break compilation and prevent people just trying to run the library script If the run script breaks chances are the library itself is broken too, so...
  • b
    yes, but some libs are mostly about the script, like haxelib itself, or things like hlc-compiler which broke bc of all those abstract transitivity changes
  • b
    tbh tho it wouldn't be too hard to get it to use run.hl, the main problem would probably be that right now there isn't a good way of installing hashlink on most systems apart from building from source
  • b
    but still we shouldn't leave neko broken ;)
  • p
    Indeed, we should delete it :)
  • b
    have you tried 
    -v
    ? or does it happen when compiling the neko byte code?
  • b
    i havent really tried anything tbh, just 
    lime test neko
  • p
    Happens deep in the bowels of the neko generator, so 
    --verbose
    doesn't help. See
  • b
    ah yh that makes sense
  • b
    is that the neko generator or the neko compiler?
  • p
    The thing that actually outputs the final bytecode I think. So compiler, I guess?
  • b
    is there a no compile option for neko? 🤔
  • p
    -D neko-source
    but that seems to give a stack overflow too iirc. And a`-D use-nekoc` but that throws an error in, I assume, nekoc.
  • b
    that's odd
  • p
    -D neko-source
    => stack overflow 
    -D use-nekoc
    => stack overflow in nekoc
  • b
    but at least the behaviour is consistent between haxe's built in neko compiler and nekoc
  • b
    wow
  • b
    i guess we're only on neko 2
  • p
    neko_v1
    errors with 
    /home/zeta/.local/share/haxelib/openfl/9,1,0/src/openfl/display/DisplayObjectContainer.hx:516: characters 68-78 : This integer is too big to be compiled to a Neko 31-bit integer. Please use a Float instead
  • b
    31 bit 😅
  • b
    i would imagine that's not related to the current error?
  • b
    openfl compiles fine to neko 🤔
  • b
    at least on latest
  • p
    Does your project include haxeui?
  • b
    yes
  • b
    has an issue been created yet?
1...123512361237...1687Latest