hair-pulling frustration

[Dr. Hawkins]

I can't help but wonder what it would take to get runrev to follow normal
practice and actually get something to alpha level before calling it a
"developer preview", beta by a "release candidate" (ok, that still wouldn't
be normal), and working rather than early beta before release.

If I sold something at these stages, I'd be out of business by sundown.

Do the developers even pretend to use the IDE before slapping "release
candidate" on it? Do they even have some kind of test suite?

The sheer number of pieces of working code that have broken when going from
5.5 to 7.0 is beyond belief, as is the giant step backward in the IDE.

I used to have to kill livecode frequently for the phantom "shadow
variable" problem. While that happens more often under 6 (which is why I
could never use it) and 7, I now usually have to kill the whole thing
before that happens, as I can't get it to set a breakpoint, or even
acknowedge that I've clicked anything, delays of several seconds, and so
forth.

In addition to the others I've mentioned here an in other recent posts, the
recompile of sqlite is not quite compatible with the old, and behaves
differently. For example, a semicolon at the end of an entry without
begin/end transaction now causes a parsing error.

Moving forward is one thing, but the only near release grade version is
5.x, which itself isn't quite ready for primetime.

OK, I'll stop venting, but the amount of time I'm losing to bugs that never
should have seen a public preview is getting increasingly frustrating.

[Richmond]

Post by Dr. Hawkins
I can't help but wonder what it would take to get runrev to follow normal
practice and actually get something to alpha level before calling it a
"developer preview", beta by a "release candidate" (ok, that still wouldn't
be normal), and working rather than early beta before release.
If I sold something at these stages, I'd be out of business by sundown.
Do the developers even pretend to use the IDE before slapping "release
candidate" on it? Do they even have some kind of test suite?
The sheer number of pieces of working code that have broken when going from
5.5 to 7.0 is beyond belief, as is the giant step backward in the IDE.
I used to have to kill livecode frequently for the phantom "shadow
variable" problem. While that happens more often under 6 (which is why I
could never use it) and 7, I now usually have to kill the whole thing
before that happens, as I can't get it to set a breakpoint, or even
acknowedge that I've clicked anything, delays of several seconds, and so
forth.
In addition to the others I've mentioned here an in other recent posts, the
recompile of sqlite is not quite compatible with the old, and behaves
differently. For example, a semicolon at the end of an entry without
begin/end transaction now causes a parsing error.
Moving forward is one thing, but the only near release grade version is
5.x, which itself isn't quite ready for primetime.
OK, I'll stop venting, but the amount of time I'm losing to bugs that never
should have seen a public preview is getting increasingly frustrating.

Dear Dr Hawkins,

I hope RunRev listen to you: they certainly have shown little or no sign
of listening
when I have stated similar reservations about "Stable" releases.

As a Mac PPC "loony" the fact that the 'last' Mac PPC compatible version
(6.6.5) doesn't have an
icon that shows up is, frankly, pathetic, and easily resolved . . . but
it hasn't been.

And that, as they say, is the smallest of all the "bi*ches" there are
right across the stable releases.

The problem of Unicode fonts being substituted for on past XP Windows
shows no sign of being resolved, despite
Microsoft having pumped out "Vista", "7", "8" and "*.1" since then.

Boom, boom, and so it goes . . .

Richmond.

[Richard Gaskin]

Post by Dr. Hawkins
OK, I'll stop venting, but the amount of time I'm losing to bugs that never
should have seen a public preview is getting increasingly frustrating.

I agree, which is why it benefits no one more than ourselves to test our
work with pre-release versions.

The SQLite issue may be more related to the new SQLite code base than
with LiveCode. I can't say specifically - Mr. Haworth, what do you find
with that?

On the other issues, can you share the bug report numbers so we can
follow them?

[Richmond]

Post by Richard Gaskin

Post by Dr. Hawkins
OK, I'll stop venting, but the amount of time I'm losing to bugs that never
should have seen a public preview is getting increasingly frustrating.

I agree, which is why it benefits no one more than ourselves to test
our work with pre-release versions.

That is, of course, very true.

Another idea that might not be bad, is to slow down the releases so
there is more time for testing.

I would love to do more testing (I do almost none) but do not have the
time as I have a full work schedule both in terms of my
teaching duties and my programming ones. Given more time between
releases of development previews, release candidates and stable releases
might allow many of us busy people slightly more time to do this sort of
thing.

Another idea would be to award "brownie points" to anyone who identifies
and documents a bug, and, after somebody has collected
enough points they could receive some sort tangible reward.

Post by Richard Gaskin
The SQLite issue may be more related to the new SQLite code base than
with LiveCode. I can't say specifically - Mr. Haworth, what do you
find with that?
On the other issues, can you share the bug report numbers so we can
follow them?

Richmond.

[Dr. Hawkins]

Post by Richard Gaskin

Post by Dr. Hawkins
OK, I'll stop venting, but the amount of time I'm losing to bugs that never
should have seen a public preview is getting increasingly frustrating.

I agree, which is why it benefits no one more than ourselves to test our
work with pre-release versions.

Two problems, though:
1) One can *either* stay with 5.5, *or* use any of the new features.
Without maintaining two codebases (impossible with livecode's monolithic
file), there is no way to do both.
2) These prereleases just aren't ready for what they're called and
presented as. I simply cannot believe that anyone who uses the debugger
would have signed off on it.

I really can't give up any significant portion of my coding time to do
livecode's work for them; these are things that are so basic that they
never should have seen a release to the public.

[Richmond]

<snip>
I really can't give up any significant portion of my coding time to do
livecode's work for them; these are things that are so basic that they
never should have seen a release to the public.

I'm afraid, Richard Gaskin et al, the above is going to be a fairly
widespread response.

Obviously Dr Hawkins is not over-enamoured of the Open Source theory:
LiveCode is paid for in a different way [the "I'll scratch your back if
you'll scratch mine" way] than the 'standard' commercial way [I pay you,
and you do ALL the work].

Part of the problem is that Livecode is NOT like GIMP (for instance):
GIMP is 100% Open Source, while Livecode both IS and ISN'T Open Source,
and RunRev has to play a terrible balancing act keeping both camps happy.

-----------------------------

I can see this problem, and have to cope with it frequently in my 'real'
job.

I run an English as a Foreign Language school in Bulgaria, and have
constantly to explain to parents that, in spite of the fact they
pay me to teach English to their children, their children will not learn
anything if only I do any work and the kids do nothing.
One cannot learn English in the same way as a sponge soaks up water.

-----------------------------

The difference between what I do and LiveCode is also quite important:
Livecode is a product which can be used [rather like
a car can be used to drive from place to place] without having to
understand what goes on 'under the hood'. Language learning
means constantly messing around under the hood.

And, quite honestly, if I bought a car and then was supposed to beta
test the thing and keep going back to buy replacements
every time something went wrong with the car I would get pretty fed up
pretty quickly.

The reason I don't get fed up is I keep going back and getting free
replacements, and that is the main difference.

Now what I don't get with the free version is the ability to lock up my
code so that other people cannot pinch it, and at present that
doesn't fuss me. I can, however, imagine a time when it will matter, so
I will stump up the money to buy the non-free version.

If, on buying the non-free version and it turns out to be "dicky" I
shall be even more trenchant in my response than Dr Hawkins.

-----------------------------

Of course Dr Hawkins does not really make a distinction between
'developer previews' and 'release candidates' (which are marked
as such to signal a lower level of confidence in their functional
completeness than 'stable' versions. He does, however, state
that 'stable' versions are not much better than the others, and that is
where the problem lies.

Several times I have stated that in my opinion RunRev are being swept
along into a sort of feature bloat which prevents them
from sorting out little 'niggles' in existing features. I se no reason
to change that opinion.

When or if I come to thinking about buying a commercial version of
LiveCode I will be in a very odd position, not really knowing whether
I am buying a version that is, really, stable, or just something
beta-ish labelled 'stable' which will then cause all sorts of unforeseen
problems with my product.

Richmond.

[J. Landman Gay]

Post by Richmond
Several times I have stated that in my opinion RunRev are being swept
along into a sort of feature bloat which prevents them
from sorting out little 'niggles' in existing features. I se no reason
to change that opinion.

Suppose while teaching English, you were not paid by the time you put
in, but rather by the number of students who learn each word. If you
teach 10 students and they all learn the word, you get paid for 10 words.

If one student does not learn the word, then you must go back and
re-teach it until the student understands it. You don't get paid for
"his" word until that happens.

If 9 of your students learn the word but one does not, would you stop
introducing new words in class until the one student understands it? Or
would you re-teach that student on your own time? Or would you just
postpone it for a while because it affects only one person?

Suppose 6 students don't understand the word. In that case you would
probably decide to re-teach it during class time because so many
students are affected. The four remaining students would be idle until
that is done and may feel you are depriving them of a full education.

Suppose 3 students don't understand it. Where would you draw the line?
Remember, you get paid by the word.

[Vaughn Clement]

The student example

Your comment is interesting BUT;

Instructors need to test the curricula before, during and after the
instruction.

The question is, is it the instruction, the testing or the student having
the problem. It all comes back to the testing. The teacher who does not
test the instruction fails. The instruction that is not tested will fail.
The student that is not learning from the instruction fails.

The bottom line, no testing no learning.

This forum is the best source for learning at this time, your comments
allow the students to learn, the teachers "You" are helping us all to
learn. Lastly you're wasting time explaining what your not doing. NOT
TESTING!

Thank you

Vaughn Clement

Apps by Vaughn Clement (Support)
*http://www.appsbyvaughnclement.com/tools/home-page/
<http://www.appsbyvaughnclement.com/tools/home-page/>*
On Target Solutions LLC Website: http://www.ontargetsolutions.biz
Email: ***@yahoo.com
Skype: vaughn.clement

FaceTime: ***@gmail.com
Ph. 928-254-9062

Post by Richmond
Several times I have stated that in my opinion RunRev are being swept
along into a sort of feature bloat which prevents them
from sorting out little 'niggles' in existing features. I se no reason
to change that opinion.

Suppose while teaching English, you were not paid by the time you put in,
but rather by the number of students who learn each word. If you teach 10
students and they all learn the word, you get paid for 10 words.
If one student does not learn the word, then you must go back and re-teach
it until the student understands it. You don't get paid for "his" word
until that happens.
If 9 of your students learn the word but one does not, would you stop
introducing new words in class until the one student understands it? Or
would you re-teach that student on your own time? Or would you just
postpone it for a while because it affects only one person?
Suppose 6 students don't understand the word. In that case you would
probably decide to re-teach it during class time because so many students
are affected. The four remaining students would be idle until that is done
and may feel you are depriving them of a full education.
Suppose 3 students don't understand it. Where would you draw the line?
Remember, you get paid by the word.
--
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Mark Schonewille]

Jacque,

I teach a class for free and if one student doesn't understand one word,
I spend some extra time with that student to make sure he or she
understands it. If I didn't do this, I would lose the students one by
one and in the end I'd be the only one understanding the lesson. So, I
guess it means I slow down until every student understands all words.

--
Best regards,

Mark Schonewille

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

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book "Programming LiveCode for the Real Beginner"
http://qery.us/3fi

LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

Post by J. Landman Gay

Post by Richmond
Several times I have stated that in my opinion RunRev are being swept
along into a sort of feature bloat which prevents them
from sorting out little 'niggles' in existing features. I se no reason
to change that opinion.

Suppose while teaching English, you were not paid by the time you put
in, but rather by the number of students who learn each word. If you
teach 10 students and they all learn the word, you get paid for 10 words.
If one student does not learn the word, then you must go back and
re-teach it until the student understands it. You don't get paid for
"his" word until that happens.
If 9 of your students learn the word but one does not, would you stop
introducing new words in class until the one student understands it? Or
would you re-teach that student on your own time? Or would you just
postpone it for a while because it affects only one person?
Suppose 6 students don't understand the word. In that case you would
probably decide to re-teach it during class time because so many
students are affected. The four remaining students would be idle until
that is done and may feel you are depriving them of a full education.
Suppose 3 students don't understand it. Where would you draw the line?
Remember, you get paid by the word.

[Richmond]

Post by Richard Gaskin
Jacque,
I teach a class for free and if one student doesn't understand one
word, I spend some extra time with that student to make sure he or she
understands it. If I didn't do this, I would lose the students one by
one and in the end I'd be the only one understanding the lesson. So, I
guess it means I slow down until every student understands all words.

I have parents who ask me how long it will take me to get through a
textbook, and I
always tell them I don't know . . . because pupils are all different and
one must work at the rate that is best for the slowest.

Richmond.

Post by Richard Gaskin
--
Best regards,
Mark Schonewille
Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553
http://qery.us/468
Buy my new book "Programming LiveCode for the Real Beginner"
http://qery.us/3fi
https://www.facebook.com/groups/runrev/

Post by J. Landman Gay

Post by Richmond
Several times I have stated that in my opinion RunRev are being swept
along into a sort of feature bloat which prevents them
from sorting out little 'niggles' in existing features. I se no reason
to change that opinion.

Suppose while teaching English, you were not paid by the time you put
in, but rather by the number of students who learn each word. If you
teach 10 students and they all learn the word, you get paid for 10 words.
If one student does not learn the word, then you must go back and
re-teach it until the student understands it. You don't get paid for
"his" word until that happens.
If 9 of your students learn the word but one does not, would you stop
introducing new words in class until the one student understands it? Or
would you re-teach that student on your own time? Or would you just
postpone it for a while because it affects only one person?
Suppose 6 students don't understand the word. In that case you would
probably decide to re-teach it during class time because so many
students are affected. The four remaining students would be idle until
that is done and may feel you are depriving them of a full education.
Suppose 3 students don't understand it. Where would you draw the line?
Remember, you get paid by the word.

