 |
lua-l archive |
|
|
||
|
A quick skim over your site results in quotes like this: "Idle is not Lua. Sure, Idle is *based* on Lua and it tries to be as compatible as possible. But in the end it is a separate application..." It IS lua [...snip...] [...snip...] You did not write a scripting language, stop stating that you did. Release this stuff as proper lua modules [...snip...]
C'mon...give the bloke a break. Every time Idle comes up on this list there's a harsh backlash which boils down to "how dare you do something you thought was useful."
_I_ have some problems with Idle, including:1. It's _definitely_ a silly name, since Idle is already fairly well known as a basic IDE in the Python world, so the choice was poor.
2. It's _possibly_ a slightly arrogant name, and I'm sure most of us would be happier if it were "LuaSomething" or "SomethingLua."
3. It's Windows only, which happens to make it useless to me. (I am looking for portability across Windows, Linux and the BSDs.)
On the other hand:4. It's palpably _isn't_ Lua, since there are some incompatibilities in the core, so "Luasomething" or "SomethingLua" would _probably_ be confusing.
Thomas, perhaps, if you explicitly labelled it "Idle, a Lua-based scripting language," you could please more of the people more of the time. (Of course, you need IMO to find a name other than Idle, but that's a separate issue.)
Another thing: if I were you I'd also offer an EXE which is statically linked, so you can make a single-file program (no DLL required). Where the DLL is useful is if you have multiple Idle EXEs, so each EXE is much smaller.
For these cases I suggest you also offer a non-UPXed version of the DLL. The usual reason for offering a DLL is so that multiple EXEs can load it at the same time, thus saving space. But a UPXed DLL can waste a lot of physical memory, since the DLL's decompressed code pages aren't shared between all the EXEs linking to it (as they are, for instance, with KERNEL32.DLL and USER32.DLL). This is because the in-memory UPX decompression causes a copy-on-write of all the code which is decompressed on the fly, even though that code ends up the same as in other instances of the DLL. After all, to the Windows loader they aren't code pages mapped in from the binary image -- the final in-memory code pages are marked as uninitialised data pages in the image file. These data pages are then written to separately by each copy of the DLL as it loads.
I haven't explained that very well. But UPXing a DLL which gets loaded more than once means you end up with the DLL's code in memory, as non-shared data, multiple times. A DLL with code pages that are identical across multiple instances of that DLL in memory will share those code pages amongst all the copies. This can save a lot of (physical) RAM.