Build times
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Re: Build times
Just watching it closer.
The bit that is causing the delay is
'Auto detecting library inclusion'.
It sits here for 10-12 minutes sometimes.
(Other times 20 seconds).
Same stack. Same build process. Always saving the project just before. As far as I can tell, my process is always the same.
The bit that is causing the delay is
'Auto detecting library inclusion'.
It sits here for 10-12 minutes sometimes.
(Other times 20 seconds).
Same stack. Same build process. Always saving the project just before. As far as I can tell, my process is always the same.
Re: Build times
I'm sorry mvillion, when i said to look at the processes, I meant (for apple) using the "Activity Monitor" to see what was taking up resources on the system during a build although it is good to know where in the build process the slow down takes place. It really shouldn't require (I don't think) a lot to figure out the libraries when they probably are not changing.
Check the activity monitor, and see if something goofy is suddenly shooting up in resource usage when that happens.
Check the activity monitor, and see if something goofy is suddenly shooting up in resource usage when that happens.
-
- VIP Livecode Opensource Backer
- Posts: 7228
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Build times
That was my first thought, you have "search for inclusions" turned on in standalone settings. The more controls in the stack, the longer it takes while LC searches the scripts of every control. There must be some caching going on if it runs quickly sometimes, maybe it only does a new scan when new controls are added.mvillion wrote:Just watching it closer.
The bit that is causing the delay is
'Auto detecting library inclusion'.
It sits here for 10-12 minutes sometimes.
(Other times 20 seconds).
Turn off the search and set up any inclusions you need manually. I think you'll see consist build times that happen much faster.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Build times
Maybe I thunk wrong ? It happens a lot you know.
-
- VIP Livecode Opensource Backer
- Posts: 9648
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Build times
Matt.
Build times notwithstanding, are there any lingering issues with that little thing about not being able to save custom properties?
Craig
Build times notwithstanding, are there any lingering issues with that little thing about not being able to save custom properties?
Craig
Re: Build times
Custom properties of the stack issue
When I first encountered this I decided to create simple test
I created a stack with three buttons
1 = set the cTest of this stack to "Fish"
2 = set the cTest of this stack to empty
3 = put the cTest of this stack into T_Variable
answer T_Variable
I ran it and in the IDE it worked perfectly.
I then pressed button 2 and created a standalone app.
When running the standalone app, button three would only ever display empty, even after pressing button 1 before exiting (Unless I pressed button 1 just prior)
When I first encountered this I decided to create simple test
I created a stack with three buttons
1 = set the cTest of this stack to "Fish"
2 = set the cTest of this stack to empty
3 = put the cTest of this stack into T_Variable
answer T_Variable
I ran it and in the IDE it worked perfectly.
I then pressed button 2 and created a standalone app.
When running the standalone app, button three would only ever display empty, even after pressing button 1 before exiting (Unless I pressed button 1 just prior)
Re: Build times
That actually sounds like it worked as coded.
...if you press button 3, you would see "Fish" at this point
...if you press button 2, you would "empty" ctest/Fish
You pressed button 2, then compiled the standalone. There is nothing in cTest at this point.
You start the standalone, and pressing button 3 gives you "", unless you press button 1 (set cTest to "Fish") just prior to pressing button 3.
Am I missing something?
I ran it and in the IDE it worked perfectly.
I then pressed button 2 and created a standalone app.
So, if I followed correctly, everything worked in the IDE, i.e. you pressed button one and put "Fish" into ctest2 = set the cTest of this stack to empty
...if you press button 3, you would see "Fish" at this point
...if you press button 2, you would "empty" ctest/Fish
You pressed button 2, then compiled the standalone. There is nothing in cTest at this point.
You start the standalone, and pressing button 3 gives you "", unless you press button 1 (set cTest to "Fish") just prior to pressing button 3.
Am I missing something?
Re: Build times
I don't think so.
This test proves to me that Stack custom properties are stored at complie time and cannot be modified and saved once in a standalone app.
You can modify them but they will reset to the state at compilation after an application restart.
No matter what state I left cTest in when I closed the standalone app, when it is opened it will always be blank. (The state of compilation).
In the tutorials, I found nothing that made this distinction and it functions differently in the IDE than in standalone.
(It would have to else there is nothing to allow the setting of a custom property.)
This test proves to me that Stack custom properties are stored at complie time and cannot be modified and saved once in a standalone app.
You can modify them but they will reset to the state at compilation after an application restart.
No matter what state I left cTest in when I closed the standalone app, when it is opened it will always be blank. (The state of compilation).
In the tutorials, I found nothing that made this distinction and it functions differently in the IDE than in standalone.
(It would have to else there is nothing to allow the setting of a custom property.)
Re: Build times
Properties of a standalone stack can be modified, as the stack is loaded into memory. This is volatile though as a standalone cannot save differences to itself. This is as per all operating systems.
When you try your test 3 button standalone, press button 1, then button 3 and you should see "Fish".
If you restart the standalone and press just button 3, it will show empty content. Which is expected.
Therr are numerous discussions about this on this forum and tutorials about how to save content between application loads. Sounds like you would be best off with the "splashstack" technique.
I'd find some links but using phone so easier for you just to search.
When you try your test 3 button standalone, press button 1, then button 3 and you should see "Fish".
If you restart the standalone and press just button 3, it will show empty content. Which is expected.
Therr are numerous discussions about this on this forum and tutorials about how to save content between application loads. Sounds like you would be best off with the "splashstack" technique.
I'd find some links but using phone so easier for you just to search.
Re: Build times
@ mvillion , just realized SparkOut must have posted just prior to me
OH I see. Yes, that is all correct, to a point.
From my understanding of it (and I am sure someone with a ton more knowledge will jump in if I crusk this up), when you are in the IDE you are working in straight up memory. In other words, cust. props will carry over there (unless you close and remove from memory with the stack).
However, as Craig pointed out up there :
This lesson does a pretty good job of explaining the launcher or "splash" stack, as Craig was mentioning. In particular, this part of it:
Hope that helps.
OH I see. Yes, that is all correct, to a point.
From my understanding of it (and I am sure someone with a ton more knowledge will jump in if I crusk this up), when you are in the IDE you are working in straight up memory. In other words, cust. props will carry over there (unless you close and remove from memory with the stack).
However, as Craig pointed out up there :
What the splash stack method means is that you use a stack compiled to an exe to 'launch' the program and other stacks. The 'other stacks' are saved just as regular stacks, not standalones. Any custom properties/fields/etc that you want the state to carry over, you store in the regular stacks, and they will remain unchanged between runs.An entirely new issue has been raised. Standalones are executables. They cannot save anything at all, never mind custom properties or, say, field data. There are a million threads on this subject.
Everything, though, can be saved if you use the "splash" stack method. Do you know about this? Do write back, because you are missing something absolutely vital.
This lesson does a pretty good job of explaining the launcher or "splash" stack, as Craig was mentioning. In particular, this part of it:
Make sure to also pay attention to this part, Building a standalone, where it illustrates how to save everything, and you should be set to go.Creating the launcher
The launcher stack will be built into a standalone and all we need it to do is to open our main application, it can then close itself. Add the following script to the stack script of the launcher stack.
on openStack
open stack "Main Application.livecode"
close stack "Launcher"
end openStack
Thats all we need to do. The launcher will then open the Main Application stack, which can be modified and saved as it is not a standalone.
Hope that helps.
Last edited by bogs on Sat Jun 24, 2017 2:45 am, edited 2 times in total.
Re: Build times
Brilliant. Thanks
Re: Build times
You know, as I re-read that lesson, I became curious about something. Could the code to launch the other stack be put in before the launcher stack ever shows? For instance -
thereby eliminating ever showing the launcher stack on-screen?
I can already see where something like that might be useful.
Code: Select all
on preOpenStack
open stack "Main Application.livecode"
close stack "Launcher"
end preOpenStack
I can already see where something like that might be useful.
-
- Livecode Opensource Backer
- Posts: 9359
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Build times
This maybe completely off the point, but then again, maybe not.
As a standalone cannot save stuff within in it my Devawriter, when it quits, saves a text file to the user's default folder
containing the contents of a field within Devawriter. When Devawriter is restarted it "looks around" for a text file named as being from Devawriter's
previous session, and if it finds one it loads its contents back into the text field.
I don't see any particular reason why custom props couldn't be restored in the same sort of way.
As a standalone cannot save stuff within in it my Devawriter, when it quits, saves a text file to the user's default folder
containing the contents of a field within Devawriter. When Devawriter is restarted it "looks around" for a text file named as being from Devawriter's
previous session, and if it finds one it loads its contents back into the text field.
I don't see any particular reason why custom props couldn't be restored in the same sort of way.
Re: Build times
I agree. They can be and that is what I did. I just did not know that they were not stored until I coded myself into a corner and had to code myself out.
-
- VIP Livecode Opensource Backer
- Posts: 9648
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Build times
Just so we are clear, custom props are saved in the IDE, just like, say, field text. Or anything else at all. One has to save the stack before closing and quitting LC, of course.
In a standalone, I like custom props more than external files just because I like to keep things local if I can. In one large project I do maintain a folder of external files, since these are visible to all users on my network. These files are constantly accessed and reloaded into each user's standalone, restoring past data in preparation for changes to that data. The updated information is then saved back into that folder.
Richmond's point that custom props could be saved in an external file is indeed valid, assuming one did not use the splash method. If you are the sort that likes a single stack standalone and loves external files, then fine. But there can be many types of changes to a stack that go far beyond what might be considered reasonable to save that way. The splash stack seems, to me, the default go-to method.
Consider that you wanted to change the backColor of a button. One could certainly, in a naked standalone, track that property and store it in an external file, resetting it in the next session. Or, in the splash world, simply change the color.
Craig
In a standalone, I like custom props more than external files just because I like to keep things local if I can. In one large project I do maintain a folder of external files, since these are visible to all users on my network. These files are constantly accessed and reloaded into each user's standalone, restoring past data in preparation for changes to that data. The updated information is then saved back into that folder.
Richmond's point that custom props could be saved in an external file is indeed valid, assuming one did not use the splash method. If you are the sort that likes a single stack standalone and loves external files, then fine. But there can be many types of changes to a stack that go far beyond what might be considered reasonable to save that way. The splash stack seems, to me, the default go-to method.
Consider that you wanted to change the backColor of a button. One could certainly, in a naked standalone, track that property and store it in an external file, resetting it in the next session. Or, in the splash world, simply change the color.
Craig