Hi,
Is there a way to create a script library that may use c functions? In Xcode you need to create the bridge or something like that.
Thanks,
kel
That’s one thing. I don’t think you can do that with a script library. Only in Xcode does it work. I think Apple should have provided the c functions to applescripters a long time ago.
I agree totally.
I also wish that if such a thing should happen, that the primitive math function was to be incorporated into AppleScript, that they kept the parenthesis.
Heavily parenthesized expressions, doesn’t play well with command words in my experience.
Sometimes, it seems like the compiler has an opinion of it its own, which is of course always wrong, when it comes to placing the parenthesis.
Maybe because there were to few parenthesis for it to resolve it properly in the first place, but still a nuisance that could have been avoided.
As it is, the only way I see it possible to get the functionality, is to link something into the foundation frameworks, that is currently active on your machine. 
(Don’t try that!)
It’s not something you just built in. I’ll hope I can briefly explain you why.
In AppleScriptObjC you can use a bridge between Objective-C and AppleScript. The reason for this is that Object-Oriented programming language do need an runtime to work properly. This is still a considerable drawback of OOP languages but also an great advantage. The runtime of Objective-C allows developers to create objects even if the program is already running. This means that when the applications starts the AppleScriptObjC framework kicks in. It will open the AppleScript files and create Objective-C objects based on these AppleScript files.
Back to C.
C is a procedural compiler languages without a runtime. That means that the code needs to be created at compile time. There is no manager/controller available at run time that will control any of your code. The advantage is that C will beat Objective-C in anything when it comes to performance. The drawback is that it is a strong typed language.
Is it impossible?
C datatypes are more different from AppleScript than Objective-C and AppleScript. For instance when I write C I love to work with structs. But as most C developers know, a struct is not something like a record even if it presents itself that way in your editor. It’s an collection of data of different types. Then I also like to work with pointers, which can be difficult when you’re not familiar with it. When I work with strings I do sometimes have multiple (w)char pointers to the same string but all to different positions. So what should I return to AS then? Then at last, something also very common in C, is sending an pointer to a void function and the function only moves the pointer to the right direction. These are just examples why it’s too hard to build a bridge between AppleScript and C.
What’s left to do?
Considering that AppleScript is written in C, you could see AppleScript commands in the scripting addition as an bridge to C. All of it is written in C. Because Apple hasn’t officially announced that scripting additions are deprecated and still fully supported in AppleScript 2.3 I think an scripting addition is the best and closest form of bridging C to AppleScript till today. Scripting additions development guidelines will tell you exactly which kind of data can be returned to AppleScript (and which not).
The alternative!?
The best thing you can do is write an Objective-C wrapper class for your C functions. Then use that class in AppleScriptObjC to to call the C functions. The performance gain of using a scripting addition is so small that I would go for the wrapper class. Unless you’re comfortable in the world of C(arbon).
And you can see this in ASObjC, where in theory you can call lots of functions in the various frameworks, but in practice most of them are out-of-bounds because either the arguments or results are datatypes that aren’t or can’t be bridged to AS classes.
True – but they are strongly hinting that they don’t see them as the way of the future.
And there’s not just the (negligible) performance difference to consider: there’s also the fact that additions pollute the namespace. Ill-judged addition command names are a nightmare, whereas frameworks/libraries give you more control over the namespace.
(and in the case of C functions, any performance difference would be overwhelmingly swamped by the overhead of converting to/from AS objects.)
As it happens, I’m working on an Objective-C framework of stuff that is hopefully of general use. So I’m interested to know what people are pining for, apart from the obvious trig functions. I don’t see many concrete examples, other than my favourite, “I want!” 
Hello.
It isn’t much that is needed beyond the transcental functions of C. Though the full math.h would have been nice.
But, some numeric functions, should be in such a framework, so we can have consistency in scripts.
One word commands, lets me use parenthesis in AppleScript and I am happy with that.
I’m really not be questioned as I have started to write the stuff I needed it for in Objective-C. LLVM beeing the sole reason.
But if Shane is so kind that he is writing a framework for covering this, and wanting to know the needs, then here it is.
Actually, the most important thing, is to support whatever math functions there is in an advanced basic environment. And that isn’t many functions. And they should be of one word, so the parenthesis are usable. If you had sind cosd, asind and acosd as an addendum, then that wouldn’t hurt! The hyperbolic functions should also be implemented, because they and the logarithms is very useful.
int,sgn,abs,floor,ceil,
cos,sin,sec,cosec,tan,cot,acos,asin,asec,acosec,atan,acot,cosh,sinh,tanh,coth.
Degree versions of the above where it makes sense. (You can even drop sec and cosec).
exp, ln, log10,log2, power.
That is the basics I think. If you have these, you can roll a lot of your own. Another thing is that such a framework, gives something common, removing a lot of fuzz.
Hopefully I haven’t forgotten anything. But those are the important ones for me in this matter. Then I can translate a basic program, or write something in the same genre.
There are a lot of nice to haves, most nice to haves, should be possible to be implemented with the handlers above.
I think such an addition to AppleScript would make it popular among people that calculates.
Edit
I’d also like to have rev, revd, (revd = modulus 360) deg2rad, and rad2deg as conversion functions in the same place. And maybe I forgot odd: and even:
Why bother? You can do them in native AS, and probably quicker than all the overhead of going to C and back via ASObjC/scripting bridge/Obejective-C. Just put native versions in a library.
Some of those, sure. But some of those aren’t even in math.h.
That’s a simple AS multiplication – I don’t see that the complication of extra methods is worth it.
Logs I understand, but you’re wandering outside math.h again. And why power when we have ^?
Do them in AS.
I agree with Shane, many of those request can be done with vanilla AS.
I was more expecting things like full ODF support using an C/Objective-C++ class. In C or Objective-C I use an C/C++ project or Objective-C++ project. Apple did the same with webkit (is an C++ framework as well).
I’m not quoting Shane’s post for obvious reasons. :lol:
Not all of those handlers are difficult to implement in AS, the thing is to have a standardized set everybody can relate to.
So if the front end is an ASOC library, then they could be implemented as AS handlers of course.
And you can of course implement the hyperbolics yourself, when the other stuff is inplace.
My idea was to collect what has a common denominator, together with the stuff that are hard to implement in ASOC/AppleScript by yourself. Also, giving a low entry way for people that comes to OSX/AppleScript, and hasn’t figured out yet the rounding methods that are in play when you coerce something to integer (for instance).
Edit
And maybe you actually can implement the “inaccessible functions” in pure ASOC, with key value observing and swizzling, where you transform the changed value, on its way back through a predicate. But this is obviously time-consuming. I still purport that the best thing, would be if it was built into AppleScript as primitive commands.
Hi everybody,
Lately, I’ve wanted to use the bitwise operators (the OR), the constants (think it was e or n), and of course sine and log. Also, the set operations. Can’t think of the rest right now. I need to find that document with the c stuff again.
Sounds like a big job creating the framework! Think it took me several days just to get log with Xcode and needed a lot of help also.
Thanks,
kel
I remember now. It was in Math.h.
These would be helpful also:
Then you don’t need to write something like (x^2 + y^2)^(.5).
Btw, you can see the math functions from Terminal with ‘man math’. They moved Math.h in Mavericks. I can’t find the actual header file now.
You can’t do bitwise operations with objects, as opposed to types. But again, you can do the equivalent with mod and div.
You do have NSSet, as well as the the array operators you can use with valueForKeyPath:.
Just write it in a library, once. It will probably be quicker than any bridging to C anyhow.
Hi Shane,
I didn’t know it might be quicker. So, if you use just vanilla AppleScript math, then it’s quick.
Thanks,
kel
Generally, yes. Things like the round command are (or at least, used to be) slow, and obviously if there are a lot of calculations involved, it can be a different story. But you have to account for the fact that going via ASObjC and a framework and back adds a certain amount of overhead – often much more than the actual calculation time.
Hello.
I thought I had posted the cbrt handler somewhere here, but here it is anyway. it is not the fancy one with imaginary roots, it only delivers the real solution.
on cbrt(x)
# http://www.stjarnhimlen.se/comp/tutorial.html
if x > 0.0 then
return x ^ (1 / 3)
else
return -(-x ^ (1 / 3))
end if
end cbrt
Keep in mind that when working in C you can directly work with parameters while working in cocoa there is a lot of converting done. This is done by the OSAKit framework in order to make cocoa communicate with the C(arbon) AppleScript and the event manager. There is a lot more conversions and allocations done in cocoa than direct communication in C.
That’s true, but I still wonder whether that difference is mostly lost in the noise. I did quite a few timings when I first wrote ASObjC Runner, comparing some commands with scripting addition commands. I suppose it’s possible I just coded brilliantly ;), but the result was that the differences were mostly negligible, and I think the explanation is a bit more mundane…
Hello
I don’t find mundanity in this respect so very mundane, so please elaborate:
Are you pointing to the fact that the cocoa runtime is already in memory, and can hardly be noticed, or is there some other reason that makes the difference neglible?