_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Dr. Hawkins]

Post by Richmond
LiveCode is paid for in a different way [the "I'll scratch your back if
you'll scratch mine" way] than the 'standard' commercial way [I pay you,
and you do ALL the work].

Actually, I published the seminal paper on the economics of open source
software, and am quite familiar with it.

I purchased a $1k/year commercial license before the kickstarter campaign,
and have never used the community version (and given the GPL3, probably
never will, at least not until there are US court cases).

While I'm at it, instead of the "you get the same license" on the
kickstarter campaign, I ended up with the newer, subscription license. But
that's a whole separate issue.

When I'm paying for a license, I expect things to generally work, not to be
test cases.

Post by Richmond
Of course Dr Hawkins does not really make a distinction between 'developer
previews' and 'release candidates' (which are marked
as such to signal a lower level of confidence in their functional
completeness than 'stable' versions. He does, however, state
that 'stable' versions are not much better than the others, and that is
where the problem lies.

Sure I do; but each is inflated.

Normal parlance is that an alpha release executes, a beta release is
feature complete and generally works but with bugs expected to be found,
and that a release has been tested.

LiveCode's developer previews simply execue (nightly snapshot that
executed), the RC are alpha quality, the 5.5 series are late beta, and the
6.x and 7.x releases are early beta.

When or if I come to thinking about buying a commercial version of LiveCode

Post by Richmond
I will be in a very odd position, not really knowing whether
I am buying a version that is, really, stable, or just something beta-ish
labelled 'stable' which will then cause all sorts of unforeseen
problems with my product.

My attitude would probably be far different if I were using a community
version . . . I understand the open source and mixed models quite well, but
would be far better off with a fixed and working 5 than what the efforts
have been spent on the last couple of years.

[Terry Judd]

Post by Dr. Hawkins
LiveCode's developer previews simply execue (nightly snapshot that
executed), the RC are alpha quality, the 5.5 series are late beta, and the
6.x and 7.x releases are early beta.

I think that¹s a bit harsh. There are problems with every version but
typically only a very small number effect individual users. Like many
others I move to a newer version when a new feature that I want has been
added or a bug that is holding me back gets fixed. If other problems
emerge then I step back and monitor things for a bit longer. I don¹t
really care how a release is named, alpha, beta, DP or RC - if it does
enough of what I want then I use it.

Post by Dr. Hawkins
When or if I come to thinking about buying a commercial version of LiveCode

Post by Richmond
I will be in a very odd position, not really knowing whether
I am buying a version that is, really, stable, or just something beta-ish
labelled 'stable' which will then cause all sorts of unforeseen
problems with my product.

My attitude would probably be far different if I were using a community
version . . . I understand the open source and mixed models quite well, but
would be far better off with a fixed and working 5 than what the efforts
have been spent on the last couple of years.

I guess it depends on what you want the software to do. While things move
relatively slowly in the desktop world, mobile OSes are changing rapidly.
A stable version 5 would be fairly useless to an iOS developer. I like the
fact that LC is evolving - warts and all. If the alternative is what used
to happen with Director (maybe still does), where Œstable¹ versions go
unchanged for years, then I¹ll go for the LC model every time.

Nevertheless, I wholeheartedly agree that it is annoying when you
regularly butt up against bugs - old and new - and it would be good to get
some useful info on these in an accessible and easily digestible format -
that is, other than via the release notes and the bug database. Perhaps if
these could be aggregated in some way and added as a Œknown issues¹ item
to LC¹s help menu it would be easier for us to decide which version of LC
to use and when to make the switch. The identification/verification of
major new issues against a version (or multiple versions) or fixes in
newly released versions could also perhaps appear as notifications in LC's
start centre.

Terry...

[Dr. Hawkins]

Post by Terry Judd

Post by Dr. Hawkins
LiveCode's developer previews simply execue (nightly snapshot that
executed), the RC are alpha quality, the 5.5 series are late beta, and the
6.x and 7.x releases are early beta.

I think that¹s a bit harsh.

*shrug* That's the normal meaning of alpha & beta (for non-microsoft
products)

[Peter Haworth]

The SQLite issue may be more related to the new SQLite code base than with
LiveCode. I can't say specifically - Mr. Haworth, what do you find with
that?

Just asked for an example and will check it out.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

[Rick Harrison]

Hi Dr. Hawkins,

The whole computer industry is changing too rapidly now.
Their is no such thing as “stable” as a result.

What everyone wants is a “stable” OS, a “stable” language, a
“stable” database, and stable hardware platforms to go with it all.

If we had all of that, we’d already have a stable “AI” computer
system. Instead it’s all becoming an upgrade hell for everyone
except the people who at the top are making money from the
entire circus they’ve created.

Just my 2 cents.

Thanks for letting all of us vent a little! LOL

Rick

Post by Dr. Hawkins
I can't help but wonder what it would take to get runrev to follow normal
practice and actually get something to alpha level before calling it a
"developer preview", beta by a "release candidate" (ok, that still wouldn't
be normal), and working rather than early beta before release.
If I sold something at these stages, I'd be out of business by sundown.
Do the developers even pretend to use the IDE before slapping "release
candidate" on it? Do they even have some kind of test suite?
The sheer number of pieces of working code that have broken when going from
5.5 to 7.0 is beyond belief, as is the giant step backward in the IDE.
I used to have to kill livecode frequently for the phantom "shadow
variable" problem. While that happens more often under 6 (which is why I
could never use it) and 7, I now usually have to kill the whole thing
before that happens, as I can't get it to set a breakpoint, or even
acknowedge that I've clicked anything, delays of several seconds, and so
forth.
In addition to the others I've mentioned here an in other recent posts, the
recompile of sqlite is not quite compatible with the old, and behaves
differently. For example, a semicolon at the end of an entry without
begin/end transaction now causes a parsing error.
Moving forward is one thing, but the only near release grade version is
5.x, which itself isn't quite ready for primetime.
OK, I'll stop venting, but the amount of time I'm losing to bugs that never
should have seen a public preview is getting increasingly frustrating.
--
Dr. Richard E. Hawkins, Esq.
[phone]
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Peter Haworth]

Post by Dr. Hawkins
In addition to the others I've mentioned here an in other recent posts, the
recompile of sqlite is not quite compatible with the old, and behaves
differently. For example, a semicolon at the end of an entry without
begin/end transaction now causes a parsing error.

I rarely, if ever, try to execute multiple SQL statements in one
revDatabasexxx so haven't seen that particular problem. Could you give an
example? I'd like to check it out as I don't want to get hit by the same
bug.

Thanks,

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

[Dr. Hawkins]

Post by Peter Haworth
I rarely, if ever, try to execute multiple SQL statements in one
revDatabasexxx so haven't seen that particular problem. Could you give an
example? I'd like to check it out as I don't want to get hit by the same
bug.

I routinely execute many synchronize with the remote, as latency is a big
deal and stops the single-threaded livecode.

"SELECT * FROM sometable;" worked before the change with SQLite. Now, it
is necessary to remove the semicolon.

I routinely code the semicolons in because I variously use both direct
revDatabaseXxxx calls and my own routine which wraps with Begin/End. That
way, I can, err, could, simply write my queries.

[Peter Haworth]

OK, I'll try with and without multiple statements in both versions.

I do want to double check that you're not trying to access an SQLite
database over a network because you WILL have major problems if you are :-)

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

Post by Dr. Hawkins

Post by Peter Haworth
I rarely, if ever, try to execute multiple SQL statements in one
revDatabasexxx so haven't seen that particular problem. Could you give an
example? I'd like to check it out as I don't want to get hit by the same
bug.

I routinely execute many synchronize with the remote, as latency is a big
deal and stops the single-threaded livecode.
"SELECT * FROM sometable;" worked before the change with SQLite. Now, it
is necessary to remove the semicolon.
I routinely code the semicolons in because I variously use both direct
revDatabaseXxxx calls and my own routine which wraps with Begin/End. That
way, I can, err, could, simply write my queries.
--
Dr. Richard E. Hawkins, Esq.
[phone]
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Dr. Hawkins]

Post by Peter Haworth
OK, I'll try with and without multiple statements in both versions.

Now, to make matters worse, it appears that I've been using 7.0.0, not
7.0.1-RC-1 for an unknown period of time--it has managed to set itself as
the default version more than once on this machine.

Anyway, where this bit me was the single transaction with semicolon but
without begin/end

Post by Peter Haworth
I do want to double check that you're not trying to access an SQLite
database over a network because you WILL have major problems if you are :-)

Been, there, done that, silkscreened the t-shirt. Interestingly, though,
when simultaneously opened, come of the changes could be read by the other
(come to think of it, it wasn't network, but two instances on the same
machine).

But, no, these are actually :memory: SQLite dbs. (now, I'm *dying* for
multi-threading so that the second/slave process can handle synchronization)

[Peter Haworth]

Post by Dr. Hawkins
"SELECT * FROM sometable;" worked before the change with SQLite. Now, it
is necessary to remove the semicolon.

I just tried this using LC 5.5.4 (prior to the SQLite library change) and
LC 6.6.2 (after the SQLite library change), with and without the semicolon
and all tests worked fine.

You mentioned a "parsing error" - did you mean an LC compile error or an
SQLite error? Either way, what was the error?


Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

[Dr. Hawkins]

Post by Peter Haworth

Post by Dr. Hawkins
"SELECT * FROM sometable;" worked before the change with SQLite. Now,

it

Post by Dr. Hawkins
is necessary to remove the semicolon.

I just tried this using LC 5.5.4 (prior to the SQLite library change) and
LC 6.6.2 (after the SQLite library change), with and without the semicolon
and all tests worked fine.
You mentioned a "parsing error" - did you mean an LC compile error or an
SQLite error? Either way, what was the error?

revDataFromQuery(,,17,"SELECT * FROM vader_darth______001_dna;")
yields
Message execution error:
Error description: value: error executing expression
Hint: ")

While if I leave out the semicolon, it gives me all the data in the table.

This from 7.0-RC2 moments ago

[Neil Roger]

Hi Richard,

I've attempted to replicate the semicolon issue without any success.
This could be why we have not come accross it during testing in-house.
The script that I tested with is-

global gConnectionID
on mouseUp
global gConnectionID
if gConnectionID is not a number then
answer error "Please connect to the database first."
exit to top
end if
put "Table1" into tTableName
put "SELECT * FROM " & tTableName into tSQL

put revDataFromQuery(,,gConnectionID,"SELECT * FROM Table1;") into tData

if item 1 of tData = "revdberr" then
answer error "There was a problem querying the database:" & cr &
tData
else
put tData into field "Data"
end if
end mouseUp


Both the inclusion and exclusion of the semi-colon return data as
expected. If possible, could you supply a stack for me to test with and
I will happily look into this further.

Kind Regards,

Neil Roger
--
LiveCode Support Team ~ http://www.livecode.com
--

Post by Dr. Hawkins
revDataFromQuery(,,17,"SELECT * FROM vader_darth______001_dna;")
yields
Error description: value: error executing expression
Hint: ")

[Ralph DiMola]

Neil,

With user input and Richard's moderating this thread has started to bear
some fruit. After writing HW diagnostics for years I know how challenging is
to come with thorough testing scenarios. I don't know what your QC process
for databases is but might I suggest using challenging queries. I would be
happy to set up a stack to test them along with the DBs. For example:

SELECT Table1.*, Table2.*,Table3.* FROM Table1 LEFT JOIN Table2 ON
Table1.Designation = Table2.Designation LEFT JOIN Table3 ON Table1.State =
Table3.State AND Table1.County = Table3.County WHERE (Table3.Region = 'Foo')

or

ATTACH DATABASE "Table3.db" AS Table3DB
SELECT Table3.*,Table1.* from Table3DB.Table3 JOIN Table1 ON Table3.CourseID
= Table1.CourseID JOIN Table2 ON Table2.County = Table1.County AND
Table2.State = Table1.State WHERE (Table3.Favorite or Table3.frog <> '')

Mr. Haworth and all you other DB gurus out there, what other testing
scenarios do think should be included in the RR DB QC process?

The way I look at it the more we help RR the more we help ourselves.


Ralph DiMola
IT Director
Evergreen Information Services
***@evergreeninfo.net

-----Original Message-----
From: use-livecode [mailto:use-livecode-***@lists.runrev.com] On Behalf
Of Neil Roger
Sent: Thursday, November 13, 2014 2:59 PM
To: How to use LiveCode
Subject: Re: hair-pulling frustration

Hi Richard,

I've attempted to replicate the semicolon issue without any success.
This could be why we have not come accross it during testing in-house.
The script that I tested with is-

global gConnectionID
on mouseUp
global gConnectionID
if gConnectionID is not a number then
answer error "Please connect to the database first."
exit to top
end if
put "Table1" into tTableName
put "SELECT * FROM " & tTableName into tSQL

put revDataFromQuery(,,gConnectionID,"SELECT * FROM Table1;") into tData

if item 1 of tData = "revdberr" then
answer error "There was a problem querying the database:" & cr &
tData
else
put tData into field "Data"
end if
end mouseUp


Both the inclusion and exclusion of the semi-colon return data as
expected. If possible, could you supply a stack for me to test with and
I will happily look into this further.

Kind Regards,

Neil Roger
--
LiveCode Support Team ~ http://www.livecode.com
--

Post by Dr. Hawkins
revDataFromQuery(,,17,"SELECT * FROM vader_darth______001_dna;")
yields
Error description: value: error executing expression
Hint: ")

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

[Neil Roger]

Hi Ralph,

Thanks for your fantastic suggestion!

