Re: Do ... as Applescript, bugs??

[Sarah Reichelt]

On Mon, Apr 12, 2010 at 11:38 PM, Andrew Meit  wrote:
> My error msg: Execution Error
>
> The file name changes each time its run for its created via Rev script. So no 
> file is made till the end. And I have to go through AS editor because am 
> creating AS files on the fly for later use. It appears Rev is somehow not 
> letting go of its connection to the AS Editor. I am trying not to have to 
> type stuff out a lot due to my disabilities thats why am creating this. 
> Please, someone...help. Thanks.


Andrew, can you provide more info about what you are trying to do here.

If you are using Rev to create AppleScript apps, then stop. I always
tell people that it is pointless trying to write AppleScript in Rev,
but to write it in the AS editor and when you are sure it works, then
transfer it to Rev.

When you say your script works once and then fails, are you trying to
save the same script each time? If not, maybe there is an error in the
second script that is preventing compilation.

Like I said before, I don't understand what you are trying to do, so
it is very hard to provide any useful advice.

Cheers,
Sarah
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Do ... as Applescript, bugs??

[Andrew Meit]

My error msg: Execution Error

The file name changes each time its run for its created via Rev script. So no 
file is made till the end. And I have to go through AS editor because am 
creating AS files on the fly for later use. It appears Rev is somehow not 
letting go of its connection to the AS Editor. I am trying not to have to type 
stuff out a lot due to my disabilities thats why am creating this. Please, 
someone...help. Thanks.


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Do ... as Applescript, bugs??

[stephen barncard]

Andrew,
What is the error that you get and from where? Is it a "file exists" error?
Perhaps that is why it works the first time and not the second in Rev;  The
applescript editor probably traps for that.
perhaps you could try "file exists" in rev to check first.

On 11 April 2010 20:03, Andrew Meit  wrote:

> I give up. It appears do AS is somehow picky/buggy or what...here is my
> simple code:
>
> copy to clipboard this: --testing code
>
> I have the AS code below in a field:
>
> tell application "AppleScript Editor"
> activate
> set fpath to "/Users/ScholarMeit/Desktop/As tests/moving window"
> make new document with data the clipboard
> compile document 1
> save document 1 in POSIX file fpath as "script"
> close window 1
> end tell
>
> With this script for the field:
>
> on enterinfield
> do (text of me) as Applescript
> put the result
> end enterinfield
>
> I tried both the latest beta and latest shipping version, both hang. I am
> using 10.6.3. iMac 21.5.
> It will work once and then on next time its called Rev hangs a long time
> then report an error.
> AS code works without error in Script editor.
>
> It was supposed to help me work faster...any clues? Thanks.
> Andrew___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



-- 
-
Stephen Barncard
Back home in SF
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Do ... as Applescript, bugs??

[Andrew Meit]

I give up. It appears do AS is somehow picky/buggy or what...here is my simple 
code:

copy to clipboard this: --testing code

I have the AS code below in a field:

tell application "AppleScript Editor"
activate
set fpath to "/Users/ScholarMeit/Desktop/As tests/moving window"
make new document with data the clipboard
compile document 1
save document 1 in POSIX file fpath as "script"
close window 1
end tell

With this script for the field:

on enterinfield
do (text of me) as Applescript
put the result
end enterinfield

I tried both the latest beta and latest shipping version, both hang. I am using 
10.6.3. iMac 21.5.
It will work once and then on next time its called Rev hangs a long time then 
report an error. 
AS code works without error in Script editor.

It was supposed to help me work faster...any clues? Thanks. 
Andrew___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Do ... as Applescript, bugs??

[Sarah Reichelt]

On Mon, Apr 12, 2010 at 4:18 AM, Andrew Meit  wrote:
> Ahh I had an insight to rework it and now it works. However, am always 
> wanting to work smart than hard...
> I am creating AS statements on the fly via Rev then sending them to 
> Applescript editor to be compiled and saved via clipboard.
> Is there a way to send a list of AS statements to AS to be compiled and saved?
>
> Like this?
>
> do "Tell process "&"Applescript"&cr&"to compile "&AS_stmts as Applescript

Why?

In revTalk, you can just use:
   do AS_stmts as Applescript
and it doesn't need to be pre-compiled. You can save it as text if you
want and then pull it into your app or stack and "do" it.
Running it through the Script Editor first seems an unnecessary step.

Cheers,
Sarah
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Do ... as Applescript, bugs??

[Ian Wood]

On 11 Apr 2010, at 19:18, Andrew Meit wrote:

Ahh I had an insight to rework it and now it works. However, am  
always wanting to work smart than hard...
I am creating AS statements on the fly via Rev then sending them to  
Applescript editor to be compiled and saved via clipboard.
Is there a way to send a list of AS statements to AS to be compiled  
and saved?


Like this?

do "Tell process "&"Applescript"&cr&"to compile "&AS_stmts as  
Applescript


thanks, andrew


You can compile AppleScripts via the command line although I've not  
done much of it. Have a look at osacompile and osascript in the  
Terminal.


http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/osacompile.1.html

Ian

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Do ... as Applescript, bugs??

[Andrew Meit]

Ahh I had an insight to rework it and now it works. However, am always wanting 
to work smart than hard...
I am creating AS statements on the fly via Rev then sending them to Applescript 
editor to be compiled and saved via clipboard.
Is there a way to send a list of AS statements to AS to be compiled and saved?

Like this?

do "Tell process "&"Applescript"&cr&"to compile "&AS_stmts as Applescript

thanks, andrew___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Do ... as Applescript, bugs??

[Jim Ault]

One 'bug' that was present for me in Rev 2.7.2 and Rev 2.9.0 was in  
the IDE


I found that after the first AScript sent to a Rev stack 'on  
appleevent', that subsequent calls to Rev were silent.


The answer was to switch from Browse tool to Pointer, then back again.
This was not the case for making calls to other programs like Excel,  
Photoshop, Word, etc.




On Apr 11, 2010, at 9:22 AM, Andrew Meit wrote:

I am struggling to figure out why do as Applescript works once  
correctly but second time its fired off, Rev hangs and returns  
"execution error". My As code works correctly within the As editor  
all the time. I am talking directly to the Applescript editor with  
my do statements. I am using 4.0. Are there known bugs with As with  
Rev at this time?
Any As gurus willing to help please contact me off list.  
Thanks___




Jim Ault
Las Vegas



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Do ... as Applescript, bugs??

[Ian Wood]

On 11 Apr 2010, at 17:22, Andrew Meit wrote:

I am struggling to figure out why do as Applescript works once  
correctly but second time its fired off, Rev hangs and returns  
"execution error". My As code works correctly within the As editor  
all the time. I am talking directly to the Applescript editor with  
my do statements. I am using 4.0. Are there known bugs with As with  
Rev at this time?

Any As gurus willing to help please contact me off list. Thanks


Can you post a sample of your script?

Also, are you scripting the Script Editor itself? Otherwise there  
should be no need to talk to it.


Ian
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Do ... as Applescript, bugs??

[Mark Schonewille]

Andrew,

I don't understand how Rev can hang and still return something. What  
do you mean exactly?


It is probably wrong to talk directly to the AppleScript editor. I  
can't think of any reason why one would want that. What are you trying  
to do?


Please, post your script. I'd be happy to try to help you on-list.

--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer

Share the clipboard of your computer with other computers on a local  
network with Clipboard Link

http://clipbaordlink.economy-x-talk.com

Op 11 apr 2010, om 18:22 heeft Andrew Meit het volgende geschreven:

I am struggling to figure out why do as Applescript works once  
correctly but second time its fired off, Rev hangs and returns  
"execution error". My As code works correctly within the As editor  
all the time. I am talking directly to the Applescript editor with  
my do statements. I am using 4.0. Are there known bugs with As with  
Rev at this time?

Any As gurus willing to help please contact me off list. Thanks




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Do ... as Applescript, bugs??

[Andrew Meit]

I am struggling to figure out why do as Applescript works once correctly but 
second time its fired off, Rev hangs and returns "execution error". My As code 
works correctly within the As editor all the time. I am talking directly to the 
Applescript editor with my do statements. I am using 4.0. Are there known bugs 
with As with Rev at this time? 
Any As gurus willing to help please contact me off list. 
Thanks___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

ARGH! How are we supposed to enter RevServer bugs in the quality center when RevServer is not among the build platforms!?

[Andre Garzia]

Folks,

I am trying to enter some bug reports on Bugzilla/Quality Center regarding
RevServer being somewhat crippled. On the components drop down, the one that
lists the builds such as desktop, web, plugin, there's no entry for
RevServer, so, how to proceed?

The On-Rev forum has a bug Forum but then, do they check it?

Argh!

Andre

-- 
http://www.andregarzia.com All We Do Is Code.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Groups: Bugs and features ("last group" broken)?

[Mark Schonewille]

Yup! The owner is the solution. I just ran into the very same problem  
and not knowing which group has been created, I can use the owner of a  
grouped object, because I know which objects have been grouped :-) The  
other issues don't seem to affect me that much at this moment.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com

Submit your software at http://www.quickestpublisher.com

On 16 sep 2009, at 21:54, Wilhelm Sanke wrote:

Thanks for the confirmation of one of the group issues I listed in  
my post. I must have missed the thread in May being out of office  
and country at that time.


Using Scott's "templategroup" proposal may be handy when only one  
group building is involved.


In the case of my "Gradient Kaleidoscope" scripts I have to make  
frequent use of grouping and ungrouping (the last group) of images,  
and I find it easier and more convenient to use the workaround with  
finding the "owner" of one of the controls that have been grouped,  
as in -  I quote myself here -


"select fld "one" and fld "two"
group
put the owner of fld "one" into tlastgroup"


Best regards,

Wilhelm Sanke


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Groups: Bugs and features ("last group" broken)?

[DunbarX]

Wilhelm:

Workarounds. That is one of the endearing things about Rev.

I still like the templateGroup method, where, for example, you could set 
the name of each new group to some text (like "groupNumber") appended with the 
number of groups plus 1. So the last group of 15 would be:

group "groupNumber15"

This ties up the name of the templateGroup, of course.

Ken Ray suggested trapping the "newGroup" message. I suppose you could use 
this to set a property or the group name, similar to the templateGroup 
scenario.

Any of these can get you any group you need, just querying them all.

Craig Newman

In a message dated 9/16/09 3:55:02 PM, sa...@hrz.uni-kassel.de writes:


> In the case of my "Gradient Kaleidoscope" scripts I have to make
> frequent use of grouping and ungrouping (the last group) of images, and
> I find it easier and more convenient to use the workaround with finding
> the "owner" of one of the controls that have been grouped, as in -  I
> quote myself here -
> 

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Groups: Bugs and features ("last group" broken)?

[Wilhelm Sanke]

On Wed Sep 16, 2009, DunbarX at aol.com DunbarX at aol.com wrote

Yes, I ran into at least one of your issues back in May. Check out the 
"New

groups bugaboo" thread in the archives.

Eventually I was led to a very cool feature (by Scott Rossi), the
"templateGroup". Check this out. It is very stable. This is something 
solid; using
the somewhat ephemeral "last" keyword as a hard tool always seemed 
like a very

cute, but a little dishonest, methodology.

Apparently this is only a problem with groups. The "last" keyword works
fine with, say, buttons.

Craig Newman


Thanks for the confirmation of one of the group issues I listed in my 
post. I must have missed the thread in May being out of office and 
country at that time.


Using Scott's "templategroup" proposal may be handy when only one group 
building is involved.


In the case of my "Gradient Kaleidoscope" scripts I have to make 
frequent use of grouping and ungrouping (the last group) of images, and 
I find it easier and more convenient to use the workaround with finding 
the "owner" of one of the controls that have been grouped, as in -  I 
quote myself here -


 "select fld "one" and fld "two"
 group
 put the owner of fld "one" into tlastgroup"


Best regards,

Wilhelm Sanke

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Groups: Bugs and features ("last group" broken)?

[DunbarX]

Yes, I ran into at least one of your issues back in May. Check out the "New 
groups bugaboo" thread in the archives.

Eventually I was led to a very cool feature (by Scott Rossi), the 
"templateGroup". Check this out. It is very stable. This is something solid; 
using 
the somewhat ephemeral "last" keyword as a hard tool always seemed like a very 
cute, but a little dishonest, methodology.

Apparently this is only a problem with groups. The "last" keyword works 
fine with, say, buttons.

Craig Newman
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Groups: Bugs and features ("last group" broken)?

[Wilhelm Sanke]

I will discuss a number of peculiarities concerning groups.

1. "last group" is broken, at least it is unreliable
2. Rev remembers group names, even after you have ungrouped a group
3. If you select controls and group them by script the handles of the 
group are shown

4. You cannot paint on an image when it is grouped
5. Groups belong to the factors in an already reported scenario for 
safely crashing Rev


1. "last group" is broken, at least it is unreliable

From the dictionary

"Tip:  To refer to the newly-created group, use the last keyword:

 group button "Yes" and button "No"
 set the name of last group to "Do It""

Unfortunately, this is no longer the case - or has never been?. "last 
group" may indeed still refer to newly created groups, but there are a 
number of scenarios where this does *not* apply.

One example:

Create a group consisting of two graphics. Then create two fields and 
run the following script:


"on mouseUp
 select fld "one" and fld "two"
 group
 put the name of last group
end mouseUp"

You will get the name of the group of graphics, not that of the fields! 
Conclusion:


If the topmost group consists of graphics and that graphics' group is 
also on the top layer, then a newly created group of fields will not be 
the "last group" - although it may be even placed on the top layer.


This bug is apparently also the cause for sometimes creating nested 
groups up to 9 levels deep, a phenomenon I had mentioned in my last 
crash report "How to reliably crash Rev 3.5 and 4.0-dp3 with four script 
lines".


Workarounds:
To be on the safe side, I have rewritten my relevant scripts using the 
"owner" property, like

"on mouseUp
 select fld "one" and fld "two"
 group
 put the owner of fld "one" into tlastgroup
end mouseUp"

Another, more circumstantial, workaround would be to use the "newgroup" 
keyword in an accompanying card script:

"on newgroup
global glastgroup
 put the name of the target into glastgroup
end newgroup"

and then refer to the global "glastgroup" in your button script.


2. Rev remembers group names, even after you have ungrouped a group

Example: Create two fields, group them, and give the group a name. Then 
ungroup this group.
If you now - or at a later time - group these same two fields again, 
they will automatically get the name given to that group the first time.


Interesting "feature", what purpose would it serve?


3. If you select controls and group them by script the handles of the 
group are shown


If you are in "pointer tool" mode it is convenient to see the handles of 
controls and groups in order to be able to select and manipulate them 
manually, but if you select and group in a script you do not need this 
"help", it is a nuisance at best.


Although you are in "browse tool" mode when you run the script

" select fld "one" and fld "two"
 group"

