Re: [Plplot-devel] Example status
On Thu, Jan 08, 2009 at 08:52:21AM +0100, Werner Smekal wrote: > Hi Andrew, > > > > I woke up this morning and realised the cause of this. Currently > > test_octave.sh runs all the tests from a single octave process. I > > suspect this is the cause since plrandd is now used in 2 examples (17 > > and 21) and so example 21 will give different results now since the > > random number generator will already have been called in example 17. > > This sounds reasonable, since the corresponding variables are static. > Just call > > plseed(5489) > > in the octave examples before plrandd(), this will set the random > number generator to the default seed. No need to do this for the other > bindings as long as a new process is started for every example. Thank's Werner. I'd actually delved into the code for the magic value anyway. I have included this in all the other implementations of example 21 since plseed is not tested anywhere else. This showed up bugs in the f77 and f95 bindings to plseed which I have also fixed. I've also documented plrandd and plseed in api.xml. They were currently missing, which was how they had got missed off when I checked the api coverage in the examples recently. I should probably go back to plplot.h to ensure the documentation is complete. Andrew -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Example status
On Thu, Jan 08, 2009 at 08:37:36AM +0100, Arjen Markus wrote: > > tcl > >Missing examples: 17 19 > >Differing postscript output : > >Missing stdout : > >Differing stdout: > > > > The API exercised by example 19 is not straightforward to implement, but > > it's been done for Fortran (both f77 and f95) so hopefully somebody will > > take up this challenge for java, octave, and python. My understanding is > > that Arjen is working on this issue for Tcl. > > > > 17 is missing for Tcl and OCaml, but it should be less of a challenge than > > implementing the API for 19. My understanding is that Hez is working on > > OCaml example 17. > > > > I was surprised to see example 17 missing yesterday. But then I started > to convert the C code into Tcl and I noticed that the plstrip* functions > are not available within the Tcl bindings. So it is not just a matter > of missing example code. > > With the exception of one new type of data, adding the interface will > not be problematic. Arjen, That's great - thanks. > I am ignoring the plsError() function in the C code - certainly for the > moment. There is a way to implement it (via Tcl_LinkVar()), but I do not > think it is worth the effort right now. Several other languages ignore the plsError function in example 17. This is not strictly part of the common api anyway. > I will implement example 19, as I have thought of a convenient way > to do it. That would also be great. I think it should be possible to call java functions from C, but I need (at least) a few hours working out how to do it with swig and the jni. That leaves octave and python. Octave should also be possible, if messy, but will also require some learning on my part. Andrew -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Example status
On Thu, Jan 08, 2009 at 02:54:35PM +, Andrew Ross wrote: > > Thank's Werner. I'd actually delved into the code for the magic value > anyway. I have included this in all the other implementations of example > 21 since plseed is not tested anywhere else. This showed up bugs in the > f77 and f95 bindings to plseed which I have also fixed. I've also > documented plrandd and plseed in api.xml. They were currently missing, > which was how they had got missed off when I checked the api coverage in > the examples recently. I should probably go back to plplot.h to ensure > the documentation is complete. I've been back and cross checked with plplot.h. The only common API functions missing from docs and examples are plhls, plrgb and plrgb1 which are depreciated according to the source. I've now marked these as such in plplot.h. The only two others missing are plot3dcl and plsurf3dl. These are closely related to plot3dc and plsurf3d so usage should be clear. Andrew -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] My recent Ada changes
On Jan 6, 2009, at 1:03 AM, Alan W. Irwin wrote: > Hi Jerry: > > I noticed some garbage after the device name for the Ada thick and > thin > example 31 results in stderr. Thanks for catching that--I don't know where my stderr output goes. Or more likely, this line was not executed when I ran the example. > In contrast to this less-than-ideal result > for plgfnam, plgver produces good looking results for Ada thick and > thin > example 1 library version. There plgver is called using the > functional form > without arguments so I tried to do the same for plgfnam and it > didn't work. > > IMO, plgdev, plgfnam, and plgver (and their thick versions) should all > be implemented identically in the bindings since they all produce > strings. Accordingly I have made some Ada bindings changes as > of revision 9259. > > Note, there was no way I could get the procedure version of plgfnam > to work > with the To_Ada second argument True, so I uniformly set that to > False for > all procedure versions of plgdev, plgver, and corresponding thick > versions > in analogy with the existing plgfnam procedural version. Unless > the analogy > is wrong for some unknown reason this should be the right thing to > do, but > note we do not test the procedural versions of anything but plgfnam > so these > API changes are untested by any of our tests. Setting the second parameter in To_Ada (full name is Interefaces.C.To_Ada, FWTW) to False should be best, as you found. Ada String (one of three string types in Ada) is an array of Character (char) that is _not_ terminated by null. (Null is not needed in Ada since the length of the array is known.) In the case of e.g. plgfnam, the String PL_Output_File_Name is declared to be an array of length 80, 0..79. As I understand it, the call to C (PLplot_Thin.plgfnam) will fill up that array with 80 characters beginning from 0 offset, one of which is null. To_Ada converts that to an Ada String that is manufactured on the spot to be exactly the right length; if the second argument to To_Ada is True, a null character is appended; if False, no null character is appended. Thus, the length of the Ada string will vary by 1 depending on whether the second argument is True or False. > > I also changed the Ada 31st examples to use the new function > version of > plgfnam (and its thick counterpart) when outputting results to > stderr, and > it no longer has garbage after the output name. I can see where the garbage came from--fnam is an 80-character string and Ada appended all 80 characters to the argument in Put_Line. It put out not only the null character but everything after that, all 80 characters. > > Thus, everything seems to be working correctly with my changes with no > garbage output results for examples 31. However, I am programming > by analogy > here with no deep understanding of what I am doing so will you > please review > my changes? Your changes look good. The only thing I see odd is that the new function version of plgfnam has To_Ada(blabla, True) and I think you want that to be False, like the other instances. > > N.B. I am pretty sure you could stick strictly with the procedural > form of > plgfnam (and thick counterpart) in Ada examples 31 if you used some > string-trimming function to get rid of the trailing garbage for the > filename > output to stderr. However, please do not do that since I think the > current > implementation in Ada examples 31 is a better way to go since it > exercises > both the procedural and functional forms of plgfnam while also > getting rid of the trailing garbage in stderr. Yes--that string-trimming function is performed by To_Ada, as I described above. Example 31 could have been repaired like this: Put_Line(Standard_Error, "Output file name is " & To_Ada(fnam, False); but, as you say, that is an inconsistent use between these three string-returning functions/procedures. FWIW, I wrote a little Ada program that outputs a string with a null character at the end. When it went to the terminal, the null character was suppressed but when I redirected the output to a text file, the null character was present. Maybe this is a Unix thing. > > Alan > __ > Alan W. Irwin > > > On 2009-01-06 00:03-0800 Alan W. Irwin wrote: > > >> >> N.B. I am pretty sure you could stick strictly with the procedural >> form of >> plgfnam (and thick counterpart) in Ada examples 31 if you used some >> string-trimming function to get rid of the trailing garbage for >> the filename >> output to stderr. However, please do not do that since I think >> the current >> implementation in Ada examples 31 is a better way to go since it >> exercises >> both the procedural and functional forms of plgfnam while also >> getting rid of the trailing garbage in stderr. >> > > Hi Jerry: > > I woke up this morning with a different conclusion on this matter. > There is > no need
[Plplot-devel] Ada and plscmap1l
Jerry, While adapting example 12 to use plcol1 and plscmap1l I came across one interesting issue with ada. Several example use something like A_Boolean : Boolean_Array_1D(1 .. 1); A_Boolean(1) := False; plscmap1l(HLS, i, h, l, s, A_Boolean); Note that in these cases the h, l, s arrays are only of length 2. This works for these examples, but when I try for example 12 with colour arrays of length 5 then it doesn't work. I assume this is trying to emulate the C usage of NULL for the array pointer to signal no colours are reversed. Explicitly defining an array of length 5 and willing with False values works as expected. With f77 I found some errors in the examples where a value of 0 was passed for this purpose. Because f77 passes all arguments by reference this actually got interpreted as an array of length 5 with the first value 0. Obviously the subsequent values were undefined. I wonder if something similar is happening in Ada? Perhaps you could explain? Use of valgrind shows use of uninitialised values in the case which doesn't work, but only when the array length is > 2. This suggests my diagnosis might be correct. Can you think of a way of fixing this so a NULL value equivalent works, or if not, then correct the examples? Thanks Andrew -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
