From: Alan W. I. <ir...@be...> - 2004-04-27 16:06:16
|
On 2004-04-27 01:37+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-04-26 09:31]: > > > On 2004-04-26 08:32+0100 Andrew Ross wrote: > > > > > I have one more release goal. > > > > > > 4) Decide on examples for the new plvect functions. Adding language > > > bindings and examples for languages other than C / C++ / fortran. Alan > > > volunteered to help me with this some time ago. > > > > I think this is an important goal, and I am willing to help, but finding the > > time is a problem at the moment for me since I am trying to finish off two > > equation of state (EOS) research projects which are time-consuming of > > themselves and also involve the required PLplot change (5) below. > > Indeed, this sounds like an interesting goal. Could you please give an > estimate of time of completion? I cannot make any sort of estimate because my EOS research is open-ended (nobody has done it before), and it must have my highest priority. What I can say is when I have time again for PLplot, (5) will have the highest PLplot priority for me (because it is required to publish my EOS work) followed by (4). My advice to Andrew is to focus on getting a really good vector example done in one language of his choice before the release. Hopefully, he will be able to find (or somebody on this list can point him to) some textbook example function with an interesting vector field. If I don't have time to help (quite likely) with (4) before release, and Andrew runs out of time himself, then we can put off propagating that good example to the rest of our languages until after release when I will have a lot more time to help out. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-04-28 08:34:49
|
Here is my proposal for the schedule of the next release (will be 5.3.1, I see no reason for a 5.4.0 leap). For me, the feasible "launching window" is during June. Assuming that we will be releasing around the end of June, I will try to get a release candidate tarball around June 13. This will give enough time for at least two release cycles. If we need more release cycles, then I will be able to do the release work only later in July, or perhaps only after the Summer. If we stick to the above schedule, then we have roughly a month and a half between now and the time I will "freeze" CVS HEAD (or make a release branch, but I prefer not to do it). The five release goals that have been discussed so far are (in arbitrary order): * completion of perldl examples * gcw + plplotcanvas driver * build the info documentation using upstream docbook2x * examples for the new plvect functions * new API for plot3d and friends None of those is release critical, so if some of them are not complete by the time of release, then they will not make their way into the tarball. Period. These projects may even be in a intermediate stage for 5.3.1 (for instance, plvect examples only in two or three languages), but they should not result in broken code. At any rate, we have already accumulated enough improvements in CVS since 5.3.0 to justify a new release. What do you think? -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-04-28 08:55:51
|
Rafael Laboissiere wrote: > > > If we stick to the above schedule, then we have roughly a month and a half > between now and the time I will "freeze" CVS HEAD (or make a release branch, > but I prefer not to do it). The five release goals that have been discussed > so far are (in arbitrary order): > > * completion of perldl examples > * gcw + plplotcanvas driver > * build the info documentation using upstream docbook2x > * examples for the new plvect functions > * new API for plot3d and friends > > None of those is release critical, so if some of them are not complete by > the time of release, then they will not make their way into the tarball. > Period. These projects may even be in a intermediate stage for 5.3.1 (for > instance, plvect examples only in two or three languages), but they should > not result in broken code. > I would like to add one item: The changes I made to incorporate PLplot as a library in a larger program that has its own GUI. Most of these are very small, but as the PLStream structure is involved, they potentially affect a lot of stuff... Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-04-28 09:47:29
|
* Arjen Markus <arj...@wl...> [2004-04-28 10:55]: > I would like to add one item: > The changes I made to incorporate PLplot as a library in a larger > program that has its own GUI. As far as I remember, these changes are not yet in CVS, are they? > Most of these are very small, but as the PLStream structure is involved, > they potentially affect a lot of stuff... If the changes do not break HEAD, them this could be a possible release goal. However, I think that such changes in the library must be largely discussed in the mailing list and an appropriate design must be done before even implementing changes. Bad designs in the API are particularly harmful when they perpetuate. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-04-28 09:58:51
|
Rafael Laboissiere wrote: > > * Arjen Markus <arj...@wl...> [2004-04-28 10:55]: > > > I would like to add one item: > > The changes I made to incorporate PLplot as a library in a larger > > program that has its own GUI. > > As far as I remember, these changes are not yet in CVS, are they? No, not yet :) > > > Most of these are very small, but as the PLStream structure is involved, > > they potentially affect a lot of stuff... > > If the changes do not break HEAD, them this could be a possible release > goal. > > However, I think that such changes in the library must be largely discussed > in the mailing list and an appropriate design must be done before even > implementing changes. Bad designs in the API are particularly harmful when > they perpetuate. > Yes, I agree - one reason why I have not put them into CVS yet. My plan should be: - Describe them first on this list - After consent, add them to CVS Note, they concern mainly registering the connection to the GUI part and subsequent use in the screen drivers. The API is rather ad hoc at the moment - I had to get it all working ;) Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-04-28 10:30:17
|
* Arjen Markus <arj...@wl...> [2004-04-28 11:58]: > My plan should be: > - Describe them first on this list > - After consent, add them to CVS > > Note, they concern mainly registering the connection to the GUI part and > subsequent use in the screen drivers. The API is rather ad hoc at the > moment - I had to get it all working ;) You might create a CVS branch for this. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-05-03 09:13:25
|
Rafael Laboissiere wrote: > > * Arjen Markus <arj...@wl...> [2004-04-28 11:58]: > > > My plan should be: > > - Describe them first on this list > > - After consent, add them to CVS > > > > Note, they concern mainly registering the connection to the GUI part and > > subsequent use in the screen drivers. The API is rather ad hoc at the > > moment - I had to get it all working ;) > > You might create a CVS branch for this. > That seems a bit heavy to me. Let me describe what I had to do to make it work: - My application uses a GUI library for managing the windows and dialogues and it uses PLplot to draw graphs. To avoid having to redraw the graphs each time the window holding such a graph is uncovered, I use pixmaps instead of the window itself. - My application therefore needs to tell: - the X Window or MS Windows drivers that they do not create a window themselves - what the connection is to the X display or to the window. - what pixmap to use (the actual thing to draw in) - (in case of the Windows driver) that the device to draw in is a printer. - This led to a number of changes in the PLStream structure, some extra fields, in the device structures (ditto) and to additional logic in the code for these two drivers. - For the public API, I have introduced three small functions to set these fields. All in all, less than 100 lines are involved, though scattered over four different files. Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-05-03 15:05:53
|
* Arjen Markus <arj...@wl...> [2004-05-03 11:13]: > That seems a bit heavy to me. Let me describe what I had to do to make > it work: > > - My application uses a GUI library for managing the windows and > dialogues > and it uses PLplot to draw graphs. To avoid having to redraw the > graphs > each time the window holding such a graph is uncovered, I use pixmaps > instead of the window itself. > - My application therefore needs to tell: > - the X Window or MS Windows drivers that they do not create a window > themselves > - what the connection is to the X display or to the window. > - what pixmap to use (the actual thing to draw in) > - (in case of the Windows driver) that the device to draw in is a > printer. > - This led to a number of changes in the PLStream structure, some > extra fields, in the device structures (ditto) and to additional > logic in the code for these two drivers. > - For the public API, I have introduced three small functions to > set these fields. > > All in all, less than 100 lines are involved, though scattered over > four different files. Do your changes make the PLplot API backwards incompatible? -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-05-04 06:16:53
|
Rafael Laboissiere wrote: > > * Arjen Markus <arj...@wl...> [2004-05-03 11:13]: > > > That seems a bit heavy to me. Let me describe what I had to do to make > > it work: > > > > - My application uses a GUI library for managing the windows and > > dialogues > > and it uses PLplot to draw graphs. To avoid having to redraw the > > graphs > > each time the window holding such a graph is uncovered, I use pixmaps > > instead of the window itself. > > - My application therefore needs to tell: > > - the X Window or MS Windows drivers that they do not create a window > > themselves > > - what the connection is to the X display or to the window. > > - what pixmap to use (the actual thing to draw in) > > - (in case of the Windows driver) that the device to draw in is a > > printer. > > - This led to a number of changes in the PLStream structure, some > > extra fields, in the device structures (ditto) and to additional > > logic in the code for these two drivers. > > - For the public API, I have introduced three small functions to > > set these fields. > > > > All in all, less than 100 lines are involved, though scattered over > > four different files. > > Do your changes make the PLplot API backwards incompatible? > No, not at all, as existing functions are not touched. I merely introduced a few new ones. The only thing that could be bothersome is the additional few fields, that means the library would not be binary compatible - though even that is only important when a program uses the internals of the PLStream structure: if you recompile the PLplot library (make a new shared library), compatibility is guaranteed, isn't it? Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-05-04 09:17:26
|
* Arjen Markus <arj...@wl...> [2004-05-04 08:16]: > No, not at all, as existing functions are not touched. I merely > introduced a few new ones. The only thing that could be bothersome > is the additional few fields, that means the library would not be > binary compatible - though even that is only important when a > program uses the internals of the PLStream structure: if you recompile > the PLplot library (make a new shared library), compatibility is > guaranteed, isn't it? So, this means that your changes *_do_* make the PLplot library backwards incompatible. Since this is an important move, we need to discuss further about your improvements. Perhaps we could achieve a improved designed in relation to what you did. Also, as the Release Manager, I would also ask you to not commit your changes to HEAD until the next release. Could you please create a CVS branch and work on it please? This will give us a chance to appreciate your work. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-05-04 09:31:31
|
Rafael Laboissiere wrote: > > * Arjen Markus <arj...@wl...> [2004-05-04 08:16]: > > > No, not at all, as existing functions are not touched. I merely > > introduced a few new ones. The only thing that could be bothersome > > is the additional few fields, that means the library would not be > > binary compatible - though even that is only important when a > > program uses the internals of the PLStream structure: if you recompile > > the PLplot library (make a new shared library), compatibility is > > guaranteed, isn't it? > > So, this means that your changes *_do_* make the PLplot library backwards > incompatible. Since this is an important move, we need to discuss further > about your improvements. Perhaps we could achieve a improved designed in > relation to what you did. > > Also, as the Release Manager, I would also ask you to not commit your > changes to HEAD until the next release. Could you please create a CVS branch > and work on it please? This will give us a chance to appreciate your work. > Okay, I will do that, may need your help though, as I have never created a CVS branch before ... Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-05-04 13:37:57
|
* Arjen Markus <arj...@wl...> [2004-05-04 11:30]: > Okay, I will do that, may need your help though, as I have never created > a CVS branch before ... The CVS manual explains that very well. See the chapter named "Branching and merging". Creating a branch should not be more complicated than issuing the command: cvs tag -b name-of-the-branch In order to commit changes into the created branch, you need to "cvs update -r" first. It is really very simple, look at the manual. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-05-04 13:48:33
|
Rafael Laboissiere wrote: > > * Arjen Markus <arj...@wl...> [2004-05-04 11:30]: > > > Okay, I will do that, may need your help though, as I have never created > > a CVS branch before ... > > The CVS manual explains that very well. See the chapter named "Branching > and merging". Creating a branch should not be more complicated than > issuing the command: > > cvs tag -b name-of-the-branch > > In order to commit changes into the created branch, you need to "cvs update > -r" first. It is really very simple, look at the manual. > It must be "cold-water fear" then ... :) Regards, Arjen |
From: Andrew R. <and...@us...> - 2004-05-04 09:37:05
|
On Tue, May 04, 2004 at 11:16:37AM +0200, Rafael Laboissiere wrote: > * Arjen Markus <arj...@wl...> [2004-05-04 08:16]: > > > No, not at all, as existing functions are not touched. I merely > > introduced a few new ones. The only thing that could be bothersome > > is the additional few fields, that means the library would not be > > binary compatible - though even that is only important when a > > program uses the internals of the PLStream structure: if you recompile > > the PLplot library (make a new shared library), compatibility is > > guaranteed, isn't it? > > So, this means that your changes *_do_* make the PLplot library backwards > incompatible. Since this is an important move, we need to discuss further > about your improvements. Perhaps we could achieve a improved designed in > relation to what you did. > > Also, as the Release Manager, I would also ask you to not commit your > changes to HEAD until the next release. Could you please create a CVS branch > and work on it please? This will give us a chance to appreciate your work. We did discuss changes like this some time ago. _Nobody_ should be using the internal PLStream structures. None of the API functions require it. Since this is internals of the library then anyone who does try to use it should expect changes. I believe there have been some changes fairly recently to the plstream structure and nobody complained about it breaking anything. Maybe we should be more explicit that we make no guarantees about the PLStream structure. It seems to me that we are unecessarily hampering ourselves otherwise. Correct me if I'm wrong. Of course, as release manager, it's your call Rafael. Andrew |
From: Rafael L. <rla...@us...> - 2004-05-04 13:30:53
|
* Andrew Ross <and...@us...> [2004-05-04 10:36]: > We did discuss changes like this some time ago. _Nobody_ should be using the > internal PLStream structures. None of the API functions require it. Since > this is internals of the library then anyone who does try to use it > should expect changes. I believe there have been some changes fairly > recently to the plstream structure and nobody complained about it > breaking anything. Maybe we should be more explicit that we make no > guarantees about the PLStream structure. It seems to me that we are > unecessarily hampering ourselves otherwise. > > Correct me if I'm wrong. This is my recollection, too. > Of course, as release manager, it's your call Rafael. I cannot really judge before seeing Arjen's changes, though. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-05-04 13:38:55
|
Rafael Laboissiere wrote: > > * Andrew Ross <and...@us...> [2004-05-04 10:36]: > > > We did discuss changes like this some time ago. _Nobody_ should be using the > > internal PLStream structures. None of the API functions require it. Since > > this is internals of the library then anyone who does try to use it > > should expect changes. I believe there have been some changes fairly > > recently to the plstream structure and nobody complained about it > > breaking anything. Maybe we should be more explicit that we make no > > guarantees about the PLStream structure. It seems to me that we are > > unecessarily hampering ourselves otherwise. > > > > Correct me if I'm wrong. > > This is my recollection, too. > > > Of course, as release manager, it's your call Rafael. > > I cannot really judge before seeing Arjen's changes, though. > > Would it help if I posted the differences, either via the mailing list or in a private email? Regards, Arjen |
From: <jc...@fe...> - 2004-05-04 15:42:51
|
On Monday 03 May 2004 10:13, Arjen Markus wrote: | Rafael Laboissiere wrote: | > * Arjen Markus <arj...@wl...> [2004-04-28 11:58]: | > > My plan should be: | > > - Describe them first on this list | > > - After consent, add them to CVS | > > | > > Note, they concern mainly registering the connection to the GUI | > > part and subsequent use in the screen drivers. The API is rather | > > ad hoc at the moment - I had to get it all working ;) | > | > You might create a CVS branch for this. | | That seems a bit heavy to me. Let me describe what I had to do to | make it work: | | - My application uses a GUI library for managing the windows and | dialogues | and it uses PLplot to draw graphs. To avoid having to redraw the | graphs | each time the window holding such a graph is uncovered, I use | pixmaps instead of the window itself. | - My application therefore needs to tell: | - the X Window or MS Windows drivers that they do not create a | window themselves Hi, There exists an entry for that in PLplot, plcore.c:plsxwin(): using it before calling plinit() makes plplot render its graph in the supplied window. E.g., if I add plsxwin(0xe00003); before plinit() in x01c.c, where 0xe00003 is the window id of a window that I created with tk, then x01c will be ploted in that window. [jcard@feup] wish % winfo id . 0xe00003 % | - what the connection is to the X display or to the window. | - what pixmap to use (the actual thing to draw in) the xwin driver already uses a pixmap; it is used to redraw the plot when the window becomes un-obscured. When a resize occurs, the plot buffer is reploted, (xwin.c calls plRemakePlot(), which is in src/plbuff.c --- src/plcore also calls it). There is no need to re-issue the plot commands. | - (in case of the Windows driver) that the device to draw in is a | printer. | - This led to a number of changes in the PLStream structure, some | extra fields, in the device structures (ditto) and to additional | logic in the code for these two drivers. | - For the public API, I have introduced three small functions to | set these fields. | | All in all, less than 100 lines are involved, though scattered over | four different files. I don't know the windows driver, but shouldn't your changes be applied to the driver, instead of the core routines? Does this help? Joao | | Regards, | | Arjen | | | | ------------------------------------------------------- | This SF.Net email is sponsored by: Oracle 10g | Get certified on the hottest thing ever to hit the market... Oracle | 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. | http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <arj...@wl...> - 2004-05-05 06:24:45
|
Jo=E3o Cardoso wrote: >=20 >=20 > Hi, >=20 > There exists an entry for that in PLplot, plcore.c:plsxwin(): >=20 > using it before calling plinit() makes plplot render its graph in the > supplied window. > E.g., if I add plsxwin(0xe00003); before plinit() in x01c.c, where > 0xe00003 is the window id of a window that I created with tk, then x01c > will be ploted in that window. >=20 Actually, I am using that function too, with a patch for Windows. But I needed to set the connection and the pixmap (because I need control over it - I did not want to change too much in my application and this stuff is rather "hairy"). It may be very peculiar to my app, I do not know, but I did find out that things were not quite working as expected. > | - what the connection is to the X display or to the window. > | - what pixmap to use (the actual thing to draw in) >=20 > the xwin driver already uses a pixmap; it is used to redraw the plot > when the window becomes un-obscured. When a resize occurs, the plot > buffer is reploted, (xwin.c calls plRemakePlot(), which is in > src/plbuff.c --- src/plcore also calls it). There is no need to > re-issue the plot commands. Yes, but this presumes that PLplot receives the X events directly. This is not the case in my program: the GUI library handles them all. >=20 > I don't know the windows driver, but shouldn't your changes be applied > to the driver, instead of the core routines? >=20 That would mean direct access to the driver - my little additional functions simply make this transparent to the program (the extra fields are only used to pass the information on at the appropriate time). Note: I made these changes when I was still learning about PLplot.=20 I may need to rethink them ... :) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-05-06 13:01:42
|
Hello, I would like to know if there is a (simple) way to find out if a particular device is available? The reason: I can print my pictures to various output formats, but if the required device is not present the program will stop with an error. I would like to offer an alternative to my users, as this concerns an interactive program that allows them to do all manner of things, among which printing to a file. The function plgdev() returns the current device, that is not what I want. I want something like: if ( plhasdev( "png" ) ) { plsdev( "png" ) ; } else { plsdev( "psc" ) ; /* Or the like */ } Any suggestions? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-05-06 13:38:23
|
Hello, I just did a small experiment with the PNG driver, and it gave me a picture that resembles the oddities I have had with the Windows win3 driver. Does anybody use that driver? Is it being maintained? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-05-06 13:49:55
|
Arjen Markus wrote: > > Hello, > > I just did a small experiment with the PNG driver, and it gave me > a picture that resembles the oddities I have had with the Windows > win3 driver. > > Does anybody use that driver? Is it being maintained? > > Regards, > > Arjen > FIY the examples seem to work fine, but they use a different aspect ratio than my program does. This was a particular problem with the win3 driver too. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-05-06 15:33:32
|
On 2004-05-06 15:49+0200 Arjen Markus wrote: > Arjen Markus wrote: > > > > Hello, > > > > I just did a small experiment with the PNG driver, and it gave me > > a picture that resembles the oddities I have had with the Windows > > win3 driver. > > > > Does anybody use that driver? Is it being maintained? If you are referring to the Unix/Linux png driver, then the answers are Yes and Yes. :-) (If memory serves there is also an additional png driver that Andrew Roach is maintaining for the dos/djgpp platform, but I don't think you have access to that platform.) > > FIY the examples seem to work fine, but they use a different > aspect ratio than my program does. This was a particular > problem with the win3 driver too. Arjen, we need specifics. Otherwise, there is nothing we can do and nothing we can discuss. So please give us a simple programme example (or combination of options for a standard example) which demonstrates the png device problem you have found so we can replicate the problem for ourselves. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2004-05-07 05:39:26
|
> > > Does anybody use that driver? Is it being maintained? > >If you are referring to the Unix/Linux png driver, then the answers are Yes >and Yes. :-) (If memory serves there is also an additional png driver that >Andrew Roach is maintaining for the dos/djgpp platform, but I don't think >you have access to that platform.) It's same PNG driver under DOS/DJGPP. The DOS/DJGPP version has it's own TIF and JPG drivers that are separate from the rest of plplot (there is nothing in common with the "other" GD-based JPEG driver). These extra drivers are basically subsets of the DOS/DJGPP screen driver. -Andrew |
From: Arjen M. <arj...@wl...> - 2004-05-07 11:26:32
|
Hello, now that I have written an additional chapter for PLplot's documentation, I started wondering about a few other aspects of the documentation: 1. There are two rather empty but potentially interesting chapters, chapters 4 and 5. They seem meant to describe the various drivers in more detail. Is anybody working on them? Is there any interest to have these chapters written? I do not mean to criticise the situation, but it seems a shame to have these empty chapters in the documentation - if only for cosmetic reasons. 2. The description of several individual functions is rather sketchy. Take for instance plspage. It has six arguments, but from the description of these arguments it is not clear that the first two deal with the resolution: xp (PLFLT, input) Number of pixels, x For the others, the unit is not at all clear: xleng (PLINT, input) Page length, x Again, I quite understand the difficulty of keeping the documentation in good shape, but I think there is a lot to be gained here. Any volunteers? Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-05-07 12:33:34
|
* Arjen Markus <arj...@wl...> [2004-05-07 13:26]: > now that I have written an additional chapter for PLplot's > documentation, > I started wondering about a few other aspects of the documentation: > > 1. There are two rather empty but potentially interesting chapters, > chapters 4 and 5. They seem meant to describe the various drivers > in more detail. > Is anybody working on them? Is there any interest to have these > chapters written? > I do not mean to criticise the situation, but it seems a shame > to have these empty chapters in the documentation - if only > for cosmetic reasons. > > 2. The description of several individual functions is rather > sketchy. Take for instance plspage. It has six arguments, > but from the description of these arguments it is not > clear that the first two deal with the resolution: > > xp (PLFLT, input) > Number of pixels, x > > For the others, the unit is not at all clear: > > xleng (PLINT, input) > Page length, x > > Again, I quite understand the difficulty of keeping the > documentation in good shape, but I think there is a lot > to be gained here. Any volunteers? You, for instance? :-) The DocBook-XML sources of the documentation are under CVS control, so that any PLplot developer can make improvements to the manual. Just go ahead, please. -- Rafael |