the handles of the group will be shown. If you would like to take a 
snapshot of the newly created group ( "(rect of group tlastgroup) of 
this card"), this snapshot would include the handles.


Workaround: Add two lines to the script

" select fld "one" and fld "two"
 group
 choose pointer tool
 choose browse tool".

The same holds for the ungroup command.
==

4. You cannot paint on an image when it is grouped

This is a bug - or feature? - that has already been discussed several times.

If you want to paint on a grouped image by script - for example using 
the "drag" command - you have first to move the image out of the group 
and then later put it back into the group, like in


"on mouseUp
 set the relayergroupedcontrols to true
 put the layer of img "x" into tlayer
 set the layer of img "x" to top
 send "mouseup" to btn "drag on image x"
 set the layer of img "x" to tlayer
 set the relayergroupedcontrols to false
end mouseUp"

Applying the global property "selectGroupedControls" or the new group 
property with the same name "selectGroupedControls" (introduced in Rev 
3.5) does not  make a difference, at least I did not succeed in putting 
together another workaround.



5. Groups belong to the factors in an already reported scenario for 
safely crashing Rev


I have described this in detail in my recent post to this list "How to 
reliably crash Rev 3.5 and 4.0-dp3 with four script lines". Here I just 
point out that "group" is among the elements causing to crash Rev and 
refer you to my original post for more details.


The following script assumes that you have set the angle of img "test" 
to an angle other than 0, that img "test" is ungrouped, and that img 
"Test" belongs in the category of "Pre-PNGs".


 "lock screen
 select img "Test"
 group
 set the angle of img "Test" to 0"

For the definition of "Pre-PNGs" see my above-mentioned post or the 
introduction to my stack


 in the text 
brought up on the menu card from the topright introduction butt

Re: is it worth reporting bugs in 2.6.1?

[Mark Schonewille]

Hi Bernard,

The first part of this bug was reported already as <http://quality.runrev.com/qacenter/show_bug.cgi?id=6348 
> some time ago.


Since the close box issue exists in 2.6.1 but --if I understand you  
correctly-- seems to be resolved in 3.0, it makes no sense to report it.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com
http://www.salery.biz
Dutch forum: http://runrev.info/rrforum/

Benefit from our inexpensive hosting services. See http://economy-x-talk.com/server.html 
 for more info.


On 3 okt 2008, at 14:33, Bernard Devlin wrote:

The first thing I did after installing 2.6.1 on Linux was to run  
Bjoernke's
chat rev stack (http://bjoernke.com/runrev/chatrev.php), since it  
presented
so many problems in Rev 3.0 Linux.  After creating a legacy stack  
using 3.0,
in 2.6.1 I was at least able to submit more than a few lines to my  
chat
server, without the IDE locking up.  Even though 2.6.1 looks worse  
than 3.0,
I was feeling relieved.  At least I have a version of Rev that looks  
like I

might be able to work with it.

Then I noticed, that the chat rev stack had no 'close' decoration.  I
checked back in 3.0 and it has a 'close' decoration there.  So I  
opened up
my Ubuntu VM and installed 2.6.1 there.  There too in 3.0 it has a  
close

decoration, but not in 2.6.1.

So the same legacy stack opened in 2.6.1 on Ubuntu and Fedora has no  
'close'
decoration, but on 3.0 it does have a 'close' decoration (and  
'close' is one
of the items of the decorations of the stack).  Oh, and whilst I had  
that

legacy stack open on 3.0 on ubuntu, the IDE crashed.  This was a
freshly-restarted VM, and within 2 minutes of being opened Rev 3.0  
crashed.

I had done nothing but open chatrev.

Is it possible there is something in that stack that could be causing
problems?  I have a lot of respect for the skills of Bjoernke and  
the other
chat rev users, so I find it hard to believe that they would not  
have found
any obvious bugs in the stack by now, and reported them or worked  
round

them.

Chatrev is not the only thing I've had problems with in 3.0, but  
since I am
also seeing such bizarre behaviour in 2.6.1, I'm starting to think I  
am

jinxed.

I'm tired of weeks of bug tracking, and just want to get back to  
doing some
developmen, using Linux on my new laptop.  Is there any point in  
adding this

information to QCC?

Bernard.



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

is it worth reporting bugs in 2.6.1?

[Bernard Devlin]

The first thing I did after installing 2.6.1 on Linux was to run Bjoernke's
chat rev stack (http://bjoernke.com/runrev/chatrev.php), since it presented
so many problems in Rev 3.0 Linux.  After creating a legacy stack using 3.0,
in 2.6.1 I was at least able to submit more than a few lines to my chat
server, without the IDE locking up.  Even though 2.6.1 looks worse than 3.0,
I was feeling relieved.  At least I have a version of Rev that looks like I
might be able to work with it.

Then I noticed, that the chat rev stack had no 'close' decoration.  I
checked back in 3.0 and it has a 'close' decoration there.  So I opened up
my Ubuntu VM and installed 2.6.1 there.  There too in 3.0 it has a close
decoration, but not in 2.6.1.

So the same legacy stack opened in 2.6.1 on Ubuntu and Fedora has no 'close'
decoration, but on 3.0 it does have a 'close' decoration (and 'close' is one
of the items of the decorations of the stack).  Oh, and whilst I had that
legacy stack open on 3.0 on ubuntu, the IDE crashed.  This was a
freshly-restarted VM, and within 2 minutes of being opened Rev 3.0 crashed.
 I had done nothing but open chatrev.

Is it possible there is something in that stack that could be causing
problems?  I have a lot of respect for the skills of Bjoernke and the other
chat rev users, so I find it hard to believe that they would not have found
any obvious bugs in the stack by now, and reported them or worked round
them.

Chatrev is not the only thing I've had problems with in 3.0, but since I am
also seeing such bizarre behaviour in 2.6.1, I'm starting to think I am
jinxed.

I'm tired of weeks of bug tracking, and just want to get back to doing some
developmen, using Linux on my new laptop.  Is there any point in adding this
information to QCC?

Bernard.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: OT: Doc Bugs (mine!) - A Lesson To Be Learned

[Paul Looney]

Ken,
Thanks for the ever-timely reminder.
I'd add one rule I consider critical:
Get a "typical" user to read the docs and run the software while you  
watch and take notes.

Paul Looney


On May 31, 2008, at 3:18 PM, Ken Ray wrote:


As you may have already seen, I released a new version of the STS XML
Library today. One of the main reasons for doing this is that the  
previous
documentation, which I had prized quite highly as being clear,  
thoughtful,

and informatory.

Someone who recently purchased the Library pointed out several doc  
bugs that
have actually been in there for a long time. Anyone who was trying  
to follow
the examples I gave would fail because of the errors, and this  
could have
easily caused people evaluating the Library to turn away and think  
it's too

difficult to use or they just can't "get it".

The new version has these issues resolved, and is much better at  
guiding new

users into using the Library.

Why am I bringing this up? So you all can avoid this in *your*  
application's
documentation (assuming it is to be printed or viewed as a PDF,  
like mine

is).

Here's a handful of simple rules that have come out of this (I'm  
sure there

are more, but these are the ones that "bit" me):

1) Test All Example Code

  If you include example code in your docs, make sure you  
*test* it
first, ESPECIALLY if you are copying and pasting code from another  
example
in the same docs, or copying it from a more comprehensive script  
that may

have dependencies on other functions/handlers/etc.
  This can especially become an issue when you are very  
comfortable
using common functions or handlers that are "always there" for you  
(because
of your framework, common libraries you use, etc.) that very well  
may not be
there in your user's hands. A good example of this is the q()  
function I use

that simple puts double quotes around a string:

function q pWhat
  return quote & pWhat & quote
end q

 I have used this function for many years, so it is second- 
nature to me
to put q() around strings I want quoted without thinking of the  
dependency
on the function. Hand out an example in docs that uses q() without  
providing

the function, and your users will get errors.

2) Check Page Numbers in TOCs
--
 If you include a table of contents in your app's docs, make  
sure that
before you ship that the TOC has been updated and points to the  
right pages.
Nothing is more frustrating than going to an incorrect page when  
you are

trying to learn a new app.

3) Watch Page Breaks
--
 I have seen too many sets of docs where code examples are  
split by a
page break at the inappropriate time, either leaving an "orphan" of  
a code
line on the next page, or worse, appearing to end properly, but  
there's
actually *more* code on the next page you didn't know about that's  
critical.

 It reminds me of the Raiders of the Lost Ark scene where Indy is
getting the amulet translated and the bad guys only have one part  
of it. The
translator tells Indy that the piece he has says to make a stick  
"ten Jamirs
high", and Indy's about to grab the amulet and leave when the  
translator
says "Wait, I am not finished!" and turns it over and reads "And  
add one
jamir to honor the Hebrew God whose Ark this is." Had there not  
been a break

between the two halves... ;-)

4) Read Your Own Docs As a New User Would

 After you *think* you are done with the docs, print them out  
and read
them as if you were a new user getting this application for the  
first time.
Imagine you know nothing about the program and that someone you  
respect has

just suggested to you that you take a look at it because "it's a great
program".  Look for all the little things that might drive you  
crazy as a
new user - inconsistent references, inconsistent use of text  
styles, indexes
that don't point to the right place, etc. I'm sure you'll find a  
number of

things you should change.

As I said, I know there's plenty more caveats to go through, but  
these four

are good ones, IMHO.

Just wanted to pass this along to anyone working on their own docs.  
You'll
never know how many people turned away from your product due to bad  
docs,
but if you know you have *good* docs, you can rest assured that no  
one will

turn away because of bad docs...

:-)

Ken Ray
Sons of Thunder Software, Inc.
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferenc

Re: OT: Doc Bugs (mine!) - A Lesson To Be Learned

[william humphrey]

I wish everyone would pay attention to their docs especially with the idea
of not only new users but ones that are also trying something new to them
and that might really need some instruction. I loved the Altuit docs that
was a RunRev stack for their MySQL plug-in. It thought that was a very clear
presentation which could be an example for anyone to follow.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

OT: Doc Bugs (mine!) - A Lesson To Be Learned

[Ken Ray]

As you may have already seen, I released a new version of the STS XML
Library today. One of the main reasons for doing this is that the previous
documentation, which I had prized quite highly as being clear, thoughtful,
and informatory.

Someone who recently purchased the Library pointed out several doc bugs that
have actually been in there for a long time. Anyone who was trying to follow
the examples I gave would fail because of the errors, and this could have
easily caused people evaluating the Library to turn away and think it's too
difficult to use or they just can't "get it".

The new version has these issues resolved, and is much better at guiding new
users into using the Library.

Why am I bringing this up? So you all can avoid this in *your* application's
documentation (assuming it is to be printed or viewed as a PDF, like mine
is). 

Here's a handful of simple rules that have come out of this (I'm sure there
are more, but these are the ones that "bit" me):

1) Test All Example Code

  If you include example code in your docs, make sure you *test* it
first, ESPECIALLY if you are copying and pasting code from another example
in the same docs, or copying it from a more comprehensive script that may
have dependencies on other functions/handlers/etc.
  This can especially become an issue when you are very comfortable
using common functions or handlers that are "always there" for you (because
of your framework, common libraries you use, etc.) that very well may not be
there in your user's hands. A good example of this is the q() function I use
that simple puts double quotes around a string:

function q pWhat
  return quote & pWhat & quote
end q

 I have used this function for many years, so it is second-nature to me
to put q() around strings I want quoted without thinking of the dependency
on the function. Hand out an example in docs that uses q() without providing
the function, and your users will get errors.

2) Check Page Numbers in TOCs
--
 If you include a table of contents in your app's docs, make sure that
before you ship that the TOC has been updated and points to the right pages.
Nothing is more frustrating than going to an incorrect page when you are
trying to learn a new app.

3) Watch Page Breaks
--
 I have seen too many sets of docs where code examples are split by a
page break at the inappropriate time, either leaving an "orphan" of a code
line on the next page, or worse, appearing to end properly, but there's
actually *more* code on the next page you didn't know about that's critical.
 It reminds me of the Raiders of the Lost Ark scene where Indy is
getting the amulet translated and the bad guys only have one part of it. The
translator tells Indy that the piece he has says to make a stick "ten Jamirs
high", and Indy's about to grab the amulet and leave when the translator
says "Wait, I am not finished!" and turns it over and reads "And add one
jamir to honor the Hebrew God whose Ark this is." Had there not been a break
between the two halves... ;-)

4) Read Your Own Docs As a New User Would

 After you *think* you are done with the docs, print them out and read
them as if you were a new user getting this application for the first time.
Imagine you know nothing about the program and that someone you respect has
just suggested to you that you take a look at it because "it's a great
program".  Look for all the little things that might drive you crazy as a
new user - inconsistent references, inconsistent use of text styles, indexes
that don't point to the right place, etc. I'm sure you'll find a number of
things you should change.

As I said, I know there's plenty more caveats to go through, but these four
are good ones, IMHO.

Just wanted to pass this along to anyone working on their own docs. You'll
never know how many people turned away from your product due to bad docs,
but if you know you have *good* docs, you can rest assured that no one will
turn away because of bad docs...

:-)

Ken Ray
Sons of Thunder Software, Inc.
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: able to log bugs now

[Richard Gaskin]

Colin Holgate wrote:
Meanwhile, I've logged four bugs, and that Mark is super fast at 
checking them out! It's the closest I've seen to real time bug 
tracking.


Welcome aboard.

Yes, Mark's been amazing, even more than usual.  I had occasion this 
morning to review several dozen bugs related to fields, and most of them 
were marked as "Fixed for 2.9".


Great job, Mr. Waddingham!


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

able to log bugs now

[Colin Holgate]

Just to let anyone who was interested know, I've managed to get a 
password. Apparently there's a convention that all emails have some 
sort of return address, even DoNotReply messages have one in there 
somewhere. It's so that it's possible to let the sender know if there 
is a problem. Unfortunately the Rev bugzilla emails don't have such 
an address, and so our company junk filter treats it as pure spam. 
I'm now set to be allowed to receive those messages, but it could be 
something that should be fixed at some point.


