[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Idle 0.10 alpha
- From: Duck <duck@...>
- Date: Sat, 22 Sep 2007 15:45:17 +1000 (EST)
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...]
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
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
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
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.