10,000 Line Limit for Extensions

[PaulDaMacMan]

FYI:
Apparently there is a 10,000 lines of code limit (which in my current case is about 2.4mb of data in 12,285 lines) for Extension Builder compilation.
I'm using v.9.x, I gather there have been some changes in 10.x so perhaps this limit doesn't apply to v.10.x LCB?

Since this current project did not actually need to be written in Extension Builder and rather then trimming it down or slicing it into seperate <= 10,000 line modules, as a work around I converted the code to regular LCS / xTalk script and now it loads all of it just fine (and surprisingly fast).

9,999 Seems like a rather arbitrary limit to me so I'll be looking to find/eliminate that limit at a later time.

[PaulDaMacMan]

Not sure if this issue was ever resolved, but it would probably be helpful for this situation if it were:
https://forums.livecode.com/viewtopic.php?t=28086

The comment from HH and reply from Dr. Peter Brett provides a basis for the work-around, which is to slurp a files contents into a Data type variable and then using the <builtin> internal FFI bind string mentioned to convert the Data type to String type.
It seems the stalled development was due to some uncertainty about reading multi-byte unicode characters, but I'm currently only interested in parsing files with ASCII text in it anyway.

So thanks to Dr Brett's Understudy project source, here's the working code (just now tested) to convert a Data type variable to a String type:

Code: Select all

foreign handler MCStringEncode(in Source as String, in Encoding as CInt, in IsExternalRep as CBool, out Encoded as Data) returns CBool binds to "<builtin>"
foreign handler MCStringDecode(in Encoded as Data, in Encoding as CInt, in IsExternalRep as CBool, out Result as String) returns CBool binds to "<builtin>"
public handler DataFromUTF8(in pString as String) returns Data
	variable tEncoded as Data
	unsafe
		MCStringEncode(pString, 4 /* UTF-8 */, false, tEncoded)
	end unsafe
	return tEncoded
end handler
public handler DataToUTF8(in pData as Data) returns String
	variable tString as String
	unsafe
		MCStringDecode(pData, 4 /* UTF-8 */, false, tString)
	end unsafe
	return tString
end handler

[mwieder]

Ack! I've been working on writing gtk foreign handler libraries in LCB and will soon hit the 10k line limit.
Guess it's time to give up on LCB again.

[stam]

Just out of curiosity - is it not possible to parcel out code to LCB libraries and load them, to avoid hitting the 10K line limit?
S.

[PaulDaMacMan]

Ack! I've been working on writing gtk foreign handler libraries in LCB and will soon hit the 10k line limit.
Guess it's time to give up on LCB again.

GTK foreign handler library? Awesome! Just split it up into separate modules...

Just out of curiosity - is it not possible to parcel out code to LCB libraries and load them, to avoid hitting the 10K line limit?
S.

Yes, I'm fairly certain that I could've split it up into separate Builder modules, and then use the 'use' keyword to import those modules, the same way you do with the built-in / included modules. The one thing I'm not sure about is where you would store those sub-modules because the Extension Builder stack will only compile one module at a time and fails if the folder contains more than 1 file with a *.lcb extension.

Again, LCS doesn't have this limit and in fact the IDE's revIDELibrary stack is over 12,000 lines of script, so if you can do your thing in LCS instead of LCB then that is a possible option too.

What I was doing was a scripted wrapping the Material Icons SVG font into a library similar to IconSVG, but after finding Dr. Brett's comment I re-wrote the LCB using the code I posted to read in spread-sheet-style .tsv (tab-separated-values) files with the glyph name/SVG path data one per line. Now I have a very small LCB library that loads 6,063 (all of Material 4.0) symbol icons in about 0.5 seconds, and can load any other SVG 'fonts' from tsv file too. I also made a stack for parsing *-webfont.svg files converting into the tab-separated format.

I also included a demo palette stack (that is useful with or without this new library loaded) meant for browsing SVG Icons and drag-n-dropping SVG Icons into stacks. (Hold alt/option key when opening to topLevel the stack and allow editing).

It's still very much a work in progress, need to add some error checking and I'm planing to add the .svg-to-.tsv parsing as an LCB handler (currently in a stack script) or maybe have it load directly from the *-webfont.svg (which is XML format). I also want to add some other more general SVG Path manipulation handlers (such as retrieve a new SVG path with a flipped or stretched transform applied to the original SVG Path).

Anyway, it's basic functionality is already working now, LCB source code is here:
https://github.com/OpenXTalk-org/org.op ... GIcons.lcb