I've had a quick chat with our testing master, Hanson, and he is more
than happy to look at into integrating any advance query stacks you may
have into our current test system.

If you do get a chance to create any of these, please fire them over to
***@livecode.com and we will then forward them onto Hanson.

We're also in the process of integrating a system that allows the
community to submit tests with any reports they create. This means that
they should be automatically included during any internal testing we do.

Kind Regards,

Neil Roger
--
LiveCode Support Team ~ http://www.livecode.com
--

Post by Ralph DiMola
Neil,
With user input and Richard's moderating this thread has started to bear
some fruit. After writing HW diagnostics for years I know how challenging is
to come with thorough testing scenarios. I don't know what your QC process
for databases is but might I suggest using challenging queries. I would be
SELECT Table1.*, Table2.*,Table3.* FROM Table1 LEFT JOIN Table2 ON
Table1.Designation = Table2.Designation LEFT JOIN Table3 ON Table1.State =
Table3.State AND Table1.County = Table3.County WHERE (Table3.Region = 'Foo')
or
ATTACH DATABASE "Table3.db" AS Table3DB
SELECT Table3.*,Table1.* from Table3DB.Table3 JOIN Table1 ON Table3.CourseID
= Table1.CourseID JOIN Table2 ON Table2.County = Table1.County AND
Table2.State = Table1.State WHERE (Table3.Favorite or Table3.frog <> '')
Mr. Haworth and all you other DB gurus out there, what other testing
scenarios do think should be included in the RR DB QC process?
The way I look at it the more we help RR the more we help ourselves.
Ralph DiMola
IT Director
Evergreen Information Services
-----Original Message-----
Of Neil Roger
Sent: Thursday, November 13, 2014 2:59 PM
To: How to use LiveCode
Subject: Re: hair-pulling frustration
Hi Richard,
I've attempted to replicate the semicolon issue without any success.
This could be why we have not come accross it during testing in-house.
The script that I tested with is-
global gConnectionID
on mouseUp
global gConnectionID
if gConnectionID is not a number then
answer error "Please connect to the database first."
exit to top
end if
put "Table1" into tTableName
put "SELECT * FROM " & tTableName into tSQL
put revDataFromQuery(,,gConnectionID,"SELECT * FROM Table1;") into tData
if item 1 of tData = "revdberr" then
answer error "There was a problem querying the database:" & cr &
tData
else
put tData into field "Data"
end if
end mouseUp
Both the inclusion and exclusion of the semi-colon return data as
expected. If possible, could you supply a stack for me to test with and
I will happily look into this further.
Kind Regards,
Neil Roger

[Dr. Hawkins]

Post by Neil Roger
Both the inclusion and exclusion of the semi-colon return data as
expected. If possible, could you supply a stack for me to test with and I
will happily look into this further.

I'll see what I can pop together.

And now, I am getting an empty return (rather than data or error) when I
include the semicolon . . .

[Peter Haworth]

I just tried it under 7.0 and same result - no problems with or without the
semicolon. There must be something else going on in Dr Hawkins code.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

Post by Alejandro Tejada
Hi Richard,
I've attempted to replicate the semicolon issue without any success. This
could be why we have not come accross it during testing in-house. The
script that I tested with is-
global gConnectionID
on mouseUp
global gConnectionID
if gConnectionID is not a number then
answer error "Please connect to the database first."
exit to top
end if
put "Table1" into tTableName
put "SELECT * FROM " & tTableName into tSQL
put revDataFromQuery(,,gConnectionID,"SELECT * FROM Table1;") into tData
if item 1 of tData = "revdberr" then
answer error "There was a problem querying the database:" & cr &
tData
else
put tData into field "Data"
end if
end mouseUp
Both the inclusion and exclusion of the semi-colon return data as
expected. If possible, could you supply a stack for me to test with and I
will happily look into this further.
Kind Regards,
Neil Roger
--
LiveCode Support Team ~ http://www.livecode.com
--

Post by Dr. Hawkins
revDataFromQuery(,,17,"SELECT * FROM vader_darth______001_dna;")
yields
Error description: value: error executing expression
Hint: ")

_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Dr. Hawkins]

Post by Peter Haworth
I just tried it under 7.0 and same result - no problems with or without the
semicolon. There must be something else going on in Dr Hawkins code.

The ones I posted today were typed into the message box!

[Peter Haworth]

OK, so you mean this:

revDataFromQuery(,,17,"SELECT * FROM vader_darth______001_dna;")

revDataFromQuery is a function, you need to either "put" it or "get" it or
"set" a cprop to it. If I type the above statement into the message box I
get exactly the same error as you whether there's a semicolon or not. If I
add "put" before it, everything works with or without the semicolon..

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

Post by Dr. Hawkins

Post by Peter Haworth
I just tried it under 7.0 and same result - no problems with or without

the

Post by Peter Haworth
semicolon. There must be something else going on in Dr Hawkins code.

The ones I posted today were typed into the message box!
--
Dr. Richard E. Hawkins, Esq.
[phone]
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Peter Haworth]

Post by Dr. Hawkins
revDataFromQuery(,,17,"SELECT * FROM vader_darth______001_dna;")

Somehow, an earlier version of my reply was sent. Here's what I meant to
send.

Knowing that you used the message box makes a big difference, Everyone who
has checked this out used a script.

I was surprised your statement worked at all in the message box since
revDataFromQuery is a function and seems like it should need a "put" or
"get" or "set, so I tried various LC versions, with/without semicolon,
with/without "put", all in the message box.

LC 5.5
All combinations of put/semicolon worked.

LC 6.1
No put, with semicolon, failed "error executing expression"
No put, no semicolon, worked
With put, with semicolon, failed "can't find handler"
With put, no semicolon, failed "can't find handler"

LC 6.6
No put, with semicolon, failed "error executing expression"
No put, no semicolon, worked
With put, with semicolon, failed "can't find handler"
With put, no semicolon, worked

If it had something to do with the new SQLite library, there would have
been an SQL error message but it never gets as far as executing
revDataFromQuery.

My feeling is that something changed in the message box parsing routines
and the semicolon is being taken as a separator between two statements.

However, bottom line is that all works fine in a script with or without the
semicolon.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

[J. Landman Gay]

Post by Peter Haworth
My feeling is that something changed in the message box parsing routines
and the semicolon is being taken as a separator between two statements.

A semicolon in any script is interpreted as a line ending, except when
within quotation marks. If the example failed (where the semicolon is
within the quotes) then that would be a problem with the scripts that
interpret the message box content.

That said, it is very tricky to implement code correctly in all cases
from the message box because of the "do" statements and other
contortions it needs to use. Ideally, tests should always be conducted
from the script editor where the intermediate interpretive layer isn't
present.

[Peter Haworth]

Right, it looks like something in the message box message box
interpretation scripts changed between the various releases I tested.

I guess I should file a bug report.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

Post by J. Landman Gay

Post by Peter Haworth
My feeling is that something changed in the message box parsing routines
and the semicolon is being taken as a separator between two statements.

A semicolon in any script is interpreted as a line ending, except when
within quotation marks. If the example failed (where the semicolon is
within the quotes) then that would be a problem with the scripts that
interpret the message box content.
That said, it is very tricky to implement code correctly in all cases from
the message box because of the "do" statements and other contortions it
needs to use. Ideally, tests should always be conducted from the script
editor where the intermediate interpretive layer isn't present.
--
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Dr. Hawkins]

Post by J. Landman Gay
A semicolon in any script is interpreted as a line ending, except when
within quotation marks. If the example failed (where the semicolon is
within the quotes) then that would be a problem with the scripts that
interpret the message box content.

I *initially* found this in a script, which worked fine once I removed the
semicolon (which was inside the parenthesis). I removed the semicolon, and
it began working.

Also, I always have strict compilation on.

[Peter Haworth]

Can you send us the relevant script lines? So far, it has worked in my
script with or without semicolons in various versions from 5.5 and up in my
testing so there must be something different in your script and mine.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

Post by Dr. Hawkins

Post by J. Landman Gay
A semicolon in any script is interpreted as a line ending, except when
within quotation marks. If the example failed (where the semicolon is
within the quotes) then that would be a problem with the scripts that
interpret the message box content.

I *initially* found this in a script, which worked fine once I removed the
semicolon (which was inside the parenthesis). I removed the semicolon, and
it began working.
Also, I always have strict compilation on.
--
Dr. Richard E. Hawkins, Esq.
[phone]
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Peter Haworth]

Post by Dr. Hawkins
revDataFromQuery(,,17,"SELECT * FROM vader_darth______001_dna;")
yields
Error description: value: error executing expression
Hint: ")
While if I leave out the semicolon, it gives me all the data in the table.
This from 7.0-RC2 moments ago

Thanks for the clarification. SInce this works in 6.6.2 which uses the new
SQLite library but not in 7.0rc2, it looks to be a 7.0rc2 bug.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

[Richard Gaskin]

Post by Richmond

Post by Richard Gaskin
I agree, which is why it benefits no one more than ourselves to test
our work with pre-release versions.

That is, of course, very true.
Another idea that might not be bad, is to slow down the releases so
there is more time for testing.

Agreed. While v7 did have an unusually long test period as it was
(first test build was release March 19), there are a couple rough edges
in the "Stable" build that seem the sort of thing that might have been
handled prior to that designation.

Post by Richmond
I would love to do more testing (I do almost none) but do not have
the time as I have a full work schedule both in terms of my
teaching duties and my programming ones.

True, we can only afford the time we can afford. Unicode's not very
critical for my work, so most of my testing was with v6.7, testing v7
only on Ubuntu and really only focused on the new Linux-specific
additions there.

But when a given version has new features that seem useful to us,
testing is critical to ensure that it'll do what we want to it do when
the final build comes out.

And testing needn't necessarily be all that deep. LiveCode has a lot
going on, arguably more akin to an OS than to any consumer app. We all
do different things with it, and no one can guess the exact interaction
of language elements we'll be using in our own scripts.

So while we can't be expected to test everything, if we only test our
own apps with new builds that's usually all we need for our own work.
Collectively, if we call just ensured that new features get implemented
in ways we need, we'll all have what we want.

Rather than thinking about testing LiveCode, big as it is, it may be
more helpful to think of it as testing you own app's functionality in
the sliver of LiveCode that it uses. Just test your own stuff, and your
own needs will be addressed.

Post by Richmond
Another idea would be to award "brownie points" to anyone who
identifies
and documents a bug, and, after somebody has collected
enough points they could receive some sort tangible reward.

That's a good idea, and one I know Ben is keenly interested in persuing.
In fact, he's brought it up in a couple of our Community meetings, but
maybe you can help us out with some of the details we've been stuck on:

What sorts of perks would you find motivating, and at what level of
testing effort or bug report count should they kick in?

[Richmond]

Post by Richard Gaskin

Post by Richmond

Post by Richard Gaskin
I agree, which is why it benefits no one more than ourselves to test
our work with pre-release versions.

That is, of course, very true.
Another idea that might not be bad, is to slow down the releases so
there is more time for testing.

Agreed. While v7 did have an unusually long test period as it was
(first test build was release March 19), there are a couple rough
edges in the "Stable" build that seem the sort of thing that might
have been handled prior to that designation.

Post by Richmond
I would love to do more testing (I do almost none) but do not have
the time as I have a full work schedule both in terms of my
teaching duties and my programming ones.

True, we can only afford the time we can afford. Unicode's not very
critical for my work, so most of my testing was with v6.7, testing v7
only on Ubuntu and really only focused on the new Linux-specific
additions there.
But when a given version has new features that seem useful to us,
testing is critical to ensure that it'll do what we want to it do when
the final build comes out.
And testing needn't necessarily be all that deep. LiveCode has a lot
going on, arguably more akin to an OS than to any consumer app. We
all do different things with it, and no one can guess the exact
interaction of language elements we'll be using in our own scripts.
So while we can't be expected to test everything, if we only test our
own apps with new builds that's usually all we need for our own work.
Collectively, if we call just ensured that new features get
implemented in ways we need, we'll all have what we want.
Rather than thinking about testing LiveCode, big as it is, it may be
more helpful to think of it as testing you own app's functionality in
the sliver of LiveCode that it uses. Just test your own stuff, and
your own needs will be addressed.

Post by Richmond
Another idea would be to award "brownie points" to anyone who identifies
and documents a bug, and, after somebody has collected
enough points they could receive some sort tangible reward.

That's a good idea, and one I know Ben is keenly interested in
persuing. In fact, he's brought it up in a couple of our Community
meetings, but maybe you can help us out with some of the details we've
What sorts of perks would you find motivating, and at what level of
testing effort or bug report count should they kick in?

How about a series of T-shirts with insects all over them and the
LiveCode logo: and the words, "I've helped squash X bugs." where 'X' is
a number?

Fairly childish, but fun and effective!

Richmond.

[J. Landman Gay]

Post by Richard Gaskin
So while we can't be expected to test everything, if we only test our
own apps with new builds that's usually all we need for our own work.
Collectively, if we call just ensured that new features get implemented
in ways we need, we'll all have what we want.

If it's easy to report a bug, I do it. The lack of command key
functionality for example. I can just describe a procedure to follow.
Demonstrating a problem with an image redraw is easy and only requires a
single card with an image and a few lines of script. I jump on that sort
of thing right away.

What usually stops me is the need to create a separate, stripped-down
stack to demonstrate a more complicated bug. I completely understand the
need for this, especially in my case where the original stack is huge
and complex, and I wouldn't expect RR to plow through all that. But
extracting the exact set of circumstances that reproduce the problem
without including all the surrounding code can sometimes be a whole
afternoon's work or more, so I don't do it. I just hope someone else has
a simpler example and will report it for me instead.

