Skip to content
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

Error installing glslify-optimize #2

Open
FarhadG opened this issue Feb 27, 2015 · 5 comments
Open

Error installing glslify-optimize #2

FarhadG opened this issue Feb 27, 2015 · 5 comments

Comments

@FarhadG
Copy link

FarhadG commented Feb 27, 2015

Been having some issues installing this module. Have you guys ran into something similar?

Gist: https://gist.github.com/FarhadG/604299589d2233b7f4df
Node v0.12.0

@alexanderGugel
Copy link

Having the exact same issue.

@ftripier
Copy link

ftripier commented Mar 3, 2015

I think the problem might actually be with the mapbox-glsl-optimizer dependency, but I'm getting the same issue.

@hughsk
Copy link
Member

hughsk commented Mar 3, 2015

This is because the V8 API changes with every Node release, unless you're using nan for handling the bindings and have that up to date too then it won't compile across every version. It won't work for io.js either, and sadly all I can recommend is falling back to node@0.10.x for the time being.

It's an issue with mapbox-glsl-optimizer but unfortunately native bindings are a little beyond my understanding – @mikolalysenko @tmpvar do you guys have any ideas? :)

@aferriss
Copy link

aferriss commented May 25, 2017

Actually was able to get this compiled on a fork, but I still can't get it working. I ended up ditching mapbox-glsl-optimizer and using marcs-glsl-optimizer instead.

There's some things in this package that just look weird to me. I'm not sure where 'glslify/adapter.js' is coming from. I've never seen it in the node tree and omitting this statement seems to let things continue onward. Also the final if(!(callee = callee.callee)) return causes an exit. And nowhere did I see callee.name ever being require. I added a check for if(node.value.length < 1) return and that finally dumped out my shader, but I'm not sure this would work in all instances. So what finally worked for just a single frag shader was:

walk(function(node){
      if (node.type !== 'Literal') return
      var parent = node
      var callee = node

      if (!(parent = parent.parent)) return
      if (!(parent = parent.parent)) return
      if (!(callee = parent.callee)) return
      //      if (!(callee = callee.callee)) return

     // my glslify func variable name....
      if (callee.name !== 'glsl') return

      if(node.value.length < 1) return

      var args = parent.arguments
      var opti = optimize.frag(node.value); 
      console.log(opti);
      .....

I'm wondering if those checks are looking for the wrong thing. Perhaps something changed in the way that these trees are structured in the past couple years? Here's a sample node output.

{ type: 'Literal',
  value: '#define GLSLIFY 1\n\n  void main(){\n  vec4 t = vec4(1.0);\n  vec4 color = vec4(1.0,0.0,0.0,1.0);\n  gl_FragColor = color;\n  }\n',
  raw: '"#define GLSLIFY 1\\n\\n  void main(){\\n  vec4 t = vec4(1.0);\\n  vec4 color = vec4(1.0,0.0,0.0,1.0);\\n  gl_FragColor = color;\\n  }\\n"',
  parent: 
   { type: 'ArrayExpression',
     elements: [ [Circular], [Object] ],
     parent: 
      { type: 'CallExpression',
        callee: [Object],
        arguments: [Object],
        parent: [Object] } } }

@aferriss
Copy link

Ok, think I got this sorted here aferriss@3680d4c and seems to be working for me. I'm not 100% that it is safe for all setups, would love if someone could take a look and see if I'm doing anything dangerous. Otherwise, I'm happy to submit a pr!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants