subject:"How do you handle the poor performance of LC 7\?"

This is not to say that the solution for people suffering with a 'bad
relationship between their computer and v7' is restarts like I describe -
that works for me and I'm sure that people suffering multiple
crashes/freezes have tried this and many other 'solutions'  

I have no idea why some people seem to get on ok with v7 and others don't -
and hope RunRev manage to figure out what is going on...

Kind regards

Dave



Dave Kilroy wrote
> Sounds roughly the same - I've learnt that as soon as v7 seems unhappy the
> best thing is to quit and restart - but it only goes wonky for me
> following an error brought on by my code and is ok the rest of the time
> 
> However, I've seen other people suffering with it in ways you mention...
> :(
> 
> 
> Dr. Hawkins wrote
>> "becomes" sluggish
>> 
>> Mine *starts* with a 2s or so delay to switch panes in the editor . . .
>> 
>> 
>>> (when this happens I quit and restart LiveCode and everything is
>>> fine) - but apart from that I can't remember the last time the IDE
>>> crashed/froze on me. It starts very quick on my systems (Yosemite &
>>> Win7) -
>>> but not quite as quick as older versions...
>>>
>> 
>> I get at least a couple of IDE crashes on any given day of writing.
>> Sometimes, I can see it becoming less stable (e.g., when clicking for red
>> dots reads 2-4 lines off) and quit.
>> 
>> 
>> -- 
>> Dr. Richard E. Hawkins, Esq.
>> (702) 508-8462
>> ___
>> use-livecode mailing list

>> use-livecode@.runrev

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





-
"The difference between genius and stupidity is; genius has its limits." - 
Albert Einstein
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692819.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: AW: AW: How do you handle the poor performance of LC 7?

Sounds roughly the same - I've learnt that as soon as v7 seems unhappy the
best thing is to quit and restart - but it only goes wonky for me following
an error brought on by my code and is ok the rest of the time

However, I've seen other people suffering with it in ways you mention... :(




Dr. Hawkins wrote
> "becomes" sluggish
> 
> Mine *starts* with a 2s or so delay to switch panes in the editor . . .
> 
> 
>> (when this happens I quit and restart LiveCode and everything is
>> fine) - but apart from that I can't remember the last time the IDE
>> crashed/froze on me. It starts very quick on my systems (Yosemite & Win7)
>> -
>> but not quite as quick as older versions...
>>
> 
> I get at least a couple of IDE crashes on any given day of writing.
> Sometimes, I can see it becoming less stable (e.g., when clicking for red
> dots reads 2-4 lines off) and quit.
> 
> 
> -- 
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> use-livecode mailing list

> use-livecode@.runrev

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





-
"The difference between genius and stupidity is; genius has its limits." - 
Albert Einstein
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692818.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: How do you handle the poor performance of LC 7?

2015-06-01 Thread Richard Gaskin

John Dixon wrote:

>> > On 1 Jun 2015, at 14:16, Peter TB Brett wrote:
>> >
>> > Unless some major showstopper problems are encountered, there will
>> > be commercial builds of the next release of LiveCode 8.  That'll
>> > be in the next couple of weeks.
>
> Will this be after the bugs in LC 7 have been sorted ?

I think Peter merely means a pre-release edition which includes support 
for encrypted stacks.

The v8 process will hopefully be a long and patient one, and will depend 
on v7's robustness, so I'm confident any showstoppers in v7 will be 
addressed long before v8 is called "Stable".

--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.com

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

RE: How do you handle the poor performance of LC 7?

2015-06-01 Thread John Dixon



> From: t.heaf...@icloud.com
> Subject: Re: How do you handle the poor performance of LC 7?
> Date: Mon, 1 Jun 2015 18:17:46 +0100
> To: use-livecode@lists.runrev.com
> 
> 
> > On 1 Jun 2015, at 14:16, Peter TB Brett  wrote:
> > 
> > Unless some major showstopper problems are encountered, there will be 
> > commercial builds of the next release of LiveCode 8.  That'll be in the 
> > next couple of weeks.

Will this be after the bugs in LC 7 have been sorted ?
  
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How do you handle the poor performance of LC 7?

2015-06-01 Thread Terence Heaford


> On 1 Jun 2015, at 14:16, Peter TB Brett  wrote:
> 
> Unless some major showstopper problems are encountered, there will be 
> commercial builds of the next release of LiveCode 8.  That'll be in the next 
> couple of weeks.


Will there be a built-in LCB editor or will it rely on TextWrangler/BBEdit?


All the best

Terry

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

Re: AW: AW: How do you handle the poor performance of LC 7?

2015-06-01 Thread Dr. Hawkins

On Mon, Jun 1, 2015 at 2:06 AM, Dave Kilroy 
wrote:

>
> I say 'in general' because v7 seems to be more fragile than earlier
> versions
> because sometimes when I hit an error in my code the IDE becomes sluggish
> afterwards


"becomes" sluggish

Mine *starts* with a 2s or so delay to switch panes in the editor . . .


> (when this happens I quit and restart LiveCode and everything is
> fine) - but apart from that I can't remember the last time the IDE
> crashed/froze on me. It starts very quick on my systems (Yosemite & Win7) -
> but not quite as quick as older versions...
>

I get at least a couple of IDE crashes on any given day of writing.
Sometimes, I can see it becoming less stable (e.g., when clicking for red
dots reads 2-4 lines off) and quit.


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

Re: How do you handle the poor performance of LC 7?

2015-06-01 Thread Peter TB Brett


On 2015-06-01 13:54, Dave Kilroy wrote:

Thanks for the confirmation Peter

To get through the iOS App Store I need a commercial version of 
LiveCode, so

can you give us a rough date of when a commercial version of v8 will be
released? I'm not after a definite date but something I can use to help 
me

decide...


Unless some major showstopper problems are encountered, there will be 
commercial builds of the next release of LiveCode 8.  That'll be in the 
next couple of weeks.


If an approximate release date is either unknown or too far in the 
future to
be contemplated then can you assure us that we could develop in v8 and 
- as

long as no widgets etc were used - build standalones with v7?


The LiveCode 8 IDE and engine will automatically save stacks in the v8 
format if any widgets are used, and in the v7 format otherwise.


Peter

--
Dr Peter Brett 
LiveCode Engine Development Team


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

Re: How do you handle the poor performance of LC 7?

Thanks for the confirmation Peter

To get through the iOS App Store I need a commercial version of LiveCode, so
can you give us a rough date of when a commercial version of v8 will be
released? I'm not after a definite date but something I can use to help me
decide...

If an approximate release date is either unknown or too far in the future to
be contemplated then can you assure us that we could develop in v8 and - as
long as no widgets etc were used - build standalones with v7?

Kind regards

Dave



Peter TB Brett wrote
> You're correct -- LiveCode 8 is indeed LiveCode 7 with widgets and a 
> revamped IDE.
> 
> I do hope that you can make the switch to using LiveCode 8.  LCB and 
> widgets are especially fun to play with, and in particular widgets make 
> it much easier to teach and demonstrate how good LiveCode is for rapid 
> app development.  It feels much more fun and productive to design apps 
> when you don't have to spend half an hour fiddling individual graphics 
> objects into place to create your user interface!
> 
>Peter





-
"The difference between genius and stupidity is; genius has its limits." - 
Albert Einstein
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692802.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: How do you handle the poor performance of LC 7?

2015-06-01 Thread Graham Samuel

Just to echo these remarks: I too have been using LC7 for ages and am confident 
that the product I’m working on (desktop, cross-platform Windows and Mac) will 
work fine as it’s been tweaked many times (lots of IDE use) and can now be seen 
to be 99% working in the real world. I have had no particular problems for 
months, although naturally I have found (and reported) a few bugs.

I also echo the sentiment about LC8. It turns out (perhaps just in my mind) to 
be a bit of a struggle to come to terms with it, so I haven’t started yet. But 
I can see the advantages of the whole structural idea behind widgets, so I hope 
in a fairly short time I too will make the jump.

Just my two eurocents.

Graham

> On 1 Jun 2015, at 11:06, Dave Kilroy  wrote:
> 
> Similar to Alex I too have been using v7 for everything I do (except for a
> couple of projects) since about 7.0.3 - and in general have been doing so
> without problems.
> 
> I say 'in general' because v7 seems to be more fragile than earlier versions
> because sometimes when I hit an error in my code the IDE becomes sluggish
> afterwards (when this happens I quit and restart LiveCode and everything is
> fine) - but apart from that I can't remember the last time the IDE
> crashed/froze on me. It starts very quick on my systems (Yosemite & Win7) -
> but not quite as quick as older versions...
> 
> However I have seen other people using v7 experiencing slow-startup and
> fairly regular freezes/crashes (for example I was doing a LC workshop at the
> weekend and two people running windows experienced freezes/crashes every 30
> minutes or so - but both did successfully create an app and got everything
> to work). But other times I've seen it work fine on people's systems...
> 
> In fact I'm also thinking of using LC8 full-time. LCB looks good and I 'get'
> that it will be used to leap-frog some of LC's current woes - but I simply
> haven't had time to play with it yet and think the only time I'll learn is
> if I'm using it day-in-day-out. I'm thinking v8 is basically v7 with LCB and
> widgets added and if this is so then I think I'll make the jump. Trevor,
> Richard do you have any views on this?
> 
> 
> 
> Richard Gaskin wrote
>> Alex Tweedly wrote:
>> 
>>> I too have used only v7 for everything I've done recently for myself (no
>>> released products - just stuff I do for myself and friends/family). I've
>>> been still using v6 when I don't control it all myself.
>>> 
>>> I'm happy to say I've had no crashes, no serious IDE problems and few
>>> performance issues (which were all already reported or known).
>> 
>> Good to hear.  At least Trevor and I aren't alone.
> 
> 
> 
> 
> 
> -
> "The difference between genius and stupidity is; genius has its limits." - 
> Albert Einstein
> --
> View this message in context: 
> http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692799.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: How do you handle the poor performance of LC 7?

2015-06-01 Thread Peter TB Brett


On 2015-06-01 11:06, Dave Kilroy wrote:
In fact I'm also thinking of using LC8 full-time. LCB looks good and I 
'get'
that it will be used to leap-frog some of LC's current woes - but I 
simply
haven't had time to play with it yet and think the only time I'll learn 
is
if I'm using it day-in-day-out. I'm thinking v8 is basically v7 with 
LCB and
widgets added and if this is so then I think I'll make the jump. 
Trevor,

Richard do you have any views on this?


Hi Dave,

You're correct -- LiveCode 8 is indeed LiveCode 7 with widgets and a 
revamped IDE.


I do hope that you can make the switch to using LiveCode 8.  LCB and 
widgets are especially fun to play with, and in particular widgets make 
it much easier to teach and demonstrate how good LiveCode is for rapid 
app development.  It feels much more fun and productive to design apps 
when you don't have to spend half an hour fiddling individual graphics 
objects into place to create your user interface!


  Peter

--
Dr Peter Brett 
LiveCode Engine Development Team


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

Re: AW: AW: How do you handle the poor performance of LC 7?

Similar to Alex I too have been using v7 for everything I do (except for a
couple of projects) since about 7.0.3 - and in general have been doing so
without problems.

I say 'in general' because v7 seems to be more fragile than earlier versions
because sometimes when I hit an error in my code the IDE becomes sluggish
afterwards (when this happens I quit and restart LiveCode and everything is
fine) - but apart from that I can't remember the last time the IDE
crashed/froze on me. It starts very quick on my systems (Yosemite & Win7) -
but not quite as quick as older versions...

However I have seen other people using v7 experiencing slow-startup and
fairly regular freezes/crashes (for example I was doing a LC workshop at the
weekend and two people running windows experienced freezes/crashes every 30
minutes or so - but both did successfully create an app and got everything
to work). But other times I've seen it work fine on people's systems...

In fact I'm also thinking of using LC8 full-time. LCB looks good and I 'get'
that it will be used to leap-frog some of LC's current woes - but I simply
haven't had time to play with it yet and think the only time I'll learn is
if I'm using it day-in-day-out. I'm thinking v8 is basically v7 with LCB and
widgets added and if this is so then I think I'll make the jump. Trevor,
Richard do you have any views on this?

Richard Gaskin wrote
> Alex Tweedly wrote:
> 
>> I too have used only v7 for everything I've done recently for myself (no
>> released products - just stuff I do for myself and friends/family). I've
>> been still using v6 when I don't control it all myself.
>>
>> I'm happy to say I've had no crashes, no serious IDE problems and few
>> performance issues (which were all already reported or known).
> 
> Good to hear.  At least Trevor and I aren't alone.

-
"The difference between genius and stupidity is; genius has its limits." - 
Albert Einstein
--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692799.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: How do you handle the poor performance of LC 7?

2015-05-31 Thread Mark Talluto

On May 31, 2015, at 2:33 PM, tbodine  wrote:

> I have turn off all 3rd-party plug-in tools in case those are a factor and
> will see if there are any improvements.

Tom, have you tried Navigator by Geoff Canyon? I have it open every day, all 
the time. No issues.
It is a very solid replacement for the project browser. It is all text. Small 
footprint on screen too. Fast!

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

Re: AW: How do you handle the poor performance of LC 7?

Thanks Richard and Mike.

I will run without Project Browser and see how that goes.

Mike, good theory on drives, but not a factor here: this machine runs off
one SSD. No USB drives involved. I don't have data on the time factor, but
I'll start logging my sessions to look for a pattern.

>>When a hard crash occurs, do you kill whatever processes might be hung,
then immediately restart lc? Or do you restart the whole machine? I'd
recommend a total machine restart at least once then see if stability will
increase for a while.

I have done both... relaunch LC immediately and, other times, restart the
machine.

Thanks for the insights.

Tom



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692796.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: AW: How do you handle the poor performance of LC 7?

2015-05-31 Thread Mike Bonner

