[32973] in Perl-Users-Digest
Perl-Users Digest, Issue: 4249 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 16 03:09:22 2014
Date: Wed, 16 Jul 2014 00:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 16 Jul 2014 Volume: 11 Number: 4249
Today's topics:
Re: Cost of qr// vs m// <nospam-abuse@ilyaz.org>
Re: How does the perl debugger find the source lines <nospam-abuse@ilyaz.org>
Re: Keeping data and code separate in a module <rm-dash-bau-haus@dash.futureapps.de>
Re: Keeping data and code separate in a module <rweikusat@mobileactivedefense.com>
Re: Keeping data and code separate in a module <cal@example.invalid>
Re: Keeping data and code separate in a module <cal@example.invalid>
perl bug in regular expression parsing! zahavi.eitan@gmail.com
Re: perl bug in regular expression parsing! <peter@makholm.net>
Re: perl bug in regular expression parsing! <netnews@invalid.com>
Summer puzzle <gamo@telecable.es>
Re: Summer puzzle <gravitalsun@hotmail.foo>
Re: Summer puzzle <gamo@telecable.es>
Re: Summer puzzle <netnews@invalid.com>
Re: Summer puzzle <gamo@telecable.es>
Re: Summer puzzle <netnews@invalid.com>
Re: Summer puzzle <gamo@telecable.es>
Re: Summer puzzle <jurgenex@hotmail.com>
Re: Summer puzzle <jurgenex@hotmail.com>
Re: Summer puzzle <gamo@telecable.es>
Re: Summer puzzle <jurgenex@hotmail.com>
Re: Summer puzzle <gamo@telecable.es>
Re: Summer puzzle <gamo@telecable.es>
Re: Summer puzzle <gravitalsun@hotmail.foo>
Re: Summer puzzle <gamo@telecable.es>
Re: Summer puzzle <gamo@telecable.es>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 15 Jul 2014 00:52:58 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Cost of qr// vs m//
Message-Id: <lq1u1a$fgk$1@dont-email.me>
On 2014-07-08, Peter J. Holzer <hjp-usenet3@hjp.at> wrote:
> On 2014-07-06 23:08, I <nospam-abuse@ilyaz.org> wrote:
>> With 5.8.8 (the last version for which I bear some responsibility),
>> the timing is
>> qr 2.28
>> q 2.19
>> inline 1.78
> [...]
>> *This* is reasonable, and matches what I intended with qr//.
>
> It's much better than the current behaviour, but reusing the precompiled
> regex is still *slower* than just recompiling the regex every time.
There is no recompilation entering the equation at all. At most,
there is a check that the string did not change from the last time,
AND THEN a reuse of previously compiled expression.
> I
> thought the intention was to be faster - ideally almost as fast an
> inline regexp.
No, the intent was to be “as fast as possible” — but not faster. The
problem (IIRC) is the extra redirections needed for “foolproofing”. I did not
want people expecting that
my $rx = qr(foo); # Actually, *my* implementation was using: my $rx = study /foo/;
would make something assessible in $$rx (so that one may change
internal implementation of RExes without breaking people’s XSUBs — as
v5.20 did with COW). So I made $$rx being undef, and “hid” the
compiled form in a magic slot of $$rx.
These extra redirections make things slower, but made it much easier
to manipulate this feature through p5p police. Theoretically, with
Perls of today, this may be changed.
> (Of course /some/ is an atypically simple regex, the results may be
> different with a more complex regex).
Yes, the slowdown is really tiny — usually I fight for every cache
miss, but here I thought it is going to be hidden by the noise.
============
BTW, looking at timing other people did with newer Perls, somebody
thought that malloc()+free() is a free lunch. Even with “my”
malloc(), the cost of malloc()+free() is about the same as dispatch of
3 Perl opcodes. (And, with trivial code as the discussed one, opcode
dispatch should be the principal contribution into the runtime.)
Hope this helps,
Ilya
------------------------------
Date: Tue, 15 Jul 2014 01:30:17 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: How does the perl debugger find the source lines
Message-Id: <lq2078$qm5$1@dont-email.me>
On 2013-12-30, Ben Morrow <ben@morrow.me.uk> wrote:
> Ah, I was going to ask if you were using #line. The only case I can come
> up with where the debugger sees no lines at all is
>
> eval <<'PERL';
> #line 1 evil
> PERL
>
> eval <<'PERL';
> #line 1 evil
> sub bar {
> $DB::single = 1;
> return;
> }
> PERL
>
> bar();
>
> It seems that the first time the compiler sees a given logical file, it
> creates @{"_<FILE"} and starts populating it. If it created this @_< as
> the result of a #line directive, it starts inserting lines at the
> correct index. After that, all lines from there until the end of the
> current compilation unit (file or eval) go into successive indices of
> that @_<, regardless of any further #line directives.
>
> In particular, several #lines in the same file giving different
> filenames will cause the lines to be put into multiple @_< arrays. If
> perl sees a given logical file again, it ignores that fact and doesn't
> change which @_< arrays it's recording lines into.
How could it “change” it: there is no “useful” name to use.
Anyway, I do not think there is a good way out of this: this “feature”
makes foo1() fully debuggable in
eval <<EOE for 1..10;
#line 1 fooCreator
sub foo$_ { $_ }
EOE
the price being that foo2() .. foo10() have their text **stored**, but
in a place the debugger cannot find. So the benefits are
• The text of all the subroutines is stored;
• The first one is fine;
vs
• The non-first ones are not fine.
I cannot see any solution with a comparable benefits-to-problems ratio…
Hope this helps,
Ilya
P.S. I do not think it is **my** code. ;-)
------------------------------
Date: Fri, 11 Jul 2014 14:45:35 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Keeping data and code separate in a module
Message-Id: <53bfdc6e$0$6710$9b4e6d93@newsspool2.arcor-online.net>
On 11.07.14 00:25, Cal Dershowitz wrote:
> Perl doesn't like the "our" variable being in a used package
A simple alternative seems to be
$config = do 'path/to/config';
------------------------------
Date: Fri, 11 Jul 2014 15:33:28 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Keeping data and code separate in a module
Message-Id: <874myot16v.fsf@sable.mobileactivedefense.com>
Cal Dershowitz <cal@example.invalid> writes:
> I'm revamping my templates for producing html pages. Every project
> has its cloned version of template_stuff, where it finds everything it
> needs to build a page and put it on my domain space.
>
> $ cd template_stuff/
> $ cat choir3.pm
> #!/usr/bin/perl -w
> package choir3;
> require Exporter;
>
> our @ISA = qw(Exporter);
> our @EXPORT = qw( print_hash
> get_ftp_object highest number
> get_content get_html_filename
> create_html_file write_header
> write_footer write_script);
>
> our %config = (
> my_ftp => {
> domain => '',
> username => '',
> password => '',
> },
>
> usenet => {
> domain => '',
> username => '',
> password => '',
> },
> );
[...]
> This works great, but I can't show anyone this module without also
> showing them my ftp data.
[...]
> My idea was to have a use statement at the beginning of the .pm
>
> $ cat revamp1.pm
> #!/usr/bin/perl -w
> package revamp1;
> require Exporter;
> use config1;
> ...
>
> $ cat config1.pm
> #!/usr/bin/perl -w
> package config1;
> require Exporter;
>
> our @ISA = qw(Exporter);
>
> our %config = (
> my_ftp => {
> domain => 're',
> username => 'dac',
> password => 'ted',
> },
>
> );
>
>
> $
>
> Perl doesn't like the "our" variable being in a used package:
>
> $ perl revamp1.pl
> Global symbol "%config" requires explicit package name at
> template_stuff/revamp1.pm line 66.
It doesn't mind that at all. our declares that a variable residing in
the symbol table of the containing package is supposed to be visible
within the current, lexical scope. The only effect of that is that
strict won't complain when this variable is later on used without a
fully qualified name.
You're declaring a variabler %config1::config
supposed to be visible throughout config1.pm and try to use it from
package revamp1. Inside this package, an unadorned %config refers to
%revamp1::config and since you didn't declare that, strict rejects
it. Even if it didn't, you'd be accessing the wrong hash. One way around
that is to export %config into the symbol table/ namespace of code using
the module. Considering that you want to make %config1::config available
unconditionally, I'd use an automatic export for that, eg,
-------------
package config1;
use Exporter qw(import);
our @EXPORT = qw(%config);
our %config = (
name => 'Kasimir',
city => 'Buxtehude');
1;
-------------
and
-------------
use config1;
printf("It's %s from %s.\n",
$config{name}, $config{city});
-------------
NB: This compiles 'silently' with strict and warnings enabled..
------------------------------
Date: Fri, 11 Jul 2014 14:43:58 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: Keeping data and code separate in a module
Message-Id: <c2b44vFm7o6U1@mid.individual.net>
On 07/11/2014 07:33 AM, Rainer Weikusat wrote:
> It doesn't mind that at all. our declares that a variable residing in
> the symbol table of the containing package is supposed to be visible
> within the current, lexical scope. The only effect of that is that
> strict won't complain when this variable is later on used without a
> fully qualified name.
>
> You're declaring a variabler %config1::config
> supposed to be visible throughout config1.pm and try to use it from
> package revamp1. Inside this package, an unadorned %config refers to
> %revamp1::config and since you didn't declare that, strict rejects
> it. Even if it didn't, you'd be accessing the wrong hash. One way around
> that is to export %config into the symbol table/ namespace of code using
> the module. Considering that you want to make %config1::config available
> unconditionally, I'd use an automatic export for that, eg,
Alright, thx Rainer, I think I've got you. I did away with the shebang
lines and added 1; at the ends, as is recommended:
>
> -------------
> package config1;
>
> use Exporter qw(import);
>
> our @EXPORT = qw(%config);
>
> our %config = (
> name => 'Kasimir',
> city => 'Buxtehude');
>
> 1;
> -------------
>
> and
>
> -------------
> use config1;
>
> printf("It's %s from %s.\n",
> $config{name}, $config{city});
> -------------
>
> NB: This compiles 'silently' with strict and warnings enabled..
>
$ cat config1.pm
package config1;
use Exporter qw(import);
our @EXPORT = qw(%config);
our %config = (
my_ftp => {
domain => '',
username => '',
password => '',
},
);
1;
$ cat revamp1.pm
package revamp1;
require Exporter;
use config1;
our @ISA = qw(Exporter);
...big snip...
1;
$
Since I'm able to create the ftp object, I know that it's working, so
that's a good result for the afternoon....
Cheers,
--
Cal Dershowitz
------------------------------
Date: Fri, 11 Jul 2014 16:16:38 -0700
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: Keeping data and code separate in a module
Message-Id: <c2b9ioFn93aU1@mid.individual.net>
On 07/10/2014 04:12 PM, gamo wrote:
> El 11/07/14 00:25, Cal Dershowitz escribi:
>> What are my options?
>
> Try to export %config in its module
>
> @EXPORT_OK = qw( %config );
>
> otherwise you need to call the hash via something like config1::config,
> which is unreadable.
>
That's exactly what worked, and of course, right? I'm starting to
brainstorm the types of things I would rather stuff into modules than
have in the body of scripts....
Thanks for your comment,
--
Cal Dershowitz
------------------------------
Date: Mon, 14 Jul 2014 05:59:58 -0700 (PDT)
From: zahavi.eitan@gmail.com
Subject: perl bug in regular expression parsing!
Message-Id: <7f14c2bf-045b-423f-9475-07cded4097d5@googlegroups.com>
To whom it may concern...
This is perl, v5.8.8 built for x86_64-linux-thread-multi
When I try to match against the nonsense $bad regexp perl goes to 99% CPU and stuck. The $good works like charm...
my $bad = qr/^X\S+\s*\S+\s*\S+\s*\S+\s*\S+\s*([pn]ch[p][gdu]_\S+)/;
(notice the single [p])
my $good = qr/^X\S+\s*\S+\s*\S+\s*\S+\s*\S+\s*([pn]chp[gdu]_\S+)/;
Eitan Zahavi
------------------------------
Date: Mon, 14 Jul 2014 15:26:13 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: perl bug in regular expression parsing!
Message-Id: <8761j08422.fsf@vps1.hacking.dk>
zahavi.eitan@gmail.com writes:
> To whom it may concern...
>
> This is perl, v5.8.8 built for x86_64-linux-thread-multi
That version of perl is 8 years old and there has been 6 major releases
of Perl since 5.8.8. Can you reproduce the problem with a more recent
version?
//Makholm
------------------------------
Date: Mon, 14 Jul 2014 06:50:35 -0700
From: HASM <netnews@invalid.com>
Subject: Re: perl bug in regular expression parsing!
Message-Id: <87bnsst5g4.fsf@127.0.0.1>
zahavi.eitan@gmail.com writes:
> This is perl, v5.8.8 built for x86_64-linux-thread-multi
My system is up to 5.18.2. Have you tried with a more recent version?
> When I try to match against the nonsense $bad regexp perl goes to 99% CPU
> and stuck. The $good works like charm...
What are you trying to match against?
I tried and it worked for a simple case.
-- HASM
------------------------------
Date: Sat, 12 Jul 2014 15:17:39 +0200
From: gamo <gamo@telecable.es>
Subject: Summer puzzle
Message-Id: <lprchh$v5h$1@speranza.aioe.org>
We have a matrix 3x3 with a hole to slide
other numbers into that position.
An initial arrangement could be:
- 8 5
4 1 2
3 6 7
and we want to play until the numbers
are ordered as
- 1 2
3 4 5
6 7 8
Beware: not all initial positions can
lead to a solution.
Can you write an algorithm that lead
to a solution and predict when there
isn't?
Cheers
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 12 Jul 2014 16:20:53 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Summer puzzle
Message-Id: <lprcno$fdt$1@news.ntua.gr>
what, do you problem to order 8 numbers ?
------------------------------
Date: Sat, 12 Jul 2014 15:53:40 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Summer puzzle
Message-Id: <lprel2$3ij$1@speranza.aioe.org>
El 12/07/14 15:20, George Mpouras escribió:
> what, do you problem to order 8 numbers ?
No, the problem consist in sliding a neightbour
number in to the hole, until reach the solution.
I'm afraid there is to think the strategy.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 12 Jul 2014 07:44:44 -0700
From: HASM <netnews@invalid.com>
Subject: Re: Summer puzzle
Message-Id: <87ha2mvdpf.fsf@127.0.0.1>
gamo <gamo@telecable.es> writes:
> No, the problem consist in sliding a neightbour
> number in to the hole, until reach the solution.
Do we usually do other posters' homework in this group?
-- HASM
------------------------------
Date: Sat, 12 Jul 2014 16:51:54 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Summer puzzle
Message-Id: <lpri27$c4g$1@speranza.aioe.org>
El 12/07/14 16:44, HASM escribió:
> gamo <gamo@telecable.es> writes:
>
>> No, the problem consist in sliding a neightbour
>> number in to the hole, until reach the solution.
>
> Do we usually do other posters' homework in this group?
>
> -- HASM
>
It's not a homework. It's a puzzle that somepeople like
to try to resolve. Like I am. I'm thinking in hints.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 12 Jul 2014 08:00:39 -0700
From: HASM <netnews@invalid.com>
Subject: Re: Summer puzzle
Message-Id: <877g3ivcyw.fsf@127.0.0.1>
gamo <gamo@telecable.es> writes:
> It's not a homework. It's a puzzle that somepeople like
> to try to resolve. Like I am. I'm thinking in hints.
http://en.wikipedia.org/wiki/Fifteen_puzzle
------------------------------
Date: Sat, 12 Jul 2014 17:10:32 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Summer puzzle
Message-Id: <lprj56$enr$1@speranza.aioe.org>
El 12/07/14 17:00, HASM escribió:
> gamo <gamo@telecable.es> writes:
>
>> It's not a homework. It's a puzzle that somepeople like
>> to try to resolve. Like I am. I'm thinking in hints.
>
> http://en.wikipedia.org/wiki/Fifteen_puzzle
>
Very interesting. So there is only to code it.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 12 Jul 2014 08:19:20 -0700
From: Jrgen Exner <jurgenex@hotmail.com>
Subject: Re: Summer puzzle
Message-Id: <eck2s91vinr5njpi877fc77e73ngishnm2@4ax.com>
gamo <gamo@telecable.es> wrote:
[old-fasioned puzzle]
>Can you write an algorithm that lead
>to a solution and predict when there
>isn't?
Do you have a Perl question?
jue
------------------------------
Date: Sat, 12 Jul 2014 08:20:17 -0700
From: Jrgen Exner <jurgenex@hotmail.com>
Subject: Re: Summer puzzle
Message-Id: <9gk2s9dngfndnamm34jh96e8qkb82uo2t4@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 12/07/14 15:20, George Mpouras escribi:
>> what, do you problem to order 8 numbers ?
>
>No, the problem consist in sliding a neightbour
>number in to the hole, until reach the solution.
>
>I'm afraid there is to think the strategy.
And that strategy _DOES NOT_ depend on the programming language used to
implement a program.
jue
------------------------------
Date: Sat, 12 Jul 2014 23:30:50 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Summer puzzle
Message-Id: <lps9e6$77u$1@speranza.aioe.org>
El 12/07/14 17:20, Jrgen Exner escribi:
> gamo <gamo@telecable.es> wrote:
>> El 12/07/14 15:20, George Mpouras escribi:
>>> what, do you problem to order 8 numbers ?
>>
>> No, the problem consist in sliding a neightbour
>> number in to the hole, until reach the solution.
>>
>> I'm afraid there is to think the strategy.
>
> And that strategy _DOES NOT_ depend on the programming language used to
> implement a program.
>
> jue
>
Actually, my -not so clever- strategy DOES DEPEND on the language
since it use a list of lists.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sat, 12 Jul 2014 14:57:16 -0700
From: Jrgen Exner <jurgenex@hotmail.com>
Subject: Re: Summer puzzle
Message-Id: <4hb3s9p0n27ne3i0380ecjj9b5mairdh4j@4ax.com>
gamo <gamo@telecable.es> wrote:
>El 12/07/14 17:20, Jrgen Exner escribi:
>> gamo <gamo@telecable.es> wrote:
>>> El 12/07/14 15:20, George Mpouras escribi:
>>>> what, do you problem to order 8 numbers ?
>>>
>>> No, the problem consist in sliding a neightbour
>>> number in to the hole, until reach the solution.
>>>
>>> I'm afraid there is to think the strategy.
>>
>> And that strategy _DOES NOT_ depend on the programming language used to
>> implement a program.
>
>Actually, my -not so clever- strategy DOES DEPEND on the language
>since it use a list of lists.
Is there any commonly used general purpose programming language which
does not support nested dynamic data structures, including list of
lists?
jue
------------------------------
Date: Sun, 13 Jul 2014 00:33:55 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Summer puzzle
Message-Id: <lpsd4k$f4q$1@speranza.aioe.org>
El 12/07/14 23:57, Jrgen Exner escribi:
> gamo <gamo@telecable.es> wrote:
>> El 12/07/14 17:20, Jrgen Exner escribi:
>>> gamo <gamo@telecable.es> wrote:
>>>> El 12/07/14 15:20, George Mpouras escribi:
>>>>> what, do you problem to order 8 numbers ?
>>>>
>>>> No, the problem consist in sliding a neightbour
>>>> number in to the hole, until reach the solution.
>>>>
>>>> I'm afraid there is to think the strategy.
>>>
>>> And that strategy _DOES NOT_ depend on the programming language used to
>>> implement a program.
>>
>> Actually, my -not so clever- strategy DOES DEPEND on the language
>> since it use a list of lists.
>
> Is there any commonly used general purpose programming language which
> does not support nested dynamic data structures, including list of
> lists?
>
> jue
>
I suposse that no, but not so easy a is to write in Perl
@pos = ( [1,],
[2,3,],
);
So given that perl is slow and doesn't do anything special,
does not matter to me, since I can do the same in minus time
and space.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sun, 13 Jul 2014 01:01:36 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Summer puzzle
Message-Id: <lpseoh$ih8$1@speranza.aioe.org>
El 12/07/14 17:19, Jrgen Exner escribi:
> gamo <gamo@telecable.es> wrote:
> [old-fasioned puzzle]
>> Can you write an algorithm that lead
>> to a solution and predict when there
>> isn't?
>
> Do you have a Perl question?
>
> jue
>
Yes, after having a stupid bug, I found
a "reasonable" heuristic solution.
Questions could be:
1. Anyone interested in?
2. When is expected to launch perl6,
to compile code and going faster?
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Sun, 13 Jul 2014 19:31:07 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: Summer puzzle
Message-Id: <lpuc8d$2bo6$1@news.ntua.gr>
> So given that perl is slow and doesn't do anything special,
> does not matter to me, since I can do the same in minus time
> and space.
>
what do you mean by "doesn't do anything special" ;
do you find it is slow ;
------------------------------
Date: Sun, 13 Jul 2014 21:42:27 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Summer puzzle
Message-Id: <lpunf1$h6v$1@speranza.aioe.org>
El 13/07/14 18:31, George Mpouras escribi:
>> So given that perl is slow and doesn't do anything special,
>> does not matter to me, since I can do the same in minus time
>> and space.
>>
>
>
> what do you mean by "doesn't do anything special" ;
>
It is called "reduction to the absurd"
> do you find it is slow ;
Well, I like Perl, but it's not a bullet
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Tue, 15 Jul 2014 15:16:45 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Summer puzzle
Message-Id: <lq39k0$d4h$1@speranza.aioe.org>
El 13/07/14 01:01, gamo escribi:
> 2. When is expected to launch perl6,
> to compile code and going faster?
I have been reading the documentation of
the Perl 6 of "rakudo star" and it's a
new lenguage. So, the typical response
"when it's ready" sounds better.
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4249
***************************************