Meanwhile, I've logged four bugs, and that Mark is super fast at 
checking them out! It's the closest I've seen to real time bug 
tracking.


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: WAR ON BUGS [WAS Open Source (was Don't you just wish Rev, would do this?)]

[Bob Warren]

Thanks Jacque!  :-*

Bob
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: WAR ON BUGS [WAS Open Source (was Don't you just wish Rev, would do this?)]

[J. Landman Gay]

Bob Warren wrote:

When you mentioned "the roadmap" I was taken aback. What roadmap? 
"Enterprise" license holders and those who have the money to travel to 
conferences are undoubtedly more in the know because they are paying for 
it, but ordinary "Studio" license holders such as myself have little 
idea of what Rev plans to do.


Right. Enterprise users are under NDA and so they get more info. It's 
one of the perks. Conference attendees also sign an NDA. I guess the 
best that Studio and Media users can do is trust others when they say 
that things are going along according to plan.



1. Is there a need for regular Rev updates or not?


Sure there is. Runtime generally releases 4 to 6 updates per year, which 
is quite a lot for a multi-OS-compatible program. That's one every two 
to three months.


2. To know that a bug has been "fixed" doesn't help if the fix cannot be 
implemented within a reasonable time. Is "turnaround" in this sense 
anywhere near adequate at the moment?


You can tell which bugs have been fixed by searching the Quality Control 
center, using the "advanced" search option to look for bugs that have 
been fixed since a particular date. Those fixes will be in the next 
release, which will generally be within 3 months or so of the last one.




If you tell me that such wonderful things are already in the pipeline, 
then I am very pleased. But Rev didn't tell me.


Nor should they. Few companies release details on upcoming release 
timelines or what's included in them until the release is actually out. 
Can you tell me when the next update of Photoshop is due out and what 
will be in it?


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: WAR ON BUGS [WAS Open Source (was Don't you just wish Rev, would do this?)]

[Bob Warren]

Stephen Barncard wrote:

At 4:12 PM -0300 6/7/07, Bob Warren wrote:


1. RR should provide feature releases on a regular basis. We pay for them.
  
And we'll be getting them. It's in the roadmap, and Kevin is sticking to 
it.
>2. We do not pay for bugfixes. The manufacturer is just putting 
>right what he has done wrong.
  
We didn't pay for bug fixes. Runrev extended their free upgrade policy 
to customers for over a year while the WOB was going on.
>The other day, I put forward a model under the thread "A glimpse of 
>the future" which was totally ignored. I must therefore presume that 
>in the opinion of all
  
I don't think we're ignoring you, we're just exhausted from the 
negative. I feel Rev has emerged from a dark buggy period into the 
light. We've had a few 'Rev outa do this' emails lately where the poster 
seemed to go on and on and complain that Rev isn't doing enough to 
please him, and he takes the stand of 'demanding customer'. Arguments 
about 'bug free is impossible' vs 'it must be bug free, screw the new 
features' ensues. These threads go on for weeks, then die down, then 
another person (who didn't read the ones before) takes over. (I won't 
name names...) I will mention Bill Marriot was once a big complainer 
(with good reason)... but the difference is that he joined the Rev team, 
started a 'War On Bugs!' and made a difference. I'm glad Rev exists, and 
if a few bumps along the road are there, I won't complain as long as I 
know there's work being done on my wishes. They are not Microsoft and 
cannot deliver the manpower in the same way. Actually they have enlisted 
many of us in their efforts to improve the product, and I think that's 
far better than Microsoft. How can you help? When you see a bug, take 
the time to describe it enough to repeat it, or make a movie, or demo 
stack and send all of it to Quality Control. It will get fixed. I've 
seen it happen in days.


-
Thanks for that, Stephen. First of all, I think that Rev have been doing 
rather well lately, that's why I feel inspired enough to put forward 
some suggestions for further improvement. Do you think I should stop? 
How does one point out limitations in the current practice of the system 
without being "negative" as you suggest?


When you mentioned "the roadmap" I was taken aback. What roadmap? 
"Enterprise" license holders and those who have the money to travel to 
conferences are undoubtedly more in the know because they are paying for 
it, but ordinary "Studio" license holders such as myself have little 
idea of what Rev plans to do.  It is therefore very difficult for us to 
arrange our programming lives.


I didn't say we paid for bugfixes. I really don't know what we actually 
pay for, either directly or indirectly. It's not clear to me. What I did 
suggest is that upgrades should be (well) paid for and that they should 
not be for the purpose of bugfixing. Bugfixing should be done constantly 
in between releases. Certainly, this would make the situation a bit clearer.


As for the rest of your post, the only thing I will say is that I feel 
there is no need to put me into the category of the various stereotypes 
you mention, since they are all negative and you are obviously "bugged" 
about something. I am not one of your bugs, so please try and trust my 
intentions a little more.


Let me just ask you a few questions. In relation to current practices as 
they are seen by ordinary users:


1. Is there a need for regular Rev updates or not?
2. To know that a bug has been "fixed" doesn't help if the fix cannot be 
implemented within a reasonable time. Is "turnaround" in this sense 
anywhere near adequate at the moment?


If you tell me that such wonderful things are already in the pipeline, 
then I am very pleased. But Rev didn't tell me.


Bob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: WAR ON BUGS [WAS Open Source (was Don't you just wish Rev would do this?)]

[Stephen Barncard]

At 4:12 PM -0300 6/7/07, Bob Warren wrote:


1. RR should provide feature releases on a regular basis. We pay for them.


And we'll be getting them. It's in the roadmap, and Kevin is sticking to it.

2. We do not pay for bugfixes. The manufacturer is just putting 
right what he has done wrong.


We didn't pay for bug fixes. Runrev extended their free upgrade 
policy to customers for over a year while the WOB was going on.


The other day, I put forward a model under the thread "A glimpse of 
the future" which was totally ignored. I must therefore presume that 
in the opinion of all


I don't think we're ignoring you, we're just exhausted from the 
negative. I feel Rev has emerged from a dark buggy period into the 
light.


We've had a few 'Rev outa do this' emails lately where the poster 
seemed to go on and on and complain that Rev isn't doing enough to 
please him, and he takes the stand of 'demanding customer'. Arguments 
about 'bug free is impossible' vs 'it must be bug free, screw the new 
features' ensues. These threads go on for weeks, then die down, then 
another person (who didn't read the ones before) takes over. (I won't 
name names...)


I will mention Bill Marriot was once a big complainer (with good 
reason)... but the difference is that he joined the Rev team, started 
a 'War On Bugs!'  and made a difference.


 I'm glad Rev exists, and if a few bumps along the road are there, I 
won't complain as long as I know there's work being done on my 
wishes. They are not Microsoft and cannot deliver the manpower in the 
same way. Actually they have enlisted many of us in their efforts to 
improve the product, and I think that's far better than Microsoft.


How can you help?

When you see a bug, take the time to describe it enough to repeat it, 
or make a movie, or demo stack and send all of it to Quality Control. 
It will get fixed.  I've seen it happen in days.


sqb

--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Please vote for this bugs. All windows users.

[Girard Damien]

Hi all,

 

I encourage everybody to vote for this bug about scrollbar corrution under
Windows Vista and XP.

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

 

Regards, 

 

Damien

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Stack purging - and other bugs

[Francis Nugent Dixon]

Hi from Paris,

Please note syntax error in Hallowe'en ..
The ' means that a "v" is missing (Old English !)


Hi,

Well it is Halloween!

Dave



Francis (an ancient Celt !)

"Nothing should ever be done for the first time !"

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Ironing out the bugs, Web operability, and "more bang for your buck".

[Richmond Mathewson]

Dear Runtime Revolution afficionados,

It seems that there is one of those "merry storms"
brewing.

There seems to be some consensus about 2 points (which
are mentioned in the title of this posting).

I should like to point out some things that may be
being 
overlooked at the moment:

1. I am not at all sure that HC/MC/RR was ever
intended to be 
"the complete solution to all and everything that
concerns computers." 
I have always thought (maybe naively - permission to
jump all over me is herewith granted) that RR's
primary focus was on RAD. And, RAD normally bypasses
the whole jingbang anent the SDL - from "Zero to Hero"
in 3 easy moves. To have really Rapid RAD ( RRAD ??? )
one will, necessarily have to sacrifice some other
things along the way.

Some of us are still perfectly happy (for our needs)
with the capabilities of RR 2.0.1 (in fact I normally
use the 'Free' version of 2.0.1 and only worked for DC
2.6.1 and paid for RRMedia 2.7.1 because my conscience
started acting up) - 2.0.1 with the added Graphic
capabilities of 2.7.4 could be pushed at the
"educational crowd".

2. Bugs - all software has bugs; and at least RR lets
you work around most of them. Mind you . . . one would
expect big bugs to be sorted out fairly rapidly.

3. Web operability - yes, it would be super - either
one way or the other. However cheap-jacks like me who
are trying to stump up the dosh for RR Studio don't
suddenly want to find out that the price has taken a
quantum leap to pay for all the time and work that
have gone into designing the web-operability. So . . .
Um . . .

a two-tier system ??? RRWeb and RRNon-Web ???

4. More Bang for Your Buck  . . .

On the whole it often turns out to be "More Bucks for
Your Bang".

You can't have it both ways.

5. Why do I have a feeling (?) that it should not be
that difficult to make a standalone player that
incorporates all the bells and whistles of RR
Enterprise.

Looking forward to the "jumpings", sincerely, Richmond Mathewson



I have just read and signed the online petition:

   "Hinge & Bracket"

hosted on the web by PetitionOnline.com, the free online petition
service, at:

   http://www.PetitionOnline.com/HandB/

I personally agree with what this petition says, and I think you might
agree, too.  If you can spare a moment, please take a look, and 
consider signing yourself.

Richmond Mathewson




___ 
The all-new Yahoo! Mail goes wherever you go - free your email address from 
your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Stack purging - and other bugs

[Richard Gaskin]

Paul L wrote:

Richard, Jerry, Chipp, Jacque, Ken, Jeanne, Dave, Phil, et. al.,
Should bug #3937 be combined with bug #1081?
It has been so long, I'd forgotten about it.


I've marked mine as related to #1081.

GMTA :)

--
 Richard Gaskin
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Stack purging - and other bugs

[Dave]

Hi,

Well it is Halloween!

Dave

On 31 Oct 2006, at 16:36, Luis wrote:


Someone's middle name is Trouble... I like that.

Got my vote.

Cheers,

Luis.


Dave wrote:

Hi,
Sounds good to me! Just choose one though, 66, seems like a good  
choice, now as long as everyone votes for that one bug and no  
other bug, the count should go sky high!!!

Not sure if this is going to get us in Hot Water though!!!
All the Best
Dave
On 31 Oct 2006, at 16:15, [EMAIL PROTECTED] wrote:

OK Dave,
How about bug #66, from 2003?
Or 1619,   from 2004, which already has 108 votes - and is still  
listed as

"unconfirmed"?

I chose these because
1. They affect a lot of users
2. They are old - and past due for fixing
3. Their resolution would make the Rev experience significantly  
better
4. Their resolution would help restore some credibility to using  
Bugzilla

5. They are fixable with moderate effort and minimal side effects

I'd entertain other suggestions as well. Yours?
Paul Looney
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Stack purging - and other bugs

[SimPLsol]

OK Dave,
How about bug #66, from 2003?
Or 1619,   from 2004, which already has 108 votes - and is still listed as 
"unconfirmed"?

I chose these because
1. They affect a lot of users
2. They are old - and past due for fixing
3. Their resolution would make the Rev experience significantly better
4. Their resolution would help restore some credibility to using Bugzilla
5. They are fixable with moderate effort and minimal side effects

I'd entertain other suggestions as well. Yours?
Paul Looney
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Stack purging - and other bugs

[Dave]

Meant to say, it doesn't really bother me too much which one is voted  
for. I'll leave it to others that have more knowledge on what causes  
the most headaches. Just let me know which one you'd like me to vote  
for and I'll do it.


Just want *something* fixed!!

All the Best
Dave

Hi,

Sounds good to me! Just choose one though, 66, seems like a good  
choice, now as long as everyone votes for that one bug and no other  
bug, the count should go sky high!!!


Not sure if this is going to get us in Hot Water though!!!

All the Best
Dave

On 31 Oct 2006, at 16:15, [EMAIL PROTECTED] wrote:


OK Dave,
How about bug #66, from 2003?
Or 1619,   from 2004, which already has 108 votes - and is still  
listed as

"unconfirmed"?

I chose these because
1. They affect a lot of users
2. They are old - and past due for fixing
3. Their resolution would make the Rev experience significantly better
4. Their resolution would help restore some credibility to using  
Bugzilla

5. They are fixable with moderate effort and minimal side effects

I'd entertain other suggestions as well. Yours?
Paul Looney
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Stack purging - and other bugs

[Dave]

Hi,

Sounds good to me! Just choose one though, 66, seems like a good  
choice, now as long as everyone votes for that one bug and no other  
bug, the count should go sky high!!!


Not sure if this is going to get us in Hot Water though!!!

All the Best
Dave

On 31 Oct 2006, at 16:15, [EMAIL PROTECTED] wrote:


OK Dave,
How about bug #66, from 2003?
Or 1619,   from 2004, which already has 108 votes - and is still  
listed as

"unconfirmed"?

I chose these because
1. They affect a lot of users
2. They are old - and past due for fixing
3. Their resolution would make the Rev experience significantly better
4. Their resolution would help restore some credibility to using  
Bugzilla

5. They are fixable with moderate effort and minimal side effects

I'd entertain other suggestions as well. Yours?
Paul Looney
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Stack purging - and other bugs

[Luis]

Someone's middle name is Trouble... I like that.

Got my vote.

Cheers,

Luis.


Dave wrote:

Hi,

Sounds good to me! Just choose one though, 66, seems like a good choice, 
now as long as everyone votes for that one bug and no other bug, the 
count should go sky high!!!


Not sure if this is going to get us in Hot Water though!!!

All the Best
Dave

On 31 Oct 2006, at 16:15, [EMAIL PROTECTED] wrote:


OK Dave,
How about bug #66, from 2003?
Or 1619,   from 2004, which already has 108 votes - and is still 
listed as

"unconfirmed"?

I chose these because
1. They affect a lot of users
2. They are old - and past due for fixing
3. Their resolution would make the Rev experience significantly better
4. Their resolution would help restore some credibility to using Bugzilla
5. They are fixable with moderate effort and minimal side effects

I'd entertain other suggestions as well. Yours?
Paul Looney
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Stack purging - and other bugs

[Dave]

Hi All,

Yeah, and plenty of new stuff being added all the time, all with  
their own real and potential bugs.


One thing I thought of dong was to get as many people as possible to  
vote for just one bug and no others, this would drive the vote count  
way up on that one bug, would be hard not to fix *something* then!  
Then just repeat the process on the next bug!


What do you think?

Cheers
Dave

On 30 Oct 2006, at 23:04, [EMAIL PROTECTED] wrote:


Richard,
I voted for bug 3932 - but I'm not optimistic.
I voted for bug 1072 as well - ages ago - and nothing happened.
Lots of votes - over lots of years - little action.
Bugzilla seems to be a black hole into which votes go and out of which
nothing comes.
Paul Looney
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Stack purging - and other bugs

[SimPLsol]

Richard,
I voted for bug 3932 - but I'm not optimistic.
I voted for bug 1072 as well - ages ago - and nothing happened.
Lots of votes - over lots of years - little action.
Bugzilla seems to be a black hole into which votes go and out of which 
nothing comes.
Paul Looney
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re-2: Bugs in Revolution 2.7.3

[runrev260805]

Hi,

the stacks are working here under windows xp.

Regards,

Matthias


 Original Message 
Subject: Re: Bugs in Revolution 2.7.3 (13-Aug-2006 19:59)
From:[EMAIL PROTECTED]
To:  [EMAIL PROTECTED]

> Hello,
> 
> Thanks for the test.
> For bug # 2, it's not when calling a sub stack but a separate main  
> stack.
> Could you give a try with the provided stacks. It seems that the  
> "openStack" message is not catched.
> 
> Thanks, regards,
> 
> ÉrIC
> 
> 
> 
> To: use-revolution@lists.runrev.com


To: [EMAIL PROTECTED]
use-revolution@lists.runrev.com


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Bugs in Revolution 2.7.3

[Éric Miclo]

Hello,

Thanks for the test.
For bug # 2, it's not when calling a sub stack but a separate main  
stack.
Could you give a try with the provided stacks. It seems that the  
"openStack" message is not catched.


Thanks, regards,

ÉrIC




Le 13 août 06 à 19:38, [EMAIL PROTECTED] a écrit :


Hi,

Bug #1: the same here.
My os is Windows XP SP2 german.


Bug #2: cannot verify. I created a mainstack which hides itself in  
the "openCard" handler and opens a substack. That works for me  
here. If you want, send me your test file and i will check this out.


Best regards,

Matthias Rebbe

 Original Message 
Subject: Bugs in Revolution 2.7.3 (13-Aug-2006 16:17)
From:[EMAIL PROTECTED]
To:  [EMAIL PROTECTED]


Hello,

• Bug #1:

The version manager shows a lot of development versionsand not the
gold master of version 2.7.3.
Making version "2.7.3-dp-2" to default launches version 2.7.2

• Bug # 2:

I have an app where the first open stack just shows itself for  few
second then is hidden and another stack is opened.
This works fine until version 2.7.2. With version 2.7.3 it doesn't
work anymore.
I've tried to create just 2 simple stacks to test it and be sure
nothing else was involved with the bug and the results are the same.

Can anyone on the list confirm those 2 bugs? Thanks.

Regards,

ÉrIC

-- My NeXT computer will Be a Mac too! --

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution



To: use-revolution@lists.runrev.com
[EMAIL PROTECTED]
Cc:



To: [EMAIL PROTECTED]
use-revolution@lists.runrev.com





-- My NeXT computer will Be a Mac too! --

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Bugs in Revolution 2.7.3

[runrev260805]

Hi,

Bug #1: the same here. 
My os is Windows XP SP2 german.


Bug #2: cannot verify. I created a mainstack which hides itself in the 
"openCard" handler and opens a substack. That works for me here. If you want, 
send me your test file and i will check this out.

Best regards,

Matthias Rebbe

 Original Message 
Subject: Bugs in Revolution 2.7.3 (13-Aug-2006 16:17)
From:[EMAIL PROTECTED]
To:  [EMAIL PROTECTED]

> Hello,
> 
> • Bug #1:
> 
> The version manager shows a lot of development versionsand not the  
> gold master of version 2.7.3.
> Making version "2.7.3-dp-2" to default launches version 2.7.2
> 
> • Bug # 2:
> 
> I have an app where the first open stack just shows itself for  few  
> second then is hidden and another stack is opened.
> This works fine until version 2.7.2. With version 2.7.3 it doesn't  
> work anymore.
> I've tried to create just 2 simple stacks to test it and be sure  
> nothing else was involved with the bug and the results are the same.
> 
> Can anyone on the list confirm those 2 bugs? Thanks.
> 
> Regards,
> 
> ÉrIC
> 
> -- My NeXT computer will Be a Mac too! --
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 
> 
> 
> To: use-revolution@lists.runrev.com
> [EMAIL PROTECTED]
> Cc: 


To: [EMAIL PROTECTED]
use-revolution@lists.runrev.com


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Bugs in Revolution 2.7.3

[Éric Miclo]

Hello,

• Bug #1:

The version manager shows a lot of development versionsand not the  
gold master of version 2.7.3.

Making version "2.7.3-dp-2" to default launches version 2.7.2

• Bug # 2:

I have an app where the first open stack just shows itself for  few  
second then is hidden and another stack is opened.
This works fine until version 2.7.2. With version 2.7.3 it doesn't  
work anymore.
I've tried to create just 2 simple stacks to test it and be sure  
nothing else was involved with the bug and the results are the same.


Can anyone on the list confirm those 2 bugs? Thanks.

Regards,

ÉrIC

-- My NeXT computer will Be a Mac too! --

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Basic UI idiosyncrasies (bugs?) with 2.7.1 Win version

[Rob Cozens]

Moi:

selecting the standalone from the task bar when it is beneath another 
app unselects the other app but brings _no_ window to the front.


Unless one selects a window from the popup menu...   :{`)


Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Basic UI idiosyncrasies (bugs?) with 2.7.1 Win version

[Richard Gaskin]

Bob Earp wrote:
> I guess this is because Rev does not bind all of its components
> (and any open stack windows) together, as is standard Windows
> practice with other apps.

The behavior you describe would be appropriate for Mac OS 9 and 
earlier*, but Microsoft describes a different behavior in their Windows HIG:


When the user reactivates a primary window, the window and
all its secondary windows come to the top of the window
order and maintain their relative positions. If the user
activates a secondary window, its primary window comes to
the top of the window order along with the primary window's
other secondary windows.


Elsewhere they define "secondary windows" as:

   ...similar to primary windows but differ in some fundamental
   aspects. This chapter covers the common uses of secondary
   windows, such as property sheets, dialog boxes, palette
   windows, and message boxes.


Applying this to Rev paralance, it would seem reasonable to expect all 
windows which are not toplevel to come to the front (modeless and 
palette).


So while the suggestion that *all* windows come forward may not comply 
with Microsoft's guidelines, at least modeless and palettes should, like 
your observation about the Message Box.


In v2.6.1 (I haven't moved to v2.7.x yet), Rev brings palettes to the 
front, but not modeless.


Given that on Windows modeless windows have the same visual appearance 
as palettes (a silly design decision at MS; anyone know if they've 
improved that in Vista?), it becomes even clearer that modeless windows 
should be brought forward with toplevel stacks.


Is there a BZ request for this?

And is the loss of palettes being brought forward in v2.7 confirmable? 
That would definitely be a bug, and should be reported.




* Thankfully Apple made OS X consistent with all other major GUIs with 
the introduction of interleaved windows:


   Each application and document window exists in its own layer,
   so documents from different applications can be interleaved.
   Clicking a window to bring it to the front doesn’t disturb
   the layering order of any other window.



--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Basic UI idiosyncrasies (bugs?) with 2.7.1 Win version

[Rob Cozens]

Hi Bob,

if I have a stack open with the message box open (and no other Win app 
running) I will see the basic Revolution interface bar, the Tools 
palette, the Message Box window, and the stack window.  If I now open, 
say, Win Explorer it opens on the top of everything (correct/expected 
behaviour), but normal Windows behaviour then means I should be able 
to click on any visible part of the stack, or the Rev UI (Tools 
palette, Message Box, etc.) and everything to do with the Rev UI 
including the open stack windows should all come to the front.  
However, only the window you click on comes to the front, except in 
the case of clicking on the main Rev interface bar and then just some 
of the Rev components (not all !!) come to the front.


The same thing happens here--as I recently reported to someone whose 
compiled Rev standalone I was testing--with one additional bug:  
selecting the standalone from the task bar when it is beneath another 
app unselects the other app but brings _no_ window to the front.



Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Basic UI idiosyncrasies (bugs?) with 2.7.1 Win version

[Thomas McGrath III]

Hi Bob,

I have the same thing happening here but since I have a lot of other  
Win apps that also act this way I did not consider it a bug.


Tom

On May 19, 2006, at 4:14 AM, Bob Earp wrote:

Greetings from a very warm and sunny west coast, normally referred  
to by people not living here as the "wet" coast


I just had a chance to compare Mac vs. Win versions of 2.7.1 (side  
by each) and a number of basic UI idiosyncrasies (bugs?) really  
highlighted themselves on the Win side of things, and I was  
wondering if this is new to v2.7.1 or just new observations for  
me.  The most frustrating one is not being able to get the whole of  
the Rev UI and the opened stacks to be the topmost windows (with  
other Win apps open), when clicking on any of the Rev UI windows or  
an open stack window.


For example, if I have a stack open with the message box open (and  
no other Win app running) I will see the basic Revolution interface  
bar, the Tools palette, the Message Box window, and the stack  
window.  If I now open, say, Win Explorer it opens on the top of  
everything (correct/expected behaviour), but normal Windows  
behaviour then means I should be able to click on any visible part  
of the stack, or the Rev UI (Tools palette, Message Box, etc.) and  
everything to do with the Rev UI including the open stack windows  
should all come to the front.  However, only the window you click  
on comes to the front, except in the case of clicking on the main  
Rev interface bar and then just some of the Rev components (not  
all !!) come to the front.  I say "not all" as I know the  
Documentation doesn't, but I haven't had time to try every  
component !!


I guess this is because Rev does not bind all of its components  
(and any open stack windows) together, as is standard Windows  
practice with other apps.


I can't find anything on Bugzilla which is strange as I'm sure this  
sort of behaviour has existed for some time.  Am I missing a pref  
or something, or is this really just life with Rev running in  
Windows ?


Thanks, Bob...

PS. setting the Backdrop to true does not help !!
_
Express yourself instantly with MSN Messenger! Download today it's  
FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ 
___

use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


Thomas J McGrath III
[EMAIL PROTECTED]

Lazy River Software - http://www.lazyriversoftware.com

Lazy River Metal Art™ - http://www.lazyriversoftware.com/metal.html

Meeting Wear - http://www.cafepress.com/meetingwear

Semantic Compaction Systems - http://www.minspeak.com

SCIconics, LLC - http://www.sciconics.com/sciindex.html







___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Basic UI idiosyncrasies (bugs?) with 2.7.1 Win version

[Bob Earp]

Greetings from a very warm and sunny west coast, normally referred to by people 
not living here as the "wet" coast 
 
I just had a chance to compare Mac vs. Win versions of 2.7.1 (side by each) and 
a number of basic UI idiosyncrasies (bugs?) really highlighted themselves on 
the Win side of things, and I was wondering if this is new to v2.7.1 or just 
new observations for me.  The most frustrating one is not being able to get the 
whole of the Rev UI and the opened stacks to be the topmost windows (with other 
Win apps open), when clicking on any of the Rev UI windows or an open stack 
window.  
 
For example, if I have a stack open with the message box open (and no other Win 
app running) I will see the basic Revolution interface bar, the Tools palette, 
the Message Box window, and the stack window.  If I now open, say, Win Explorer 
it opens on the top of everything (correct/expected behaviour), but normal 
Windows behaviour then means I should be able to click on any visible part of 
the stack, or the Rev UI (Tools palette, Message Box, etc.) and everything to 
do with the Rev UI including the open stack windows should all come to the 
front.  However, only the window you click on comes to the front, except in the 
case of clicking on the main Rev interface bar and then just some of the Rev 
components (not all !!) come to the front.  I say "not all" as I know the 
Documentation doesn't, but I haven't had time to try every component !!
 
I guess this is because Rev does not bind all of its components (and any open 
stack windows) together, as is standard Windows practice with other apps.
 
I can't find anything on Bugzilla which is strange as I'm sure this sort of 
behaviour has existed for some time.  Am I missing a pref or something, or is 
this really just life with Rev running in Windows ?
 
Thanks, Bob...
 
PS. setting the Backdrop to true does not help !!
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Can't close a socket. Bugs ?

[Mark Schonewille]

Dear Girard,

One might also say: the port is already open and there is no reason  
to open it again. It looks like you have a script that accepts  
connections on ports 9850 and 9851. What exactly are you trying to do?


Best,

Mark

--

Economy-x-Talk
Consultancy and Software Engineering
http://economy-x-talk.com
http://www.salery.biz

Salery is the easiest way to get your own web store on-line: http:// 
www.salery.biz/salery.html



Op 27-apr-2005, om 22:43 heeft Girard Damien het volgende geschreven:


Hi all,

I am searching about how using socket in Runtime Revolution (for  
permit two software to communicate between

them).

But I have a strange bug.

I have opened and close after a socket, and I have got this strange  
result :


-> put opensockets()
9850
9851

-> open socket "127.0.0.1:9850" with message "DPComOpen"
socket is already open


Why runrev say that this socket is already open ? This socket is  
not in the opensockets() list.
This is really strange, because when I have got the same result  
after I have done this command :

close socket "127.0.0.1:9850"


I don't really understand. Why runrev say that the socket is  
opened ? and what he cannot unload this socket.

(the close socket command don't return anything).

Regards,

Girard Damien.



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Can't close a socket. Bugs ?

[Girard Damien]

Hi all,

I am searching about how using socket in Runtime Revolution (for permit  
two software to communicate between

them).

But I have a strange bug.

I have opened and close after a socket, and I have got this strange result  
:


-> put opensockets()
9850
9851

-> open socket "127.0.0.1:9850" with message "DPComOpen"
socket is already open


Why runrev say that this socket is already open ? This socket is not in  
the opensockets() list.
This is really strange, because when I have got the same result after I  
have done this command :

close socket "127.0.0.1:9850"


I don't really understand. Why runrev say that the socket is opened ? and  
what he cannot unload this socket.

(the close socket command don't return anything).

Regards,

Girard Damien.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Reporting fatal error bugs

[Mark Schonewille]

Hi Dave and everybody who struggles with error handling,

Earlier tonight, I started writing an e-mail to ask you more about  
the error messages you received, but since you have already solved  
the issue, I'll have to re-write my message before I send it.


When Windows reports a fatal error, I suppose there is little to do  
about it, other than to insist that your users/customers try harder  
to find the cause of the problem. If it is Revolution that reports  
the error, you might want to have more options to collect debugging  
information.


Recently, a fellow-developer asked me to write a library to deal with  
execution errors. I have written a library, which I call errorLib,  
that parses the error information and shows this in a dialog window.  
The user can copy the information and paste it into an e-mail, for  
instance. In the IDE, it lets you open and edit a script, just like  
Revolution's built-in error handling features do, but without the  
danger of getting trapped by the revErrorDisplay stack. You can also  
write errors to alog file for further analyses. The library comes  
with detailed documentation.


I would appreciate to receive some feedback. It would be very useful  
to know which features other Revolution developers would like to see.  
Contact me off-list if you would like to test a trial version of my  
ErrorLib.


Best,

Mark

--

Economy-x-Talk
Consultancy and Software Engineering
http://economy-x-talk.com
http://www.salery.biz

Salery is the easiest way to set up your own web store: http:// 
www.salery.biz/salery.html



Op 6-apr-2006, om 18:05 heeft David Beck het volgende geschreven:




Hi,



As I've posted previously to the list many of my users have  
problems with a
rev standalone unexpectedly quitting do to illegal operations. I am  
getting
more and more reports of this problem (on both Win XP Pro and Home,  
using a
standalone built form Rev 2.6.1). There is no specific pattern as  
to when

the errors occur that I can determine but for many users it is a daily
event. In a response to an earlier post somebody suggested that I  
start a
bugzilla report for the errors and post any crash logs to that  
report. Two

questions:



1. Where do I go to log this problem to bugzilla?

2. How can my users capture the error logs from the Windows illegal
operation error dialog? I have tried to capture these logs before  
but have
not been able to figure it out. I can't copy the contents of the  
log; I
can't find an option to save it to a file. The only options are  
"Send",

"Don't Send", and view the log, but no way to extract the data!



Thanks,

Dave


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

problem found (was Re: Reporting fatal error bugs)

[Dave Beck]

First of all sorry about the recent re-post of the last message in this
thread. It was sent from a different address weeks ago and it must have just
got through moderator approval today.

In any event I just wanted to let the list know that I believe I identified
at least one of the major issues that was causing these very common fatal
errors in the standalone. The problem was related to launching a program via
the "launch" command. The program was a "launcher" program that actually
just opened up another file and then quit. However, once a few instances of
this program were launched Rev would fatal quit. I have crash logs and the
problem is more or less consistently reproducible even in the development
environment, so I guess the next step is to bugzilla it and see if it gets
fixed? For now I found that using the shell function to launch the program
instead of the launch command seems to fix the problem.

Thanks for everybody's input on this matter.

Dave

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reporting fatal error bugs

[David Beck]

 

Hi,

 

As I've posted previously to the list many of my users have problems with a
rev standalone unexpectedly quitting do to illegal operations. I am getting
more and more reports of this problem (on both Win XP Pro and Home, using a
standalone built form Rev 2.6.1). There is no specific pattern as to when
the errors occur that I can determine but for many users it is a daily
event. In a response to an earlier post somebody suggested that I start a
bugzilla report for the errors and post any crash logs to that report. Two
questions:

 

1. Where do I go to log this problem to bugzilla?

2. How can my users capture the error logs from the Windows illegal
operation error dialog? I have tried to capture these logs before but have
not been able to figure it out. I can't copy the contents of the log; I
can't find an option to save it to a file. The only options are "Send",
"Don't Send", and view the log, but no way to extract the data!

 

Thanks,

Dave

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: reporting fatal error bugs

[J. Landman Gay]

Dave Beck wrote:

Thanks Jacqueline,

But the question remains which log is helpful to post and where to find it.
There is no easy way to extract the log from the Microsoft Dr. Watson dialog
that I am aware of. In a previous post somebody suggested that the log of
interest was located at:

C:/Documents and Settings/All Users/Application Data/Microsoft/Dr
Watson/user.dmb

However, that to me appears to be gibberish binary data. There is another
file in that folder on my machine called "dtwtsn32.log". Is that the one?


I had to check on this. They'd like you to send both the binary and the 
log file. Sometimes either or both are useable. So, go for it, they want 
to see what Dr. Watson produces.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Rob Cozens]

Hi Dave,

what's the bug? The fact that it loops endlessly or the fact that the 
COA was non existent?


Well my buddy Bernie would say the bug is a user error for installing 
the A/R module before installing G/L and setting up the COA.  Actually 
it appears in the setup screen for any module that includes default G/L 
accounts:


If the G/L interface is checked, A/R account fields become required 
fields, and as the field closes the system verifies the contents in the 
COA.  Not finding the account, Flexware takes the user back to the 
field.  The only way to escape the loop without killing the computer or 
Flexware A/R is to go to another workstation and set up a COA.


Flexware modules were bundled individually, with a separate manual & CD 
for each.  I don't recall there being anything in the documentation 
advising sys admins to install G/L first if it was among the modules 
purchased.  And if there was, it didn't stop many users from having 
their first experience with Flexware--before it was even set up to do 
useful work--include finding a way out of an endless loop.


So Bernie could truthfully claim (on this point) "Flexware is bug-free 
if people use it correctly."  But in the real world, a significant 
number of users fell victim to this and similar "user" errors.


I believe the developer's job goes beyond delivering an application 
that works for her.  One has the obligation to provide the user a 
graceful escape mechanism when the user does something he wasn't 
supposed to do.


In this case, every Flexware setup screen that included default G/L 
accounts should, at the very least, disable the "G/L Installed" check 
box if the COA is not present.  Ideally, it would also display a dialog 
box explaining the box was disabled because the COA was not set up.  
Such a simple modification would have left first-time users with a much 
better feeling about Flexware then they got when told "That's your 
fault for not installing G/L first."


Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Geoff Canyon]

On Apr 10, 2006, at 10:11 PM, Tariel Gogoberidze wrote:


On Apr 9, 2006, at 1:00 PM, Geoff Canyon wrote:


Here is an example of something slightly larger than a single line
(and actually useful) that I think is bug-free:




on stableSetSize pID,W,H
   -- sets the width and height of pID
   -- while keeping the topleft the same
   try
 put the rect of pID into tRect
   catch tSomeError
 exit stableSetSize
   end try
   if W is a number then put item 1 of tRect + W into item 3 of tRect
   if H is a number then put item 2 of tRect + H into item 4 of tRect
   set the rect of pID to tRect
end stableSetSize



Assuming correct input  it seems to be bug free. However..

on mouseUp
  put "button 1" into PID
  put 500.2 into W -- !
  put 50.3 into H
  stableSetSize pID,W,H
end mouseUp

Throws execution error here "rectangle does not have 4 points"

:)


In discussion with a non-Rev-using friend earlier today (what, you  
don't spend your spare time discussing esoteric issues with your  
friends?) the idea of overflow was pointed out to me.


Note in my defense that the code is proof against non-integers, non- 
numbers, and negative numbers. So the only thing that should break it  
is too-large numbers.


That said, I noticed in the docs that if the lockLoc of an object is  
true, it resizes from the topleft. I thought this would be a good  
thing, but it means that I have to lock the screen in order to not  
show first the width changing, then the height. It also doesn't  
handle cds or groups, etc. So I stuck with the rectangle routine, but  
with more data checks:


on stableSetSize pID,W,H
  -- sets the width of and height of pID
  -- while keeping the topleft the same
  try
put the rect of pID into tRect
  catch tSomeErr
exit stableSetSize
  end try
  if W is a number then
if word 1 of pID is among the items of "image,img" and \
the platform is "MacOS" then
  put min(4096,W) into W  -- this is a temp
end if
put min(32767,W + item 1 of tRect) into item 3 of tRect
  end if
  if H is a number then put min(32767,H + item 2 of tRect) into item  
4 of tRect

  set the rect of pID to tRect
end stableSetSize

Maybe that will hold up a bit longer.

regards,

gc
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Tariel Gogoberidze]

On Apr 9, 2006, at 1:00 PM, Geoff Canyon wrote:


Here is an example of something slightly larger than a single line
(and actually useful) that I think is bug-free:




on stableSetSize pID,W,H
   -- sets the width and height of pID
   -- while keeping the topleft the same
   try
 put the rect of pID into tRect
   catch tSomeError
 exit stableSetSize
   end try
   if W is a number then put item 1 of tRect + W into item 3 of tRect
   if H is a number then put item 2 of tRect + H into item 4 of tRect
   set the rect of pID to tRect
end stableSetSize



Assuming correct input  it seems to be bug free. However..

on mouseUp
  put "button 1" into PID
  put 500.2 into W -- !
  put 50.3 into H
  stableSetSize pID,W,H
end mouseUp

Throws execution error here "rectangle does not have 4 points"

:)

best regards
Tariel

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: reporting fatal error bugs

[Dave Beck]

Thanks Jacqueline,

But the question remains which log is helpful to post and where to find it.
There is no easy way to extract the log from the Microsoft Dr. Watson dialog
that I am aware of. In a previous post somebody suggested that the log of
interest was located at:

C:/Documents and Settings/All Users/Application Data/Microsoft/Dr
Watson/user.dmb

However, that to me appears to be gibberish binary data. There is another
file in that folder on my machine called "dtwtsn32.log". Is that the one?

Thanks,

Dave

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Burgun]

On 10 Apr 2006, at 17:54, Robert Sneidar wrote:

It is theoretically possible to write bug free code, but the  
chances of doing it decrease exponentially with complexity. (For  
anything like software someone would actually want to use, the  
chances are about the same as the coin dropping to the ground and  
staying on it's side.)


That's just not true! Bugs do not necessarily increase as complexity  
increases it all a matter of coding correctly. It's true you cannot  
apply the same rules you use to develop complex software as you do to  
write trivial software, but if you stick to sound software  
engineering principals, then complex software is actually more stable.


Point in case, look at games like WarCraft I and II, StarCraft,  
Diablo II, SimCity, etc. etc. etc. these are increibly complex  
systems and they have very few bugs. Reason? Most of these games work  
on devices like the PlayStation and rely on the CD being correct,  
there's no downloading a bug-fix release in this case.


Another point in case, are mainframe OSes (like IBM/390), also as I  
have mentioned before check out SNOBOL4 and SPITBOL.


All the Best
Dave



.




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: reporting fatal error bugs

[J. Landman Gay]

Dave Beck wrote:

Might
somebody from the Rev team reading this post be able to chime in about what
is needed in order to have this issue addressed properly? 


Go here:



Paste the content of one or more logs into the Comments field, or else 
use the "create a new attachment" link to attach the logs. Click Commit. 
If you get more logs, repeat. If the team needs to see your stack(s) 
they can contact you. This is the best way to help the team track the 
problem.


Alternately, you can enclose your logs in an email, along with a 
description of the problem and a recipe to repeat it, which you can send 
to support at <[EMAIL PROTECTED]>. This method may take a little longer 
to process because it needs to wait in a queue until we move it to 
Bugzilla manually, but it is an acceptable way to report a problem and 
the lag isn't excessive.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Robert Sneidar]

It seems to me you guys are playing shell games with words. It's all  
a matter of semantics. "Bug" to one of you is not the same meaning as  
"bug" to another. So let me define "bug" for both of you. A bug is  
code that does not function the way the author of the code intended.  
If the author intended to fry your toaster when you clicked the "OK"  
button, and your toaster did in fact fry, it's NOT A BUG! If he did  
not intend it, it is. All talk of usability and expectations for end  
users is frivolous.


It is theoretically possible to write bug free code, but the chances  
of doing it decrease exponentially with complexity. (For anything  
like software someone would actually want to use, the chances are  
about the same as the coin dropping to the ground and staying on it's  
side.)


My experience is that if I try to be very very careful as I am  
writing the code not to make syntax errors, I don't get much coding  
done. My focus has to be mainly on concept. So what is the point to  
saying that I can write bug free code in theory? In practice I have  
proven that I cannot. And how would I ever be sure? Unless someone  
does the unexpected thing that triggers the bug, no one would ever  
know, including me. If a bug is never triggered, is it still a bug?  
If a tree falls in the woods... but I digress.


Such talk is silly. We live in an imperfect world with imperfect  
people. We produce imperfect things. We try to fix them when we find  
them. The only perfect man who ever showed up, we crucified. But not  
to worry, He's alright now. :-)


Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: reporting fatal error bugs

[Dave Beck]

Thanks Martin. I am very eager to have this problem addressed. We have about
250 installed users and we are getting almost daily reports now of the stack
*consistently* crashing on Windows XP (both Home and Pro) systems.

I looked at the user.dmp file and it seemed to be a bunch of binary data.
Then I looked at the "drwtsn32.log" file in the same "Dr Watson" folder and
it seemed to be more in line with what would be helpful to track this down.

The stack contains proprietary technology so I can't post it directly to the
bugzilla site, although we could post the standalone if it would help. Might
somebody from the Rev team reading this post be able to chime in about what
is needed in order to have this issue addressed properly? 

Thanks,

Dave

> I'm not an authority in this, but have been poking around in my XP 
> system to see if I can figure this out and it appears that DR Watson is 
> configured to write a mini crash dump file. I didn't configure it to do 
> that, so that is presumably a default.
>
> I had a crash in Thunderbird this morning and indeed found the relevant 
> crash dump in:
>
> C:\Documents and Settings\All Users\Application Data\Microsoft\Dr 
> Watson\user.dmp
>
> I found out where it was by double-clicking the drwtson32.exe which on 
> my system is in C:\WINDOWS\system32\
>
> Don't know if this helps, but I pass it on FWIW.
> 
> Martin Baxter

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Bugs

[David Burgun]

On 10 Apr 2006, at 02:13, Francis Nugent Dixon wrote:


Hi from Paris,

Many - many years ago, I came across a simple program
written to print out paychecks (in 1401 AutoCoder, for anybody
who wants to know). The input to the program was  you've
guessed it  ...  punched cards, containing basic information,
such as :

1 - a code (1 for man, 2 for woman),
2 - Employee code number (six digits),
3 - Employee name (25 characters)
4 - Number of hours worked in the week (3 digits)

The program needed the sex code, because the hourly
rate for a woman was less than that of a man (nothing has
changed, even 40 years later !).

Tests were conclusive, the programmer eliminated invalid
employee codes, and hours worked in excess of 45, etc, etc.
So the programmer did a run on REAL data for the current month.

The program blew 30 seconds later .. but only because the
employee was . neither a man or a woman ..

From then on, programmers were instructed to FIRST test their
programs with blank cards ...



Actually this is a good example for another reason. If you equate the  
"blank" card to the "empty" concept in TranScript, you will see that  
TranScript actually makes things a little worse in some cases here.  
By this I mean, you can get away with passing empty to RevRev  
functions etc. and it will accept them, even when they don't make  
sense. For instance:


if there is a folder myFolder then
new folder myFolder
end if

the part that handles "there is a folder" allows an empty string to  
be passed to it and fails. On the face of it this is good, it didn't  
identify "empty" as being a valid folder. The problem here is that  
you'd get the same result if "myFolder" contained a valid folder.   
The programmer in this example should have coded:


put empty into myFolder

if myFolder <> empty then
  if there is a folder myFolder then
  new folder myFolder
   end if
 end if

If the "there is a folder" clause generated an Execution Error if it  
were passed empty data, it would help a lot.


There are also a number of cases where "empty" is passed around which  
while they don't cause any problems immediately they cause more  
processing than is necessary to be performed. For instance:


put the keys of myArray into myKeysList
sort lines of myKeysList
repeat with myKeyIndex = 1 to the number of lines in myKeysList
end repeat

Here the extra "sort" operation was performed on an "empty" string,  
is just continued on and hit the repeat statement which then  
immediately failed. Here we are not talking about much overhead, but  
when I traced some code I wrote recently, I found that it was  
traveling down 4 layers of function calls, uselessly passing "empty".  
It was only when I added some code to the bottom layer that was  
"empty" intolerant did I notice the problem. For instance:


Stack;
function StackFunc theParam
local myParam

-- do something that is "empty" tolerant with theParam
put SomeCalc(theParam) into myParam
put CardFunc(myParam ) into myResult

return myResult
end StackFunc


Card:
function CardFunc theParam
local myParam

-- do something that is "empty" tolerant with theParam
put SomeCalc(theParam) into myParam
put GroupFunc(myParam ) into myResult

return myResult
end CardFunc


Group:
function GroupFunc theParam
local myParam

-- do something that is "empty" tolerant with theParam
put SomeCalc(theParam) into myParam
put ControlFunc(myParam ) into myResult

return myResult
end GroupFunc


Control:
function ControlFunc theParam
local myParam

-- do something that is "empty" tolerant with theParam
put SomeCalc(theParam) into myResult

return myResult
end ControlFunc

In this case "empty" was being passed needlessly, but harmlessly down  
4 layers. All is ok, until you add some empty non-tolerant code to  
one of the lower levels. In my case I added it to the Control.


All the Best
Dave







___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Geoff Canyon]

On Apr 9, 2006, at 5:21 PM, David Vaughan wrote:



On 10/04/2006, at 2:37, Geoff Canyon wrote:

The question is this: what do you think is the upper limit for  
_completely_ bug-free code?


Was your code bug-free the first time you wrote it, no typographic  
errors or any other changes? Do not answer that because it is only  
a lead-in to the next comment, that the upper limit is for code  
which can be made bug free with reasonable economic effort, and  
that is in my view controlled by the number of people involved.


I'll answer anyway -- nope, not bug free the first time I wrote it.  
The first version had:


  if W is not empty then put item 1 of tRect + W into item 3 of tRect

which of course fails if W is "test."



Your script worked well because you (I presume) conceived the  
requirement, the design and the implementation and it was self- 
documenting in that the descriptive text carries import to you  
which it may not for other people. I take it for the moment that  
you are also the user.


To the extent that you introduce new actors at any one of those  
five roles, you will increase the probability of bugs both arising  
and persisting.


Well, maybe we need to define our terms a bit. The genesis of this  
was the declaration that bug free means code free, so bugs in  
requirements don't really apply. I agree that it's possible for  
requirements to be vague, incomplete, or wrong, but that doesn't make  
a bug in the code.


If you introduce new actors, the requirements might change.

If you find new bugs because you introduce new actors, _not_ because  
the requirements changed, but simply because you missed them the  
first time, that means that the requirements (or your test plan)  
weren't complete.


I have some small to complex stacks which to the best of my  
knowledge are bug free, but no-one else uses them, they are  
substantially undocumented, and the design and usage pattern are  
perfectly matched, both being through me. I have little doubt that  
use by other people might expose real bugs and absolutely no doubt  
whatsoever that those other users would raise as bugs points which  
I considered to be "obvious" design choices or usages.


If the code meets your needs without fail, then it doesn't matter  
that the requirements are only in your head, they're complete, and  
your code is bug-free. Perhaps it has (numerous) documented (i.e. you  
know about them) limitations.


If the code doesn't behave correctly per your needs, then the code  
isn't bug-free. As the only user, you're the judge. If your code is  
anything like some of the utilities I've written for my own use, the  
requirements are very particular and limited -- as long as it gets  
the job done that needs doing at the moment, that's fine. That  
doesn't mean that the code is buggy per se, but it does mean that the  
code is likely limited and brittle.


If the code were to be used by other people, then the brittle nature  
of the code and lack of documentation is likely to raise issues. In  
addition, their requirements might be different than yours, in which  
case the code doesn't meet the requirements any more.


I have also a fairly complex stack with at least one obvious bug  
but I know about it and work around it because that costs me less  
effort, even on a regular basis, than investing in fixing that  
stack compared with my other development priorities which are  
themselves way below my other life priorities (reiterating for  
those who have not read it before that I do not develop software to  
order nor for product). Eventually, it will irritate me enough and  
I will have the spare time so I will fix it.


Then obviously it has a bug, but since you're the only person who has  
to live with it, it's obviously your call whether it needs to be fixed.


The last part was a bit of a digression. The main answer is that  
bugs arise less from code size than from the count of actors in the  
five steps from concept to use. A sufficiently complex project  
conceived, developed and used by a single person will merely not be  
finished while the development bugs are being ironed out. :-)


Then someone should be able to step forward with some large piece of  
code written by them, for them, which is completely bug free.


Likewise, there should be no one able to step forward with a piece of  
code of any size beyond tiny that is written by someone for general  
consumption that is completely bug free.


As far as I can see, the code I posted -- all eight lines of it ;-)  
-- is bug free for use by anyone. The requirement is reasonably  
clearly stated, and it will do what it says no matter what, given  
proper input, and given improper input it won't die.


I invite everyone (famous last words) to prove me wrong. If the code  
stands up, I'll try to find something twenty to thirty lines long  

Re: bugs

[Geoff Canyon]

On Apr 9, 2006, at 1:04 PM, Rob Cozens wrote:

Is it a bug that Parameter Setup didn't check for the existence of  
a COA when it opened?  By my definition, "yes", even if the specs  
didn't call for it.


The thing is, this calls for common sense, but what is common sense  
if it isn't specified?


To give an extreme example, suppose I open Revolution and type the  
following into the message box:


2+2=

and press return. Is it a bug that Revolution doesn't put 4? Common  
sense would say what should happen, but that's not what the spec says.


Obviously this is an extreme example, but the question is where does  
the line get drawn?


The only way to be certain to make sure the spec is complete, and  
code to the spec. In the example above, the spec should be amended  
before the behavior is considered a bug. The rationale for this is  
clear: what _should_ happen? I agree that an infinite loop is a bad  
thing, but I don't know what the right thing to do is.


So no -- if the behavior doesn't violate the specs, I wouldn't call  
it a bug.


But I agree completely that common sense pertains, and the  
requirements need to be updated.


regards,

geoff
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Bugs

[Francis Nugent Dixon]

Hi from Paris,

Many - many years ago, I came across a simple program
written to print out paychecks (in 1401 AutoCoder, for anybody
who wants to know). The input to the program was  you've
guessed it  ...  punched cards, containing basic information,
such as :

1 - a code (1 for man, 2 for woman),
2 - Employee code number (six digits),
3 - Employee name (25 characters)
4 - Number of hours worked in the week (3 digits)

The program needed the sex code, because the hourly
rate for a woman was less than that of a man (nothing has
changed, even 40 years later !).

Tests were conclusive, the programmer eliminated invalid
employee codes, and hours worked in excess of 45, etc, etc.
So the programmer did a run on REAL data for the current month.

The program blew 30 seconds later .. but only because the
employee was . neither a man or a woman ..

From then on, programmers were instructed to FIRST test their
programs with blank cards ...

Bugs usually exist because programmers don't think of things
that can NEVER happen, but do ! And their test data is usually
incomplete and insufficient !

When you flick a coin into the air, you might say that there is
a 50/50 chance of either heads or tails.

No Way ! - the coin may land on the edge, so you must envisage
the third (small) possibility ..

No Way - because the coin may not come down at all (at all !), so
you have to think of zero gravity ..

NOW - do you think we have covered all the bases in your "simple"
system ?  Norbert Weiner may not agree !

-Francis

"Nothing should ever be done for the first time !"


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Vaughan]

I forgot to mention the sixth actor, although alluding to it in my  
very first line below: inverse time.


David

On 10/04/2006, at 10:21, David Vaughan wrote:



On 10/04/2006, at 2:37, Geoff Canyon wrote:

The question is this: what do you think is the upper limit for  
_completely_ bug-free code?


Was your code bug-free the first time you wrote it, no typographic  
errors or any other changes? Do not answer that because it is only  
a lead-in to the next comment, that the upper limit is for code  
which can be made bug free with reasonable economic effort, and  
that is in my view controlled by the number of people involved.


Your script worked well because you (I presume) conceived the  
requirement, the design and the implementation and it was self- 
documenting in that the descriptive text carries import to you  
which it may not for other people. I take it for the moment that  
you are also the user.


To the extent that you introduce new actors at any one of those  
five roles, you will increase the probability of bugs both arising  
and persisting.


I have some small to complex stacks which to the best of my  
knowledge are bug free, but no-one else uses them, they are  
substantially undocumented, and the design and usage pattern are  
perfectly matched, both being through me. I have little doubt that  
use by other people might expose real bugs and absolutely no doubt  
whatsoever that those other users would raise as bugs points which  
I considered to be "obvious" design choices or usages.


I have also a fairly complex stack with at least one obvious bug  
but I know about it and work around it because that costs me less  
effort, even on a regular basis, than investing in fixing that  
stack compared with my other development priorities which are  
themselves way below my other life priorities (reiterating for  
those who have not read it before that I do not develop software to  
order nor for product). Eventually, it will irritate me enough and  
I will have the spare time so I will fix it.


The last part was a bit of a digression. The main answer is that  
bugs arise less from code size than from the count of actors in the  
five steps from concept to use. A sufficiently complex project  
conceived, developed and used by a single person will merely not be  
finished while the development bugs are being ironed out. :-)


cheers
David
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Vaughan]

On 10/04/2006, at 2:37, Geoff Canyon wrote:

The question is this: what do you think is the upper limit for  
_completely_ bug-free code?


Was your code bug-free the first time you wrote it, no typographic  
errors or any other changes? Do not answer that because it is only a  
lead-in to the next comment, that the upper limit is for code which  
can be made bug free with reasonable economic effort, and that is in  
my view controlled by the number of people involved.


Your script worked well because you (I presume) conceived the  
requirement, the design and the implementation and it was self- 
documenting in that the descriptive text carries import to you which  
it may not for other people. I take it for the moment that you are  
also the user.


To the extent that you introduce new actors at any one of those five  
roles, you will increase the probability of bugs both arising and  
persisting.


I have some small to complex stacks which to the best of my knowledge  
are bug free, but no-one else uses them, they are substantially  
undocumented, and the design and usage pattern are perfectly matched,  
both being through me. I have little doubt that use by other people  
might expose real bugs and absolutely no doubt whatsoever that those  
other users would raise as bugs points which I considered to be  
"obvious" design choices or usages.


I have also a fairly complex stack with at least one obvious bug but  
I know about it and work around it because that costs me less effort,  
even on a regular basis, than investing in fixing that stack compared  
with my other development priorities which are themselves way below  
my other life priorities (reiterating for those who have not read it  
before that I do not develop software to order nor for product).  
Eventually, it will irritate me enough and I will have the spare time  
so I will fix it.


The last part was a bit of a digression. The main answer is that bugs  
arise less from code size than from the count of actors in the five  
steps from concept to use. A sufficiently complex project conceived,  
developed and used by a single person will merely not be finished  
while the development bugs are being ironed out. :-)


cheers
David
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Vaughan]

On 10/04/2006, at 1:56, David Burgun wrote:


The real problem here is if the marketing department get ahold of  
it, they will make it into a "feature" ! e.g. this Application is  
"supposed" to tell you the time in the USA, it's so cool you don't  
have to figure it out for yourself, thereby cutting out the rest of  
the world from the product. Eventually when the US market slows  
down, they add a preference to allow the time to be shown in local  
time, call it an upgrade and charge everyone for the privilege of  
fixing the bug!


How many times you seen that happen???


:-)



All the Best
Dave

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Burgun]

On 9 Apr 2006, at 21:04, Rob Cozens wrote:


Geoff, et al:

Well, my international (from an american viewpoint) friend, how  
about this:


on mouseUp -- display the date
  answer the system date with "OK"
end mouseUp

The requirements are stated clearly in the comment, so the long  
date is out. The system date should work properly for you, correct?




Yes, the system date meets my requirement.

But I would point out that this is not an international issue per se:

Any user of Windows and MacOSes has the capability of specifying to  
the operating system the format in which dates, times, and numbers  
are displayed.  In my view, any software that ignores the user's  
preferences is flawed, and therefore buggy.  It may be a design  
bug, not a bug in the code; but it's a bug to moi.


Since my buddy Bernie isn't on the List, here's a further example  
at his expense:


Flexware's A/R Parameter Setup screen worked flawlessly...so long  
as the G/L module was not installed OR a Chart of Accounts was set  
up.  If the user indicated in the A/R Params that G/L was  
installed, the setup would loop endlessly trying to verify the  
first G/L account # in the parameters record if there were no COA  
set up.


Is it a bug that Parameter Setup didn't check for the existence of  
a COA when it opened?  By my definition, "yes", even if the specs  
didn't call for it.




Yes, but what's the bug? The fact that it loops endlessly or the fact  
that the COA was non existent? This is where robustness comes in,  
nearly every instance of a bug (with the exception of typeo's) is  
because something was assumed to be set to something that wasn't/ 
isn't set up!


All the Best
Dave

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Rob Cozens]

Geoff, et al:

Well, my international (from an american viewpoint) friend, how about 
this:


on mouseUp -- display the date
  answer the system date with "OK"
end mouseUp

The requirements are stated clearly in the comment, so the long date 
is out. The system date should work properly for you, correct?




Yes, the system date meets my requirement.

But I would point out that this is not an international issue per se:

Any user of Windows and MacOSes has the capability of specifying to the 
operating system the format in which dates, times, and numbers are 
displayed.  In my view, any software that ignores the user's 
preferences is flawed, and therefore buggy.  It may be a design bug, 
not a bug in the code; but it's a bug to moi.


Since my buddy Bernie isn't on the List, here's a further example at 
his expense:


Flexware's A/R Parameter Setup screen worked flawlessly...so long as 
the G/L module was not installed OR a Chart of Accounts was set up.  If 
the user indicated in the A/R Params that G/L was installed, the setup 
would loop endlessly trying to verify the first G/L account # in the 
parameters record if there were no COA set up.


Is it a bug that Parameter Setup didn't check for the existence of a 
COA when it opened?  By my definition, "yes", even if the specs didn't 
call for it.



Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Garrett Hylltun]

Geoff Canyon wrote:


On Apr 9, 2006, at 9:34 AM, Rob Cozens wrote:


Geoff,


The thing is, that is not a bug.  The programmer did not make any error
in his code at all.


You've removed the smiley; so I'm taking back some of that slack.

The original request was for bug-free SOFTWARE, not a bug-free CODE 
snippet.



  The code works as it was intended.



Ignoring for the moment that it was Garrett who wrote that and not me ;-)


Best to disregard my replies to this specific thread since I grossly 
mixed up people and comments within the thread itself.  Hard to make 
sense if you're not speaking to the right people, of the right people 
with the right information.  Besides, I don't make any sense in the 
first place.  :-)


-Garrett
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Rob Cozens]

Cousin Geoff,


I would argue that code that matches the specification _is_ bug-free.


I grant you that from the perspective of a programmer delivering 
software to a client or employer, if one has met the specs one might 
contend her work is "bug-free".  But I would err on the side of caution 
and limit my claim to "it meets the specifications".


Here's a situation that bites me every so often.  I wonder if others 
experience this and how they respond:


A client presents me with a specification for quote or comment , over 
time we enter into a working relationship, and I begin coding.


Somewhere into the process I get the nagging feeling things aren't 
working out, or that the design has some problematical aspects to it.  
Sometimes this just comes up during development, other times I have 
suggested alternatives and been told "No, this is the way we want it."


More often then not, there comes a time in this process when I can see 
the design specs are leading me to a dead end or dangerous territory.  
Then comes the issue: do I give the client what he asked for, or try to 
persuade him his real needs weren't  correctly articulated?  (Which 
sometimes depends on if I'm working time & materials or fixed bid.)  
Generally I find myself going down a dead-end road further than I 
should because "that's what the client specified."



Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Geoff Canyon]

On Apr 9, 2006, at 9:34 AM, Rob Cozens wrote:


Geoff,

The thing is, that is not a bug.  The programmer did not make any  
error

in his code at all.


You've removed the smiley; so I'm taking back some of that slack.

The original request was for bug-free SOFTWARE, not a bug-free CODE  
snippet.



  The code works as it was intended.



Ignoring for the moment that it was Garrett who wrote that and not  
me ;-)


The original statement I responded to was this:

On Apr 6, 2006, at 8:11 PM, Mark Wieder wrote:



As a QA engineer, I'd love to find some bug-free software someday.
Doesn't exist. Bug-free is code-free.


I agree that my example obviously qualifies as "software" only in the  
technical sense of the word. But I was really responding more to the  
statement after: "Bug-free is code-free." By _that_ statement, I  
think one line qualifies as a counter-example, if it is bug-free.



So you're in the same camp as my Flexware buddy, Bernie Mulcahy:  
"my software is bug-free if people use it correctly"?


I don't think I would ever phrase it that way. I'm reminded of a  
support issue I once dealt with. It was a hardware issue, but even so:


A user called because her cd drive wasn't working. I went to help.  
She wasn't there, so I put in a cd, and it worked. I left her a note  
and went back to my office. Later she called and said it still wasn't  
working for her. I don't remember how long it took me to do this, but  
eventually I asked her to show me what she was doing. Here's what she  
did:


She pushed the button to open the cd drive (this was on an old  
PowerMac with a tray drive). She put the cd into the tray, label side  
up as it should be. She then shoved the tray closed. I mean _shoved_.  
You could clearly hear the mechanism whining in protest as she forced  
it shut.


Now, I don't know why that should cause the Mac not to recognize the  
cd. After all, the cd was correctly in place to be read. The fact  
that she was destroying her drive's open/close mechanism shouldn't  
have any bearing on whether the Mac could read the cd. But it  
obviously and repeatably did.


So, the drive was bug-free as long as it was used correctly ;-)



Simply meeting a specification does not guarantee that every user  
who installs your software will experience no problems using it.   
The critiques posted by others list several valid deficiencies in  
your example.


Agreed re: specifications not being correct, but I would argue that  
code that matches the specification _is_ bug-free. The _requirements_  
have problems, but it isn't the code's job to exceed the  
requirements. I think people have listed valid deficiencies in my one- 
liner as you say, but I don't think anyone has demonstrated a bug  
(apart from the possible question of international date formats, now  
fixed).


Finally, a funny coincidence: my middle name is Garrett. But I'm not  
Garrett Hylltun in disguise. ;-)


Regards,

Geoffrey Garrett Canyon
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Geoff Canyon]

On Apr 9, 2006, at 2:04 AM, David Vaughan wrote:

As for my posts referring to your code, Geoff, I hoped I had made  
it sufficiently clear already that I was using it as a jumping off  
point to elaborate on the issues of what is a bug and differences  
in user experiences, and nothing at all to do with your code which  
I understood and accepted in the context in which you presented it.


Absolutely, no worries here.

This leads me to a question for those who agree with the following  
two statements:


 A. One line of code can be completely bug free -- regardless of  
whether or not my one line is in fact bug free ;-)
 B. It is (nearly) impossible to write large programs that are  
completely bug free.


The question is this: what do you think is the upper limit for  
_completely_ bug-free code?


Here is an example of something slightly larger than a single line  
(and actually useful) that I think is bug-free:


on stableSetSize pID,W,H
  -- sets the width and height of pID
  -- while keeping the topleft the same
  try
put the rect of pID into tRect
  catch tSomeError
exit stableSetSize
  end try
  if W is a number then put item 1 of tRect + W into item 3 of tRect
  if H is a number then put item 2 of tRect + H into item 4 of tRect
  set the rect of pID to tRect
end stableSetSize

Now someone point out to me that I've forgotten the built-in  
transcript property resizeFromTopLeft ;-)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Rob Cozens]

Geoff,



The thing is, that is not a bug.  The programmer did not make any 
error

in his code at all.


You've removed the smiley; so I'm taking back some of that slack.

The original request was for bug-free SOFTWARE, not a bug-free CODE 
snippet.



  The code works as it was intended.



So you're in the same camp as my Flexware buddy, Bernie Mulcahy: "my 
software is bug-free if people use it correctly"?


I write a lot of code that works the way it was intended  And I end 
up changing a lot of code during debugging because I and/or the user 
find that what was intended (ie: in the project specs) turns out to be 
flawed in implementation, doesn't address a real-world issue, leads the 
user in the wrong direction, or is simply inferior to a different 
approach that comes out of the testing process.


Simply meeting a specification does not guarantee that every user who 
installs your software will experience no problems using it.  The 
critiques posted by others list several valid deficiencies in your 
example.


Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Rob Cozens]

Hi Garrett,

So tell us, did your parents just take up the hind end and accept it 
as normal performance?


Pretty much.

 Or did they go after the builder?  Take them to court?  Did they win 
in court?


Not to my knowledge, no, & no.


Was the builder held responsible?


N/A


Did your parents have to pay to fix the errors?


"Have to", I don't know; "did", some; "lived with it", some.

In some ways it's like software bugs...the walls & roof didn't leak, 
the power & plumbing basically worked (once one remembered the faucets 
were reversed in one bathroom); so since the basic functionality was 
not impaired, they lived with or learned to work around the problems.


FWIW, the house is in Rancho Santa Fe, CA, and is now worth in excess 
of six figures.



Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Burgun]

On 8 Apr 2006, at 12:07, David Vaughan wrote:


So tell me what could go wrong? ;-)


I realised while cooking the salmon this evening (crocodile being  
off the menu) that Geoff had inadvertently provided a wonderful  
case study on bugs. Any link to Geoff in the following is purely  
coincidental and nothing to do with him at all :-)


Once upon a time, an aspiring programmer wrote:

on mouseUp -- display the date
  answer the date with "OK"
end mouseUp

and released it as shareware.

His American audience loved it. He received five star ratings on  
Versiontracker and plaudits on download.com, so impressed were  
users at being able to load an application, click a single button  
and see the date. Most impressive of all, it looked bug free.


Then, some old bloke from Australia gave a negative review,  
declaring the code contained a bug in that the information "4/8/06"  
for 8 April was simply wrong. A Frenchman wrote to say that the  
format should be "060408". Both complained that this was a clear- 
cut bug about which the developer should have known before  
releasing the software with the documentation "Displays the date".


Relying on precedents in  "Gutnick v. Dow Jones", they observed  
that even though the software was uploaded in America to an  
American server, it was published in Australia and France where it  
was read, and therefore subject to those foreign laws of fitness  
for purpose, with which any judge in those jurisdictions would  
agree ;-) Therefore, we have an indisputable bug in even this  
simple application.


Now that we know that no code is bug-free, two issues arise, one of  
morality and one of money.


Has the programmer committed an Immoral Act by publishing this  
software with a bug about which those foreign users believe he  
should surely have known?


What commercial decision should the programmer make? Add 33% more  
lines to the code ("set the useSystemDate to true") just to cater  
for foreign system dates, or add one word to the documentation so  
that it says "Displays the U.S. date"? One action will cost more  
than the other, and either will cost more than doing nothing and  
restricting his target market. Perhaps he should focus his  
development energies on his upcoming product "Displays the time"  
which he expects to sell at twice the price?


So, it appears that
- bugs happen, even when they are sincerely believed not to exist  
and with the best will in the world, and testing which seemed  
comprehensive at the time;
- money matters in commercial decisions without greed per se being  
a factor;
- the morality of the developer is not questioned by the discovered  
bug.


Perhaps RunRev has more bugs than it should have. That is something  
I do not know, but Lynn may on industry benchmarks. Regardless,  
bugginess is a relative question.


The real problem here is if the marketing department get ahold of it,  
they will make it into a "feature" ! e.g. this Application is  
"supposed" to tell you the time in the USA, it's so cool you don't  
have to figure it out for yourself, thereby cutting out the rest of  
the world from the product. Eventually when the US market slows down,  
they add a preference to allow the time to be shown in local time,  
call it an upgrade and charge everyone for the privilege of fixing  
the bug!


How many times you seen that happen???

All the Best
Dave








___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Mark Wieder]

Garrett-

Saturday, April 8, 2006, 11:30:44 PM, you wrote:

> You are correct.  I went back read the thread again and I do not see
> Mark making any statements to that regard.

> I apologize to Mark for my mistake.

Cool. I *was* wondering a bit at your logic. But I think I'll back my
way out of this thread now anyway. I don't know that it's really doing
any productive work anymore.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Mark Wieder]

Geoff-

Sunday, April 9, 2006, 12:44:31 AM, you wrote:

> On Apr 8, 2006, at 7:33 PM, Chipp Walters wrote:

>> I don't think anyone is attacking your programming prowess here.  
>> It's just that by providing a one line script and calling it a  
>> 'program' you invite questions.

> Am I coming off as defensive? It's not my intent. Based on your post:

...I don't see Geoff as coming off defensive, either. And I hope I'm
not seen as attacking him. To my knowledge, this is a discussion about
possible failure modes for the one line of code in question.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Vaughan]

On 09/04/2006, at 17:44, Geoff Canyon wrote:
I think you and I are agreed: the software itself is bug free.  
There seems to be debate over whether a bug in the code's context  
-- requirements, the engine, the OS, etc. -- qualifies as a bug in  
the software. I think it doesn't, but I can understand the point of  
people who think that's a useless distinction. In fact I'm likely  
to agree, but I still maintain that the code itself is bug free ;-)


It's funny that this all started as a joke, but I'm actually  
experiencing this as we speak: the windowshade control I released.  
I think the code is clean, but some people are having troubles with  
it. I can't replicate their errors, and there are others using it  
without troubles as well. Is there a context issue? Am I wrong that  
the code is clean? I'm stuck trying to figure that out. 


As for my posts referring to your code, Geoff, I hoped I had made it  
sufficiently clear already that I was using it as a jumping off point  
to elaborate on the issues of what is a bug and differences in user  
experiences, and nothing at all to do with your code which I  
understood and accepted in the context in which you presented it.


cheers
David


As far as my programming prowess is concerned, I hope it takes more  
than one line of code to judge that!


You are too modest 
LOL


regards,

Geoff

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Geoff Canyon]

On Apr 8, 2006, at 7:33 PM, Chipp Walters wrote:

I don't think anyone is attacking your programming prowess here.  
It's just that by providing a one line script and calling it a  
'program' you invite questions.


Am I coming off as defensive? It's not my intent. Based on your post:

On Apr 8, 2006, at 7:33 PM, Chipp Walters wrote:
Personally, I think your one line script looks bug free to me! I  
imagine after I run the finished program (how much you gonna  
charge?), I might have more to say ;-)


I think you and I are agreed: the software itself is bug free. There  
seems to be debate over whether a bug in the code's context --  
requirements, the engine, the OS, etc. -- qualifies as a bug in the  
software. I think it doesn't, but I can understand the point of  
people who think that's a useless distinction. In fact I'm likely to  
agree, but I still maintain that the code itself is bug free ;-)


It's funny that this all started as a joke, but I'm actually  
experiencing this as we speak: the windowshade control I released. I  
think the code is clean, but some people are having troubles with it.  
I can't replicate their errors, and there are others using it without  
troubles as well. Is there a context issue? Am I wrong that the code  
is clean? I'm stuck trying to figure that out. 


As far as my programming prowess is concerned, I hope it takes more  
than one line of code to judge that!


regards,

Geoff

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Garrett Hylltun]

David Vaughan wrote:


On 09/04/2006, at 9:26, Garrett Hylltun wrote:


  The intent of the code is far too obvious for you or anyone else 
here to say any different.

Ah, the sweetness of certainty; the certainty of not knowing.


You're just upset because your belief that bug free is impossible was 
shown to be wrong.
Mark did not put that position so far as I recall. Neither did I. You 
may recall I have consistently referred to questions of scale.  Either 
attack the correct person, or stop putting up straw men and go back to 
your contributions to this list.


You are correct.  I went back read the thread again and I do not see 
Mark making any statements to that regard.


I apologize to Mark for my mistake.

-Garrett
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Chipp Walters]

Geoff,

I don't think anyone is attacking your programming prowess here. It's 
just that by providing a one line script and calling it a 'program' you 
invite questions.


If it is in a button, and the cursor problem (where it disappears in XP, 
documented recently on this list), how does one 'click' the button w/out 
a cursor? That would be a bug. Course it wouldn't be for me, because 
even though I use XP I've never seen *that* bug (my guess it has to do 
with video drivers?). And it probably wouldn't be for you as certainly 
your code has nothing to do with cursors. But if you had a customer 
complain about it, then you would have to assume they have encountered 
what *they think* is a bug.


IOW, without a spec for the program and the platform and set user 
expectations, it's really hard to define what is a bug. As someone 
mentioned earlier, does Rev's insistence on storing the htmlText of a 
script as a custom prop of it's control, even when there's no script 
constitute a bug? Not an easy question to answer.


Personally, I think your one line script looks bug free to me! I imagine 
after I run the finished program (how much you gonna charge?), I might 
have more to say ;-)


It's all food for thought.

best regards,

Chipp

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Vaughan]

On 09/04/2006, at 9:26, Garrett Hylltun wrote:


  The intent of the code is far too obvious for you or anyone else  
here to say any different.

Ah, the sweetness of certainty; the certainty of not knowing.


You're just upset because your belief that bug free is impossible  
was shown to be wrong.
Mark did not put that position so far as I recall. Neither did I. You  
may recall I have consistently referred to questions of scale.   
Either attack the correct person, or stop putting up straw men and go  
back to your contributions to this list.


David


-Garrett


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Vaughan]

On 09/04/2006, at 6:23, Garrett Hylltun wrote:


The thing is, that is not a bug.  The programmer did not make any  
error in his code at all.  The code works as it was intended.


You could also claim that if a user in Japan downloaded the program  
and could not read it because it was in English and not Japanese,  
that he could say that the program has a bug.


Or a Linux user downloaded the Windows version, it would not run,  
so it must be a bug.


Your scenario is lacking completely, and rather a petty attempt to  
push your belief.


Garrett

Thank you for the ad hominem attack in your last line. Mark has  
already disposed of your prior argument that there is no bug  
("programmer's intention") so I will not elaborate on his concise  
statement. For your further enlightenment here is a set categories of  
bugs:

- Requirements defects
- Design defects
- Source code defects
- User documentation defects
- "Bad fixes", or secondary defects found in repairs to prior defects
[source: Capers-Jones, "Applied Software Measurement"]

Your attempt to dismiss the basis of the single coding example I used  
seems rather an attempt to avoid the three conclusions I drew.
- bugs happen, even when they are sincerely believed not to exist  
and with the best will in the world, and testing which seemed  
comprehensive at the time;
- money matters in commercial decisions without greed per se being  
a factor;
- the morality of the developer is not questioned by the discovered  
bug.


I will not discuss these further here with you because I see no point  
to it. I expect that great majority of developers would take these  
points as self-evident. If you wish to evangelise your position of  
bug-free heaven where commerce does not exist, write to me privately.  
Better still, write to someone else.


Where you have an actual bug of any category, post it to support or  
with Revzilla


David


-Garrett

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Garrett Hylltun]

Mark Wieder wrote:

Garrett-

Saturday, April 8, 2006, 1:23:55 PM, you wrote:


The thing is, that is not a bug.  The programmer did not make any error
in his code at all.  The code works as it was intended.


That's just silly. How do *you* know what was intended? The entire
requirements for this app seem to be defined in a three word comment

[snip]

And how do you know?  You make assumptions and then layout a plot that 
in itself is not even related to the code before you, making it more 
complicated than what it really is, just so you can find a way to back 
up your stance.  But the fact is, there was nothing there to back up 
your stance.  The intent of the code is far too obvious for you or 
anyone else here to say any different.  You can try to deter the 
attention to the obvious, but that's just not going to cut it.


The point was that the program is bug free.  And it is.  I can 
understand though that this does not really represent a real world 
application where there is far more code and more chances of bug getting 
into the scheme of things, but the fact still remains, the code that was 
provided is bug free, no if, and, or but about it.


You're just upset because your belief that bug free is impossible was 
shown to be wrong.


-Garrett
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Mark Wieder]

Garrett-

Saturday, April 8, 2006, 1:23:55 PM, you wrote:

> The thing is, that is not a bug.  The programmer did not make any error
> in his code at all.  The code works as it was intended.

That's just silly. How do *you* know what was intended? The entire
requirements for this app seem to be defined in a three word comment
placed in the script. What code would you write given the following
requirement?

-- display the text

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Mark Wieder]

Geoff-

Saturday, April 8, 2006, 12:24:12 PM, you wrote:

> 1. The requirements simply say to display the date -- the date is  
> displayed. If non-modality is needed, that should be in the  
> requirements.

...and conversely if a modal display is desired then that should be
spelled out...

> First you need a clear and complete set of requirements. Note that
> there is no equivocation there. The requirements must be totally  
> clear, and absolutely complete. The requirements must be such that  
> any reasonably intelligent person can sit down, read them, and then
> answer _any_ question about what the software is to do. Furthermore,

...

> I have never seen such requirements, nor really anything close to it,
> and that's okay. Requirements like that would be exceptionally hard
> to write, and most people are willing to deal with the issues that  
> come with easier-to-write vague specifications.

I have. I had the pleasure of working for a year and a half on a
project that spent the first 60% of the sdlc hammering out a
requirements document. This was the contract between development and
QA - they could each build from the same document and refer to it when
conflicts came up. We delivered the product more or less on time, more
or less bug-free (nothing major, nothing that you didn't have to go
way out of your way to find), and received awards for the finished
product. And this was a three-tiered java app with a mainframe backend
encrypting financial data across the internet. It *can* be done. And
done well.

> Quoting: "Consider these stats : the last three versions of the
> program -- each 420,000 lines long-had just one error each. The last
> 11 versions of this software had a total of 17 errors."

> The part I don't get is: if you have it down to just one bug, how  
> hard is it to find and fix that one bug?

ROTFL.

The article makes a point of pointing out a certain uniqueness:
"What makes it remarkable is how well the software works. This
software never crashes. It never needs to be re-booted. This software
is bug-free."

I notice, however, that even with "one error" in the last version of
the software "Four identical machines, running identical software,
pull information from thousands of sensors, make hundreds of
milli-second decisions, vote on every decision, check with each other
250 times a second. A fifth computer, with different software, stands
by to take control should the other four malfunction."

...and I love the tagline:
"The sooner you fall behind, the more time you will have to catch up."

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Garrett Hylltun]

Rob Cozens wrote:
[snip]

Must have been a spokesman for the building trades industry.:{`)

There is no house of any size or complexity that is "bug" free.

After first visiting my parents' new $80K home--which in the 1970s was a 
lot of $--my wife and I remarked to each other how shoddy the 
workmanship was.  Some plumbing fixtures were plumbed hot water to cold 
faucet, ill-fitting cabinetry, sloppy painting, etc.


So tell us, did your parents just take up the hind end and accept it as 
normal performance?  Or did they go after the builder?  Take them to 
court?  Did they win in court?  Was the builder held responsible?  Did 
your parents have to pay to fix the errors?


-Garrett
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Garrett Hylltun]

David Vaughan wrote:

So tell me what could go wrong? ;-)


I realised while cooking the salmon this evening (crocodile being off 
the menu) that Geoff had inadvertently provided a wonderful case study 
on bugs. Any link to Geoff in the following is purely coincidental and 
nothing to do with him at all :-)


Once upon a time, an aspiring programmer wrote:

on mouseUp -- display the date
  answer the date with "OK"
end mouseUp

and released it as shareware.


The thing is, that is not a bug.  The programmer did not make any error 
in his code at all.  The code works as it was intended.


You could also claim that if a user in Japan downloaded the program and 
could not read it because it was in English and not Japanese, that he 
could say that the program has a bug.


Or a Linux user downloaded the Windows version, it would not run, so it 
must be a bug.


Your scenario is lacking completely, and rather a petty attempt to push 
your belief.


-Garrett
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Geoff Canyon]

1. The requirements simply say to display the date -- the date is  
displayed. If non-modality is needed, that should be in the  
requirements.
2. It is certainly possible to put the code someplace inappropriate,  
but I think for the purposes of this assignment we can assume that  
isn't the case. To assume otherwise would be like if I say a car I'm  
selling runs fine and you say, "Not if I drop it out of an airplane."
3. Also a requirements issue. At the time the code is called, it will  
display the date. If the screen saver activates five minutes later,  
thus hiding the date, that's not a bug.
4. Dropping the car out of an airplane. The code _as presented_ is  
bug free, I believe.


I think it's important to note that I don't consider this code to be  
presented "out of context." It is the entire program, in one visible,  
enabled button, on the only card in one stack. It's not very useful,  
but for the extremely limited functionality that it provides, I think  
it is bug free.


My point is that I think it _is_ possible to write bug-free software.  
Not that I have ever done so, of course ;-) Writing bug-free software  
requires two things:


First you need a clear and complete set of requirements. Note that  
there is no equivocation there. The requirements must be totally  
clear, and absolutely complete. The requirements must be such that  
any reasonably intelligent person can sit down, read them, and then  
answer _any_ question about what the software is to do. Furthermore,  
such requirements, should map cleanly to a set of tests. The mapping  
should be bi-directional: given the requirements you should be able  
to produce the tests, and given the tests you should be able to  
produce the requirements.


I have never seen such requirements, nor really anything close to it,  
and that's okay. Requirements like that would be exceptionally hard  
to write, and most people are willing to deal with the issues that  
come with easier-to-write vague specifications.


Second, you need time and effort to work against those requirements.

There is an article on the Space Shuttle software that I find  
interesting:


http://www.fastcompany.com/online/06/writestuff.html

Quoting: "Consider these stats : the last three versions of the  
program -- each 420,000 lines long-had just one error each. The last  
11 versions of this software had a total of 17 errors."


The part I don't get is: if you have it down to just one bug, how  
hard is it to find and fix that one bug?


regards,

Geoff

On Apr 8, 2006, at 11:21 AM, Mark Wieder wrote:


Geoff-

Saturday, April 8, 2006, 12:21:38 AM, you wrote:


So tell me what could go wrong? ;-)


In addition to the "system" date already taken care of,

1. The date is displayed in a modal dialog, which makes further use of
the app impossible until it's dismissed.
2. The mouseUp handler is never called. Did you mean to put it into a
button instead of an unlocked field?
3. I brought up the answer dialog at 11:59PM. When I went back and
checked it five minutes later it still had yesterday's date on it.
4. Displaying the mouseUp handler out of context doesn't guarantee
that it will run without problems. What if your mouseUp handler is in
the stack script and another mouseUp handler in a button intercepts
the message and doesn't pass it? You'll still have some debugging to
do in order to figure out why the date isn't displayed.

The point of all this is not that I'm nit-picking (I am, of course).
The point is that the ambiguities in the requirements can provoke any
number of equally valid (and equally wrong) responses. If I had wanted
the date displayed in the upper-right corner of the main stack and
continually updated, that still would fall under "display the date".
So would the case where I wanted a stack to function as a cgi app and
display the date as a string sent to stdout.

--
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Mark Wieder]