@tBodine
If it were me, I'd also try to evaluate time as a factor.  Does the crash
chance increase based on how long lc or the system itself has been
running?  Is there a chance that there is an external drive involved in the
problem, like a usb drive that spins down into power save mode (or
depending on your power settings, an internal drive can spin down too but
far less likely if you're actively working)
Having to wait for a drive to spin up shouldn't have a crash affect, but
shouldn't and can't are two different things.
I also ask about time as a factor because if you haven't hit a menu for a
while, the resources might need to be popped back  into memory (again
possibly linked to a sleeping drive?)

When a hard crash occurs, do you kill whatever processes might be hung,
then immediately restart lc? Or do you restart the whole machine? I'd
recommend a total machine restart at least once then see if stability will
increase for a while.

One of the first things I do when having strange behaviors is remove usb
drives from the loop, or before I do something that might cause the drive
to be ramped up, I go to explorer and hit the drive so i'm sure its
accessible, then go back and do whatever thing it was that has been causing
crashes. (I've had some issues with plex crashing if my external drive
doesn't respond with alacrity)

On Sun, May 31, 2015 at 4:06 PM, Richard Gaskin 
wrote:

> Tom Bodine wrote:
>
> > I virtually always have the project browser open!
>
> Try running with it off for a while, perhaps using the App Browser instead.
>
> I know that's asking a lot, 'cause the Project Browser is pretty handy.
>
> But it'll certainly narrow things down if your crashes go away with it not
> open.
>
> --
>  Richard Gaskin
>  LiveCode Community Manager
>  rich...@livecode.org
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: AW: How do you handle the poor performance of LC 7?


Tom Bodine wrote:

> I virtually always have the project browser open!

Try running with it off for a while, perhaps using the App Browser instead.

I know that's asking a lot, 'cause the Project Browser is pretty handy.

But it'll certainly narrow things down if your crashes go away with it 
not open.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.org

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

Re: AW: How do you handle the poor performance of LC 7?

Hi Richard. 

Thanks for your interest in this case.

>>Do you recall if these crashes occur more frequently if the Project
Browser is open? 

I virtually always have the project browser open!

I have turn off all 3rd-party plug-in tools in case those are a factor and
will see if there are any improvements.

Thanks,
Tom



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692793.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: AW: How do you handle the poor performance of LC 7?

Thanks for submitting that report, Tom. I just added some notes there 
that may be helpful.


Do you recall if these crashes occur more frequently if the Project 
Browser is open?


I ask because one of the differences between that IDE component and 
others is that it's not merely much newer, but also makes extensive use 
of relatively new engine features (the "at " option for the 
"export snapshot" command).


Just a hunch, but offhand it's the best hunch I have on this trying to 
think of newer things that might give rise to this issue.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.org


Tom Bodine wrote:

> Thanks, Richard. Here are the basics:
> * Platform Win 7, 64-bit machine
> * Running LC 7.0.5 (rc2)
> * Bug report of these crashes:
> http://quality.runrev.com/show_bug.cgi?id=15418
> * The application is a quiz application that lets the user to create
> quiz content and customize its presentation. It's been in development
> starting with LC 5.5 about two years ago. I moved it to v7 to make
> use of the Unicode support, which has worked great. (The app has no
> database or network functions.)
>
> All crashes (so far) have been in the IDE, not in standalones.
> Crashes are usually triggered just by using the IDE's menubar. For
> instance, sometimes when several controls are selected and I want
> to align them, clicking the menubar to access the alignment cmd
> will trigger a crash. (But not always.)
> Other times, clicking menubar to access Save cmd will do it. Another
> crash came from trying to select some output text from the message
> box.
>
>>> Have you found some activities that never crash, and others where
>>> the crashes occur?
>
> That's the maddening thing. Actions that works fine much of the time
> will suddenly yield a crash. For instance, saving a stack in the the
> IDE from the menubar. (Now I do all my saves from the keyboard
> shortcut.) So what all the crashes have in common is an action
> involving use of the mouse.
>
> Thanks for any insights on this.
>
> Tom Bodine



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

Re: AW: How do you handle the poor performance of LC 7?

Thanks, Richard. Here are the basics:
* Platform Win 7, 64-bit machine
* Running LC 7.0.5 (rc2)
* Bug report of these crashes:
http://quality.runrev.com/show_bug.cgi?id=15418
* The application is a quiz application that lets the user to create quiz
content and customize its presentation. It's been in development starting
with LC 5.5 about two years ago. I moved it to v7 to make use of the Unicode
support, which has worked great. (The app has no database or network
functions.)

All crashes (so far) have been in the IDE, not in standalones. Crashes are
usually triggered just by using the IDE's menubar. For instance, sometimes
when several controls are selected and I want to align them, clicking the
menubar to access the alignment cmd will trigger a crash. (But not always.)
Other times, clicking menubar to access Save cmd will do it. Another crash
came from trying to select some output text from the message box.

>> Have you found some activities that never crash, and others where the
>> crashes occur?

That's the maddening thing. Actions that works fine much of the time will
suddenly yield a crash. For instance, saving a stack in the the IDE from the
menubar. (Now I do all my saves from the keyboard shortcut.) So what all the
crashes have in common is an action involving use of the mouse.

Thanks for any insights on this.

Tom Bodine

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

--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692790.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: AW: How do you handle the poor performance of LC 7?

Tom Bodine wrote:
> I am trying to move entirely to V7 engine, but as Brahmanathaswami
> notes, 7.0.5 is makes it very hard with frequent and unpredictable
> hard crashes. (I'm on Win 7. Yes, crash report filed, but not for
> every crash because at this rate that would become about half my
> work day.)
>
> Is the instability of 7.0.5  just on the Windows side or are Mac users
> seeing this, too?
>
> It's hard to be optimistic when something that crashes as much as
> 7.0.5 is labeled a "release candidate".

No optimism needed, just a cool head to think this through to come up 
with a diagnosis the team can work with.

It may be useful to remember that a crash you experience may not be 
experienced by others.  In fact, as I think back on the posts here I see 
a great many crashes discussed, but from a very small number of people.

This suggests there's something about the nature of those specific 
projects or the workflows used in making them which is exposing a 
weakness in the engine.

The weakness is there; I don't imagine anyone is inventing crash stories.

But empirically and anecdotally we know crashers are very rare among the 
thousands of projects LC is used on, and even in cases like yours 
unpredictably intermittent among sessions with the same project, as you 
described.

Given that each release has passed internal manual review and automated 
testing, and that most of us aren't reporting crashers (I haven't seen a 
crash in a long time, and I spend most of my time in the least-supported 
platform of all, Linux), it's helpful to try to identify the specific 
causes of the crash so that it becomes possible for the team to see them.

Once seen, issues like that are often easy to fix, and crashers get a 
high priority.

But first it must be seen.  And it's probably not something easily seen 
or the rest of us would be seeing it too.

Every problem can be solved by identifying the differences between the 
working and non-working states.  Once identified, in deterministic 
systems like software working through that list will always find the 
root cause.  In more than 25 years of making software I've never seen a 
bug yet that couldn't be isolated through this process (some more easily 
than others ).

Let's start with the basics:  what platform are you on, and what does 
your app do?

Have you found some activities that never crash, and others where the 
crashes occur?   If so, can you describe the nature of those activities 
where crashes have occurred - connecting to databases, handling sockets, 
rendering graphics, etc?

--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.com

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

Re: AW: How do you handle the poor performance of LC 7?


> Currently everything I do in LiveCode is done in v7.0.5.
Do you get frequent crashes?


> That said.. 7.0.5 is frustrating. Crashed 5 times on me to today...

I am trying to move entirely to V7 engine, but as Brahmanathaswami notes,
7.0.5 is makes it very hard with frequent and unpredictable hard crashes.
(I'm on Win 7. Yes, crash report filed, but not for every crash because at
this rate that would become about half my work day.)

Is the instability of 7.0.5  just on the Windows side or are Mac users
seeing this, too?

It's hard to be optimistic when something that crashes as much as 7.0.5 is
labeled a "release candidate". 

Thanks,
Tom Bodine




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/How-do-you-handle-the-poor-performance-of-LC-7-tp4692676p4692780.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: How do you handle the poor performance of LC 7?

Wilöhelm, as a fellow benchmarking fan I always look forward to your 
ongoing graphics manipulation metrics with enthusiasm.  Your tests are 
well detailed, and you keep enviably complete notes on them.


I have a couple small thoughts on the tests themselves, and one about 
the bigger picture of the suitability of this sort of work in LiveCode.


Small thing #1:

>- Scripts running in LC 4.6.1 are about 10 to 20% slower compared to
>  running under the MC (Metacard) 4.6.1 IDE

There will always be difference in IDE overhead because the two IDEs are 
written with very different goals in mind.  MC attempts to provide the 
bare minimum of GUI support, while LC strives for a more complete 
experience. As much as I enjoyed MC, its Spartan nature was one of the 
reasons I've amassed so many custom tools, often for things that are 
already included with more feature completeness in the LC IDE.


Since the underlying engine is the same, there should be very little if 
any difference at all in how it affects our final deliverable, the 
standalone.


So while comparisons with MC may be useful for considering trimming 
features from the LC IDE, in general they don't affect what we produce 
with either IDE.



Small thing #2:

The comparisons across different engine versions which make up the bulk 
of your post are indeed more helpful, but since these tests also include 
the unsupported MC IDE for the older engine versions they'd be even more 
helpful for identifying engine changes if they either used the same IDE 
or a standalone build from the same IDE.



The bigger picture:

Many of us do ambitious things in LiveCode, and it's a wonder it lets us 
do half of them at all.  A surprisingly complete language given its 
uncommon ease, we have deep control over binary structures just as we do 
with parsing text; given the breadth of interests in our community the 
engine gets tested across a wide range of task categories.


While it's nice to be able to work with a language this flexible, Kevin 
himself is more restrictive in how he positions LiveCode's "sweet spot" 
than many of us are.


For example, when v5.5 introduced the wonderful new field object, I was 
quick to suggest we could now make a word processor with it - and Kevin 
was equally quick to suggest we not:


LiveCode is for verticals, of which there are many to which
it is greatly suited. The new field features support those
and there is a much more flexibility in there now, not least
the textChanged message allowing a great deal of custom control.
However we would not recommend it for developing the next Word.


We're both right, in the sense that I do indeed make a word processor as 
the core of one of my biggest projects right now, but it's a very 
specialized, "vertical", word processor, one that won't in any way 
compete with Microsoft Word.  Mine is made only for the authoring of 
specific content within one company, and with LiveCode we're spending a 
fraction of what a much larger team in the same company spent making a 
similar system.


Along those lines, it's possible to write image filters in LiveCode but 
none of the professional image editing products attempt to do so in any 
scripting language.  While v7 is no doubt slower than earlier versions 
in ways that might benefit other tasks as well, image filtering was 
never LiveCode's sweet spot, nor with any general purpose scripting 
language I've seen.


Historically the externals API was a good fit for that task, allowing us 
to use LiveCode for the UI and handing off the heavy lifting of image 
filtering to the language most commonly used for that, C.


In the future, v8 opens up an even better option: rather than rewriting 
the world's image filters from scratch, it may be possible to use v8's 
ability to talk directly to lower-level APIs to write a library that 
would allow us to use the vast collection of existing third-party 
Photoshop filters.


It may even be that such a subsystem already exists for Skia-based 
graphics frameworks like LiveCode, or will someday soon, so all we'd 
need to do is wire up the existing work to be exposed to our scripts.


None of this is to discourage your excellent benchmarking in this area. 
 On the contrary, optimizing operations on binary data merits attention 
for a wide range of tasks; bitmap indices and Bloom filters come to mind 
as logical compliments to LiveCode's grace with text handling, esp. now 
that it uses the world standard of Unicode for richer language-savvy 
parsing.


This is only to invite a 30,000 foot view, looking at the full range of 
possible ways to solve problems as we craft our products.


There are hundreds of great languages, each bringing their own unique 
value to the mix.


Sometimes the best solution for a given task isn't LiveCode.

But at least with LiveCode we often have the opportunity to leverage 
work done in other language

Re: AW: AW: How do you handle the poor performance of LC 7?


Alex Tweedly wrote:


I too have used only v7 for everything I've done recently for myself (no
released products - just stuff I do for myself and friends/family). I've
been still using v6 when I don't control it all myself.

I'm happy to say I've had no crashes, no serious IDE problems and few
performance issues (which were all already reported or known).


Good to hear.  At least Trevor and I aren't alone.


I'm no RQCC expert - is there a simple recipe to find all (or most) v7
performance related bug reports ?


I don't think so, because there's no guarantee that submitters will use 
easily searchable language.


The search options are pretty broad, though, so I was at least able to 
come up with a search for all open issues where any v7 has been listed 
as the target:




(Mind those line wraps )

First in that list is one from you, which does thankfully include 
"performance" in its summary:



Nice demo stack - not only clearly illustrates the issue, but fun to watch.

I've added a confirmation there for Linux, and some additional notes 
that may be helpful.


Looking forward to hearing from the team on this one - it's a very 
interesting case, since both v7.0.5 and the noticeably faster v6.7.5 
both use the Skia graphics subsystem.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.org

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

Re: How do you handle the poor performance of LC 7?

Peter W A Wood wrote:

>> On 31 May 2015, at 07:07, Richard Gaskin wrote:
>>
>> If there are bugs that have been submitted but not acted on and
>> are holding up work without a workaround, let's identify those
>> and get them resolved.
...
> I reported a bug - 
> - in the default version of LiveCode Server used on On-Rev on 8th
> April 2015. The bug stopped me using LiveCode to develop a small web
> app used by a client. I had to use Ruby instead. When the client
> asked, “What did you write it in?”. I answered “Ruby” not “LiveCode”.

Looks like Lyn Teyla came through with a workaround in that report 
(thanks Lyn).  In fact, I tend to read from stdIn anyway since I rarely 
use LiveCode Server, preferring faceless standalones so I can do unit 
testing and reasonably complete server emulation right in the desktop IDE.

Also, your report was against v6.6.5, so while Lyn was able to confirm 
that this is also present in v7.0.5 in this thread about issues 
preventing people from moving to v7 this would not be one of them.

Still, it would of course be good to see it fixed, and I spent a couple 
minutes to search for related items in the DB, and posted links across 
them to help steward this to resolution.

