Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
6th November 2013, 02:28 | #221 | Link |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,666
|
As a novice AviSynth user I had this problem a few times, and when someone is new to AVS this could be kind of a turn off. Now that I know better and I'm used to this behavior would I like to see a change? Not really, but a more comprehensive error message would definitely be a good idea.
@TurboPascal7 On a side note, any plans to integrate FTurn into AviSynth+? Last edited by Reel.Deel; 6th November 2013 at 02:49. Reason: FTurn comment |
6th November 2013, 03:06 | #222 | Link |
Oz of the zOo
Join Date: May 2005
Posts: 208
|
On the 'last':
So, irregardless of user experience, there seems to be no logic *syntax-wise* behind current behavior (but of course if one looks into the source code it's clear that filters() explicitly try to use the 'last' clip in rather an unsightly manner, which doesn't compensate the lack of syntax logic anyway). |
6th November 2013, 07:58 | #224 | Link |
Registered User
Join Date: Jan 2008
Location: Finland
Posts: 68
|
I've run into this so many times I've lost count, usually in the exact situation described (testing filtering and commenting out a line), so here's a very large "yes, please make assignment return last" from here.
__________________
Where did neuron1 go? | Doom10 |
6th November 2013, 10:38 | #225 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
When you write a function in C for example, the compiler forces you to return from that function with the correct type and that makes sense. You don't dumb down the language because of convenience. |
|
6th November 2013, 10:56 | #226 | Link | |
Registered User
Join Date: Jan 2010
Posts: 270
|
Quote:
As for assignment on the last line being wrong argument, what about scripts like this: Code:
super=MSuper(last, pel=4, planar=true) pp_super=fft3dgpu().MSuper(pel=4, planar=true) b1vec = MAnalyse(super, delta=1, isb=true, blksize=8, overlap=4,search=5) f1vec = MAnalyse(super, delta=1, blksize=8, overlap=4,search=5) b1clip = MCompensate(orig, super, b1vec, thSAD=400) f1clip = MCompensate(orig, super, f1vec, thSAD=400) As for users not knowing what script returns: if this behavior got silently changed, how many people do you think would notice? P.S. I'm sorry if I sound too "rude" and I should probably stop posting on the issue. The question was posted to get opinions, not arguing about them. Sorry. Last edited by TurboPascal7; 6th November 2013 at 11:06. Reason: Millions of typos |
|
6th November 2013, 11:17 | #228 | Link | |
Registered User
Join Date: May 2008
Posts: 40
|
Quote:
Anyway, I'm against a fix that will allow sloppy coding (commenting lines and leaving an assignment as the last line sounds like sloppy coding to me), instead of commenting just use a return last in the place you need to test the output. |
|
6th November 2013, 12:03 | #229 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Yes, I was about to make that point myself. |
|
6th November 2013, 12:17 | #230 | Link |
Oz of the zOo
Join Date: May 2005
Posts: 208
|
Commenting was just an example, there's no need to focus on that per se.
The real problem is the quirky behavior of an assignment statement in avisynth at the end of a scope. It is inconsistent. Either make all assignment statements kill the 'last' clip (nonsense), or make the last assignment behave exactly the same as the others. |
6th November 2013, 12:24 | #231 | Link | |
Registered User
Join Date: Jan 2010
Posts: 270
|
Quote:
Code:
function test() { colorbars(640, 480) clp = blur(1) } colorbars(320, 240) test() blur(1.0) Anyway, this was actually pointed out as an example where this proposal would break stuff, which for me is a showstopper. So I'm gonna quit here. But I (and not only I) would still love to see your ideas on multithreading. |
|
6th November 2013, 13:18 | #234 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
What is the inconsistency from the user's point of view?
Quote:
The Fluff had an excellent post just now describing how it works in detail, but it seems to have disappeared. |
|
6th November 2013, 14:25 | #236 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
I deleted the post because I thought the discussion had already covered what I was talking about but here's the relevant part again:
Avisynth has four types of expressions: 1) explicit returns ("return <expression>") 2) explicit assignments ("variable = <expression>") 3) implicit assignments to last (all expressions that aren't one of the two first types and evaluate to a clip) 4) other expressions where the return value is thrown away (everything else) When the last expression in a block (either a function or a script) is not an explicit return (type 1 above), Avisynth will evaluate the expression and implicitly return the value it evaluates to, regardless of what the type of that value is (clip, int, string, undefined, whatever). The quirky thing here is that while expressions of type 3 and 4 above return the value of the expression, an explicit assignment returns an undefined value. I think this is a lazy fix to make sure an explicit assignment of a clip to an arbitrary variable doesn't overwrite last, which I suspect would happen if the assignment returned the assigned value like every other assignment operator on the planet does. The inconsistency is that an explicit assignment returns undefined while an implicit assignment to last returns the assigned value. What TurboPascal7 proposed to change is simply the implicit return mechanism: if you attempt to implicitly return an explicit assignment expression, last should be returned instead of the undefined value, if last is defined at that point. The problem with this is that there's nothing about the scripting language that forces you to use last, and thus there's really nothing that says that at the end of a block the contents of last would be a better or more correct value to return than any other arbitrary value. I can accept an operator returning an undefined value, even if I think that's ugly, but having an operator return a defined, arbitrary value that may be completely unrelated to any of its operands is beyond ugly. What I think you should do is promote the assignment operator to full citizen status like all of Avisynth's other operators, give it a place in the precedence table and make it return the assigned value like assignment operators in basically every other language do. Then fix the script parser so this doesn't overwrite last when the assigned value is a clip. This will probably break things though. Last edited by TheFluff; 6th November 2013 at 14:43. |
6th November 2013, 14:43 | #237 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Yesterday we discussed this issue extensively with a couple of folks on IRC, and because there was no consensus, I encouraged them to bring this to the forums, to see what others think. I take Gavino's, Fluff's, Sapo's and Groucho's side here, and their arguments are the same why I wouldn't like to make this modification. To reiterate my points (which practically already have been said here by others), IMHO integrating this fix is not a good idea because:
- It will lead to confusion with non-expert users. If they expect anything to be returned after an assignment, they will expect the assigned value to be returned, not some hidden variable ('last') from a couple of lines earlier. - More importantly, it can (and probably will) lead to hard-to-discover bugs, even with more experienced users. If the last statement is an assignment, did the user want the assigned value to be returned, or did he forget a line with 'last'? Changing the behavior to which basically equals to adding an implicit 'last' statement will hide one of these errors, while the current behavior makes the user spell out his expectations exactly (which avoids both error possibilities). Wishful thinking on my part, but if we really wanted to make return values more logical and easier to use, we should either (1) return the last assigned value whatever it is even if not 'last', or (2, preferred) get rid of implicit returns completely and always require a 'return' statement in any block for a variable to be returned. Of course, both of these solutions would seriously break a lot of scripts, so obviously none of these two are gonna happen. |
6th November 2013, 15:16 | #238 | Link | ||
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
I don't want to prolong the debate unnecessarily, as it seems we have now reached a conclusion, but just to address a couple of points raised...
Quote:
Code:
function f(clip c) { c ... width() } The value of that expression is returned rather than the value of 'last' (which is 'c'). (Note that only clip values are ever implicitly assigned to 'last'.) Quote:
If you look at it this way, then there is no inconsistency in the treatment of assignments. |
||
6th November 2013, 16:33 | #239 | Link |
Registered User
Join Date: Nov 2005
Location: Russia
Posts: 62
|
"nah, this will break my scripts because I found a way to rely on this behavior" or something like that. I got used to current behaviour. And moreover i am often creating chains of scripts by importing them into one biggest. I think that new modification can make more difficulties than making life easier.
|
6th November 2013, 18:08 | #240 | Link | |
Registered User
Join Date: Aug 2007
Posts: 374
|
Quote:
In one word I can describe it as "superscalar" architecture. The same ideas as used in modern superscalar CPUs: 1) Work is separated from data flow. (-> denotes function call) How it goes now: Render->FilterB->FilterA->Source. How it should be: Scheduler->Source, Scheduler->FilterA, Scheduler->FilterB. 2) Filter has to be able to tell the scheduler which frame numbers from which its sources it needs to produce each destination frame number. Fast, without actual frames, but maybe imprecise (can fail its processing call and request more). 3) There are several kinds of filters: one instance multicall (like MTMode 1), one instance singlecall (MTMode 3), multi instance one call per instance (MTMode 2). Type is provided by the filter itself, always. 4) Based on 1-3, number of available hardware threads and data flow graph Scheduler builds filter call plan in superscalar way: several frames in flight on different stages. 5) Refcounting and no cache. Based on call plan each frame has its own reference count and will be kept exactly until all references are used. All produced frames are read-only, but could be forwarded (for filters like Trim). As could be seen, such architecture not only would allow efficient and scalable utilization of hardware threads but will be able to incorporate even extremely threading-unfriendly filters with sequential frame processing without any correctness or speed drawbacks given enough other work in script. Also it would be very memory-efficient: only actually needed data is kept and memory is consumed as much as needed for no redundant work in the scheduling window. Cons: hard to implement, scheduling is active and will consume some resources, how filters work needs to be modified: source frames are provided to filter, not requested from inside. Legacy Avisynth 2.5 filters work through separate filter "wrapper". Threading information is provided to it in textual user-editable file config. |
|
|
|