Geoff-

Saturday, April 8, 2006, 12:21:38 AM, you wrote:

> So tell me what could go wrong? ;-)

In addition to the "system" date already taken care of,

1. The date is displayed in a modal dialog, which makes further use of
the app impossible until it's dismissed.
2. The mouseUp handler is never called. Did you mean to put it into a
button instead of an unlocked field?
3. I brought up the answer dialog at 11:59PM. When I went back and
checked it five minutes later it still had yesterday's date on it.
4. Displaying the mouseUp handler out of context doesn't guarantee
that it will run without problems. What if your mouseUp handler is in
the stack script and another mouseUp handler in a button intercepts
the message and doesn't pass it? You'll still have some debugging to
do in order to figure out why the date isn't displayed.

The point of all this is not that I'm nit-picking (I am, of course).
The point is that the ambiguities in the requirements can provoke any
number of equally valid (and equally wrong) responses. If I had wanted
the date displayed in the upper-right corner of the main stack and
continually updated, that still would fall under "display the date".
So would the case where I wanted a stack to function as a cgi app and
display the date as a string sent to stdout.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Rob Cozens]

Moi:

I was more venting emotions built up after reading previous posts on 
this thread


Apparently being rude to Geoff did not complete the catharsis, as I 
feel the need to offer these thoughts as well:


