iverilog-devel — Conversations on matters of Icarus Verilog development

Re: [Iverilog-devel] Type conversion and parameters

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> In section 4.5.1 of 1364-2001 it states that for non-self-determined
> operands if any operand is real the results will be real, but my
> interpretation of a simple parameter is that it can be self-determined. If
> not specified it takes the type and size of the RHS. So would the
> following give one real and one bit based parameter or two real
> parameters?
> 
> parameter real_val = 1'b1 ? 1.0 : 4'b1010;
> parameter int_val = 1'b0 ? 1.0 : 4'b1010; // is this 4'b1010 or 10.0?

I would say that they are both real. In both cases above, the
operands that carry type in the ternary are both logically checked
for type and width, and I think therefore the ternary as a whole
is real valued. The standard doesn't seem to say so, but I think
it is reasonable to assume that "5.5.1 Rules for expression types"
applies to ternary operators' true and false operands and not
the condition operand (which is defined to be logic):

- From 5.5.1 Rules for expression types:
- -- Expression type depends only on the operands.



- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH0ZCurPt1Sc2b3ikRAgZQAJ9czffo1gQJtxeO+b7kbkK/4OSSKQCfcVAp
WRDk9LeL/Q6LjRNMoaP/qjk=
=7RcD
-----END PGP SIGNATURE-----

[Iverilog-devel] Type conversion and parameters

[Cary R. <cy...@ya...>]

In section 4.5.1 of 1364-2001 it states that for non-self-determined
operands if any operand is real the results will be real, but my
interpretation of a simple parameter is that it can be self-determined. If
not specified it takes the type and size of the RHS. So would the
following give one real and one bit based parameter or two real
parameters?

parameter real_val = 1'b1 ? 1.0 : 4'b1010;
parameter int_val = 1'b0 ? 1.0 : 4'b1010; // is this 4'b1010 or 10.0?

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Iverilog-devel] do_include bug: FIXED

[Michael W. <mfw...@MI...>]

On 5 Mar 2008, at 12:52 PM, Cary R. wrote:

> --- Stephen Williams <st...@ic...> wrote:
>
>> I think this is a lot of hoopla for the testing of such a tiny  
>> feature.
>> I would rather not pollute the main test suite script for such rare
>> cases.
>
> Like I said in an earlier post, my preference is for you to have a  
> local
> test for this that you run along with the normal test suite. I have a
> bunch of circuits I run locally to check for problem. It is these  
> local
> tests that found pr1903343. As long as someone in the development  
> process
> is testing this I think we can omit it from the test suite.

Frankly, I think that all useful testing should be made part of one  
testing
framework.

After all, the painfully obvious/embarrassing bug that I introduced  
passed
the official testing suite with flying colors, and the latest patch that
I submitted was accepted as follows:

	"The regression test still passes, and I trust that it solves the
	problem it's supposed to solve."

While I'm flattered, it seems that the trust in the test suite is a  
bit undue.

Michael Witten

Re: [Iverilog-devel] do_include bug: FIXED

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

> I think this is a lot of hoopla for the testing of such a tiny feature.
> I would rather not pollute the main test suite script for such rare
> cases.

Like I said in an earlier post, my preference is for you to have a local
test for this that you run along with the normal test suite. I have a
bunch of circuits I run locally to check for problem. It is these local
tests that found pr1903343. As long as someone in the development process
is testing this I think we can omit it from the test suite.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Iverilog-devel] do_include bug: FIXED

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> --- Michael Witten <mfw...@MI...> wrote:
>> Could you just construct the path from the current working directory and
>> the qualified name used to run vvp_reg.pl?
> 
> This may be the best choice. I don't think we should build the code on the
> fly since that requires too much coupling to the driver program, but the
> driver program could provide the working directory to a script as needed.
> 
> There are a couple of different paths we could take on this. The script
> could create a file with the current path as a define that any test could
> use. Or we could make a macro that the the script would use to pass the
> value e.g.(-D@PATH@ in the *_regress.list). Either is probably acceptable.
> There may be other information we may want to pass as well.
> 
> Steve, do you have a preference?

I think this is a lot of hoopla for the testing of such a tiny feature.
I would rather not pollute the main test suite script for such rare
cases.

Maybe a better idea might be to come up with a test harness just
for testing the preprocessor. Use "iverilog -E" everywhere in that
script, and use gold files and a directory structure just for that
purpose. Then all the oddities of testing the preprocessor are
taken out of the main test bench. This preprocessor specific test
harness can be designed to be better suited to the needs of testing
a preprocessor (including its interaction with command line flags
and command files).

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHztrkrPt1Sc2b3ikRAvRZAJ4sHSv+wezNNJ3uuGJvG3UWACq8MgCgi82f
LS0Ivet0smCxzLmHjBOMASw=
=BKM6
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] do_include bug: FIXED

