Structure into JavaScript patch?

randall's picture

So I've figured out how to output structures from a JS patch, but I haven't yet figured out how to take a structure in and successfully modify its contents. I've tried accessing it like an array and an object, and both give me an error. Any thoughts?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

randall's picture
Re: Structure into JavaScript patch?

Also-- while we're at it... is there any way to do a console.log style thing for debugging?

randall's picture
Re: Structure into JavaScript patch?

gtoledo3's picture
Re: Structure into JavaScript patch?

It might be worth noting you don't necessarily need to do that test mode stuff all over the place (like is often seen). Scrutinize the code examples you see for crufty stuff that doesn't necessarily need to be there.

For example:

function (__structure outStruct) main (__structure inStruct)
{
    var result = new Object();
   //var outStruct = new Array();
 
       result.outStruct = inStruct;
   return result;
}

This is just passing the input to the output.

So, this would be a pattern to introduce an Index value, Boolean that would make the input structure do something, given that other value (use Indexes for indices with your js QC patch stuff, not floats, even though it will sorta work).

The commented line here does nothing, but it won't "hurt", apparently. I can't help but feel like lines that do nothing are flaky though, and might not scale well if it's done all over the place. I'm not saying that's the case in the code snippet you linked, but it's a general thought that comes to mind when I think of QC JS.

randall's picture
Re: Structure into JavaScript patch?

While we're at it... any ideas of how to construct a structure of images from an iterator? Basically, I'm trying to download a bunch of images, queue them into a structure, and then programmatically display the results.

Normally I'd do something like this in a for loop, with an array collecting items, then sending the array to another iterator for rendering once it's filled. I can't figure out how to collect items in an iterator for later use. Any ideas?

randall's picture
Re: Structure into JavaScript patch?

I should stop asking questions and just keep working. I figured it out again... JS is the way.

usefuldesign.au's picture
Re: Structure into JavaScript patch?

var statements do not "do nothing". They are very important when you try to scale your code since they define scope.

   var outStruct = new Array(); is equivalent to

   var outStruct = [];* so it's also setting outStruct to a null set which will have implications if you put such a line after outStruct has values in it, such as inside a loop.

Since the var statement declares scope, it has implications for garbage collection which is probably more an issue inside browsers than QC but one should be aware of that to before saying "lines that do nothing are flaky though". The flakyness, in this instance, is in the eye (and mind) of the beholder.

* According to JS guru Douglas Crockford this is the preferred way of writing this line these days since it's identical and easier to read.

usefuldesign.au's picture
Re: Structure into JavaScript patch?

Check out Apples developer example composition. They're installed into rootHD/Developer/Examples/Quartz Composer/Compositions folder.

In Image Flow.qtz creating a structure of downloaded images is done in conjunction with a JS patch. This is one that comes to mind but there's possibly others.

gtoledo3's picture
Re: Structure into JavaScript patch?

usefuldesign.au wrote:
var statements do not "do nothing". They are very important when you try to scale your code since they define scope.

   var outStruct = new Array(); is equivalent to

   var outStruct = [];* so it's also setting outStruct to a null set which will have implications if you put such a line after outStruct has values in it, such as inside a loop.

Since the var statement declares scope, it has implications for garbage collection which is probably more an issue inside browsers than QC but one should be aware of that to before saying "lines that do nothing are flaky though". The flakyness, in this instance, is in the eye (and mind) of the beholder.

* According to JS guru Douglas Crockford this is the preferred way of writing this line these days since it's identical and easier to read.

I didn't say they do nothing "period". In the code above, it "does nothing". There is no loop here.

It's good to be aware of what every single line is doing, not do test mode stuff, if it doesn't really need it, not induce patch time stuff, if it doesn't really need it to jog eval, etc., etc. I'm making the point because this is a user who's starting to poke into this, and it's not a bad thought to keep in mind to not do "magical incantation" type stuff that has gotten passed along in QC js examples that are not ideal, or do nothing. If you disagree with that, ok.

I also will say that Douglas Crockford's writings or interpretations thereof, or QC garbage collection issues (!) have nothing to do with the point I'm making.

usefuldesign.au's picture
Re: Structure into JavaScript patch?

It's comments like yours that, I think, contribute to all the poor code out there not improve the situation.

Why not explain what the var statement does rather than say 'leave it out it doesn't do anything' possibly leading to false assumptions? It's good practice to get used to using var statements, and putting all your vars at the top of your functions, or top of code if globals.

The runtime overhead of var statements is zero; they are important in defining scope and they help with code readability. My advice — start using var statements, if not religiously, consciously.

