RunRev Script Editor and Linux

Richard Gaskin ambassador at
Wed Jul 14 16:32:24 EDT 2010

Éric Miclo wrote:

 > Le 14 juil. 2010 à 17:17, Richard Gaskin a écrit :
 >> FWIW, yesterday I read all 153 RQCC reports that come up when
 >> searching for "Linux":
 >> <>
 >> Of those 153 reports, only two mention "print" in the subject line,
 >> one of which is being investigated by the team as I write this
 >> (7017) and the other noted by the submitter as having a simple
 >> workaround (8477).
 > Hello Richard,

Thanks for chiming in here, Éric.  After reading all those reports and 
finding you'd submitted a good many of them, I was impressed by the 
effort you put in and the level of detail offered where it was useful. 
Thanks for posting those.

 > What makes you say that bug #7017 is under investigation by the team?

I had a correspondence with Kevin about that on Monday, shortly after he 
let me know that the team fixed another Linux bug:

They really are making a good effort to do what they can on the Linux 
engine, even if it's not very visible between releases.

There's not much money coming in to Rev from the Linux community right 
now, and relatively few Rev developers even port there, so I believe 
it's safe to say that Kevin, Mark, Ben, and the rest of the team are 
putting in a disproportionately strong effort to make the Linux engine 
as good as they can within the constraints they work in.  I can't 
reasonably ask for anything more than that.

 > It is still unconfirmed since 2 years.
 > Bug #8477 is unconfirmed too.

True, as well as for #7490, even though it was fixed a couple days ago.

As Jacque has noted here many times, the RQCC is a part of their 
workflow process but not all of it.  Internally they use different 
systems for tracking progress, updating the RQCC in batches as time permits.

You'll notice that every few months Oliver goes through the RQCC and 
marks dozens of things fixed in the span of a few hours.  It's not that 
the team was sitting around drinking for months and then suddenly got a 
burst of energy and did everything in one day, but just that the system 
that helps them best internally is separate from the public convenience 
they provide in the RQCC.

Very few companies provide a publicly accessible database of known bugs 
and possible future features, and for good reason:  the features feed 
competitors, and quite of few of those bugs are experienced by the 
majority of Rev developers only by their visibility in the RQCC and here 
on this list, but are not actually experienced for themselves in using 
the product.  So public bug lists can become a noise factory that can 
make a product look worse than it is (can you imagine how outraged Mac 
users would be if they had access to Apple's internal bug database?).

This thread is a good example:  so far, from what I've read only two 
users have experienced this issue with copy-and-paste, and thus far 
there's been no repeatable recipe which would allow others (such as the 
Rev team) to reproduce the bug.

But even though it appears to affect only a few users, every member of 
this list has been reading dozens of messages about it.  The perception 
of the bug far exceeds the actual scope of affected people.

This is not to suggest that we shouldn't have such discussions. Of 
course we should, even for things which don't effect most folks, like 
the rounding errors discussed here at length some years ago which led to 
a new function (statRound) that addressed a long-outstanding HyperTalk 
limitation.  Same thing with integers as dates, now allowed in large 
part because of the productive conversations here.

That's really the key: "productive".   As long as a thread sticks to 
presenting an issue and exploring ways to arrive at a recipe for it, I'm 
a happy reader and an eager participant.  But once it strays off into 
the weeds of how to run other people's companies, I lose interest pretty 

I run my shop, Kevin runs his.  We both like it like that.  Any time we 
spend together is done in the spirit of partnership in which we look for 
ways our efforts can be coordinated to further our mutual goals.  We 
don't call each other names, we don't waste each other's time on 
distractions.  We have work to do, he in his office and me in mine.

  Richard Gaskin
  Fourth World
  Rev training and consulting:
  Webzine for Rev developers:
  revJournal blog:

More information about the Use-livecode mailing list