[Ticket#: 2006040510000641] Re: [OT] Articles to read

[David Burgun]

On 6 Apr 2006, at 23:53, J. Landman Gay wrote:

> David Burgun wrote:
>
>> Just look at the Script Editor! There are at least 10 bugs that I   
>> come across every day, and for 2+ years???!!!!
>
> Did you put them into bugzilla? If you didn't, the team won't  
> always know there is a problem.
>
>> For instance, straight off the top of my head:
>> 1.  I open a script and do nothing to the script, I then close  
>> the  script and it gives me the "Do you want to save?" dialog.
>
> I'm not sure this is really a bug. It is more a by-product of one  
> of the features. Revolution saves not only your script, but also  
> the location of the insertion point so that the next time you open  
> the script it will  scroll automatically to where you were last  
> working. This is a nice feature. So, if you close the script editor  
> without clicking anywhere, you won't get the "save" warning. If you  
> do click, it marks the script as dirty, stores the current cursor  
> location, and asks if you want to save
> it.
>
> Once you understand what's happening, it may not seem so terrible  
> any more.
>

I just tried it and this isn't how it works on my system. I open a  
script, click in a few places but don't enter any data. The apply  
button is disabled and if I hit the close button in the window title  
bar is close ok.

When the spurious "Do you want to save?" dialog log appears, I've  
noticed that when I only the Script in question the Apply button is  
enabled straight away. At first I thought it was something to do with  
having text selected when the script was saved, but I just tried that  
and it worked. But, today, it must have happened at least 10 times.

>> 2.  The script colorization doesn't work consistently.
>> 3.  Sometimes the script editor/debugger loses it's mind and when  
>> you  click on the error it opens the *same* script in another  
>> window. If  you then edit this window and close it, then notice  
>> that the other  window is still open and close that one, you lose  
>> your changes!
>> 4.  The debugger sometimes just plain refuses to breakpoint, even   
>> when you insert a "breakpoint" command into the script.
>> 5.  The Menu Builder tool is really flakey.
>
> These are mostly valid and I've also seen some of them. I can't  
> comment on colorization because I abhor it and always turn it off.  
> (It also increases the size of your stack on disk because Rev must  
> store a duplicate htmltext copy.)

Point noted, thanks.

> I've seen the double script window problem only a couple of times,  
> but it needs to be reported. If you have a stack that reproduces  
> the problem, I hope you will submit it so it can be fixed. I've  
> never had any trouble at all with the menu builder, but if you can  
> define the problem more concisely than "flakey" the team can look  
> at it. It has always worked okay for me.

I  had it happen about 2 hours ago, I have no idea why it happened,  
but once it loses it mind like this, the only way out is to quit and  
start again. I can't reproduce it at will, when it does happen it's  
hard to know what to report. Today I'd being doing the same thing  
over and over in a "test" stack, trying something out. I was writing  
a little code and then testing it using buttons to execute pieces of  
the code and then looking at the variable window. It was easy to tell  
what had happened this time and get out of it by copying both scripts  
into a text window, quitting RunRev and then pasting back the real  
script, if it happens when there are a lot of scripts open it's not  
so easy to tell what has happened and then you can lose code.
>
> Number 4, refusing to break, happens only under very particular  
> circumstances. I've been able to reproduce it twice, reported it  
> twice, and both times it was immediately fixed. In each case, it  
> was a problem with a library or a backscript -- once with libURL  
> and another time with the way the IDE was parsing file paths. I  
> think it happens when a library is in use in a stack that is not  
> open -- or when a backscript has been inserted -- and the library  
> has a bug. The debugger will not trace into that script. The engine  
> has two choices at this point; the first is to go into an infinite  
> loop (that's what the MetaCard IDE does) and the other choice is to  
> simply not break at all. Rev does not break at all. This is  
> infinitely superior to a loop that you can't get out of. When I  
> used to hit this problem in the MetaCard IDE I had to force-quit  
> without the opportunity to save my work.

Yes, that's when I've seen it too mostly, but today it happened with  
a small 3 control script and no libraries. I put a breakpoint in the  
mouseUp handler of a button and it just wouldn't breakpoint. One  
thing I have noticed is that if you insert an "answer" command just  
before the breakpoint command and OK the dialog, it breakpoint's ok.
>
> Careful debugging of your own library scripts can help, if that is  
> where the problem is. If the problem is with one of the backscripts  
> or libraries that Rev employs, then *report it.* I just did a  
> couple of searches in Bugzilla, and did not find any bug reports  
> submitted under either your name or email address. You can't expect  
> fixes to things that aren't in the bug database.

If I reported every glitch, I'd spend all day in BZ and no time  
actually do some work. That said, I am guilty as charged, I haven't  
entered any of the above bugs in the database, since they are *so*  
obvious that I really can't see the point. If they need the database  
to notice that the colorization doesn't work 100% then we are all in  
serious trouble!

> Note also that the team uses Rev and all its features daily to  
> develop Rev's IDE, among other things. Therefore, if you are having  
> a problem it is likely localized to either your setup or your work  
> style. They need to know. For example, one reason my copy of the  
> debugger would not break was because of a file path issue that  
> existed only on my hard drive. No one else could reproduce it; I  
> finally figured it out when I changed the name of a folder. Then I  
> reported it.

Then they must be really patient people is all I can say. If I had to  
live with just of those minor bugs but had the source code so I could  
fix it, then I'd do in my spare time if necessary. It's like living  
with a squeeky door for 2 years and not bothering to get out the oil  
can!

All the Best
Dave