use Magick.Native build

[KnicKnic]

This PR won't build yet, will push more changes when it can.

Beginning work to fix
#46

[cancerberoSgx]

Hey , i tried thesame thing but wasm throw errors, did it workfor you ? also Im trying to build a node.js CLI based on your work (when ready I will PR), but I wonder if this will be possible with the new wasm ? Thanks

[KnicKnic]

I am going to merge the one that passed tests when I get time.

[cancerberoSgx]

Nice, That build has some surprising technologies don't you think ? I wanted to fork and colaborate with some build scripts or notes in the readme but I'm not sure will be welcome. Seem the project is focused on supporting other products Like ImageNet than being a product itself. Also I doubt reporting an issue so magick* files get's released will be welcome, I think I will wait some time and see the evolution of that project before acting. BTW I'm working on building WASM-imagemagick targetting Node.js without FS - when I have some decent thing to show I will probably open a PR, the build will be almost similar. After that I will focus on building a descent CLI , what do you think ? Thanks

A bout keeping updated the online version of magick.js that was a joke but I see you take it seriously. BTW I think there are npm CDNs for that like https://unpkg.com/ and https://www.jsdelivr.com/ that will pick up files automatically from the npm project so is just a matter of keep npm updated and the .js files will be served identically and automatically from those. Also IMO it seems more appropriate to use those as CDN since are real ones and probably faster / cached than directly from github server.
Thanks

[KnicKnic]

this threw exceptions so I abandoning it

