use the perl license for their
documentation too? I know there's a GNU
documentation license too. Has anyone
on the list open-sourced a document? what
license did you use? and why?
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman
are scheduled for deletion.
Enjoy.
Greg
___
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
I'm not very experienced with Test::* type modules.
I'm using Test::More, but I'm not attached.
If there is some otehr test module that solves the below problems, I
will switch.
First thing, when I run Test::More and there are problems,
I get a summary report at the end like:
# Looks like
Third option is to use oct() and hex() based on pattern
~/perl -le 'print hex("0xdeadbeef")'
3735928559
~/perl -le 'print oct("0177")' #also handles 0b
127
my $match = /^\s*0([xb])?[0-9a-f]+?/;
my $num;
if( $match && $1 eq 'x' ){ $num = hex() }
elsif( $match && ( $1 eq 'b' or $1 eq undef) ){
I have a rather complex regex that I'm throwing text at.
if($str=~m/\Athing1\:thing2\,thing3\@(\w+)\?(\d+)\Z/){
# process str
} else {
die "bad str 'str' ";
}
Is there a way to get better built in reporting with regexps?
with the above, if the string doesn't match, I get "bad input".
Copy/pasting a regexp for checking
would probably work in my situation.
That numpack idea is great.
It solves another issue i didnt
even mention which is that some
numbers can be arbitrarily huge.
If i parse one char at a time,
I should be able to use bignum
and still get the correct answer.
ok, so, I need to read in some numbers from a file.
Numbers need to allow integer, float, signed/unsigned,
as well as supporting decimal, hex, binary, octal.
Extra level of annoyance: using modules from cpan is difficult.
So, if it can be pure perl, all the better.
What I came up with was this:
Looking for a perl tool, module, script that would help me define a
register map for firmware, and take that map and generate code,
documents, you name it.
Needs to support 32 bit wide registers with sub fields, and
sub-sub-fields. And needs to be something that can handle a large submap
the amount of test code is likely to far
exceed the amount of code being tested!
The industry standard rule of thumb for ASICs is the pre-tapeout
verification effort is 3x the desigm effort.
On 2022-09-13 09:05, Bill Ricker via Boston-pm wrote:
On Tue, Sep 13, 2022 at 9:38 AM Adam
9 matches
Mail list logo
