Script too large to compile
 
 
 
PST User Forum
Home       Members    Calendar    Who's On
Welcome Guest ( Login | Register )
        



Script too large to compile Expand / Collapse
Author
Message
Posted 7/9/2008 10:39:05 AM
Junior Member

Junior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior Member

Group: Forum Members
Last Login: 9/8/2008 2:27:00 PM
Posts: 14, Visits: 39
I have a Personality Implicit Association (P-IAT) test written in E-Prime 2.0. I actually made the P-IAT for one personality domain in E-Prime 1.2 and then had to switch to E-Prime 2.0 because version 1.2 does not support full copying of structures that have children. So I switched to E-Prime 2. So far so good.
I copied the entire block for one Personality domain four times and adjusted all the filenames used in the TrialLists and some instructions.
After this I compiled. The error: Script is too large to be compiled. Funny stuff.
The script is now approx. 10000 lines long. It is a standard P-IAT in that there are 5 domains, each consisting of 6 blocks that have +/- 30 trials each.
Since E-Prime 1.2 does not accept variables in the filename attribute, I didnt see any other way to perform the experiment for all 5 domains than to copy the procedure for one domain 4 times.
Last time I checked it was 2008. My computer does about 5 billion calculations each second. How can the length of the script be capped at 8000!? What do I do now!? I still have a bunch of stuff to add...
Post #1767
Posted 7/10/2008 10:46:40 AM
Forum MVP

Forum MVPForum MVPForum MVPForum MVPForum MVPForum MVPForum MVPForum MVP

Group: Administrators
Last Login: Today @ 8:53:29 AM
Posts: 577, Visits: 1,255
The "script too large to be compiled" error is in relation to the amount of quoted strings that appear in generated Full script.  E-Prime 1.2 introduced a number of steps to reduce the possibility of encountering this error.  E-Prime 2.0 went even farther making the chances for this error significantly difficult to occur.

Please see the below link for steps to avoid this error.  If all of the List objects are set with a LoadMethod of embedded which is the default, then the only real causes for this error to occur in E-Prime 2.0 is if your experiment had a signifiant (hundreds) of unique named Attribute columns or you had significant amount of quoted strings in InLine objects.

KB1300 - INFO: Steps to Avoid "Script Too Large to be Compiled" Errors

If after viewing the steps to avoid still have the error, please attach a copy of your experiment here or to a web support request ticket.

-Brandon

Post #1770
Posted 7/11/2008 8:16:55 AM
Junior Member

Junior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior Member

Group: Forum Members
Last Login: 9/8/2008 2:27:00 PM
Posts: 14, Visits: 39
"If all of the List objects are set with a LoadMethod of embedded which is the default, then the only real causes for this error to occur in E-Prime 2.0 is if your experiment had a signifiant (hundreds) of unique named Attribute columns or you had significant amount of quoted strings in InLine objects."

All the list objects get their data from .txt-files, so the loadmethod is set to file. Just for laughs I changed this to embedded for all the lists which didnt change the error report.
Each text-file has at most 6 variables, if this is what you mean by attribute column. I do not have any quoted strings in InLine objects.

Regarding the hints from the webpage you linked:
1) Upgrade to E-Prime 1.2.
> I have E-Prime 2.0. Would it help if I changed the filetype to Professional?

2) Take the time to design your experiment before implementing it. A number of the "script too large" errors can be reduced by simply changing the design of the experiment, which in turn makes the experiment easier to manage. For a list of general guidelines, please see INFO: E-Basic Style Guidelines/Recommendations.
> I have 2 slides per trialblock, 6 trialblocks per personality domain and 5 personality domains.
I could not think of an easy way to stick all stimuli data for each block into one file, besides, the amount of text will stay the same.

3) Ensure all List objects have their LoadMethod property set to Embedded (located on the General tab of the List's property pages).
>Tried, didnt work.

4) When presenting a lot of text (e.g. instructions screens), attempt to store the text in a List attribute. Then, reference the attribute in the TextDisplay/SlideText object's Text property (i.e. instead of typing the text directly into the Text property). This reduces the number of string literals that must be generated.
>I put all the instruction text in a txt-file and accessed the variable for all the slides which are supposed to display instructional text. Didnt help.

5) Attempt to reduce the number of objects in the experiment. Keep in mind that it is very rarely necessary to create more than one object to present your stimuli. That is, unless two objects are completely different (e.g. they are collecting responses from different devices), there are very few cases where creating a new object would be preferred over using attribute references to vary a single object's properties.
>I use two slides, one with 2 states. I think this is a necessity because both slides should react to different keys.