magick.js:32 exception thrown: RangeError: Invalid typed array length: undefined,RangeError: Invalid typed array length: undefined
    at new Int8Array (<anonymous>)
    at updateGlobalBufferViews (https://knicknic.github.io/imagemagick/test/magick.js:1341:29)
    at _emscripten_resize_heap (https://knicknic.github.io/imagemagick/test/magick.js:8747:7)
    at wasm-function[8949]:64
    at wasm-function[8164]:7263
    at wasm-function[8171]:187
    at wasm-function[8172]:166
    at wasm-function[391]:123
    at wasm-function[1538]:2022
    at wasm-function[1536]:1760
printErr @ magick.js:32
callMain @ magick.js:11246
processFiles @ magick.js:75
onmessage @ magick.js:128

Also I do not know what this was about

magick.js:32 Calling stub instead of sigaction()
printErr @ magick.js:32
_sigaction @ magick.js:9236
wasm-function[386] @ wasm-03bde4d2-386:4232
wasm-function[214] @ wasm-03bde4d2-214:27
Module._main @ magick.js:10830
callMain @ magick.js:11226
processFiles @ magick.js:75
onmessage @ magick.js:128
magick.js:32 Calling stub instead of sigprocmask()
printErr @ magick.js:32
_sigprocmask @ magick.js:9261
wasm-function[386] @ wasm-03bde4d2-386:4246
wasm-function[214] @ wasm-03bde4d2-214:27
Module._main @ magick.js:10830
callMain @ magick.js:11226
processFiles @ magick.js:75
onmessage @ magick.js:128

I created a PR on what I thought would have been good at
#48

[KnicKnic]

Nice, That build has some surprising technologies don't you think ? I wanted to fork and colaborate with some build scripts or notes in the readme but I'm not sure will be welcome. Seem the project is focused on supporting other products Like ImageNet than being a product itself. Also I doubt reporting an issue so magick* files get's released will be welcome, I think I will wait some time and see the evolution of that project before acting. BTW I'm working on building WASM-imagemagick targetting Node.js without FS - when I have some decent thing to show I will probably open a PR, the build will be almost similar. After that I will focus on building a descent CLI , what do you think ? Thanks

A bout keeping updated the online version of magick.js that was a joke but I see you take it seriously. BTW I think there are npm CDNs for that like https://unpkg.com/ and https://www.jsdelivr.com/ that will pick up files automatically from the npm project so is just a matter of keep npm updated and the .js files will be served identically and automatically from those. Also IMO it seems more appropriate to use those as CDN since are real ones and probably faster / cached than directly from github server.
Thanks

@cancerberoSgx I strongly recommend you reach out to Dirk. I reached out in the past and found that Dirk was very reasonable (busy but reasonable). Some people are more unwilling than others to find a middle ground. It takes very little effort to reach out to Dirk and ask.

Personally I was going to file an issue and ask for utilities to get published, so we could directly consume it. However I wasn't able to get a good build, and I thought a PR would go a long way and seeing my request approved. It is just a few extra lines and they get published. Since I have abandoned my change, I submitted the issue dlemstra/Magick.Native#1

@cancerberoSgx your code has as much public documentation as Dirk's does right now :-) . Currently it is a work in progress. One suggestion I would make to you is offer to setup some basic tests if cmdline is published. Btw they should fail... I know its not glorious work, but it would help ensure that Dirk is motivated to publish the cmdline (and that it doesn't get regressed in the future).

I am glad both of you are working on a proper Javascript Api. Hopefully you won't duplicate the effort that much :-). BTW since you wanna know my opinion (I care much more about browser and not node, so make sure there are es 6 modules).

[cancerberoSgx]

@KnicKnic In my case it didn't work because there is no Module.main (I don't know/want to use the API, just the CLI like this project.. I suspect the reason is that utilities are being disabled, --without-utilities , I'm compiling now without that flag. Will update when finish

[cancerberoSgx]

I am glad both of you are working on a proper Javascript Api. Hopefully you won't duplicate the effort that much :-). BTW since you wanna know my opinion (I care much more about browser and not node, so make sure there are es 6 modules).

I was working in the last weeks in a CLI app that directly uses magick.* files from here. But Igot enthusiastic and I ended also supporting a JavaScript API both for node.js and browser. A took some ideas form the implementing I did here for InputFile and execute and simplified the most I could. have lots of tests running in node.js and some tests running in the browser and a descent werbworker API alghouh I still need to high level a bit. I also adapted the code in magickWoker.js for node, for example using host filesystem instead of emscripten memory fs.

https://github.com/cancerberoSgx/magica

My reasoning was. after dealing with ny big pull request with lots of high level features, and seen that there could other projects providing wasm files and be able to provide just the same api as this .wasm files (which is being able to execute (convert/indentify/etc) I think is a good idea to continue my research there (high level) and perhaps better than projects like this better focus on the build of the wasm files. Those two are totally differnt tasks and if the high level API is independent it will allows to experiment with both using the same hight level fachade. I already have impoemented som performance tests there and I will try to PR features or tests that makes sense here work on the high level browser, node and cli, playground, demos and probably sub projects with high level effects and that kind of crazy stuff only there

At the bottom of the readme there ia checklist with more or less the roudmap and the progress. I still have little issues to resolve but I feel very happy. When the playground is acceptable and I reach parity with this project features and stability, I will push https://github.com/dlemstra/Magick.Native to build the api I consume (which is the command line utilities like in this project) and here where I feel more at home I will work on creating minimal infrastructure to segment the build and hhy not add other libraries.I notice a .wasm of 1.5 mb works and still have lots of features and adding freetype make it 7mb so will add some value. The high level facade will also allow to test this, just switvhing the underlying build abd asking for available capabilities dynamically to according to this preconditions, run a test or not. But thats long ahead yet.

@KnicKnic please if you have any comments on this or eome things you don't like I can change anything. Also I appreciate yout thoughts or ideas. It does donuds ok for you to separate between the biuld and a agnostic hight level layer?

Thanks

[KnicKnic]

@cancerberoSgx sorry I don't have a ton of time to look at this. Yeah I am fine with it. It seems like a decent layered approach.

One thing I would think would be nice is to ensure is some easy way to have a cicd setup that consumes latest stable magica tests for testing the latest magick.wasm build. This way we could at least reuse magica tests.

Its a wish list item, that I currently don't have time to pick up.