Re: LC Garbage Collection?

I think "large" is dependent on context. I've used LSON files larger than 100 MB, but I don't know that I would recommend that for all possible use cases. The bug DB link in this post suggests that size of a given array isn't necessarily a problem or not a problem, it all depends on what spe

Re: LC Garbage Collection?

Do we have a ballpark idea of what "large" might be? Is it more like a gigabyte or a few hundred megabytes or...? I know it will be variable and depend on other factors, but it would be nice to have a general idea. On 9/26/19 11:12 PM, Dar Scott Consulting via use-livecode wrote: I don't think

Re: LC Garbage Collection?

I don't think that is large. If you are processing data the same size and somehow leaving the previous data around, that might build up. That might build up in queues and stacks, in a message storm and in appended data. But, I am guessing that that is not likely. > On Sep 26, 2019, at 1:54 PM,

Re: LC Garbage Collection?

Tom Glod wrote: > Hi folks, I'm wondering if anyone can help me to understand > Livecode's garbage collection. I am developing an application that > is intended to stay in memory and so I must watch memory consumption > carefully. I've had some instances where memo

Re: LC Garbage Collection?

2.5 mb is not big at all. please remember to test with 9.05 when worried about leaks. On Thu, Sep 26, 2019 at 3:55 PM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > On 9/24/19 2:39 PM, Dar Scott Consulting via use-livecode wrote: > > Sources of memory leaks are LC,

Re: LC Garbage Collection?

On 9/24/19 2:39 PM, Dar Scott Consulting via use-livecode wrote: Sources of memory leaks are LC, LC scripts, OS, libraries, LCB and (I suppose) compilers. I don't think we can assume the problem is not in the user script. I have seen script memory leaks like these: 1. Leaving large data in scri

Re: LC Garbage Collection?

in > the > >> user script. I have seen script memory leaks like these: > >> 1. Leaving large data in script locals > >> 2. Indefinite log variables > >> 3. Poor range checking in recursive functions > >> 4. mouseUp recursion* > >> 5. Queue/stack bugs

Re: LC Garbage Collection?

t;> 4. mouseUp recursion* >> 5. Queue/stack bugs >> 6. Bad parsing >> >> *GUI recursion is a root of all kinds of evil. If tempted, leave your >> cloak and run. >> >> Dar Scott >> Mad Scientist >> >>> On Sep 24, 2019, at 12:36 PM,

Re: LC Garbage Collection?

ad parsing > > *GUI recursion is a root of all kinds of evil. If tempted, leave your > cloak and run. > > Dar Scott > Mad Scientist > > > On Sep 24, 2019, at 12:36 PM, Tom Glod via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Hi folks,

Re: LC Garbage Collection?

cloak and run. Dar Scott Mad Scientist > On Sep 24, 2019, at 12:36 PM, Tom Glod via use-livecode > wrote: > > Hi folks, I'm wondering if anyone can help me to understand Livecode's > garbage collection. I am developing an application that is intended to > stay

Re: LC Garbage Collection?

LC 9.0.5 closed at about 42 memory leaks ... ___ 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

LC Garbage Collection?

Hi folks, I'm wondering if anyone can help me to understand Livecode's garbage collection. I am developing an application that is intended to stay in memory and so I must watch memory consumption carefully. I've had some instances where memory ran way out of control but I fo

Re: Garbage collection (crashing on Windows)

rely you still need to do some kind of garbage collection in order to collapse what may be isolated fragments of 'free' memory? When a value is no longer referenced, the area(s) of memory occupied by it are returned to the heap for future allocation. Note that LiveCode relies on the stan

Re: Garbage collection (crashing on Windows)

LiveCode doesn't use what is generally referred to as 'garbage collection' as it generally frees 'things' up as soon as they are no longer referenced. But does 'freed' literally release the memory, or just mark the object as available? Surely you still need to

Re: Garbage collection (crashing on Windows)