[Cary R. <cy...@ya...>]

--- Michael Witten <mfw...@MI...> wrote:

> Could you just have the perl script create a temporary file and use its
> absolute path?

The problem here is where would you create it so that you always had
permission? /tmp is an easy choice for UNIX machines, but Icarus is used
on more platforms than that. I'm uncertain if there is a place that is
universally available. 
 
> Could you just construct the path from the current working directory and
> the qualified name used to run vvp_reg.pl?

This may be the best choice. I don't think we should build the code on the
fly since that requires too much coupling to the driver program, but the
driver program could provide the working directory to a script as needed.

There are a couple of different paths we could take on this. The script
could create a file with the current path as a define that any test could
use. Or we could make a macro that the the script would use to pass the
value e.g.(-D@PATH@ in the *_regress.list). Either is probably acceptable.
There may be other information we may want to pass as well.

Steve, do you have a preference?

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Iverilog-devel] do_include bug: FIXED

[Michael W. <mfw...@MI...>]

On 5 Mar 2008, at 1:16 AM, Cary R. wrote:

> Actually you can't reliably test this in the test suite. What path  
> would
> you use that is available on all platforms that points into  
> something the
> test suite can access? There is no restriction on where the test  
> suite can
> be installed.
>
> Maybe Steve should have a local test for this since he verifies  
> patches do
> not break anything before he pushes them into the main git repository.

Could you just have the perl script create a temporary file and use its
absolute path?

Could you just construct the path from the current working directory and
the qualified name used to run vvp_reg.pl?

Re: [Iverilog-devel] do_include bug: FIXED

[Cary R. <cy...@ya...>]

--- Michael Witten <mfw...@MI...> wrote:

Thanks for taking care of this bug!

> This brings me to another point: the test suite
> should be testing this (at least now).

Actually you can't reliably test this in the test suite. What path would
you use that is available on all platforms that points into something the
test suite can access? There is no restriction on where the test suite can
be installed.

Maybe Steve should have a local test for this since he verifies patches do
not break anything before he pushes them into the main git repository.

> Also, are there any plans to convert the test
> suite to use git?

That would be nice, but CVS seems to work fine. To me we need the power of
git for Icarus Verilog because we have more people working on it. As far
as I know Steve and I are the only ones currently working on the test
suite. Other than my rewrite of the two driver programs and some gold file
cleanup all we have done lately is add tests from bug reports and patch
submissions.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

[Iverilog-devel] do_include bug: FIXED

[Michael W. <mfw...@MI...>]

Hello,

Cary pointed out that do_include was not
handling absolute paths after I rearranged
the code.

This is a fairly serious bug, so it would
be best to get this fixed quickly.

I've submitted a patch:

	http://sourceforge.net/tracker/index.php?func=detail&aid=1907664&group_id=149850&atid=775999

This brings me to another point: the test suite
should be testing this (at least now).

Also, are there any plans to convert the test
suite to use git?

Sincerely,
Michael Witten

Re: [Iverilog-devel] git exclude file and git-status

[Cary R. <cy...@ya...>]

--- Michael Witten <mfw...@MI...> wrote:

> What a godsend!
> 
> I had aquiesced to using
> 
> 	git ls-files -m

I'm glad to be of assistance! ls-files works, but it, as you probably
know, doesn't show new files that have been created.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Iverilog-devel] git exclude file and git-status

[Michael W. <mfw...@MI...>]

On Tuesday 04 March 2008 17:32:53 Cary R. wrote:
> You should only see changed files and any local files you have
> created. The gitignore(5) manual page has details on the file syntax.

What a godsend!

I had aquiesced to using

	git ls-files -m

;-)

Michael Witten

[Iverilog-devel] git exclude file and git-status

[Cary R. <cy...@ya...>]

git-status is a nice command to see what files you have locally changed
without having to look at the actual details. The problem is that all the
generated files show up in the list as files that could be added to the
repository. The attached exclude file removes these generated files from
the list. You should only see changed files and any local files you have
created. The gitignore(5) manual page has details on the file syntax.

Starting in the top repository directory the file should be placed in the
.git/info directory. There will probably already be a dummy file in the
directory. Everything should be commented out.

If I missed anything let me know. I checked this with the latest
development from git on RHEL 4 and cygwin.

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

[Iverilog-devel] Google Summer of Code 2008

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


It's that time of year again, its time for the Google Summer of Code!

Here's a summary:
 <http://code.google.com/soc/2008/>

I intend for Icarus Verilog to participate as part of the gEDA
project, and as I did last year, I'll be volunteering as a mentor.
If you know of some "students" who might be interested in doing
google sponsored work in Icarus Verilog, now's the time to point
them to the above link.

