Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

"Bradley M. Kuhn" <[EMAIL PROTECTED]> writes: > That doesn't sound that unreasonable. I think, if I understand you > correctly, is that it would be possible to do everything with Perl > rather than Guile, but that it would not be part of the official > GNUcash distribution nor would it be suppor

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

[EMAIL PROTECTED] writes: > Turns out (duhh) tightly intertwining html with code is a bad idea, > whether that is C or perl or scheme. So I'd strongly advise against > the style shown above, other than maybe as a test case/scaffolding. Right. I just meant to use it to replace what we have now,

Maybe Coming Time to XML?

The "special markup language" idea morphs very naturally over to that of using XML as the format; this has the merit that it is: a) Somewhat understood; b) "Sexy" and widely believed-in. I agree that the flexibility limits probably aren't that much of a real issue. The killer issue for *any* of

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

It's been rumoured that Rob Browning said: > > You can give the HTML widget an HTML string, yes. > > > > As I understand it, the way report generation works now is that > > eperl is invoked on an html file with embedded perl commands which > > use the perl<->engine bindings to calculate the value

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

It's been rumoured that Dave Peticolas said: > On a related note, can you build without nana? > > Has anyone used nana? Right now, we just seem > to be using it as a replacement for 'assert'. I'm not married to nana. It doesn't do all of the things I would have liked it to do. In particular, I

Re: Problems compiling from CVS

It's been rumoured that Bruce Z. Lysik said: > Still can't find table-gnome.h, however. And it's not being pulled > down with my updates, or checkouts. I'd failed to get it into cvs. Its should be there byt the time you read this. --linas -- Gnucash Developer's List To unsubscribe send empty

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's

It's been rumoured that Tim Mooney said: > >> use a new HTML widget, GtkHTML. We've had problems with XmHTML. Curretnly, its use is isolated to one file and changing to something else should be straigh-forward, since no sophiosticated hooks are used. --linas -- Gnucash Developer's List To u

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

It's been rumoured that Bradley M. Kuhn said: > What do you think about a Perl interface that is directly in XS? I don't think anyone is in a position to turn down patches that integrate well, configure scripts that work, and code that works. Since you're painting something that's better tan swig

Re: Perl in internals (was Re: A bit off topic---Java as "SUN'slanguage" (was Re: Java implementation))