In the meantime, although Ruby's an excellent language, if you want to 
use LiveCode for that I believe there's code in the community for 
parsing multi-part form data, and I could dig some up if you're in a 
position to rewrite that (though since it's working now I'd understand 
if it's not worth the time).

> Nobody at LiveCode has bothered to review the bug report yet.

Consider how differently that sentence reads with one small change:

  Nobody at LiveCode has reviewed the bug report yet.

I try to be mindful that this is an international community and 
sometimes expressions carry different weight in different cultures.

I see a number of people outside the US use phrases like "RunRev can't 
be bothered" quite liberally, but in the States that wouldn't be how 
professionals address one another in conversation.

In American culture "can't be bothered" is used almost exclusively as 
derisive, carrying a connotation that the subject had sufficient time 
available for whatever task is being discussed, but wilfully chose to do 
something less important, or perhaps even trivial.

I once worked for a manager with limited technical skills, but he held 
his position well because he possessed an uncommonly insightful 
awareness of the nuances of communication that shape human performance.

He advocated with his staff a practice he called "de-hooking", reviewing 
communications before they go out to see if there's an opportunity to 
remove any phrases which might raise the recipient's ire, to keep the 
focus on actionable outcomes.

Lord knows - as do many of you here - this is something I'm still 
learning to get right myself.  I enjoy language, and could benefit from 
using it less pointedly at times.

We all want things, and many of the things worth having are bigger than 
any single person can accomplish alone.  So we work in teams, together, 
in a spirit of mutual respect, and collectively we can have a chance to 
get what we want.

Thanks in no small part to some kind nudging from Jacque many years ago, 
I try to write as though I'm sitting across the dinner table from the 
reader.  After all, in this community, which includes the core dev team, 
chances are that'll happen in person at some point or another.

Though I can certainly improve my own "de-hooking", I find a mindfulness 
of tone helps me get what I need from the people I work with.  Extra 
bonus points that it makes the conversation that much more pleasant as well.

--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.org

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

Re: How do you handle the poor performance of LC 7?

2015-05-31 Thread sanke

The somewhat "sluggish" behavior of all LC versions 7.x is apparent 
without testing a single script over several versions. Just use the LC 
IDE and copy and paste any object and you see how reluctantly the IDE 
performs these basic steps. In my case this is on a Windows machine with 
Windows 7 and 32 bit.


More specially, I have tested this for imagedata processing, where I 
have set a personal focus these last years. I have several times filed 
bug reports accompanied by sample stacks. Recently I have repeated tests 
and added new ones comparing MC and LC versions from MC 4.6.1 to LC 8.0.


The general (average) results on the basis of identical (or 
"corresponding" - see below) scripts are like this:


- Scripts running in LC 4.6.1 are about 10 to 20% slower compared to 
running under the MC (Metacard) 4.6.1 IDE

- Scripts in LC 6.7.5 are about 1.7 times slower than in MC 4.6.1
- Scripts in versions LC 7.x run about 3 to 10 times slower, depending 
on the complexity of the script,  compared to MC 4.6.1, which means for 
example that more time-consuming filters (without using DLLs) for image 
sizes 640x480 like convolution-matrix filters which might need 30 
seconds in MC 4.6.1 will run for 2 to 3 minutes under LC 7.0.4.
With larger images you can easily reach ten and more minutes, which is 
inacceptable.


These comparisons take into account that in versions 7.x you have to 
substitute char, chartonum, numtochar by byte, numtobyte, bytetonum - 
this is why I spoke of "corresponding" scripts above.


You can use the byte-functions already in versions 4 to 6, but with some 
caveats:


- The first is that "put  bytetonum(numtobyte(-100))" (as an example) 
evaluates to "0" instead of  156 in "chartonum(numtochar(-100)). With 
filters possibly dealing with negative values like in my "duplicate 
colors"-algorithm you therefore get a totally black image after the 9th 
iteration instead of returning to the original image.
- The second is that in certain contexts - as with matrix operations - 
you need to use a "hybrid" combination like "chartonum(numtobyte(x)" to 
avoid an error message.


In versions 7.x pure "byte"-scripts are the norm, but "char"-scripts are 
tolerated up to (including) version 7.0.4.
The use of any "char"-scripts in LC versions 7.0.5 immediately leads to 
crashes,  resulting for example in opening the script editor without 
showing any part of the script and sometimes in removing all 
image-values stored in custom properties. After that I had to force-quit 
Livecode.
When I tried to create a sample stack that could be opened both in MC 
4.6.1 and LC 8.0  the menu items (entered in the properties inspector) 
of all case-statements in the menupick handlers became scrambled, but 
left the menupick scripts itself untouched. This effect was visible in 
each of the buttons on the card that used menupick handlers, meaning the 
distortion of the menu items appeared simultaneously.


In LC 7.04 quite a number of scripts using bytes or chars respectively 
run with similar speeds sometimes with a slight overhead (slower) for 
scripts using chars, but, as already mentioned, 4 to 10 times slower 
compared to MC 4.6.1


Here is an elementary example script for an internal "mirror from right" 
(the right side of the image is mirrored on the left side):


"on mouseUp
  set the cursor to watch
  put the milliseconds into Start
  put the imageData of image x into iData
  put the height of img x into theight
  put the width of img x into twidth
  set the endvalue of scrollbar 1 to theight
  put trunc(theight/30) into scrollstep
  put 4* twidth into re
  put twidth/2 into twhalf
  repeat with i = 0 to theight - 1
if i mod scrollstep = 0 then set the thumbpos of scrollbar 1 to i
put i*re into ti
put -1 into DiffJ
repeat with j = twhalf to twidth - 1
  add 2 to DiffJ
  put char (ti + (j*4+2)) of idata into char (ti + ((j-DiffJ)*4 
+2)) of idata
  put char (ti + (j*4+3)) of idata into char (ti + ((j-DiffJ)*4 
+3)) of idata
  put char (ti + (j*4+4)) of idata into char (ti + ((j-DiffJ)*4 
+4)) of idata

end repeat
  end repeat
  set the imageData of image x to iData
  put the milliseconds - Start into fld "Test"
  set the thumbpos of scrollbar 1 to theight
end mouseUp"

Speed tests for this script under MC 4.6.1 with different image sizes in 
milliseconds - using "byte" instead of "char" in the sample script above 
for the second row:


 320x240480x360512x384   640x480
chars  104  179 203  303
bytes  104 186  203  296

Corresponding values for LC 7.0.4:

 320x240480x360512x384   640x480
chars  14491692  1842 2087
bytes  14071641  1793 2003

I noticed however that *some* scripts running relatively fast under MC 
4.6.1 could take up to 2000 (two thousand) times longer -and even more 
depending on image size

Re: How do you handle the poor performance of LC 7?

2015-05-31 Thread Richmond


On 31/05/15 00:05, Mark Wieder wrote:

On 05/30/2015 12:40 PM, Mark Wieder wrote:


along the way or are new converts to LiceCode. And add to those


Oops. Obviously I meant LiveCode.



Presumably LiceCode is the version full of bugs!

Richmond.

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

Re: How do you handle the poor performance of LC 7?


On 05/30/2015 04:45 PM, Dr. Hawkins wrote:


LiceCode:  the hairiest programming experience you will ever have.  The
compiler is truly nit-picking . . .

:)


I should have known I was opening the door to lousy puns.

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: AW: AW: How do you handle the poor performance of LC 7?

2015-05-30 Thread Alex Tweedly



On 31/05/2015 00:07, Richard Gaskin wrote:


Currently everything I do in LiveCode is done in v7.0.5.

I too have used only v7 for everything I've done recently for myself (no 
released products - just stuff I do for myself and friends/family). I've 
been still using v6 when I don't control it all myself.


I'm happy to say I've had no crashes, no serious IDE problems and few 
performance issues (which were all already reported or known).


So I've now started to go through some of my older stacks that I think 
might be more performance-dependent to see if I can find and report 
anything. First one I tried did indeed show a graphics performance issue 
(on Mac - so maybe due to different graphic libs rather than the 
engine)- anyway that's 15447.


I agree that focusing on specific actionable issues experienced 
firsthand is very valuable.


If there are bugs that have been submitted but not acted on and are 
holding up work without a workaround, let's identify those and get 
them resolved.


In addition to review of the current bug DB, Ben recently contacted a 
few developers to solicit such a shortlist, and as Community Manager 
I'm happy to add to that list with anything critical we can identify 
here.


I'm no RQCC expert - is there a simple recipe to find all (or most) v7 
performance related bug reports ?


Thanks
-- Alex.

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

Re: How do you handle the poor performance of LC 7?

2015-05-30 Thread Peter W A Wood

Richard 

> On 31 May 2015, at 07:07, Richard Gaskin  wrote:
> 
> If there are bugs that have been submitted but not acted on and are holding 
> up work without a workaround, let's identify those and get them resolved.
> 
> In addition to review of the current bug DB, Ben recently contacted a few 
> developers to solicit such a shortlist, and as Community Manager I'm happy to 
> add to that list with anything critical we can identify here.

I reported a bug - http://quality.runrev.com/show_bug.cgi?id=15173 
 - in the default version of 
LiveCode Server used on On-Rev on 8th April 2015. The bug stopped me using 
LiveCode to develop a small web app used by a client. I had to use Ruby 
instead. When the client asked, “What did you write it in?”. I answered “Ruby” 
not “LiveCode”. 

Nobody at LiveCode has bothered to review the bug report yet.

Peter


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

Re: How do you handle the poor performance of LC 7?

On Sat, May 30, 2015 at 2:05 PM, Mark Wieder  wrote:

> On 05/30/2015 12:40 PM, Mark Wieder wrote:
>
>  along the way or are new converts to LiceCode. And add to those
>>
>
> Oops. Obviously I meant LiveCode.


LiceCode:  the hairiest programming experience you will ever have.  The
compiler is truly nit-picking . . .

:)




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

Re: AW: AW: How do you handle the poor performance of LC 7?

Malte Brill wrote:

>> And thankfully, warts and all, none of the issues with LiveCode are
>> preventing Trevor, myself, and many others from shipping products
>> made with it.
>
> Out of interest, how many of those have you moved to use the 7 engine?

Currently everything I do in LiveCode is done in v7.0.5.

> Still there are areas where 7 is just not ready for prime time.

It would be useful to know which ones are affecting your apps.

> The more importance I see in openly discussing the issues we
> encounter. I think it does not help to point out that the current
> state works for others.

I agree that open discussion in a community is helpful, but I don't see 
the value in limiting the discussion only to what doesn't work.

I see no harm in Trevor or others noting that they're doing productive 
work with v7.  Why not allow the full scope of experience to be shared?

In light of the many posts here from folks describing things they've 
heard from others but not actually seen for themselves, any discussion 
of first-hand experience would seem welcome, even if it's as shockingly 
unfashionable as people merely having a good time. :)

> It is more helpful to try to help identifying the areas where there
> are issues which I believe aren’t that many anymore

Yes, despite the ongoing distraction of constant iOS updates, they've 
been working hard to knock off many issues for other platforms as well.

> however for a certain amount of apps being built that handful of
> things are real showstoppers.

I agree that focusing on specific actionable issues experienced 
firsthand is very valuable.

If there are bugs that have been submitted but not acted on and are 
holding up work without a workaround, let's identify those and get them 
resolved.

In addition to review of the current bug DB, Ben recently contacted a 
few developers to solicit such a shortlist, and as Community Manager I'm 
happy to add to that list with anything critical we can identify here.

--
 Richard Gaskin
 LiveCode Community Manager
 rich...@fourthworld.com

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

Re: AW: AW: How do you handle the poor performance of LC 7?

2015-05-30 Thread Malte Brill

> And thankfully, warts and all, none of the issues with LiveCode are 
> preventing Trevor, myself, and many others from shipping products made 
> with it.
Out of interest, how many of those have you moved to use the 7 engine?

I have no interest in lamenting here. I do admire the job that has been done 
since the kickstarter and all the new shiny stuff like widgets looks rather 
good. Still there are areas where 7 is just not ready for prime time. I guess 
we will get there, especially seeing how responsive the folks at RR are at the 
moment. The more importance I see in openly discussing the issues we encounter. 
I think it does not help to point out that the current state works for others. 
It is more helpful to try to help identifying the areas where there are issues 
which I believe aren’t that many anymore (sort, filter and maybe rendering 
speed on high density displays), however for a certain amount of apps being 
built that handful of things are real showstoppers.

Best,

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

Re: How do you handle the poor performance of LC 7?

2015-05-30 Thread Brahmanathaswami


Mark Wieder wrote:


Yeah, but here's the difference: you're the boss, you can make the 
decisions, you don't have to convince upper management about how new 
development tools fit into the existing set; and you don't have to 
manage a group of half a dozen engineers all trying to make changes to 
parts of the same application in development, and figure out how to 
merge their changes into one stack.


Point well taken... in fact I do ponder now how to move forward on some 
projects where I am ready to pay for an LC "engineer" to help with 
apps... (stay tuned for a call on this in the weeks to come...our 
budgets are very small though...)


The collaborative environment is not looking too facile... We are kind 
of left with the old RCS model, check file out... wait while I work on 
it... check it in... wait while you work on it... making archival copies 
along the way of course, but there is easy way for regression or 
innovative testing of alternative methods along the way without having 
do regress the entire stack.


BR

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

Re: AW: AW: How do you handle the poor performance of LC 7?


Mark Wieder wrote:
> The problem is that "pretty good" isn't good enough for LiveCode
> positioning itself in the marketplace, and that bodes ill for all
> of us who hope for its continued existence. We old-timers are more
> willing to accept some of the flaws, the degradations in performance,
> the long-standing bugs, the lack of features, etc. Folks
> investigating LC as a development platform won't be as forgiving.

I'd like to live in an ideal world too.  I just recognize the world 
we're in.


And thankfully, warts and all, none of the issues with LiveCode are 
preventing Trevor, myself, and many others from shipping products made 
with it.



>> If moving into the present with LiveCode 7 seems like a lot of work,
>> talk to Python 2 fans migrating their code to Python 3. ;)
>
> Heh. Yeah. Python is quite particular about versions. I've had to
> move my code to Python 3.3, not just 3.2 any more, because there
> were too many incompatibilities.

Exactly - warts and all, that hasn't stopped a good many people from 
using Python.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: How do you handle the poor performance of LC 7?


On 05/30/2015 12:40 PM, Mark Wieder wrote:


along the way or are new converts to LiceCode. And add to those


Oops. Obviously I meant LiveCode.

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: How do you handle the poor performance of LC 7?


On 05/30/2015 11:19 AM, Brahmanathaswami wrote:


But... I'm not a programmer...


I''ve seen some of the code you've thrown together, and I beg to differ.



So I get it that there may be a lot of weeping and wailing if you are
doing industrial systems. In that world perhaps "the time has passed for
Livecode to be considered a serious development tool."  But I think this
misses the point about the vision of the future context(s) where
software that is this incredibly easy to use and for such an amazing
array of jobs... has incredible value for the masses of would be geeks
who will never, ever worry about 20,000 of anything and who would like
to code but not have it be so "painful"  and, as they mature, have a
toolbox they can use to get serious work to done.


Yeah, but here's the difference: you're the boss, you can make the 
decisions, you don't have to convince upper management about how new 
development tools fit into the existing set; and you don't have to 
manage a group of half a dozen engineers all trying to make changes to 
parts of the same application in development, and figure out how to 
merge their changes into one stack.




So "the rest of us" I really believe that there really *nothing* out
there like LiveCode that can give me this kind of freedom and create
power to do this kind of diverse tool generation in such short time
frames across all these usage contexts -- desktop, standalone, server,
mobile, all working seamlessly together.


...and I'm certainly not going to argue that point with you, but really 
what you're aguing for is the power of the xtalk environment, not 
LiveCode in particular. And I agree, that's why we're still here today 
whether we started with HyperCard or discovered SuperCard somewhere 
along the way or are new converts to LiceCode. And add to those 
affirmations the fact that I'm four to five times as productive writing 
xtalk code as I am in C or Ruby or Javascript or whatever.

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: AW: AW: How do you handle the poor performance of LC 7?


On 05/30/2015 10:54 AM, Richard Gaskin wrote:


If we were in a more optimistic mood, we could say:

   LiveCode 7 is very good at exposing suboptimal algorithms.


Yep. And for dp or rc builds I think that's a good thing.
But not for 'stable' releases.


That most stuff works without any noticeable difference at all is pretty
good, even if we can expect to find a handful of edge cases where
optimizing the algorithm may be needed.


The problem is that "pretty good" isn't good enough for LiveCode 
positioning itself in the marketplace, and that bodes ill for all of us 
who hope for its continued existence. We old-timers are more willing to 
accept some of the flaws, the degradations in performance, the 
long-standing bugs, the lack of features, etc. Folks investigating LC as 
a development platform won't be as forgiving.



If moving into the present with LiveCode 7 seems like a lot of work,
talk to Python 2 fans migrating their code to Python 3. ;)


Heh. Yeah. Python is quite particular about versions. I've had to move 
my code to Python 3.3, not just 3.2 any more, because there were too 
many incompatibilities.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: Subject: Re: How do you handle the poor performance of LC 7?


Mark Rauterkus wrote:

So, one possible answer as to how to handle the poor performance of LC 7 is
to wait. But how long is that waiting?


Depends on the specifics of this issue.  What performance issues are 
affecting your apps?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Subject: Re: How do you handle the poor performance of LC 7?

2015-05-30 Thread Mark Rauterkus

Hi All,

Everyone won't ever always be happy, but when do "the rest of us" turn
those frowns upside down? In what month or year?

Tell us about the timing of the arrival of the light at the end of the
tunnel.

What is your guess as to WHEN? Wondering.

Of course, this asks for total speculation. Of course, skeptics are friends
too.

So, one possible answer as to how to handle the poor performance of LC 7 is
to wait. But how long is that waiting?

--
Ta.


Mark Rauterkus   mark.rauter...@gmail.com
412 298 3432 = cell
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How do you handle the poor performance of LC 7?

