Chunk order must be small to large

[Ben Rubinstein]

Richard Gaskin wrote:
> Ben Rubinstein wrote:
>...
>  > ... a simple statement, legal in the syntax, which crashed Rev
>  > with 100% reliability shouldn't be marked "critical"  because
>  > it could only affect the programmer, who should know better.
> 
> What statement is that, and has it been fixed?

See
http://quality.runrev.com/qacenter/show_bug.cgi?id=1634

apparently fixed but I've never checked


> ...
> Agreed on it's usefulness, but overriding the answer command seems a 
> workaround to a deeper issue:  "exit to top" isn't honored when called 
> from within any modal dialog.
> <http://quality.runrev.com/qacenter/show_bug.cgi?id=294>
> 
> If we address that root issue and added support for Cmd-. to invoke it 
> in that dialog (at least within the IDE), the "answer" command itself 
> would be fine.
> 
> 
>  > * RevBrowser responds to a javascript alert in the hosted page by
>  > invoking 'answer'.  I'd really like to trap this - currently I can't
>  > see any way to do so.  If I could override "answer", I'd have a
>  > method.
> 
> Custom-handling the JS alert sounds very valuable indeed, and while I 
> haven't done much with RevBrowser thus far I will be later this year and 
> may need that myself.
> 
> I wonder if this might be handled well with a property, maybe something 
> like "the JSAlert", which would let you assign any command in your 
> stacks to handle JavaScript alerts.  If left empty, the current behavior 
> would remain.
> 
> Do you have a RQCC request for this?

http://quality.runrev.com/qacenter/show_bug.cgi?id=6986

My point is exactly that - I totally accept "if you need a custom behavior, 
give it a custom name" - all the cases that I can think of where we do want to 
override a built-in function are because that would give us a workaround while 
waiting for communication with RevBrowser to be implemented, or for cmd-period 
doing exit to top in all threads, etc...

We've recently begun a new project, for which we've settled on using Qt.  Rev 
would have been faster; but one of the reasons we decided against it was that 
if you hit a problem with Rev, you may have no option but to take another 
route; because you can't fix the problems, and you can't wait for RunRev to 
fix them.  (By contrast, Qt is just a set of frameworks - when push comes to 
shove, if you need to, you can dig into the C++ code and fix it yourself.)

>  > ...but really I'm playing devil's advocate: I'm very happy with the
>  > trade-offs Scott Raney made that give us blazing speed.
> 
> Amen, brother.  I loved it when C++ Journal wrote a review of my 
> Rev-build WebMerge app in which they mistakenly said it was written in 
> C. :)  I wish I could take credit for that, but its performance has more 
> to do with Raney pruning the token table than my scripts.

Absolutely.  I've replaced C code with Rev, and had it go faster; because (a) 
Raney is a brilliant programmer and (b) his code is more optimised - it took 
me so long to write the C code just to do the job, that it wasn't fast.

I'm going to stop doing devil's advocate now...

Ben