On Sat, 2003-01-18 at 02:57, Nikolai :: lone-star :: Weibull wrote: > On Fri, 17 Jan 2003 19:27:01 +0000, Timo Sirainen wrote: > > memory management: > > - heap allocations aren't exactly fast and it gets fragmented > > - free() is dangerous, avoid it when possible > > - garbage collectors would help, but they don't work well > > with Perl (leaks a lot) > > - use allocate-only memory pools and data stack for temporary > > memory allocations. fast and safe. > > - possibly create a string memory pool which allows > > defragmenting by moving the data (special pstring_t type) > > isn't there lots of GLib code for things like this?
Not really. There's some kind of memory pool for allocating multiple objects with same size. > again, GLib. why not use GObject? .. > yet again, GLib has signals. I don't know how they work or what they > are for, never used GLibs signal facilities, but they could perhaps be > used. Irssi has always been based quite heavily on GLIB. xirssi and original gtk irssi was also based on GTK, which is based on GObject and GSignals. GLIB is heavily based on dynamic memory allocations. Without relying on garbage collector that's a real pain to free all the memory you've allocated. GObject and GSignals aren't type safe. They check errors at runtime (assuming used properly), but it's much better to be able to find errors at compile time before they even happen. GSignals don't really fit into irssi's usage, they're more about emitting and catching a signal for a single object, while irssi likes to catch a signal for all objects. I've used GLIB for maybe 4 years now. It's much better than using libc directly, but using the library I've been writing for the past year has been a _lot_ easier (as well as faster and less memory intensive). And since I already have most of the required library code written, there's not much need to use GLIB anyway :) > perhaps try to make as much of stuff a part of the Perl scripting > language. Don't keep /notify command in irssi, but move to a perl > script? look at XiRCON: has never crashed on me, and i've used it since > the first release... > there aren't many commands that actually need to be kept in irssi (and > C) even for added speed. Make the interfacing clean, simple, and > correct and you probably solve a lot of issues, and make the design > cleaner. > > And how about using some other language (hint: Ruby)? Perl seems to be > a mess to interface with. I agree that scripts should hold as much of the features as possible, but I also think that irssi should be fully functioning for most people without external scripting language. You already note the worst problem, people want to use different scripting languages. People also install irssi in computers that don't have some specific language installed, Perl is quite safe nowadays since it's been around for ages. I'm IRCing from a computer that doesn't have Ruby installed, and likely will not be unless I install it into homedir. Supporting multiple scripting languages is good for giving script coders a choice, but annoying for users who want to use script done with multiple languages, possibly requiring them to install the language and at the very least use more memory. I won't be writing support for more than one language (very likely Perl), but that doesn't mean others can't write it. Irssi's core doesn't make any assumptions what scripting language you may be using.