2015-05-30 Thread Brahmanathaswami


And then there is the rest of us... how many I don't know.

I'm not  "Programmer" per se... I did some PHP, kinda grok JS... and 
they make me very edgy if I start thinking about useing them to getting 
work done. ...


Mostly   I just "need to get stuff done today!"

I can hack up a stack for some volunteer to load .epubs, extract the 
xhtml files and then dig out pull quotes for me into an on-board 
database, dump those to a  pipe delimited file and then on the server 
using the same language read that file and upload all that data into a 
MySQL date base and then use RevIgniter to run the web site.


I can take visual assets from our designers here and in less then 30 
minutes throw them into an app. open it in Xcode and pop it onto my 
iPhone and say "See I told you so.. the type is really way too small."


I can load 1000 images in space (loc -1000,-1000) get their rects and 
save this and post to the online database.


I can create an interface in a few hours for some 14 year old girls to 
go thru and fix titles and description to art work.


If I need to process some horrible mass of text.. .I can just whip open 
my "text processor stack" which has 100 cards all load with an 
incredible mess of buttons that I' developed over 20 years of doing 
xTalk, pick a card tweak a script  process .ics calendars, put them to 
html... on and on


But... I'm not a programmer...

So I get it that there may be a lot of weeping and wailing if you are 
doing industrial systems. In that world perhaps "the time has passed for 
Livecode to be considered a serious development tool."  But I think this 
misses the point about the vision of the future context(s) where 
software that is this incredibly easy to use and for such an amazing 
array of jobs... has incredible value for the masses of would be geeks 
who will never, ever worry about 20,000 of anything and who would like 
to code but not have it be so "painful"  and, as they mature, have a 
toolbox they can use to get serious work to done.


So "the rest of us" I really believe that there really *nothing* out 
there like LiveCode that can give me this kind of freedom and create 
power to do this kind of diverse tool generation in such short time 
frames across all these usage contexts -- desktop, standalone, server, 
mobile, all working seamlessly together.


I suppose someone will try to convince me that some other language X can 
do all these things if I took the time to learn it... But, I'm familiar 
with enough of them... I've hever hired people who are "experts" in 
those languages and they time frames for getting stuff done just drive 
me nuts after years of doing xTalk.


I built a complete revision control system for Indesign documents here 
in house in under 20 hours... we have been using it for 5 years (since 
EOL adobe version control) with zero problems... )  I did this crazy 
wizard for the local desktops here on the LAN that sends search strings 
to a CGI on the big server (400,000 plus images) in house tha calls a 
shell command to use the locate database and returns results that the 
user can filter as he sees fit... way better than spotlight!


total lines of code in the app and the cgi on the server: less than 300.

I just don't think I'm going to get that anywhere else.

That said.. 7.0.5 is frustrating. Crashed 5 times on me to today... and 
I didn't have time to send in any bug reports... I saved one crash log.. 
will send later.. So, yeah, if I were in a corporate environment and 
some software manager were looking over my shoulder, I can understand 
the he might not take LC seriously.


Swasti Astu, Be Well!
Brahmanathaswami

Kauai's Hindu Monastery
www.HimalayanAcademy.com



Trevor DeVore wrote:

Hi Andrew,

I've been reading the responses to this thread and wanted to add some
additional thoughts. I understand where you are coming from and I don't
mean to argue against what you are saying. Each developer has different
needs and has different resources to allocate. Rather, I just want to add a
different perspective as the perspective most often shared on the mailing
list is from those experiencing problems with LC 7.


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

Re: AW: How do you handle the poor performance of LC 7?

On Sat, May 30, 2015 at 10:33 AM, Tiemo Hollmann TB 
wrote:

> I made some more performance benchmarks with my real life data
> I deactivated my "special sort" xSortListe handler and replaced it just by:
> 1. sort lines of tListe numeric
> 2. sort lines of tListe international
> (though it is not a solution for my sorting feature, but just to drill it
> down)
>

I don't think you need to go this far.

Just call it once and for all before editing; no need to do so at each
character, as filtering will preserve order.



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

Re: AW: AW: How do you handle the poor performance of LC 7?

2015-05-30 Thread Peter TB Brett


On 2015-05-30 19:33, Tiemo Hollmann TB wrote:

I made some more performance benchmarks with my real life data
I deactivated my "special sort" xSortListe handler and replaced it just 
by:

1. sort lines of tListe numeric
2. sort lines of tListe international
(though it is not a solution for my sorting feature, but just to drill 
it down)


LC 6.5.2, average times:
My repeat loop: 14 millisecs
plain Sort numeric: 3 millisecs
plain Sort international: 128 millisecs

LC 7.0.5, average times:
My repeat loop: 55 millisecs (+393%)
plain Sort numeric: 8 millisecs (+267%)
plain Sort international: 4100 millisecs (+3203%)


Oh dear. That "sort international" performance is really not very good 
at all, is it?  I think we will need to address this soon!


I was going to suggest trying the following but perhaps it will not make 
much difference because it still uses "sort international"



function TiemoSort pList
   local tSorted, tLine, tNumeric, tAlpha

   repeat for each line tLine in pList
  if isNumber(first char of  tLine) then
 put tLine & return after tNumeric
  else
 put tLine & return  after tAlpha
  end if
   end repeat

   sort tNumeric numeric
   sort tAlpha international

   return tAlpha & tNumeric
end TiemoSort


Thank you for sending your stack.  I hope it will enable us to deal with 
your problem promptly.  :-)



  Peter

--
Dr Peter Brett 
LiveCode Engine Development Team


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

Re: AW: AW: How do you handle the poor performance of LC 7?

Mark Wieder wrote:
> Nonetheless, if there's a significant performance hit in *the same
> code* running on different LC versions, then it's something to worry
> about.

If we were in a more optimistic mood, we could say:

  LiveCode 7 is very good at exposing suboptimal algorithms.

;)

Of course it would be more convenient for everyone if LiveCode could 
have undertaken the most significant rewrite of any xTalk ever and 
pulled it off with only performance gains and not a single downside.

But in the imperfect world we live in, desirable as that might be I 
don't think it's a realistic goal.

Some areas of the v7 engine are faster, some slower, and now and then 
the slower parts will be slow enough that it'll prompt us to consider 
revising our code as it would have been faster all along.

It's worth noting that the scope of Tiemo's slowdown is far beyond 
anything I've been able to measure in v7 myself, and well outside of 
just about anything I've even read about.

That most stuff works without any noticeable difference at all is pretty 
good, even if we can expect to find a handful of edge cases where 
optimizing the algorithm may be needed.

If moving into the present with LiveCode 7 seems like a lot of work, 
talk to Python 2 fans migrating their code to Python 3. ;)

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

AW: AW: How do you handle the poor performance of LC 7?

I made some more performance benchmarks with my real life data
I deactivated my "special sort" xSortListe handler and replaced it just by: 
1. sort lines of tListe numeric
2. sort lines of tListe international
(though it is not a solution for my sorting feature, but just to drill it down)

LC 6.5.2, average times:
My repeat loop: 14 millisecs
plain Sort numeric: 3 millisecs
plain Sort international: 128 millisecs

LC 7.0.5, average times:
My repeat loop: 55 millisecs (+393%)
plain Sort numeric: 8 millisecs (+267%)
plain Sort international: 4100 millisecs (+3203%)

for my real life app just unacceptable
Tiemo



-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Tiemo Hollmann TB
Gesendet: Samstag, 30. Mai 2015 18:59
An: 'How to use LiveCode'
Betreff: AW: AW: How do you handle the poor performance of LC 7? 

Hi Malte, you and Richard are on the right trace - and I was blind :) The time 
cruncher is not the repeat loop, but my "special" sorting routine. I have a 
mixed alpha-numerical list. It is perhaps a little bit strange, but I want the 
numbers to be sorted at the end of the list. "A-Z-1-9-10-99-100-x" Because I 
didn't found a "build-in" function to realize this, that’s why I created this 
"Tiemo-Sort" (xSortListe). Perhaps there is a much straight forward way to do 
this. Because I never had performance issues with this I completely forgot this 
handler, I think I have to rethink this special sort:


---
function xSortListe pListe
   -
   -- Sortierung einer einfachen Liste, Zahlen am Ende
   local tZeile, tLine, tArt, tOben, tAlphaSort
   sort lines of pListe numeric -- gesamte Liste numerisch sortieren, damit 
stehen alle Alphazeilen vorne und numerische hinten, Zahlen in richtiger Folge.
   put the number of lines of pListe into tOben
   
   put "mixed" into tArt
   if not isNumber(first char of line tOben of pListe) then -- Letztes Zeichen 
ist ein Alpha, also ganze Liste Alpha
  put "alpha" into tArt
   else if isNumber(first char of line 1 of pListe) then -- Letztes Zeichen ist 
Zahl und 1. Zeichen auch Zahl
  put "numeric" into tArt
   end if
   switch tArt
  case "alpha" -- reine Alphaliste einfach international sortieren
 sort lines of pListe international
 break
  case "mixed" -- bei gemischter Alpha + Zahlenliste nur den Alphateil 
international sortieren
 put 1 into tZeile
 repeat for each line tLine in pListe
if the first character of tLine is a number then -- erste Zeile, 
die mit einer Zahl beginnt
   exit repeat
end if
add 1 to tZeile
 end repeat
 put line 1 to (tZeile - 1) of pListe into tAlphaSort -- den Alpha-Teil 
herausnehmen und international sortieren
 sort lines of tAlphaSort international
 put tAlphaSort into line 1 to (tZeile - 1) of pListe -- den Alphateil 
wieder zurück in die Gesamtliste setzen.
 break
 -- rein numerische Liste ist am Anfang schon sortiert
   end switch
   return pListe
end xSortListe

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Malte Brill
Gesendet: Samstag, 30. Mai 2015 15:51
An: use-livecode@lists.runrev.com
Betreff: Re: AW: How do you handle the poor performance of LC 7? 

Hey Tiemo,

what does the xSortListe function do? What is rather funny that my real life 
problem childs are also revolving around a live search feature. It might well 
be that your speed issues (as mine) are related to the sorting part (if you do 
a sort). My approach is a little diffrent than yours, as I do have numeric keys 
in the array (and as numeric keys are not in stable order in an array I have 
(had) to sort those on each keystroke). 

To be fair towards 7, I have refactored quite a bit of my own code over the 
past weeks and now have scenarios where the performance impact is far less 
dramatic than it used to be. I just got around to test this yesterday and now 
see a speed loss of the 7 engine of 7 to 15% which is somewhat acceptable (not 
good, but acceptable). I had to jump through quite some hoops to get there 
though. The only upside is that stuff got significantly faster also in 6.7 so 
my users would see a general performance boost regardless the engine. That is 
something I can sell. This is speaking for my own software though. If I am in 
control of the budget all it costs is my time to refactor existing stuff and 
most of the times refactoring is my friend, as generally the code base gets 
better. If I am on the other side of my programming life, namely coding for 
other customers, it gets a lot harder to sell them on refactoring a couple of 
100 stacks, just to get them to the same speed with the newer

Re: AW: AW: How do you handle the poor performance of LC 7?


On 05/30/2015 09:58 AM, Tiemo Hollmann TB wrote:


Hi Malte, you and Richard are on the right trace - and I was blind :)


Nonetheless, if there's a significant performance hit in *the same code* 
running on different LC versions, then it's something to worry about.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: How do you handle the poor performance of LC 7?


On 05/29/2015 09:27 PM, Andrew Kluthe wrote:


Most of our c# stuff is still .Net ;)


Yeah, C# isn't really as bad as it might be. The language itself is 
reasonable, if only it could be separated from the .NET stuff.



nodejs debugging suite, built in git client, great js intellisense while


Speaking of NodeJS, have you checked out famo.us yet? I went to their 
new api launch last week, and I think they're going to make a big splash 
at the conference next month. This is what I'll be doing instead of the 
LiveCode/HTML5 thing.


http://famo.us
http://famous.org

--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: How do you handle the poor performance of LC 7?


On 05/30/2015 08:07 AM, Richard Gaskin wrote:


In short, the developers were completely insulated from any
understanding of the average user experience.  It simply wasn't possible
for them to know how slow their code had become in the eyes of their
market.


I had a similar experience doing QA work at Apple. I refused on 
principle to do what the other developers were doing: using the latest 
bleeding-edge computers off the line, instead verifying that things 
worked across the range of systems. This led to filing some interesting 
bug reports...


My favorite was finding what turned out to be a bug in the way the MPW C 
compiler created its stack frames. It would have been completely missed 
and shipped if I had been using the latest and greatest CPU set, and at 
first the bug report was dismissed as unreproducible because of course 
it worked fine on the newest machines.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

AW: AW: How do you handle the poor performance of LC 7?

Hi Malte, you and Richard are on the right trace - and I was blind :)
The time cruncher is not the repeat loop, but my "special" sorting routine. I 
have a mixed alpha-numerical list. It is perhaps a little bit strange, but I 
want the numbers to be sorted at the end of the list. "A-Z-1-9-10-99-100-x" 
Because I didn't found a "build-in" function to realize this, that’s why I 
created this "Tiemo-Sort" (xSortListe). Perhaps there is a much straight 
forward way to do this. Because I never had performance issues with this I 
completely forgot this handler, I think I have to rethink this special sort:


---
function xSortListe pListe
   -
   -- Sortierung einer einfachen Liste, Zahlen am Ende
   local tZeile, tLine, tArt, tOben, tAlphaSort
   sort lines of pListe numeric -- gesamte Liste numerisch sortieren, damit 
stehen alle Alphazeilen vorne und numerische hinten, Zahlen in richtiger Folge.
   put the number of lines of pListe into tOben
   
   put "mixed" into tArt
   if not isNumber(first char of line tOben of pListe) then -- Letztes Zeichen 
ist ein Alpha, also ganze Liste Alpha
  put "alpha" into tArt
   else if isNumber(first char of line 1 of pListe) then -- Letztes Zeichen ist 
Zahl und 1. Zeichen auch Zahl
  put "numeric" into tArt
   end if
   switch tArt
  case "alpha" -- reine Alphaliste einfach international sortieren
 sort lines of pListe international
 break
  case "mixed" -- bei gemischter Alpha + Zahlenliste nur den Alphateil 
international sortieren
 put 1 into tZeile
 repeat for each line tLine in pListe
if the first character of tLine is a number then -- erste Zeile, 
die mit einer Zahl beginnt
   exit repeat
end if
add 1 to tZeile
 end repeat
 put line 1 to (tZeile - 1) of pListe into tAlphaSort -- den Alpha-Teil 
herausnehmen und international sortieren
 sort lines of tAlphaSort international
 put tAlphaSort into line 1 to (tZeile - 1) of pListe -- den Alphateil 
wieder zurück in die Gesamtliste setzen.
 break
 -- rein numerische Liste ist am Anfang schon sortiert
   end switch
   return pListe
end xSortListe

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Malte Brill
Gesendet: Samstag, 30. Mai 2015 15:51
An: use-livecode@lists.runrev.com
Betreff: Re: AW: How do you handle the poor performance of LC 7? 

Hey Tiemo,

what does the xSortListe function do? What is rather funny that my real life 
problem childs are also revolving around a live search feature. It might well 
be that your speed issues (as mine) are related to the sorting part (if you do 
a sort). My approach is a little diffrent than yours, as I do have numeric keys 
in the array (and as numeric keys are not in stable order in an array I have 
(had) to sort those on each keystroke). 