I know when I do this that I'm not helping myself very much, but there's
too much going on to do otherwise.

[Richard Gaskin]

Post by Richard Gaskin
I agree, which is why it benefits no one more than ourselves to test
our
work with pre-release versions.
1) One can *either* stay with 5.5, *or* use any of the new features.
Without maintaining two codebases (impossible with livecode's
monolithic
file), there is no way to do both.
2) These prereleases just aren't ready for what they're called and
presented as. I simply cannot believe that anyone who uses the
debugger
would have signed off on it.

I'd like to raise these concerns with Ben and Kevin at my next meeting.
It would be very helpful if you could point me to the bug reports that
describe these issues.

Being in touch with them fairly regularly, I can say with confidence
that it's not like they're all sitting at the beach drinking Mai Tais.
Heck, it's Edinburgh - is it even sunny enough to go to the beach? :)

I believe they're every bit as committed as many of the community
members here in seeing LiveCode take what I feel is its rightful place
among the world's great programming languages. For that to happen they
need to cover a lot of ground, with new features, feature completion,
and QA.

As with any company, it's always a balancing act with resources. And
like most companies that survive beyond their third year (that seems the
be the threshold at which a majority close up shop) they've done
reasonably well in this narrow field of developer tools, far beyond any
xTalk before them, for so long because of a demonstrated willingness to
learn and grow, just as all of us do with our own business management.

There are many great things on the road ahead, and even in the current
versions. But it never hurts to check in along the way to make sure the
balance is optimal for all concerns.

I'll be happy to review with them the issues you cited once I can find
them in the report queue.

[Richmond]

<snip>
Being in touch with them fairly regularly, I can say with confidence
that it's not like they're all sitting at the beach drinking Mai
Tais. Heck, it's Edinburgh - is it even sunny enough to go to the
beach? :)
<snip>

While I know they are not at the beach, drinking Mai Tais, or even
glasses of "Heavy" for that matter, I do resent the comment about Edinburgh!

North of Edinburgh, in St. Andrews, where I have a house, it is often
sunny enough to go to the beach, and even go swimming:

http://www.geograph.org.uk/photo/3135428

LOL!

Richmond.

[Dr. Hawkins]

Post by Richard Gaskin

Post by Richard Gaskin
I agree, which is why it benefits no one more than ourselves to test our
work with pre-release versions.
1) One can *either* stay with 5.5, *or* use any of the new features.
Without maintaining two codebases (impossible with livecode's monolithic
file), there is no way to do both.
2) These prereleases just aren't ready for what they're called and
presented as. I simply cannot believe that anyone who uses the debugger
would have signed off on it.

I'd like to raise these concerns with Ben and Kevin at my next meeting.
It would be very helpful if you could point me to the bug reports that
describe these issues.

That's the problem. These are at a level that never should have seen the
outside to be reported as bugs.

That something unusual happens under certain circumstances is a bug. That
the IDE window regularly pauses for seconds at a time, or stops taking
input, is impossible to not notice if you actually use it.

This is a commercial product that was released without testing; *that* the
paying customers are expected to file bug reports over what should have
been done before is the fundamental problem.

I have, however, added bugs 13997-9 about the failures of the checkpoints
in the IDE

[Richard Gaskin]

Post by J. Landman Gay
What usually stops me is the need to create a separate, stripped-down
stack to demonstrate a more complicated bug. I completely understand
the need for this, especially in my case where the original stack is
huge and complex, and I wouldn't expect RR to plow through all that.
But extracting the exact set of circumstances that reproduce the
problem
without including all the surrounding code can sometimes be a whole
afternoon's work or more, so I don't do it. I just hope someone else
has a simpler example and will report it for me instead.
I know when I do this that I'm not helping myself very much, but
there's too much going on to do otherwise.

No shame in that, or if there is I'm just shameless 'cause I do that all
the time.

Like you, I recognize that not pinning down a recipe won't help me get
it fixed, but like RunRev themselves we all have to balance the desire
for completely air-tight work with the realities of keeping the doors
open.

[Richard Gaskin]

Post by Richmond
Obviously Dr Hawkins is not over-enamoured of the Open Source
theory: LiveCode is paid for in a different way [the "I'll
scratch your back if you'll scratch mine" way] than the
'standard' commercial way [I pay you, and you do ALL the work].

I think you and I may be a rare breed. I know folks in both the
proprietary and open source worlds who feel the other is the embodiment
of evil, but I see only an inherent symbiosis in which each side not
only benefits the other, but perhaps even to the point of mutually
beneficial dependency. Where would open source be without support from
proprietary vendors, and where would those vendors be without the tools
and infrastructure the open source world provides? Heck, these days
both Apple and Microsoft promote Linux - I think it's safe to say both
worlds can get along well at this point by working together.

With developer tools, the argument for open source is undeniable: of
the Top 100 Programming Languages on the TIOBE list, all but a small
handful from multi-billion-dollar companies are open source.

Since the turn of the century, the range of great tools available under
open source licenses has exploded. There's simply no way a smaller
player like LiveCode could ever hope to make it into the Top 50 without
at least an open source option.

Post by Richmond
GIMP is 100% Open Source, while Livecode both IS and ISN'T Open Source,
and RunRev has to play a terrible balancing act keeping both camps
happy.

This is another of the distinctions between consumer tools and developer
tools:

As a consumer took, GIMP does well under GPL because it doesn't need to
support developers building proprietary apps with it.

As a developer tool, LiveCode needs to provide an option for proprietary
deployment. And as a complex work, it needs considerable resources to
be maintained.

The dual-license model used by MySQL and others seems a good fit
covering both sides.

Post by Richmond
If, on buying the non-free version and it turns out to be "dicky"
I shall be even more trenchant in my response than Dr Hawkins.

And perhaps rightly so.

The issue with testing, however, is very different from the decision to
move from "Release Candidate" to "Stable" (in which case it really ought
to be stable):

With testing, the primary beneficiary is ourselves.

I've been a beta tester for Adobe, Asymetrix, Oracle, Triton, Silicon
Graphics, Canonical, and others, and I've never been paid nor expected I
would be. I did it because the quality of my own work is dependent on
theirs, and I've been in the business long enough to appreciate how the
complexity of software requires beta testing.

When I have no serious investment in a tool, I don't bother. But for
tools my business relies on, testing them to make sure they do what I
need has never struck me as anything other that just part of running a
business that relies on software.

I also do a stress test on new hard drives before I put them into
production. And I test drive cars before I buy them. Just seems like a
prudent thing to do.

Post by Richmond
He does, however, state that 'stable' versions are not much better than
the others, and that is where the problem lies.

To a degree I would agree with that. Obviously a quick review of the
change logs shows how much effort is expended to fixing show-stoppers
during the test cycle, but in all fairness to Dr. Hawkins the issue
Chipp found with the Quit item on Mac is an odd one that one could
reasonably be assumed would not warrant "Stable".

It'll be interesting to hear how that one happened. I think it's safe
to say no one at RunRev saw it and said, "Nah, good enough, ship it
anyway". I'd wager that somehow it never showed up in their daily work
for some reason, even with their large and growing set of automated
regression testing tools, and no doubt this issue has been added to that
suite since.

Post by Richmond
Several times I have stated that in my opinion RunRev are being
swept along into a sort of feature bloat which prevents them
from sorting out little 'niggles' in existing features. I se no
reason to change that opinion.

Perfectly valid. We all have our own preferences, and one of the
reasons I left the dev tools world long ago and have no intention of
returning to it is that it's full of a great many very smart people who
can each come up with compelling reasons to need very different things.

Some prefer we aim for a completely bug-free version, holding off all
new development until that's done. But there's never been a completely
bug-free app of this scope in the history of software, and with things
like Apple's deprecation of QT, their pending deprecation of Carbon,
Ubuntu's pending deprecation of 32-bit, Windows' ever-changing rendering
models, and other things in the business environment over which no one
at RunRev has any control, it's hard for them to come back to us and
demand we use outdated OS version until they deliver the world's first
bug-free dev tool.

I tend to favor performance, even though I know full well Knuth's maxim,
"Premature optimization is the root of all evil."

And others need things like Unicode, which required sweeping revision of
nearly every code module, while others need mobile native controls, and
others need PDF support, and others need something else.

It's a tough balancing act.

On the whole, given the scope of v7 and the number of true show-stoppers
being at this point one (if there are others please let me know), it's
not bad for a code base of some 800,000 lines and growing.

And I'm happy to advocate for further review of the process that moves
the designation from "Release Candidate" to "Stable".

But for that to move from an abstract "Just do more!" to specific
actionable tasks, it would be very helpful if I could get the bug report
numbers to make it possible for me to advocate for those bugs.

[Richard Gaskin]

Post by Dr. Hawkins

Post by Richard Gaskin
I'd like to raise these concerns with Ben and Kevin at my next
meeting.
It would be very helpful if you could point me to the bug reports that
describe these issues.

That's the problem. These are at a level that never should have seen
the outside to be reported as bugs.

Hard to say without knowing what the specific issue is.

Peter's investigating the SQLite issue (thanks, Peter), and that may be
a regression in LiveCode or it may be a change in SQLite itself. There
are many changes logged for SQLite in recent builds, so hopefully
Peter's analysis will help shed some light on that.

Any other specific issues you feel are show-stoppers may well be worth
looking into, and I'd be happy to help if I can. But to do that I'd
need to know what they are.

Post by Dr. Hawkins
That something unusual happens under certain circumstances is a bug.
That the IDE window regularly pauses for seconds at a time, or stops
taking input, is impossible to not notice if you actually use it.

Have you considered the possibility that things your app uses regularly
may not be used as often by others?

Post by Dr. Hawkins
This is a commercial product that was released without testing;

I think the hundreds of testers who put in thousands of hours testing
over the last 8 months would disagree.

Post by Dr. Hawkins
*that* the paying customers are expected to file bug reports over what
should have been done before is the fundamental problem.

No one's obliged to test. If having bugs fixed isn't of interest,
there's no need to let anyone know when you find them.

If you prefer to wait until after release to find out if a build will
suit your app's needs, any issues you find will, by definition, be
post-release, and can only be addressed in yet another build later in
the future.

It's a choice we make with complete freedom, with any software, or any
product, according to our own needs for such assessment.

I never bother reporting bugs for software I don't rely on. But I never
buy a car without driving it several miles first.

Post by Dr. Hawkins
I have, however, added bugs 13997-9 about the failures of the
checkpoints
in the IDE

I saw that - thanks for filing the report. I'm sure by now you got
notice that the lead engineer began researching it within 48 hours after
you'd submitted it.

I suspect this will soon join the other 1,700 reported issues that were
fixed over the last year, now that it's been brought to their attention.

This particular bug makes a good case study for the nature of testing in
all software, whether it's LiveCode, or our own, or Apple's, or anyone
else's:

A given issue may seem obvious if it's something your app uses
regularly, but it's worth noting that after 8 months of testing by
hundreds of community members in addition to internal resources both
human and automated at RunRev, this issue had never before been
reported. I'd never seen it, nor heard anyone mention anything like it.
And eight months is a long time.

This is one of the tricky things about complex systems: with so many
thousands of tokens that can be combined and recombined in nearly
infinite variety, the likelihood that the specific intersection of
features a given app needs will be easily found by others simply can't
be assured.

If you want to use a new version, it can help you get any issues that
need resolving done before release if you choose to try the pre-release
builds.

No one's required to test. But many of us choose to do so because it
benefits our own goals.

[Dr. Hawkins]

Post by Richard Gaskin
Any other specific issues you feel are show-stoppers may well be worth
looking into, and I'd be happy to help if I can. But to do that I'd need
to know what they are.

That the IDE doesn't work?

I filed those bugs, but can anyone really have used the IDE and breakpoints
without noticing the hangs, and the inability to set these?

And how many years has it been since a current version can watch a global
variable without crashing? or the false failures to compile over shadowed
names?

If I spend a day programming, I have to kill livecode a dozen or more times.

[William Prothero]

Folks:
Just to chime in on this. I’ve been using version 7.0 for a couple of months. No problems. I’m not using many of the new features like unicode, but have found the IDE working fine for my purposes, so far. The slowdown in some operations has affected me, though. Picking out a byte from a large byte array is slower than older versions.

That said, I’m glad you guys are finding the bugs in features I don’t use, because eventually, I will use them.
Best,
Bill

William A. Prothero
http://es.earthednet.org/

Post by Dr. Hawkins

Post by Richard Gaskin
Any other specific issues you feel are show-stoppers may well be worth
looking into, and I'd be happy to help if I can. But to do that I'd need
to know what they are.

That the IDE doesn't work?

[Mark Talluto]

Any other specific issues you feel are show-stoppers may well be worth looking into, and I'd be happy to help if I can. But to do that I'd need to know what they are.

Hi Richard,

Thanks for taking this on. These are stopping us from using 7 either in shipping applications and in some cases development:

Move command renders graphics improperly when screen has been recently locked
http://quality.runrev.com/show_bug.cgi?id=13961

Player object should be able to transform video content
http://quality.runrev.com/show_bug.cgi?id=13942
(We are currently relying on Trevor’s excellent QT External for this. Thus, this is really an enhancement.)

Color overlay doesn't seem to be applied to alpha channel correctly
http://quality.runrev.com/show_bug.cgi?id=11520

(Fixed but not released) Command keys not working correctly
http://quality.runrev.com/show_bug.cgi?id=13847

This list does not include a serial port communication bug. The general issue is that serial communication is very slow. We rely on serial communication for our remote control system to communicate with the vision testing software. Just need to find the time to build a recipe stack this one.

The overall slowness of 7 is also an issue. Thankfully plenty of benchmarking scripts are being created by the wonderful people on this list to show those issues. I personally think there should be more life applied to the 6.7 cycle. This will be important until 7 matures.

A quick glance at which engine is used for some of our applications:
Live Events Conference App: 6.6.3
20/20 Vision Testing Software: 6.1.1
LiveCloud Servers: 6.6.5
LiveCloud Manager: 6.5.1
Electronic Medical Records (under development): Shooting for 6.7

You might ask yourself why we are using such a range of engines. Why not use the latest or why not use only one or two? Selecting the right engine depends on a number of factors like: Is this for mobile or desktop. Then there are sub-factors like: Media playback features needed, serial port access, graphic overlay use, text manipulation, array features, and various bug fixes that affect your particular app. These are just the ones that come to mind.

Best regards,

Mark Talluto
livecloud.io
canelasoftware.com

[Alejandro Tejada]

Hi Richard,

on Tue, 11 Nov 2014
Richard Gaskin wrote:

[snip]

Post by Richard Gaskin
On the other issues, can you share the
bug report numbers so we can follow them?

Does exist an automatic way to post
every new bug report in this mail list?

Could bugzilla do this?
In this way, every bug will be noticed and
reviewed by all mail list users.

Al

[Richard Gaskin]

Post by Dr. Hawkins

Post by Richard Gaskin
Any other specific issues you feel are show-stoppers may well be worth
looking into, and I'd be happy to help if I can. But to do that I'd
need
to know what they are.

That the IDE doesn't work?

I'll run a search for "IDE doesn't work" and see what I can come up
with. ;)