All that I can think of now is to use external programs to create the stimuli and instructional text files before it runs the e-prime experiment on them. Or make five e-prime programs, one for each personality domain and then have another program execute them in turn.
I would surely appreciate it if I was directed to a help-file on how to start one or more e-prime programs from a C#-application, that should 'sleep' until the e-prime programs are done and then continue where it left off.

Thanks in advance for your help.
Post #1772
Posted 7/11/2008 10:39:53 AM
Forum MVP

Forum MVPForum MVPForum MVPForum MVPForum MVPForum MVPForum MVPForum MVP

Group: Forum Members
Last Login: Today @ 5:01:25 PM
Posts: 336, Visits: 897
JurgenW,

Thank you for posting your source code so we can look at it, you bring up an interesting problem.

I don't know the limit for number of objects, but I would pay more attention to point #5 above. Your program uses a lot of separate objects where one object would do. For instance, TrainSelf is identical to TrainDomain, except that TrainSelf has the literal text "Self" and "Other" where TrainDomain has "Extraversion" and "Introversion". Instead of using two separate slides with literal text, you could use one slide and use attributes (i.e., "variables") to change "Self" to "Introversion", etc. Similarly, FeedbackSlide is identical to FeedbackSlideDomain, except for the same changes in literal text. (BTW, some of your slides are set to infinite duration and do not take any input, so I don't know how they get terminated.) Even your inline script repeats itself -- FeedbackCode is identical to FeedbackCodeDomain, except for a few variable names. If you used one object as suggested above, then you could also use the same inline script in both places.

I suspect this is all a result of pasting together a lot of code that originated from separate programs -- as is often the case you cannot easily make one big program simply by pasting together a lot of little programs, usually you have to rethink and substantially restructure things to make a big program. Sad fact of life, take it from a guy who has been through this many times himself.

So doing all this could reduce the number of objects in your program, and make it easier for the programmer (e.g., you), and the compiler, to manage.

With that all said, as an exercise I deleted all the Intro and Instruction slides (BTW, any reason those are all slides rather than text displays?), and voila, the program compiled without an error. So I would take a much closer look at point #4 above.

Regards,
-- David McFarlane, Professional Faultfinder
Post #1773
Posted 7/12/2008 5:30:58 PM
Forum MVP

Forum MVPForum MVPForum MVPForum MVPForum MVPForum MVPForum MVPForum MVP

Group: Administrators
Last Login: Today @ 8:53:29 AM
Posts: 577, Visits: 1,255
Thanks for attaching your experiment and I concur with much of David's response.  Some small modifications to update your paradigm to reuse a number of the objects will certainly help and make the experiment easier to navigate.  In addition, using the same objects will make for analysis of the data file easier to parse because similar trials will be under the same column headings.

E-Prime 2.0 included a number of code generation techniques to reduce the script too large errors and seeing your paradigm have found a number of additional that we will look to add.

If you find that your paradigm cannot be readily modified in the short term to reduce the number of objects, then the only suggestion to offer would be to replace any of the InLine code where there is quoted strings and replace that with a string variable that is assigned once in SessionProc or uses Const declarations in Full script.  Any of your c.GetAttrib entries that use attributes created with List's can automatically take into account for constants generated by E-Studio.  For example, c.GetAttrib("CorrectAnswer") can become c.GetAttrib(attribCorrectAnswer).

Post #1777
Posted 7/15/2008 5:51:19 AM
Junior Member

Junior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior MemberJunior Member

Group: Forum Members
Last Login: 9/8/2008 2:27:00 PM
Posts: 14, Visits: 39
I fixed it by using one object for the initial 'self' -trial which is always exactly the same. But I fear when I add more things to the experiment the problem will reappear.
So how would I increase object re-use? Each List object uses a different txt-file to get its stimuli from. The filename of a List object cannot be an attribute is an errormessage i get a lot. If I cannot load in a txt-file in the main List object that indicates the filenames to be used for each child-list object, then I do not see how to re-use the objects for all five personality domains.

Ive attached a version of the experiment wherein only one domain is implemented. The question is how do I continue from here? The experiment should use other txt-files that use different domainnames and targets, but are otherwise identical.
Post #1783
Posted 7/15/2008 9:15:54 AM
Forum MVP

Forum MVPForum MVPForum MVPForum MVPForum MVPForum MVPForum MVPForum MVP

Group: Administrators
Last Login: Today @ 8:53:29 AM
Posts: 577, Visits: 1,255