lix-pm / haxeshim Goto Github PK

Got nekotools not found on windows

I used yarn to install on windows and when I run switchx I got error:

PS C:\WINDOWS\system32> switchx

C:\WINDOWS\system32>"$basedir/C:/Users/kevin/AppData/Local/Yarn/config/global/node_modules/.bin/switchx.cmd"   "$@"
The filename, directory name, or volume label syntax is incorrect.

C:\WINDOWS\system32>exit $?

Seems something's wrong with the absolute path

Trying to build the attached project fails with haxeshim 0.9.0 (installed globally), but works with haxe 3.4.2.

d:\projects\hscwd>haxe build.hxml
Error: ENOENT: no such file or directory, open 'd:\projects\hscwd\build-js.hxml'

hscwd.zip

Targets that have a post-compile haxelib run step fail to compile when calling haxe.cmd of a local lix installation directly (as vshaxe does for its tasks). Somehow it works through npx though:

> node_modules\.bin\haxe.cmd build.hxml
Error: Error: Library hxjava is not installed : run 'haxelib install hxjava'
Called from haxelib/client/Main.hx line 1222
Called from haxelib/client/Main.hx line 1424
Called from haxelib/client/Main.hx line 1456
Called from haxelib/client/Main.hx line 493

> npx haxe build.hxml
haxelib run hxjava hxjava_build.txt --haxe-version 4005 --feature-level 1
javac.exe "-sourcepath" "src" "-d" "obj" "-g" "@cmd"

I thought that it must be calling the wrong Haxelib in the first example, but explicitly putting it into the PATH doesn't help either:

set PATH=node_modules\.bin;%PATH%

So there must be some other difference. Could well be a Windows specific problem.

Related: https://community.haxe.org/t/vscode-with-lix-extension-compile-to-cpp/1826

Lix version 15.4.0.

lix create scope creates an unformatted .haxerc file that looks like this, which is not very friendly to edit manually:

{"version":"3.4.2","resolveLibs":"scoped"}

Running lix use haxe 4.0.0-rc.2 after that formats the file:

{
  "version": "4.0.0-rc.2",
  "resolveLibs": "scoped"
}

Any reason not to just format it to begin with?

1. Have a build.hxml and build_base.hxml on root of your project
2. Add line build_base.hxml to build.hxml to include it to build
3. haxe build.hxml works fine while haxe ../build.hxml called from 1 level deep directory results in error no such file: /path/to/deep/directory/build_base.hxml. Current workaround is cd .. && haxe build.hxml && cd deepdirectory

Currently my project has an hxml at the root folder:

-cp src

and if I go into a subfolder and run haxe --cwd ../ build.hxml it throws me classpath src is not a directory or cannot be read from

An install in a docker container (so no previous haxe installations) and then running haxelib gives me:

/root/haxe/versions/6899468/haxelib: error while loading shared libraries: libneko.so: cannot open shared object file: No such file or directory

Tested with 3.2.1 and nightly.

Is neko a dependency or should haxeshim manage installing it as well?

Lix version 15.4.0.

Adding a lib like -lib random to my build.xml causes this popup to appear in VSCode:

This is not normal, normally it should be an error that looks like this, which is much user-friendlier:

Checking the output channel, it turns out haxeshim actually crashes completely in this case, which explains the error, but shouldn't happen:

Haxe server restart requested: Haxe process was killed

Error message from the compiler:

\Users\Jens\Documents\HaxeFlixelProjects\HaxeRepro\node_modules\lix\bin\haxeshim.js:3492
			throw new js__$Boot_HaxeError(v.map(function(e) {
			^
Error: Cannot resolve `-lib random` because file c:\Users\Jens\Documents\HaxeFlixelProjects\HaxeRepro/haxe_libraries/random.hxml is missing
    at haxeshim_Resolver.resolve (c:\Users\Jens\Documents\HaxeFlixelProjects\HaxeRepro\node_modules\lix\bin\haxeshim.js:3492:10)
    at haxeshim_Scope.resolve (c:\Users\Jens\Documents\HaxeFlixelProjects\HaxeRepro\node_modules\lix\bin\haxeshim.js:3354:24)
    at processData (c:\Users\Jens\Documents\HaxeFlixelProjects\HaxeRepro\node_modules\lix\bin\haxeshim.js:2355:89)
    at reduce (c:\Users\Jens\Documents\HaxeFlixelProjects\HaxeRepro\node_modules\lix\bin\haxeshim.js:2373:7)
    at Socket.<anonymous> (c:\Users\Jens\Documents\HaxeFlixelProjects\HaxeRepro\node_modules\lix\bin\haxeshim.js:2400:4)
    at Socket.emit (events.js:180:13)
    at addChunk (_stream_readable.js:269:12)
    at readableAddChunk (_stream_readable.js:256:11)
    at Socket.Readable.push (_stream_readable.js:213:10)
    at Pipe.onread (net.js:581:20)

Apologies if this is the wrong project for this issue.

I'm trying to use lix locally via npx. This lack of an exit code was causing my vscode build task to "succeed", even when the build fails, which makes for a bad vscode experience - the "problems" tab is not populated, and the debug task is launched anyway, even though the build failed silently.

Observe:

cd /tmp/
mkdir zz
cd zz
echo "{}" > package.json
npm install lix
npx haxe -version  # installs stable / 4.0.2
echo "class Test { asdf }" > Test.hx

Ok, now that we're setup, we clearly expect that Test class not to compile:

npx haxe -cp . Test -js out.js && echo "yay"
# shows build errors
# echos yay, unfortunately

By contrast, haxe itself exits correctly:

haxe -cp . Test -js out.js && echo "yay"
# shows build errors
# Does NOT echo yay

invoking haxe -cp build --run Build will result in Type not found : Build even though Build.hx exists and is valid in build folder.

Downgrading to [email protected] fixes issue.

A few packages might need a recompile + publish to account for this hxnodejs issue:
HaxeFoundation/hxnodejs#102

The current package won't run with nodejs >10.0.0 due to the improper check,
https://registry.npmjs.org/haxeshim/-/haxeshim-0.12.4.tgz

Currently what lix calls download is called install in haxeshim, which might be confusing.

...so it doesn't call Sys.exit() anymore and can be used as an API.

Hello,
I've recently started using openfl's hxp library to generate hxml files. When you use hxp's HXML tool it will wrap any codepaths you specify in quotes, while this works fine with normal haxe with lix you get a 'classpath is not a directory or cannot be read from' error.
The culprit seems to be this line https://github.com/lix-pm/haxeshim/blob/master/src/haxeshim/HaxeCli.hx#L56 as I did some tests and haxe will throw an exception when pass a string surrounded in quotes to readDirectory. My solution for now was to modify hxp to not put quotes around the code paths but it would be nice to have haxeshim match haxe in this case.

Cheers.

Would be awesome to be able to interpolate environment variables to achieve things like these examples:

-js $DIST/client.js
include/server_$TARGET.hxml
-D php-prefix=$PREFIX

• https://github.com/lix-pm/haxeshim/blob/master/src/haxeshim/HaxelibCli.hx#L60 uses haxelib.json's mainClass, but it should be just main based on docs.
• It doesn't consider the default value of "main": "Run".
• It doesn't actually implement running the interpreter.

The first 2 should be easy enough, not sure about actually running it. Would it come down to just callHaxelib(['run', name].concat(args)) or would it be better to call haxe directly?

With haxeshim 0.8.1+, I got the following:
(0.8.0 and below is fine though)

npm run haxe server_tests.hxml
> haxe "server_tests.hxml"

/Users/kevin/Codes/wkphc-hierarchy/node_modules/haxeshim/bin/haxeshim.js:1081
                        if(withNeko.indexOf(_gthis.nekoPath) != -1) {
                                   ^

TypeError: Cannot read property 'indexOf' of undefined
    at addNeko (/Users/kevin/Codes/wkphc-hierarchy/node_modules/haxeshim/bin/haxeshim.js:1081:15)
    at haxeshim_HaxeInstallation.env (/Users/kevin/Codes/wkphc-hierarchy/node_modules/haxeshim/bin/haxeshim.js:1092:4)
    at haxeshim_HaxeCli [as __class__] (/Users/kevin/Codes/wkphc-hierarchy/node_modules/haxeshim/bin/haxeshim.js:815:35)
    at Function.haxeshim_HaxeCli.main (/Users/kevin/Codes/wkphc-hierarchy/node_modules/haxeshim/bin/haxeshim.js:841:2)
    at /Users/kevin/Codes/wkphc-hierarchy/node_modules/haxeshim/bin/haxeshim.js:2147:18
    at Object.<anonymous> (/Users/kevin/Codes/wkphc-hierarchy/node_modules/haxeshim/bin/haxeshim.js:2148:3)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)

Regular haxe will pipe output of -cmd to your terminal, while haxeshim doesn't seem to do so.

tried haxelib run hxcpp but fails with "failed to get content" c:/users/user" when path is "c:/users/user name"

probably a problem with lix but I was using vscode

Currently it's only handled correctly for --wait stdio it seems.

I have 3 html file.
one for dependencies one for global parameters and one for multiple js target.

dependencies.hxml

-lib angular.haxe
-lib gotocore-hx
-lib haxe-crypto
-lib materialize.hx
-lib compiletime
-lib random

global.hxml

dependencies.hxml
-cp src
-dce no

build.hxml

global.hxml
-main admin.AdminApp
-js ../www/public/js/app/AdminApp.js
--next
global.hxml
-main company.CompanyApp
-js ../www/public/js/app/CompanyApp.js
--next
global.hxml
-main user.UserApp
-js ../www/public/js/app/UserApp.js

the haxe_libraries is contained all the dependencies:

haxe_libraries/angular.haxe.hxml
haxe_libraries/compiletime.hxml
haxe_libraries/gotocore-hx.hxml
haxe_libraries/haxe-crypto.hxml
haxe_libraries/materialize.hx.hxml
haxe_libraries/random.hxml

but on haxe build.hxml I got:

src/company/CompanyApp.hx:2: characters 7-22 : Type not found : angular.Angular

If the build.hxml just contains just the CompanyApp target without --next, or build the project without lix (renamed the .haxerc to .haxerc_bac) haxe build.hxml, everything is working.

I miss something, or this is a known issue?

As far as I can tell, the .haxerc file watcher is not needed anymore with the lix extension. I also can't think of a reason to use lix with VSCode without the lix extension.

In fact, it only seems to lead to issues, such as the server sometimes crashing just before the lix extension can update vshaxe's Haxe executable:

I'm guessing this doesn't always happen because there's a race condition here (the lix extension also has a file watcher for the .haxerc file).

Even running haxelib setup doesn't appear to work.
I worked around it with a symbolic link

$USER/haxe/haxelib

Low priority, but:

I just stared at this for 5 minutes thinking it was still doing something...

Version: v15.5.3

lix.hxml

-main Main
-js bin/lix.js
-cp ../non-existent

Running haxe lix.hxml will print classpath /Users/kevin/Codes/non-existent is not a directory or cannot be read from

but haxe lix.hxml > lix.stdout 2> lix.stderr will log nothing to both files

This is problematic when the command is invoked programmatically (e.g. haxe.io.Process) and the output cannot be captured

C:\GitHub\haxe>npm -v
5.4.2

C:\GitHub\haxe>npm i haxeshim -g
C:\Users\simn\AppData\Roaming\npm\haxelib -> C:\Users\simn\AppData\Roaming\npm\node_modules\haxeshim\bin\haxelibshim.js
C:\Users\simn\AppData\Roaming\npm\haxe -> C:\Users\simn\AppData\Roaming\npm\node_modules\haxeshim\bin\haxeshim.js
C:\Users\simn\AppData\Roaming\npm\neko -> C:\Users\simn\AppData\Roaming\npm\node_modules\haxeshim\bin\nekoshim.js

> [email protected] postinstall C:\Users\simn\AppData\Roaming\npm\node_modules\haxeshim
> node bin/postinstall.js

Error: Could not process argument show-version
invalid character: -
+ [email protected]
updated 1 package in 0.982s

C:\GitHub\haxe>where haxe
C:\GitHub\haxe\haxe.exe
C:\HaxeToolkit\4.0.0-preview.1\haxe\haxe.exe
C:\Users\simn\AppData\Roaming\npm\haxe
C:\Users\simn\AppData\Roaming\npm\haxe.cmd
C:\Users\simn\AppData\Roaming\npm\haxe.exe

Interestingly, it replaced the binaries in C:\HaxeToolkit\4.0.0-preview.1\haxe, but not the ones in C:\GitHub\haxe, which has higher priority. That's why it ends up calling my actual haxe.exe with haxeshim-specific arguments.

Follow up on lix-pm/lix.client#10 (comment)

Calling set HAXESHIM_LIBCACHE=%cd% and then lix install haxelib:tink_core still downloads into the default location. But haxe -lib tink_core fails as it should.

While working on an issue in formatter I thought I'd upgrade lix from 15.5.4 to 15.8.6 (npm refused to install 15.8.7).
When running unittests I use -x TestMain to execute TestMain directly from test.hxml.

lix 15.8.6 tells me -x not allowed here, so I switched to --run. It works fine for Haxe 4, but with Haxe 3.4.7 I get some weird error messages from mcover (haxe/haxe_libraries/mcover/2.2.1/haxelib/mcover/coverage/munit/client/MCoverPrintClient.hx:196: characters 2-38 : Invalid field access : addClient), that I cannot really explain - maybe I haven't dug deep enough to understand it.
I haven't tried running text.hxml on a non lix Haxe 3.4.7 installation, so I can't really eliminate / verify the possibility that mcover always had that error with --run.

Steps to reproduce:

git clone https://github.com/HaxeCheckstyle/haxe-formatter.git
cd haxe-formatter
npm i [email protected]
npx lix use haxe 3.4.7
mv haxe_libraries haxe4_libraries
mv haxe3_libraries haxe_libraries
npx haxe test.hxml

Is my setup wrong, am I doing something unusual or is it a bug?

First start a compilation server:
haxe --wait 6000

Then connect to it:
haxe --connect 6000

Then the server crashes with:

events.js:163
      throw er; // Unhandled 'error' event
      ^

Error: connect ECONNREFUSED 127.0.0.1:51251
    at Object.exports._errnoException (util.js:1033:11)
    at exports._exceptionWithHostPort (util.js:1056:20)
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1099:14)

Note the port "51251" will be different every time.

Currently, --server-connect doesn't work via haxeshim. It's not even documented yet, but it would be nice to already support it in haxeshim. Here I wrote a small doc about how it's supposed to work: https://gist.github.com/nadako/1f6b6eecc339a110dbfd7249db012e2f.

It can be tested with git version of vshaxe with the "haxe.displayServer": {"useSocket": true} setting.

I'm trying to use lix along with flixel, but I'm having this issue:

 $ lix run lime build html5
Called from lime/_internal/backend/native/NativeCFFI.hx line 364
Called from lime/system/CFFI.hx line 198
Called from lime/system/CFFI.hx line 346
Uncaught exception - Could not find NekoAPI interface.

Any advice here?

• Using macOS 10.14.3.
• Haxe 4.0.0-rc.2+77068e1

Here I can see the libneko files available under ~/haxe directory. Not sure why they aren't picked up.

 $ find ~/haxe/ -name libneko.so
/Users/endel/haxe//haxe_libraries/hxcpp/4.0.8/haxelib/project/libs/nekoapi/bin/RPi/libneko.so
/Users/endel/haxe//haxe_libraries/hxcpp/4.0.8/haxelib/project/libs/nekoapi/bin/Linux/libneko.so
/Users/endel/haxe//haxe_libraries/hxcpp/4.0.8/haxelib/project/libs/nekoapi/bin/Linux64/libneko.so

 $ find ~/haxe/ -name libneko.dylib
/Users/endel/haxe//neko/libneko.dylib
/Users/endel/haxe//haxe_libraries/hxcpp/4.0.8/haxelib/project/libs/nekoapi/bin/Mac64/libneko.dylib
/Users/endel/haxe//haxe_libraries/hxcpp/4.0.8/haxelib/project/libs/nekoapi/bin/Mac/libneko.dylib

Try this:

haxelib install snowfall
haxelib run snowfall update luxe
# cd to luxe/samples/empty
haxelib run flow info --hxml > client.hxml
haxe client.hxml
> Error: Resource file not found : <cwd>/version

# try using real haxe
/usr/local/bin/haxe client.hxml
> [OK]

1. when it fails (unknown variable or invalid syntax) it throws
2. it's invoked from a number of different places

Just for discuss.

Is there any concerns why not to shim haxelib path ...? It can be useful for more tight integration with lime / hxp, which calls haxelib path ... internally.

As far as I know lime generates .hxml by itself. This makes haxeshim less useful, because lime already resolve library paths:

-cp ......../haxe/haxelib/actuate/1,8,7
-D actuate=1.8.7

Insteaf of -lib actuate which can be handled by haxeshim.

If haxelib path ... will report shimed library paths (eg. ......../haxe/haxe_libraries/actuate/..., this will probably make things better.

Sort of a followup for #51:

I've just published vshaxe 2.18.0 which modifies the PATH correctly so haxeshim has the right Haxelib. This seems to work perfectly fine for Java and C#, but there's still something wrong with C++.

This is what I get when running the default build task of https://github.com/Gama11/HaxeRepro/tree/lix-hxcpp-broken-pipe with enableCompilationServer: false (but it also reproduces on the command line if you call haxe.cmd directly and modify the PATH as before):

> Executing task: c:/Users/Jens/GitHub/HaxeProjects/HaxeRepro/node_modules/.bin/haxe.cmd build.hxml -cpp export/cpp -cmd cmd /C export\cpp\Main-debug.exe <

events.js:174
      throw er; // Unhandled 'error' event
      ^

Error: EPIPE: broken pipe, write
    at Socket._write (internal/net.js:58:25)
    at doWrite (_stream_writable.js:410:12)
    at writeOrBuffer (_stream_writable.js:394:5)
    at Socket.Writable.write (_stream_writable.js:294:11)
    at Y.path (c:\Users\Jens\GitHub\HaxeProjects\HaxeRepro\node_modules\lix\bin\haxelibshim.js:2:90346)
    at Y.dispatch (c:\Users\Jens\GitHub\HaxeProjects\HaxeRepro\node_modules\lix\bin\haxelibshim.js:2:91517)
    at Y.main (c:\Users\Jens\GitHub\HaxeProjects\HaxeRepro\node_modules\lix\bin\haxelibshim.js:2:89749)
    at Object.Ce.invoke (c:\Users\Jens\GitHub\HaxeProjects\HaxeRepro\node_modules\lix\bin\haxelibshim.js:2:124916)
    at Ze.handle (c:\Users\Jens\GitHub\HaxeProjects\HaxeRepro\node_modules\lix\bin\haxelibshim.js:2:128918)
    at Be.f (c:\Users\Jens\GitHub\HaxeProjects\HaxeRepro\node_modules\lix\bin\haxelibshim.js:2:128832)
Emitted 'error' event at:
    at onwriteError (_stream_writable.js:425:12)
    at onwrite (_stream_writable.js:456:5)
    at Socket._write (internal/net.js:62:14)
    at doWrite (_stream_writable.js:410:12)
    [... lines matching original stack trace ...]
    at Object.Ce.invoke (c:\Users\Jens\GitHub\HaxeProjects\HaxeRepro\node_modules\lix\bin\haxelibshim.js:2:124916)
haxelib run hxcpp Build.xml haxe -Ddebug -Ddump="pretty" -Dhaxe="4.0.5" -Dhaxe3="1" -Dhaxe4="1" -Dhaxe_ver="4.005" -Dhxcpp_api_level="400" -Dhxcpp_smart_strings="1" -Dsource-header="Generated by Haxe 4.0.5" -Dstatic="1" -Dtarget.name="cpp" -Dtarget.static="true" -Dtarget.sys="true" -Dtarget.threaded="true" -Dtarget.unicode="true" -Dtarget.utf16="true" -Dutf16="1" -I"source/" -I"" -I"C:\\Users\\Jens\\AppData\\Roaming/haxe/versions/4.0.5/std/cpp/_std/" -I"C:\\Users\\Jens\\AppData\\Roaming/haxe/versions/4.0.5/std/"
source/Main.hx:3: Test

Somehow it still compiles and runs despite the broken pipe, but something is clearly wrong. With "haxe.enableCompilationServer": true, the task just hangs without any output, I'm assuming that's related to this EPIPE error.

this is the beginning of the haxeshim/bin/haxeshim.js

#!/usr/bin/env node

#!/usr/bin/env node

// Generated by Haxe 3.4.0 

this is the error:

d:\......\haxe-node-boilerplate\node_modules\haxeshim\bin\haxeshim.js:3
#!/usr/bin/env node
^
SyntaxError: Invalid or unexpected token
    at Object.exports.runInThisContext (vm.js:78:16)
    at Module._compile (module.js:543:28)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.runMain (module.js:605:10)
    at run (bootstrap_node.js:420:7)
    at startup (bootstrap_node.js:139:9)
    at bootstrap_node.js:535:3

Removing the 2nd #!/usr/bin/env node fixes the problem.

Especially cleanup the exe voodoo on windows.

Try to run test on tink_sql#pure with haxeshim 0.8.2, the process exits with code 244 without any meaningful error.

0.6.3 was fine though.

  "haxe.displayServer": {
    "arguments": ["-v"]
  }

The above setting should make vshaxe emit some debug info in the Output panel, but with haxeshim nothing shows.

When compiling a project that uses mcover and munit for unittests and coverage, lix tries to resolve library dependencies and ends up running infinitely.
Probably caused by munit referencing mcover, and mcover referencing munit in haxe_libraries

It works fine with lix 15.5.4, but 15.6 or 15.7 will hang.

Edit: I tested with Linux, I assume Windows shows the same behaviour.

Gotta check out why and write tests for it.

Seems like -lib parameters defined after --next are stripped, but not replaced.

All that "failed to invoke" output makes it harder to spot what's actually important at a glance:

It's not correct either. It didn't fail to invoke, the command it invoked simply had a non-zero exit code.

Should help to avoid having to restart manually.