Post by Dr. Hawkins
I filed those bugs, but can anyone really have used the IDE and
breakpoints
without noticing the hangs, and the inability to set these?

Thanks for noting which bugs were concerning you.

The one I had referred to was about the card reference, which has
already been fixed:
http://quality.runrev.com/show_bug.cgi?id=13972


For those following this the breakpoint bugs are:
http://quality.runrev.com/show_bug.cgi?id=13997
http://quality.runrev.com/show_bug.cgi?id=13998
http://quality.runrev.com/show_bug.cgi?id=13999

I did a quick triage on those:

The first one ('97) was especially interesting because in all the years
I'd been using LC I'd never used that particular feature. The
description of that feature on p68 of the User Guide does seem to match
your expectations, and I was able to confirm your report.

The second one ('98) was one that could benefit from others here who've
used the debugger more than I have (Jacque, that means you <g>). I'm
not sure if it's a bug or merely needs more explanation in the docs.

The last one ('99) I was unable to reproduce, but if there are any
additional steps I can follow to reliably reproduce I'd be happy to
submit my notes there.

Post by Dr. Hawkins
And how many years has it been since a current version can watch a
global
variable without crashing? or the false failures to compile over
shadowed
names?

Bug #s?

Anyone else experience those?

There was a recent comment about shadowed name warnings in the Facebook
group recently, but that seemed related to turning on the feature to
warn about those (Prefs -> Script Editor -> Strict Compilation Mode).
The person who noted the issue reported back that after restoring that
feature to its default "off" setting he was happy. Is that not working
for you?

[Mark Talluto]

There was a recent comment about shadowed name warnings in the Facebook group recently, but that seemed related to turning on the feature to warn about those (Prefs -> Script Editor -> Strict Compilation Mode). The person who noted the issue reported back that after restoring that feature to its default "off" setting he was happy. Is that not working for you?

I have seen this one too. My quick enough work around is copy the script to memory. Empty the script from the control that is complaining and compile. Then paste the script back into the control. The true issue will properly error at the bottom of the script editor. Fix that issue and compile again. Everything goes back to normal.


Best regards,

Mark Talluto
livecloud.io
canelasoftware.com

[Dr. Hawkins]

Post by Richard Gaskin
Any other specific issues you feel are show-stoppers may well be worth

Post by Richard Gaskin
looking into, and I'd be happy to help if I can. But to do that I'd need
to know what they are.

That the IDE doesn't work?

I'll run a search for "IDE doesn't work" and see what I can come up with.
;)

:)

http://quality.runrev.com/show_bug.cgi?id=13997
http://quality.runrev.com/show_bug.cgi?id=13998
http://quality.runrev.com/show_bug.cgi?id=13999
The first one ('97) was especially interesting because in all the years
I'd been using LC I'd never used that particular feature. The description
of that feature on p68 of the User Guide does seem to match your
expectations, and I was able to confirm your report.

The only reason *I* found it (the feature) was that I was trying to set
breakpoints, and my usual ways didn't work.

The second one ('98) was one that could benefit from others here who've
used the debugger more than I have (Jacque, that means you <g>). I'm not
sure if it's a bug or merely needs more explanation in the docs.

I suspect it may need someone running livecode itself in another debugger,
or massive checkpoint dumping in the IDE code.

The last one ('99) I was unable to reproduce, but if there are any
additional steps I can follow to reliably reproduce I'd be happy to submit
my notes there.

It seems to be some level of corruption that survives saving and reloading.

And how many years has it been since a current version can watch a global

Post by Richard Gaskin
variable without crashing? or the false failures to compile over shadowed
names?

Bug #s?
Anyone else experience those?

These get discussed here every few months.

There was a recent comment about shadowed name warnings in the Facebook
group recently, but that seemed related to turning on the feature to warn
about those (Prefs -> Script Editor -> Strict Compilation Mode). The
person who noted the issue reported back that after restoring that feature
to its default "off" setting he was happy. Is that not working for you?

!!!

No, not having strict compilation can't make me happy; I depend upon such
things. (I don't even like the lack of case sensitivity in names, or the
inability to apply types, but those only bite on the database side, and I
have scripts that watch my stacks for those on every build.

[J. Landman Gay]

Post by Richard Gaskin
The second one ('98) was one that could benefit from others here who've
used the debugger more than I have (Jacque, that means you <g>). I'm
not sure if it's a bug or merely needs more explanation in the docs.

For reference: http://quality.runrev.com/show_bug.cgi?id=13998

I added a comment there. It is quite possible (and convenient!) to add a
breakpoint while debugging, I do it all the time. But I have never
right-clicked, I always just left-click normally on a line number and it
works. I just tested it again in 7.0.1 rc 1 and it still works here.

The next bug (13999) mentions a popup that should appear when
right-clicking a line number. I don't see one in 6.x either, and I'm not
sure I remember ever seeing it, though it vaguely rings a bell. That
said, right-clicking on an existing and active breakpoint *does* put up
the expected popup, the one that gives you debugging options. So I don't
see any problems here.

I don't know if the removal of the line-number popup was intentional or
even if I'm remembering it correctly. I may be thinking of the popup
that appears in the Breakpoints pane when you right-click. That one
still works in 7.0.

The last bug (13999) mentions a greyed-out breakpoint and a lack of
responsiveness in the script editor. A breakpoint will be grey if its
script has been edited but not recompiled yet. Since saving a stack will
also save any uncompiled scripts, the grey breakpoint and a confused
editor will persist across relaunches.

An unresponsive IDE was mentioned. The editor and the IDE can both
become "frozen" if you are debugging and you try to do something else
without exiting debug mode. Not only can you not type into the editor,
which is to be expected, but most of your stack and even the IDE won't
respond either (though the message box still works, and the app
browser.) Almost everything else just stops and you are in a state of
suspension while the engine waits for debugging to finish. The solution
is to hit the blue square to stop debugging, or to hit the Run button to
execute the rest of the handler, and everything picks up again. I've
never seen the IDE freeze up outside of that situation.

We used to get questions in the support queue about that. People didn't
realize they were still in debug mode.

[J. Landman Gay]

That said, right-clicking on an existing and active breakpoint *does*
put up the expected popup, the one that gives you debugging options. So
I don't see any problems here.

I take that back, I didn't test far enough. The popup appears and the
dialog is put up, but clicking OK after entering a line number does
nothing. So yeah, this is a bug.

[Dr. Hawkins]

An unresponsive IDE was mentioned. The editor and the IDE can both become
"frozen" if you are debugging and you try to do something else without
exiting debug mode. Not only can you not type into the editor, which is to
be expected, but most of your stack and even the IDE won't respond either
(though the message box still works, and the app browser.) Almost
everything else just stops and you are in a state of suspension while the
engine waits for debugging to finish. The solution is to hit the blue
square to stop debugging, or to hit the Run button to execute the rest of
the handler, and everything picks up again. I've never seen the IDE freeze
up outside of that situation.

What works, however, is far more limited than in 5.5.

The freezes I see include while editing or scrolling, when it freezes for
2-5 seconds before accepting clicks or keys, and just plain locking up
*after* exiting debugging and refusing evermore to make any changes,
requiring a restart of livecode.

[Bob Sneidar]

Let me just say that for some folks who do not have enough time to report bugs, they certainly have found an abundance of time to post their frustrations to this list! Just sayin’.

Bob S

[Richmond]

Post by Bob Sneidar
Let me just say that for some folks who do not have enough time to report bugs, they certainly have found an abundance of time to post their frustrations to this list! Just sayin’.
Bob S
_______________________________________________

Ooo! Bi*chy :)

The point that came out of this discussion is that the LiveCode
'Community' are dividing into two camps:

1. The Open Source, willing-to-pitch-in-and-help brigade, who pay for
their LiveCode by contributing, bug-hunting and so forth.

2. The Commercial, I-pay-and-I-expect quality brigade, who do not want
to have to worry their pretty little heads about bugs.

The latter group have just as much right to complain about bugs as the
former one.

Richmond.

[Peter Haworth]

Can't quite agree with that simplistic analysis. There are many Commercial
users who test the dp and rc releases, especially if they contain fixes for
bugs they reported.

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

Post by Richmond

Post by Bob Sneidar
Let me just say that for some folks who do not have enough time to report
bugs, they certainly have found an abundance of time to post their
frustrations to this list! Just sayin’.
Bob S
_______________________________________________

Ooo! Bi*chy :)
The point that came out of this discussion is that the LiveCode
1. The Open Source, willing-to-pitch-in-and-help brigade, who pay for
their LiveCode by contributing, bug-hunting and so forth.
2. The Commercial, I-pay-and-I-expect quality brigade, who do not want to
have to worry their pretty little heads about bugs.
The latter group have just as much right to complain about bugs as the
former one.
Richmond.
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Geoff Canyon]

Post by Bob Sneidar
Let me just say that for some folks who do not have enough time to report
bugs, they certainly have found an abundance of time to post their
frustrations to this list! Just sayin’.

It takes far less time to send an email than it does to file a bug. This
has gotten better with the new bug entry interface -- not sure when that
went in.

[Richard Gaskin]

Post by Mark Talluto
Thanks for taking this on. These are stopping us from using 7 either
in shipping
Move command renders graphics improperly when screen has been recently
locked
http://quality.runrev.com/show_bug.cgi?id=13961
Player object should be able to transform video content
http://quality.runrev.com/show_bug.cgi?id=13942
(We are currently relying on Trevor’s excellent QT External for this.
Thus, this
is really an enhancement.)
Color overlay doesn't seem to be applied to alpha channel correctly
http://quality.runrev.com/show_bug.cgi?id=11520
(Fixed but not released) Command keys not working correctly
http://quality.runrev.com/show_bug.cgi?id=13847
This list does not include a serial port communication bug. The general
issue is that serial communication is very slow. We rely on serial
communication for our remote control system to communicate with the
vision
testing software. Just need to find the time to build a recipe stack
this one.
The overall slowness of 7 is also an issue. Thankfully plenty of
benchmarking
scripts are being created by the wonderful people on this list to show
those
issues. I personally think there should be more life applied to the 6.7
cycle.
This will be important until 7 matures.

Very helpful - thanks for posting that list. I've added them to my
notes for my next Community meeting with them.

The fixed item is good to see, but of course it would have been better
to see it fixed before release. Do you happen to know offhand if that
was a late-stage regression?

The enhancement request seems very useful, though of course it'll likely
play a minimal role in a discussion of show-stoppers.

The other two are interesting, and I look forward to learning the
challenges behind those.

[Richard Gaskin]

Post by Dr. Hawkins

Post by Richard Gaskin
The first one ('97) was especially interesting because in all the
years
I'd been using LC I'd never used that particular feature. The
description
of that feature on p68 of the User Guide does seem to match your
expectations, and I was able to confirm your report.

The only reason *I* found it (the feature) was that I was trying to set
breakpoints, and my usual ways didn't work.

I've always just clicked om the line number. I know you've reported an
issue doing that while the script is running, but are you also unable to
set the breakpoints by clicking the line number at all?

Post by Dr. Hawkins

Post by Richard Gaskin
There was a recent comment about shadowed name warnings in the
Facebook
group recently, but that seemed related to turning on the feature to
warn
about those (Prefs -> Script Editor -> Strict Compilation Mode). The
person who noted the issue reported back that after restoring that
feature
to its default "off" setting he was happy. Is that not working for
you?

!!!
No, not having strict compilation can't make me happy; I depend upon
such things. (I don't even like the lack of case sensitivity in names,
or the inability to apply types, but those only bite on the database
side,
and I have scripts that watch my stacks for those on every build.

It seems I had misunderstood. What's the bug report number for that
one?

[Dr. Hawkins]

Post by Richard Gaskin

Post by Richard Gaskin
The first one ('97) was especially interesting because in all the years

Post by Richard Gaskin
I'd been using LC I'd never used that particular feature. The
description
of that feature on p68 of the User Guide does seem to match your
expectations, and I was able to confirm your report.

The only reason *I* found it (the feature) was that I was trying to set
breakpoints, and my usual ways didn't work.

I've always just clicked om the line number. I know you've reported an
issue doing that while the script is running, but are you also unable to
set the breakpoints by clicking the line number at all?

I filed that as a separate bug. Yes, once it's corrupted enough, it
ignores line-number clicking, which is why I discovered the other. I
experimented, and foudn it.

Post by Richard Gaskin
There was a recent comment about shadowed name warnings in the Facebook

Post by Richard Gaskin

Post by Richard Gaskin
group recently, but that seemed related to turning on the feature to warn
about those (Prefs -> Script Editor -> Strict Compilation Mode). The
person who noted the issue reported back that after restoring that
feature
to its default "off" setting he was happy. Is that not working for you?

!!!
No, not having strict compilation can't make me happy; I depend upon
such things. (I don't even like the lack of case sensitivity in names,
or the inability to apply types, but those only bite on the database side,
and I have scripts that watch my stacks for those on every build.

It seems I had misunderstood. What's the bug report number for that one?

To start with, Peter Hayworth filed *Bug 10511*
<http://quality.runrev.com/show_bug.cgi?id=10511> in 2006 . . . but wee
discuss this every three or fourt months on this list.

[Richard Gaskin]

Post by Dr. Hawkins
Now, to make matters worse, it appears that I've been using 7.0.0,
not 7.0.1-RC-1 for an unknown period of time--it has managed to
set itself as the default version more than once on this machine.

If that's on a Mac, I don't believe there's anything a developer can do
- that's a long-standing Finder "feature", in which it uses rules known
only to itself to determine which version to launch whenever a
compatible file is double-clicked.

For greater control over app versions I put all the ones I use in my
Dock and launch them explicitly from there.

[Terry Judd]

Post by Richard Gaskin
For greater control over app versions I put all the ones I use in my
Dock and launch them explicitly from there.

I¹m sure you¹re not alone there. I have six versions of LC in my dock that
I use for different projects and for testing. I have many more than that
in my Applications folder.

Terry...

[Richmond]

Post by Terry Judd

Post by Richard Gaskin
For greater control over app versions I put all the ones I use in my
Dock and launch them explicitly from there.

I¹m sure you¹re not alone there. I have six versions of LC in my dock that
I use for different projects and for testing. I have many more than that
in my Applications folder.
Terry...

I have 13 versions along the 'dock' on my Ubuntu Studio machine, all with
differently coloured icons, as I develop my language tools with 4.5 and
my educational in-house stuff with
anything Open Source.

And several versions of MetaCard.

I have every version (dp, rc, gm, stable) since the first Open Source
release installed as I am just too
lazy to take the time to remove anything.

SO, I NEVER double-click on a .rev, .mc or .livecode file as that would
be like playing Russian roulette.

Richmond.

[J. Landman Gay]

Post by Terry Judd

Post by Richard Gaskin
For greater control over app versions I put all the ones I use in my
Dock and launch them explicitly from there.

I¹m sure you¹re not alone there. I have six versions of LC in my dock that
I use for different projects and for testing. I have many more than that
in my Applications folder.

I've only got four in the dock and maybe a dozen in Applications. Have
you seen screenshots of the RR team's dock? They must have twenty in
there. :)

[Richard Gaskin]

Post by Dr. Hawkins
To start with, Peter Hayworth filed *Bug 10511*
<http://quality.runrev.com/show_bug.cgi?id=10511> in 2006
. . . but wee discuss this every three or fourt months on
this list.

I recall only vague descriptions with no clear outcome, and that
amazingly long bug report evidences why.

Apparently after a very long period of some of the best minds at RunRev
and within this community exploring the issue from every angle, only
fairly recently did a seemingly reliable recipe emerge, but with Peter's
most recent note there it appears the root cause remains as the recipe.

Many thanks to Peter, Ralph, Monte, and the others who contributed to
that. Good reading about thorough diagnostic process in the face of a
problem that for most had been unpredictably intermittent.

Hopefully this can be worked out. Interesting problem.

[Mark Schonewille]

I agree. I have always felt that RunRev should occasionally hire one or
two people for beta-testing. They could test new releases before they
are labelled pre-release. This would cost only a little money and safe
hundreds, if not thousands of people lots of frustrations.

--
Best regards,

Mark Schonewille

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

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book "Programming LiveCode for the Real Beginner"
http://qery.us/3fi

LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

Post by Dr. Hawkins
I can't help but wonder what it would take to get runrev to follow normal
practice and actually get something to alpha level before calling it a
"developer preview", beta by a "release candidate" (ok, that still wouldn't
be normal), and working rather than early beta before release.
If I sold something at these stages, I'd be out of business by sundown.
Do the developers even pretend to use the IDE before slapping "release
candidate" on it? Do they even have some kind of test suite?
The sheer number of pieces of working code that have broken when going from
5.5 to 7.0 is beyond belief, as is the giant step backward in the IDE.
I used to have to kill livecode frequently for the phantom "shadow
variable" problem. While that happens more often under 6 (which is why I
could never use it) and 7, I now usually have to kill the whole thing
before that happens, as I can't get it to set a breakpoint, or even
acknowedge that I've clicked anything, delays of several seconds, and so
forth.
In addition to the others I've mentioned here an in other recent posts, the
recompile of sqlite is not quite compatible with the old, and behaves
differently. For example, a semicolon at the end of an entry without
begin/end transaction now causes a parsing error.
Moving forward is one thing, but the only near release grade version is
5.x, which itself isn't quite ready for primetime.
OK, I'll stop venting, but the amount of time I'm losing to bugs that never
should have seen a public preview is getting increasingly frustrating.

[Richard Gaskin]

Post by Geoff Canyon
It takes far less time to send an email than it does to file a bug.

If you just want to type, the difference is negligible.

If you want to actually see the bug fixed, the ROI for filing a bug
report is much higher. ;)

[Geoff Canyon]

Any positive value is higher than zero, so sure. I'm just expressing
frustration about barriers to reporting bugs. For example, a login is
required to file a bug, and the bug submission form all but requires an
example stack. I understand the desire to get clear, actionable bug
reports, and I understand the need to not waste limited team resources on
bad bug reports, but if the requirements are causing Jacque to fail to
report a bug, that's a huge issue.

Post by Geoff Canyon
It takes far less time to send an email than it does to file a bug.
If you just want to type, the difference is negligible.
If you want to actually see the bug fixed, the ROI for filing a bug report
is much higher. ;)
--
Richard Gaskin
LiveCode Community Manager
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

[Richmond]

WINE has an interesting release model: https://www.winehq.org/

Every 2 weeks, dead on time, they release another beta version,
and whenever (and 'whenever' can mean anything between 2 weeks to 2
years) they
release a stable version.

The beta versions are labelled like this: 1.7.1, 1.7.2 and so on.

The stable releases always have an even number in second place, so 1.6,
1.8 etc.

They advise anybody except for nutty fruitcakes like myself to stick with
the stable releases and explicitly state that they accept NO responsibility
for anything the beta versions may do.

Richmond.

[Richard Gaskin]

I'm just expressing frustration about barriers to reporting bugs.
For example, a login is required to file a bug...

...as it is for this list, which the bug system is being compared to.

Just about any publicly-accessible venue that displays user-generated
content will either require some form of authentication, or be overrun
to the point of uselessness by spambots.

Like this list and the forums, the account setup for RunRev's Bugzilla
DB is just a one-time thing. And like the forums, you can choose to
have it remember your login, so from that moment forward you'll never
need to log in again.

...and the bug submission form all but requires an example stack.

"But" seems the key word there, because while it can sometimes be useful
to submit an example stack it isn't a requirement. Most of the reports
there have no attachments at all, even those submitted by RunRev staff
themselves.

All that's truly needed is any description of the issue clear enough to
allow it to be reproduced by the maintainers.

Like nearly all bug reporting systems they suggest a step-by-step
recipe, but sometimes that's not needed. Many submissions are just a
single line, like "Run this in the Message Box: <some command>".

In some cases, like the report Dr. Hawkins referred to that Peter had
submitted about breakpoints, the issue may elude a reliable recipe. In
that report many from both the community and RunRev have worked toward
arriving at a repeatable recipe, yet even now there appears to be some
disagreement as to whether the recipes there actually work.

But even in those cases, Ben, Kevin and others at RunRev have encouraged
us to go ahead and submit the issue anyway. Just include the best info
you have, and the core team and the community can continue to add notes
there as they work toward an actionable diagnosis.

When a recipe is truly elusive, that's when this list and the forums
become very valuable:

By describing the issue among peers, we can solicit feedback from others
who may have experienced what we're seeing, or something similar enough
to be relevant, and together we can work toward an actionable
description of the problem.

I understand the desire to get clear, actionable bug reports,
and I understand the need to not waste limited team resources
on bad bug reports, but if the requirements are causing Jacque
to fail to report a bug, that's a huge issue.

In this comparison between posting bugs to this user-to-user discussion
list vs. putting them into the bug DB where they can be acted on, I
don't think Jacque's comment applies.

After all, it's not like she choose to take the time to report it here
either.

All she noted was that sometimes when she's under a heavy deadline to
ship something with the version she has, she doesn't take the time to
submit a bug report at all, either here or in the bug DB.

I noted in reply to her post that I often to do the same, as we all do
when we're busy.

None of us is obliged to submit bug reports. We can choose to submit
them when a bug impacts our work to the point that it benefits us to see
it resolved. Or not. It's entirely voluntary.


Looking forward....

As you noted the current version of the Bugzilla implementation RunRev
has is much improved over earlier versions, and there may be ways it
could be streamlined further still.

Many years ago one of our community members, Ken Ray, made a nifty
plugin stack to submit and review Bugzilla posts from within the IDE.

It's long since outdated and he's been too busy with other commitments
to maintain it, and like myself and others, he's found the Web
implementation usable enough that it hasn't been an impediment for him.

But if going to the Web page is holding folks back from submitting a
bug, I'm sure Ken would grant permission for anyone with sufficient time
and interest to rewrite his stack to work with the current bug DB.

It's available as "Revzilla", the first link on this page:
<http://www.sonsothunder.com/devres/livecode/downloads.htm>

If there's interest I'd be happy to contact him to get explicit
permission for such a revision.

That's just one option. There may be others.

What other things might we consider to make filing bug reports into the
bug DB significantly more efficient than filing them here in this
user-to-user list?

[Sean Cole (Pi)]

HI Richard,

I have a suggestion for this, having just read the entire thread.

I too find it hard at times to get the time to even write here let alone
fill out a report on Bugzilla. And then to go through the process of
creating a recipe or sample stack. The reason for this is obvious, that
like many others here we are too busy actually making products (or trying
to) for our paying clients to set deadlines (often unreasonable, mostly due
to their ongoing misconception to the time it takes to make software
despite attempts to help them appreciate or understand it). The Bugzilla
form is, I'm sure you'd agree, far more involved than writing an email. And
I in turn appreciate that protocols need to be in place to avoid spammers,
etc.

How about this approach (which is nothing new - Apple use a similar system
and I personally have had much success with it). In the LiveCode app itself
(both Commercial and Community) in the Help menu should be a button to
submit a report. This can either take you to a basic form on the web or
internally in the app itself (a better option to keep down spam). This goes
through to a private list that only those on the RunRev development team
can read. This form should be far simpler than that found on Bugzilla,
i.e., Name, email, symptoms noticed, option to upload stack. If it was
included in the IDE then it would automatically gather data like the
platform, version number, etc. The team member that picks it up can then
decide if it is worth adding to Bugzilla, adding the submitters email to
the list and requesting more info via the Bugzilla repository if needed.

Psychologically this works in favour of the end user. They would be more
likely to provide feedback willingly if the thought that it was easy and
involved far less steps. You could even have a button on the form to
provide more details that could log you right into your Bugzilla account in
a one step process filling in any data you'd already provided and those
acquired from the system.

I have a bug (Bug 13801 <http://quality.runrev.com/show_bug.cgi?id=13801>) I
reported a little while back that, because I had no time because of my
clients demands on my time, has been marked as 'Resolved' due to my not
responding to their request for a sample stack. When my time is a little
more free'd up (i.e., not now, despite my ability to write this email -
proof that what you said earlier was bumpkin and unfair - emails are easier
to write than are sample stacks that can replicate issues along with
recipes.) I will be able to reopen the report and prove that it is indeed
an issue that needs resolving.

Here are some more reasons I find using Bugzilla so frustrating
(infuriating at times). The search feature (a term I use lightly) is
appalling. Loading it (bearing in mind I have a 150MB internet line) takes
over 10 seconds to load. Every. Single. Time. That. I. Want. To. Do. A.
New. Search!! So, trying to track down if someone else has already done one
is laborious. If i enter my search in the bar at the top of the page it
only returns new and pending results. So resolved ones are not shown. But
that is not made clear in the search bar. So then you have to go to the
advanced search which is not clear on how to access (at the top we have
buttons for Home, New & Search then a Search Button after the search
dialogue - Is that clear?). When I add a comment to a bug and click the
'save changes' button it saves but then takes me to the next bug in the
list. As an alternative I can write a rant on here with far more
satisfaction and far less time wasted ;)

Simple is best, my favourite philosophy. A simple form in the IDE that gets
submitted for review and/or follow up. Far more likely to get results.

All the best

Post by Richard Gaskin

I'm just expressing frustration about barriers to reporting bugs.
For example, a login is required to file a bug...

...as it is for this list, which the bug system is being compared to.
Just about any publicly-accessible venue that displays user-generated
content will either require some form of authentication, or be overrun to
the point of uselessness by spambots.

Sean Cole
*Pi Digital Productions Ltd*
www.pidigital.co.uk
[phone]
[phone]
π
'Don't try to think outside the box. Just remember the truth: There is no
box!'
'For then you realise it is not the box you are trying to look outside of,
but it is yourself!'

This email and any files transmitted with it may be confidential and are
intended solely for the use of the individual to whom it is addressed. You
are hereby notified that if you are not the intended recipient of this
email, you must neither take any action based upon its contents, nor copy
or show it to anyone. Any distribution, reproduction, modification or
publication of this communication is strictly prohibited. If you have
received this in error, please notify the sender and delete the message
from your computer.



Any opinions presented in this email are solely those of the author and do
not necessarily represent those of Pi Digital. Pi Digital cannot accept any
responsibility for the accuracy or completeness of this message and
although this email and any attachments are believed to be free from
viruses, it is the sole responsibility of the recipients.


Pi Digital Productions Ltd is a UK registered limited company, no. 5255609.
VAT GB998220972

[Richard Gaskin]

Post by Sean Cole (Pi)
I have a suggestion for this, having just read the entire thread.
How about this approach (which is nothing new - Apple use a similar
system and I personally have had much success with it). In the
LiveCode app itself (both Commercial and Community) in the Help menu
should be a button to submit a report. This can either take you to a
basic form on the web or internally in the app itself (a better
option to keep down spam).

That's an excellent suggestion - I'll pursue that with Ben later this
morning.

Post by Sean Cole (Pi)
I have a bug (Bug 13801

<http://quality.runrev.com/show_bug.cgi?id=13801>) I

Post by Sean Cole (Pi)
reported a little while back that, because I had no time because of
my clients demands on my time, has been marked as 'Resolved' due to
my not responding to their request for a sample stack. When my time
is a little more free'd up (i.e., not now, despite my ability to
write this email - proof that what you said earlier was bumpkin and
unfair - emails are easier to write than are sample stacks that can
replicate issues along with recipes.) I will be able to reopen the
report and prove that it is indeed an issue that needs resolving.

My apologies if what I wrote seemed unfair.

It's statistically accurate to note that an overwhelming majority of
issues in the bug DB do not have example stacks attached, and that
includes the 1600+ items fixed over the last year.

From time to time a given issue may elude a simple recipe, and in those
cases it may be beneficial to provide an example stack.

It's helpful that you provided the link to the report, as we can see
there that while Hanson asked if you had a sample stack he never
required it for you to re-open the report if you choose to do so.

The one thing he did require is that you please try to see the issue in
the latest build, and given the scope of changes between builds lately
it's not impossible it may have been addressed while fixing other things.

One of the benefits of an open source project having a Community Manager
is that you get another whipping post: yours truly. :) I'm happy to
advocate any community concern that hasn't been sufficiently addressed
through other channels.

In this case, however, the only action needed is to verify that the
issue remains in the latest version, and to write one sentence there
noting if that's the case. I haven't seen this myself, so I'll have to
rely on your help on that.

As Hanson wrote there, with your notice that the issue remains they'll
devote internal resources to trying to reproduce it.

[Andrew Henshaw]

Does anyone have any ideas when I get a messagebox with 'Could not compile application class’ in it when I try to save an app so I can deploy it on an iPhone, and at the same time I get a another window popping up saying I need Java runtime environment.

Its frustrating as its only on one app, everything else works fine but there is nothing special in the app, the build settings are exactly same as another than compiles file, it has no included files, im at a loss.

[Ralph DiMola]

This is an error I have received for Android builds a couple of times. It is usually caused by an update to the Android SDK. Do you have the Android build checked?

Ralph DiMola
IT Director
Evergreen Information Services
***@evergreeninfo.net

-----Original Message-----
From: use-livecode [mailto:use-livecode-***@lists.runrev.com] On Behalf Of Andrew Henshaw
Sent: Thursday, November 13, 2014 12:20 PM
To: How to use LiveCode
Subject: Could not compile application class

Does anyone have any ideas when I get a messagebox with 'Could not compile application class’ in it when I try to save an app so I can deploy it on an iPhone, and at the same time I get a another window popping up saying I need Java runtime environment.

Its frustrating as its only on one app, everything else works fine but there is nothing special in the app, the build settings are exactly same as another than compiles file, it has no included files, im at a loss.
_______________________________________________
use-livecode mailing list
use-***@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

[Neil Roger]

Hi Andrew,

The could not "compile application class message" will genreally occur
when you are trying to build for Android and there is a discrepancy in
your Android SDK/Java setup.

In your message you mention that you are trying to build for an iPhone
so it could be that you have Android checked in your stacks standalone
application settings.

Kind Regards,

Neil Roger
--
LiveCode Support Team ~ http://www.livecode.com
--

Post by Andrew Henshaw
Does anyone have any ideas when I get a messagebox with 'Could not compile application class’ in it when I try to save an app so I can deploy it on an iPhone, and at the same time I get a another window popping up saying I need Java runtime environment.
Its frustrating as its only on one app, everything else works fine but there is nothing special in the app, the build settings are exactly same as another than compiles file, it has no included files, im at a loss.
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Andrew Henshaw]

