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?
>
> objects:
> - inheritance is annoying with C, probably do it like:
> struct irc_server { struct server server; ... }; to keep type
> safety. A bit annoying to access server struct though.
> - reference counting is needed, especially for Perl interface
> - there aren't many objects, so they could contain extra data
> set by plugins/scripts (especially the perl plugin itself)
> - except for nick object. should it be special case?..
>
again, GLib. why not use GObject?
> signals:
> - requires better type safety. at the very least change the
> signals to emit a single parameters-structure instead of
> a number of C pointers, and check that the parameters are
> what the signal expects.
> - that could still lead to runtime errors. maybe we should have
> a separate signal_emit() function for each signal? .. would
> generate more code though, but much less chance for runtime
> errors.
>
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.
> perl:
> - keep the perl objects permanently in memory, attach it with
> the extra object data. it's created when object is first used
> in perl, it's destroyed when object itself is destroyed
> - update object's reference counter while perl object's refcount
> is updated. so it's possible to store object permanently to
> perl's memory and access it even when C code has already
> forgotten it -> scripts can't crash irssi
>
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.
anyway,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,php,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