To be fair towards 7, I have refactored quite a bit of my own code over the 
past weeks and now have scenarios where the performance impact is far less 
dramatic than it used to be. I just got around to test this yesterday and now 
see a speed loss of the 7 engine of 7 to 15% which is somewhat acceptable (not 
good, but acceptable). I had to jump through quite some hoops to get there 
though. The only upside is that stuff got significantly faster also in 6.7 so 
my users would see a general performance boost regardless the engine. That is 
something I can sell. This is speaking for my own software though. If I am in 
control of the budget all it costs is my time to refactor existing stuff and 
most of the times refactoring is my friend, as generally the code base gets 
better. If I am on the other side of my programming life, namely coding for 
other customers, it gets a lot harder to sell them on refactoring a couple of 
100 stacks, just to get them to the same speed with the newer engine, without 
(many) other benefits. ROI isn’t that appealing / existent for them there.

That said, I guess we need more real life things where the 7 and 8 engine is 
slower to hand over to the team, so many thanks you sent your stacks. As Mark 
said, the „laboratory“ benchmark tests do not appear to help as much as I would 
have thought in the first place. On the other hand it is rather difficult to 
send over complete projects if they require additional requisites (like a 
Database, or even worse a complete server) to demonstrate the issues. I must 
say the team has been most helpful there, so I really hope for the best.

Cheers,

Malte



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

Re: How do you handle the poor performance of LC 7?

On Sat, May 30, 2015 at 8:07 AM, Richard Gaskin 
wrote:

> It turned out that the acquiring company is very generous with their
> developers, outfitting them with the very latest and fastest Macs loaded
> with maximum RAM and the fastest HDDs on the market.

I hit the opposite of this during my dissertation.

The Fortran compiler I was using (absoft?) was based on the Cray compiler
(yes, an odd adaptation).  Anyway, I was working with huge matrices on a
mathematically intractable problem.  This was probably in '07 o '98.

The source of the crashes finally turned out to be my allocation of a
dynamic array.

I had more memory (512mb, iirc) than any of the developers so they had
never tried an array that was larger than 256mb.  Turns out that such
arrays were bit addressed, and I had surpassed 2^31 bits . . .  I was
bemused by accidentally tripping over a situation where 32 bit addressing
was not enough . . .

Fixed dimension arrays were faster, anyway . . .

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

Re: AW: How do you handle the poor performance of LC 7?


Thanks for sending your stack to the team.  Please let us know the outcome.

And thanks for posting that handler.  Mike and Richard already hit on 
the only two items that come to mind (sorting and filtering), but I'm 
curious:  How does performance look if you comment out the call to 
xSortListe?


I wish I had time this morning to run some benchmarking between a loop 
through an array as you have here and a filter on a pre-sorted list, but 
my hunch is the latter would take care of a lot of that performance for you.


If you have time to run a quick benchmark on that handler with and 
without the xSortListe call commented, I would be very interested in the 
results.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


Tiemo Hollmann wrote:

> Hi Richard,
>
> the scenario is a field to enter a search term. With each entered
> character (keyUp) or each backspace (rawKeyUp) correcting the search
> term I call the following selecting routine to get a "live selection"
> of my 20,000 record list of words. In LC 6 I can enter the chars as
> fast as I want and this handler is always "on time" to show me the
> result list. In LC 7.0.5 it swallows the entered chars, can't catch
> up until it stucks completely. I am not talking of a slow down of 10
> or 50%. I am talking about a slow down of some x100%, which makes the
> complete handling unacceptable. Maybe my code isn't very
> professional, so feel free to show up better style. I have send
> Hanson my original real live stack.
> Tiemo
>
> Here is the relevant piece of code:
>
>repeat for each key tKey in garrVideos -- alle Begriffe und Sätze
> durchgehen
>   if gAktRubrik <> 99 and gAktRubrik is not item 2 of 
garrVideos[tKey]

> then next repeat -- falsche Rubrik
>   if tBegriffFlag is not item 6 of garrVideos[tKey] then next 
repeat --

> falsche Kategorie Begriffe
>   if gMenuAktuell is "Bearbeiten" and tKey is in 
tLernlistenInhalt then

> next repeat -- Begriff schon in Lernliste
>   if tSuchbegriff is empty then -- kein Suchbegriff, Begriff/Satz
> übernehmen
>  put tKey & cr after tListe
>   else -- nach Suchbegriff selektieren
>  if tSuchenBeliebig is true then -- an beliebiger Stelle im Wort
> suchen
> if tKey contains tSuchbegriff then -- Wort/Satz enthält
> Suchbegriff
>put tKey & cr after tListe
> end if
>  else -- Suchbegriff nur am Anfang des Wortes
> if tKey begins with tSuchbegriff then -- Wort/Satz 
beginnt mit

> Suchbegriff
>put tKey & cr after tListe
> end if
>  end if
>   end if
>end repeat
>if tListe is not empty then delete last char of tListe   -- letzten CR
> löschen
>put xSortListe(tListe) into fld "Liste" -- Text ins Anzeigefeld 
kopieren




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

Re: How do you handle the poor performance of LC 7?

Richmond wrote:

> How do I handle the poor performance of LC 7?
>
> Make sure I deploy my standalones on computers that are over 7 years
> old; then one doesn't notice the difference!
>
> Seriously; most of my computers are a bit like me: "of a certain age"
> and I haven't really noticed a difference.

Me neither.  That is, once I stepped away from the benchmarks and the 
vague complaints and actually ran my software in v7.

Some of my friends poke fun at my choice of modest hardware, but the 
reasons I prefer the components I work with extends far beyond being 
able to spend the cost difference on a weekend at a seaside resort:

Many years ago I was a Beta tester for a product which shall remain 
nameless, shortly after it was acquired by another company also unnamed 
here.  Prior to the acquisition it was a Mac-only app that ran 
beautifully, but that summer the acquiring team folded the code into 
their cross-platform framework, and the app size exploded while 
performance dropped about proportionately.  With some features the 
performance loss was significant enough to impair usability.

So I submitted a couple of performance-related bugs, feeling that was a 
reasonable thing to do since back in those days my hardware habit was to 
buy Apple's second-best machine every three years at the outside, so I 
never worked on the latest and greatest (that is, after the clone I 
bought from PowerComputing, but that's another story), but somewhat 
ahead of what the average computer user would have.

My reports came back "UTR" - Unable to Reproduce.

We went back and forth and ultimately I asked for a machine profile so I 
could compare what the devs were working with to what I was working with.

It turned out that the acquiring company is very generous with their 
developers, outfitting them with the very latest and fastest Macs loaded 
with maximum RAM and the fastest HDDs on the market.

In short, the developers were completely insulated from any 
understanding of the average user experience.  It simply wasn't possible 
for them to know how slow their code had become in the eyes of their market.

I can't really blame them, but I did find it curious that the product 
manager didn't notice this performance disparity while managing the 
testing pool.

Ever since then my hardware choices have become increasingly lean, 
buying only the CPU power I truly need while keeping an eye on what 
average customers are using.

And I'll admit I have a simpler life than those devs: as a scripter 
using LiveCode, I never have to wait for a compile cycle. :)

So all hail cheap hardware!  It keeps our code honest.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: AW: How do you handle the poor performance of LC 7?

On Sat, May 30, 2015 at 7:16 AM, Mike Bonner  wrote:

> Malte, it might help if you don't sort the keys on each keystroke, instead
> put the keys into a list and sort them once, then keep referring to that
> same list as you do your filtering. Its faster to pop the full sorted list
> into a working variable on each keystroke and filter than it is to get the
> keys, sort the keys, then filter.
>

That's also what mine does.  Pulled once from the database already sorted,
stashed,then copied on use to a working set.  Working set is further
filtered for added characters, and recopied then filtered if a char is
deleted.

Now that I think of it in this context, a FILTER SORTED that assumes sorted
data might be faster (but I suppose only faster if filtering from first
character, rather than arbitrary position).

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

Re: AW: How do you handle the poor performance of LC 7?

2015-05-30 Thread Mike Bonner

Malte, it might help if you don't sort the keys on each keystroke, instead
put the keys into a list and sort them once, then keep referring to that
same list as you do your filtering. Its faster to pop the full sorted list
into a working variable on each keystroke and filter than it is to get the
keys, sort the keys, then filter.


To optimize further, you can do a comparison on each keystroke by keeping
track of the previous search.

if char 1 to -2 of the current search string is the same as the previous
search string,.  you've just added a single char to the end of the search
string.  In this case you can do your filter on the most recently filtered
list rather than doing the full list filter each time. Otherwise, pull in
the full sorted list from wherever you're hiding it and do the filter on
that.

On Sat, May 30, 2015 at 7:50 AM, Malte Brill  wrote:

> Hey Tiemo,
>
> what does the xSortListe function do? What is rather funny that my real
> life problem childs are also revolving around a live search feature. It
> might well be that your speed issues (as mine) are related to the sorting
> part (if you do a sort). My approach is a little diffrent than yours, as I
> do have numeric keys in the array (and as numeric keys are not in stable
> order in an array I have (had) to sort those on each keystroke).
>
> To be fair towards 7, I have refactored quite a bit of my own code over
> the past weeks and now have scenarios where the performance impact is far
> less dramatic than it used to be. I just got around to test this yesterday
> and now see a speed loss of the 7 engine of 7 to 15% which is somewhat
> acceptable (not good, but acceptable). I had to jump through quite some
> hoops to get there though. The only upside is that stuff got significantly
> faster also in 6.7 so my users would see a general performance boost
> regardless the engine. That is something I can sell. This is speaking for
> my own software though. If I am in control of the budget all it costs is my
> time to refactor existing stuff and most of the times refactoring is my
> friend, as generally the code base gets better. If I am on the other side
> of my programming life, namely coding for other customers, it gets a lot
> harder to sell them on refactoring a couple of 100 stacks, just to get them
> to the same speed with the newer engine, without (many) other benefits. ROI
> isn’t that appealing / existent for them there.
>
> That said, I guess we need more real life things where the 7 and 8 engine
> is slower to hand over to the team, so many thanks you sent your stacks. As
> Mark said, the „laboratory“ benchmark tests do not appear to help as much
> as I would have thought in the first place. On the other hand it is rather
> difficult to send over complete projects if they require additional
> requisites (like a Database, or even worse a complete server) to
> demonstrate the issues. I must say the team has been most helpful there, so
> I really hope for the best.
>
> Cheers,
>
> Malte
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: AW: How do you handle the poor performance of LC 7?

2015-05-30 Thread Malte Brill

Hey Tiemo,

what does the xSortListe function do? What is rather funny that my real life 
problem childs are also revolving around a live search feature. It might well 
be that your speed issues (as mine) are related to the sorting part (if you do 
a sort). My approach is a little diffrent than yours, as I do have numeric keys 
in the array (and as numeric keys are not in stable order in an array I have 
(had) to sort those on each keystroke). 

To be fair towards 7, I have refactored quite a bit of my own code over the 
past weeks and now have scenarios where the performance impact is far less 
dramatic than it used to be. I just got around to test this yesterday and now 
see a speed loss of the 7 engine of 7 to 15% which is somewhat acceptable (not 
good, but acceptable). I had to jump through quite some hoops to get there 
though. The only upside is that stuff got significantly faster also in 6.7 so 
my users would see a general performance boost regardless the engine. That is 
something I can sell. This is speaking for my own software though. If I am in 
control of the budget all it costs is my time to refactor existing stuff and 
most of the times refactoring is my friend, as generally the code base gets 
better. If I am on the other side of my programming life, namely coding for 
other customers, it gets a lot harder to sell them on refactoring a couple of 
100 stacks, just to get them to the same speed with the newer engine, without 
(many) other benefits. ROI isn’t that appealing / existent for them there.

That said, I guess we need more real life things where the 7 and 8 engine is 
slower to hand over to the team, so many thanks you sent your stacks. As Mark 
said, the „laboratory“ benchmark tests do not appear to help as much as I would 
have thought in the first place. On the other hand it is rather difficult to 
send over complete projects if they require additional requisites (like a 
Database, or even worse a complete server) to demonstrate the issues. I must 
say the team has been most helpful there, so I really hope for the best.

Cheers,

Malte



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

AW: How do you handle the poor performance of LC 7?

Hi Malte,
I've send Hanson my "real live stack"
Waiting what they will tell me
Tiemo

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Malte Brill
Gesendet: Freitag, 29. Mai 2015 17:53
An: use-livecode@lists.runrev.com
Betreff: Re: How do you handle the poor performance of LC 7?

I set up a couple of benchmark stacks a while back:

http://forums.livecode.com/viewtopic.php?f=67&t=22072 
<http://forums.livecode.com/viewtopic.php?f=67&t=22072>

Bad thing was that the team wanted to see „real live scenarios“ (which most of 
my benchmark stacks are, just boiled down to the core of the problems as I 
found them). I was able to fly over to Edinburgh and discuss many of the 
problematic areas with the team. I guess the more „real live“ scenarios they 
see, the better as it might help find optimisations. Until the speed issues are 
resolved I am stuck with 6.7 for productive work, which is a shame because for 
one project I would urgently need to be able to support arabic RTL input. But I 
guess the old rule applies: First you make it work, then you make it fast. 
Impatiently waiting for the latter. :-)

Best,

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


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

AW: How do you handle the poor performance of LC 7?

Hi Richard,

the scenario is a field to enter a search term. With each entered character
(keyUp) or each backspace (rawKeyUp) correcting the search term I call the
following selecting routine to get a "live selection" of my 20,000 record
list of words. In LC 6 I can enter the chars as fast as I want and this
handler is always "on time" to show me the result list. In LC 7.0.5 it
swallows the entered chars, can't catch up until it stucks completely. I am
not talking of a slow down of 10 or 50%. I am talking about a slow down of
some x100%, which makes the complete handling unacceptable. Maybe my code
isn't very professional, so feel free to show up better style. I have send
Hanson my original real live stack.
Tiemo

Here is the relevant piece of code:

   repeat for each key tKey in garrVideos -- alle Begriffe und Sätze
durchgehen
  if gAktRubrik <> 99 and gAktRubrik is not item 2 of garrVideos[tKey]
then next repeat -- falsche Rubrik
  if tBegriffFlag is not item 6 of garrVideos[tKey] then next repeat --
falsche Kategorie Begriffe
  if gMenuAktuell is "Bearbeiten" and tKey is in tLernlistenInhalt then
next repeat -- Begriff schon in Lernliste
  if tSuchbegriff is empty then -- kein Suchbegriff, Begriff/Satz
übernehmen
 put tKey & cr after tListe
  else -- nach Suchbegriff selektieren
 if tSuchenBeliebig is true then -- an beliebiger Stelle im Wort
suchen
if tKey contains tSuchbegriff then -- Wort/Satz enthält
Suchbegriff
   put tKey & cr after tListe
end if
 else -- Suchbegriff nur am Anfang des Wortes
if tKey begins with tSuchbegriff then -- Wort/Satz beginnt mit
Suchbegriff
   put tKey & cr after tListe
end if
 end if
  end if
   end repeat   
   if tListe is not empty then delete last char of tListe   -- letzten CR
löschen
   put xSortListe(tListe) into fld "Liste" -- Text ins Anzeigefeld kopieren

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von Richard Gaskin
Gesendet: Freitag, 29. Mai 2015 20:12
An: use-livecode@lists.runrev.com
Betreff: Re: How do you handle the poor performance of LC 7?

