| Author |
 Topic  |
|
|
tinkusch
Germany
94 Posts |
 Posted - 12/20/2004 : 07:24:55 AM
|
Origin Version (Select Help-->About Origin): 7.0 PRO German
Operating System:XP
Hi,
I have some problems with compiling and linking of .op-files.
I use the following settings for the relevant system variables:
@OCS=1 //create .op-files
@OCST=1 //save .op in /OCTemp-folder
@OCSE=1 //encrypt .op-file
My trouble is the following: It seems that I always need to have the .c-file in the ORIGIN-file system, e.g. in the folder C:\Programme\OriginLab\OriginPro7G in order to compile and link the code with LoadOC and in order to execute the code. I use the following Labtalk script:
if (run.LoadOC(%yMyProg)!=0) , where "MyProg" names a .c-file and its respective .op-file.
As written in Help: "An overview of the Build Process", ORIGIN should first compile and link an.op-file there is any.
How can I compile, link and execute explicitly the .op-file from a LabTalk script without having the respective .c-file in the origin-file system. The respective Help text simply states that this is possible ("Encrypted op-files... can be loaded and linked by any installation....") but it does not tell how.
What is the procedure for ORIGIN 7.5G? It seems there are some differences in the file system.
Thanks for any help!
Stefan
Edited by - tinkusch on 12/20/2004 08:00:48 AM |
|
|
Gary Lane
USA
150 Posts |
Posted - 12/20/2004 : 09:37:48 AM
|
Hi,
The best solution across all versions of Origin is to place your source file and OP file (if any) in the Origin C folder or a subfolder of the Origin C folder and then use the following command (which assumes pathing relative to the Origin C folder).
run.LoadOC(MyProg) // In Origin C folder
run.LoadOC(MySubFolder\MyProg) // In \MySubFolder folder of Origin C folder
The above will always look first for and load the *.OP file. If the *.OP file is not found or if the *.c file is more recent than the *.OP file then Origin will load the *.c file.
But in v7 to create the *.OP file in the source folder you must first set @OCST=0 and in v75 you must first set @OCSB=0 to create the OP file in place of the *.OCB file.
Thanks for the post. I am going to review the v7 and v75 documentation and provide an update with a better example as needed.
Gary
OriginLab
Edited by - Gary Lane on 12/20/2004 2:23:28 PM |
 |