In regard to: Re: Perl in internals (was Re: A bit off topic---Java as...: > >> As long as we're talking about what components to swap out, it was reported >> on the gimp list today by Federico Mena that the GNOME project is dumping >> the use of GtkXmHTML, the Gtk port of XmHTML. He indicated

Re: Problems compiling from CVS

> "R" == Rob Browning <[EMAIL PROTECTED]> writes: R> First thing to try (presuming you have autoconf installed). [snip instructions] Tried all that, and same results. One odd bit, autoconf was complaining because I didn't have mawk installed. As a quick fix I just made a symlin

Re: Problems compiling from CVS

> Hi folks. > > I've checked out the CVS version of gnucash, and am attempting to make > the gnome version. It had compiled successfully before, but after a > recent update, it now fails. > > make[2]: Entering directory `/home/workspace/gnucash/src' > gcc -Wp,-MD,obj/gnome/MultiLedger.d.tmp -c

Re: Problems compiling from CVS

[EMAIL PROTECTED] (Bruce Z. Lysik) writes: > Hi folks. > > I've checked out the CVS version of gnucash, and am attempting to make > the gnome version. It had compiled successfully before, but after a > recent update, it now fails. > > make[2]: Entering directory `/home/workspace/gnucash/src'

Problems compiling from CVS

Hi folks. I've checked out the CVS version of gnucash, and am attempting to make the gnome version. It had compiled successfully before, but after a recent update, it now fails. make[2]: Entering directory `/home/workspace/gnucash/src' gcc -Wp,-MD,obj/gnome/MultiLedger.d.tmp -c -g -O2 -I/usr/

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

Dave Peticolas <[EMAIL PROTECTED]> writes: > On a related note, can you build without nana? I'm not sure. Some of the code is set up that way, but I don't know if all of it has, and I don't know if configure's happy about that. In the long run, I suppose it should be controlled with --enable-de

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

> Not planned. I think the overall idea is to move the swig/perl stuff > off into its own partition, and if configure can't find the right > bits, it just doesn't get built. Or perhaps we should just have a > --enable-perl so you have to ask for it. Ok, that makes sense. It will make gnucash ea

Re: SQL backend

Pat Spinler <[EMAIL PROTECTED]> writes: > I can't speak for Rob Coker, but I'm only talking about making a SQL > backend a "one of many" option, and probably not the default one for > all the reasons you mention. Ok, I figured we might have been speaking at cross-purposes... -- Rob Browning <[

Re: SQL backend

Rob Browning wrote: > > "Rob Coker" <[EMAIL PROTECTED]> writes: > > > I'm not quite sure why PostGreSQL is untenable. > > (First let me say that I'm addressing the issue of using something > like PostgreSQL across the board, rather than just as an option for > experts. If that's not what y

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

Tim Mooney <[EMAIL PROTECTED]> writes: > As long as we're talking about what components to swap out, it was > reported on the gimp list today by Federico Mena that the GNOME > project is dumping the use of GtkXmHTML, the Gtk port of XmHTML. He > indicated that it wasn't being maintained any more

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

Dave Peticolas <[EMAIL PROTECTED]> writes: > Will we be removing swig as well? Not planned. I think the overall idea is to move the swig/perl stuff off into its own partition, and if configure can't find the right bits, it just doesn't get built. Or perhaps we should just have a --enable-perl

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

> As long as we're talking about what components to swap out, it was reported > on the gimp list today by Federico Mena that the GNOME project is dumping > the use of GtkXmHTML, the Gtk port of XmHTML. He indicated that it wasn't > being maintained any more and had some other problems, so GNOME

Re: Perl in internals (was Re: A bit off topic---Java as "SUN'slanguage" (was Re: Java implementation))

In regard to: Re: Perl in internals (was Re: A bit off topic---Java as...: >I haven't looked into the current report generation stuff, and I'm not >really familiar with XmHTML, but would it be possible to just generate >a big string in scheme using call-with-output-string and then hand >that over

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

> Dave Peticolas <[EMAIL PROTECTED]> writes: > > > Are there plans for phasing out the eperl stuff and using > > something else for report generation? > > That's the general plan, though there's nothing too concrete at the > moment. Good :) eperl seems like a pain to install. I've never actuall

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

Dave Peticolas <[EMAIL PROTECTED]> writes: > Are there plans for phasing out the eperl stuff and using > something else for report generation? That's the general plan, though there's nothing too concrete at the moment. I haven't looked into the current report generation stuff, and I'm not reall

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

> It's been rumoured that James A. Treacy said: > > > However, I wondercould we mitigate the problems you describe by allow > ing > > > users who don't want it to turn off the option at compile time, and by be > ing > > > careful to control what access is given to the scripting language? > >

Re: SQL backend

"Rob Coker" <[EMAIL PROTECTED]> writes: > I'm not quite sure why PostGreSQL is untenable. (First let me say that I'm addressing the issue of using something like PostgreSQL across the board, rather than just as an option for experts. If that's not what you meant, then the rest of this is irr

Re: qt version

> Is noone interested in the qt version? The web site seemed to say that it > was in work. On the web site, it also says that the big drawback on the > gnome side is a good ledger-like widget. Is that still an issue? In regards to the second question, the gnome register widget has recently bee

RE: qt version

Is noone interested in the qt version? The web site seemed to say that it was in work. On the web site, it also says that the big drawback on the gnome side is a good ledger-like widget. Is that still an issue? cvs is great. I'd just have to port it to windows since I inadvertantly bought a w

RE: SQL backend

> > Pat Spinler <[EMAIL PROTECTED]> writes: > > > No no no - (at least in a rdbms) the program doesn't create the > > database, or tell the database what structure it should have. > > That's something you configure prior to ever starting the program. > > Wholly independant. > > Um. I understand e

Re: SQL backend

That's what I was trying to work toward in my suggested design last night. I think it's an advantage to support multiple data storage modes. Thanks, -- Pat "James A. Treacy" wrote: > Can we support multiple data storage methods? We definitely need to > > su

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

"Bradley M. Kuhn" <[EMAIL PROTECTED]> writes: > However, I wondercould we mitigate the problems you describe by > allowing users who don't want it to turn off the option at compile > time, and by being careful to control what access is given to the > scripting language? > > Baring that, if a

Re: SQL backend

On Wed, Nov 10, 1999 at 10:49:40AM -0600, [EMAIL PROTECTED] wrote: > It's been rumoured that Pat Spinler said: > > What functionality would be desirable for a data store ? > > > > *) high reliability > > *) crash recoverable > > *) high speed > > *) able to represent account group, acco

Re: SQL backend

Pat Spinler <[EMAIL PROTECTED]> writes: > No no no - (at least in a rdbms) the program doesn't create the > database, or tell the database what structure it should have. > That's something you configure prior to ever starting the program. > Wholly independant. Um. I understand everything you ta

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

It's been rumoured that James A. Treacy said: > > However, I wondercould we mitigate the problems you describe by allowing > > users who don't want it to turn off the option at compile time, and by being > > careful to control what access is given to the scripting language? The problem with p

Re: SQL backend

It's been rumoured that Pat Spinler said: > What functionality would be desirable for a data store ? > > *) high reliability > *) crash recoverable > *) high speed > *) able to represent account group, account, and transaction > information > *) (my desire:) fewer files than current s

Re: Perl in internals (was Re: A bit off topic---Java as "SUN's language" (was Re: Java implementation))

On Wed, Nov 10, 1999 at 08:47:59AM -0500, Bradley M. Kuhn wrote: > Rob Browning wrote: > > So, after thinking about all these bits, we decided that we needed to pick > > just one language as the embedded one. In the end we went with Guile. To > > be fair, that's probably in large part my fault.

Re: SQL backend

Christopher Browne wrote: > > This is a true fact, and suggests that GnuCash could perhaps be a candidate > for use with CDB , a highly robust > hash table scheme that provides fast lookups *but only one value per key.* > Sounds promising. Hum, allow

Re: SQL backend

Rob Browning wrote: > > Patrick Spinler <[EMAIL PROTECTED]> writes: > > Looked at from a DBA point of view - if you're creating a table for > > anything other than a purely temporary usage (e.g. doing a set join) > > there's something wrong with your application. > > OK. Let me totally skin m

Re: SQL backend

Christopher Browne writes: > This is a true fact, and suggests that GnuCash could perhaps be a candidate > for use with CDB , a highly robust > hash table scheme that provides fast lookups *but only one value per key.* And fast, atomic updates. On a de

Lesstif-0.89.4

Heya, everyone.. Just to let everyone know, gnucash segfaults with lesstif-0.89.4, released on the 6th November. So far, nothing above 0.88.9 will work with gnucash. So, if using the Motif version, and using lesstif, grab 0.88.9. It should be at ftp.lesstif.org:/pub/hungry/les