Tiemo Hollmann wrote:

 > Testing my stacks in LC 7.0.5 , they show such a poor performance.
 > E.g. plain repeat loops with 20,000 records which take a fraction  > of a
second in LC 6, last up to 10 seconds in LC 7, which is more  > than
unacceptable for me / my clients on old poor machines.

Can you post the code for that loop, and tell us a bit about the data it
works on?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  
  ambassa...@fourthworld.comhttp://www.FourthWorld.com

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


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

Re: How do you handle the poor performance of LC 7?

2015-05-30 Thread Pierre Sahores


> Le 30 mai 2015 à 01:17, Richard Gaskin  a écrit :
> 
> The ability to deliver a single compact binary file that contains both 
> objects and code contributes strongly to LiveCode's uncommon productivity,

Not only…

Nobody seems to care around about something possibly more important about the 
LiveCode uncommon productivity…

...

« Can programming be liberated from the von Neumann style? : a functional style 
and its algebra of programs »

John Backus (Fortran Lead Designer, IBM researcher, inventor of the Functional 
Programming paradigm).

http://www.columbia.edu/cu/computinghistory/backus.html

…

http://en.wikipedia.org/wiki/Functional_programming

The main superiority of the Functional Programming Paradigm over the Object 
Oriented Programming Paradigm is very simple :

- FP permits to software designers to describe and implement the software 
complexity trough 2D representation’s plans of what has to be done. This is not 
possible in the OOP world where UML is intended to suits the same needs.
- The Stack’s model is a lots more productive way to go than the Decision Tree 
will ever been.

…

Scala and LiveCode are today two of the most productive functional programming 
languages available around but :

- LiveCode is not intended to be incredibly productive because it’s a 
functional language but because it’s an XTalk.

http://en.wikipedia.org/wiki/LiveCode

- Scala is intended to be incredibly productive because it’s a functional 
language.

http://en.wikipedia.org/wiki/Scala_%28programming_language%29

…

Apple (Hypercard, Swift), Oracle (Oracle Media Object), IBM (Rexx), NASA, EADS, 
and, probably, even Microsoft and Google, are using functional programming 
languages for their own internal development needs.

Why ? 

- Because what can be implemented in one line of code in FP will in average 
need 20 to 50 lines of code in OOP.

Why FP is not intended to be used by the most important companies selling 
development services to (beside their now internal needs) to the outside world ?

- Because they are selling days, months and years of developments, not 
development performance.

…

LiveCode will probably never be pushed up and being seen as a first class 
professional grade programming language as long as it will not assume pliantly 
is FP roots.

A bon entendeur, Salut !
--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com


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

Re: How do you handle the poor performance of LC 7?

2015-05-30 Thread Richmond


How do I handle the poor performance of LC 7?

Make sure I deploy my standalones on computers that are over 7 years 
old; then one doesn't notice the difference!


Seriously; most of my computers are a bit like me: "of a certain age" 
and I haven't really noticed a difference.


Richmond.

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

Re: How do you handle the poor performance of LC 7?

Most of our c# stuff is still .Net ;)

I've come to really like more staticly typed development ( one thing I love
about lcb stuff I've messed with) and now I can do all my js and node work
in the same ide. I never thought I'd say it, but visual studio and c# and
.net is growing on me. Particularly in regards to their new open source
efforts and being able to target Mac and Linux hosts with their upcoming
asp.net MVC and web api products. The new visual studio code editor is
cross platform, built on similar tech to the atom editor And comes with a
nodejs debugging suite, built in git client, great js intellisense while
still staying really light on the ide features. I'd do naughty things for
an LC script editor with intellisense like features.

On Fri, May 29, 2015, 10:25 PM Mark Wieder  wrote:

> On 05/29/2015 07:28 PM, Andrew Kluthe wrote:
>
> > And yes, since montes effort on lcvcs and the new flat file lcb
> libraries,
> > VCS support is being addressed. I'm excited to build something great. But
> > unfortunately, even after the transition and this new stuff is continuing
> > to wow us I don't think I'll be allowed to do much more with livecode at
> my
> > 9-5 and that bums me out. I'll have to save livecode 8 and 9 stuff for
> > contract work or as a hobby/personal project.
>
> Yeah, essentially my situation as well. Over the last dozen or so years
> I've seen projects that might have been realized in LiveCode turned into
> Adobe Flex (yuck), C# (not quite so yuck), .NET (yuck again), Rails (not
> quite so yuck)... several things have held back and still hold back the
> acceptance of LiveCode into existing development environments: the lack
> of integrated version control, the learning curve, the inability to
> interact with other tools, the lack of dynamic linking, etc. The biggest
> hurdle is the monolithic structure, promoting cowboy coding and acting
> as an obstacle to teamwork. I think the time for LiveCode to have been
> accepted as a serious development tool has passed.
>
> Coding in LiveCode is fun and I continue to do in on a hobby basis, but
> I've given up on trying to use it for serious work. The promise and hype
> of LC7/8 is great, but the reality just doesn't live up to it. We'll see
> what the future has in store.
>
> --
>   Mark Wieder
>   ahsoftw...@gmail.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Mark Wieder


On 05/29/2015 07:28 PM, Andrew Kluthe wrote:


And yes, since montes effort on lcvcs and the new flat file lcb libraries,
VCS support is being addressed. I'm excited to build something great. But
unfortunately, even after the transition and this new stuff is continuing
to wow us I don't think I'll be allowed to do much more with livecode at my
9-5 and that bums me out. I'll have to save livecode 8 and 9 stuff for
contract work or as a hobby/personal project.


Yeah, essentially my situation as well. Over the last dozen or so years 
I've seen projects that might have been realized in LiveCode turned into 
Adobe Flex (yuck), C# (not quite so yuck), .NET (yuck again), Rails (not 
quite so yuck)... several things have held back and still hold back the 
acceptance of LiveCode into existing development environments: the lack 
of integrated version control, the learning curve, the inability to 
interact with other tools, the lack of dynamic linking, etc. The biggest 
hurdle is the monolithic structure, promoting cowboy coding and acting 
as an obstacle to teamwork. I think the time for LiveCode to have been 
accepted as a serious development tool has passed.


Coding in LiveCode is fun and I continue to do in on a hobby basis, but 
I've given up on trying to use it for serious work. The promise and hype 
of LC7/8 is great, but the reality just doesn't live up to it. We'll see 
what the future has in store.


--
 Mark Wieder
 ahsoftw...@gmail.com

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

Re: How do you handle the poor performance of LC 7?

Exactly Trevor and Richard. I agree strongly with both sentiments. There is
great promise in what's coming up but what we have now, I think, is still
in transition.

And yes, since montes effort on lcvcs and the new flat file lcb libraries,
VCS support is being addressed. I'm excited to build something great. But
unfortunately, even after the transition and this new stuff is continuing
to wow us I don't think I'll be allowed to do much more with livecode at my
9-5 and that bums me out. I'll have to save livecode 8 and 9 stuff for
contract work or as a hobby/personal project.

I wish I could spend some time giving the kind of dedication Trevor gives
to his LC projects and , indirectly, all of us by implementing and pushing
LC continually to its limits all these years. Clarify is such a valuable
tool in our shop. I'm excited to see what the widget architecture allows
you to accomplish!

I know this topic is a sensitive one at the moment, but it's important and
part of LCs adolescence as it goes open and becomes this new modern
platform its evolving to be.

On Fri, May 29, 2015, 6:18 PM Richard Gaskin 
wrote:

> Andrew Kluthe wrote:
>
>  > I think the decision boiled down to just wanting more mainstream
>  > processes for development and being able to find programmers we
>  > didn't have to train from scratch. So the decision was made to become
>  > a .Net shop...
>
> Ah yes, that's a conversation I know well.  Some of the members of this
> list may be old enough to remember the mantra of middle management, "No
> one ever got fired for buying IBM".  I have that conversation about
> every few months, with prospective clients and even current clients
> after acquisition or during review.
>
> That's why the Tiobe Index is such a long-tailed L curve: the most
> popular languages are picked up by new users looking for the most
> popular languages.  Heck, Pascal is still in the top 20 there right now,
> while the darling of Big Data, Erlang, is way down at #36 with only
> 0.403% of surveyed developers using it (though I'd wager there's at
> least twice as much demand for Erlang, and in arguably more interesting
> companies).
>
> Malcolm Gladwell's "The Tipping Point" explores thisultural dynamic
> well, and Geoff Moore's "The Gorilla Game" applies it to the software
> industry cogently.
>
> The irony of the middle manager fixation on number of available
> developers is that it doesn't really matter if there are a million Java
> programmers, because they're never going to hire a million programmers.
>
> All they really need to see is that the number of developers available
> is higher than the number they want to hire, often just one or two, or
> maybe if they're really invested in a language as many as a dozen.  And
> there are least a dozen developers well versed in Erlang, and in
> LiveCode. :)
>
> That's why middle managers aren't founders:  You don't build a company
> from scratch by doing whatever everyone else is already doing.
>
>
> The need for good support of third-party version control systems is a
> more practical problem, one that's historically never been addressed by
> any toolkit in this family of languages.
>
> The ability to deliver a single compact binary file that contains both
> objects and code contributes strongly to LiveCode's uncommon
> productivity, but this uncommon way of working doesn't yet fit well in a
> world of VCSes designed for a world of sameness in which apps written in
> most languages are comprised of hundreds of tiny text files.
>
> We're only halfway there now, but a big half: a library stack can be
> expressed as a text file, suitable for use in any VCS, and in
> well-factored projects that's where the meat will be.
>
> That still leaves UI stacks as binaries, and the LiveCode team is
> working on a solution for that.  And I believe Trevor and others are
> already using Monte's solution for that right now.
>
> Once that's built-in, a lot of larger teams will be able to come on board.
>
>
> In the meantime, LiveCode is just like the other bottom 90 in the Tiobe
> Index:  there will always be those managers who will only consider the
> top 10, which is why the top 10 rarely change position.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How do you handle the poor performance of LC 7?

Andrew Kluthe wrote:

> I think the decision boiled down to just wanting more mainstream
> processes for development and being able to find programmers we
> didn't have to train from scratch. So the decision was made to become
> a .Net shop...

Ah yes, that's a conversation I know well.  Some of the members of this 
list may be old enough to remember the mantra of middle management, "No 
one ever got fired for buying IBM".  I have that conversation about 
every few months, with prospective clients and even current clients 
after acquisition or during review.

That's why the Tiobe Index is such a long-tailed L curve: the most 
popular languages are picked up by new users looking for the most 
popular languages.  Heck, Pascal is still in the top 20 there right now, 
while the darling of Big Data, Erlang, is way down at #36 with only 
0.403% of surveyed developers using it (though I'd wager there's at 
least twice as much demand for Erlang, and in arguably more interesting 
companies).

Malcolm Gladwell's "The Tipping Point" explores thisultural dynamic 
well, and Geoff Moore's "The Gorilla Game" applies it to the software 
industry cogently.

The irony of the middle manager fixation on number of available 
developers is that it doesn't really matter if there are a million Java 
programmers, because they're never going to hire a million programmers.

All they really need to see is that the number of developers available 
is higher than the number they want to hire, often just one or two, or 
maybe if they're really invested in a language as many as a dozen.  And 
there are least a dozen developers well versed in Erlang, and in 
LiveCode. :)

That's why middle managers aren't founders:  You don't build a company 
from scratch by doing whatever everyone else is already doing.

The need for good support of third-party version control systems is a 
more practical problem, one that's historically never been addressed by 
any toolkit in this family of languages.

The ability to deliver a single compact binary file that contains both 
objects and code contributes strongly to LiveCode's uncommon 
productivity, but this uncommon way of working doesn't yet fit well in a 
world of VCSes designed for a world of sameness in which apps written in 
most languages are comprised of hundreds of tiny text files.

We're only halfway there now, but a big half: a library stack can be 
expressed as a text file, suitable for use in any VCS, and in 
well-factored projects that's where the meat will be.

That still leaves UI stacks as binaries, and the LiveCode team is 
working on a solution for that.  And I believe Trevor and others are 
already using Monte's solution for that right now.

Once that's built-in, a lot of larger teams will be able to come on board.

In the meantime, LiveCode is just like the other bottom 90 in the Tiobe 
Index:  there will always be those managers who will only consider the 
top 10, which is why the top 10 rarely change position.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Mark Wieder

Dr. Hawkins  writes:

> Several years ago (ok, it's really decades), Byte had a standard test suite
> to compare compilers.
> 
> Then they hit a compiler that recognized nothing was done with the
> information, and optimized the entire suite out . . . produced something
> that executed in 0 . . .
> 

LOL

Every program can be optimized.
Every program has bugs.
Therefore every program can be optimized to a single line of buggy code.

-- 
 Mark Wieder
 ahsoftw...@gmail.com



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

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Ray

Earlier today I jumped in briefly on this thread to confirm I had also 
experienced slower performance and on the same hand I'd like to jump 
back in now in full agreement with Trevor.  Coincidentally, just 
yesterday I was railing on to my wife (an excellent listener) about the 
old Hypercard days back in the late 1980's and how a very secretive 
Apple strung us along for years 'leading us to believe' they were 
continuing to support it, when if fact it was nothing more than that, 
'leading us on'.


In sharp contrast, the Livecode team has been nothing but open, 
visionary, dedicated and productive.  They've consistently done an 
excellent job of keeping Livecode on the leading edge.  This week I 
finally got around to building an app for iPhone/android.  It was 
relatively easy and I'm excited to delve into the many features these 
devices offer that I can now tap into via Livecode.  I thought of the 
conference in Edinburgh I attended years ago when Kevin Miller was 
almost beside himself with excitement as he shared his first successes 
in that area.


I've gotten around the slower performance in the script editor by 
dividing large scripts into multiple libraries, something which is 
probably good coding practice I should have been doing anyway. Regarding 
the slower production performance, it seems we have a variety of sound 
suggestions here which will help any of us address that issue while 
continuing to take advantage of the latest and greatest coming out of 
Edinburgh.


On 5/29/2015 11:20 PM, Trevor DeVore wrote:

On Fri, May 29, 2015 at 3:12 PM, Andrew Kluthe  wrote:


...

It's not really an excuse to sit back and wait for someone else to find out
the bugs as it is the hard reality of some people's situations.

In short, the request for us to invest this much time in helping them
figure it out is almost as stressful as the actual problems.

The Us (community) vs Them (RunRev) that persists is the result that most
of the people started using this software when it was still proprietary.
It's a big step for many of us to transition to. Particularly, if we came
to runrev/livecode to save us on development/prototyping time. Our
community used to be so sure of the praises of livecode. It really was and
will again sometime be a fantastic product. But I'm sorry to say v7 is not
a production quality toolset for those without tons of extra time on their
hands.


Hi Andrew,

I've been reading the responses to this thread and wanted to add some
additional thoughts. I understand where you are coming from and I don't
mean to argue against what you are saying. Each developer has different
needs and has different resources to allocate. Rather, I just want to add a
different perspective as the perspective most often shared on the mailing
list is from those experiencing problems with LC 7. I would like others
reading to know that there are people being productive with 7/8 right now.
It seems that the big issue that some have run into has to do with
processing large amounts of data. I don't do that within LiveCode itself. I
do a lot of work with arrays, however, and as Mark Waddingham has pointed
out, working with arrays is much more efficient in LC 7. I'm really
enjoying that. Now, I do see a slow-down in the IDE, particularly the
script editor, which I would like to see addressed, but that doesn't affect
my product.

I very much view my relationship with RunRev as a partnership rather than a
me vs. them. I've chosen LiveCode as my desktop development tool and I
believe in the vision that Kevin, Mark, and the team have for the product.
I've heard them discuss that vision over the 12 years that I've been using
LC. I see the changes being made in LC 7/8 as major steps in realizing that
vision. I love that LC is robust enough a tool for me to create my
products, while at the same time being easy enough to learn that I can
teach my young kids math and programming lessons using it. Because I
believe in that vision I don't mind allocating time troubleshooting bugs so
that the product can move forward. Most of the time those bugs are ones I
find while working on my product and they affect me directly. But not
always. Either way, I want the product to be the best it can be. I spend
more time tracking down my own bugs so every once in a  while it is nice to
track down a bug that somebody else has to fix :-)