> On 21 Aug 2016, at 2:33 AM, Dr. Hawkins wrote: > > In that case, what are the several second pauses in the IDE, particularly > the editor (versions 5 & 7, maybe others) Do you happen to have bug report numbers for these pauses because they can probably be fixed? I’ve recently done some work

Re: Garbage collection (crashing on Windows)

> >> On Fri, Aug 19, 2016 at 10:42 AM, Mark Waddingham wrote: >> >> LiveCode doesn't use what is generally referred to as 'garbage collection' >> as it generally frees 'things' up as soon as they are no longer referenced. > > > In th

Re: Garbage collection (crashing on Windows)

On Fri, Aug 19, 2016 at 10:42 AM, Mark Waddingham wrote: > LiveCode doesn't use what is generally referred to as 'garbage collection' > as it generally frees 'things' up as soon as they are no longer referenced. In that case, what are the several second paus

Re: Garbage collection (crashing on Windows)

On Thu, Aug 18, 2016 at 11:09 AM, Jeanne A. E. DeVoto < revolut...@jaedworks.com> wrote: > I've had ugly crashes with large or complex arrays (that weren't anywhere > near the 4G limit). It's not just LiveCode where I trip over obscure bugs . . That's actually how I found met buy in Cray's Fort

Re: Garbage collection (crashing on Windows)

Split would works for simple data sets. This made up example would support split just fine. > On Aug 19, 2016, at 8:29 PM, Monte Goulding wrote: > > Mark you could use the split command here if you don’t mind numerically > indexed arrays. > >> On 20 Aug 2016, at 9:07 AM, Mark Talluto wrote:

Re: Garbage collection (crashing on Windows)

Ah! Using repeat for each key is essentially using the keys of an array as a 'proper list' - it is probably the fastest way currently to iterate over a sequence of strings. In this case the value of each element in that array is immaterial - so the performance benefit comes iterating over the k

Re: Garbage collection (crashing on Windows)

Mark you could use the split command here if you don’t mind numerically indexed arrays. > On 20 Aug 2016, at 9:07 AM, Mark Talluto wrote: > > command createArray > local tListOfRecordIDs, tTableID > > put fld "recordID data" into tListOfRecordIDs > put uuid() into tTableID > >

Re: Garbage collection (crashing on Windows)

I do not remember how much of a performance boost we got from manipulating long lists this way, but if memory serves, it was quite beneficial. This code sample is just something I made up on the fly. Hopefully it demonstrates the value of this method. command createArray local tListOfRecord

Re: Garbage collection (crashing on Windows)

Ah, the wonders of paged memory. - -- Mark Wieder ahsoftw...@gmail.com -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Garbage-collection-crashing-on-Windows-tp4707560p4707624.html Sent from the Revolution - User mailing list archive at Nabble.com

Re: Garbage collection (crashing on Windows)

With the current implementation of the engine, the only reason using empty is faster than using pValue is because the latter requires a variable lookup, the former is a constant. What are you using sValueCache for? Sent from my iPhone > On 19 Aug 2016, at 19:37, Mark Talluto wrote: > > >> O

Re: Garbage collection (crashing on Windows)

> On Aug 19, 2016, at 10:42 AM, Mark Waddingham wrote: > > command shareAndStoreKey @xArray, pKey, pValue > set the caseSensitive to true -- this is assuming your values are > sensitive to case > if pValue is not among the keys of sValueCache then > put pValue into sValueCache[p

Re: Garbage collection (crashing on Windows)

Please refresh my memory: is there any way to cause/allow garbage to be collected without ending all script running? LiveCode doesn't use what is generally referred to as 'garbage collection' as it generally frees 'things' up as soon as they are no longer referen

Re: Garbage collection (crashing on Windows)

issed this.) Every version from 2.4 to 8.1! One problem of course is that over this long my memory fades - checking the script I see that it has a number of instances of wait for 1 second with messages -- theory that this might improve garbage collection which is why I thought I'd e

Re: Garbage collection (crashing on Windows)

