OS X Externals

Frank D. Engel, Jr. fde101 at fjrhome.net
Wed Oct 13 12:41:26 EDT 2004

That looks doable, but I would have preferred to have the value 
returned by the function (as a return value).  I guess I will use (the 
below) unless someone could tell me how to provide a binary return 

Thank you!

On Oct 13, 2004, at 11:23 AM, Thierry Arbellot wrote:

> You can return binary data in argument:
> for example
> in transcript
> 	local thebinaryData
> 	theExternalCommand "theBinaryData"
> in C program
> {
> 	int				retvalue;
> 	MCstring	rdata;
> // put here your process
> 	rdata.sptr = pointerToBinaryData;
> 	rdata.length = sizeOfbinaryData;
> 	SetVariableEx(args[0],"",&rdata,&retvalue);
> }
> On Wednesday, Oct 13, 2004, at 16:49 Europe/Paris, Frank D. Engel, Jr. 
> wrote:
>> Aha!  Got it built and working.  It had something to do with the 
>> prefix header, whatever that is.
>> However, I now have a slightly different question.  Since one of 
>> these functions returns a string with binary image data, that string 
>> may contain null bytes -- not a problem for Rev, but as far as I can 
>> tell, the return value from an external function call is 
>> null-terminated.  How can I return a string value from an external 
>> function and include embedded null characters in the string?
>> Thank you!
>> On Oct 13, 2004, at 9:22 AM, Frank D. Engel, Jr. wrote:
>>> I don't mind copying it when built; it should not need to be redone 
>>> too often after I have it working; there are two functions which I 
>>> translated to C from Transcript in order to improve performance 
>>> (they are quite slow under Transcript, since they need to look at 
>>> each byte in the text of an image).
>>> Toward the beginning of the C source code, I placed this line:
>>> char Xname[] = "PostgreSQL BLOB encoding functions external v0.0";
>>> (I previously posted the Transcript versions of the functions)
>>> At the end of external.c, I placed this code:
>>> Xternal Xtable[] = {
>>>     {"dbblob", XFUNCTION, 0, dbBLOB, dbabort},
>>> 	{"dbunblob", XFUNCTION, 0, dbUNBLOB, dbabort},
>>> 	{"", XNONE, 0, NULL, NULL}
>>> };
>>> Note that the 'dbabort' function simply contains an fprintf function 
>>> call (outputs to stderr).
>>> What else would be needed to get this working?  I created an Xcode 
>>> project using the "Carbon Bundle" template, and did simple changes 
>>> to get the project to build with the following files listed when the 
>>> project icon is selected in the left-hand pane:
>>> bytea-funcs.bundle (the target)
>>> Carbon.framework (from OS X)
>>> external.c (my code)
>>> InfoPList.strings (provided by Xcode, then modified)
>>> XCmdGlue.c (from the SDK)
>>> XCmdGlue.h (from the SDK)
>>> XCmdName.h (from the SDK)
>>> I also have XCmdFunc.c (from the SDK) copied into the project 
>>> directory.
>>> Toward the end of XCmdGlue.c, there was a line:
>>> #include "XCmdFunc.c"
>>> I commented that line out because I could not get the project to 
>>> build otherwise.  After commenting out that line, the project now 
>>> builds without errors or warnings, but does not work.  Could this be 
>>> related to the problem, and if so, how can I get the project to 
>>> build with the line uncommented?  My own code does not call any of 
>>> the functions provided by the engine; I tried to keep it as simple 
>>> as I could.
>>> On Oct 13, 2004, at 9:04 AM, Thierry Arbellot wrote:
>>>> OK
>>>> If you don't want to copy the bundle every-time you rebuild it, use 
>>>> the full path to the folder where XCode build the bundle.
>>>> And each time you rebuild the bundle, you should close the stack, 
>>>> remove it from memory then reopen it.
>>>> Another thing to check: have you add the 2 functions in the Xtable 
>>>> array declared in the external.c source file ?
>>>> On Wednesday, Oct 13, 2004, at 14:40 Europe/Paris, Frank D. Engel, 
>>>> Jr. wrote:
>>>>> No, just the name.  However, I have now tried using the EnhancedQT 
>>>>> external, just to see how that one worked (place it where in order 
>>>>> for it to work), and placing it in the Rev folder causes it to 
>>>>> work, even w/o the full path in "the externals of this stack", and 
>>>>> the externalFunctions does return a list of functions.
>>>>> I placed my external in the same place, but have an empty list of 
>>>>> externalFunctions.  Apparently something is wrong, either in my C 
>>>>> source code, or in the build process.
>>>>> On Oct 13, 2004, at 5:10 AM, Thierry Arbellot wrote:
>>>>>> On Tuesday, Oct 12, 2004, at 23:44 Europe/Paris, Frank D. Engel, 
>>>>>> Jr. wrote:
>>>>>>> I am trying to build an external for OS X (which I will 
>>>>>>> eventually need to get working under Windows as well).  There 
>>>>>>> should be no outside dependencies from the external itself, 
>>>>>>> other than the standard libc.  The external contains two 
>>>>>>> functions.
>>>>>>> I tried various things, and finally ended up with a .bundle 
>>>>>>> file, courtesy of XCode.  I tried several different placements 
>>>>>>> of the file, and have the name of the bundle in the externals 
>>>>>>> property of my main stack, but using 'answer the 
>>>>>>> externalFunctions of this stack' from the msgbox always results 
>>>>>>> in an empty message box (just the ever-present OK button).
>>>>>>> I cannot tell if Rev is not finding my external, if my external 
>>>>>>> was not built correctly (found but considered corrupt and 
>>>>>>> silently ignored), or if it is somehow being considered an 
>>>>>>> 'empty' external (a valid external with no functions).
>>>>>>> Could anyone help me to debug this problem?  Thank you!
>>>>>>> -----------------------------------------------------------
>>>>>>> Frank D. Engel, Jr.  <fde101 at fjrhome.net>
>>>>>> Frank,
>>>>>> Have you set the full path to the bundle in the externals 
>>>>>> property of the main stack ?
>>>>>> Thierry
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.

$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com

More information about the Use-livecode mailing list