Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nw broken on OSX 10.13 because of objc #74

Open
stuta opened this issue Mar 29, 2018 · 8 comments
Open

nw broken on OSX 10.13 because of objc #74

stuta opened this issue Mar 29, 2018 · 8 comments
Milestone

Comments

@stuta
Copy link

stuta commented Mar 29, 2018

When I try to run nw_demo.lua in osx 10.13.3 I get:

[objc] cdef             size of C type is unknown or too large at line 4
	struct CGRect {
	struct CGPoint origin;
	struct CGSize size;
}
[objc] cdef             size of C type is unknown or too large at line 5
	struct AlertTemplate {
	struct Rect boundsRect;
	short itemsID;
	short stages;
}
[objc] cdef             size of C type is unknown or too large at line 10
	struct BasicWindowDescription {
	unsigned int descriptionSize;
	struct Rect windowContentRect;
	struct Rect windowZoomRect;
	void *windowRefCon;
	unsigned int windowStateFlags;
	unsigned int windowPositionMethod;
	unsigned int windowDefinitionVersion;
	void windowDefinition;
}
lj: ../objc/objc.lua:839: ../objc/objc.lua:286: bad argument #3 to '_' (number expected, got nil)
stack traceback:
	[C]: in function 'write'
	../objc/objc.lua:839: in function 'parse_xml'
	../objc/objc.lua:868: in function 'process_xml'
	../objc/objc.lua:873: in function 'load_bridgesupport'
	../objc/objc.lua:941: in function 'load'
	nw_cocoa.lua:14: in main chunk
	[C]: in function 'require'
	nw.lua:16: in main chunk
	[C]: in function 'require'
	nw_demo.lua:9: in main chunk
	[C]: at 0x0100001140
@capr
Copy link
Member

capr commented Mar 29, 2018

Thanks for the bug report! I can reproduce the problem but I can't fix it right now. I found some information about it on the LuaCocoa page though which I will copy/paste:

macOS 10.13 (High Sierra) introduced new bugs which broke their BridgeSupport format. They broke the format for compound structs (such as NSRect), nil terminated variadic methods & functions (e.g. NSArray arrayWithObjects), and removed the data in BridgeSupport which lists all the dependent libraries/frameworks for a given framework (which brnow will require you to explicitly LuaCocoa.import() all the frameworks you indirectly need).

I filed 3 bugs with Apple. If you depend on BridgeSupport for any of your projects, please file duplicates with Apple Radar and list these bug numbers in your bug reports. (Apple does count the number of bug reports and has influence over prioritization.)

5844688 10.13 broke BridgeSupport for compound struct definitions

35844763 10.13 broke BridgeSupport and compatibility with existing apps for variadic nil terminated methods/functions

35844832 10.13 broke BridgeSupport format for listing dependency framework information

@capr
Copy link
Member

capr commented Mar 29, 2018

I'll create a bug report in luapower/objc and close this one.

update: decided to keep this open, after all, this makes nw incompatible with OSX 10.13 until this is fixed.

@capr
Copy link
Member

capr commented Mar 29, 2018

Moved to luapower/objc#5

@capr capr closed this as completed Mar 29, 2018
@capr capr reopened this Mar 30, 2018
@capr capr added this to the r1 milestone Mar 30, 2018
@capr capr changed the title OSX: size of C type is unknown or too large nw broken on OSX 10.13 because of https://github.com/luapower/objc/issues/5 Mar 30, 2018
@capr capr changed the title nw broken on OSX 10.13 because of https://github.com/luapower/objc/issues/5 nw broken on OSX 10.13 because of objc Mar 30, 2018
@stuta
Copy link
Author

stuta commented Jun 20, 2018

Tested in 10.13.5, does not work.

@capr
Copy link
Member

capr commented Jun 20, 2018

No wonder. I don't think they'll fix it. I see a few options:

  1. copy good bridgesupport xml files from a good OSX version to your app and deploy them with your app (and add your path to objc search paths).

  2. investigate how Swift gets type info for Cocoa (I don' think they'll ever break that) and rewrite objc.lua to do the same.

  3. implement a type info cache system in objc.lua, run the app on a good OSX then deploy the app with the cache files so that it won't break when run on OSX 10.13. this is a good idea even if bridgesupport files weren't broken because it speeds up app startup.

Btw, I don't think I'll personally start working on options 2 or 3 time soon unless I need this for a future app, but feel free.

@stuta
Copy link
Author

stuta commented Jun 20, 2018

Wouldn't option 1 be easy to do? Obviously you have older system version, just copy files to repo and use them.

@capr
Copy link
Member

capr commented Jun 20, 2018

I'm not sure what's the licensing on those files.

@stuta
Copy link
Author

stuta commented Jun 20, 2018

Caching only those few broken definitions on startup and saving them as json or text files should be as easy as manyally copying and pointing to them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants