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 :D.

[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 :D

>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 :)

[Manao]

What happens with user defined function:

function mpeg2dec_motionmask (.......){} ?They create an error, and I don't see a problem here. The user can define it another way.Nobody knows about all exported functions from all installed plugins.Yes, but an error message saying function's name is already in use should be enough.I'll never prefer that quadro point thing, one point is enoughYes, of course, but '.' is already in use ( clip.filter() ), so you have to find another separator.

BTW, banning '_' from dll & function name would resolve almost all the issues you're expecting. The filters using '_' in the dll name or a function name can be counted on the finger of one hand ( I know only _2DcleanerYUY2 )

[stickboy]

Originally posted by Manao
What happens with user defined function:

function mpeg2dec_motionmask (.......){} ?They create an error, and I don't see a problem here.If I'm understanding sh0dan correctly, there would be no error.

Despite what the AviSynth docs say, user-defined functions seem to override plug-ins and built-in function names. (I think it's better that way. Functions in the script itself should take precedence. It would be bad if adding a plug-in to the autoload directory broke an existing script.) Nothing should happen to that user-defined function.

The current approach is that when a plug-in adds its function names to the namespace, AviSynth generates the corresponding dll_ names and adds those to the namespace too. This has the advantage of not requiring any changes to the parser and not having any ambiguity, but it has the disadvantage that the generated names won't necessarily be unique. If there is a collision, behavior would be the same as it currently is.
BTW, banning '_' from dll & function name would resolve almost all the issues you're expecting. The filters using '_' in the dll name or a function name can be counted on the finger of one hand ( I know only _2DcleanerYUY2 )If you want to include user-defined functions, I can think of quite a number of functions that have underscores (http://www.avisynth.org/stickboy/) in their names. :p

[zettai]

If we are creating alias function names do we really need overrides at all?

Is it not possible that when a filter is parsed that the regular function names are defined AND an alias name which is filtername_functionname is also defined. If a name exists then only the latter is defined.

This not only allows you to use the first funciton in the chain as Function() but it also allows you to specify which type you use whether there is a function clash or not.

So even if I didn't have any other filters that contained Telecide I could still have a script containing decomb511_telecide(order=1) and know what I was going to get and if by chance I happen to leave an old version in the plugin dir I'd still be able to use the new one.

Am I making any sense?

[stickboy]

Originally posted by zettai
Is it not possible that when a filter is parsed that the regular function names are defined AND an alias name which is filtername_functionname is also defined.I think this is what the new scheme already does.
If a name exists then only the latter is defined.

This not only allows you to use the first funciton in the chain as Function() but it also allows you to specify which type you use whether there is a function clash or not.Currently whatever plug-in was loaded last will take Function(). Last or first seems pretty arbitrary to me; I don't see why there should be any major reason to prefer one over the other, so it might as well be last. (If we include user-defined functions in our discussion, then having the last definition override the earlier ones makes more sense.)
So even if I didn't have any other filters that contained Telecide I could still have a script containing decomb511_telecide(order=1) and know what I was going to get and if by chance I happen to leave an old version in the plugin dir I'd still be able to use the new one.I imagine that this is what the new scheme already does.

[WarpEnterprises]

Originally posted by stickboy
Despite what the AviSynth docs say, user-defined functions seem to override plug-ins and built-in function names.

You are right - shame on me :o

[stickboy]

Hmm... I'm trying the 2004-03-14 AviSynth build, and it looks like the new DLLName_function() support works only for auto-loaded plug-ins. It doesn't seem to auto-generate the additional names for plug-ins loaded from LoadPlugin.

Is this the intended behavior?

[stickboy]

Also, do the built-in functions get additional names too?