Nope, only iPhone checked.

I went back to 6.6.5 and it compiled fine, so the error only happens in LC6.7 and LC 7.

Odd, hopefully its just a one off and will work itself out somehow, its only happening in one app, everything else compiles fine.

Thanks

Andy

Post by Neil Roger
Hi Andrew,
The could not "compile application class message" will genreally occur when you are trying to build for Android and there is a discrepancy in your Android SDK/Java setup.
In your message you mention that you are trying to build for an iPhone so it could be that you have Android checked in your stacks standalone application settings.
Kind Regards,
Neil Roger
--
LiveCode Support Team ~ http://www.livecode.com
--

[J. Landman Gay]

Post by Geoff Canyon
if the requirements are causing Jacque to fail to
report a bug, that's a huge issue.

Well, to be fair, it doesn't always prevent me from reporting things. If
I have time I do create an example stack, especially if my current work
can't proceed without a bug fix. But I've also found that if a problem
is pretty obvious, about 80% of the time someone else will report it.
The failure of the command keys is one example where there were multiple
reports without my help.

[Geoff Canyon]

Post by Geoff Canyon
if the requirements are causing Jacque to fail to
report a bug, that's a huge issue.

Well, to be fair, it doesn't always prevent me from reporting things. If I
have time I do create an example stack, especially if my current work can't
proceed without a bug fix. But I've also found that if a problem is pretty
obvious, about 80% of the time someone else will report it. The failure of
the command keys is one example where there were multiple reports without
my help.

