LCContextGet

[monte]

Out of interest, what issues did you find here? I remember adding the ability to specify weak/non-weak frameworks in the .ios file, but (to be fair) it was a pretty hasty addition.

Hmm... checking... I don't think you've released this version.. well I guess you have now... my solution just weak linked everything... if this was in version 14 then I must have overwritten it with my mod...

I needed both weak linking and conditional inclusion so I could compile the same external for older SDKs and gracefully degrade... For example, mergSocial degrades from the Social framework to Twitter.... actually I think that was the external I needed both of these things for...

[LCMark]

Hmm... checking... I don't think you've released this version.. well I guess you have now... my solution just weak linked everything... if this was in version 14 then I must have overwritten it with my mod...

That is entirely possible - I think it was added on the lead up to KickStarter or during it and probably got lost during that mayhem!

[monte]

Right... I don't think there's been an official SDK since soon after 5.5.2...

I've done the number prefix change... looking at the default change... If it's only int and double that we can't call with nil then why not just default to assigning them 0 if there's no default specified?

[LCMark]

I've done the number prefix change... looking at the default change... If it's only int and double that we can't call with nil then why not just default to assigning them 0 if there's no default specified

The reason it's done this way is because there is a difference between 'optional with default', and 'optional'.

An optional parameter with default, from the point of view of the method being called, has a complete set of parameters - the default is filled in when it is not specified by the caller. i.e. an 'optional defaulted int' can only be int values.

An optional parameter, from the point of view of the method being called, is a union of nil and the type. i.e. an 'optional int' can be int values *or* not specified.

[monte]

Ok... bed time so no time to test yet but I think I've done the optional defaults for the optional parameters:
https://github.com/montegoulding/liveco ... parameters

[LCMark]

Well, you've made it so they can be parsed... Then there's the actual code generation aspect

Sleep well!

[mwieder]

I think I was just over-thinking things at the time - strings it is

I have a dream of a generic way to access system APIs and other external library functions the way other environments do.
Toolbook had a nifty way of doing this, as did Visual Basic, even if they were Windows-specific.
This requires the ability to declare variable types and the ability to declare a prototype on the fly.

Something like (from memory - someone will come along and correct the mistakes)

Code: Select all

declare osFunction(integer pInteger, string pString) as integer
put osFunction(42, "hello, bucko") into tVar

[monte]

OK, I'll check it again but it looked like things were being initialised to nil already if default was nil... yep... they are initialised correctly...

[monte]

So... looking at boolean defaults now. It's fairly easy if the default value is a quoted string rather than an unquoted one... default "true" vs default true... Is that reasonable... or do I need to mess with identifiers?

[LCMark]

OK, I'll check it again but it looked like things were being initialised to nil already if default was nil... yep... they are initialised correctly...

Right - but if default_value is nil it doesn't check the argument count and so will try and execute fetch__* as appropriate which will cause badness...

I think you'll need to add an 'is_optional' bool to HandlerParameter and fill it in appropriately; then modify InterfaceGenerateHandlers() to not generate the fetch logic if default_value is nil. Also probably best to add a RULE check in InterfaceDefineHandlerParameter so that only types that are passed as pointers (c-string, objc-string, objc-number, objc-data, objc-array, objc-dictionary) can be optional without default_value.

So... looking at boolean defaults now. It's fairly easy if the default value is a quoted string rather than an unquoted one... default "true" vs default true... Is that reasonable... or do I need to mess with identifiers?

I suspect that's why it was left as a 'TODO' item... Although it looking at the code, it would be easy enough to do it 'properly' and use true / false as they can be added as keywords and processed appropriately in ParserMatchConstant. Also seems I never wrote the API for boolean ValueRefs...

[monte]

arrgh... working on this thing is horrible... it all looked good until I started testing

Giving up for the moment... hopefully I'll find some more time tonight or tomorrow..

[monte]

I think I've worked out my issues with this thing... I still need to do some testing with some real externals to make sure everything works as expected

[monte]

@runrevmark If I understand what you are doing here we will be able to declare java methods in our lcidl but the same external could declare C functions? So... can we remove the #ifdef TARGET_OS_IPHONE surrounding libexports? And then #ifdef out just the android specific stuff so se can generate JNI stubs for desktop too...

[LCMark]

@monte: As it stands on the branch I'm working on, if you define a 'java command', or 'java function' then all this means that lcidlc generates a native code stub for the external handler that calls into Java - so the actual implementation you write is Java. This extra stub is only compiled on Android, so you can use the same IDL file (and indeed, the same source file it generates) for both Android and iOS.

The 'libexports' stuff is iOS specific (since there is no dynamic libraries allowed on iOS device builds).

In terms of JNI stubs for Desktop then it depends on what the purpose would be here - there is no JavaVM or any support for such currently in the engine so it wouldn't have much point at the moment. The reason to do this for Android is that Android is written in Java so you need to write the majority of stuff that talks to the system in Java.

EDIT: Also, the Android class libraries are essentially entirely different from standard Java - meaning code written for Android that does anything related system/UI related won't do anything on the Desktop.

[monte]

As it stands on the branch I'm working on, if you define a 'java command', or 'java function' then all this means that lcidlc generates a native code stub for the external handler that calls into Java - so the actual implementation you write is Java. This extra stub is only compiled on Android, so you can use the same IDL file (and indeed, the same source file it generates) for both Android and iOS.

That's what I was getting at.

The 'libexports' stuff is iOS specific (since there is no dynamic libraries allowed on iOS device builds).

Ah... sorry, my mistake. I see MCExternalDescribe etc are already extern...

In terms of JNI stubs for Desktop then it depends on what the purpose would be here - there is no JavaVM or any support for such currently in the engine so it wouldn't have much point at the moment. The reason to do this for Android is that Android is written in Java so you need to write the majority of stuff that talks to the system in Java.

Couldn't a JVM be created if an external is loaded that needs one?

EDIT: Also, the Android class libraries are essentially entirely different from standard Java - meaning code written for Android that does anything related system/UI related won't do anything on the Desktop.

Well... there's heaps of Java stuff that could be used that has nothing to do with android... arguably it would be better to find a C library that does the same job and use that but for Java devs that's not going to help much...