hair-pulling frustration

classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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.
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richmond Mathewson-2
On 11/11/14 21:25, Dr. Hawkins wrote:

> 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.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richard Gaskin
In reply to this post by Dr. Hawkins
Dr. Hawkins wrote:
> 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?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richmond Mathewson-2
On 11/11/14 21:55, Richard Gaskin wrote:
> Dr. Hawkins wrote:
>> 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.

>
> 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.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Rick Harrison
In reply to this post by Dr. Hawkins
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

> On Nov 11, 2014, at 2:25 PM, Dr. Hawkins <[hidden email]> wrote:
>
> 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.
> (702) 508-8462
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Dr. Hawkins
In reply to this post by Richard Gaskin
On Tue, Nov 11, 2014 at 11:55 AM, Richard Gaskin <[hidden email]
> wrote:

> Dr. Hawkins wrote:
>
>> 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.

--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Peter Haworth
In reply to this post by Dr. Hawkins
On Tue, Nov 11, 2014 at 11:25 AM, Dr. Hawkins <[hidden email]> wrote:

> 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>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Peter Haworth
In reply to this post by Richard Gaskin
On Tue, Nov 11, 2014 at 11:55 AM, Richard Gaskin <[hidden email]
> wrote:

> 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>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richard Gaskin
In reply to this post by Dr. Hawkins
Richmond wrote:

> On 11/11/14 21:55, Richard Gaskin wrote:
>> 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.


> 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.


> 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?

--
  Richard Gaskin
  LiveCode Community Manager
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richmond Mathewson-2
In reply to this post by Dr. Hawkins
On 11/11/14 22:59, Dr. Hawkins wrote:
> <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.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richmond Mathewson-2
In reply to this post by Richard Gaskin
On 11/11/14 23:16, Richard Gaskin wrote:

> Richmond wrote:
>
>> On 11/11/14 21:55, Richard Gaskin wrote:
>>> 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.
>
>
>> 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.
>
>
>> 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?
>

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.

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

J. Landman Gay
In reply to this post by Richard Gaskin
On 11/11/2014, 3:16 PM, Richard Gaskin wrote:
> 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.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richard Gaskin
In reply to this post by Dr. Hawkins
J. Landman Gay wrote:

> 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
  LiveCode Community Manager
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

J. Landman Gay
In reply to this post by Richmond Mathewson-2
On 11/11/2014, 3:23 PM, Richmond wrote:
> 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.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

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: [hidden email]
Skype: vaughn.clement

FaceTime: [hidden email]
Ph. 928-254-9062


On Tue, Nov 11, 2014 at 2:53 PM, J. Landman Gay <[hidden email]>
wrote:

> On 11/11/2014, 3:23 PM, Richmond wrote:
>
>> 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.
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richard Gaskin
In reply to this post by Dr. Hawkins
Richmond wrote:

> 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.


> 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.

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.


> 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.


> 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.


> 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
  LiveCode Community Manager
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Dr. Hawkins
In reply to this post by Peter Haworth
On Tue, Nov 11, 2014 at 1:09 PM, Peter Haworth <[hidden email]> wrote:

> 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.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Dr. Hawkins
In reply to this post by Richmond Mathewson-2
On Tue, Nov 11, 2014 at 1:23 PM, Richmond <[hidden email]>
wrote:


> 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].
>

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.



> 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
> 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.

--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Richard Gaskin
In reply to this post by Dr. Hawkins
Dr. Hawkins wrote:

> On Tue, Nov 11, 2014 at 1:34 PM, Richard Gaskin wrote:
>> 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.


> 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?


> 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.


> *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.


> 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.

--
  Richard Gaskin
  LiveCode Community Manager
  [hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: hair-pulling frustration

Dr. Hawkins
On Tue, Nov 11, 2014 at 4:38 PM, Richard Gaskin <[hidden email]>
wrote:

> 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.


--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12345