-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pathutils_nodejs_support #14512
pathutils_nodejs_support #14512
Conversation
compiler/pathutils is not a standard lib. is it so useful that it should become one? |
I am trying compile nimpretty to js backend, it depends on this module. dont know if it is possible. |
when defined(nodejs): | ||
fs.createReadStream(source.cstring).pipe(fs.createWriteStream(dest.cstring)); | ||
else: | ||
os.copyFile(source.string, dest.string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but this is the wrong place to branch; instead make os.copyFile
work with with nodejs
likewise with other procs.
That way is much more useful as it'll make clients of os work with nodejs.
I guess that's a fair use case (ideally nim compiler should work on all reasonable backends, including nodejs), but you'll probably face other issues than pathutils; in any case the branching (c vs nodejs) should be done at the right place, ideally at the lowest level place possible (eg the importc proc) unless there's a performance consideration (eg if nodejs has a builtin way to do something that's more efficient than calling the nim way). in this case, it's probably os.nim for most of those. right now |
I need listen thoughts, make sure this can be continued, as you mentioned some proc can be place to os.nim, I'll try that so , as far I only have "compile nimpretty to js " goal, maybe it will becoming huge for wrap nodejs libs, when it comes I may create separate nodejs modules wrapper like document listed "modules for js backend" |
yay. anything is the spirit of #14095 is highly appreciated. Instead of creating "modules for js backend", it's best to make existing module work (or work better) for js backend (unless something is js-backend specific of course, like jsconsole)
see tests/js/tstdlib_imports.nim which attempts to list all modules that at least compile with js backend. Of course compile and being fully compatible is a different story. |
@timotheecour Thanks for your reply! I guess I have new field that I can create PR for :P |
My goodness, stop adding nodejs support to Nim. If you want it then create a Nim package. |
A nim package can't work for something like that, it requires some support logic in nim. |
compiled passed on my machine, need review not sure am I doing right.
addNormalizePath
need fix not work with jsgen.