Facility to skip portions of script

[vcmohan]

In Avisynth script # symbol makes the parser to disregard the line. When a large number of statements are being tried for optimum results very often need to skip a large chunk of script arises. By meticulous planning and equating results to some symbols this is possible but immediately one statement is changed a chain of statements need some modifications. Functions can be specified but not always convenient. I am looking forward for a facility like /* */ of C++ may be /# or @# or &# and their inverses on a line by itself can ignore the code inbetween by the parser.

Yesterday I posted a similar request but today I did not find it in the topics.

[stickboy]

Originally posted by vcmohan
Functions can be specified but not always convenient.Functions usually are the best way to go.

Disabling code by commenting it out in general software development usually leads to maintainability problems. Refactoring and modularizing are good things.

But, if you really must, one hack is to use quotes (or triple-quotes (http://forum.doom9.org/showthread.php?s=&threadid=71597)) and treat an entire section of a script as one big, unused string.

[Mug Funky]

could you elaborate on the triple quote thing? i don't get how it'd carry across lines.

btw, avisynth scripting, though often quite advanced, isn't software development. it's good to be able to "rem out" several lines when you're only talking about trying different things out on a clip. it'd also be nice for documenting useful scripts (so other people can use them) without having to put heaps of # everywhere.

for example, i'm the only geek at work who really knows avisynth, though heaps of people would like to use it for simple things (NTSC to PAL comes up a lot). to have an instruction manual inside a script is useful in these cases, though it's not really important to have no #'s at the start of each line. more of a convenience thing i guess.

hehe... i second vcmohan's request :)

[Didée]

Originally posted by Mug Funky
could you elaborate on the triple quote thing? i don't get how it'd carry across lines.
It just does. That's the way how AviSynth's script parser works.

mpeg2source("sample.d2v")

# unused = """ \
addborders(16,0,0,0)
subtitle("funny text")
# normal comments don't interfere
greyscale
# \"""

return last

In the same manner, after uncommenting the first and last #'s you could even do

eval(unused)

By doing so, you can enclose different parts of a script in quotation marks, and use these strings as quasi-functions. At times this may come handy for conditional executions and such. See here (http://www.avisynth.org/stickboy/ternary_eval.html).

stickboy wrote lots of useful stuff for AviSynth (http://www.avisynth.org/stickboy/). Reading it is really worth it.
- But if one doesn't mind bowing down to grab the money that's lying on the street, well ... ;)

[Mug Funky]

tnx, didée :)

[esby]

Disabling code by commenting it out in general software development usually leads to maintainability problems.


1- Sorry to be abrupt, but how is that possible? Commenting out code is a way to quick test code part. I do agree that it means that you have no cvs/svn/ source control (god knows what you are or should be using) system. Now, I doubt that the facility provided by /* or (* blocks leads to maintainability problems.
If I take vb6 as an example, you don't have this option... so you are forced to use comment your block by starting ' which is kinda depressing...
I do agree that the use of goto and labels leads to disastrous problem, but that's not the case for style commenting, as far I know.

2- Even with this argument taken (and proven as valid), I doubt that it will affect the stability of scripts, if such concept exists. Am I wrong?

Now adding the corresponding comment style is possible in the actual parser and in the future (3.0) right?

esby

[stickboy]

Originally posted by esby
1- Sorry to be abrupt, but how is that possible? Commenting out code is a way to quick test code part. I do agree that it means that you have no cvs/svn/ source control (god knows what you are or should be using) system. Now, I doubt that the facility provided by /* or (* blocks leads to maintainability problems.Abusing the comment system as a means to disable code has the following problems: Comments serve as documentation. When you disable code by putting it in comments, it isn't always clear whether that code is merely disabled or if that code is serving as documentation to the code around it. e.g.
# x = y
y = zDoes the above mean that x == y == z? Or does it mean that x = y and y = z are mutually exclusive? It's confusing. #if 0 .. #endif in C is usually slightly better.
It allows the commented out code to become stale. You disable some code, the rest of the code evolves, and now you have this section of disabled code that no longer works if enabled, and it's usually not clear what purpose the disabled code served, why it's disabled, and why it wasn't just completely removed in the first place. Or sometimes there are several sections of code that are commented out, but they are meant to be re-enabled only in certain combinations.Sure, using comments to disable code for quick testing is fine, but once time starts elapsing, you start forgetting things. Maintainable code needs to defend itself against time.
2- Even with this argument taken (and proven as valid), I doubt that it will affect the stability of scripts, if such concept exists. Am I wrong?I'm not talking about stability; I'm talking about modifying a script at some future date and not wasting time trying to figure it out. Furthermore, as memory fades, it becomes increasingly difficult to remove disabled code. "Why didn't I remove this code originally? I must have left it here for a reason, so I'll keep it around in case I remember later." Right.

[esby]

I agree with the explanation, except a few points...

# x = y
y = z

I am not wrong, but it is not 'start/end block style commenting'
So you are merely talking of the usage of comments to take code out, no matter the type of comments used.
I mean, the example you use can be done (and is done already) in avisynth.
So it does not justify the absence of 'comment blocks'.

Now give me just the counter example of what you say.
(pascal style)


(*** Removed code
y := z
x := z
End of removed code ***)

I think there is no possible ambiguity.
The ambiguity you describe is only possible by bad documentation practice to my eyes. Of course, nobody is perfect, but the point is not here.



I'm talking about modifying a script at some future date and not wasting time trying to figure it out.

That's what the 'real & proper' comments are for, no matter the language.
Having a start & end comment type can help here,
as you can format more easily comments, althought it is very relative and narrowed point of view...
Of course, functionnal programming is a better approach.
Now I usually create an avs script by modifying a model or template.
When I use function, it is mainly to avoid rewriting existing code, not to maintain these scripts over time. These scripts have a relatively restricted utility over time. You can even consider that once there have been written and used, you'll almost never use them again, but that's my mere opinion.

esby

PS: I think that the one of the reason to the absence of comment blocks is that nobody ever requested them or estimated them to be avs scripting.

[stickboy]

Originally posted by esby
I am not wrong, but it is not 'start/end block style commenting'
So you are merely talking of the usage of comments to take code out, no matter the type of comments used.
I mean, the example you use can be done (and is done already) in avisynth.
So it does not justify the absence of 'comment blocks'.Right, and I'm not opposing adding start/end comment blocks in AviSynth. None of my posts above referred specifically to multi-line comments.

All I said was that using comments (whether single-line or multi-line) for the purpose of disabling code is in general a poor programming practice that can lead to maintainability problems.

[vcmohan]

May be maintainability problems exist with this style of commenting out portions of script. but I find that just as in C++ coding it is useful in many cases, there is utility in having such a facility in Avisynth scripting also. Every facility can be misused, but that does not preclude having such a facility. Hope it will be introduced.

[Fizick]

It is a time to return to this discussion.
IMO, block comments would be useful both for multi-line and single-line comments like C /* comment */
It also may be useful for editors like AvsP for of sliders or switching blocks.

The implementation is quite easy (in tokenizer.cpp).

The question is: what symbols to use as a comment.
New avosynth must be compatible with old scripts.
The possible candidates are: [ and ] or [# and #]
May be some other. AvsP-compatibility is important too,
but AvsP syntax may be changed IMO.
For example, it is possible to use filter(param=[<"name",0,255>]5) instead of filter(param=[<"name",0,255,5>]).
In this case brackets may be considered by new Avisynth as comment block.

?

[IanB]

I would hate to waste a good set of single bracketing characters. You never know when you might need them.

So I would prefer to go with a pair of characters like the [# ... #] or what most current languages seem to be using i.e good ol' /* ... */

[Fizick]

After some playing I discover, that Didee example with triple quotes may be even more simple:


version()

""" it is docstring comment block
addborders(16,0,0,0)
subtitle("funny text")
# normal comments don't interfere
greyscale
"""

return last


So, we already have some almost normal block comments (python-style). http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Comments_and_docstrings

But it can not be used in function parateters through.


Looking to source I discover one more undocumented feature:
__END__ statement for comments after end of code!
(like Perl and Ruby)


version()

addborders(16,0,0,0)
# normal comments don't interfere

__END__
any lines after this end statement is a comment and not processed

subtitle("funny text")
greyscale

return last


seems, it was so in all avisynth versions. :)

[gzarkadas]

Triple double quoted strings may appear in the script as values to assign in variables or pass to functions (especially when you want to make something a bit more elaborate with the runtime filters, or make an if..else block). Thus one cannot block-comment such sections of the script with this trick.

I believe a special double pair with its first character to be # is the best solution, because then only the part of the tokenizer that skips characters after the comment has to be modified. Some possible candidates:

#/ ...... /#

#{ ...... }#

#< ...... >#

#[ ...... ]#

[IanB]

Using a leading '#' will change the existing behaviour. Any script that happens to match the chosen pair would no longer work. Candidate pairs need to cause a systax error in the existing versions.

[Leak]

Using a leading '#' will change the existing behaviour. Any script that happens to match the chosen pair would no longer work. Candidate pairs need to cause a systax error in the existing versions.
I guess /* */ fits that bill quite well...

np: The Black Dog - Vir²l (Parallel)

[Fizick]

well, /* ... */ is not so bad (this combination is not possible in current version).

will it possible to comment inside a function?


version()
borders(0,/* add two top lines */ 2, -0,-0)

[Leak]

will it possible to comment inside a function?


version()
borders(0,/* add two top lines */ 2, -0,-0)

As long as comments are skipped in the tokenizer that should be possible, yes.

Will there be support for nested block comments? Those would simply need a counter in the skipping routine.

And what should happen with stuff like "/*/" and "*/*"?

np: Porn Sword Tobacco - Copyright The Universe (New Exclusice Olympic Heights)

[IanB]

Hmmm, nested block comments. Very usefull. Possible, but not straight forward. I have currently hijacked the """ code and it seems to work, but nesting cannot be done this way.

[IanB]

Okay, I've been tinkerin' somewhat.

1. Having both nestable and first drop terminable comments is damn usefull.

2. [# #] I think looks ugly, the # char is to heavy.

3. [* *] seems to look more balanced to my eye.

So currently I have /* */ as first drop terminable comments. i.e /* /* */ is valid.

And [* *] as nestable terminable comments i.e. [* [* *] *] is valid.

To keep things backwards compatible the # nuke to EOL style comment has priority. i.e # /* and # [* are valid.

I'll put the code into CVS soonish and put up an avisynth.dll to try.

Thoughts?

[IanB]

Try this http://avisynth2.sourceforge.net/avisynth2572.zip

[Fizick]

Nested comments is interesting.
But why both nested and not nested?

[check]

The only concern I have with [* *] is that it's very unusual and will take me a while to get used to. If /* */ is included as well hopefully everyone will just use the latter instead ;)

[IanB]

But why both nested and not nested?So people can experiment, experience and comment on both philosophies.... concern I have with [* *] is that it's very unusual ...I needed 2 distinct tokens to make both nested and first drop comments available together in the one version. The choice at this point is purely arbitary.

Now is the time to speak up. Make a proposition and argue your case.

[Leak]

Now is the time to speak up. Make a proposition and argue your case.
Is there even any reason for non-nestable comments? If you don't want to nest comments you can just not do it...

But it's always a pain in the rear end to comment out bigger parts of code that happen to already have a block comment - like they're often used to document functions and the like, after all...

A vote for nested comments from me.

[Fizick]

Probably one nested will be enough (if it is not very hard for parser to process complex multi-level scripts).
I tried a new avisynth version a little.
Seems, it works fine.

Let's comment all!
IMO it is the greatest addition to avisynth language for recent years!
The previous was KillVideo of course (I can not appraise the mysterious OPT_UseWaveExtensible)
:)

[gzarkadas]

I like having both alternatives. They are useful on different occasions. The interaction with strings must be thinked of more though IMHO. The following script:
[*
s = " [* "
*]
BlankClip().Subtitle("OK")

gives error "nestable block comment missing closing *]", which I believe it would suprised most people of Avisynth user base that are not inclined in programing.

Perhaps string contents should not be examined for starting or terminating comment characters, as they currently do not for single line # comments.

[IanB]

@gzarkadas,

Yes, sprung! The current code has been thrown together rather quickly to explore the concept. You will also find a comment closing inside a string trips up as well.

This is where we need to define some grammar rules with hierachy and how this most usefully will work.

[Fizick]

So, in this beta version we can not use comment symbols in string.
In this case we probably can replace comment block symbols to combination not-permitted in strings (and more long):
[""" for comment opening
"""] for comment closing

It is not perfect but more rarely occures.

[3ngel]

I am looking forward for a facility like /* */ of C++
Wow, now i remember i wanted to open this thread many time ago, but then i forgot :mad:

BTW, i would be very happy if avisynth would implement the C++ /* */ comments.
MANY times i've had the situation to comment out many lines, and i had to type # and type... and type... and type... and type...

Any news about this?
Sorry if i'm late or if it's already developed :)

OPS: I forgot an important, i think the /* */ is the best because some of avs users are programmers, and so it's good to the non programmers to just adapt them to the C++ language in some way eheheh :devil:

[esby]

Is // assigned to something currently in avisynth?

Could it be used as an alternative to # single line comments ?

esby

[Fizick]

IMO, adding // will broke compatibility without any real need.

here is my version to try:
http://avisynth.org.ru/tmp/avisynth258_comments.zip

[" "] nested block comments
/""" """/ not nested

this way we can use nested comments in complex string (with tripled doublequote) for Eval, subtitle, etc.

[stickboy]

MANY times i've had the situation to comment out many lines, and i had to type # and type... and type... and type... and type...You need a better text editor. :p

In TextPad, for example, I can select the lines, hit Ctrl+Q,B to enable block-selection mode, then go to Edit > Fill Block. And then to undo it, I could enable block-selection mode, highlight the # characters, and just hit delete.

Or as I mentioned a the very beginning of this thread, it's trivial to wrap the relevant lines in a function.

[stickboy]

Is // assigned to something currently in avisynth?

Could it be used as an alternative to # single line comments ?I agree with Fizick. It doesn't offer new functionality and just restricts the grammar. Multiple ways to do things isn't always good.

[Didée]

In TextPad, for example, I can select the lines, hit Ctrl+Q,B to enable block-selection mode, then go to Edit > Fill Block.
Somewhat cumbersome for my taste, since you need to Ctrl+Q,B once more to quit block-selection mode again. I prefer Alt+draggin' (press down Alt before using the mouse button). ;)

[IanB]

@Fizick, Ahhggggg! You just changed the strings, you didn't fix my code :(

Parse this/"""
BlankClip()
SubTitle("""/ is the "divide" character""")
"""/As I saidThis is where we need to define some grammar rules with hierachy and how this most usefully will work.In C // seems to have the highest lexical priority followed by /* , i.e. // /* does not start a block comment. And nothing protects or masks a */ and the nearest C has to nestable comments is #if 0, #endif.

This model does not seem to be what people want. We struggle to express clearly how we want the grammar to work. Less coding more deep thinking needed here.

[smok3]

from a nonprogramer; i do like a # button in AVSedit 1.1.0.0 :)

[gzarkadas]

This is where we need to define some grammar rules with hierachy and how this most usefully will work.

The existing behavior is that everything inside a string is preserved, even a comment character (#); once a " or """ is found the tokenizer skips everything until a matching closing " or """ is found.

Thus, IMHO, the tokenizer when searching for a matching closing block comment should skip entirely string literals, with the existing rules (which allow inserting a "" string inside a """ string). Anything else would break the established from the current behavior user expectations.

[IanB]

@gzarkadas, How would you parse this/* """ */How is it different from this# """

[Bidoche]

easy : "/*" *(. - "*/") "*/" :p

[Fizick]

IMO string must not be skipped for comment symbols,
i.e. it is bettter to use comment symbols which is not permitted (or at least not usualy exist) in string. That is why i suggest use doublequote as a part of comment delimiter.
If string is opened, any symbols must be part of this string, not a comment.

Current alpha prioritity is quite good.

IMO we must simply select some exotic symbols combination for comment, and say to users do not use it in strings. In particular, currently users can not use triple double quote in strings, and all are quite happy with it :)

I do not like /""" too. But I like [" "] for nested comments. May be [""" is better or [[" for not-nested comments.



["""
BlankClip()
SubTitle(""""""""+""""] is not permitted "symbol combination" in string""")
"""]

:)

[IanB]

Note to self!

Catch free standing */ and *] sequences as an error.

[Ebobtron]

Note to self!

Catch free standing */ and *] sequences as an error.I am currently getting; sytax error at line#, column# for the "*". Seems like lot of work to report missing matching /* [*. ??

oops almost forgot.
Thanks for the block comments and nested block comments

[IanB]

A novel approach a friend has suggested is to match the next character after the block start with character before the block end sequence.

i.e. /* comment */

/*- comment 3
/** comment 2
/* comment 1 */
/* comment 2 **/
comment 3 -*/

Thoughts anybody....

[Ebobtron]

A novel approach a friend has suggested is to match the next character after the block start with character before the block end sequence.

i.e. /* comment */

/*- comment 3
/** comment 2
/* comment 1 */
/* comment 2 **/
comment 3 -*/

Thoughts anybody....
Well I like it. If I understand correctly ? any "/*?" matches the next "?*/" Would /*comment*/ still work ?
Very clever :) more lexer fun.

[IanB]

Would /*comment*/ still work ?No, the 'c' does not match the 't'.

I guess by the overwhelming number of responses, this particular idea is not of great interest. :(

[Ebobtron]

No, the 'c' does not match the 't'.
I still like it, but then that could be a good reason not to use it. :)
I guess by the overwhelming number of responses, this particular idea is not of great interest. :(:(

[Fizick]

IMO, it is better do not create too many kinds of comments :)

and IMO two (nested and not nested) is too many too :)

[IanB]

Yes, exactly, I am looking for a single style that is satisfactory to most people.

I only included the 2 styles originally so people could play and contrast with each style and make comments about them.

At this point, I am inclined to go with nested comments using /* */ as the tokens. I am still experimenting with the 3rd character matching on both types and it does dodge the bullet with closing tokens found inside strings fairly well.

[Fizick]

IMO some more compatibility with AvsP syntax would be useful (but qwerpoi is silent :) ).

And yes, we need in more users comments about comments :)