* Just so we're sure we're comparing apples to apples:  My closest 
contact on Microfinancial Corp's Flexware programming team used to say 
"FlexWare is bug free...so long as people use it the way they are 
supposed to."  If any among you are making the contention "my software 
is bug free" on the basis of "I tested all the features and they work 
for me", your definition of "bug-free" is quite different from mine: if 
5% or more of your users make the same mistake, that's your fault, not 
theirs.


* If the industry norm was that no software would be shipped if it 
contained a single known bug, there would be no industry...unless you 
can point to an operating system that meets that requirement.


* Considering the number of auto safety recalls, personal instances of 
packages (eg: auto parts) not containing what they are supposed to, 
spelling & grammar errors in newscasts, etc., I suggest if builders 
built buildings and auto workers built cars and packagers packed 
product the way programmers wrote programs and news writers paid the 
same attention to spelling & "grammar" as programmers, we might have a 
more productive society in general.  [Not that I fault workers for 
having no more dedication to their employers than their employers have 
for them.]


Rob Cozens, CCW
Serendipity Software Company

"There's nothing wrong with Capitalism except Capitalists:
 they're too damn greedy!"   -- Herbert Hoover

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Mark Wieder]

David-

Saturday, April 8, 2006, 4:26:49 AM, you wrote:

