[NTLUG:Discuss] Re: has anyone used Alexandria?

[Bryan J. Smith]

On Sat, 2004-12-18 at 08:26, Kevin Brannen wrote:
> Suse 9.2

I assumed you were on Debian (I must have you confused with someone
else), and was wondering why you were doing it manually.

> They make it sound so simple don't they?

Yeah.  Scripting language modules seem to be simple, but I've run into
some issues where a Perl program had me running around in circles on
what modules to install.  And that's just on Linux (it's impossible on
Windows most of the time -- at least without the ActiveState Perl
Developer Network).

> With the help of a Ruby/Gnome person on IRC I managed to make it all 
> compile ad install (I couldn't tell you everything he had me do if my 
> life depended on it, the list was that long and unknown to me -- hey, I 
> never done Ruby before. :-)  But it still won't run!
> If I run it in a plain xterm, it says:
> /usr/lib/ruby/site_ruby/1.8/alexandria/ui/about_dialog.rb:20: undefined 
> superclass `About' (TypeError)
>         from /usr/lib/ruby/site_ruby/1.8/alexandria/ui.rb:25:in `require'
>         from /usr/lib/ruby/site_ruby/1.8/alexandria/ui.rb:25
>         from /usr/lib/ruby/site_ruby/1.8/alexandria.rb:57:in `require'
>         from /usr/lib/ruby/site_ruby/1.8/alexandria.rb:57
>         from /usr/bin/alexandria:7:in `require'
>         from /usr/bin/alexandria:7
> which means it can't find some basic UI class (or so the guy told me).  
> But if I set RUBYLIB to 
> /usr/lib/ruby/1.8:/usr/lib/ruby/site_ruby/1.8/i686-linux and run it I get:
> (process:21213): GLib-GObject-CRITICAL **: gtype.c:2253: initialization 
> assertion failed, use g_type_init() prior to this function
> /usr/bin/ruby: symbol lookup error: 
> /usr/lib/ruby/site_ruby/1.8/i686-linux/gdk_pixbuf2.so: undefined symbol: 
> rbgobj_define_class
> which basically means it can't find glib2.0.so, or maybe it finds it in 
> the wrong order, which stumped the IRC guy.  Until last night, I was 
> going to say "I *will* make this work!"  I'm not so sure I'm going to 
> take that attitude now. :-(  I may be invested enough time in it, and I 
> should just give up and work on another program I found (Thokbook) that 
> actually does work, but is a bit primitive -- which I can fix. :-)

I hear you.  Sounds like the developer really didn't get specifics
down.  You may need a different version of the libraries, etc..., stuff
that is difficult to solve without distributed package management.

> This really makes me long for the days of C and X/Motif,

Which is one of the reasons why I avoid a lot of tools that have full
KDE or GNOME bindings, and prefer just Qt or GTK+.  So I do understand
your points.

BTW, do you mean C and X/Motif, or C and X/Xt?  Because there are a
number of C programs that use Xt directly (with some GTK+ hints without
GNOME).  They are very fast and light.  Although X/GTK+ or X/Qt aren't
much slower either.

> as then all the support libs (minus X & Motif) I needed would be sub-dirs
> and readily available.  This also makes me more fully understand why
> some people think Linux is hard, something for me to keep in mind when
> I work on future packages for others.

Well, if you are a developer, I don't care what OS you're developing
for, some tools are just "hard" in general.  Debian continues to be one
of the most ideal "packages" distributions out of sheer package number,
including addressing the endless set of scripting language modules, for
developers.


-- 
Bryan J. Smith                                    b.j.smith at ieee.org 
-------------------------------------------------------------------- 
Subtotal Cost of Ownership (SCO) for Windows being less than Linux
Total Cost of Ownership (TCO) assumes experts for the former, costly
retraining for the latter, omitted "software assurance" costs in 
compatible desktop OS/apps for the former, no free/legacy reuse for
latter, and no basic security, patch or downtime comparison at all.