As developers, we should all look at the Projects page in the
Icarus Verilog Wiki <http://iverilog.wikia.com/wiki/Projects>
and put some thought into expanding that list with tasks that are
appropriate for GSoC candidates. Candidates tend to draw from the
existing suggestions so this is the best way to encourage
participation.

Also, the rest of gEDA (i.e. gschem, pcb, etc.) will be looking for
students as well so the geda-dev mailing list is a good place to
send potential students interested in that side of EDA.
- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHwwFurPt1Sc2b3ikRAjdOAJ9GtLq60v406EpixbwOxDVWllAnlACgl6Gq
Uy8NRLfOf+ZS/OOu088r45M=
=rfmt
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] The mostly monochromatic bug database and renaming reports.

[Cary R. <cy...@ya...>]

I have updated many of the devel reports with new summaries or priorities.
I'm sure I missed a few, but it is a start.

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Iverilog-devel] The mostly monochromatic bug database and renaming reports.

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:
 
> I like that break-down. It would be handy in fact if the message
> shown to the bug submitter shows this (or it is put in the Wiki)
> so that it is more up front.

Both are possible, but I don't know if normal users can set bug priority
and some do not supply the information needed to correctly determine the
priority. I try to poke at most reports when they appear to find the easy
fixes and could change priorities at that time. As a minimum this needs to
be documented on the Wiki with a pointer to it on the bug submission page.

> I should add that it also is pretty monochromatic because we've
> done a stellar job of killing high-priority bugs:-)

Well there is that! There are a few 5's that fit in the 6 category and a
few more that fit in the 4 category. 
 
> Oh, there are *many* times when I thought of doing that, but as
> often as not I fix the bug before I could think of a better name
> for the subject. By all means if you think you have a better subject,
> please change it.

Will do! There are a few that I have done some preliminary debug on, but
at the time, and possible still, didn't have enough knowledge of the
system to feel comfortable fixing.

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Iverilog-devel] The mostly monochromatic bug database and renaming reports.

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> The bug database is not truly monochromatic, but there is not much dynamic
> range either. Does it make sense to expand the range a bit to help
> determine what is important? Something like the following:
> 
> 7 - an invalid result without a warning that cannot be worked around.
> 
> 6 - an invalid result without a warning, but it can be worked around or a
> program crash that is preventing someone for using Icarus.
> 
> 5 - the catch all and where everything starts.
> 
> 4 - functionality that is missing from Icarus, but is not currently needed
> or can be worked around with code changes.
> 
> 3 - minor issues like invalid warnings or missing warnings.

I like that break-down. It would be handy in fact if the message
shown to the bug submitter shows this (or it is put in the Wiki)
so that it is more up front.

I should add that it also is pretty monochromatic because we've
done a stellar job of killing high-priority bugs:-)

> There are also a number of bug reports that could be renamed to more
> closely reflect the problem they are reporting. Doing this would make it
> easier for someone looking at the bug database to determine what the
> problems actually are instead of having to read the comments attached to
> the individual reports. So would this be useful, is this something we want
> to do?

Oh, there are *many* times when I thought of doing that, but as
often as not I fix the bug before I could think of a better name
for the subject. By all means if you think you have a better subject,
please change it.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHvfpRrPt1Sc2b3ikRAifwAKCjrcBN3v6c4ZPcj07BdQClAa/wEgCeMWgc
EeS/DBx/y3NzXHPQK2bMFmw=
=yqpA
-----END PGP SIGNATURE-----

[Iverilog-devel] The mostly monochromatic bug database and renaming reports.

[Cary R. <cy...@ya...>]

The bug database is not truly monochromatic, but there is not much dynamic
range either. Does it make sense to expand the range a bit to help
determine what is important? Something like the following:

7 - an invalid result without a warning that cannot be worked around.

6 - an invalid result without a warning, but it can be worked around or a
program crash that is preventing someone for using Icarus.

5 - the catch all and where everything starts.

4 - functionality that is missing from Icarus, but is not currently needed
or can be worked around with code changes.

3 - minor issues like invalid warnings or missing warnings.


There are also a number of bug reports that could be renamed to more
closely reflect the problem they are reporting. Doing this would make it
easier for someone looking at the bug database to determine what the
problems actually are instead of having to read the comments attached to
the individual reports. So would this be useful, is this something we want
to do?

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

[Iverilog-devel] minor flex bug

[Larry D. <ldo...@re...>]

Debian bug #466793 applies to (and I discovered with) builds
of Icarus.  If you "upgrade" to flex-2.5.34, be aware that two
new compile-time warnings appear that are flex's fault.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466793

   - Larry

Re: [Iverilog-devel] Claiming some files.

[Steven W. <st...@in...>]

Your welcome ;-)