At 3:28 PM +0100 8/18/2016, Ben Rubinstein wrote: The real problem is that the script was written originally 13 years ago, and the basic architecture was to load everything into large global arrays for cleanliness. I've had ugly crashes with large or complex arrays (that weren't anywhere nea

Re: Garbage collection (crashing on Windows)

Ben Rubinstein wrote: > The real problem is that the script was written originally 13 years > ago, and the basic architecture was to load everything into large > global arrays for cleanliness. Over that period, the size of the data > has multiplied over the years by 1-2 orders of magnitude J

Re: Garbage collection (crashing on Windows)

hes 2GB, the app faults. >>>> >>>> Obviously this is very distressing for me and my client, because the >>>> app has lost control at this point and can't even tell us what's happening >>>> (it normally runs on a schedule on a VM, so it oft

Re: Garbage collection (crashing on Windows)

ssing for me and my client, because the app >>> has lost control at this point and can't even tell us what's happening (it >>> normally runs on a schedule on a VM, so it often takes days to discover >>> that the system downstream hasn't been updated for a w

Re: Garbage collection (crashing on Windows)

anaged to reduce the incidence of this by breaking the processing into two parts, but this is undesirable for various reasons, and only palliative. What I really want is a way for my main function to invoke garbage collection after calling some of the larger processing steps. Is there any way to

Re: Garbage collection (crashing on Windows)

liative. What I really want is a way for my main function to invoke garbage collection after calling some of the larger processing steps. Is there any way to do this? Am I right in thinking that the issue is related to LC's total memory usage reaching 2GB on Windows? Are there any useful functions

Re: Garbage collection (crashing on Windows)

been updated for a while, and trace back to find > that the LC app is halted). > > I have managed to reduce the incidence of this by breaking the processing > into two parts, but this is undesirable for various reasons, and only > palliative. What I really want is a way for my

Garbage collection (crashing on Windows)

really want is a way for my main function to invoke garbage collection after calling some of the larger processing steps. Is there any way to do this? Am I right in thinking that the issue is related to LC's total memory usage reaching 2GB on Windows? Are there any useful functions

Re: garbage collection run amok again in 7.1.1Rc2?

For me, they were actually disappearing. Dropped into the void. On Fri, Nov 6, 2015 at 11:41 AM, Bob Sneidar wrote: > I have seen times where saving a stack took an excessively long time to > finish. I assumed that LC was doing some kind of high priority > housekeeping. I have been using 6.7.6

Re: garbage collection run amok again in 7.1.1Rc2?

I have seen times where saving a stack took an excessively long time to finish. I assumed that LC was doing some kind of high priority housekeeping. I have been using 6.7.6 since it came out. Bob S On Nov 6, 2015, at 10:24 , Dr. Hawkins mailto:doch...@gmail.com>> wrote: On Fri, Nov 6, 2015 a

Re: garbage collection run amok again in 7.1.1Rc2?

On Fri, Nov 6, 2015 at 8:53 AM, Mike Bonner wrote: > I've seen similar, to the point where keystrokes are dropped in the script > editor, and I must type RELY slow to get things going. > at times when I assumed that that had happened, the keystrokes eventually showed up . . . -- Dr. Rich

Re: garbage collection run amok again in 7.1.1Rc2?

I've seen similar, to the point where keystrokes are dropped in the script editor, and I must type RELY slow to get things going. Unfortunately, while it happens often enough to notice, I haven't managed to nail down a recipe. Sometimes it goes away when I shut the dictionary, other times I t

Re: garbage collection run amok again in 7.1.1Rc2?

On Thu, Nov 5, 2015 at 3:29 PM, Ali Lloyd wrote: > I have actually seen this myself once whilst running in debug mode from > source, and I think it was stuck in a 'TryToEvaluate' loop for some reason > - I think it can be stopped by doing Cmd + . although that might not be the > same thing. > To

Re: garbage collection run amok again in 7.1.1Rc2?

I am always in for this. gc gc > On Nov 5, 2015, at 4:01 PM, J. Landman Gay wrote: > > It would be an interesting challenge if Richard could supply a sample of a > long handler and see if we could reduce it. ___ use-livecode mailing list use-livec

Re: garbage collection run amok again in 7.1.1Rc2?

I have actually seen this myself once whilst running in debug mode from source, and I think it was stuck in a 'TryToEvaluate' loop for some reason - I think it can be stopped by doing Cmd + . although that might not be the same thing. Anyway, It's worth filing a bug report if there isn't one alrea

Re: garbage collection run amok again in 7.1.1Rc2?

On Thu, Nov 5, 2015 at 1:01 PM, J. Landman Gay wrote: > I think he probably meant "script" rather than "handler." But even my most > complex project wasn't that long. (If it really is a single handler then it > isn't written correctly.) When I see numbers like that, my first thought is > "optimiz

