Re: Lightning Digest, Vol 114, Issue 4

[Paulo César Pereira de Andrade]

Em ter., 8 de nov. de 2022 às 03:48, Marc Nieper-Wißkirchen
<marc.nieper+gnu@gmail.com> escreveu:
>
> Am Mo., 7. Nov. 2022 um 20:06 Uhr schrieb Paulo César Pereira de
> Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
> >
> > Em seg., 7 de nov. de 2022 às 15:17, Marc Nieper-Wißkirchen
> > <marc.nieper+gnu@gmail.com> escreveu:
> > >
> > > Am Mo., 7. Nov. 2022 um 18:43 Uhr schrieb Paulo César Pereira de
> > > Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
> > > >
> > > > Em seg., 7 de nov. de 2022 às 11:50, Paulo César Pereira de Andrade
> > > > <paulo.cesar.pereira.de.andrade@gmail.com> escreveu:
> > > > >
> > > > > Em dom., 6 de nov. de 2022 às 12:55, Francis McCabe
> > > > > <frankmccabe@icloud.com> escreveu:
> > > > >
> > > > > > Hi Paulo
> > > > >
> > > > >   Hi Francis,
> > > > >
> > > > > >  So, your suggestion definitely allowed more progress.
> > > > > >
> > > > > > I now get:
> > > > > >
> > > > > >  make CFLAGS="-D__OpenBSD__=1" check
> > > > >
> > > > >   The commit
> > > > > https://git.savannah.gnu.org/cgit/lightning.git/commit/?id=cf4e23aa06e07db3ce5a2debef7431add4b11674
> > > > >  makes it build and pass all tests.
> > > > >
> > > > >   But note that some tests were disabled, because stack arguments
> > > > > are packed and the caller must adjust the argument. It is the inverse
> > > > > of what Windows and any Unix or Unix like system ABI does.
> > > > >
> > > > >   It is advisable to only use jit_word_t and jit_float64_t data types.
> > > > >
> > > > >   To be fully compliant, it would be required to add support for 
> > > > > packed
> > > > > stack, and a new family of pusharg calls, for example:
> > > > >
> > > > > jit_pushargr_c
> > > > > jit_pushargr_uc
> > > > >
> > > > > etc
> > > >
> > > >   I will wait a few more days before a new release, and once I
> > > > have enough time I plan to implement (but no guarantees) the new:
> > > >
> > > > jit_code_pushargr_c, jit_code_pushargr_uc,
> > > > jit_code_pushargr_s, jit_code_pushargr_us,
> > > > jit_code_pushargr_i, jit_code_pushargr_ui
> > > >
> > > > that would be aliases to jit_pushargr and jit_pushargi
> > > > on environments other than __APPLE__. Then, for __APPLE__
> > > > would add extra code to make a packed stack based on the
> > > > pusharg*_T and getarg*_T pairs. Basically only need to update
> > > > offsets, as it already uses ldx*_T and stx*_T, just that it does
> > > > not use a packed stack layout as all other ports do not need it.
> > >
> > > Does it mean that pushargr and pushargi will be deprecated?
> >
> >   No. It would still work the same way.
> >
> >   But need to add the new codes:
> >
> > jit_code_arg_c, jit_code_arg_uc,
> > jit_code_arg_s, jit_code_arg_us,
> > jit_code_arg_i, jit_code_arg_ui,
> > jit_code_arg_l,
> > jit_code_pushargr_c, jit_code_pushargi_c,
> > jit_code_pushargr_uc, jit_code_pushargi_uc,
> > jit_code_pushargr_s, jit_code_pushargi_s,
> > jit_code_pushargr_us, jit_code_pushargi_us,
> > jit_code_pushargr_i, jit_code_pushargi_i,
> > jit_code_pushargr_ui, jit_code_pushargi_ui,
> > jit_code_pushargr_l, jit_code_pushargi_l,
> > jit_code_putargr_c, jit_code_putargi_c,
> > jit_code_putargr_uc, jit_code_putargi_uc,
> > jit_code_putargr_s, jit_code_putargi_s,
> > jit_code_putargr_us, jit_code_putargi_us,
> > jit_code_putargr_i, jit_code_putargi_i,
> > jit_code_putargr_ui, jit_code_putargi_ui,
> > jit_code_putargr_l, jit_code_putargi_l
> >
> >   Basically would be in some pseudo code:
> >
> > #if __APPLE__
> > #define jit_pushargr_c(c)  _jit_pushargr_c(_jit, c)
> > #else
> > #define jit_pushargr_c(c)  jit_pushargr(c)
> > #endif
>
> What I meant is that code using GNU lightning that wants to work even
> on Apple hardware would have to check the uses of pushargr on a
> case-by-case basis.  Only when the argument is, in fact, a word, it is
> safe to leave pushargr, right?

   Sorry, now I better understand the question. As you probably understood,
existing code will only need to be rebuilt. It will require a new major
release, probably called Lightning 2.2.0 as jit_code_X will change values.
This is an oportunity to reorder the enum...

  Short answer is yes, it is required to check case-by-case to work on
Apple M1. If not intending to work on Apple M1, nothing changes.
But newer architectures in the future might use this new approach.
  If using only jit_word_t and jit_float64_t and the compatible long,
unsigned long and double, there is no need to check case-by-case.

  Some history first :)
  The original change to Lightning 2.x was to simplify as much as possible
the api. It is mainly intended to create dynamic code for custom languages,
usually languages that, for example on overflow convert an integer to
a bignum, a non exact division to a fraction, when valid, float operations
might convert to a complex number, etc. It was not intended for a C like
compiler.
  All 64 bit cpus support a kind of 32 bit mode operation, but for Lightning
I preferred to use only wide instructions. The extra cost is minimal.

  Now it is time to add back some noise.

  If calling a C function like:

int f(char a1, unsigned char a2, short a3, unsigned short a4,
      int a5, unsigned int a6, long a7, unsigned long a8,
      char a9, unsigned char a10, short a11, unsigned short a12,
       int a13, unsigned int a14, long a15, unsigned long a16);
To be in the safe side will need to use:
    prepare
    pushargi_c a1
    pushargi_uc a2
    pushargi_s a3
    pushargi_us a4
    pushargi_i a5
    pushargi_ui a6
    pushargi_l a7
    pushargi_l a8
    pushargi_c a9
    pushargi_uc a10
    pushargi_s a11
    pushargi_us a12
    pushargi_i a13
    pushargi_ui a14
    pushargi_l a15
    pushargi_l a16
    finishi f

and if implementing it in jit:

    prolog
    arg_c $a1
    arg_uc $a2
    arg_s $a3
    arg_us $a4
    arg_i $a5
    arg_ui $a6
    arg_l $a7
    arg_l $a8
    arg_c $a9
    arg_uc $a10
    arg_s $a11
    arg_us $a12
    arg_i $a13
    arg_ui $a14
    arg_l $a15
    arg_l $a16
    ...
    getarg_c %Rc $a1
    ...
    getarg_c %Rc $a16
    ...
    reti_i 0
    epilog

This is required because it is really desirable to not have jit code
using a different abi, that is, should be possible to pass around
jit function pointers as valid C functions.

  Note that now there will also be various ret{r,i}_T.

  Documentation should be added, showing the new instructions and
when they should be used.

  To avoid caller and callee doing truncation and sign/zero extension,
there will be a compile time implementation, and for now, only in the
aarch64 port.

  At first I think I will call it PACKED_STACK. Then, basically will
have the pattern:

#if PACKED_STACK
#  define jit_arg_c()        _jit_arg_c(_jit)
...
#  if __WORDSIZE == 32
#    define jit_arg()        _jit_arg_i(_jit)
#  else
#    define jit_arg()        _jit_arg_l(_jit)
#  endif
#  define jit_putargr_c(c)    _jit_putargr_c(_jit,c)

#else
#  define jit_arg_c()        jit_arg()
#  define jit_putargr_c(c)    jit_putargr(c)
...
#  define jit_arg()        _jit_arg(_jit)
#  define jit_putargr(c)    _jit_putarg(_jit,c)
#endif

  Need the jit_arg_T because arguments in stack will have a different,
size aligned offset in the stack, not a wordsize stack slot.
  Need the jit_putarg*_T because need to extr_T if argument in register,
otherwise, stxi_C in the stack as usual, just that in a type aligned,
but packed offset.

  Then, we have an inversion where getarg_T and retval_T alias to
a simple getarg and retval:

#if PACKED_STACK
#  define jit_getarg_c(Rc,offs)    jit_getarg(Rc,offs)
...
#  define _jit_getarg(Rx,offs)    _jit_getarg(Rc,offs)
#else
#  define jit_getarg_c(Rc,offs)    _jit_getarg_c(_jit,Rc,offs)
#endif

  Because now we know arguments in registers already did have an extr_T,
so, just jit_movr(Rt, Rs) if a register argument, otherwise the normal
ldxi_T from the stack, just that the offset is in a packed layout.

  The existing jit_arg_f, jit_pusharg*_f, jit_putarg*_f will work
normally, just that if PACKED_STACK is defined, they will return/use
a different offset if a stack argument. If in a register, nothing
changes.

  The existing jit_arg_d, jit_pusharg*_d, jit_putarg*_d might need
only an adjust for stack arguments if need to align to 8 bytes.


> > ...
> > #if __APPLE__
> > jit_pushargr_c(Rc):
> >     if call_regarg < regarg_max:
> >     jit_extr_c(register(call_regarg_count), Rc);
> >     ++call_regarg;
> >     else: /* argument in stack */
> >     jit_stxi_c(call_stack_offset, JIT_FP, Rc);
> >     call_stack_offset += sizeof(char);
> > jit_arg_c():
> >     int result;
> >     if self_regarg < regarg_max:
> >     result = self_regarg++;
> >     else /* income argument in stack */
> >     result = self_stack_offset;
> >     self_stack_offset += sizeof(char);
> >     return result;
> > jit_getarg_c(Rc, offs):
> >     if (offs >= 0 && < regarg_max)
> >     jit_movr(Rc, regarg_base + offs);
> >     else
> >     jit_ldxi_c(Rc, JIT_FP, offs);
> > #else
> >
> > /* The default, note that jit_pushargr_c would just alias to jit_pushargr */
> >
> > jit_pushargr(Rc):
> >     if call_regarg < regarg_max:
> >     jit_movr(regarg_base + call_regarg, Rc);
> >     ++call_regarg;
> >     else: /* argument in stack */
> >     jit_stxi_c(call_stack_offset, JIT_FP, Rc);
> >     call_stack_offset += sizeof(jit_word_t);
> > jit_arg_c():
> >     int result;
> >     if self_regarg < regarg_max:
> >     result = self_regarg++;
> >     else /* income argument in stack */
> >     result = self_stack_offset;
> >     self_stack_offset += sizeof(jit_word_t);
> >     return result;
> > jit_getarg_c(Rc, offs):
> >     if (offs >= 0 && < regarg_max)
> >     jit_extr_c(Rc, regarg_base + offs);
> >     else
> >     jit_ldxi_c(Rc, JIT_FP, offs);
> > #endif
> >
> >   Ais is now, there are only issues if calling functions with more
> > than 8 arguments (actually 8 integers and 8 float/double). The first
> > 8 arguments go on registers, but calling external code might require
> > special care if calling code that receives non word size arguments;
> > the caller must truncate and sign/zero extend.
> >
> > > > >   This is required because it would not be required to have:
> > > > >
> > > > > jit_getarg_c and jit_getarg_uc
> > > > >
> > > > >  because it is the caller that must zero or sign extend the argument.
> > > > >
> > > > >   I am afraid lightning probably has been broken for 32 bit arm also
> > > > > for significant time. But, for 32 bit, it should work if not using any
> > > > > variadic function nor using types other than int, float and double.
> > > > >
> > > > >   Due to a major issue with the 32 bit x86 compilation failure,
> > > > > a new Lightning 2.1.5 release should be made soon. This will
> > > > > include the patch listed above, to pass all tests in the sample
> > > > > Apple M1.
> > > > >
> > > > > > …
> > > > > >
> > > > > > FAIL: 3to2
> > > > > >
> > > > > > ln -s ./check.sh add
> > > > > >
> > > > > > FAIL: add
> > > > > >
> > > > > > ln -s ./check.sh align
> > > > > >
> > > > > > FAIL: align
> > > > > >
> > > > > > ln -s ./check.sh allocai
> > > > > >
> > > > > > FAIL: allocai
> > > > > >
> > > > > > ln -s ./check.sh allocar
> > > > > >
> > > > > > FAIL: allocar
> > > > > >
> > > > > > ln -s ./check.sh bp
> > > > > >
> > > > > > FAIL: bp
> > > > > >
> > > > > > ln -s ./check.sh divi
> > > > > >
> > > > > > FAIL: divi
> > > > > >
> > > > > > ln -s ./check.sh fib
> > > > > >
> > > > > > FAIL: fib
> > > > > >
> > > > > > ln -s ./check.sh rpn
> > > > > >
> > > > > > FAIL: rpn
> > > > > >
> > > > > > ln -s ./check.sh ldstr
> > > > > >
> > > > > > PASS: ldstr
> > > > > >
> > > > > > ln -s ./check.sh ldsti
> > > > > >
> > > > > > PASS: ldsti
> > > > > >
> > > > > > ln -s ./check.sh ldstxr
> > > > > >
> > > > > > PASS: ldstxr
> > > > > >
> > > > > >
> > > > > > …
> > > > > >
> > > > > > ============================================================================
> > > > > >
> > > > > > Testsuite summary for GNU lightning 2.1.4
> > > > > >
> > > > > > ============================================================================
> > > > > >
> > > > > > # TOTAL: 64
> > > > > >
> > > > > > # PASS:  46
> > > > > >
> > > > > > # SKIP:  0
> > > > > >
> > > > > > # XFAIL: 0
> > > > > >
> > > > > > # FAIL:  18
> > > > > >
> > > > > > # XPASS: 0
> > > > > >
> > > > > > # ERROR: 0
> > > > > >
> > > > > > ============================================================================
> > > > > >
> > > > > > See check/test-suite.log
> > > > > >
> > > > > > Please report to pcpa@gnu.org
> > > > > >
> > > > > > ============================================================================
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Looking forward to seeing more progress :)
> > > > > >
> > > > > > Francis
> > > > > >
> > > > > > On Nov 6, 2022, at 2:31 AM, Paulo César Pereira de Andrade 
> > > > > > <paulo.cesar.pereira.de.andrade@gmail.com> wrote:
> > > > > >
> > > > > > Em dom., 6 de nov. de 2022 às 02:30, Francis McCabe
> > > > > > <frankmccabe@icloud.com> escreveu:
> > > > > >
> > > > > >  Hi Francis,
> > > > > >
> > > > > > So, I am having a hard time with this stuff:
> > > > > >
> > > > > > I can’t use gdb, because it is not compiled for arm. I can use 
> > > > > > clang & lldb however.
> > > > > > I can’t seem to find my way through the thicket of libtool and auto 
> > > > > > tool junk. In particular, I can’t figure out what is the actual 
> > > > > > executable that I can use to load into lldb.
> > > > > >
> > > > > >
> > > > > >  Sorry for this issue. My bad as I had access to this system
> > > > > > https://cfarm.tetaneutral.net/news/41#
> > > > > >
> > > > > >  When reading your email, I mostly guessed what could be wrong.
> > > > > >
> > > > > >  I just tested in gcc104, and you can get it to mostly work if 
> > > > > > building as:
> > > > > >
> > > > > > $ ./configure --enable-assertions CFLAGS="-D__OpenBSD__=1"
> > > > > > $ make CFLAGS="-D__OpenBSD__=1"
> > > > > >
> > > > > >  Fixing the above is trivial.
> > > > > > The major problem should be a different ABI for variadic functions.
> > > > > >
> > > > > >  It should also be mostly trivial. It appears to use a very simple
> > > > > > va_list as described at
> > > > > > https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
> > > > > >
> > > > > >  Doing some initial work/research with a very simple example I get:
> > > > > >
> > > > > > gcc104:check pcpa$ lldb .libs/lightning
> > > > > > ...
> > > > > > (lldb) r add.tst
> > > > > > error: process exited with status -1 (this is a non-interactive 
> > > > > > debug
> > > > > > session, cannot get permission to debug processes.)
> > > > > >
> > > > > > apparently need some special procedures if running in a ssh 
> > > > > > connection.
> > > > > >
> > > > > >  But hopefully  it will not be required to be able to use a 
> > > > > > debugger as
> > > > > > long as my guesses are right :), and fixing the lldb issue probably
> > > > > > needs sudo privilege.
> > > > > >
> > > > > >  I believe I will not be able to work on it early today. But 
> > > > > > hopefully
> > > > > > by tomorrow I will have a patch.
> > > > > >
> > > > > >  Sorry for not having properly tested it for the Lightning 2.1.4 
> > > > > > release.
> > > > > >
> > > > > >
> > > > > > On Nov 5, 2022, at 9:00 AM, lightning-request@gnu.org wrote:
> > > > > >
> > > > > > Send Lightning mailing list submissions to
> > > > > >      lightning@gnu.org
> > > > > >
> > > > > > To subscribe or unsubscribe via the World Wide Web, visit
> > > > > >      https://lists.gnu.org/mailman/listinfo/lightning
> > > > > > or, via email, send a message with subject or body 'help' to
> > > > > >      lightning-request@gnu.org
> > > > > >
> > > > > > You can reach the person managing the list at
> > > > > >      lightning-owner@gnu.org
> > > > > >
> > > > > > When replying, please edit your Subject line so it is more specific
> > > > > > than "Re: Contents of Lightning digest..."
> > > > > >
> > > > > >
> > > > > > Today's Topics:
> > > > > >
> > > > > >  1. Re: Lightning Digest, Vol 114, Issue 2 (Marc Nieper-Wißkirchen)
> > > > > >
> > > > > >
> > > > > > ----------------------------------------------------------------------
> > > > > >
> > > > > > Message: 1
> > > > > > Date: Sat, 5 Nov 2022 16:58:21 +0100
> > > > > > From: Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>
> > > > > > To: Francis McCabe <frankmccabe@icloud.com>
> > > > > > Cc: Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>,
> > > > > >      lightning@gnu.org
> > > > > > Subject: Re: Lightning Digest, Vol 114, Issue 2
> > > > > > Message-ID:
> > > > > >      
> > > > > > <CAEYrNrTfrHDazMtifwCdgH5aS0mnBS+Lms5pXKs9Nra8HBh2Rw@mail.gmail.com>
> > > > > > Content-Type: text/plain; charset="UTF-8"
> > > > > >
> > > > > > Am Sa., 5. Nov. 2022 um 15:54 Uhr schrieb Francis McCabe
> > > > > > <frankmccabe@icloud.com>:
> > > > > >
> > > > > >
> > > > > > It hangs on that 3ro2 test. If I control-c then it cleans up that 
> > > > > > log file
> > > > > >
> > > > > >
> > > > > > Can you run it with gdb?
> > > > > >
> > > > > >
> > > > > > Sent from my iPhone
> > > > > >
> > > > > > On Nov 5, 2022, at 6:24 AM, Marc Nieper-Wißkirchen 
> > > > > > <marc.nieper+gnu@gmail.com> wrote:
> > > > > >
> > > > > > Am Sa., 5. Nov. 2022 um 06:59 Uhr schrieb Francis McCabe
> > > > > > <frankmccabe@icloud.com>:
> > > > > >
> > > > > >
> > > > > > I tried downloading and building lightning-2.1.4
> > > > > >
> > > > > > On my mac M1
> > > > > >
> > > > > > make check hangs on 3to2
> > > > > >
> > > > > > Is this ever going to get fixed?
> > > > > >
> > > > > >
> > > > > > Can you be a bit more precise about what actually happens?  Or does
> > > > > > the process crash without any output?
> > > > > >
> > > > > >
> > > > > > Francis
> > > > > > P.S. If not, then I will not bother y’all again.
> > > > > >
> > > > > > On Nov 4, 2022, at 9:00 AM, lightning-request@gnu.org wrote:
> > > > > >
> > > > > >
> > > > > > Send Lightning mailing list submissions to
> > > > > >    lightning@gnu.org
> > > > > >
> > > > > > To subscribe or unsubscribe via the World Wide Web, visit
> > > > > >    https://lists.gnu.org/mailman/listinfo/lightning
> > > > > > or, via email, send a message with subject or body 'help' to
> > > > > >    lightning-request@gnu.org
> > > > > >
> > > > > > You can reach the person managing the list at
> > > > > >    lightning-owner@gnu.org
> > > > > >
> > > > > > When replying, please edit your Subject line so it is more specific
> > > > > > than "Re: Contents of Lightning digest..."
> > > > > >
> > > > > >
> > > > > > Today's Topics:
> > > > > >
> > > > > > 1. GNU lightning 2.1.4 release (Paulo César Pereira de Andrade)
> > > > > >
> > > > > >
> > > > > > ----------------------------------------------------------------------
> > > > > >
> > > > > > Message: 1
> > > > > > Date: Fri, 4 Nov 2022 09:54:01 -0300
> > > > > > From: Paulo César Pereira de Andrade
> > > > > >    <paulo.cesar.pereira.de.andrade@gmail.com>
> > > > > > To: lightning <lightning@gnu.org>
> > > > > > Subject: GNU lightning 2.1.4 release
> > > > > > Message-ID:
> > > > > >    
> > > > > > <CAHAq8pGNRjSo_hoUyduATCc6GRQs4utGJkA5h4Qxa4cOvrDwaQ@mail.gmail.com>
> > > > > > Content-Type: text/plain; charset="UTF-8"
> > > > > >
> > > > > > GNU lightning 2.1.4 released!
> > > > > >
> > > > > > GNU lightning is a library to aid in making portable programs
> > > > > > that compile assembly code at run time.
> > > > > >
> > > > > > Development:
> > > > > > http://git.savannah.gnu.org/cgit/lightning.git
> > > > > >
> > > > > > Download release:
> > > > > > ftp://ftp.gnu.org/gnu/lightning/lightning-2.1.4.tar.gz
> > > > > >
> > > > > > 2.1.4 main features are the new Loongarch port, currently supporting
> > > > > > only Linux 64 bit, and a new rewrite of the register live and
> > > > > > unknown state logic. Now it should be faster to generate code.
> > > > > >
> > > > > > The matrix of built and tested environments is:
> > > > > > aarch64        Linux
> > > > > > alpha        Linux (QEMU)
> > > > > > armv7l        Linux (QEMU)
> > > > > > armv7hl        Linux (QEMU)
> > > > > > hppa        Linux (32 bit, QEMU)
> > > > > > i686        Linux, FreeBSD, NetBSD, OpenBSD and Cygwin/MingW
> > > > > > ia64        Linux
> > > > > > mips        Linux
> > > > > > powerpc32    AIX
> > > > > > powerpc64    AIX
> > > > > > powerpc64le    Linux
> > > > > > riscv        Linux
> > > > > > s390        Linux
> > > > > > s390x        Linux
> > > > > > sparc        Linux
> > > > > > sparc64        Linux
> > > > > > x32        Linux
> > > > > > x86_64        Linux and Cygwin/MingW
> > > > > >
> > > > > > ------------------------------------------------------------------------
> > > > > >
> > > > > > Highlights are:
> > > > > >
> > > > > > o Faster jit generation.
> > > > > > o New loongarch port.
> > > > > > o New skip instruction and rework of the align instruction.
> > > > > > o New bswapr_us, bswapr_ui, bswapr_ul byte swap instructions.
> > > > > > o New movzr and movnr conditional move instructions.
> > > > > > o New casr and casi atomic compare and swap instructions.
> > > > > > o Use short unconditional jumps and calls to forward, not yet 
> > > > > > defined labels.
> > > > > > o And several bug fixes and optimizations.
> > > > > >
> > > > > >
> > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > Subject: Digest Footer
> > > > > >
> > > > > > _______________________________________________
> > > > > > Lightning mailing list
> > > > > > Lightning@gnu.org
> > > > > > https://lists.gnu.org/mailman/listinfo/lightning
> > > > > >
> > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > End of Lightning Digest, Vol 114, Issue 2
> > > > > > *****************************************
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > Subject: Digest Footer
> > > > > >
> > > > > > _______________________________________________
> > > > > > Lightning mailing list
> > > > > > Lightning@gnu.org
> > > > > > https://lists.gnu.org/mailman/listinfo/lightning
> > > > > >
> > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > End of Lightning Digest, Vol 114, Issue 4
> > > > > > *****************************************
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Paulo
> > > > >
> > > > > Thanks!
> > > > > Paulo
> > > >