problems with conflicting function names

[scharfis_brain]

lets assume following script:

loadplugin("masktools.dll")
loadplugin("mpeg2dec.dll")
loadplugin("mpeg2dec3.dll")

mpeg2source("bla.d2v")
motionmask(...)


here are conflicting the functions mpeg2source and motionmask

would it be possible to create something like this:

masktools.motionmask
mpeg2dec.motionmask

to be absolutely sure, which function to choose.
and to be able to use both functions called motionmask

[Manao]

It could be possible ( I mean, I can do it, with an underscore, not a dot ), but I think it would be better if it was avisynth itself which took care of such situation, detecting conflict and resolvind it by changing function names.

I don't know if it's possible however. Anyway, in the next release, if nothing has been decided, I'll add a MaskTools_MotionMask in the list of filters.

[scharfis_brain]

I think AVIsynth should handle this automatically internally.

filenameoflibary_function()

for example:

loadplugin("masktools.dll")
loadplugin("mpeg2dec.dll")
loadplugin("mpeg2dec3.dll")
loadplugin("kerneldeint140.dll")

mpeg2dec3_mpeg2source("bla.d2v")
mpeg2dec_motionmask(...)
kerneldeint140_kerneldeint(...)


thus no need within the libaries will be needed.

sometimes there aree conflicting avisynths internal functions with libaries functions or users functions

internal functions may be called like
avisynth_levels()

user-functions like this:

user_levels()

just as idea

[mf]

Ooo, Document Object Model for AVISynth .

[Bidoche]

Rather than an underscore, I would rather have an :: like in C++, but I doubt the parser will accept them as part of a name as the time being.

[scharfis_brain]

how about some other possible signs?

% or $ or ~

seem to be unused

[vion11]

Avisynth already uses the point operator for OOP notation.
I see no advantages on establishing syntactic sugar like
a quadro point or underscore operator.

The idea is however quite good, since it solves naming problems
without the need of recoding all plugins and provides better
support for GUI editors.

Only thing left is to avoid plugin-DLLs with same name,
which is quite easy.

I'd like to see it in version 2.6

[sh0dan]

I'm currently looking at it - it is however not an easy task, as plugin name and function names gets separated. (env->AddFunction() doesn't know the dll name).

I'll go for underscore, as separator, as that will not break anything, nor require any parser changes.

Can anyone quickly do a function that extracts the filename without extension from a path+filename+extension? (const char* as input)

[Manao]

void ExtractFilename(const char *path, char *filename) {
	const char *fullfilename = strrchr( path , '\\' );

	int pos = strcspn(fullfilename, ".");

	filename = new char[pos];
	for ( int i = 0; i < pos-1; i++ )
		filename[i] = fullfilename[i+1];

	filename[pos-1] = 0;

}

The function assumes that path ( ) path + filename + extension ) is valid, so no test are made inbetween to test the validity of the path.

Edit : between the ' ' in strrchr, I put a double \, but the script which prints the message transforms it into a single \, so beware.

[vion11]

As script without looping:

colorbars(400,300).trim(1,100)
subtitle(GetFile("c:\myfolder\myplugin.dll"))
killaudio

