lin-club  

Re: r2llib-0.08 and biditext-0.04 "sniffing baboons" release

Orr Dunkelman
Tue, 24 Jul 2001 10:35:43 -0700

Available under R2L/tzafrir directory in the haifux site.

Orr Dunkelman,
[EMAIL PROTECTED]

A mathematician is a device for turning coffee into theorems"    -
Paul Erdos

On Tue, 24 Jul 2001, Tzafrir Cohen wrote:

> On Mon, 23 Jul 2001, mulix wrote:
> 
> > another night, another release. and it's not even dawn yet.
> > 
> > http://www.pointer.co.il/~mulix/r2l/biditext-mulix-0.04.tar.gz
> > http://www.pointer.co.il/~mulix/r2l/r2llib-0.08.tar.gz
> > 
> > * please help test biditext. get it, compile it, install it, run it.  *
> > * thanks to tzafrir for the rpm and doxygen stuff in r2llib *
> > * any X gurus know if XDrawString has a limit on the size of the string
> > it accepts for drawing? *
> > 
> > r2llib Changelog:
> > 0.08:
> >     added doxygen support and rpm support (tzafrir)
> 
> I decided that it would be nice to use such a system. Generally it means
> that every function should be preceded with remarks in a special (but not
> very complicated) syntax. There is a utility (doxygen) that extracts this
> documentation, along with the general structure, to generate API
> documentation. But even without this utility, I believe those comments
> make the code more eadable.
> 
> Any /** */ /** */ ?
> 
> The output can be found at:
> http://www.technion.ac.il/~tzafrir/R2L/r2llib-doc-html-0.09/
> http://www.technion.ac.il/~tzafrir/R2L/r2llib-doc-html-0.09.tar.gz
> 
> >     added packaging support to Makefile (tzafrir)
> 
> Well, I decided to play with library creatin a little. Currently the
> r2llib is an independent library (still static, though)  I have now added
> the compulsory r2llib-config (and also fixed a number of other small
> issues).
> 
> You can now get:
> 
> http://www.technion.ac.il/~tzafrir/R2L/r2llib-0.09.tar.gz
> http://www.technion.ac.il/~tzafrir/R2L/r2llib-0.09-2.i586.rpm
> 
> (I hardly see the point for others to use that binary rpm, when they can
> just as easily install from the tarball, or create a binary rpm from the
> tarball. But since I need it for my system, I might as well just post it).
> 
> Now I got to building biditext:
> 
> I had to change the makefile, and even the sources.
> The change in the sources:
> - #include <r2llib/r2llib.h>
> - #include <r2llib.h>
> 
> I think that it is the job of the nakefile to worry about the exact path
> of r2llib, right? or do we want to hardwire r2llib to be in
> <source_dir>/r2llib (or have the include files in a seperate r2llib dir
> under ${PREFIX}include/ )
> 
> Not a big deal, anyway.
> 
> http://www.technion.ac.il/~tzafrir/R2L/biditext-0.9.2.tar.gz
> http://www.technion.ac.il/~tzafrir/R2L/biditext-0.9.2-2.i586.rpm
> http://www.technion.ac.il/~tzafrir/R2L/biditext-menu-0.9.2-2.i586.rpm
> 
> The last package includes some menu items for the mandrake/debian menu
> system. It is in a seperate package because it depends on the mandrake
> menu system.
> 
> Next I'll package the diffeernt r2llib clients (beginning, probably, with
> the dock applet ;-) ).
> 
> > 
> > biditext-mulix Changelog:
> > 0.04:
> >     do_biditext8() and do_biditext16() now return the buffer on success
> >             and NULL on failure
> >     added internal 4096 chars limit test to do_biditext8() and
> >             do_biditext16()
> >     moved do_biditext8() and do_biditext16() into common.c
> >     commo8.c, common16.c - removed
> >     ripped out the biditext initialization code from
> >             init_biditext(), now it uses r2llib_init() only
> >     Makefile - made r2llib location relative to biditext dir
> 
> There are some noticable differences.
> 
> I tried running rxvt with and without biditext. In both I ran 'ls' on a
> directory that has a couple of subdirectories and compressed files.
> ls is aliased to: 'ls --color=auto -F' . Maybe color displaying with rxvt
> is a bit inefficient, and maybe it is just that this requires seperate
> XDrawString calls.
> 
> /bin/ls doesn't have any noticable difference. But displaying a
> colored 'ls' takes long (around 2 seconds from 10 lines of text with no
> scrolling).
> 
> I checked this also with biditext 0.0.3, and 0.0.3 seems to perform well.
> 
> Maybe the problem is with the checks of the codepage of the font.
> 
> (Hmm... This project started as something of a GUI to biditext)
> 
> -- 
> Tzafrir Cohen
> mailto:[EMAIL PROTECTED]
> http://www.technion.ac.il/~tzafrir
>