Re: garbage collection run amok again in 7.1.1Rc2?

in it in total... Date: Thu, 5 Nov 2015 09:04:46 -0800 Subject: garbage collection run amok again in 7.1.1Rc2? From: doch...@gmail.com To: use-livecode@lists.runrev.com I am seeing the *long*, as in several seconds, delays again when making changes in long (10k+ line) handlers. A minor edit,

RE: garbage collection run amok again in 7.1.1Rc2?

10,000 lines in one liveCode handler ?... really !?... I don't think, .. no, I know that I have never written a stack that has 10,000 lines in it in total... > Date: Thu, 5 Nov 2015 09:04:46 -0800 > Subject: garbage collection run amok again in 7.1.1Rc2? > From: doch...@gmail

Re: garbage collection run amok again in 7.1.1Rc2?

I was under the impression that very long scripts take some time to compile. If this has been addressed and this was no longer the case, I am very surprised and curious how they managed that. It would mean that scripts are now indexed somehow so only the relevant parts of the scripts are recompi

garbage collection run amok again in 7.1.1Rc2?

I am seeing the *long*, as in several seconds, delays again when making changes in long (10k+ line) handlers. A minor edit, and off to la-la land. Are others being this? -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-

Re: Garbage Collection

Thanks Terry > On 22 Feb 2015, at 12:00, Fraser Gordon wrote: > > So, to answer your question, it doesn't look like it should impact > LiveCode at all. The one place it may have an effect is if a third-party > extension uses these technologies. ___ u

Re: Garbage Collection

ac-app-makers-must-transition-to-arc-memory-management-by-may> Garbage Collection and ARC are features of the Apple Objective-C compilers used to make a number of memory management operations simpler for software developers. LiveCode does its own memory management and uses neither of these technologies.

Garbage Collection

How does this impact LiveCode? http://iphone.appleinsider.com/articles/15/02/20/apple-says-mac-app-makers-must-transition-to-arc-memory-management-by-may All the best

Re: Garbage Collection/Old Data in stack

On Sun, Jan 18, 2015 at 10:50 AM, Ralph DiMola wrote: > Peter, > Is listing these is an enhancement for lcStackBrowser? > It's already there. If you right click a card in the display, there's an option to place a group with subitems that show the available unplaced groups noted as "(Unlinked)"

RE: Garbage Collection/Old Data in stack

January 18, 2015 1:21 PM To: How to use LiveCode Subject: Re: Garbage Collection/Old Data in stack Aha, that makes sense! Thank you, Scott. Cheers, Roger > On Jan 18, 2015, at 11:13 AM, Scott Rossi wrote: > > I have to ask . . . how does one end up with unplaced groups? > > Onc

Re: Garbage Collection/Old Data in stack

Aha, that makes sense! Thank you, Scott. Cheers, Roger > On Jan 18, 2015, at 11:13 AM, Scott Rossi wrote: > > I have to ask . . . how does one end up with unplaced groups? > > Once a group has been placed on a card and is then removed from all cards on > which it appeared, it is unplaced.