Larry Doolittle wrote:
> On Wed, Feb 20, 2008 at 10:05:57AM -0800, Cary R. wrote:
>   
>> --- Stephen Williams <st...@ic...> wrote:
>>
>>     
>>> Although I don't normally go changing tings for the sake of changing
>>> them [chop]
>>>       
>> I do need to touch some of these for pr1892959 and as I have looked at the
>> files I'm finding other problems that have not yet been reported. The only
>> reason I'm considering something this drastic is because I've been working
>> on  expression code for over a month now, so I think I have a good grasp
>> on what is and should be happening.
>>     
>
> All hail the test suite!
>
>     - Larry
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>   

Re: [Iverilog-devel] Claiming some files.

[Larry D. <ldo...@re...>]

On Wed, Feb 20, 2008 at 10:05:57AM -0800, Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
> 
> > Although I don't normally go changing tings for the sake of changing
> > them [chop]
> 
> I do need to touch some of these for pr1892959 and as I have looked at the
> files I'm finding other problems that have not yet been reported. The only
> reason I'm considering something this drastic is because I've been working
> on  expression code for over a month now, so I think I have a good grasp
> on what is and should be happening.

All hail the test suite!

    - Larry

Re: [Iverilog-devel] Claiming some files.

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

> Although I don't normally go changing tings for the sake of changing
> them (I try to have a cleanup plan and follow it while touching files
> for other reasons) that usually means I never get around to these
> cleanups. I do think the current division of labor has led to some
> unnecessary bugs, so yours seems like a valuable plan.

I do need to touch some of these for pr1892959 and as I have looked at the
files I'm finding other problems that have not yet been reported. The only
reason I'm considering something this drastic is because I've been working
on  expression code for over a month now, so I think I have a good grasp
on what is and should be happening.

Cary


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Iverilog-devel] Claiming some files.

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> I also need to claim eval_tree.cc.
> 
> My current thought on all this is to standardize on a two step process.
> The first will evaluate/propagate constant expressions and will also do
> any optimizations/synthesis that is needed. This is all done at the
> expression level. The second part will convert the optimized expressions
> into NetNet objects for the back end to use. I think this should clean up
> the code significantly over what is currently in elab_net.cc. Where
> everything is combined into a single routine.

I'm OK with all that.

Although I don't normally go changing tings for the sake of changing
them (I try to have a cleanup plan and follow it while touching files
for other reasons) that usually means I never get around to these
cleanups. I do think the current division of labor has led to some
unnecessary bugs, so yours seems like a valuable plan.


- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHvGdHrPt1Sc2b3ikRAsAZAKDrsrFp1UAMjN9MDW8GtKqWvq1AKgCgwfJ/
r3AtucWqQrytC+qgTgwCkLE=
=7TGr
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] Claiming some files.

[Cary R. <cy...@ya...>]

I also need to claim eval_tree.cc.

My current thought on all this is to standardize on a two step process.
The first will evaluate/propagate constant expressions and will also do
any optimizations/synthesis that is needed. This is all done at the
expression level. The second part will convert the optimized expressions
into NetNet objects for the back end to use. I think this should clean up
the code significantly over what is currently in elab_net.cc. Where
everything is combined into a single routine.

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: [Iverilog-devel] On Spaces and Tabs

[Michael W. <mfw...@MI...>]

On 18 Feb 2008, at 2:45 PM, Stephen Williams wrote:

> ... But I do insist that the code should be viewed the way the
> writer wrote it.
> ...
> As for the actual indent position for each level of nesting, I tend
> to use 6, although I will sometimes shrink that to keep lines from
> falling too far off the end. The rest is pretty much an accident of
> my emacs configuration

So, it would seem you are suggesting that all whitespace
be soft tabs (spaces) and that the main concern be to
produce readable (locally-consistent) code.

In any case, I think it would be wise for you to put your
foot down on something explicit, such as outlawing tabs,
which can easily be caught by git with some commit hook.

Sincerely,
Michael Witten

Re: [Iverilog-devel] Claiming some files.

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> If possible I want to claim the following files for a week or so. I
> started some major reorganizations/rewrites and to make all our lives
> easier it would be best if I'm the only one changing them for a while.
> 
> elab_expr.cc, elab_net.cc, expr_synth.cc and to a lesser extent netmisc.*.

I've been warned.

I'm reworking the handling of lexical scope so I might also find
myself touching elab_sig.cc and elaborate.cc somewhat. For the
moment though I'm deep in the parse.y and pform*.{h,cc} files.
(I should catch up on the outstanding patches submitted too.)

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHuw3+rPt1Sc2b3ikRAobsAJ9xeu7CxVI2FAUmFZJ6aNMiP7gjIgCgpZnR
GsfbcgAizhjnUeZb+GBpZeo=
=IcI7
-----END PGP SIGNATURE-----