function GetFile (string sfile){
nPosPoint = strlen(sfile)-findstr(RevStr(sfile),".")
nPosSlash = strlen(sfile)-findstr(RevStr(sfile),"\")
return MidStr(sfile, nPosSlash + 2, nPosPoint - nPosSlash -1)}

Still wondering how such complicated as c++ can be used to
build such simple as avisynth

[sh0dan]

Seems nice. I'll have a look.

[sh0dan]

Got it working. You can test when the next CVS binary is out.

If you're interested I used a combination of your methods:

      char result[512] = "\0";
      char* t_string = _strrev(_strdup(filename));
      int len = strlen(filename);
      int pos = len-strcspn(t_string, ".");
      int pos2 = len-strcspn(t_string, "\\");
      strncat(result, filename+pos2, pos-pos2-1);

Syntax highlighting in VdubMod is working nicely. Some of the other code is based on some guessing, so the next version might be a true alpha version.

Duplicate filternames should however still be avoided in all cases.

[stickboy]

Originally posted by scharfis_brain
how about some other possible signs?

% or $ or ~

seem to be unused

% is used for modulus. $ is used for hex values. AFAIK ~ and @ are unused.

It's not clear how the implementation should work:

• The filename_ portion is strictly optional, right?
• What if a function name normally has an underscore? If I call foo_bar(), will the parser check for a function named foo_bar() first, or will it look for a function bar() in foo.dll?
• What if the filename has an underscore?
• What if there are multiple underscores? Is this sytem going to search through all the possibilites?

BTW, other alternatives that wouldn't require any parser changes would be:

A. to add a primitive that removes a plug-in's functions from the global namespace. Then you could do:

function MaskTools_MotionMask(...)
{
    LoadPlugin("MaskTools.dll")
    c = MotionMask(...)
    UnloadPlugin("MaskTools.dll")
    return c
}

I suppose that this would require significant changes to LoadPlugin too and to plug-ins' destruction and that it would be a little inconvenient.

B. to change scoping behavior so that in something like the above, MaskTools' functions wouldn't be available outside the scope of the function. (But then there's the question about what happens if the unction is called multiple times, and I expect that modifying the scoping behavior would be more troublesome than modifying the parser.)

In the long run, namespaces would be better, but I'd prefer :: instead of _.

[sh0dan]

>The filename_ portion is strictly optional, right?

Yes. We are not mad

>What if a function name normally has an underscore? If I call foo_bar(), will the parser check for a function named foo_bar() first, or will it look for a function bar() in foo.dll?

Whichever registered last. When you plugin foo.dll registers bar(), foo_bar() will be registered at the same time.


> What if the filename has an underscore?

No difference. You should add it as any character. Space and other space characters are more problematic.

> What if there are multiple underscores? Is this sytem going to search through all the possibilites?

Every plugin is added twice, this is the only overhead.

>I suppose that this would require significant changes to LoadPlugin too and to plug-ins' destruction and that it would be a little inconvenient.

Changes are rather small. Main changes are in IScriptEnvironment::AddFunction(...), and a global variable.

[vion11]

To step back and get the whole picture has some advantages.

Can a underscore solution really be unambiguous?
Are there really no sideeffects?
How many different scripts have been tested?

I think it leads to a lot of work in documentation and
comments and forum questions and less in code,
it should be otherwise.

Is there really a problem to put hands on the parser and
if at all adjust the tokenizer to use existing OOP notation
as a clear solution?

He simply has to expect a pluginname in addition where
only functions can be (now).

Better implement and forget about than:
"I have strange effects with underscores....."

[stickboy]

Originally posted by sh0dan
Whichever registered last. When you plugin foo.dll registers bar(), foo_bar() will be registered at the same time.

<smacks forehead>

Right, of course. That's much simpler than the tokenization scheme I was fearing.

[Manao]

vion11 : at the moment, there are no filter nor dll which uses an underscore in their names ( except perhaps _2DCleanYUY2 ).

For an ambiguity to appear with the _, you would need to have something like that :

Foo.dll with a function called bar_bla()
Foo_bar.dll with a function called bla()

As you can see, in that case, their are no ambiguities in the name of the functions, so you should use bla() and bar_bla() instead of foo_bar_bla().

Of course, '::' would be a better separator, but it would complicate the parser, whereas the '_' is easy to implement.

[vion11]

Sorry can't follow these arguments.

It is better to complicate the script language than the parser...?
Underscore is a legal char for user function names, so no ambiguities...?
There is already a seperation operator, lets implement another one...?

Which problems are expected on changing
expression.cpp and scriptparser.cpp?

The simpler the language the more uses!

[Manao]

vion11 : you may not have read all wh0dan's explanations : when you have a function bar() defined inside the dll foo.dll, both foo_bar() and bar() are defined. So the script language won't be complicated.

That modification with '_' doesn't imply a change on the parser. If you wan't to use '::', you have to define a token 'dll' and to modify tokenizer.cpp ( because ':' is already an operator ). That makes a lot of modifications.

[vion11]

What happens with user defined function:

function mpeg2dec_motionmask (.......){} ?

Nobody knows about all exported functions from all installed plugins.
If one knows, please tell me, so I can change the code in AVEditor
from brute force to smart handling.

I'll never prefer that quadro point thing, one point is enough