Re: Garbage Collection/Old Data in stack

I have to ask . . . how does one end up with unplaced groups? Once a group has been placed on a card and is then removed from all cards on which it appeared, it is unplaced. The group remains in the stack so it can be used again. Regards, Scott Rossi Creative Director Tactile Media, UX/UI

Re: Garbage Collection/Old Data in stack

Just tried the following script in a button in your Test3 stack file: on mouseUp get the revUnplacedGroupIDs of stack "GolfDay FL" repeat for each line rID in it delete group id rID of stack "GolfDay FL" end repeat end mouseUp The saved the stack. It's now 9kbytes in size. Pete

Re: Garbage Collection/Old Data in stack

Hi Ralph, There's an undocumented property of a stack named revUnplacedGroupIDs. See what it shows for your stack You should be able to repeat through the lines in that property and delete the group ids listed in it. Pete lcSQL Software Home of lcStackBrowser

Re: Garbage Collection/Old Data in stack

I have to ask . . . how does one end up with unplaced groups? Cheers, Roger > On Jan 18, 2015, at 9:19 AM, Scott Rossi wrote: > > There isn’t any list of unplaced groups. The reason I was able to tell the > groups were not placed is because all visible objects had been removed from > the sa

Re: Garbage Collection/Old Data in stack

There isn’t any list of unplaced groups. The reason I was able to tell the groups were not placed is because all visible objects had been removed from the sample stack. There Go to the Object menu under Place Group to see groups that can be placed on the current card. Anything in the list th

Re: Garbage Collection/Old Data in stack

Look at item “place groups” in object menu (and to delete groups, don’t use “remove group” but place the group somewhere, select it and edit -> clear). > Le 18 janv. 2015 à 16:19, Dr. Hawkins a écrit : > > On Sat, Jan 17, 2015 at 10:06 PM, Scott Rossi > wrote: > >> You have 20+ unplaced group

Re: Garbage Collection/Old Data in stack

On Sat, Jan 17, 2015 at 10:06 PM, Scott Rossi wrote: > You have 20+ unplaced groups present in the stack, many of which contain > images, which is why you have 2+ MB in file size. OK, how do we find unplaced objects? I think I have a few megs in my main project. -- Dr. Richard E. Hawkins, E

Re: Garbage Collection/Old Data in stack

Thanks for posting the stack, Ralph. I love a good mystery. There are unplaced background there: Exit BottomBarG NavScreen1GroupC NavScreen1GroupD NavScreen1GroupE MenuGrp NavScreen1GroupA NavScreen1GroupB LogoG1 BG2G BG3G BG6G BG4G Browser BG5G Back NextG Picker Picker EmailNote -- Richard G

Re: Garbage Collection/Old Data in stack

You have 20+ unplaced groups present in the stack, many of which contain images, which is why you have 2+ MB in file size. Not sure if there’s a programmatic way to remove them, but if you place each one and then delete it, you’ll eventually remove them from the stack. Regards, Scott Rossi Cr

RE: Garbage Collection/Old Data in stack

There are no objects except for the 1 blank card. I wonder how many other stacks out there are experiencing this creep of orphan object/properties. I just happen to find them because I did not want to redo all my standalone setting for mobile splash pages when creating a stub stack. I just deleted

Re: Garbage Collection/Old Data in stack

On Sat, Jan 17, 2015 at 3:27 PM, Richard Gaskin wrote: > These orphaned images are making my standalones larger than they should be. >> This is more of a problem for mobile than desktop. I guess it's time for a >> Bug Report. >> > > Maybe. Any unplaced backgrounds in the stack file? > > Did you

Re: Garbage Collection/Old Data in stack

Ralph DiMola wrote: Thank for all the suggestions. Compact did nothing. The properties and images are from long gone cards. They were not rev stack properties. Other properties are for fields and buttons that were on the deleted cards. This stack now has one empty card and it is 2MB. I know I cou

RE: Garbage Collection/Old Data in stack