If you'd listened to Crockford's lectures or read his books I suspect you'd know his comments on coding style have everything to do with var statements and including them or otherwise. Otherwise he would not have made them.

gtoledo3's picture
Re: Structure into JavaScript patch?

You don't know what you're even talking about at this point. Ok. Be "right".

gtoledo3's picture
Re: Structure into JavaScript patch?

Tell you what. Get all of those JS samples together.

THEN get all of those "QC JS" bugs together - get those "QC JS" bugs you're always talking about. Let's see 'em.

gtoledo3's picture
Re: Structure into JavaScript patch?

Also:

My care about Crockford=0.00

I realize this comes off as harsh, but you're nitpicking the fuck out of my statement, in a ridiculous way. GO FOR IT if that gives you a stiffy. Don't hurt yourself patting reaching around to pat yourself on the back, because my statement above stands. There's nothing inaccurate. That you want to go on some ridiculous tangent is just some wackadoo bs.

jersmi's picture
Re: Structure into JavaScript patch?

I appreciate seeing this about now: http://javascript.crockford.com/code.html

usefuldesign.au's picture
Re: Structure into JavaScript patch?

Okay you want to go total OT for some reason, I will answer, but I'm not expecting this to calm your nerves any. At this point you seem pretty upset and not for first time this month it seems.

Some of the JS bugs I've experienced were definitely the illusory bug of my ignorance. As I used to tell my students using Adobe CS, although there are a few known bugs, esp on PC versions of suite, 99% of times I'm told 'there's this bug…' I examine what they are doing and it's good old user error.

That's why I made these comments. Bad / unhelpful habits are easy to form when teaching yourself anything. One reason JS is notorious for poor coding style is that it's mainly self taught by non-Comp Sci types.

One source of problems I had was trying to use input structures without first testing for (!_testMode), which can result in errors. Sometimes I'd reuse a JS patch and delete some code including the testMode test and then wonder why it wasn't working. Even log statements appear to be misleading in testMode. These days I'm usually onto it pretty quick but when you are learning JS inside QC you can forget about that anomaly and waste time. So I suggest, against your advice, to any new users just use the (!_testMode) test all the time until they know it probably needs to be there.

Then there's the var statement. If you weren't just passing it a pointer to an input structure and are actually doing something with the variable that assumes it's a structure (array or object), like pushing an element to an array (myArray.push(point_ur_missing)) or using dot notation (myTask.take_abuse_mindfully) will fail without the var statement. This can be confusing when you have a complicated JS patch and you add an new variable and forget to declare it b/c someone said oh that's 'flacky' using var statements when you don't need them.

Perhaps you like to enlighten us all as to when var statements are required and when they aren't rather than being sarcastic like in the email you just sent me, that would be more helpful for novices and less wasteful of your time.

The bug I just documented in another thread about output of a variable being null until I duplicated the variable with a second one different name and then they both outputted the correct value (just was a counter++ kind of thing) is the kind of bug I still find happens now and then. I'm 100% sure I didn't change the code on the first variable and it went from null to 7 (the result of the index count) as soon as I outputted another result. Just a querky weird thing that can make even a simple bit of code to an experienced coder go WTF and this would really confuse a novice coder, which I was for a long long time. One of the things about doing JS in QC as we tend to not use it much at all for weeks on end and then go into it deep for a couple of weeks and little things like this and var and !_testMode can get forgotten making good habits more important and flacky advice more dangerous.

usefuldesign.au's picture
Re: Structure into JavaScript patch?

The JS sample I could find recently does just what the Kineme Index from Key patch does except it does the whole structure.

In pseudo code it goes:

var out_array =[] for (i in Input_Struct) { out_array [i] = Input_Struct [i]; }

result.Output = out_array;

Hope that helps you keep the faith, George.

usefuldesign.au's picture
Re: Structure into JavaScript patch?

could -> couldn't

gtoledo3's picture
Re: Structure into JavaScript patch?

usefuldesign.au wrote:
Okay you want to go total OT for some reason, I will answer, but I'm not expecting this to calm your nerves any. At this point you seem pretty upset and not for first time this month it seems.

Some of the JS bugs I've experienced were definitely the illusory bug of my ignorance. As I used to tell my students using Adobe CS, although there are a few known bugs, esp on PC versions of suite, 99% of times I'm told 'there's this bug…' I examine what they are doing and it's good old user error.

Have you ever had any of your bugs confirmed? Is it possible to show us some of these examples of bugs, so that we can be aware of what to avoid, and where QC is deficient and javascript doesn't work as expected, that you've filed and had confirmed? Any that you just have, either way?

usefuldesign.au wrote:

That's why I made these comments. Bad / unhelpful habits are easy to form when teaching yourself anything. One reason JS is notorious for poor coding style is that it's mainly self taught by non-Comp Sci types.

I don't understand how my saying that one should scrutinize function of every line of code, and you're being critical about that, makes sense.

I also don't understand how your comments about there being "illusory bugs of ignorance", justify your statements about me suggesting that one simply be aware of what each line of their code is doing.

You seem to be arguing with the exact statement you should be agreeing with, for the sake of argument, and to make some sort of correct statement. This seems pathological, and is why my reaction towards you reads so harshly.

So, am I to deduce that we "should not" be aware of what each line of code does, since you take exception to my statement? That's a better route?

usefuldesign.au wrote:

One source of problems I had was trying to use input structures without first testing for (!_testMode), which can result in errors.

Can you explain when it does or doesn't and why?

Have you noted it being used many times when it doesn't need to be?

usefuldesign.au wrote:

Sometimes I'd reuse a JS patch and delete some code including the testMode test and then wonder why it wasn't working. Even log statements appear to be misleading in testMode. These days I'm usually onto it pretty quick but when you are learning JS inside QC you can forget about that anomaly and waste time. So I suggest, against your advice, to any new users just use the (!_testMode) test all the time until they know it probably needs to be there.

So, your advice is just to use something all of the time, whether it needs to be used or not? This is your advice? You also weigh in that it needs to be there more often than not, when dealing with input structures? Is this your take?

usefuldesign.au wrote:

Then there's the var statement. If you weren't just passing it a pointer to an input structure and are actually doing something with the variable that assumes it's a structure (array or object), like pushing an element to an array (myArray.push(point_ur_missing)) or using dot notation (myTask.take_abuse_mindfully) will fail without the var statement. This can be confusing when you have a complicated JS patch and you add an new variable and forget to declare it b/c someone said oh that's 'flacky' using var statements when you don't need them.

Yes. That's not what the code did though. So, what are you arguing about?

Your variable names are ridiculous, and exactly the kind of thing I've been talking about concerning you.

I didn't say it's flaky using something that you do need. Again, you are purposely misconstruing my statement. You are not reading the words and coming to a logical conclusion about the meaning of them, or you're purposely choosing to rail against me, in a way that is not logical, given my statements.

usefuldesign.au wrote:

Perhaps you like to enlighten us all as to when var statements are required and when they aren't rather than being sarcastic like in the email you just sent me, that would be more helpful for novices and less wasteful of your time.

When you have someone jump all over you for no logical reason, it doesn't set a good tone to do so. You can definitely hire me per hour though.

usefuldesign.au wrote:

The bug I just documented in another thread about output of a variable being null until I duplicated the variable with a second one different name and then they both outputted the correct value (just was a counter++ kind of thing) is the kind of bug I still find happens now and then.

Can you link to that/share the example?

usefuldesign.au wrote:

I'm 100% sure I didn't change the code on the first variable and it went from null to 7 (the result of the index count) as soon as I outputted another result.

This is able to be reproduced? Again, I don't know what thread your talking about. Without seeing context, this makes no sense, to me at least.

usefuldesign.au wrote:

Just a querky weird thing that can make even a simple bit of code to an experienced coder go WTF

Hmm, interesting. Who is an experienced coder that has gone WTF at this bug?

usefuldesign.au wrote:

and this would really confuse a novice coder, which I was for a long long time. One of the things about doing JS in QC as we tend to not use it much at all for weeks on end

Oh really?

usefuldesign.au wrote:

and then go into it deep for a couple of weeks and little things like this and var and !_testMode can get forgotten making good habits more important and flacky advice more dangerous.

I don't understand how that relates to me saying that one should be consciously aware of what each line of their code is doing, and need for it, or not.

gtoledo3's picture
Re: Structure into JavaScript patch?

usefuldesign.au wrote:
The JS sample I could find recently does just what the Kineme Index from Key patch does except it does the whole structure.

In pseudo code it goes:

var out_array =[] for (i in Input_Struct) { out_array [i] = Input_Struct [i]; }

result.Output = out_array;

Hope that helps you keep the faith, George.

What does that have to do with me?

usefuldesign.au's picture
Re: Structure into JavaScript patch?

Yes and he makes some more comments regarding scope in his lecture series on YouTube which I recommend.

For example a variable declared inside a function is limited in scope to that function, but all the calling function's variables are available to the called function. This can be useful but the fact also needs to be observed, since you could overwrite something by repeating the use of a variable name inside a function thinking you have restricted scope to just the function.

PreviewAttachmentSize
Var scope.qtz24.29 KB