On Fri, Jan 17, 2003 at 07:13:34PM +0100, Alexander Demenshin wrote:
> > I've had at least a few rewrite plans before, but they've pretty much
> > sucked. Now, I think I'm finally enlightened enough and could actually
> > design a good new irssi.
>
> Does it mean that development of current vesrion will be discontinued
> completely?
Well, it hasn't had much development anyway for some time.
> > get nowadays are rarely usable, I just know that "something" happened
> > "somewhere" which caused this crash later (heap corruption). I'd guess it's
>
> Did you ever tried valgrind to track the sources of the problems? :)
Yes. It's usually the scripts. There's a lot of different ways buggy scripts
can crash irssi. For example sending signals with wrong parameters types or
accessing structures that have already been free'd from C code.
> > So, new plan is basically: Write code that doesn't crash. Ever.
>
> You have to use some interperted language to write such code (or spent
> infinite amout of time writing this in C - large C projects are never
> crash-safe).
I think they could be :) I've some experience now with my IMAP server
(dovecot.procontrol.fi), it hardly ever crashes and it's always been to some
assert or NULL pointer access. I've yet to see a single crash in it that I
couldn't explain immediately. Of course, IMAP server is easier than IRC
client since it doesn't require much permanent data.
> > - still C. it's the language I know well and like :)
>
> Why not C++? May be it worth to study C++ a bit more and use it? :)
I don't see that much advantages in C++. And I tried for a while to design
irssi in OO-style with C++, but I didn't like at all what it looked like. So
if I used only a couple of C++ features but mostly C-style coding, it'd just
annoy all the C++ programmers ;)
> > - void pointers lose type safety, avoid them
>
> Prefix every allocated data structure with type tag and make a macro
> instead of direct casting. Something like:
Yes. Something similiar is already in irssi, it assumes that the pointer
begins with "int type" and uses it to check what object the pointer actually
points to.
> struct object {
> int __tag;
> void *self; // Assigned upon allocation
> ... declarations here ...
> }
This would be safer of course.
> > use string and buffer APIs.
>
> This may also be used to access regular strings, so you will avoid any
> problems including NUL.
Possibly. That'd just require to rewrite/wrap many of the libc functions. I
don't see char*s as that bad :)
> > - if it requires coder to be careful, it's usually badly
> > designed
>
> Did you forget about unexperienced coders? Nothing is safe in C for them :)
Yeah, they can do a lot of things wrong. The above comment was meant for
people who actually know the language, but might design difficult or unsafe
APIs.
> > - free() is dangerous, avoid it when possible
>
> Alternatives?
For permanently stored data, not really. "when possible" are the keywords :)
> > - garbage collectors would help, but they don't work well
> > with Perl (leaks a lot)
>
> True. So make your own :)
Too difficult I'd think. Especially if it should be somewhat easy to use and
portable. Hmm. Maybe it could be made to work better with Perl. I think the
problem with current irssi code is that the Perl objects contain pointers to
C objects, but they're never cleared. That could be done..
> > - possibly create a string memory pool which allows
> > defragmenting by moving the data (special pstring_t type)
>
> This it what you call "overdesign" :) Fragmentation is not always so bad.
Yeah, it has "possibly" there :) I'm not sure how bad the fragmentation
would be, maybe not too bad. That could anyway be added later easily, so I
won't begin with it.
> > So if ^S was pressed, irssi should continue on the background
> > until ^Q was pressed, when it would just redraw the screen.
>
> Virtual terminal emulation, a-la screen? So when output is blocked, it
> still gets filled, and once unblocked it will redisplay the content.
No, a simple irssi_redraw() function that gets called. You can already do
that with ^L.
> > Good internal iconv() support, to allow very simple to use UTF-8
> > support.
>
> Would be nice to have embedded charset conversions too...
Embedded? I'm not sure what you mean.
> > Internal scripting? The current $vars are quite near scripting
> > themselves. Maybe we should have some very simple language to use in
> > themes, statusbars and such.
>
> Small, simple but powerful?
Not necessarily powerful. For more powerful there would be Perl and maybe
others.
> There are two options - the one used in jed
> and ICI (this one also has C-like syntax, powerful data structures and
> core is small enough to embed; easily callable from C).
Have to look at that. I'm not really sure what the scripting should actually
look like. At least it'd have to be easy to use within themes and statusbar
items, something like nick = "$indent(<$0$1>, 10)"
