gnupic: Thread: Re: [gnupic] gplink and .lst files

The current behavior is to prevent old stale list files from being 
confused with current hex files.  All the gputils tools behave this way 
for all file types.

Best thing to do is to rename your file.  This will also help prevent 
gputils from over writing your special list file.

George M. Gallant, Jr. wrote:

>I typically use the -l option to gplink to inhibit the creation of the
>composite .lst file.
>A side effect is gplink deletes the existing .lst file.  Moving the the
>code at approx 
>lines 267-268 264 makes seems to correct this behavior.
>
>New code:
>
>void write_lst(void) {
>  gp_symbol_type *symbol = state.object->symbols;
>  gp_aux_type *aux;
>  gp_boolean first_time = true;
>
>  if(!state.lst.enabled)
>    return;
>
>  lst_init();
>
>  list_enabled = true;
>
>Thanks,
>    George
> 
>
>  
>

Craig,

I find 2 problems with the current scheme:

    1. gpasm and gplink both produce xxx.lst files.
    2. gplink deletes the xxx.lst file even if it is not writing one
itself.

George

On Mon, 2006-03-27 at 19:52 -0600, Craig Franklin wrote:

> The current behavior is to prevent old stale list files from being 
> confused with current hex files.  All the gputils tools behave this way 
> for all file types.
> 
> Best thing to do is to rename your file.  This will also help prevent 
> gputils from over writing your special list file.
> 
> George M. Gallant, Jr. wrote:
> 
> >I typically use the -l option to gplink to inhibit the creation of the
> >composite .lst file.
> >A side effect is gplink deletes the existing .lst file.  Moving the the
> >code at approx 
> >lines 267-268 264 makes seems to correct this behavior.
> >
> >New code:
> >
> >void write_lst(void) {
> >  gp_symbol_type *symbol = state.object->symbols;
> >  gp_aux_type *aux;
> >  gp_boolean first_time = true;
> >
> >  if(!state.lst.enabled)
> >    return;
> >
> >  lst_init();
> >
> >  list_enabled = true;
> >
> >Thanks,
> >    George
> > 
> >
> >  
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

George M. Gallant, Jr. wrote:

>Craig,
>
>I find 2 problems with the current scheme:
>
>    1. gpasm and gplink both produce xxx.lst files.
>  
>
They also both generate .hex and .cod files.

>    2. gplink deletes the xxx.lst file even if it is not writing one
>itself.
>  
>
gpasm deletes xxx.lst files even if it is not writing one too.

Here is the problem with your scheme:  I compile my project with the 
list file enabled.  Then later suppress the list file output and keep 
building the project.  The list file won't match any of the current 
outputs.  This is confusing at a minimum.

If you want to keep a file, whether it is a hex, cod, list,... rename it 
or move it.  Why do you want to keep a list file that doesn't match any 
of the other outputs?

>George
>
>On Mon, 2006-03-27 at 19:52 -0600, Craig Franklin wrote:
>
>  
>
>>The current behavior is to prevent old stale list files from being 
>>confused with current hex files.  All the gputils tools behave this way 
>>for all file types.
>>
>>Best thing to do is to rename your file.  This will also help prevent 
>>gputils from over writing your special list file.
>>
>>George M. Gallant, Jr. wrote:
>>
>>    
>>
>>>I typically use the -l option to gplink to inhibit the creation of the
>>>composite .lst file.
>>>A side effect is gplink deletes the existing .lst file.  Moving the the
>>>code at approx 
>>>lines 267-268 264 makes seems to correct this behavior.
>>>
>>>New code:
>>>
>>>void write_lst(void) {
>>> gp_symbol_type *symbol = state.object->symbols;
>>> gp_aux_type *aux;
>>> gp_boolean first_time = true;
>>>
>>> if(!state.lst.enabled)
>>>   return;
>>>
>>> lst_init();
>>>
>>> list_enabled = true;
>>>
>>>Thanks,
>>>   George
>>>
>>>
>>> 
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ####@####.####
>>For additional commands, e-mail: ####@####.####
>>
>>    
>>
>
>  
>

Craig,

The difference is gplink has a -l option which is
is supposed to "Disable list file output."  Thanks
for pointing out  a weakness in gpasm.

George

On Mon, 2006-03-27 at 20:57 -0600, Craig Franklin wrote:

> George M. Gallant, Jr. wrote:
> 
> >Craig,
> >
> >I find 2 problems with the current scheme:
> >
> >    1. gpasm and gplink both produce xxx.lst files.
> >  
> >
> They also both generate .hex and .cod files.
> 
> >    2. gplink deletes the xxx.lst file even if it is not writing one
> >itself.
> >  
> >
> gpasm deletes xxx.lst files even if it is not writing one too.
> 
> Here is the problem with your scheme:  I compile my project with the 
> list file enabled.  Then later suppress the list file output and keep 
> building the project.  The list file won't match any of the current 
> outputs.  This is confusing at a minimum.
> 
> If you want to keep a file, whether it is a hex, cod, list,... rename it 
> or move it.  Why do you want to keep a list file that doesn't match any 
> of the other outputs?
> 
> >George
> >
> >On Mon, 2006-03-27 at 19:52 -0600, Craig Franklin wrote:
> >
> >  
> >
> >>The current behavior is to prevent old stale list files from being 
> >>confused with current hex files.  All the gputils tools behave this way 
> >>for all file types.
> >>
> >>Best thing to do is to rename your file.  This will also help prevent 
> >>gputils from over writing your special list file.
> >>
> >>George M. Gallant, Jr. wrote:
> >>
> >>    
> >>
> >>>I typically use the -l option to gplink to inhibit the creation of the
> >>>composite .lst file.
> >>>A side effect is gplink deletes the existing .lst file.  Moving the the
> >>>code at approx 
> >>>lines 267-268 264 makes seems to correct this behavior.
> >>>
> >>>New code:
> >>>
> >>>void write_lst(void) {
> >>> gp_symbol_type *symbol = state.object->symbols;
> >>> gp_aux_type *aux;
> >>> gp_boolean first_time = true;
> >>>
> >>> if(!state.lst.enabled)
> >>>   return;
> >>>
> >>> lst_init();
> >>>
> >>> list_enabled = true;
> >>>
> >>>Thanks,
> >>>   George
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: ####@####.####
> >>For additional commands, e-mail: ####@####.####
> >>
> >>    
> >>
> >
> >  
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

George M. Gallant, Jr. wrote:

>Craig,
>
>The difference is gplink has a -l option which is
>is supposed to "Disable list file output."  Thanks
>for pointing out  a weakness in gpasm.
>
>  
>
I forgot how much fun this is.  I am glad to be back :)

So you have a project whose target is my_build.hex.  You want to add a 
-l to gplink to prevent it from generating a list file and keep another 
file not generated by gplink but named my_build.lst in the same 
project.  I will ask again, why?  Are you using some other method to 
generate a list file?

A few years back I was working on fixing a gputils bug.  Can't remember, 
but I think it was in the COD files.  Those files are managed the same 
way the list files are.  Problem was the COD file I was debugging didn't 
match the hex file because the COD file was being suppressed, but the 
output file wasn't being deleted.  A very frustrating way to waste 
time.  If it happens to me, I am sure others have experienced it.

If you have a real good reason not to do it, I am listening.  So far the 
only thing I am hearing is you don't like it.

>George
>
>On Mon, 2006-03-27 at 20:57 -0600, Craig Franklin wrote:
>
>  
>
>>George M. Gallant, Jr. wrote:
>>
>>    
>>
>>>Craig,
>>>
>>>I find 2 problems with the current scheme:
>>>
>>>   1. gpasm and gplink both produce xxx.lst files.
>>> 
>>>
>>>      
>>>
>>They also both generate .hex and .cod files.
>>
>>    
>>
>>>   2. gplink deletes the xxx.lst file even if it is not writing one
>>>itself.
>>> 
>>>
>>>      
>>>
>>gpasm deletes xxx.lst files even if it is not writing one too.
>>
>>Here is the problem with your scheme:  I compile my project with the 
>>list file enabled.  Then later suppress the list file output and keep 
>>building the project.  The list file won't match any of the current 
>>outputs.  This is confusing at a minimum.
>>
>>If you want to keep a file, whether it is a hex, cod, list,... rename it 
>>or move it.  Why do you want to keep a list file that doesn't match any 
>>of the other outputs?
>>
>>    
>>
>>>George
>>>
>>>On Mon, 2006-03-27 at 19:52 -0600, Craig Franklin wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>The current behavior is to prevent old stale list files from being 
>>>>confused with current hex files.  All the gputils tools behave this way 
>>>>for all file types.
>>>>
>>>>Best thing to do is to rename your file.  This will also help prevent 
>>>>gputils from over writing your special list file.
>>>>
>>>>George M. Gallant, Jr. wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>I typically use the -l option to gplink to inhibit the creation of the
>>>>>composite .lst file.
>>>>>A side effect is gplink deletes the existing .lst file.  Moving the the
>>>>>code at approx 
>>>>>lines 267-268 264 makes seems to correct this behavior.
>>>>>
>>>>>New code:
>>>>>
>>>>>void write_lst(void) {
>>>>>gp_symbol_type *symbol = state.object->symbols;
>>>>>gp_aux_type *aux;
>>>>>gp_boolean first_time = true;
>>>>>
>>>>>if(!state.lst.enabled)
>>>>>  return;
>>>>>
>>>>>lst_init();
>>>>>
>>>>>list_enabled = true;
>>>>>
>>>>>Thanks,
>>>>>  George
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: ####@####.####
>>>>For additional commands, e-mail: ####@####.####
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ####@####.####
>>For additional commands, e-mail: ####@####.####
>>
>>    
>>
>
>  
>

On Mon, Mar 27, 2006 at 08:57:53PM -0600, Craig Franklin wrote:
> George M. Gallant, Jr. wrote:
> 
> >   2. gplink deletes the xxx.lst file even if it is not writing one
> >itself.
> > 
> >
> gpasm deletes xxx.lst files even if it is not writing one too.
> 
> Here is the problem with your scheme:  I compile my project with the 
> list file enabled.  Then later suppress the list file output and keep 
> building the project.  The list file won't match any of the current 
> outputs.  This is confusing at a minimum.

IMHO, it's much more surprising a tool silently deleting a file without
asking, especially if you've asked it to suppress touching that file.
Couldn't it just print a message instead, eg "Warning: foo.lst exists
and is out of date"?

Regards,

Chris

>> Here is the problem with your scheme:  I compile my project with the
>> list file enabled.  Then later suppress the list file output and keep
>> building the project.  The list file won't match any of the current
>> outputs.  This is confusing at a minimum.
>
> IMHO, it's much more surprising a tool silently deleting a file without
> asking, especially if you've asked it to suppress touching that file.
> Couldn't it just print a message instead, eg "Warning: foo.lst exists
> and is out of date"?

Dear folks,

What about looking around how similar tools solve this problem?
E.g. what big brothers, 'gcc' or 'gasm' do in similar situation?

IMHO deleting (or keeping) some output files is can be done
by 'make' much better than the compiler/assembler itself.

Cheers

Gabor

The problem arises when a one of the component asm files has the same
base
name as the linker output file. For example this is my typical:

gpasm         graig,asm -> craig.o & craig.lst
gpasm         i2c.asm -> i2c.o & i2c.lst

gplink          qcraig.o + i2c.o -> craig.hex & craig.map

Identical sequences for 68k, ARM projects using the GNU tools.

I have not used the Microchip tool set since gputils started supporting
relocatable object files so I can not comment on their behavior, but

        ARC
        DEC 
        Borland
        SUN
        Microsoft
        GNU

supply options to enable/disable features that only do what the writer
requested.

Since gputils has become quite stable :), the time required for me to
hack
gputils is not very long and perhaps I could post the mods on a private
web page.

George

On Tue, 2006-03-28 at 00:11 -0600, Craig Franklin wrote:

> George M. Gallant, Jr. wrote:
> 
> >Craig,
> >
> >The difference is gplink has a -l option which is
> >is supposed to "Disable list file output."  Thanks
> >for pointing out  a weakness in gpasm.
> >
> >  
> >
> I forgot how much fun this is.  I am glad to be back :)
> 
> So you have a project whose target is my_build.hex.  You want to add a 
> -l to gplink to prevent it from generating a list file and keep another 
> file not generated by gplink but named my_build.lst in the same 
> project.  I will ask again, why?  Are you using some other method to 
> generate a list file?
> 
> A few years back I was working on fixing a gputils bug.  Can't remember, 
> but I think it was in the COD files.  Those files are managed the same 
> way the list files are.  Problem was the COD file I was debugging didn't 
> match the hex file because the COD file was being suppressed, but the 
> output file wasn't being deleted.  A very frustrating way to waste 
> time.  If it happens to me, I am sure others have experienced it.
> 
> If you have a real good reason not to do it, I am listening.  So far the 
> only thing I am hearing is you don't like it.
> 
> >George
> >
> >On Mon, 2006-03-27 at 20:57 -0600, Craig Franklin wrote:
> >
> >  
> >
> >>George M. Gallant, Jr. wrote:
> >>
> >>    
> >>
> >>>Craig,
> >>>
> >>>I find 2 problems with the current scheme:
> >>>
> >>>   1. gpasm and gplink both produce xxx.lst files.
> >>> 
> >>>
> >>>      
> >>>
> >>They also both generate .hex and .cod files.
> >>
> >>    
> >>
> >>>   2. gplink deletes the xxx.lst file even if it is not writing one
> >>>itself.
> >>> 
> >>>
> >>>      
> >>>
> >>gpasm deletes xxx.lst files even if it is not writing one too.
> >>
> >>Here is the problem with your scheme:  I compile my project with the 
> >>list file enabled.  Then later suppress the list file output and keep 
> >>building the project.  The list file won't match any of the current 
> >>outputs.  This is confusing at a minimum.
> >>
> >>If you want to keep a file, whether it is a hex, cod, list,... rename it 
> >>or move it.  Why do you want to keep a list file that doesn't match any 
> >>of the other outputs?
> >>
> >>    
> >>
> >>>George
> >>>
> >>>On Mon, 2006-03-27 at 19:52 -0600, Craig Franklin wrote:
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>The current behavior is to prevent old stale list files from being 
> >>>>confused with current hex files.  All the gputils tools behave this way 
> >>>>for all file types.
> >>>>
> >>>>Best thing to do is to rename your file.  This will also help prevent 
> >>>>gputils from over writing your special list file.
> >>>>
> >>>>George M. Gallant, Jr. wrote:
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>I typically use the -l option to gplink to inhibit the creation of the
> >>>>>composite .lst file.
> >>>>>A side effect is gplink deletes the existing .lst file.  Moving the the
> >>>>>code at approx 
> >>>>>lines 267-268 264 makes seems to correct this behavior.
> >>>>>
> >>>>>New code:
> >>>>>
> >>>>>void write_lst(void) {
> >>>>>gp_symbol_type *symbol = state.object->symbols;
> >>>>>gp_aux_type *aux;
> >>>>>gp_boolean first_time = true;
> >>>>>
> >>>>>if(!state.lst.enabled)
> >>>>>  return;
> >>>>>
> >>>>>lst_init();
> >>>>>
> >>>>>list_enabled = true;
> >>>>>
> >>>>>Thanks,
> >>>>>  George
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: ####@####.####
> >>>>For additional commands, e-mail: ####@####.####
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>> 
> >>>
> >>>      
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: ####@####.####
> >>For additional commands, e-mail: ####@####.####
> >>
> >>    
> >>
> >
> >  
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

Chris Emerson wrote:

>On Mon, Mar 27, 2006 at 08:57:53PM -0600, Craig Franklin wrote:
>  
>
>>George M. Gallant, Jr. wrote:
>>
>>    
>>
>>>  2. gplink deletes the xxx.lst file even if it is not writing one
>>>itself.
>>>
>>>
>>>      
>>>
>>gpasm deletes xxx.lst files even if it is not writing one too.
>>
>>Here is the problem with your scheme:  I compile my project with the 
>>list file enabled.  Then later suppress the list file output and keep 
>>building the project.  The list file won't match any of the current 
>>outputs.  This is confusing at a minimum.
>>    
>>
>
>IMHO, it's much more surprising a tool silently deleting a file without
>asking, especially if you've asked it to suppress touching that file.
>Couldn't it just print a message instead, eg "Warning: foo.lst exists
>and is out of date"?
>
>  
>
Understand how you feel, but I think this case is a little different.  
The assumption is the gputils is thing that normally would generate the 
file.  So it deleting something it would normally overwrite isn't as bad 
as deleting any old file in the directory.

>Regards,
>
>Chris
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####
>
>
>  
>

George M. Gallant, Jr. wrote:

>The problem arises when a one of the component asm files has the same
>base
>name as the linker output file. For example this is my typical:
>
>gpasm         graig,asm -> craig.o & craig.lst
>gpasm         i2c.asm -> i2c.o & i2c.lst
>
>gplink          qcraig.o + i2c.o -> craig.hex & craig.map
>
>  
>
Ahh, there is the problem.  Why are you using the same name for both?  
That must be confusing.

The list file isn't the only problem.  Both tools can also create and 
delete cod, hex, and coff files.  When errors occur both tools delete 
most of their output files.

Even if we change gputils like you have requested, this isn't a very 
good practice.

>Identical sequences for 68k, ARM projects using the GNU tools.
>
>I have not used the Microchip tool set since gputils started supporting
>relocatable object files so I can not comment on their behavior,
>
Good point.  I don't remember what they do.

> but
>
>        ARC
>        DEC 
>        Borland
>        SUN
>        Microsoft
>        GNU
>
>supply options to enable/disable features that only do what the writer
>requested.
>
>  
>
That is not exactly what is happening here.  You have explicitly told 
the tool to do something, -l.  The disagreement is over what -l should do.

I am not completely against changing it.  I would like to have a good 
justification.  I don't view using the same name for a component and the 
linker output as a good practice.  So it is tough to change it on that 
basis.

>Since gputils has become quite stable :), the time required for me to
>hack
>gputils is not very long and perhaps I could post the mods on a private
>web page.
>
>  
>
I will think about this and get back to you.

>George
>
>On Tue, 2006-03-28 at 00:11 -0600, Craig Franklin wrote:
>
>  
>
>>George M. Gallant, Jr. wrote:
>>
>>    
>>
>>>Craig,
>>>
>>>The difference is gplink has a -l option which is
>>>is supposed to "Disable list file output."  Thanks
>>>for pointing out  a weakness in gpasm.
>>>
>>> 
>>>
>>>      
>>>
>>I forgot how much fun this is.  I am glad to be back :)
>>
>>So you have a project whose target is my_build.hex.  You want to add a 
>>-l to gplink to prevent it from generating a list file and keep another 
>>file not generated by gplink but named my_build.lst in the same 
>>project.  I will ask again, why?  Are you using some other method to 
>>generate a list file?
>>
>>A few years back I was working on fixing a gputils bug.  Can't remember, 
>>but I think it was in the COD files.  Those files are managed the same 
>>way the list files are.  Problem was the COD file I was debugging didn't 
>>match the hex file because the COD file was being suppressed, but the 
>>output file wasn't being deleted.  A very frustrating way to waste 
>>time.  If it happens to me, I am sure others have experienced it.
>>
>>If you have a real good reason not to do it, I am listening.  So far the 
>>only thing I am hearing is you don't like it.
>>
>>    
>>
>>>George
>>>
>>>On Mon, 2006-03-27 at 20:57 -0600, Craig Franklin wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>George M. Gallant, Jr. wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Craig,
>>>>>
>>>>>I find 2 problems with the current scheme:
>>>>>
>>>>>  1. gpasm and gplink both produce xxx.lst files.
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>They also both generate .hex and .cod files.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>  2. gplink deletes the xxx.lst file even if it is not writing one
>>>>>itself.
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>gpasm deletes xxx.lst files even if it is not writing one too.
>>>>
>>>>Here is the problem with your scheme:  I compile my project with the 
>>>>list file enabled.  Then later suppress the list file output and keep 
>>>>building the project.  The list file won't match any of the current 
>>>>outputs.  This is confusing at a minimum.
>>>>
>>>>If you want to keep a file, whether it is a hex, cod, list,... rename it 
>>>>or move it.  Why do you want to keep a list file that doesn't match any 
>>>>of the other outputs?
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>George
>>>>>
>>>>>On Mon, 2006-03-27 at 19:52 -0600, Craig Franklin wrote:
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>The current behavior is to prevent old stale list files from being 
>>>>>>confused with current hex files.  All the gputils tools behave this way 
>>>>>>for all file types.
>>>>>>
>>>>>>Best thing to do is to rename your file.  This will also help prevent 
>>>>>>gputils from over writing your special list file.
>>>>>>
>>>>>>George M. Gallant, Jr. wrote:
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>I typically use the -l option to gplink to inhibit the creation of the
>>>>>>>composite .lst file.
>>>>>>>A side effect is gplink deletes the existing .lst file.  Moving the the
>>>>>>>code at approx 
>>>>>>>lines 267-268 264 makes seems to correct this behavior.
>>>>>>>
>>>>>>>New code:
>>>>>>>
>>>>>>>void write_lst(void) {
>>>>>>>gp_symbol_type *symbol = state.object->symbols;
>>>>>>>gp_aux_type *aux;
>>>>>>>gp_boolean first_time = true;
>>>>>>>
>>>>>>>if(!state.lst.enabled)
>>>>>>> return;
>>>>>>>
>>>>>>>lst_init();
>>>>>>>
>>>>>>>list_enabled = true;
>>>>>>>
>>>>>>>Thanks,
>>>>>>> George
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: ####@####.####
>>>>>>For additional commands, e-mail: ####@####.####
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: ####@####.####
>>>>For additional commands, e-mail: ####@####.####
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>> 
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ####@####.####
>>For additional commands, e-mail: ####@####.####
>>
>>    
>>
>
>  
>