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.
10,000 Line Limit for Extensions
-
- Posts: 632
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
-
- Posts: 632
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: 10,000 Line Limit for Extensions
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:
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
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: 10,000 Line Limit for Extensions
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.
Guess it's time to give up on LCB again.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: 10,000 Line Limit for Extensions
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.
S.
-
- Posts: 632
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: 10,000 Line Limit for Extensions
GTK foreign handler library? Awesome! Just split it up into separate modules...
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