Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 07 16:58
    GlassySundew commented #138
  • Oct 22 13:44
    kevinresol commented #73
  • Oct 22 13:22
    Aidan63 opened #73
  • Oct 18 19:13
    pfoof opened #177
  • Aug 10 00:16
    pzmarzly edited #176
  • Aug 10 00:16
    pzmarzly edited #176
  • Aug 10 00:12
    pzmarzly opened #176
  • Aug 10 00:08
    pzmarzly commented #65
  • Aug 10 00:06
    pzmarzly commented #65
  • Aug 10 00:04
    pzmarzly commented #65
  • Jul 27 22:51
    player-03 commented #167
  • Jul 10 18:40
    back2dos closed #174
  • Jul 10 18:40
    back2dos commented #174
  • Jul 06 01:34
    TheDrawingCoder-Gamer closed #175
  • Jul 06 00:05
    TheDrawingCoder-Gamer commented #175
  • Jul 06 00:03
    kevinresol commented #175
  • Jul 05 23:53
    TheDrawingCoder-Gamer opened #175
  • Jul 05 23:20
    TheDrawingCoder-Gamer opened #174
  • Apr 03 06:33
    TC218 edited #173
  • Apr 03 06:31
    TC218 edited #173
Dan Korostelev
@nadako
Hmm, I'm getting this Updating state in a binding warning. As far as I understand this is to prevent manual dependent state management in favor of Observable.auto, which is totally fine.
But I think I have a situation where it's not really possible and it actually seems fine to do updates like that. I have of course to think about this some more, but in the meantime - is there a way to avoid this warning? Maybe scheduling the update somehow or something?
Kevin Leung
@kevinresol
define yourself as naughty:
-D tink_state_ignore_binding_cascade_because_I_am_a_naughty_naughty_boy
Dan Korostelev
@nadako
but i don't want to:) i want this warning in general, i just don't want in this specific case
Juraj Kirchheim
@back2dos
things run within Scheduler.atomically don't produce the warning
although I'm not so sure that's such a good idea ^^
Dan Korostelev
@nadako
wait why i'm asking in the lix channel, damn :)
Philippe
@elsassph
Changed my mind, Travis can go to hell.
But your tip, @back2dos, seems to work.
Philippe
@elsassph
image.png
oook
Juraj Kirchheim
@back2dos
huh, what's that? ^^
Philippe
@elsassph
Trying to npx lix install haxe XXX in a Github action (with Node)
Juraj Kirchheim
@back2dos
why 3.5.7? :D
Philippe
@elsassph
oooh
Juraj Kirchheim
@back2dos
Is that a typo or an internal build?
Philippe
@elsassph
No it's a typo...
let me try again with 3.4.7 :D
Not a very helpful error message when you ask for a non-existent version :D
Juraj Kirchheim
@back2dos
yeah, it's weird indeed
pretty sure it was better at some point ^^
grepsuzette
@grepsuzette
If you work on a library libxyz, and its unit tests have a dependency, e.g. tink_unittest, you will have a libxyz/haxe_libraries/tink_unittest.hxml. Does that file implies a user of libxyz will also depend upon tink_unittest, or not?
Juraj Kirchheim
@back2dos
during a haxelib install haxelib.json is authoritative ... during a git(hub|lab) install, the haxe_libraries are, but if there's a haxelib.json only the dependencies resulting from that are taken
grepsuzette
@grepsuzette
thanks:)
Kevin Leung
@kevinresol
Should we pack lix into a single executable to "get rid of the nodejs dependency"? https://www.npmjs.com/package/pkg
... for those nodephobics
Juraj Kirchheim
@back2dos
I don't mind ... but that actually creates a new distribution problem ^^
Peter Achberger
@Antriel
Could it run in eval? Then the only issue is Haxe version support. :D
On top of, you know, having to install Haxe before installing Lix. :(
Juraj Kirchheim
@back2dos
it'll have to be uploaded to brew, which AFAIK is a bit of a PITA, and then to choco and whatever Microsoft's package manager thingy is called and of course to all sorts of linux package managers
Rudy Ges
@kLabz
Eval is kinda slow, too. It has to handle compilation at runtime
Which can be noticeable with tink goodies
(also, "lix" is already taken in some(many?) linux package managers °°)
Kevin Leung
@kevinresol
can we "just" host the binary somewhere and instruct people to set up their $PATH manually
Juraj Kirchheim
@back2dos
I suppose ... I guess with github actions one could compile something for windows, linux and mac and add it as an artifact to the release or something
Kevin Leung
@kevinresol
ya iiuc the pkg library can compile the three platforms already
Juraj Kirchheim
@back2dos
ooooh, nice :)
Gabriel Hayes
@piboistudios
Seems like haxeshim is required to build hxcpp with lix. Which is also weird because you have to uninstall some of the files from one of the installs of either lix or shim to install both (because they both try to install the Haxe/haxelib/neko cmds etc)
Juraj Kirchheim
@back2dos
as the friendly red block over at npm indicates haxeshim is deprecated (and now exists only as a haxe library that is compiled into lix)
if some particular thing doesn't work with lix, please open an issue, with as many details as possible on how to repro ;)
Gabriel Hayes
@piboistudios
@back2dos I know. But Lix (latest) failed to compile hxcpp without haxeshim installed as well (it could compile other targets but for hxcpp it was complaining about haxeshim module). I had tried manually deleting the files out of my global npm and installing Lix fresh but it didn't resolve the issue
Ultimately what I had to do was:
Completely uninstall lix (and by this I mean I ran npm uninstall and also deleted the cmds/sh/scripts for Haxe out of npm folder), install haxeshim, delete the cmds/sh/scripts again (Lix tries to install these as well, because as you said it includes haxeshim), then install lix, and it built
Oh I just now saw your second message. I'll open an issue
Ben
@benmerckx
Could this be considered for the next lix release? lix-pm/haxeshim#71
Use case for me: I'd like to update https://github.com/benmerckx/watch to have a runnable main to be able to do lix watch build.hxml
Juraj Kirchheim
@back2dos
it's available in 15.11
the CI via travisci.org is gone and when I try to add the repo on travisci.com, it's not there \o/
image.png
Ben
@benmerckx
Thanks :D It works for me now!