|
|
tinkusch
Germany
94 Posts |
Posted - 12/21/2004 : 04:54:50 AM
|
Hi Gary,
thanks, but my system behaves a bit peculiar:
I have set @OCST=0 and tried some alternatives:
1) If the source is in OriginC only, it is compiled and linked, but not executed from LabTalk. In Code Builder there is an entry in Temporary like this: "....OriginC/MyProg.C" and the file MyProg.op was created in OriginC.
2) If the source is in OriginPro7G only (main origin folder) the source is not found by LoadOC.
3) If the source is in both folders, compiling and linking and execution works properly and an encrypted MyProg.op was created in OriginC. After the first start of the Application.opj the CB/Temporary entry looks like this: "...OriginC/MyProg.c", after the second start it changes to "...OriginC/MyProg.op". But, after removal of the source from the OriginPro7G folder the code will no longer be executed from LabTalk.
It seems, that Origin can not work alone with the *.op file and the source is always explicitly needed. That is not satisfactory to me because I don't intend to open my sources to the users eye at this stage of development.
By the way... I installed the Origin 7.5G Demo version (v7.5870). It was not possible to set @OCSB=0, the variable does not change its value!? However, @OCST was changeable.
Perhaps there is an other workaround for my problem?
Stefan
Edited by - tinkusch on 12/21/2004 04:58:16 AM
Edited by - tinkusch on 12/21/2004 06:21:57 AM |
|
|
|
Gary Lane
USA
150 Posts |
Posted - 12/21/2004 : 11:14:02 AM
|
Hi Stefan,
"1) If the source is in OriginC only, it is compiled and linked, but not executed from LabTalk. In Code Builder there is an entry in Temporary like this: "....OriginC/MyProg.C" and the file MyProg.op was created in OriginC."
1. Seems like Origin is compiling and loading your file as expected. The function run.loadOC does not execute any Origin C functions it just builds them. You must still call the functions yourself from LabTalk. Remember, to call a function from LabTalk you can only pass arguments recognizeable by LabTalk (i.e. no pointers, structures, etc.).
2. If you want to place source code in Origin folder try
run.loadOC(..\MyProg); // Relative path from OriginC folder to Origin folder
3. I tested loading (with run.loadOC) and running code (called function from Script Window) with only an OP file in E Origin 7 SR4 v7.0552 and it worked fine for me. Origin 7 can definitely run just OP files. See my test procedure below for what I did.
I am not sure what is happening for you. Please tell me your Origin 7 Build number and I will test specifically on that G version. Also try the following:
1. Select File:New Workspace menu item in Code Builder and then create \OriginC\test.c with text below:
#include <origin.h>
int mytest()
{
printf("function mytest ran\n");
return 0;
}
2. Execute LabTalk code below from Script Window:
@OCST=0;
iRet=run.loadOC(test);
iRet=;
mytest;
====> You should see
IRET=0
function mytest ran
in Script Window and test.c in Temporary folder of Code Builder.
3. Select File:New Workspace menu item again to unload test.c and then delete test.c (or just rename it to testXXX.c). Then repeat step 2 again. You should get the same results except now test.OP should show in Temporary folder of Code Builder.
Please try above test and let me know what happens along with you v7G build number.
Thanks...we will get to the bottom of this I am sure.
Gary
OriginLab
Edited by - Gary Lane on 12/21/2004 11:18:13 AM |
|
|
|
tinkusch
Germany
94 Posts |
Posted - 12/21/2004 : 4:29:57 PM
|
Hi again Gary,
sorry for my lax description... by the term "not executed from LabTalk" I tried to describe the fact, that calling the functions from a LabTalk script does not work....
I have Origin v7.0552 SR4.
I tried your example with no success. After creation of test.c I get:
@OCST=0
iRet=run.loadOC(test)
-> loads and compiles
iRet=
-> IRET=0
mytest
-> #Command Error!
I try it once again tomorrow, its to late now...
bye
Stefan
|
|
|
|
Gary Lane
USA
150 Posts |
Posted - 12/22/2004 : 09:37:56 AM
|
Hi Stefan,
If my above steps 1-3 fail for you then try step 4 below as well to see what happens.
4. Open Code Builder GUI if not already open and then click the Rebuild All button.
===> Do you get any compiling or linking errors?
We are using the same build but I will try to reproduce today on your OS and using the G version.
Gary
OriginLab
|
|
|
|
tinkusch
Germany
94 Posts |
Posted - 12/22/2004 : 11:35:42 AM
|
Hi Gary,
it seems that your examples work now also on my PC. Don't know what went wrong when I tried it the first time...
I now can clearly spot the location of my original problem: In my application a LabTalk script is included in the c-source file like in the example below.
The peculiar thing is, if the function mytest is called from a Labtalk script, the first LT-execute command will be simply ignored and the following two LT-execute commands are properly executed. I think, there is no syntax fault in the first LT-execute command because the syntax is the same as in the help examples.
It is also possible to run MYSCRIPT from the Script Window with run.section(%yOriginC\test.c, MYSCRIPT)").
As I use many of these calls in my application I was at first glance misguided by the assumption, that the compiling does not work at al.
Any idea why
LT_execute("run.section(%yOriginC\test.c, MYSCRIPT)");
does not work in my example?
thanks & bye
Stefan
////////////////////////////////////////////////////////////////
#include <origin.h>
void mytest()
{
printf("function mytest ran\n");
LT_execute("run.section(%yOriginC\test.c, MYSCRIPT)");
LT_execute("x=sqrt(100)");
LT_execute("x=");
}
#ifdef LABTALK
[MYSCRIPT]
Data1_a[1]=100;
type -a "MYSCRIPT done";
#endif
Edited by - tinkusch on 12/22/2004 11:36:52 AM |
|
|
|
rlewis
Canada
253 Posts |
Posted - 12/22/2004 : 12:29:58 PM
|
I've had similar problems coding OC functions when strings contain the '\' character.
OriginC may interpret these as escape sequences such as ....
\n New line.
\r Return.
\d Delete/backspace.
\t Tab. .... etc
To avoid this, use "\\" instead of "\" in OriginC strings.
Instead of
LT_execute("run.section(%yOriginC\test.c, MYSCRIPT)");
use
LT_execute("run.section(%yOriginC\\test.c, MYSCRIPT)");
|
|
|
|
tinkusch
Germany
94 Posts |
Posted - 12/22/2004 : 1:21:23 PM
|
Youp, that helps, Thanks! The code now works as far as the *.c source is involved.
But, if one now deletes or renames the *.c source in order to work with the encrypted *.op file, then
run.loadOC(test) loads test.op into the temporary section of the workspace and surprisingly
the command line
"LT_execute("run.section(%yOriginC\\test.c MYSCRIPT)");
is again not executed when calling the function mytest from Labtalk.
Again the other LT_execute commands are executed.
The peculiar thing is, just adding the test.c file again to the OriginC folder without changing the code builder workspace makes the code work with no problems. The effect is reversible just by adding or deleting the *.c file.
It seems that Origin explicitly needs the *.c file if the source contains a reference to a LabTalk script within the source file.
Stefan
|
|
|
|
Gary Lane
USA
150 Posts |
Posted - 12/22/2004 : 2:01:37 PM
|
Hi Steffan,
I tested the original issue using Origin 7G SR4 on a Win XP computer and it worked fine as you stated in your last post. Setting the system variable @ocst can sometimes lead to very confusing situations if you have different versions of *.OP files with the same name in different folders. If setting @ocst and you experience difficulties I recommend making sure old *.OP files in all locations are deleted before trying to compile a new version of a source file. Users (people not developing) should not experience this issue as their source files should always remain the same and they generally do not toggle @ocst.
Regarding the LabTalk script issue mentioned in your last post: I suspect the problem is with string substitution in the pathing in your run.section call. The \ character is an escape character in C and so must be doubled up when used in a string. Awkward but part of standard C I think. See my code below which worked well. Note the \\ characters in place of the \ character. This needs to be done everywhere you have a \ in a string. The first \ in essence says treat the second \ as just the \ character and not as an escape sequence.
LT_execute("run.section(%yOriginC\\test.c, MYSCRIPT)");
Hope this helps.
Gary
OriginLab
Edited by - Gary Lane on 12/22/2004 2:07:32 PM |
|
|
|
tinkusch
Germany
94 Posts |
Posted - 12/30/2004 : 4:09:17 PM
|
Hi again Gary,
sorry to talk again on old problems: I have now tested two simple examples (see below) of Origin C-code calling Labtalk routines with LT_execute. I use Labtalk scripts like the following to call the functions mytest1 and mytest2 by clicking on a button:
////////////////////////////////////////////
@OCST=0;
if (run.LoadOC(test1)!=0)
type -b "Cannot load support Origin C file";
mytest1;
//////////////////////////////////////////////
@OCST=0;
if (run.LoadOC(test2)!=0)
type -b "Cannot load support Origin C file";
mytest2;
--------------------------------------------------
The test1,2-C-files are both in the OriginC-folder. Both files compile, test1.op and test2.op files are created and stored in the OriginC-folder.
Now the trouble starts: The first example runs only from Labtalk, if the path including the ending *.c is given explicitly in the LT-execute statement. AND: the test1.c file must still exist in the OriginC-folder!! If it is deleted, then test1.op is loaded into the Workspace and the code is executed without executing the LT-execute statement! If nothing is changed, but only the test1.c file is added again to the OriginC folder, the code works perfectly. Strange......uh??
The second example behaves as written in the Origin manuals: If tst2.c is deleted or not changed, test2.op is loaded and executed without trouble.
Therefore, once again, I come to the conclusion, that it seems not possible to compile and execute an *.op-file which contains a
LT_execute comand including "run.section......".
Either I do not understand the manuals or there is a flaw in Origin.
Anyway, may I ask you again if you can repeat this strange behavior or just explain me the pedestrians way, where my mistake is...?
thanks & Happy New Year to all of you folks!
Stefan
/////////////////////////////////////////////////////////////////////
//test1.c
#include <origin.h>
void mytest1()
{
printf("function mytest1\n");
LT_execute("run.section(%yOriginC\\test1.c, MYSCRIPT)");
}
#ifdef LABTALK
[MYSCRIPT]
Data1_a[1]=ran(.9);
type -a $(Data1_A[1]);
type -a "Done mytest1";
#endif
/////////////////////////////////////////////////////////////////////
//test2.c
include <origin.h>
void mytest2()
{
printf("function mytest2\n");
LT_execute("Data1_A[1]=ran(.9);");
}
|
|
|
|
cpyang
USA
1406 Posts |
Posted - 12/30/2004 : 4:29:39 PM
|
Hi Stefan,
%Y is the user file path, so it seems that you should change your code as follows,
string strLT = "run.section(";
strLT += GetAppPath(true); // this is the actual EXE path where Origin is installed
strLT += "originC\\test1.c, MyScript)";
LT_execute(strLT);
See if that will work.
CP
Edited by - cpyang on 12/30/2004 4:45:15 PM |
|
|
|
tinkusch
Germany
94 Posts |
Posted - 12/31/2004 : 08:21:00 AM
|
Hi CP,
thanks, but that does not work. It is the same as described above. The string content of strLT is "D:\Programme\OriginLab\OriginPro7G\originC\test1.c, MyScript)"
which is correct.
I also tried:
strLT += "originC\\test1, MyScript)";
but this did not work either.
Can you reproduce it on your PC?
Any other idea for a workaround?
bye
Stefan
|
|
|
|
cpyang
USA
1406 Posts |
Posted - 12/31/2004 : 10:27:36 AM
|
When I tried, it worked for me, make sure you have
string strLT = "run.section(";
as the strLT you showed didn't have the run.section part.
You should also turn on echo=7 to see exactly what LT strings are being executed.
By the way, is there reason that you must use this LT mixed into C technique? why not do all things in Origin C?
CP
Edited by - cpyang on 12/31/2004 10:32:44 AM |
|
|
|
tinkusch
Germany
94 Posts |
Posted - 12/31/2004 : 4:38:38 PM
|
CP:
of course strLT contained the "run.section(".... part. I just wanted to stress the fact that I tried the following variations:
1) "run.section("...originC\test1.c, MyScript)"
2) "run.section("...originC\test1, MyScript)"
here is the output to the script window after setting echo=7:
////////////////////////////////////////////////////////
for above variation 1) with test1.c and test1.op. both existing
@OCST=0
if (run.LoadOC(test1)!=0)
type -b "Cannot load support Origin C file"
mytest1
function mytest1
run.section(D:\Programme\OriginLab\OriginPro7G\originC\test1.c, MyScript)
Data1_a[1]=ran(.9)
type -a $(Data1_A[1])
0.74349
type -a "Done mytest1"
Done mytest1
/////////////////////////////////////////////////////////////
for above variation 1 but test1.op exists and test1.c does not
@OCST=0
if (run.LoadOC(test1)!=0)
type -b "Cannot load support Origin C file"
mytest1
function mytest1
run.section(D:\Programme\OriginLab\OriginPro7G\originC\test1.c, MyScript)
Error: File D:\Programme\OriginLab\OriginPro7G\originC\test1.c not found.
//////////////////////////////////////////////////////////////////
for above variation 2, test1.op exists and test1.c does not:
@OCST=0
if (run.LoadOC(test1)!=0)
type -b "Cannot load support Origin C file"
mytest1
function mytest1
run.section(D:\Programme\OriginLab\OriginPro7G\originC\test1, MyScript)
Error: File D:\Programme\OriginLab\OriginPro7G\originC\test1.OGS not found.
////////////////////////////////////////////////////////////////////
In the last case I expected that origin tries to find test1.c or test1.op instead of test1.ogs? That's probably the cause of the trouble?
There is no real need to mix LT into OriginC. Just a matter of habit and convenience. And of course a bit of work to transfer the LT code of my application.
I tried the above example on two PCs with German XP and XP home, both with no success.
bye Stefan
Edited by - tinkusch on 12/31/2004 4:40:04 PM |
|
|
|
cpyang
USA
1406 Posts |
Posted - 12/31/2004 : 4:53:16 PM
|
ok, I finally understand what the problem was, I admit that I didn't try the op without c part.
You have embeded LT code inside C file, which will not be transfered into op files, so this won't work.
OP files are the preprocessed C files, so all #ifdef etc are already processed, so the LT code under #ifdef won't appear in OP files at all. This now seems obvious but somehow I didn't see this earlier, maybe it is part of the holiday thing.
In order to run the LT codes, you will need to put them in separate ogs file and distribute with your OP files, or just put all the LT codes into string and LT_execute from your C files.
CP
|
|
|
|
tinkusch
Germany
94 Posts |
Posted - 01/01/2005 : 07:47:03 AM
|
Hi CP,
thanks for this final clarification! One last question: Is it possible to encrypt the ogs.files?
Bye
Stefan
|
|
|
|
cpyang
USA
1406 Posts |
Posted - 01/03/2005 : 3:05:03 PM
|
quote:
thanks for this final clarification! One last question: Is it possible to encrypt the ogs.files?
Yes, it is possible, use opack.pack to zip up your ogs file and from OC, use opack.unpack to unzip and then to run it.
Assume that you have an ogs file called "myTest.ogs" and you need to run a section called MyScript. First, you need to pack it. The following macro will do
def pkogs;
{
%A=system.path.program$;
opack.file1$=%A%1;
opack.filename$=%Apackedogs.ogp;
opack.SaveFolderInfo=0;
opack.pack();
};
Make sure myTest.ogs is in the EXE folder, then
pkogs myTest.ogs
Check that a new file called packedogs.ogp is created. This file you can add to your list of files for distribution.
Later, in your C code, you can call this ogs file with the following example code
void test()
{
string strPackedOGSfilename = "packedogs.ogp"; //assume the name from packing LT macro pkogs
string strOGSname = "myTest.ogs"; // assume this is the needed ogs file, with MyScript section to run
string strOGSFile = GetAppPath(false) + strOGSname; // result ogs default in USER file path, good enough
if(!strOGSFile.IsFile()) // not already extracted, need to extract
{
string str =
"%A=system.path.program$;"
"opack.filename$=%Apackedogs.ogp;"
"opack.unpack();";
out_str("doing unpack of ogs file into myTest.ogs in User file path");
LT_execute(str);
}
if(strOGSFile.IsFile())
{
string strLTstr = "run.Section(" + strOGSFile + ", MyScript)";
LT_execute(strLTstr);
out_str("del ogs after running");
DeleteFile(strOGSFile);
}
else
out_str("failed");
}
CP
Edited by - cpyang on 01/03/2005 3:44:23 PM |
|
|
|
Mike Buess
USA
3037 Posts |
Posted - 01/04/2005 : 11:50:10 AM
|
Hi Stefan,
CP's solution should work fine but I have two comments...
1. Remove the semicolon at the end of the "def pkogs;" or you'll just get the message "#Not Defined" when you try to define the macro.
2. I suggest that you omit the "doing unpack of ogs file..." and "del ogs after running" out_str messages which might clue the astute user in to what's happening. Although CP changed the extension of the OPK file if you open any OPK file (regardless of extension) in notepad you'll see "OPK" at the beginning. Anyone can open an OPK (or OGP) file in Pack/Unpack OPK dialog and extract the OGS file on their own. (I hope none of your prospective users read this post. :)
As far as I can see the only 100% reliable way to encrypt your OGS file is to create it from OriginC when it's needed...void test()
{
string strOGSFile = GetAppPath(false) + "myTest.ogs";
if( !strOGSFile.IsFile() )
CreateOGSFile();
if(strOGSFile.IsFile())
{
string strLTstr = "run.Section(" + strOGSFile + ", MyScript)";
LT_execute(strLTstr);
DeleteFile(strOGSFile);
}
else
out_str("failed");
}
void CreateOGSFile()
{
stdioFile ff(GetAppPath(false) + "MyTest.ogs", file::modeCreate | file::modeWrite);
ff.WriteString("[MyScript]");
ff.WriteString(" line 1 ");
ff.WriteString(" line 2 ");
// remaining lines
} The only problem with this method is that the CreateOGSFile() function will be as long as your OGS file. Presumably that's quite long or you would execute a line at a time with LT_execute() as CP suggested earlier. In the end I think either that or converting LabTalk code to OriginC is still the best solution.
Mike Buess
Origin WebRing Member
Edited by - Mike Buess on 01/04/2005 11:56:56 AM |
|
|
| |
Topic |
|
Compiling and Linking of .op-files