Now, if LiveCode was sitting back on a buggy product and not trying to
improve it then I would have issues. As I've stated before, though, I watch
the work the team is doing via github. I also keep an eye on the bug
database. It gives me insight as to where LiveCode is headed and what is
being done to improve the stability of the product. What I see is a
commitment to making a great product. I see test frameworks being developed
(thanks Peter!), bugs being fixed, and time being spent with valgrind on
Linux to make sure there are no memory leaks. I also see these improvements
getting rolled into the steady builds b

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Trevor DeVore

On Fri, May 29, 2015 at 3:12 PM, Andrew Kluthe  wrote:

> ...
>
> It's not really an excuse to sit back and wait for someone else to find out
> the bugs as it is the hard reality of some people's situations.
>
> In short, the request for us to invest this much time in helping them
> figure it out is almost as stressful as the actual problems.
>
> The Us (community) vs Them (RunRev) that persists is the result that most
> of the people started using this software when it was still proprietary.
> It's a big step for many of us to transition to. Particularly, if we came
> to runrev/livecode to save us on development/prototyping time. Our
> community used to be so sure of the praises of livecode. It really was and
> will again sometime be a fantastic product. But I'm sorry to say v7 is not
> a production quality toolset for those without tons of extra time on their
> hands.
>

Hi Andrew,

I've been reading the responses to this thread and wanted to add some
additional thoughts. I understand where you are coming from and I don't
mean to argue against what you are saying. Each developer has different
needs and has different resources to allocate. Rather, I just want to add a
different perspective as the perspective most often shared on the mailing
list is from those experiencing problems with LC 7. I would like others
reading to know that there are people being productive with 7/8 right now.
It seems that the big issue that some have run into has to do with
processing large amounts of data. I don't do that within LiveCode itself. I
do a lot of work with arrays, however, and as Mark Waddingham has pointed
out, working with arrays is much more efficient in LC 7. I'm really
enjoying that. Now, I do see a slow-down in the IDE, particularly the
script editor, which I would like to see addressed, but that doesn't affect
my product.

I very much view my relationship with RunRev as a partnership rather than a
me vs. them. I've chosen LiveCode as my desktop development tool and I
believe in the vision that Kevin, Mark, and the team have for the product.
I've heard them discuss that vision over the 12 years that I've been using
LC. I see the changes being made in LC 7/8 as major steps in realizing that
vision. I love that LC is robust enough a tool for me to create my
products, while at the same time being easy enough to learn that I can
teach my young kids math and programming lessons using it. Because I
believe in that vision I don't mind allocating time troubleshooting bugs so
that the product can move forward. Most of the time those bugs are ones I
find while working on my product and they affect me directly. But not
always. Either way, I want the product to be the best it can be. I spend
more time tracking down my own bugs so every once in a  while it is nice to
track down a bug that somebody else has to fix :-)

Now, if LiveCode was sitting back on a buggy product and not trying to
improve it then I would have issues. As I've stated before, though, I watch
the work the team is doing via github. I also keep an eye on the bug
database. It gives me insight as to where LiveCode is headed and what is
being done to improve the stability of the product. What I see is a
commitment to making a great product. I see test frameworks being developed
(thanks Peter!), bugs being fixed, and time being spent with valgrind on
Linux to make sure there are no memory leaks. I also see these improvements
getting rolled into the steady builds being released to developers so that
we can get work done.

As I've reflected on the architectural changes made in LC 7, I see a
project which could very well cause a company to fail. It was a huge
project with few immediate or obvious advantages to developers. (Well, the
unicode improvements are quite significant to some. I still stop and smile
every time I write code in LC 7/8 that would have required workarounds to
support unicode in the past.) Like all major projects, it took longer than
expected. My bet is that many companies would not have been able to make
that transition. Given the nature of the transition to LC 7 I feel a little
extra sympathy for the engineers when I come across issues.

Currently I'm working on a major product upgrade that I started in LC 7 and
then moved to LC 8. I feel that it is far and away the best product I have
created in LiveCode to date. It looks fantastic! Widgets have made my
design work much easier and allowed me to create controls I couldn't
before. And it has full unicode support. I realize that I am more
adventurous than some but I've been releasing products with development
versions of LC for years. If I test my product and I don't run into any
issues then why not!