rdim...@evergreeninfo.net Phone: 518-636-3998 Ex:11 Cell: 518-796-9332 -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Mark Wieder Sent: Saturday, January 17, 2015 3:40 PM To: How to use LiveCode Subject: Re: Garbage Collection/Old Data in

Re: Garbage Collection/Old Data in stack

Ralph- Saturday, January 17, 2015, 11:11:40 AM, you wrote: > How can I clean up this stack? Are there other orphans in my main stack and > other stacks that I don't know about? Am I missing something here or is > there some stack corruption that has creeped in over time? Did you try compacting t

Re: Garbage Collection/Old Data in stack

On 1/17/2015 1:11 PM, Ralph DiMola wrote: I was making a stub stack. I started with my original stack and deleted all the cards except 1. The resulting stack is 3MB. I then deleted all the scripts and objects on the remaining card and still 3MB. I Delete all the scripts from the stack and still 3

Re: Garbage Collection/Old Data in stack

On 17/01/15 21:11, Ralph DiMola wrote: I was making a stub stack. I started with my original stack and deleted all the cards except 1. The resulting stack is 3MB. I then deleted all the scripts and objects on the remaining card and still 3MB. I Delete all the scripts from the stack and still 3MB.

Garbage Collection/Old Data in stack

I was making a stub stack. I started with my original stack and deleted all the cards except 1. The resulting stack is 3MB. I then deleted all the scripts and objects on the remaining card and still 3MB. I Delete all the scripts from the stack and still 3MB. I opened that stack in a text editor and

Garbage collection in 7.0 (was Re: WindowShape)

Could be related to Bug #13126 and inadequate garbage collection in DP8. The issue has been confirmed but not yet resolved. Hugh Senior FLCo From: Paul Hibbert Crashed here too. So I opened the Activity Monitor, launched LC again, opened the stack and activated the animation, then watched

Re: Is there a serious garbage collection problem

On Sat, Jun 23, 2012 at 2:12 PM, wrote: > Don't forget about locking the screen or the recents. Oh, yes. Locking the screen made a *huge* difference in building the output (dozens upon dozens of fields being placed, moved, and filled . . .) It still takes about 15 seconds to generate 22 pag

Re: Is there a serious garbage collection problem

he other way around. Craig Newman -Original Message- From: Dr. Hawkins To: How to use LiveCode Sent: Sat, Jun 23, 2012 4:04 pm Subject: Re: Is there a serious garbage collection problem On Sat, Jun 23, 2012 at 5:27 AM, Mark Schonewille wrote: > > There might be some scripts

Re: Is there a serious garbage collection problem

On Sat, Jun 23, 2012 at 5:27 AM, Mark Schonewille wrote: > > There might be some scripts running after you delete a card. To prevent this, > lock messages before deleting the card: > > lock messages > delete card > unlock messages > > This will probably faster than whatever you're doing now. Uh,

Re: Is there a serious garbage collection problem

27;t seen anything like this for several years. > > Is there a *serious* garbage collection problem with livecode? > > When I delete cards from my output stack, the response time is > measured in seconds. For a half dozen cards, it's long enough for me > to get annoyed, and

Re: Is there a serious garbage collection problem

he PC the application was working again... On 23 Jun 2012, at 03:04, Dr. Hawkins wrote: > I haven't seen anything like this for several years. > > Is there a *serious* garbage collection problem with livecode? > > When I delete cards from my output stack, the response time

Re: Is there a serious garbage collection problem

On 6/22/12 9:04 PM, Dr. Hawkins wrote: I haven't seen anything like this for several years. Is there a *serious* garbage collection problem with livecode? When I delete cards from my output stack, the response time is measured in seconds. For a half dozen cards, it's long enough for

Is there a serious garbage collection problem

I haven't seen anything like this for several years. Is there a *serious* garbage collection problem with livecode? When I delete cards from my output stack, the response time is measured in seconds. For a half dozen cards, it's long enough for me to get annoyed, and actually laun