Hello,
i thought that to conserve the space, it would be good to use a symbols for primitive name and module name in my methods. Since all of my native-boost enabled methods using same primitive, so i thought that i can just put following: <primitive: #primitiveNativeCall module: #NativeBoostPlugin> and therefore, save some space , since declaration like following: <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> adds extra two strings to the pragma, which attached to method. (What is interesting, that a first literal of compiled method, using symbols for these names, instead of strings.. While pragma keeps original copies of strings, and therefore wasting extra space, which i want to avoid). What i found, that syntax highlighting turns the rest of method's source in red color (like if there is a parse error), while parser is perfectly ok with such syntax, and accepts such methods without any problems. Moreover, its 100% safe to use symbols instead of strings for prim/module names, since they seem used by compiler anyways, and i even double-checked it with VMMaker, that it can handle symbols instead of strings for named primitives. >From Interpreter's comment: primitiveExternalCall "Call an external primitive. The external primitive methods contain as first literal an array consisting of: * The module name (String | Symbol) * The function name (String | Symbol) so, a syntax highlighting is a bit annoying, and i'd like to fix that. Any clues where to look at? -- Best regards, Igor Stasenko AKA sig. |
Hi Igor,
On Thu, Apr 22, 2010 at 8:23 PM, Igor Stasenko <[hidden email]> wrote: Hello, Look at STParserST80>>parsePrimitive. Abstract the "self failUnless: currentTokenFirst == $'. self parseString"'s to a method or block and make them accept either strings or symbols and email me the fix :)
HTH Eliot
|
Thanks,
here it is. On 23 April 2010 07:36, Eliot Miranda <[hidden email]> wrote: > Hi Igor, > > On Thu, Apr 22, 2010 at 8:23 PM, Igor Stasenko <[hidden email]> wrote: >> >> Hello, >> >> i thought that to conserve the space, it would be good to use a >> symbols for primitive name and module name >> in my methods. >> Since all of my native-boost enabled methods using same primitive, so >> i thought that i can just put following: >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin> >> and therefore, save some space , since declaration like following: >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> adds extra two strings to the pragma, which attached to method. >> (What is interesting, that a first literal of compiled method, using >> symbols for these names, instead of strings.. >> While pragma keeps original copies of strings, and therefore wasting >> extra space, which i want to avoid). > > Look at STParserST80>>parsePrimitive. Abstract the "self failUnless: > currentTokenFirst == $'. self parseString"'s to a method or block and make > them accept either strings or symbols and email me the fix :) > HTH > Eliot >> >> What i found, that syntax highlighting turns the rest of method's >> source in red color (like if there is a parse error), >> while parser is perfectly ok with such syntax, and accepts such >> methods without any problems. >> >> Moreover, its 100% safe to use symbols instead of strings for prim/module >> names, >> since they seem used by compiler anyways, and i even double-checked it >> with VMMaker, that it can handle symbols instead of strings for named >> primitives. >> >From Interpreter's comment: >> >> primitiveExternalCall >> "Call an external primitive. The external primitive methods >> contain as first literal an array consisting of: >> * The module name (String | Symbol) >> * The function name (String | Symbol) >> >> so, a syntax highlighting is a bit annoying, and i'd like to fix that. >> Any clues where to look at? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > > -- Best regards, Igor Stasenko AKA sig. shparser-fix.1.cs (992 bytes) Download Attachment |
Free forum by Nabble | Edit this page |