[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Extension language

From: zander
Subject: Re: [Gnu-arch-users] Re: Extension language
Date: Sat, 18 Oct 2003 09:48:48 +0200

On Fri, Oct 17, 2003 at 04:38:11PM -0500, Charles Duffy wrote:
> On Fri, 2003-10-17 at 15:51, address@hidden wrote:
> > This is very true; having had a indexing engine based on smbclient I can
> > attest that its really horrible to support different versions.
> > Things like global settings files turning off certain input levels can
> > also totally make your life horrible.
> > Having the application i18n-ed totally stops any keyword parsing in total.
> Eh? So have a particular "translation" that you maintain that has
> nothing but easy-to-parse strings, and set the appropriate environment
> variable before starting the subprocess. Suddenly your job just got
> easier.

You do know that translations have to be seperately installed, and compiled,
don't you?   If the user does not have the encoding enabled and 'compiled'
your lost.   And have you ever tried to convince your machine to talk german
(for example) to you in your shell?  I can promise you that normal users don't
have any idea how to do that.
This effectively is a lot harder then any other solution I have seen.
Are you talking from experience; or just think this might be a cool solution?

> > >   SCSH process notation (the whole ball of wax in a neat little package):
> > > 
> > >
> > 
> > Thats a nonsense suggestion; for starters since it only works from c/c++
> > Does it work from Java? Perl? Python?
> > We were talking about support from several programming languages; this
> > won't cut it.
> Sure it (subprocess control w/o an intervening shell) works from Perl or
> Python, and I'm pretty sure Java. Likewise on win32.

The above (scsh) does not provide it; system calls /bin/sh, so how is this
done?  Making a technical decision based on "I'm  pretty sure Java can.."
is rather weak since I just told you it can't.  So you would really be better
off providing really good evedence instead of just calling me (implictly) a
Btw; if you do know of a way to sidestep a shell; then you also can't put
env variables in your shell-environment anymore.  Making your first argument

> I'm not going to answer the rest of your message point-by-point. To put
> it simply, though: I think a C API is a Good Thing -- but I also think
> the "issues" you raise with a subprocess-based API have readily
> available solutions.

I'm afraid that those solutions (which I would call workarounds) are not
adequate, if only because they are not well known or are worse then the thing
they try to prevent.

My point in the email you replied to was that Tom only said "no you are wrong"
kind of arguments, which really did not contain any viable arguments at all.

I really hope that you guys take advantage from each others experiences here;
and start to act a bit more mature,  since 'yes'/'no' fights without content
are really boring to look at.
And the resulting software is also going to be really weak.

Thomas Zander

Attachment: pgpBLlwDOhlok.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]