So to anyone thinking that they should steer clear of LC 7 because of what
you have read on the list, you should see how your project performs in LC
7. You may not see any performance issues at all. If you are using anything
less than 6.7 your apps look bad on high-resolution displays (Mac and
W

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Bob Sneidar

Boy I was your man. I know Foxpro and Livecode well. I actually expanded some 
SBT modules and when I got really good, I wrote my own new ones. Too bad, Ida 
come on board.

Bob S


On May 29, 2015, at 13:54 , Andrew Kluthe 
mailto:and...@ctech.me>> wrote:

I was hired to convert legacy visual foxpro programs into a more robust
system that could bring us into the present and was leaned on to sort of
build the programming teams and automate everything. Then we got a new set
of investors and could afford to write more of our industrial things
in-house and wanted to hire people who would be willing to work in LC. That
was hard to do. We wanted things like git repos once we got a bigger team
(before opensource when things like that were still hard for LC). I think
the decision boiled down to just wanting more mainstream processes for
development and being able to find programmers we didn't have to train from
scratch. So the decision was made to become a .Net shop and phase out the
livecode applications we had been using since then with .Net web apps and
desktop clients.

I guess you could say we just outgrew livecode's abilities at the time and
couldn't wait for the new ones to be available. It was more of a
convenience issue than than a showstopper for us. I keep waiting to go back
and show off some amazing new stuff the new livecode features introduce,
but so far I have been forced to keep waiting for that thing that can sell
us on doing some things in livecode still.

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

Re: How do you handle the poor performance of LC 7?

I'd still like to do other work in LC (less scale, less risk) but for
things like industrial control systems, warehouse management, etc. where
there are thousands or millions of dollars on the line, I guess it isn't
that 7.0 is really that bad as much as it was the wrong tool for us at the
wrong time. I had LC and walked around trying to build everything with it.
And I could build things really fast and it was good.

 Then I had to figure out how to structure larger applications considering
that livecode's stack format is a bit than most other tools. Andre did a
presentation at a runrev conference that inspired me to refactor some of
the big ones and make them much more manageable/testable almost like an MVC
kind of pattern.

I was hired to convert legacy visual foxpro programs into a more robust
system that could bring us into the present and was leaned on to sort of
build the programming teams and automate everything. Then we got a new set
of investors and could afford to write more of our industrial things
in-house and wanted to hire people who would be willing to work in LC. That
was hard to do. We wanted things like git repos once we got a bigger team
(before opensource when things like that were still hard for LC). I think
the decision boiled down to just wanting more mainstream processes for
development and being able to find programmers we didn't have to train from
scratch. So the decision was made to become a .Net shop and phase out the
livecode applications we had been using since then with .Net web apps and
desktop clients.

I guess you could say we just outgrew livecode's abilities at the time and
couldn't wait for the new ones to be available. It was more of a
convenience issue than than a showstopper for us. I keep waiting to go back
and show off some amazing new stuff the new livecode features introduce,
but so far I have been forced to keep waiting for that thing that can sell
us on doing some things in livecode still.

Yes, MS or Apple has waaay more resources than RunRev to do the things they
do, but damn if i wouldn't like it to be otherwise and still work everyday
in LC. Most of that reply to you, Richard, was just some back story on why
I feel the way I do. I reckon LC 7 is production ready depending on what
kind of (and what scale) production work you are talking about. The
attitude in our community is that livecode should be able to do anything
and everything. I'd agree with that. It's a great syntax. It's a great
concept. It works great for so many things. Maybe my things were just not
some of them. We had big ideas that started small, but now those big ideas
seem bigger than what we could do with it in a cost-effective manner.

On Fri, May 29, 2015 at 3:17 PM Richard Gaskin 
wrote:

> Andrew Kluthe wrote:
>
>  > I totally understand what you're talking about there, but between
>  > a full time gig, very young children, and freelance work at night.
>  > I just don't know where I'd find the time to be effective at giving
>  > them the level of detail that they need.
>
> I hear you.  The only reason I'm in a position to volunteer as much time
> as I do is because I have a responsibility to my company and those of my
> clients, which are dependent on LC as the foundation of their product
> lines.
>
> But LC is useful for a great many different workflows, and not all of
> them are as invested in it as the ones I help steward, so it's nice when
> folks have the time to submit reports but fully understandable if they
> don't.
>
>
>  > In short, the request for us to invest this much time in helping them
>  > figure it out is almost as stressful as the actual problems.
>  >
>  > The Us (community) vs Them (RunRev) that persists is the result that
>  > most of the people started using this software when it was still
>  > proprietary. It's a big step for many of us to transition to.
>
> I've seen this dynamic before, and I believe it has less to do with dual
> licensing than the nature of development tools themselves.
>
> I served on the advisory boards for Oracle Media Objects, Allegiant
> SuperCard, and Gain Momentum, and with each the relationship between the
> vendor and the community was in various ways challenging on both sides.
>
> We had many long meetings between the Gain team, a team from Irix, and
> my client, just to try to get robust video playback, and ultimately
> someone one my client's team had to write custom C code to pull it off.
>
> A number of critical features SuperCard developers relied on weren't in
> the engine at all but provided through externals, a good many of which
> were written by a team member in his spare time.  This meant funky
> syntax and design compromises, but they got us through the day well
> enough to move on to other challenges.
>
> With quality, all of them faced a daunting task that's quite literally
> orders of magnitude beyond the scope of testing requirements for
> anything we build with these tools:
>
> In the apps we make with xTalks, we use

Re: How do you handle the poor performance of LC 7?

Andrew Kluthe wrote:

> I totally understand what you're talking about there, but between
> a full time gig, very young children, and freelance work at night.
> I just don't know where I'd find the time to be effective at giving
> them the level of detail that they need.

I hear you.  The only reason I'm in a position to volunteer as much time 
as I do is because I have a responsibility to my company and those of my 
clients, which are dependent on LC as the foundation of their product lines.

But LC is useful for a great many different workflows, and not all of 
them are as invested in it as the ones I help steward, so it's nice when 
folks have the time to submit reports but fully understandable if they 
don't.

> In short, the request for us to invest this much time in helping them
> figure it out is almost as stressful as the actual problems.
>
> The Us (community) vs Them (RunRev) that persists is the result that
> most of the people started using this software when it was still
> proprietary. It's a big step for many of us to transition to.

I've seen this dynamic before, and I believe it has less to do with dual 
licensing than the nature of development tools themselves.

I served on the advisory boards for Oracle Media Objects, Allegiant 
SuperCard, and Gain Momentum, and with each the relationship between the 
vendor and the community was in various ways challenging on both sides.

We had many long meetings between the Gain team, a team from Irix, and 
my client, just to try to get robust video playback, and ultimately 
someone one my client's team had to write custom C code to pull it off.

A number of critical features SuperCard developers relied on weren't in 
the engine at all but provided through externals, a good many of which 
were written by a team member in his spare time.  This meant funky 
syntax and design compromises, but they got us through the day well 
enough to move on to other challenges.

With quality, all of them faced a daunting task that's quite literally 
orders of magnitude beyond the scope of testing requirements for 
anything we build with these tools:

In the apps we make with xTalks, we use a subset of the language in very 
specific ways that constrain the range of possibilities the users will 
encounter.

But in the xTalk engines themselves, rather than providing "features" in 
the consumer software sense, they deliver thousands of tokens that can 
be combined and recombined in a combinatorial explosion of possibilities.

Of all the xTalks, the only one that came close to the scope of 
automated testing the LC team uses was HyperCard, but theirs was much 
more limited (and of course stopped being enhanced when the toolkit died 
20 years ago).

But since the range of possible combinations is large enough to be 
reasonably considered close to infinite, the scope of any automated 
testing can only accommodate a slender minority of all possible 
combinations.

They add to it as bugs are encountered, but given the nature of the task 
it can never be a replacement for live testing in the wild.  No 
automated test suite can be, for any product, which is why all software, 
from simple consumer apps to operating systems, rely on outside Beta 
testers as a critical component of quality assurance.

And despite everyone's best efforts, all software always has bugs, 
according to McConnel's research at the rate of about 15 to 20 per KLOC.

> I'm sorry to say v7 is not a production quality toolset for those
> without tons of extra time on their hands.
> As a result, I have done no new development that wasn't a one off
> utility for something simple in livecode since it went open source.
> I'm too afraid to lose my lunch (or for users to lose theirs) to
> these issues.

Which issues in the RQCC are yours?  I'd be happy to take some time to 
review them to see if they can be bumped up in the queue.

> When one of my livecode apps needs an overhaul, I've been selecting
> other tools/technologies to rewrite it in because of how long all
> of this has been building up to and in the works.

I had considered a similar move myself for many years before LC went 
open source, since no developer tool has a chance of being taken 
seriously in the 21st century without at least an open source option.

But I've been unable to find any for which the cost of a complete 
rewrite is lower than the much cost of seeing a couple bugs fixed.

What language are you migrating your code to?

> It seems like lately there has been this big move to say "Well,
> there isn't actually a problem. People just aren't pitching in
> to help us like they should."

I've heard sentiments like that from the community but not from anyone 
at RunRev, which is among the reasons I try to skim past vague 
complaints to focus on specific actionable issues, trying to sort 
through the noise to find the signal.

I'll be the first to say LiveCode is a FUBAR project, every bit as much 
as every xTalk before it,

Re: How do you handle the poor performance of LC 7?

Of note, the only things wrong with the prototypes we did were that the
reports (pulling large amounts of data from a server, processing it,
generating html reports and outputting it) were noticeably slower (not like
what is often reported on this list, but slow enough for someone to notice
its slower). To be fair, they were fairly complex reports and they should
probably be offloaded to a reporting server that can process them in a
queue at its own pace. Which is what we did. To be fair, this new reporting
process was even slower than the slowness introduced by upgrading to newer
versions.

These issues are just the breaks with the engine changes. I get that you
guys are optimizing things, but by design, the entire thing is just
inherently a wee bit slower to your own admission. This wasn't good enough
for those who made the decision to pull the plug.  Basically, after
following along for the last few years my boss now considers LC to be good
for really robust prototypes at this point but would never let me do
another project that affects our production lines in LC, regardless of how
many things have been shot into space running livecode.

On Fri, May 29, 2015 at 2:50 PM Andrew Kluthe  wrote:

> Not a bad option for some, then. Unfortunately, decisions like that on the
> software in question are over my head. They have decided they would rather
> I just do it in something more mainstream, than spend time in that way. I
> fought tooth and nail to get permission to do it in livecode. It works, it
> still works. We'd been using it for close to 5 years and dealing with some
> small gotchas. People above me at the company I work for donated to the
> kickstarter and were as excited as the rest of us at the possibilities the
> future of livecode introduced. They have been watching new releases roll
> out and wanting to move forward on big improvements and the new features.
>
> We gave it a shot with some prototypes with the newer versions. My
> superiors were tired of waiting/dealing with it and decided to pull the
> plug on livecode. The decision was made to re-write most of it for .NET
> (some if it on my own dime) to compensate for that risk going ahead.
>
> Livcode will still be great again. I'll probably use it for freelance work
> at some point in the future, but around here. It's just not an option the
> company wishes to pursue any further.
>
>
> On Fri, May 29, 2015 at 2:28 PM Peter TB Brett 
> wrote:
>
>> On 2015-05-29 21:12, Andrew Kluthe wrote:
>> > Thanks for the reply, Richard.
>> >
>> > I totally understand what you're talking about there, but between a
>> > full
>> > time gig, very young children, and freelance work at night. I just
>> > don't
>> > know where I'd find the time to be effective at giving them the level
>> > of
>> > detail that they need. I can't give them the actual software that's
>> > suffered from these issues as it's all under NDA.
>>
>> Hi Andrew,
>>
>> Note that we are able to enter a NDA if that's necessary!  Please
>> contact support for more information.
>>
>>  Peter
>>
>> --
>> Dr Peter Brett 
>> LiveCode Engine Development Team
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How do you handle the poor performance of LC 7?

Not a bad option for some, then. Unfortunately, decisions like that on the
software in question are over my head. They have decided they would rather
I just do it in something more mainstream, than spend time in that way. I
fought tooth and nail to get permission to do it in livecode. It works, it
still works. We'd been using it for close to 5 years and dealing with some
small gotchas. People above me at the company I work for donated to the
kickstarter and were as excited as the rest of us at the possibilities the
future of livecode introduced. They have been watching new releases roll
out and wanting to move forward on big improvements and the new features.

We gave it a shot with some prototypes with the newer versions. My
superiors were tired of waiting/dealing with it and decided to pull the
plug on livecode. The decision was made to re-write most of it for .NET
(some if it on my own dime) to compensate for that risk going ahead.

Livcode will still be great again. I'll probably use it for freelance work
at some point in the future, but around here. It's just not an option the
company wishes to pursue any further.

On Fri, May 29, 2015 at 2:28 PM Peter TB Brett 
wrote:

> On 2015-05-29 21:12, Andrew Kluthe wrote:
> > Thanks for the reply, Richard.
> >
> > I totally understand what you're talking about there, but between a
> > full
> > time gig, very young children, and freelance work at night. I just
> > don't
> > know where I'd find the time to be effective at giving them the level
> > of
> > detail that they need. I can't give them the actual software that's
> > suffered from these issues as it's all under NDA.
>
> Hi Andrew,
>
> Note that we are able to enter a NDA if that's necessary!  Please
> contact support for more information.
>
>  Peter
>
> --
> Dr Peter Brett 
> LiveCode Engine Development Team
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Peter TB Brett


On 2015-05-29 21:12, Andrew Kluthe wrote:

Thanks for the reply, Richard.

I totally understand what you're talking about there, but between a 
full
time gig, very young children, and freelance work at night. I just 
don't
know where I'd find the time to be effective at giving them the level 
of

detail that they need. I can't give them the actual software that's
suffered from these issues as it's all under NDA.


Hi Andrew,

Note that we are able to enter a NDA if that's necessary!  Please 
contact support for more information.


Peter

--
Dr Peter Brett 
LiveCode Engine Development Team


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

Re: How do you handle the poor performance of LC 7?

Thanks for the reply, Richard.

I totally understand what you're talking about there, but between a full
time gig, very young children, and freelance work at night. I just don't
know where I'd find the time to be effective at giving them the level of
detail that they need. I can't give them the actual software that's
suffered from these issues as it's all under NDA. I don't really have time
to hunt down the root of the problem, recreate code to explain it, create a
data set they can refer to for testing it, wait for it to be analyzed, wait
for it to be implemented, and try again.

Sure, I would love if the users of my software would all sit down and try
to help me pinpoint regressions, bugs in new features, etc. I would want
well thought out, reproducible issues with good data to try them against.
Reality is, they are all also busy trying to use said software to do their
increasingly strenuous day jobs (of which the software is supposedly there
to make it easier). That's just something I have to understand as a someone
who writes software for users. It would be nice, it would make things go
smoothly, it's a good goal to reach for in educating users, but it's not
exactly as easy as that.

It's not really an excuse to sit back and wait for someone else to find out
the bugs as it is the hard reality of some people's situations.

In short, the request for us to invest this much time in helping them
figure it out is almost as stressful as the actual problems.

The Us (community) vs Them (RunRev) that persists is the result that most
of the people started using this software when it was still proprietary.
It's a big step for many of us to transition to. Particularly, if we came
to runrev/livecode to save us on development/prototyping time. Our
community used to be so sure of the praises of livecode. It really was and
will again sometime be a fantastic product. But I'm sorry to say v7 is not
a production quality toolset for those without tons of extra time on their
hands.

As a result, I have done no new development that wasn't a one off utility
for something simple in livecode since it went open source. I'm too afraid
to lose my lunch (or for users to lose theirs) to these issues. When one of
my livecode apps needs an overhaul, I've been selecting other
tools/technologies to rewrite it in because of how long all of this has
been building up to and in the works.

Things will get better. I know that. It will take some time. I get that.
I'm more or less fine with things taking longer to smooth out. But I won't
recommend that someone else spend their time on it, if they don't have time
to spend.

It seems like lately there has been this big move to say "Well, there isn't
actually a problem. People just aren't pitching in to help us like they
should." I don't think this line is entirely realistic for all in our
somewhat small community. Some of us are just going to have to wait until
LC is a realistic production-worthy option for us again, and I'm looking
forward to it after the 8 previews. I think this is mostly because
regardless of speed, 8 will have enough new (and relevant) features to make
it worth the hassle of trying to work with.

On Fri, May 29, 2015 at 12:36 PM Richard Gaskin 
wrote:

> Andrew Kluthe wrote:
>
>  > I guess I've just been hanging back from upgrading the important
>  > stuff until I stop seeing emails like these on the list.
>
> There is some performance degradation with v7, but improved in recent
> builds and often the difference may be measurable but not noticeable.
>
> There's an option with File -> Save As in LiveCode to pick any file
> format supported over the last decade.  Once chosen, any use of File ->
> Save will continue to use that format, so you can work on things moving
> between 6.7 and 7.0 without penalty.
>
> Of course backups are helpful, but less for LiveCode than any other
> reason all of us make multiple redundant backups nightly (earthquakes,
> disk failure, etc.).
>
> Given the scope of changes between 6.x and 7.x, relying on hearsay is
> problematic for two reasons:
>
> 1. The specific areas in which other people are seeing performance
> degradation may not be the same your app will experience.  Yours may be
> fine, or it may expose something more critical and well worth
> identifying, but if we don't identify it it can't be fixed.
>
> 2. To be frank, the number of posts here about issues in v7 is a
> multiple of the number of actual issues, with a relatively small number
> of issues cited over and over, often requiring nudging or direct
> assistance to turn those concerns into actionable bug reports.
>
> True, multiple changes in the iOS SDK have required the team to postpone
> issues for other platforms to rush out yet another 7.0.x build to
> address Apple's changes du jour, and this has meant many things we need
> for other platforms have remained outstanding longer than anyone,
> including the dev team, would prefer.
>
> In my meeting with Ben yesterday we spent t

Re: How do you handle the poor performance of LC 7?


Tiemo Hollmann wrote:

> Testing my stacks in LC 7.0.5 , they show such a poor performance.
> E.g. plain repeat loops with 20,000 records which take a fraction
> of a second in LC 6, last up to 10 seconds in LC 7, which is more
> than unacceptable for me / my clients on old poor machines.

Can you post the code for that loop, and tell us a bit about the data it 
works on?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Dr. Hawkins

On Fri, May 29, 2015 at 9:29 AM, Mark Waddingham  wrote:

> The important thing here (which reinforces me saying 'real world
> scenarios' are important) is that if my goal was to optimise the engine to
> make simpleArrayTest fast then I could. Indeed, it would be possible to
> make it take virtually no time at all since it isn't actually doing
> anything - the subtlety of missing out the key step of what the (numeric)
> keys are being sorted by completely changes the intent of the code.
> There-in lies the danger with synthetic tests.


Several years ago (ok, it's really decades), Byte had a standard test suite
to compare compilers.

Then they hit a compiler that recognized nothing was done with the
information, and optimized the entire suite out . . . produced something
that executed in 0 . . .


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

Re: How do you handle the poor performance of LC 7?

Andrew Kluthe wrote:

> I guess I've just been hanging back from upgrading the important
> stuff until I stop seeing emails like these on the list.

There is some performance degradation with v7, but improved in recent 
builds and often the difference may be measurable but not noticeable.

There's an option with File -> Save As in LiveCode to pick any file 
format supported over the last decade.  Once chosen, any use of File -> 
Save will continue to use that format, so you can work on things moving 
between 6.7 and 7.0 without penalty.

Of course backups are helpful, but less for LiveCode than any other 
reason all of us make multiple redundant backups nightly (earthquakes, 
disk failure, etc.).

Given the scope of changes between 6.x and 7.x, relying on hearsay is 
problematic for two reasons:

1. The specific areas in which other people are seeing performance 
degradation may not be the same your app will experience.  Yours may be 
fine, or it may expose something more critical and well worth 
identifying, but if we don't identify it it can't be fixed.

2. To be frank, the number of posts here about issues in v7 is a 
multiple of the number of actual issues, with a relatively small number 
of issues cited over and over, often requiring nudging or direct 
assistance to turn those concerns into actionable bug reports.

True, multiple changes in the iOS SDK have required the team to postpone 
issues for other platforms to rush out yet another 7.0.x build to 
address Apple's changes du jour, and this has meant many things we need 
for other platforms have remained outstanding longer than anyone, 
including the dev team, would prefer.

In my meeting with Ben yesterday we spent the bulk of our time 
discussing community concerns about quality and performance in v7.  One 
of the challenges the team faces is the signal-to-noise ratio, in which 
vague comments like "7 is just broken!" aren't actionable and therefore 
even if well-intended are ultimately confusing if it doesn't produce a 
bug report.

6.x may be maintained for now, but its days are numbered.  It represents 
an expense to the project that would benefit all of us if the dev team 
weren't saddled with.

8.0 is the future, but that future rests on the foundation of v7.

7.0.x is the present.  It includes the largest number of fixes and 
enhancements, it's the core that v8 depends on, and it's what the 
company's revenue depends on now and for many months ahead.

It's also what we in the community depend on for our own work, so let's 
pull together and identify specific actionable issues and make sure 
they're in the bug DB so they can be addressed.

I'll continue to do my best as time permits to help triage and steward 
reports as they come in.

--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.com

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

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Mark Wieder

Tiemo Hollmann TB  writes:

> How do you handle this performance issue in your projects?

What works for me is building a 64-bit 6.7x engine from source.
The only time I venture into LC7 land is to check compatibility.
Otherwise it's too unstable, slow, and buggy for me to work with.
And creates huge standalone apps.

-- 
 Mark Wieder
 ahsoftw...@gmail.com



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

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Mark Waddingham


(once more, it took my quad core i5 ten or fifteen minutes to build a
standalone yesterday).


Do you have 'search for required inclusions' turned on?

If so - try turning it off and see if you get a performance improvement.

Not knowing the structure of the app you are trying to build I can't say 
that it will help - just that if it is large, then searching for 
required inclusions is a linear process it does every time and so can be 
a cause of slow-down when building standalones.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Mark Waddingham


Bad thing was that the team wanted to see „real live scenarios“ (which
most of my benchmark stacks are, just boiled down to the core of the
problems as I found them).


Yes - 'real world scenarios' are important - posting a small piece of 
code and running it 10,000 times just tells you how long that piece of 
code takes to run. It doesn't tell you the context, the purpose or 
(indeed) whether it is *useful* for it to run exceptionally fast (the 
real world reality is that optimisation is time consuming and difficult 
so you want to be absolutely sure the work is of actual benefit before 
you undertake it). (More importantly, out of context, it is not possible 
to see whether the code is necessary at all - there might be that it 
could be done in a far more efficient way by stepping back one level and 
changing approach; and *that* completely changes the equation).


Anyway, I would point out that the forum post which was pointed out is 
actually quite stale. I did a significant amount of analysis of the 
'simpleArrayTest' code and posted my findings on a different thread 
(which, indeed, might well have been an error on my part!). The relevant 
posts are:


http://forums.livecode.com/viewtopic.php?f=66&t=23387#p121566
http://forums.livecode.com/viewtopic.php?f=66&t=23387#p121574
http://forums.livecode.com/viewtopic.php?f=66&t=23387#p121605

The important thing here (which reinforces me saying 'real world 
scenarios' are important) is that if my goal was to optimise the engine 
to make simpleArrayTest fast then I could. Indeed, it would be possible 
to make it take virtually no time at all since it isn't actually doing 
anything - the subtlety of missing out the key step of what the 
(numeric) keys are being sorted by completely changes the intent of the 
code. There-in lies the danger with synthetic tests.


So, anyway, I'm posting this for two reasons.

The first is to reinforce the fact that distilled real world examples 
with real world data and real world context (i.e. what the code is 
trying to achieve) are important as it ensures we can choose were we 
spend our energy wisely.


The second is to say please do help us find out what the most important 
places to optimise are. If you have tight loops which do data-processing 
in your apps *and* you are finding them significantly slower, let us 
know, work with us to distill them down into an easily runnable snippet 
of code with good data to run them on so we can take the time to analyse 
them and influence where the optimisation really needs to be.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

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

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Dr. Hawkins

On Fri, May 29, 2015 at 8:27 AM, Andrew Kluthe  wrote:

> As a personal rule of thumb, I don't use anything post-6.x.x for anything
> but trying out the bleeding edge features.

I have no choice; I absolutely need the adjustable scaling on the desktop.

So I deal with performance by a lot of screaming and cussing at the machine
. . .

(once more, it took my quad core i5 ten or fifteen minutes to build a
standalone yesterday).

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

Re: How do you handle the poor performance of LC 7?

2015-05-29 Thread Malte Brill

I set up a couple of benchmark stacks a while back:

http://forums.livecode.com/viewtopic.php?f=67&t=22072 


Bad thing was that the team wanted to see „real live scenarios“ (which most of 
my benchmark stacks are, just boiled down to the core of the problems as I 
found them). I was able to fly over to Edinburgh and discuss many of the 
problematic areas with the team. I guess the more „real live“ scenarios they 
see, the better as it might help find optimisations. Until the speed issues are 
resolved I am stuck with 6.7 for productive work, which is a shame because for 
one project I would urgently need to be able to support arabic RTL input. But I 
guess the old rule applies: First you make it work, then you make it fast. 
Impatiently waiting for the latter. :-)

Best,

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

Re: How do you handle the poor performance of LC 7?