Re: Design problems for i18n with gettext

[Laurent Pelecq]

1- Should I put sources for functions like with_elipses in directory src/
   or is there a better place for it ?

2- I will remove intl from the i18n patch since it appears to be
   redundant with the gettext package. And I will generate a pseudo C
   file from headers in order to use xgettext without modifying all
   sources.

Laurent

[EMAIL PROTECTED] writes:
 > It's been rumoured that Laurent Pélecq said:
 > >  #define ACC_CODE_C_STR  with_elipses(ACC_CODE_STR)
 > 
 > OK. 
 > 
 > >  > I noticed that it includes a lot of source code in a directory 'intl'
 > > 
 > > The patch include the directory intl because it is required by the
 > > autoconf macro AM_GNU_GETTEXT. I prefer not to change standard
 > > tools. As far as I know internationalized packages include this
 > > directory (as sharutils, ...). In fact, only the script intl/po2tbl
 > > seems to be used. It generate a file cat-id-tbl.c that contains an
 > > array with a numeric id for all strings. I didn't find the reason why
 > > this file is generated.
 > > 
 > > If you think that this directory is too much useless I can remove it
 > > and change the macro AM_GNU_GETTEXT.
 > 
 > As you can see from another note, some people have trouble compiling
 > this thing, and maintenance is hard enough. I'd rather not introduce 
 > any code that we can't maintain, with the exception of the 'temporary'
 > code in the lib subdirectory.
 > 
 > Besides, it seems these come from elsewhere anyway:
 > 
 > %locate po2tbl
 > locate: warning: database `/var/lib/locatedb' is more than 8 days old
 > /usr/share/gettext/intl/po2tbl.sed.in  
 > 
 > %rpm -q -f /usr/share/gettext/intl/po2tbl.sed.in
 > gettext-0.10.35-3
 > 
 > --linas
- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body

kde build doesn't work

[Taral]

Has anyone had any success with the KDE build of gnucash? I can't get
src/Destroy.c to build {:<

Taral

- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body

Re: Guile and Structures

[Rob Browning]

[EMAIL PROTECTED] writes:

> What struck me Friday morning was that I really should be
> marshalling data into somewhat more organized "structures" rather
> than just building assoc lists.

[ General agreement. ]

> I also finally grokked define-struct, and maybe am looking at is as
> a "hammer," and am looking for "nails" to hit with it.

Could be.  Rather than assoc lists, unless I need something fancier, I
generally use vectors and define getters/setters and use those
exclusively:

  (define (point:create x y z) (vector 'point x y z)) ;; the tag is optional...
  (define (point:x pt) (vector-ref pt 0)
  (define (point:set-x! pt value) (vector-set! v 0 value))
  ...

The advantage to using this over something like define-struct is that
define-struct is not standard scheme so your code won't be portable to
other implementations.  I'm not a about using non-portable scheme
code, but I try to avoid it unless it provides a compelling advantage.

Of course, if you need dispatch, then you have to do a little more
(which without looking closely yet, looks like what you've done).

For example, *if* we ever decided to implement even more of GnuCash in
scheme, and we really needed to speed some of it up to C level
performance, we could use a good scheme compiler as long as the
relevant code didn't depend on a lot of uncommon functions.

> [This is one of the annoyances of Scheme as compared to Common Lisp;
> there are many commonly desirable functions/macros that CL has
> standardized but that different Schemes handle differently.]

True, but there is some movement toward fixing this (see below).
Further, slib, which we already requrire implements a whole bunch of
useful things.  Though I've tended to avoid using slib if I could
implement the same function easily because we might or might not want
to keep that dependency long-term.

There's actually quite a bit of useful code at the MIT and Indiana
repositories we could include if we needed it, but more interesting
than that for your purposes would probably be the SRFI (Scheme Request
For Implementation) process (see www.schemers.org).  If you're going
to implement the skeleton of any "struct" style system, I'd suggest
modelling it after the relevant SRFI.  In fact, since a SRFI is
required to provide a reference implementation written in standard
scheme to be valid, there should already be code there for this.

SRFI's, especially the finalized ones, should be commonly available in
most schemes soon, and if not, you can just copy/paste the reference
code into your own project.

Also, if we're going to use non-standard scheme bits, I'd recommend
using hash tables instead of alists for any case where there's likely
to be more than a small number of items.  Might as well get O(1)
lookups rather than O(n).

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body

Guile and Structures

[cbbrowne]

I'm starting to look Rather More Seriously at understanding the transaction 
engine.

This is encouraging me to establish sets of data structures on the Guile side 
of the world to represent data in the two quite distinct forms:
a) QIF's "bunch of transactions that get attached to an account, sometimes 
with a split," and

b) The GnuCash Engine "Bunch of accounts that have transactions attached to 
them that have a bunch of splits attached to them."

Those are quite different structures, and I didn't fully grasp what was going 
on until Friday night.

What struck me Friday morning was that I really should be marshalling data 
into somewhat more organized "structures" rather than just building assoc 
lists.  I also finally grokked define-struct, and maybe am looking at is as a 
"hammer," and am looking for "nails" to hit with it.

What I'd like to do is collect the data all together via

(define-struct qif-txn-structure '(memo date id payee addresslist amount status
  category splitlist)))

and then go off and do (define thistxn (make-qif-txn-structure)) every time I 
want to create a new transaction.

Seems sensible to have the names all together in one spot, much as 
gnucash/src/engine/TransactionP.h and the other *P.h files collect such data 
together into C structures.

Unfortunately, Guile evidently hides (define-struct) and I've not gotten it to 
compile or otherwise work.

Hence, note the attached, that does largely the same thing.

I would be more than pleased to eliminate it in favor of a more "native" 
facility, if the "true" define-struct may be made to work.

[This is one of the annoyances of Scheme as compared to Common Lisp; there are 
many commonly desirable functions/macros that CL has standardized but that 
different Schemes handle differently.]

Note to those that didn't know; the below essentially represents a message 
dispatch system; Object Oriented Programming recreated in 43 lines of code.

Paul Graham's book, "Common Lisp," does a presentation of an 8 line OO system 
that does everything but multiple inheritance...
--
"It's a pretty rare beginner who isn't clueless.  If beginners weren't
clueless, the infamous Unix learning cliff wouldn't be a problem." 
-- david parsons
[EMAIL PROTECTED] 



;;; Some functions to help build structures

;;; define-mystruct is used to build an association list that defines
;;; the layout of a structure...
(define (define-mystruct lst)
  (define alist '())  ;; Association list
  (define count 0);; Number of entries
  (define (add-item item)
(set! alist (cons (cons item count) alist))
(set! count (+ 1 count)))
  (for-each add-item lst)
  alist)
;;; Use as follows:
;;; (define qif-split-structure  (define-mystruct '(category memo
;;; amount percent)))  
;;;

(define (build-mystruct-instance structinfo)
  ;;;  struct-instance is the vector for the data...
  (define struct-instance (make-vector (length structinfo) #f))
  (define (get-item field-id)   ;;; Look up entry based on ID
(let ((assocv (assoc field-id structinfo)))
  (if assocv
  (vector-ref struct-instance (cdr assocv))
  #f)))

  (define (set-item! field-id value)   ;;; Plunk in new value
(let ((assocv (assoc field-id structinfo)))
  (if assocv
  (vector-set! struct-instance (cdr assocv) value)
  #f)))

  (define (actions action field . value) ;;; now, methods to be applied
(cond
 ((eq? action 'get) 
  (car (get-item field)))
 ((eq? action 'put) 
  (set-item! field (car value)))
 (else
  (list structinfo struct-instance
  actions)

Re: Problem in date field in latest register.

[linas]

It's been rumoured that Rob Browning said:
> 
> 
> If you open a register, go to the bottom (new) entry, use '-' to
> change the data back a few weeks, and then click on the "Transfer
> From" field, you'll get garbage in the date field.  If you then click
> on the date field again, and back on the transfer from field,
> everything's fine...

fixed
- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body

Re: Design problems for i18n with gettext

[linas]

It's been rumoured that Laurent Pélecq said:
>  #define ACC_CODE_C_STR  with_elipses(ACC_CODE_STR)

OK. 

>  > I noticed that it includes a lot of source code in a directory 'intl'
> 
> The patch include the directory intl because it is required by the
> autoconf macro AM_GNU_GETTEXT. I prefer not to change standard
> tools. As far as I know internationalized packages include this
> directory (as sharutils, ...). In fact, only the script intl/po2tbl
> seems to be used. It generate a file cat-id-tbl.c that contains an
> array with a numeric id for all strings. I didn't find the reason why
> this file is generated.
> 
> If you think that this directory is too much useless I can remove it
> and change the macro AM_GNU_GETTEXT.

As you can see from another note, some people have trouble compiling
this thing, and maintenance is hard enough. I'd rather not introduce 
any code that we can't maintain, with the exception of the 'temporary'
code in the lib subdirectory.

Besides, it seems these come from elsewhere anyway:

%locate po2tbl
locate: warning: database `/var/lib/locatedb' is more than 8 days old
/usr/share/gettext/intl/po2tbl.sed.in  

%rpm -q -f /usr/share/gettext/intl/po2tbl.sed.in
gettext-0.10.35-3

--linas

- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body

gnucash builds

[pehr anderson]

Dear Zeek,

I'm with you on this one. I've been tracking gnucash for nearly 6
months.
>From every release I download, not *one* has compiled yet.
I usually hack at it for ~30min, make no progress, and give up.
I'd subscribe to a 'platform support' service...
$100/year for updated builds, tutorials, bugfixes & regression testing.

I use fairly stock RedHat 6.0. I want a SRPM, which will specificially
generate an i386 RPM.
I want the gnome/gtk, even it means reduced functionality, but
I want unreliable features disabled by default.
I don't want the app to crash where the bugs are, just be less
functional
until things stablize.

Is anybody out there interested in build professional build maintenace?
I can throw money in the pot but I can't make it boil.

-pehr


- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body

Re: Design problems for i18n with gettext

[Laurent Pélecq]

 > I think the second is a lot better.  It allows spell-checking
 > (which first alternative does not).
Spell-checking can be done on the gnucash.pot file generated from
sources.

 > It avoids the elipses problem you describe
 > below.
I don't see exactly what you mean. The elipses problem remains with a
centralized message file. For example , if we have the following
definitions:
 #define ACC_CODE_STR"Account Code"
 #define ACC_CODE_C_STR  ACC_CODE_STR  ":"

Then the compiler acts as if we have written:
 #define ACC_CODE_C_STR  "Account Code:"

But with gettext, we will write:
 #define ACC_CODE_STR _("Account Code")

And ACC_CODE_STR is no longer a constant since underscore is an alias
for function gettext . Thus the compiler can't concat such strings
when compiling. I think the simplest is to write something like:
 #define ACC_CODE_C_STR  with_elipses(ACC_CODE_STR)

 > It avoids the propagation of similar but slightly different messages
That's right.

 > It avoids the loss of translation when a minor change is made in
 > the native-language string.
New .po files are merged with already existing .po with msgfmt. Only
new strings or updated string have to be translated. This is true
whatever the solution is.

 > It would be a step back to loose a centralized dictionary.
If you prefer centralized dictionary, I agree with you. It will be
safer and simpler to do that.

 > > A temporary patch is available for testing at
 > >http://perso.wanadoo.fr/jl.pelecq/gnucash.html
 > 
 > I noticed that it includes a lot of source code in a directory 'intl'

The patch include the directory intl because it is required by the
autoconf macro AM_GNU_GETTEXT. I prefer not to change standard
tools. As far as I know internationalized packages include this
directory (as sharutils, ...). In fact, only the script intl/po2tbl
seems to be used. It generate a file cat-id-tbl.c that contains an
array with a numeric id for all strings. I didn't find the reason why
this file is generated.

If you think that this directory is too much useless I can remove it
and change the macro AM_GNU_GETTEXT.

Laurent
- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body

Re: Design problems for i18n with gettext

[linas]

It's been rumoured that Laurent Pélecq said:
> 
> I've started to patch gnucash to use gettext for internationalization.
> There are some design problems.
> 
> 1- Currently, for all languages, there is a file messages_.h. in
>which messages are defined by macros. But xgettext (used to extract 
>translatable strings from sources) doesn't take preprocessor
>directives in to account. According to me there are 2 solutions:
> 
>* the standard way: we can replace all macros in sources by the
>  corresponding strings marked as translatable (with directive _).
>  i.e. ACC_CODE_STR will be replaced by _("Account Code")
> 
>* the simplest way: we can produce a pseudo C file from
>  message_en.h and apply xgettext on it.
> 
>I prefer the first solution but it implies to change all files that 
>include translatable strings.

I think the second is a lot better.  It allows spell-checking
(which first alternative does not).  It avoids the elipses problem you describe
below.  It avoids the propagation of similar but slightly different messages
(e.g. having a grammer correction not being propagated to all the places
where it occurs).  It avoids the loss of translation when a minor change
is made in the native-language string.  It provides a centralized dictionary.  
It allows two different words to have the same translation, or v.v. (the same 
english word to have two different translations in another language).

I think gettext was designed for the lowest-common-denominator of programming, 
for programs that had a mess that was too painful to cleanup by any other means.  
It would be a step back to loose a centralized dictionary.

> I wish I was clear enough. A temporary patch is available for testing at
>   http://perso.wanadoo.fr/jl.pelecq/gnucash.html
> (remark: strings with colons or elipses are not translated)

I noticed that it includes a lot of source code in a directory 'intl'

-- if this is automatically generated code, it shouldn't be included
   at all.

-- if this is cut and paste from a pacakge that is not widely available
   or is buggy or poorly supported, it belongs in the lib subdirectory.

However, it looked like neither, it looked like the source for libgettext,
so I hope this code will go away ?! in the final version.

--linas


- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body

Re: Get X11 error when running configure

[linas]

It's been rumoured that [EMAIL PROTECTED] said:
> #include 
>  
> Did I miss something that needs to be installed or is there a library or  rpm 
> I need to get?  I thought I had downloaded all the packages I needed.

You need to install the X11 development environment (XFree86-devel).

--linas

- %<  >% --
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body