I didn't mean to imply that the system is preventing you from entering any
bugs; I'm saying that given your many years of experience and dedication to
the platform if the system prevents you from entering even a single bug,
that's bad.

[J. Landman Gay]

Post by Geoff Canyon
I didn't mean to imply that the system is preventing you from entering any
bugs; I'm saying that given your many years of experience and dedication to
the platform if the system prevents you from entering even a single bug,
that's bad.

The thing is, I don't blame the system at all, I think it's my own
fault. As a developer, I always need a reproducible recipe to fix bugs,
and requiring a stack that provides the recipe is reasonable. I blame
myself for the omissions (except when Richard G. forgives me.) :)

[Geoff Canyon]

I blame myself for the omissions (except when Richard G. forgives me.) :)

"Bless me Richard, for I have sinned. It has been two weeks since my last
bug report. Since then I wrote three undocumented functions and one 80-line
behemoth that was filled with hard-coded situation-specific functionality.
I also used repeat-with when I should have used repeat-for-each twice."

"File two bug reports and say ten Our Kevins."

[J. Landman Gay]

Post by Geoff Canyon

I blame myself for the omissions (except when Richard G. forgives me.) :)

"Bless me Richard, for I have sinned. It has been two weeks since my last
bug report. Since then I wrote three undocumented functions and one 80-line
behemoth that was filled with hard-coded situation-specific functionality.
I also used repeat-with when I should have used repeat-for-each twice."
"File two bug reports and say ten Our Kevins."

LOL! Okay.

Our Kevin, who art at RunRev,
Hollowed be thy frame
By coding done
Yet still undone in engine,
As it is in IDE.
Give us this day our weekly upgrade
And forgive us our complaints
As we forgive the multitude of releases.
And lead us not to false expectations,
But deliver us from errors,
For thine is the vision,
The power, and the glory
For all generations.

[Bob Sneidar]

Hah hah! I would have used “For all permutations” instead!

Bob S


On Nov 14, 2014, at 10:47 , J. Landman Gay <***@hyperactivesw.com<mailto:***@hyperactivesw.com>> wrote:

LOL! Okay.

Our Kevin, who art at RunRev,
Hollowed be thy frame
By coding done
Yet still undone in engine,
As it is in IDE.
Give us this day our weekly upgrade
And forgive us our complaints
As we forgive the multitude of releases.
And lead us not to false expectations,
But deliver us from errors,
For thine is the vision,
The power, and the glory
For all generations.

[J. Landman Gay]

Post by Bob Sneidar
Hah hah! I would have used “For all permutations” instead!

Ooh. Like. It is revised:

Our Kevin, who art at RunRev,
Hollowed be thy frame
By coding done
Yet still undone in engine,
As it is in IDE.
Give us this day our weekly upgrade
And forgive us our complaints
As we forgive the multitude of releases.
And lead us not to false expectations,
But deliver us from errors,
For thine is the vision,
The power, and the glory
For all permutations.

[FlexibleLearning.com]

If this were a realistic option, Edinburgh would have permanent testing
staff. The language, syntax and interaction permutations are simply too vast
for any automated testing whether by machine or human. As Richard G says,
ensure your own software is robust with each new version and log any issues.
The cumulative effect covers as much as is feasible.

If you find a problem, log it don't hog it.

Hugh Senior
FLCo


--
I agree. I have always felt that RunRev should occasionally hire one or two
people for beta-testing. They could test new releases before they are
labelled pre-release. This would cost only a little money and safe hundreds,
if not thousands of people lots of frustrations.

--
Best regards,

Mark Schonewille

[Mark Schonewille]

Really, why wouldn't it be realistic to pay a bunch of students for a
few hours of beta-testing (or should I say alpha-testing) some time in a
development cycle? I'm sure they could detect the bugs that every other
developer would detect right-away, but without frustrating those
developers because the people paid by RunRev have sorted them out already!

--
Best regards,

Mark Schonewille

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

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book "Programming LiveCode for the Real Beginner"
http://qery.us/3fi

LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

Post by FlexibleLearning.com
If this were a realistic option, Edinburgh would have permanent testing
staff. The language, syntax and interaction permutations are simply too vast
for any automated testing whether by machine or human. As Richard G says,
ensure your own software is robust with each new version and log any issues.
The cumulative effect covers as much as is feasible.
If you find a problem, log it don't hog it.
Hugh Senior
FLCo
--
I agree. I have always felt that RunRev should occasionally hire one or two
people for beta-testing. They could test new releases before they are
labelled pre-release. This would cost only a little money and safe hundreds,
if not thousands of people lots of frustrations.
--
Best regards,
Mark Schonewille
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Éric Miclo]

Hello,

I do agree that more testing (non automatic testing) should be made before releasing a commercial product.
But I’m not sure RunRev will listen.

When the CEO says:
"I really would urge everyone in our community to move to 7 as soon as possible. We spent 18 months building it and considering the amount of change its getting very good results stability wise. There are issues but they are mostly minor."

When minor bugs are so many, I don’t consider it is minor to test and fix before releasing a commercial product.
And by fixing I mean test if the fix really fixes the bug so it doesn’t have to be reopened immediately.
It is not the amount of time spent on a product that is an indicator of quality.

My 2 cents.

Best,

ÉrIC

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

Really, why wouldn't it be realistic to pay a bunch of students for a few hours of beta-testing (or should I say alpha-testing) some time in a development cycle? I'm sure they could detect the bugs that every other developer would detect right-away, but without frustrating those developers because the people paid by RunRev have sorted them out already!
--
Best regards,
Mark Schonewille
Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553
http://qery.us/468
Buy my new book "Programming LiveCode for the Real Beginner" http://qery.us/3fi
https://www.facebook.com/groups/runrev/

Post by FlexibleLearning.com
If this were a realistic option, Edinburgh would have permanent testing
staff. The language, syntax and interaction permutations are simply too vast
for any automated testing whether by machine or human. As Richard G says,
ensure your own software is robust with each new version and log any issues.
The cumulative effect covers as much as is feasible.
If you find a problem, log it don't hog it.
Hugh Senior
FLCo
--
I agree. I have always felt that RunRev should occasionally hire one or two
people for beta-testing. They could test new releases before they are
labelled pre-release. This would cost only a little money and safe hundreds,
if not thousands of people lots of frustrations.
--
Best regards,
Mark Schonewille
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Mark Schonewille]

I'll give you 2 cents for that, Éric. I also don't think that RunRev
will listen. Yet, I think a company should not rely on its user base for
testing. A company can't blame its user base for not testing, if
something appears not to work, but a user base can blame the company for
delivering broken software. Therefore, it would be wise to listen.

--
Best regards,

Mark Schonewille

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

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book "Programming LiveCode for the Real Beginner"
http://qery.us/3fi

LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

Post by Éric Miclo
Hello,
I do agree that more testing (non automatic testing) should be made before releasing a commercial product.
But I’m not sure RunRev will listen.
"I really would urge everyone in our community to move to 7 as soon as possible. We spent 18 months building it and considering the amount of change its getting very good results stability wise. There are issues but they are mostly minor."
When minor bugs are so many, I don’t consider it is minor to test and fix before releasing a commercial product.
And by fixing I mean test if the fix really fixes the bug so it doesn’t have to be reopened immediately.
It is not the amount of time spent on a product that is an indicator of quality.
My 2 cents.
Best,
ÉrIC

[Richard Gaskin]