> In a way, yes, but on the other hand, I worked at one place that had
> around 5 imaging products and they all used a couple of common  
> libraries. It made sense in this case for QA to track which versions
> of the libraries were used in the build of which products. Also since
> they were Shared Libraries (DLLs), they would switch out libraries  
> and move back to older versions to track when a "bug" was introduced.
> They also had a Library test tool, which exercised the API.

Maybe they "exorcised" it... 

There's a fine line between unit testing and white-box testing. I
write api test harnesses from the QA end of things, but I expect that
by the time I get to run my test suite the api will already have
passed development's unit tests. There may be overlap, and probably
should be, but I see the two as functionally different. But less so
now that XP's test-before-code methodology has taken hold.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Rob Cozens]

 Dan, et al:


I'm reminded of this quotation from the 1970's. (I think it was in the
Mythical Man Month but I'm not sure.)

"If builders built buildings the way programmers wrote programs, then 
the

first woodpecker that came along would destroy civilization."



Must have been a spokesman for the building trades industry.:{`)

There is no house of any size or complexity that is "bug" free.

After first visiting my parents' new $80K home--which in the 1970s was 
a lot of $--my wife and I remarked to each other how shoddy the 
workmanship was.  Some plumbing fixtures were plumbed hot water to cold 
faucet, ill-fitting cabinetry, sloppy painting, etc.


Realistically, there is no human activity that is "bug-free", because 
there is no human being who is "bug-free."  I learned this first hand 
while supervising the work of the data coding section of Oakland Police 
Department.


The job of the coding section was to review all crime and arrest report 
documents and add codes for computer input.  For example, each report 
received a weapons code (o=none, 1=gun, 2=knife, etc.) derived from the 
details in the report.  Simple job: read the report, determine the 
weapon code, and write the code in the appropriate box on the form.  
How could anyone screw this up?  Or so I thought until one of the 
coders was on leave and I filled in for her.  After reviewing my own 
work I realized that humans simply cannot repeat the same task hundreds 
of times in a row and maintain attention and quality of work--we are 
not computers.


Bug-free software is certainly a goal worth striving for--but it's 
unrealistic and unproductive to "wear a hair shirt" because one finds 
bugs in commercial software.  IMFO, it's the severity of the bug and 
the software provider's commitment to address bugs that matters.


Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Rob Cozens]

Mark, Geoff, et al:


To be fair, Geoff had a smiley in his post, so I think he deserves
some slack cut here.


Absolutely! I did notice that after posting, and I apologize.

I was more venting emotions built up after reading previous posts on 
this thread by others than by Geoff's remarks, and I was trying to make 
a point to the larger audience...not my Cousin Geoff in particular.


Rob

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[Geoff Canyon]

Well, my international (from an american viewpoint) friend, how about  
this:


on mouseUp -- display the date
  answer the system date with "OK"
end mouseUp

The requirements are stated clearly in the comment, so the long date  
is out. The system date should work properly for you, correct?


I agree that this is now a lesson in the nature of both bugs and  
hubris ;-)


regards,

Geoff

On Apr 8, 2006, at 1:18 AM, David Vaughan wrote:

On 08/04/2006, at 16:36, Geoff Canyon <[EMAIL PROTECTED]>  
wrote:


So tell me what could go wrong? ;-)


You are limiting yourself to the code, where bugs can have the  
forms of user requirements, specification and documentation as well  
as coding. In this case, the user may have wanted to know the date  
in long form ;-)


However, your code snippet as written does indeed have a bug. If I  
run it here, I see the answer "4/8/06" which I consider an absurd  
answer and very clearly a bug. In Australia, it is not yet August.


cheers
David


regards,

Geoff

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Burgun]

On 7 Apr 2006, at 17:49, Mark Wieder wrote:


David-

Friday, April 7, 2006, 3:26:29 AM, you wrote:


Approach 2, results in much better software and much happier
engineers. The idea is to have QA involved right from the start, at
the design stage. QA's job here is to ensure that components (such as
libraries etc.) are unit tested as they are written.


100% agreement on approach 1 vs 2. It really is true that the best way
to eliminate bugs is not to code them in the first place. I always
like to get QA involved at product inception and follow the sdlc
through to the release.

But... it shouldn't be QA's job to do unit testing. That's
development's job.


In a way, yes, but on the other hand, I worked at one place that had  
around 5 imaging products and they all used a couple of common  
libraries. It made sense in this case for QA to track which versions  
of the libraries were used in the build of which products. Also since  
they were Shared Libraries (DLLs), they would switch out libraries  
and move back to older versions to track when a "bug" was introduced.  
They also had a Library test tool, which exercised the API.



The tests written by QA should complement the unit
tests in terms of integration testing, functional and boundary tests,
etc. Otherwise you get QA locked into the same mindset as development
to where you know what the program is supposed to do, so you don't
test other scenarios. It's the same reason you can't do proper QA on a
product you've written yourself. I've had my own apps pass all the
unit tests I've written and come through with flying colors, only to
be shot down in five minutes when I handed the "finished" product off
to someone else.


I agree, the best policy I've found for this is the to have a Test  
department that writes code to test the robustness of key system  
components.


All the Best
Dave

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: bugs

[David Vaughan]

So tell me what could go wrong? ;-)


I realised while cooking the salmon this evening (crocodile being off  
the menu) that Geoff had inadvertently provided a wonderful case  
study on bugs. Any link to Geoff in the following is purely  
coincidental and nothing to do with him at all :-)


Once upon a time, an aspiring programmer wrote:

on mouseUp -- display the date
  answer the date with "OK"
end mouseUp

and released it as shareware.

His American audience loved it. He received five star ratings on  
Versiontracker and plaudits on download.com, so impressed were users  
at being able to load an application, click a single button and see  
the date. Most impressive of all, it looked bug free.


Then, some old bloke from Australia gave a negative review, declaring  
the code contained a bug in that the information "4/8/06" for 8 April  
was simply wrong. A Frenchman wrote to say that the format should be  
"060408". Both complained that this was a clear-cut bug about which  
the developer should have known before releasing the software with  
the documentation "Displays the date".


Relying on precedents in  "Gutnick v. Dow Jones", they observed that  
even though the software was uploaded in America to an American  
server, it was published in Australia and France where it was read,  
and therefore subject to those foreign laws of fitness for purpose,  
with which any judge in those jurisdictions would agree ;-)  
Therefore, we have an indisputable bug in even this simple application.


Now that we know that no code is bug-free, two issues arise, one of  
morality and one of money.


Has the programmer committed an Immoral Act by publishing this  
software with a bug about which those foreign users believe he should  
surely have known?


What commercial decision should the programmer make? Add 33% more  
lines to the code ("set the useSystemDate to true") just to cater for  
foreign system dates, or add one word to the documentation so that it  
says "Displays the U.S. date"? One action will cost more than the  
other, and either will cost more than doing nothing and restricting  
his target market. Perhaps he should focus his development energies  
on his upcoming product "Displays the time" which he expects to sell  
at twice the price?


So, it appears that
- bugs happen, even when they are sincerely believed not to exist and  
with the best will in the world, and testing which seemed  
comprehensive at the time;
- money matters in commercial decisions without greed per se being a  
factor;

- the morality of the developer is not questioned by the discovered bug.

Perhaps RunRev has more bugs than it should have. That is something I  
do not know, but Lynn may on industry benchmarks. Regardless,  
bugginess is a relative question.


regards
David
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution