Undeclared variables?

[jporkkahtc]

I thought all variables in Slick had to be declared, even the built in ones.

But I came across "_LCRight", which isn't declared anyway that I can find.
Nor documented or anything, but it is used plenty often.

What are the "LC" variables and functions for?

Why aren't they declared anywhere?

[Graeme]

_LCRight is a function not a variable - there's different #pragmas for them..  Search for strictprotos in the help - default is off.  For variables there is autodecl.

When enabled, all function calls require the function to be previously declared or imported. When disabled, when the Slick-C compiler encounters a function call to a previously undefined function, it assumes that the function is a global function. The function call is resolved at link time, and an error will show up at run time if the function does not exist or is not provided enough parameters. This option is automatically enabled within classes and namespaces.

I don't know what "link time" is - I thought it was resolved at runtime if you have it turned off.  I thought slick always calls functions by looking up the names table at run-time but I could be wrong as it would be slow - even with a hash map.

[jporkkahtc]

I pasted the wrong thing, I meant "p_LCHasCursor", which is a variable.
         if (p_LCHasCursor && _LCIsReadWrite()) {
            _LCRight();
         } else {
            wordwrap_right(def_cursorwrap);
         }


What I was trying to do was find a way to go to a *character* position in a file, not a byte position.
I have some tool that is logging character positions in source files, even when the source file is utf-8 encoded, and trying to go to the right place in Slick is challenging.

I thought I might start by looking at the cursor movement functions, since hitting the right/left arrows moves by characters, despite "p_col" is apparently reporting bytes.

But, it seems the only way would be to call right() in a loop and count how many times it takes to get to the end of the line :-(
Or call next_char() "n" times, where "n" is the character position in the file - but seems like this might be slow with a really big file - and it probably won't do things quite right due to tabs settings, mode, or other corner cases.

[jporkkahtc]

WRT name lookups: Clark has hinted a bit about how slickc works internally, but hasn't really given away the implementation details.

When a module is reloaded, all references to functions/variables in that module from other modules still work, which is apparently a neat trick - other languages (like python or java) can't do this.

A hash table lookup would be quick enough if you cache the hash of the name and don't have to compute the hash to do the lookup.

Not everything is that dynamic though, as reloading a module will sometimes cause errors (with timers specifically), which have function-pointers to functions in that module.
I haven't really explored this to find if pointers to functions/variables are invalided in general, or is there something timing specific going on when this failure happens.
I suppose then that a function-pointer could really be the hashcode of the function name in the global names table.

(libs and DLLs ought to have done a hashtable for name lookup, but AFAIK they don't. For DLLs with lots of symbols it would make loading a lot faster and would allow you to drop the full name and save space - great for C++ mangled names).

[Clark]

Not everything is that dynamic though, as reloading a module will sometimes cause errors (with timers specifically), which have function-pointers to functions in that module.

At some point we need to fix how static functions are linked. That way pointers to them (often timers), don't cause a slick-c stack when a module is reloaded. This is definitely fixable. The cost will be extra memory for static symbols. No speed hit.

[Graeme]

I use _on_load_module to kill timers in my slick macro code so a stack doesn't occur.  It works.

[Graeme]

What I was trying to do was find a way to go to a *character* position in a file, not a byte position.
I have some tool that is logging character positions in source files, even when the source file is utf-8 encoded, and trying to go to the right place in Slick is challenging.

Maybe you can use _GoToROffset() - if you know the file encoding and you have control of how a file is loaded.  I wonder how slick implements _GoToROffset.  Alternatively you could set up a table of values for each buffer in the background or when a file is loaded or saved so there's no speed hit.  e.g. for each line, calculate the number of characters before that line.

[Clark]

_GoToROffset() does a seek in bytes even if the file is converted to Utf-8 (Unicode mode). This works well for doing raw seeking but you want the file stored in either UTF8 or active code page so you can load the file without SlickEdit converting the file data when loading.