Post by Éric Miclo
I do agree that more testing (non automatic testing) should be made
before releasing a commercial product.
But I’m not sure RunRev will listen.
"I really would urge everyone in our community to move to 7 as
soon as possible. We spent 18 months building it and considering
the amount of change its getting very good results stability wise.
There are issues but they are mostly minor."
When minor bugs are so many, I don’t consider it is minor to test
and fix before releasing a commercial product.
And by fixing I mean test if the fix really fixes the bug so it
doesn’t have to be reopened immediately.
It is not the amount of time spent on a product that is an indicator of quality.
My 2 cents.
Best,
ÉrIC
-- My NeXT computer will Be a Mac too! --

Re/Code recently posted the full video of their interview with Apple VP
Greg Joswiak, discussing iOS 8.0.1 bugs among other things:
<http://www.macrumors.com/2014/11/12/greg-joswiak-full-interview/>

iOS 8.0.1 was sent out in response to critical bugs in v8.0, and it
turned out that the fix itself required fixing, as 8.0.1 wound up
bricking some user's phones.

In the video the interviewer raises the larger question of overall QA,
and we're all familiar with recent issues there from iMaps forward.

Watching the video, I don't feel Joswiak's obvious pride in Apple is at
all misplaced. Sure, there have been many issues, sometimes critical
ones, in both iOS and OS X in recent years, and this may seem surprising
given the wealth of resources Apple has at their disposal which would
seem more than sufficient to prevent such things.

Software is complex stuff.

I don't think it was a mistake for Tim Cook to suggest we upgrade our
Apple devices to the latest software version which later bricked some
phones, and I don't think it was a mistake for Kevin to suggest that we
use the latest version of his company's software.

Obviously, with the benefit of hindsight, both CEOs were mistaken about
the fitness of the final deliverable, and both companies have devoted
considerable resources to addressing the issues once they became evident.

I'd wager that Apple has now added additional QA review steps to prevent
the specific issues that affected iOS 8.0.1, and I'd wager RunRev has
done the same with the issues evident in 7.0.

Late-stage regressions are especially troubling for all of us.
developers and users alike, because in the late stages it's especially
hard to detect such things as might have happened during earlier Beta
periods. When unpredictable events occurs late-stage it becomes more
likely that a software will be delivered that makes standalones unable
to quit, or bricks people's phones.

I wouldn't assume that either Apple or RunRev spends nothing on internal
testing. On the contrary, as a percentage of payroll I'd be surprised
if RunRev's costs for that weren't a multiple of Apple's.

I volunteered for this role of Community Manager because LiveCode is
very important to my own business interests and those of my clients.
Part of this role is to advocate for community concerns, and I agree
that QA is critical.

We *all* want to see QA improved, ever more so going forward. The folks
at RunRev have more at stake in this than most of us.

Those of us who read the bug DB regularly have a good appreciation for
the level of engagement the core team has in the QA process.

That v7.0 shipped with show-stoppers is annoying to all of us, and
exploring ways to improve the QA process is the focus of my meeting with
Ben later today.

Sean's suggestion of including a reporting item in the Help menu is a
very good one, and I'll be sure to raise it at the meeting.

Any other specific actionable items like that are very welcome, and can
help us all refine the process of making complex software ever more robust.

[Richmond]

<snip>
Software is complex stuff.
I don't think it was a mistake for Tim Cook to suggest we upgrade our
Apple devices to the latest software version which later bricked some
phones, and I don't think it was a mistake for Kevin to suggest that
we use the latest version of his company's software.
<snip>

Certainly, slagging off RunRev does nobody any good at all.

What might do some good is point out to RunRev that when they released
their Open Source version of LiveCode they undertook
to be more "touchy-feely" and more responsive to their users . . . and,
just possibly, they may be falling short of this.

Also, as I mentioned earlier, some of us are raving egomaniacs who
aren't going to do anything unless we get our egos tickled
as a result; hence my suggestion about T-shirts and so on.

One of the more important reasons Communism failed was its refusal to
acknowledge that complete, uninterested altruism
only exists in fairy stories, and the profit motive is very deeply
entrenched in human nature . . .

I believe there needs to be:

1. a set list of incentives on offer for bug detection.

2. a strictly defined procedure [a detailed bug-report form online ????]
for bug reporting.

3. a regular interval between dp/rc releases so that beta-testers are
aware of how much
time they have at their disposal to do any testing.

As I mentioned earlier, WINE have a rather good way of doing things,

and Canonical do with Ubuntu:

https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule

maybe RunRev could do something like that.

Richmond.

[J. Landman Gay]

Post by Richmond
1. a set list of incentives on offer for bug detection.

I wonder if it would be possible to extend a user's license for a short
period after a certain number of verified bug reports has been submitted.

For community edition users, perhaps a larger number of verified bugs
would allow a week or so of commercial access.

I suspect this would be difficult or too time-consuming to implement on
RR's end though. But I think it would be a better incentive than a tee
shirt and wouldn't cost the company much outside of the time to maintain it.

[Richard Gaskin]

Post by Richmond
What might do some good is point out to RunRev that when they
released their Open Source version of LiveCode they undertook
to be more "touchy-feely" and more responsive to their users
. . . and, just possibly, they may be falling short of this.

Perhaps. What should "touchy-feely" ideally translate to in terms of
specific actions?

Post by Richmond
Also, as I mentioned earlier, some of us are raving egomaniacs who
aren't going to do anything unless we get our egos tickled
as a result; hence my suggestion about T-shirts and so on.

That's a good idea. Ego is very important, a key motivator in so many
aspects of life. Mention in the About box is a start, but if a t-shirt
helps that seems easy enough to do.

I'd also like to see a Community Contributors page listing those who've
contributed to the project, and Steven at RunRev is keen to add that
with some other changes they're making to clean up the site's taxonomy.

Post by Richmond
As I mentioned earlier, WINE have a rather good way of doing things,
https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule
maybe RunRev could do something like that.

You know I loves me some Ubuntu, but I have to acknowledge that their
six-month fixed cadence is a highly controversial thing, not least of
all within their office.

Last I heard they've decided to stick with the six-month cycle, but
they've discussed many other models and apparently got close to choosing
one of the alternatives a little while ago.

A fixed schedule is helpful in some respects, but is also limiting on
others. Among other things it requires that work be broken up into
six-month blocks (or actually about 4 months, since the first month
after release requires planning the work for the next one, and the last
month is feature-freeze), and not everything fits into blocks of a fixed
size.

They do manage to pursue bigger objectives, like Ubuntu Mobile, Mir, and
other projects, but if those finish later than mid-way through a cycle
they may have to postpone rollout until the next one, losing time that a
different model wouldn't require them to.

Speaking of:

This week is the Ubuntu Online Summit, where v15.04 is being planned.
If you want to participate, or even list listen in to learn the process
by which Ubuntu is made, the schedule is here:
<http://summit.ubuntu.com/uos-1411/>

Yesterday I attended the File Manager session and Mark Shuttleworth's
keynote. Learned a lot from both.

[Alex Tweedly]

Note to self :
I am *not* getting involved in this thread.
I am *not* getting involved in this thread.
I am *not* getting involved in this thread.
I am *not* getting involved in this thread.
I do *not* have time to read, never mind get involved in, this
thread. :-)


OK. Having said that to myself - one small suggestion.

It would seem "touchy-feely" for there to be more response on this list
from RR.

You (Richard) are doing a great job as Community Manager, and responding
here.
How about you get an email address like ***@runrev.com so that it
does feel more like a RR response :-)

I suspect this list is mostly us old dinosaurs, and most of the newer
users are on the forums, and *we* should all know who you are - but it
would maybe help remind us that you have a role within RR and are
effectively part of the RR team taking in our input.

Regards,
-- Alex.

Post by Richard Gaskin

Post by Richmond
What might do some good is point out to RunRev that when they
released their Open Source version of LiveCode they undertook
to be more "touchy-feely" and more responsive to their users
. . . and, just possibly, they may be falling short of this.

Perhaps. What should "touchy-feely" ideally translate to in terms of
specific actions?

[Richard Gaskin]

Post by Alex Tweedly
It would seem "touchy-feely" for there to be more response on this list
from RR.

I tend to feel the same, but as with so many things it's a balancing act
- after all, one of the reasons we want them here is to tell them to go
away so they can spend their time fixing bugs. :)

We have seen a strong increase in other communications like the
newsletters and the blog, and from time to time we see Fraser, Neil,
Ben, and once in a while even Kevin here, more so than in years past.

Certainly wouldn't hurt to see more of them (though Neil posted here
just this morning), but with all they've been doing it's not always easy
to get the time for more posts here and in the forums than they make
already.

Post by Alex Tweedly
You (Richard) are doing a great job as Community Manager, and responding
here.
How about you get an email address like richard at runrev.com so that it
does feel more like a RR response :-)

Two reasons:

1. I'm not an employee of RunRev, and volunteered primarily to support
community contributions to the open source project. I feel it's
important in a role of community advocacy to be able to speak candidly,
and an address at the corporate domain might seem a mixed message.

2. I'm lazy. I do have an address at livecode.org (the community side
of things), but simply hadn't taken the time to set up a separate
subscription to this list under that address. I get mail there, though,
and note it in posts where I'm wearing the CM hat.

That said, I took your advice and just set up a subscription from the
.org address. If you can read this, it worked.

As a practical matter (read, "I still run a business in between these
volunteer activities") I may not always remember to change my default
address when replying, but I'll continue to try to use my CM sigline
where appropriate.

Post by Alex Tweedly
I suspect this list is mostly us old dinosaurs, and most of the newer
users are on the forums, and *we* should all know who you are - but it
would maybe help remind us that you have a role within RR and are
effectively part of the RR team taking in our input.

Unless you spend a lot of time hanging out with FOSS geeks, it's not
always clear what a Community Manager even is.

I didn't really know either until I met Jono Bacon back when he was the
Ubuntu Community Manager, and I didn't really understand the scope of
the role until I read his book, "The Art of Community".

Ubuntu has been a very liberating platform for many of my business
activities, both client and server, and the more I learn about how it's
made the more it's become clear that it would be very difficult to pull
that off if it were solely a corporate effort or solely a community
effort.

Many such projects really benefit a lot from the partnership between the
corporate stewards and a supportive community, accomplishing more
together than they could alone.

When Kevin announced that LC was going FOSS, he can tell you how
annoying I became in my insistence that the project could use a CM to
really make the most of this new community focus.

After enough times of him reminding me that he needs to keep his staff
on engineering and QA, I finally just volunteered for the role as my own
contribution to the project. I justify the expense in the same way I
donate resources to the Ubuntu project: I run a business dependent on
technology, and it benefits the work I do to see the tech I need thrive.

In an environment in which most of the current audience spends most of
our time making and using proprietary software, there's a lot for all of
us to learn about how this collaboration between the business and the
community can work to the greatest benefit of our own goals.

When I first took on this role we put an outline of some of that into
the newsletter:
<http://newsletters.livecode.com/april/issue169/newsletter1.html>

But that's not enough. There's so much to learn and discover. LiveCode
is a very big deal, not only in the scope of its code base but in its
potential impact on the world.

Together I believe we can see a world in which anyone with a computing
device can get more out of it by truly mastering it through LiveCode.

As we go forward, with good suggestions like Sean's this morning and the
others that come along, step by step we'll get there.

[Bob Sneidar]

The way I see things, RunRev is not an overly large company. To remain solvent (something that benefits us all) they probably have to prioritize what they can and cannot do. In House testing of every possible scenario cannot be one of the do’s. Frankly I am thrilled at the progress made since version 2.0. I can live with a few bugs. After all, no one *has* to adopt a new version of LC! If your older version works, use it for production. If the newer version causes you problems, don’t. And file a bug report while you are at it.

Now if RunRev were as large as Microsoft, then I could see holding them accountable for every serious bug in their product.

I’m not seeing the major issue here. I think a few more pats on the back of these guys might do more to help them excel then criticisms. After all, they are likely just as much raving egomaniacs (as Richmond put it) as most of us are. :-)

Bob S

Post by Alex Tweedly
I am *not* getting involved in this thread.
I am *not* getting involved in this thread.
I am *not* getting involved in this thread.
I am *not* getting involved in this thread.
I do *not* have time to read, never mind get involved in, this thread. :-)
OK. Having said that to myself - one small suggestion.
It would seem "touchy-feely" for there to be more response on this list from RR.
You (Richard) are doing a great job as Community Manager, and responding here.
I suspect this list is mostly us old dinosaurs, and most of the newer users are on the forums, and *we* should all know who you are - but it would maybe help remind us that you have a role within RR and are effectively part of the RR team taking in our input.
Regards,
-- Alex.

Post by Richmond
What might do some good is point out to RunRev that when they
released their Open Source version of LiveCode they undertook
to be more "touchy-feely" and more responsive to their users
. . . and, just possibly, they may be falling short of this.

Perhaps. What should "touchy-feely" ideally translate to in terms of specific actions?

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[J. Landman Gay]

Post by Mark Schonewille
Really, why wouldn't it be realistic to pay a bunch of students for a
few hours of beta-testing (or should I say alpha-testing) some time in a
development cycle?

There's no way a "few hours" would catch much in a system as complex and
large as LiveCode. It wouldn't make a dent.

[Björnke von Gierke]

Post by Mark Schonewille
Really, why wouldn't it be realistic to pay a bunch of students for a
few hours of beta-testing (or should I say alpha-testing) some time in a
development cycle?

There's no way a "few hours" would catch much in a system as complex and large as LiveCode. It wouldn't make a dent.

Whenever I sit down with LC, I find several problems/bugs/unwanted behaviours. Usually, after filing one or two bug reports, I stop using LC, because it's just too annoying to run into problems so often, and not being able to concentrate on my own tasks.