the threex- planets- function from here:
https://github.com/jeromeetienne/threex.planets/blob/master/threex.planets.js
tells me that THREE/ three.js was not defined:
"threex.planets.js:406 Uncaught ReferenceError: THREE is not defined"
This is the particular line:
THREEx.Planets._RingGeometry.prototype = Object.create( THREE.Geometry.prototype );
Indeed THREE is defined and has already made a scene and several things before reaching this code- line. As THREE is located in the global space and several classes use it without complains I am a bit.... suprised by this error.
I see it is not.... essential to let planets be generated and can be "deleted" and maybe is only needed if I would like to get planetary rings.
What may I be supposed to do to make it work completely ?
After getting this message I just cleaned the code by adding MANY ";" and nothing else.
Thanks for your time.
Related
I need to replace old version of boost (1.58) with a new one (1.66). But there is an issue with a breaking change that happened since then in boost::geometry library. I have little knowledge in this library. In the code that I depend on (not written by me) function self_turns() is used. As far as I understand it calculates self intersections. In previous version it required 4 parameters, but in the new one it requires 5 (plus 2 optional). New parameter is IntersectionStrategy. I searched a lot but failed to find any documentation or examples of how this can be defined/used. Does anyone know how it should be used now?
You can try to pass a variable declared like this:
typename bg::strategy::intersection::services::default_strategy
<typename bg::cs_tag<Geometry>::type>::type strategy;
(where Geometry is your geometry type, and bg an alias for boost::geometry) as the missing Intersection Strategy
No, there are no samples yet, it is meant to be a public function in the future but currently it is not (and therefore the interface can change indeed).
I'd like to know what works in Processing 3 but doesn't work or isn't supported (yet) in Processing.js? Seems like many of the new examples in Processing 3's GUI don't work once converted to js.
I'm using this tool to convert: http://processingjs.org/tools/processing-helper.html
You're going to have a hard time tracking down everything that breaks between Processing 3 and Processing.js. They are two separate projects maintained by two separate groups of people.
The best thing you can do is try something, see specifically what breaks, and then try to find a workaround. Take each example one at a time, try to get it working, and post a question here if you get stuck on something specific.
That being said, one place to start looking for things that might not work is the Changes in 3.0 page on Processing's GitHub.
Specifically, anything involving the new surface variable is not going to work in Processing.js. Similarly, the new settings() function won't work either. Some additional functions in PVector also won't work.
Here is a link for a beta JavaScript mode for Processing 3, but you might be better off just waiting for Processing.js to catch up with Processing 3. In the meantime, take the examples one at a time, the workarounds shouldn't be too complicated to figure out.
Processing 3 (P3) is a java library, while processing.js (PJS) is a JS library, so each library will use their respective language's methods. As a basic example, a function in PJS will be declared like function myFunction () {} or in some cases var myFunction = function () {}; while P3 would look like void myFunction () {}. Another difference is strong type, in JS you can simply declare any type of variable with var myVariable = 0; but in java and therefore P3, you need to use int myVariable = 0; or boolean myBoolean = false;. Of course these aren't the only differences, but I hope they give you an idea of the differences in porting something from PJS to P3; while the library is very similar in both languages and can do many of the same things, it is mostly a difference between languages not libraries.
There is a famous function from WebGL API (and from OpenGL too) getAttribLocation http://msdn.microsoft.com/en-us/library/ie/dn302408(v=vs.85).aspx
In my project I'm trying to get the needed attribute by using this function, but getting the -1 value.
It's ok, when there isn't such attribute in shader, but in my program there is:
See it? I've dump in console the existed members of shaders, and vertexColor exists.
I don't know how can I get -1, when the dump of shader from which I'm fetching attributes shows that such an attribute exists in memory.
If to fetch other attributes, all is normal, except this one (but it was declared in same way as others and I didn't delete something in memory):
As you can see for vertexPosition and textureCoordinatesAttribute it returns their location number of the attribute.
So what's wrong and why does it occur I can't explain. Please help with a piece of advice.
Can't provide a source code, because I'm developing large library, which is right now 3k+ lines of codes. I can only tell you that you may see how shaders are creating by the screenshots and the function, which is getting attributes is just iterating a collection of the input objects with attribute list, and for each attribute is calling getAttribLocation function from WebGL. Despite on this, the screenshots show the real dump, and you can see, that I'm telling the truth about existed attributes in shader. Also, you can see that fetching two of them gives a correct result and one fails. What's wrong I don't know. As for me and if to use logic it must not return the -1 value. The attributes exists in memory and the calling syntax is correct, so this issue is rather mysterious for me right now.
If the attribute is not used the GLSL compiler is allowed to optimize it out. The WebGL API is designed so you can ignore that. Passing -1 to any of the functions that take an attribute location basically become a no-op.
Similarly the GLSL compiler can optimize away unused uniforms. gl.getUniformLocation will return null for unknown uniforms and passing null to any of the functions that take uniform location are a no-op
It's a good thing it works this way because when debugging it's common to comment out parts of a shader. Because unknown attribute and uniform locations just become a no-op everything just keeps working, no errors.
As a continuation of this question and the subsequent answer, does anyone know how to have a job created using the Parallel Computing Toolbox (using createJob and createTask) access external toolboxes? Is there a configuration parameter I can specify when creating the function to specify toolboxes that should be loaded?
According to this section of the documentation, one way you can do this is to specify either the 'PathDependencies' property or the 'FileDependencies' property of the job object so that it points to the functions you need the job's workers to be able to use.
You should be able to point the way to the KbCheck function in PsychToolbox, along with any other functions or directories needed for KbCheck to work properly. It would look something like this:
obj = createJob('PathDependencies',{'path_to_KbCheck',...
'path_to_other_PTB_functions'});
A few comments, based on my work troubleshooting this:
It appears that there are inconsistencies with how well nested functions and anonymous functions work with the Parallel Computation toolkit. I was unable to get them to work, while others have been able to. (Also see here.) As such, I would recommend having each function stored in it's own file, and including those files using the PathDependencies or FileDependencies properties, as described by gnovice above.
It is very hard to troubleshoot the Parallel Computation toolkit, as everything happens outside your view. Use breakpoints liberally in your code, and the inspect command is your friend. Also note that if there is an error, task objects will contain an error parameter, which in turn will contain ErrorMessage string, and possibly the Error.causes MException object. Both of these were immensely useful in debugging.
When including Psychtoolbox, you need to do it as follows. First, create a jobStartup.m file with the following lines:
PTB_path = '/Users/eliezerk/Documents/MATLAB/Psychtoolbox3/';
addpath( PTB_path );
cd( PTB_path );
SetupPsychtoolbox;
However, since the Parallel Computation toolkit can't handle any graphics functionality, running SetupPsychtoolbox as-is will actually cause your thread to crash. To avoid this, you need to edit the PsychtoolboxPostInstallRoutine function, which is called at the very end of SetupPsychtoolbox. Specifically, you want to comment out the line AssertOpenGL (line 496, as of the time of this answer; this may change in future releases).
I edited the question after David Hanak's answer (thanks btw!). He helped with the syntax, but it appears that I wasn't using the right function to begin with.
Basically what I want is to let the compiler ignore multiple definitions of a certain label and just use the first. In order to do that, I thought I'd just do something like this:
\makeatletter
\newcommand{\mylabel}[1]{
\#ifundefined{#1}{\label{#1}}{X}
}
\makeatother
This does not work though, because the first option is always chosen (it doesn't matter if the label is defined or not). I think the \#ifundefined (and the suggested \ifundefined) only work for commands and not for labels, but I don't really know much about LaTeX. Any help with this would be great! Thanks!
Much later update:
I marked David Hanak's response as the correct answer to my question, but it isn't a complete solution, although it really helped me.
The problem is, I think but I'm no specialist, that even though David's code checks to see if a label is defined, it only works when the label was defined in a previous run (i.e. is in the .aux file). If two \mylabels with the same name are defined in the same run, the second will still be defined. Also, even if you manage to work around this, it will make LaTeX use the first label that you defined chronologically, and not necessarily the first in the text.
Anyway, below is my quick and dirty solution. It uses the fact that counters do seem to be defined right away.
\newcommand{\mylabel}[1]{%
\#ifundefined{c##1}{%
\newcounter{#1}%
\setcounter{#1}{0}%
}{}%
\ifthenelse{\value{#1} > 0}{}{%
\label{#1}%
\addtocounter{#1}{1}%
}%
}
I'm not sure if it is necessary to initialize the counter to 0, as it seems like a likely default, but I couldn't find if that was the case, so I'm just being safe.
Also, this uses the 'ifthen' package, which I'm not sure is necessary.
I am also not a LaTeX expert, however after one day of trying and searching the internet the following worked for me. I have used a dummy counter to solve the problem. Hopefully this helps, apparently not many people are looking for this.
\newcommand{\mylabel}[1]{
\ifcsname c##1\endcsname%
\else%
\newcounter{#1}\label{#1}%
\fi%
}
# is a special character in LaTeX. To make your declaration syntactically correct, you'll have to add two more lines:
\makeatletter
\newcommand{\mylabel}[1]{
\#ifundefined{#1}{\label{#1}}{X}
}
\makeatother
The first line turns # into a normal letter, the last line reverses its effect.
Update: You might also want to take a look at the "plain" \ifundefined LaTeX macro.
Update 2
Okay, I did some research to figure out the answer to the real problem. The thing is that defining a label does not create a macro by that name; it prepends a "r#" to it. So try the following:
\makeatletter
\newcommand{\mylabel}[1]{
\#ifundefined{r##1}{\label{#1}}{X}
}
\makeatother
For more technical details, refer to line 3863 of latex.ltx in your LaTeX distribution (where it says \def\newlabel{\#newl#bel r}).
By Victor Eijkhout, "TeX by Topic", p.143:
\def\ifUnDefinedCs#1{\expandafter\ifx\csname#1\endcsname\relax}
This can be used to check whether a label is defined; if not, the label is printed:
\newcommand{\myautoref}[1]{\ifUnDefinedCs{r##1}{\color{magenta}\IDontKnow\{#1\}}\else\autoref{#1}\fi}