[32629] in Perl-Users-Digest
Perl-Users Digest, Issue: 3904 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 18 21:09:26 2013
Date: Mon, 18 Mar 2013 18:09:09 -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 Mon, 18 Mar 2013 Volume: 11 Number: 3904
Today's topics:
Re: 'Needless flexibilities' and structured records [ve <rweikusat@mssgmbh.com>
Re: bytes, English, and prototypes <hjp-usenet3@hjp.at>
Re: bytes, English, and prototypes <oneingray@gmail.com>
Re: classic loop to controlled iterator (Tim McDaniel)
Re: classic loop to controlled iterator <rweikusat@mssgmbh.com>
Re: getting perl and php to talk to each other <PointedEars@web.de>
Re: Identifying functions in C files and replacing them <jimsgibson@gmail.com>
Re: Identifying functions in C files and replacing them <ben@morrow.me.uk>
Re: Identifying functions in C files and replacing them <rweikusat@mssgmbh.com>
Re: Identifying functions in C files and replacing them <ben@morrow.me.uk>
Identifying functions in C files and replacing them wit <balaji.draj@gmail.com>
Re: Identifying functions in C files and replacing them <ben@morrow.me.uk>
Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) <oneingray@gmail.com>
Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Mar 2013 13:28:30 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: 'Needless flexibilities' and structured records [very long]
Message-Id: <87hak8n8g1.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
>> ---------------
>> package slots;
>>
>> use feature 'state';
>> use constant;
>>
>> sub import
>> {
>> state %counters;
>> my ($ctr, $fields);
>>
>> if (ref($_[1])) {
>> $fields = $_[1];
>> $ctr = 0;
>> } else {
>> $ctr = $counters{$_[1]};
>
> You can look up the inheritance here instead of having the user specify
> it (DRY and all that...). As long as they
Re: DRY
That's a cute acronym for 'Design pattern aficionados Reinventing
elementary database theorY' (in short: Databases should not contain
redundant copies of the same data to avoid so-called 'update
anomalies', the database becoming inconsistent because not all
redudant copies of 'some data' are changed during an update. People
usually ignore that in favor of 'nobdoy will ever update X without
going to gatekeeper code Z which always keeps all copies in sync' and
looking dedicatedly in another direction whenever somebody mentions
that 'updates withoug going throug Z' are possible. This could almost
be called 'a basic design principle of modern Linux distributions'
:->).
>
> use parent "Parent";
> use slots qw/one two three/;
>
> in that order, @{ caller . "::ISA" } will contain the direct parents at
> this point. You can also croak if they're trying to use MI.
I thought about that and decided against it: This would require @ISA
to be populated by the time the import method is executed and the code
would either need to operate in 'pushy nanny mode' ("I've told you you
must not inherit methods from more than one class and you must do as I say
because I say so!") or make a guess at which of the possibly many
direct and indirect(!) 'superclasses' is supposed to be the anchoring
point for the new slot name series. But in reality, @ISA is about
method lookups and not about 'allocating array slots in a
non-conflicting way to members of some "inheritance tree"'.
One can assume that packages sharing an array reference for instance
data will usually also share method via @ISA but this need not be
true. Also just because some package is listed in @ISA doesn't
necessarily mean that it should also participiate in the 'data
inheritance hierarchy'. These are orthogonal issues and one of the
serious drawbacks of many existing 'OO support modules' is that the
authors usually fell prey to their own "Jack of all trades" desires
and 'hard-coded' technically independent policy choices they usually
happen to make in their code. Eg, one cannot comfortably use parent.pm
except if one always keeps each package in a file of its own, to name
a simple example.
'Radio and television' are popular because 'they just work': Turn them
on, something's gonna happen, no need to worry about that. For the
same reason, complaining about the programme is also very popular.
>> $fields = $_[2];
>> }
>>
>> @_ = ($_[0], {map { $_, $ctr++; } @$fields});
>
> Strictly this should be "constant" rather than $_[0] (which will be
> "slots"), since this is supposed to be emulating constant->import. In
> fact constant.pm doesn't care, but in principle it might care at some
> point in the future.
It would be 'constant' if constant::import had actually been
invoked directly. But since this isn't the case and no 'requirements
specification' of any kind exists (as far as I'm aware of that)
anything would do insofar it pushes the first 'actual argument' to
$_[1]. Using whatever was passed in $_[0] to this import routine is as
good an anything as anything else and might also be useful 'in
future'.
>> $counters{caller()} = $ctr;
>>
>> goto &constant::import;
>
> It's probably easier to just create the constants manually, rather than
> bothering with goto-&:
>
> for (@$fields) {
> my $n = $ctr++;
> no strict "refs";
> *{ caller . "::$_" } = sub () { $n };
> }
>
> If you were feeling excited you could use the scalar-refs-in-the-stash
> trick constant.pm uses to avoid a full GV+CV.
Ehh ... I'm using the 'scalar-refs-in-the-stash' trick and - for that
matter - any useful other 'trick' constant.pm might employ now or in
future. That's why I'm just telling constant.pm which constants I'd
like to have created[*].
This is also a design question: Since a subroutine providing the
feature I want to build on already exists and the implementation is
suitable for the task at hand, the code should rather invoke the
subroutine than be decorated by copy of some of its code (this is also
a 'DRY/ redundant copies of identical data' issue).
[*] I've been using Perl 5 for long enough that I was pleasantly
surprised when I could stop creating long
sub A_VALUE() { 1; }
sub ANOTHER() { 2; }
.
.
.
cascades ...
[...]
>> use slots ('Person', ['NATIONALITY']);
>>
>> ('Person' being the name of the superclass package) to request an
>> additional field which will have the next 'free' slot number.
>>
>> NB: This is an idea I had yesterday and since the implementation was
>> so exceedingly simple, I thought sharing it might be a good idea. I
>> expect that there situations this simple code doesn't handle but it is
>> 'good enough' to be useful.
>
> It's not a bad idea; it's basically the same as Class::Accessor::Faster
> or MooseX::ArrayRef.
I assume the authors of the two named modules would calls this 'a
backhanded compliment' (and rightly so :->) and so would I (also
rightly so :->). This is a slight generalization of an anonymous array
sharing scheme I've been using since 199x and it really doesn't (and
shouldn't) do anything except solve this particular problem.
> As you note, it only works for single inheritance,
> and doesn't work with MI or roles-which-provide-attributes (however they
> may be implemented); it also fails (badly) if you attempt to modify the
> inheritance or attributes of a class at runtime.
It can't 'fail badly at run-time' because the code never runs 'at
run-time'. This 'anonymous array sharing scheme' might not be useful
to solve 'certain problems' or might only be a component which could
be employed for solving them. But that's a different conversation (I
already wrote about the
washer-dryer-lawnmower-bicycle-tophat-eggwarmer-hovercraft-theodolite
... sometimes, a hammer is really the right tool).
> MI can be fixed by using accessor methods, since this allows a
> subclass's implementation of ->foo to use a different slot from the
> superclass's;
A more general remark: At one end of the 'OO spectrum', you have
something like CLOS or DYLAN (or Perl 6 or 'Perl With Mossy Antlers' or
...). These systems are based on an abstract, 'behavioural'
specification of what 'an object instance' actually is. Nobody except
the people who implemented the system knows that and its users can
only interact with object instances by using a procedural
interface. The obvious advantages of that would be that the object
representation the system uses can change, either in future version or
even at run-time, without affecting exising code.
Then, there are intermediate/ hybrid systems like C++ or Java (or C)
where the object representation was set in stone when the system was
created but 'application code' does have direct access to object
instances. This will usually be better for performance (although users
of CLOS-style system will usually believe/ claim that 'the compiler'
can 'optimize' this which may even be true .. but why use a lot of
seriously complicated 'compiler technology' to make educated guesses
at facts language users could easily have provided [and provided
correctly] instead?).
Lastly, on the opposite end of the spectrum, there's Perl 5 where users
are in total control of object representation because the system only
provides a (possibly hierarchivally structured) system for routing
'messages' to 'message processing routines' (I propose a new 'flashy
acronym' here, namely P5INAE --- for 'Perl 5 Is Not An Error'). The
benefit is that what exactly constitues an object can be tailored to
the problem at hand and the obvious drawback is that people actually
have to do that.
So far (evil anecdotical argument), I haven't been stopped by a brick
wall when using that for the problems I head to deal
with. Consequently, I'm not convinced that it needs to be replaced
with a system based on different policy choices, especially
considering that 'simple system for solving relatively simple
problems' are useful because many problems are relatively simple
(Corollary: Problems which only manifest themselves dreadfully in 'really
large systems' could be a sign that createing 'really large systems'
is 'a really bad idea').
I'm also a firm desbeliever in 'the run-time environment has to defend
itself agains one million evil typing monkeys'. That's a social
problem and the solutions are 'education' and 'natural selection'.
------------------------------
Date: Sun, 17 Mar 2013 12:03:07 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: bytes, English, and prototypes
Message-Id: <slrnkkb8nb.b5e.hjp-usenet3@hrunkner.hjp.at>
On 2013-03-14 20:59, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Ivan Shmakov <oneingray@gmail.com>:
>> * how do I ensure that a value passed to my function is an octet
>> sequence? (IOW, doesn't contain a code over \xFF);
>
> $value =~ tr/\0-\xff//dc;
As asked I would prefer the answer
croak "value is not an octet sequence" if $value =~ m/[^\0-\xFF]/;
I.e., if I want to ensure that a value matches the specified interface,
I want the program to complain loudly if the specs are violated. I do
not usually want to mask the error by silently discarding data. There
are situation where it is appropriate, but this should be a conscious
decision, not the default.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 17 Mar 2013 17:36:49 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: bytes, English, and prototypes
Message-Id: <871ubej5ce.fsf@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
[...]
>> * how do I ensure that a value passed to my function is an octet
>> sequence? (IOW, doesn't contain a code over \xFF);
> $value =~ tr/\0-\xff//dc;
That was a dumb question, indeed. (Although, as it was already
pointed out, die () if ($x =~ m/[^\0-\xff]/); is actually what
I've asked for.)
>> * how do I ensure that a non-ASCII octet is never considered to be a
>> member of, say, the [[:alpha:]] set? as in the following code
>> (although, perhaps, of questionable value):
> For this you need 5.14, which has a /a regex modifier to do exactly
> that.
ACK, thanks! And now that Debian Wheezy (which I happen to use)
provides 5.14...
[...]
>> I've seen "solutions" to this kind of "problem," such as those
>> implemented by the designers of Python and Go. And the only thing
>> that comes to my mind is the old saying (paraphrased): "If
>> programmers are so smart, why aren't they walking in formation?"
> OK, whatever. If you post code here which uses English people are
> likely to find it harder to read than if it didn't, so you are less
> likely to get useful help.
Now, that's a valid point.
[...]
--
FSF associate member #7257
------------------------------
Date: Sat, 16 Mar 2013 21:56:42 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: classic loop to controlled iterator
Message-Id: <ki2pqq$4tv$1@reader1.panix.com>
There are general comments I can make: consistent indentation really
helps in understanding code, I prefer ";" at the end of each block,
the output for two alternatives should be identical so you can compare
the output of the two versions, I really prefer "return" for an
explicit return.
The biggest problem is that the proposal as written doesn't work. The
original code outputs 1..5, 10..20, but the replacement outputs 1..20.
Even if it's a contrived example to illustrate a point, working code
should be posted.
I also agree with the comment about inefficiency. It's repeating the
entire sequence to reach one value, "||" to get a value but continuing
past the first value. I'm thinking you might not have been aware of
"return", and it would not work with a zero or null value.
Here's a working version:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#! /usr/bin/perl
use strict;
use warnings;
if (0) {
my $i=5;
for (1..$i) {
print "$_\n"
}
for (2*$i..4*$i) {
print "$_\n"
}
} else {
my $prog = wrapper(5);
while ( $_ = $prog->() ) {
print "$_\n";
}
}
exit 0;
sub wrapper {
my ($i, $last) = ($_[0], 0);
return sub {
++$last;
for ($last .. $i) { return $_; }
$last = 2*$i if $last < 2*$i;
for ($last .. 4*$i) { return $_; }
return undef;
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(After Perl 5.9.4, you could use a "state" declaration, but I've hit
old versions of perl often enough, on systems that I don't control,
that a solution that works on older perls is a good notion.)
In
for ($last .. $i) { return $_; }
I believe that "for $i (a..b)" is optimized to "for ($i = a; $i < b; ++$i)".
Because the loop body returns immediately, the "for" really functions
as an "if": this works the same:
return $last if $last <= $i;
But using "for" makes it perhaps a little more readable, makes it look
more like the original version.
This is no longer O(n^2), but roughly as efficient as the original
version -- sub has no actual loops. But it still goes thru a series
of implicit if statements on each call. It's a trivial enough thing
in this case, but in general, it might be highly problematic.
One solution would be to generate the output stream on the first call
and parcel them out one at a time:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sub wrapper {
my ($i) = ($_[0]);
my @results = (1..$i, 2*$i..4*$i);
return sub {
return shift @results;
}
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's certainly clear to understand. But that sort of misses the point
of having a generator. It has to generate all the results at the
start, but one purpose of a generator is that you can get a few of the
first results, not bother getting the rest, and only pay the cost of
getting the ones you got. Also, if the process to get a result
consumes something or is less trivial than this (e.g., reading from a
terminal), it could be problematic or impossible to do this. It also
consumes all the sorage to hold all the results at once, so there are
two failures if your generator is supposed to, say, return all the
positive integers.
In general, what you really want are "generators". The notion is that
a computation can proceed for a time, but suspend and yield a result
to the caller. When the caller calls back, the thread of execution
starts continuing after the point of the last yield.
From a quick search, looking at only the first few pages of 1292 hits
in CPAN for
generator
http://search.cpan.org/~mlehmann/Coro-6.23/ is the basis of what you
want. It implements coroutines / continuations, which have the
stop-and-resume model but don't necessarily yield a result.
http://search.cpan.org/~rintaro/Attribute-Generator-0.02/lib/Attribute/Generator.pm
appears to use Coro to implement stop-and-resume plus yielding
results. I've not used either, so I can't express an opinion about
how reliable, efficient, and usable they are.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 17 Mar 2013 20:07:48 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: classic loop to controlled iterator
Message-Id: <87fvztokmj.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
[...]
> In general, what you really want are "generators". The notion is that
> a computation can proceed for a time, but suspend and yield a result
> to the caller. When the caller calls back, the thread of execution
> starts continuing after the point of the last yield.
>
> From a quick search, looking at only the first few pages of 1292 hits
> in CPAN for
> generator
> http://search.cpan.org/~mlehmann/Coro-6.23/ is the basis of what you
> want. It implements coroutines / continuations, which have the
> stop-and-resume model but don't necessarily yield a result.
> http://search.cpan.org/~rintaro/Attribute-Generator-0.02/lib/Attribute/Generator.pm
> appears to use Coro to implement stop-and-resume plus yielding
> results. I've not used either, so I can't express an opinion about
> how reliable, efficient, and usable they are.
One of the really 'nice' parts of the Wikipedia page on generators is
that it states that (paraphrase) "A generator is a kind of coroutine
except that it isn't coroutine but a subroutine" (which only ever
returns to the caller). Any 'thing' which can be 'invoked' somehow and
then returns 'the next value from some set of values' utilizing
internal state information to keep track of what precisely 'the next
value' is supposed to be, is 'a generator'. The obvious idea how to
implement that would be 'some kind of class with a next_value
method'. Often, it will be more convenient to use a closure instead.
------------------------------
Date: Mon, 18 Mar 2013 12:54:21 +0100
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Subject: Re: getting perl and php to talk to each other
Message-Id: <2785829.OKbtRJzbVc@PointedEars.de>
SwissCheese wrote:
^^^^^^^^^^^
Please put your real name there. And stop crossposting without Followup-To
(F'up2).
> The file 'php-config' is a pointer (hard/soft link) to 'php-config5'.
Most likely it is not a hardlink, but a symlink.
F'up2 .php
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
------------------------------
Date: Mon, 18 Mar 2013 15:09:57 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Identifying functions in C files and replacing them with a keyword through PERL
Message-Id: <180320131509570935%jimsgibson@gmail.com>
In article <a7299d3e-cd23-4e47-b044-a52b3cce501d@googlegroups.com>,
IJALAB <balaji.draj@gmail.com> wrote:
> Hi
>
> I have to write a parser to go over the C code base and identify all the
> functions in each file and replace each function name with a keyword, for
> example, i have a file name
> 1.c
> int func1(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> void func2(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> float func3(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> My intention is to replace func1, func2, func3 with func1_main, func2_main,
> func3_main....
> The code base is big and there are lot of files and other open close braces
> in if else statements etc.., so, i would like to know any parser that exist
> in PERL to do this intended function.
I have used Text::Balanced and its extract_delimited() subroutine for
this type of task. It works OK if your source files are reasonable and
not pathological. Search for the first '{' in the file, then use the
extract_delimited() routine to find the matching, closing '}', etc.
--
Jim Gibson
------------------------------
Date: Mon, 18 Mar 2013 22:36:41 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Identifying functions in C files and replacing them with a keyword through PERL
Message-Id: <pghk1a-nh11.ln1@anubis.morrow.me.uk>
Quoth Jim Gibson <jimsgibson@gmail.com>:
> In article <a7299d3e-cd23-4e47-b044-a52b3cce501d@googlegroups.com>,
> IJALAB <balaji.draj@gmail.com> wrote:
>
> > I have to write a parser to go over the C code base and identify all the
> > functions in each file and replace each function name with a keyword, for
> > example, i have a file name
[...]
>
> I have used Text::Balanced and its extract_delimited() subroutine for
> this type of task. It works OK if your source files are reasonable and
> not pathological. Search for the first '{' in the file, then use the
> extract_delimited() routine to find the matching, closing '}', etc.
This will also catch file-level struct/union/enum definitions. I suspect
that making this approach even moderately robust would be harder than
implementing a proper grammar: C isn't exactly a complicated language.
Ben
------------------------------
Date: Mon, 18 Mar 2013 23:19:59 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Identifying functions in C files and replacing them with a keyword through PERL
Message-Id: <87y5dk8fds.fsf@sapphire.mobileactivedefense.com>
IJALAB <balaji.draj@gmail.com> writes:
> I have to write a parser to go over the C code base and identify all the functions in each file and replace each function name with a keyword, for example, i have a file name
> 1.c
> int func1(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> void func2(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> float func3(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> My intention is to replace func1, func2, func3 with func1_main, func2_main, func3_main....
> The code base is big and there are lot of files and other open close
> braces in if else statements etc.., so, i would like to know any
> parser that exist in PERL to do this intended function.
Do you want to keep the existing formatting? If not, the 'dead-easy'
approach would be to run indent -kr on all of your source files and
then replace the name in front of the bracketed (parenthesed?) sequence on all lines
immediately followed by a line with a { in the first column.
------------------------------
Date: Mon, 18 Mar 2013 23:53:18 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Identifying functions in C files and replacing them with a keyword through PERL
Message-Id: <e0mk1a-9d21.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> IJALAB <balaji.draj@gmail.com> writes:
> > I have to write a parser to go over the C code base and identify all
> the functions in each file and replace each function name with a
> keyword, for example, i have a file name
> > 1.c
> > int func1(struct commandId)
> > {
> > do();
> > return ( SUCCESS );
> > }
> > void func2(struct commandId)
> > {
> > do();
> > return ( SUCCESS );
> > }
> > float func3(struct commandId)
> > {
> > do();
> > return ( SUCCESS );
> > }
> > My intention is to replace func1, func2, func3 with func1_main,
> func2_main, func3_main....
> > The code base is big and there are lot of files and other open close
> > braces in if else statements etc.., so, i would like to know any
> > parser that exist in PERL to do this intended function.
>
> Do you want to keep the existing formatting? If not, the 'dead-easy'
> approach would be to run indent -kr on all of your source files and
> then replace the name in front of the bracketed (parenthesed?) sequence
> on all lines
> immediately followed by a line with a { in the first column.
Heh :). I was going to say something along the lines of 'if you had used
K&R formatting this would have been easy'...
My indent(1) doesn't have a -kr switch (is this a GNUism?) but the
default of -fbs -psl is sufficient for this. This will also not handle
prototypes.
Ben
------------------------------
Date: Mon, 18 Mar 2013 01:01:32 -0700 (PDT)
From: IJALAB <balaji.draj@gmail.com>
Subject: Identifying functions in C files and replacing them with a keyword through PERL
Message-Id: <a7299d3e-cd23-4e47-b044-a52b3cce501d@googlegroups.com>
Hi
I have to write a parser to go over the C code base and identify all the functions in each file and replace each function name with a keyword, for example, i have a file name
1.c
int func1(struct commandId)
{
do();
return ( SUCCESS );
}
void func2(struct commandId)
{
do();
return ( SUCCESS );
}
float func3(struct commandId)
{
do();
return ( SUCCESS );
}
My intention is to replace func1, func2, func3 with func1_main, func2_main, func3_main....
The code base is big and there are lot of files and other open close braces in if else statements etc.., so, i would like to know any parser that exist in PERL to do this intended function.
thanks a lot
bala
------------------------------
Date: Mon, 18 Mar 2013 20:59:48 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Identifying functions in C files and replacing them with a keyword through PERL
Message-Id: <4rbk1a-dn01.ln1@anubis.morrow.me.uk>
Quoth IJALAB <balaji.draj@gmail.com>:
>
> I have to write a parser to go over the C code base and identify all the
> functions in each file and replace each function name with a keyword,
> for example, i have a file name
> 1.c
> int func1(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> void func2(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> float func3(struct commandId)
> {
> do();
> return ( SUCCESS );
> }
> My intention is to replace func1, func2, func3 with func1_main,
> func2_main, func3_main....
Do you also have to replace calls? Prototypes?
> The code base is big and there are lot of files and other open close
> braces in if else statements etc.., so, i would like to know any parser
> that exist in PERL to do this intended function.
Well, Inline::C has a limited C grammar, but I don't know if it will do
what you want. You may have to start with the grammar in the C standard,
and Parse::RecDescent.
If I were doing this I might try mucking around with nm and objdump to
get the compiler to find the functions for me. gcc -gstabs followed by
objdump -G on the object file seems to give some useful information (the
n_desc field of an SLINE entry seems to be a line number).
Alternatively, ctags -x also looks quite promising.
Ben
------------------------------
Date: Sun, 17 Mar 2013 17:57:58 +0000
From: Ivan Shmakov <oneingray@gmail.com>
Subject: Re: Imager::QRCode-ing octet sequences vs. zbarimg(1)
Message-Id: <87txo9j4d5.fsf@violet.siamics.net>
>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>> I wonder if QR codes are suitable for encoding arbitrary octet
>> sequences (AKA 8-bit data)? I've tried the following Perl code, but
>> it appears that the resulting transformations aren't "8-bit clean."
>> Somehow, I suspect a QR::Imager fault, although zbarimg(1) may be
>> responsible. (Unfortunately, the Perl module itself doesn't provide
>> a decoder.)
> There is a Perl decoder based on zbar (Barcode::ZBar), though
> presumably it would behave the same as zbarimg.
... Indeed it does, which made me file Debian Bug#703234 [1].
Now, however, given that the Wikipedia article mentions
ISO-8859-1 as the default (?) encoding for 8-bit QR codes, the
issues zbarimg(1) and Barcode::ZBar have may be considered
separately.
Taking into account that different symbologies may (and do) use
different character to code mappings, it may be sensible for
libzbar to recode the barcode read into an UTF-8 string. Better
still is that Perl supports UTF-8 as its native character string
representation. What's wrong, however, is that the UTF-8 string
returned by libzbar to Perl is not properly marked as such, thus
resulting in the observed (and incorrect) behavior.
(The obvious workaround is to Encode::decode_utf8 () the
symbol's data returned by ->get_data ().)
OTOH, zbarimg(1) should probably respect the current locale's
encoding, instead of using UTF-8 unconditionally.
[1] http://bugs.debian.org/703234
[...]
--
FSF associate member #7257
------------------------------
Date: Mon, 18 Mar 2013 23:42:38 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Imager::QRCode-ing octet sequences vs. zbarimg(1)
Message-Id: <eclk1a-9d21.ln1@anubis.morrow.me.uk>
Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> >> I wonder if QR codes are suitable for encoding arbitrary octet
> >> sequences (AKA 8-bit data)? I've tried the following Perl code, but
> >> it appears that the resulting transformations aren't "8-bit clean."
> >> Somehow, I suspect a QR::Imager fault, although zbarimg(1) may be
> >> responsible. (Unfortunately, the Perl module itself doesn't provide
> >> a decoder.)
>
> > There is a Perl decoder based on zbar (Barcode::ZBar), though
> > presumably it would behave the same as zbarimg.
>
> ... Indeed it does, which made me file Debian Bug#703234 [1].
<pet peeve> The correct place to file a bug in a Perl module is in its
CPAN bug tracker, or, in this case, in the zbar Sourceforce tracker.
Filing a bug with some random distro is Not Helpful, since such reports
frequently don't find their way upstream.
> Now, however, given that the Wikipedia article mentions
> ISO-8859-1 as the default (?) encoding for 8-bit QR codes, the
> issues zbarimg(1) and Barcode::ZBar have may be considered
> separately.
The zbar source implies that some QR codes contain something called an
ECI which explicitly indicates the charset in use. It's not clear to me
without reading the spec (which apparently isn't freely available, grr)
how 'binary' QR codes with no ECI are supposed to be interpreted.
> Taking into account that different symbologies may (and do) use
> different character to code mappings, it may be sensible for
> libzbar to recode the barcode read into an UTF-8 string.
Well, that's only sensible if the bytes are always supposed to represent
characters. libzbar also does more than just recode 8859-1 -> UTF-8: if
I'm reading it right, it tries to guess the encoding, and if the encoded
data is already valid UTF-8 it will leave it alone.
> Better
> still is that Perl supports UTF-8 as its native character string
> representation. What's wrong, however, is that the UTF-8 string
> returned by libzbar to Perl is not properly marked as such, thus
> resulting in the observed (and incorrect) behavior.
This is a bug, yes.
> (The obvious workaround is to Encode::decode_utf8 () the
> symbol's data returned by ->get_data ().)
>
> OTOH, zbarimg(1) should probably respect the current locale's
> encoding, instead of using UTF-8 unconditionally.
I don't know about that: what if the data can't be represented in that
charset?
Ben
------------------------------
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 3904
***************************************
