[<<] [<] Page 1 of 2 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: Craig Franklin ####@####.#### Date: 28 Mar 2006 02:50:12 +0100 Message-Id: <442896ED.6020104@users.sourceforge.net> 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 > > > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: "George M. Gallant, Jr." ####@####.#### Date: 28 Mar 2006 03:21:15 +0100 Message-Id: <1143512400.12961.18.camel@scuba.home.net> 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: ####@####.#### > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: Craig Franklin ####@####.#### Date: 28 Mar 2006 03:52:48 +0100 Message-Id: <4428A631.9010406@users.sourceforge.net> 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: ####@####.#### >> >> >> > > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: "George M. Gallant, Jr." ####@####.#### Date: 28 Mar 2006 04:27:12 +0100 Message-Id: <1143516386.12961.23.camel@scuba.home.net> 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: ####@####.#### > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: Craig Franklin ####@####.#### Date: 28 Mar 2006 07:05:05 +0100 Message-Id: <4428D375.3010507@users.sourceforge.net> 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: ####@####.#### >> >> >> > > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: Chris Emerson ####@####.#### Date: 28 Mar 2006 07:48:15 +0100 Message-Id: <20060328064745.GA6660@ixion.tartarus.org> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: "Gabor Kiss [Bitman]" ####@####.#### Date: 28 Mar 2006 08:47:13 +0100 Message-Id: <Pine.LNX.4.63.0603280942510.5447@nelson.cdata.hu> >> 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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: "George M. Gallant, Jr." ####@####.#### Date: 28 Mar 2006 14:02:43 +0100 Message-Id: <1143550954.12961.62.camel@scuba.home.net> 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: ####@####.#### > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: Craig Franklin ####@####.#### Date: 30 Mar 2006 02:49:11 +0100 Message-Id: <442B3A81.6050008@users.sourceforge.net> 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: ####@####.#### > > > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [gnupic] gplink and .lst files
From: Craig Franklin ####@####.#### Date: 30 Mar 2006 03:29:55 +0100 Message-Id: <442B440D.1020101@users.sourceforge.net> 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: ####@####.#### >> >> >> > > > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 2 [>] [>>] |