pure-lang-users Mailing List for Pure (Page 6)
Status: Beta
Brought to you by:
agraef
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
(31) |
May
(422) |
Jun
(241) |
Jul
(268) |
Aug
(281) |
Sep
(109) |
Oct
(1) |
Nov
|
Dec
|
---|
From: Albert G. <Dr....@t-...> - 2008-08-30 15:39:20
|
Eddie Rucker wrote: > 1. ? That might be a C speciality, I'm pretty sure that this is neither Pascal nor Algol syntax. (Pure also allows this, but only if followed by a scale factor, as in 1.e-7.) But .5 has been supported by every programming language that I remember right now (except Lisp), back to the venerable Algol 60, so there must be some reason for that. At least Pure is in good company there. Just for the record, Haskell allows neither .5 nor 5., even if followed by a scale factor. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: John C. <co...@cc...> - 2008-08-30 14:40:59
|
Eddie Rucker scripsit: > I think this thing must have started with business folk or education > folk. All the Mathematicians, Engineers, and Scientists I know frown on > this sort of thing. I suspect that ".5" got started in Fortran on the IBM keypunch machines, where typing "0" was not only extra physical work just to push down the key, but made it that much more likely that you'd run off the end of the card. -- John Cowan http://ccil.org/~cowan co...@cc... 'My young friend, if you do not now, immediately and instantly, pull as hard as ever you can, it is my opinion that your acquaintance in the large-pattern leather ulster' (and by this he meant the Crocodile) 'will jerk you into yonder limpid stream before you can say Jack Robinson.' --the Bi-Coloured-Python-Rock-Snake |
From: Eddie R. <er...@bm...> - 2008-08-30 04:16:16
|
On Sat, 2008-08-30 at 01:43 +0200, Albert Graef wrote: > John Cowan wrote: > > Supporting those is silly. a*.5? No, no. a*0.5 is far more readable. > > Just change the definition of a float. > > In good ol' Europe we never write .5, I guess it's a US thing. But it's > supported in most programming languages, and it doesn't do any harm in > the Pure syntax. Conversely, 1. is forbidden, to avoid issues with the > .. operator. 1. ? #include <stdio.h> int main(void) { printf("%g\n", 3. * 0.2); return 0; } $ a.out 0.6 I guess you're right. That's weird. e.r. |
From: Eddie R. <er...@bm...> - 2008-08-30 04:06:22
|
On Sat, 2008-08-30 at 01:43 +0200, Albert Graef wrote: > John Cowan wrote: > > Supporting those is silly. a*.5? No, no. a*0.5 is far more readable. > > Just change the definition of a float. > > In good ol' Europe we never write .5, I guess it's a US thing. But it's > supported in most programming languages, and it doesn't do any harm in > the Pure syntax. Conversely, 1. is forbidden, to avoid issues with the > .. operator. I think this thing must have started with business folk or education folk. All the Mathematicians, Engineers, and Scientists I know frown on this sort of thing. e.r. |
From: Eddie R. <er...@bm...> - 2008-08-30 03:59:20
|
On Sat, 2008-08-30 at 01:38 +0200, Albert Graef wrote: > Eddie Rucker wrote: > > We have Labor Day holiday this Monday so I guess it's time to get on the > > roof and fix those shingles. I hate heights! > > Me too. Good luck with that, don't stumble! And a nice weekend and holiday! Thanks! I have to append some boards on top of a latter and hang the latter over the roof top and climb down. The roof pitch is 45 degrees on the side with the missing shingles. Not my cup of tea :( Have a good weekend too. e.r. |
From: Eddie R. <er...@bm...> - 2008-08-30 03:56:47
|
On Fri, 2008-08-29 at 19:31 -0400, John Cowan wrote: > Albert Graef scripsit: > > > The following regex should properly describe Pure numbers, except for > > the case of a floating point number starting with a decimal point. > > Supporting those is silly. a*.5? No, no. a*0.5 is far more readable. > Just change the definition of a float. I agree absolutely! I had a Chemistry Professor that used to get red hot if students wrote numbers with a leading decimal point. Unfortunately some of the elementary statistics books I've had to use write numbers that way. It looks like they would know better? It makes it hard to get across to students not to write numbers when some of the books write them that way. Try writing on a pucked chalk board without a leading 0 ;-) e.r. |
From: Albert G. <Dr....@t-...> - 2008-08-29 23:41:17
|
John Cowan wrote: > Supporting those is silly. a*.5? No, no. a*0.5 is far more readable. > Just change the definition of a float. In good ol' Europe we never write .5, I guess it's a US thing. But it's supported in most programming languages, and it doesn't do any harm in the Pure syntax. Conversely, 1. is forbidden, to avoid issues with the .. operator. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: Albert G. <Dr....@t-...> - 2008-08-29 23:36:59
|
Eddie Rucker wrote: > We have Labor Day holiday this Monday so I guess it's time to get on the > roof and fix those shingles. I hate heights! Me too. Good luck with that, don't stumble! And a nice weekend and holiday! Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: John C. <co...@cc...> - 2008-08-29 23:31:26
|
Albert Graef scripsit: > The following regex should properly describe Pure numbers, except for > the case of a floating point number starting with a decimal point. Supporting those is silly. a*.5? No, no. a*0.5 is far more readable. Just change the definition of a float. -- What is the sound of Perl? Is it not the John Cowan sound of a [Ww]all that people have stopped co...@cc... banging their head against? --Larry http://www.ccil.org/~cowan |
From: Eddie R. <er...@bm...> - 2008-08-29 23:14:21
|
On Sat, 2008-08-30 at 00:55 +0200, Albert Graef wrote: > Thanks a bunch. It's in svn now. I added some remarks on usage to the > top of the file, maybe you want to review and correct these. I also had Your welcome. Looks good to me. > The following regex should properly describe Pure numbers, except for > the case of a floating point number starting with a decimal point. That > doesn't seem to be possible without breaking '..', since those > highlighting engines don't seem to support left context; at least I > couldn't figure it out. I played with this a while but finally gave up because fixing one case breaks another. A space between a number and .. highlights fine. Although irritating, It isn't worth the time. We have Labor Day holiday this Monday so I guess it's time to get on the roof and fix those shingles. I hate heights! Have a good weekend! e.r. |
From: Albert G. <Dr....@t-...> - 2008-08-29 23:07:17
|
Eddie Rucker wrote: > Would you be offended if I tried to port your Q ODBC module to Pure? Hell, no! :) I'd appreciate that very much. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: Albert G. <Dr....@t-...> - 2008-08-29 22:54:01
|
Eddie Rucker wrote: > On Fri, 2008-08-29 at 05:55 -0500, Eddie Rucker wrote: >> On Thu 28/08/08 6:15 PM , Albert Graef Dr....@t-... sent: >>> Cool. Mind you, there's a typo in that file: s/othrwise/otherwise/. > > Fixed. Thanks a bunch. It's in svn now. I added some remarks on usage to the top of the file, maybe you want to review and correct these. I also had to rename the file to gpure.lang, since there's already another pure.lang file for Simon's hightlight program. (That's the program I use to beautify the examples on the Pure website. Unfortunately, that program doesn't like it if the language definition file is named differently; Gedit doesn't seem to have a problem with that. Boy I hate it when programs like these use generic filename extensions like .lang or .xml, Kate is no better either.) > I noticed gedit doesn't highlight an int index when I have something > like (0..4). Kate doesn't handle it properly either (it highlights the > ".") 0. is in Kate's floating point rules and I haven't fixed rules at > all for this in gedit. I haven't figured out how to just highlight the 0 > without also highlighting the .. The following regex should properly describe Pure numbers, except for the case of a floating point number starting with a decimal point. That doesn't seem to be possible without breaking '..', since those highlighting engines don't seem to support left context; at least I couldn't figure it out. 0[xX][0-9a-fA-F]+L?|\d+L?|\d+(\.\d+)?([eE][\-\+]?\d+)?|\d+(\.\d*)?[eE][\-\+]?\d+ Unfortunately, that regex makes Kate go bonkers, don't know why, so I stick with Kate's predefined Int/Float highlighting rules for now. Maybe you have more luck with that. :) Thanks again for that gedit highlighting. I guess we support the most important non-Windows editors now. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: Eddie R. <er...@bm...> - 2008-08-29 20:57:31
|
On Fri, 2008-08-29 at 22:43 +0200, Albert Graef wrote: > To avoid having Pure depend on GSL, I can hopefully just replicate the > memory allocation and view functionality from GSL and massage them for > my needs (I probably need to add a reference counter to the gsl_matrix > and vector structs in order to support contiguous slices in an efficient > way). I'll also expose the interface to the Pure matrix and vector data > in the public runtime API, so that you have easy access to it from C, too. > > I still have some other stuff on my TODO list right now (specifically, I > want to add a basic stream implementation a la SICP to the library), but > I can hopefully start working on the vector/matrix stuff some time next > week. > > > I think that maybe some of the primitive operations like addition, > > subtraction, multiplication, and a reciprocal function might be handled > > best internally in Pure though. Before you say no too quickly, let me > > point out that GSL_BLAS has a bunch of steps involved just to multiply > > two matrices. > > If we want to replicate this kind of functionality, it can be done just > as well in the Pure GSL wrapper. I really think that all linear algebra > functionality belongs there, so that we have a clear cut between the > interpreter's basic matrix/vector container support and the GSL > wrapper's more advanced functionality. Otherwise we'll just end up > duplicating stuff. > > So in the Pure vector/matrix support, I want to concentrate on the basic > container functionality, including efficient element access and slicing. > Pure programmers will then be able to do basic vector/matrix stuff using > these operations and the array comprehensions, or they can fire up the > GSL wrapper once it's available, to do more advanced stuff and take > advantage of the speedy C implementation. All sounds good to me. While you work toward that end, I'm going to go a head and wrap the statistical distribution functions. I need those for work. Would you be offended if I tried to port your Q ODBC module to Pure? e.r. |
From: Albert G. <Dr....@t-...> - 2008-08-29 20:41:28
|
Eddie Rucker wrote: > Using the method GSL uses internally for vectors and matrices seems > reasonable and would probably allow for fast routines and make it easy > for interfacing to other libraries and/or hardware. To avoid having Pure depend on GSL, I can hopefully just replicate the memory allocation and view functionality from GSL and massage them for my needs (I probably need to add a reference counter to the gsl_matrix and vector structs in order to support contiguous slices in an efficient way). I'll also expose the interface to the Pure matrix and vector data in the public runtime API, so that you have easy access to it from C, too. I still have some other stuff on my TODO list right now (specifically, I want to add a basic stream implementation a la SICP to the library), but I can hopefully start working on the vector/matrix stuff some time next week. > I think that maybe some of the primitive operations like addition, > subtraction, multiplication, and a reciprocal function might be handled > best internally in Pure though. Before you say no too quickly, let me > point out that GSL_BLAS has a bunch of steps involved just to multiply > two matrices. If we want to replicate this kind of functionality, it can be done just as well in the Pure GSL wrapper. I really think that all linear algebra functionality belongs there, so that we have a clear cut between the interpreter's basic matrix/vector container support and the GSL wrapper's more advanced functionality. Otherwise we'll just end up duplicating stuff. So in the Pure vector/matrix support, I want to concentrate on the basic container functionality, including efficient element access and slicing. Pure programmers will then be able to do basic vector/matrix stuff using these operations and the array comprehensions, or they can fire up the GSL wrapper once it's available, to do more advanced stuff and take advantage of the speedy C implementation. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: Eddie R. <er...@bm...> - 2008-08-29 14:14:45
|
On Fri, 2008-08-29 at 02:26 +0200, Albert Graef wrote: > Yes, I see. So it's just a blob with dimensions and stride attached to > it. Well, I could easily generate data compatible with that in Pure, > along with the usual access operations and support in the runtime. > Memory management would be provided by Pure. > > I could then add the necessary marshalling so that these thingies could > be passed either as is to GSL, or the underlying gsl_block to the BLAS > routines, or just the pointer to the blob to int*, double* etc., so that > they could be used with graphics and audio software just as easily. > > Of course we need to fix a syntax for those arrays. I'd suggest the > following: {x1,x2,...} is a vector (compatible with gsl_vector struct > layout), {x11,x12,...; x21,x22,...; ...} is a matrix (compatible with > gsl_matrix struct layout). > > Elements would be either integers or doubles, promoting all ints to > double in the mixed case. We can think about complex numbers later. > Using some macro hackery, it should also be possible to provide some > kind of array comprehensions. I still have to think about this. > > Does that proposal sound reasonable? Using the method GSL uses internally for vectors and matrices seems reasonable and would probably allow for fast routines and make it easy for interfacing to other libraries and/or hardware. I think that maybe some of the primitive operations like addition, subtraction, multiplication, and a reciprocal function might be handled best internally in Pure though. Before you say no too quickly, let me point out that GSL_BLAS has a bunch of steps involved just to multiply two matrices. There is a routine to directly add two matrices but not for multiplication. For example to multiply to matrices with double entries, I have to use the following procedure (there is a more sophisticated version that deals with order (row major vs column major order like in FORTRAN) and some other things. int gsl_blas_dgemm (CBLAS_TRANSPOSE_t TransA, CBLAS_TRANSPOSE_t TransB, double alpha, const gsl_matrix * A, const gsl_matrix * B, double beta, gsl_matrix * C) Thus, the matrix operation follows C = alpha*A*B + beta*C; TransA and TransB have to be set to CblasNoTrans for regular multiplication, other choices are CblasTrans and CblasConjTrans. e.r. |
From: Eddie R. <er...@bm...> - 2008-08-29 13:19:46
|
On Fri, 2008-08-29 at 05:55 -0500, Eddie Rucker wrote: > On Thu 28/08/08 6:15 PM , Albert Graef Dr....@t-... sent: > > Cool. Mind you, there's a typo in that file: s/othrwise/otherwise/. Fixed. I also did some modifications to handle numbers better. I noticed gedit doesn't highlight an int index when I have something like (0..4). Kate doesn't handle it properly either (it highlights the ".") 0. is in Kate's floating point rules and I haven't fixed rules at all for this in gedit. I haven't figured out how to just highlight the 0 without also highlighting the .. I think I'll just leave it alone for right now as my work plate for today is full. e.r. |
From: Eddie R. <er...@bm...> - 2008-08-29 11:23:26
|
On Thu 28/08/08 6:15 PM , Albert Graef Dr....@t-... sent: > Eddie Rucker wrote: > > This is the beginnings of a keyword highlight > file for gedit. I think> Libor wanted one of these? > > Cool. Mind you, there's a typo in that file: s/othrwise/otherwise/. I'll get that fixed when I get to work. > Does gedit support folding? I think that's one of the coolest features > of Kate's Pure highlighting. I can't get to their main site www.gnome.org/projects/gedit/ to verify, but I don't think it does. > > I ripped it off from Marco Barision > and> Emanuela Aina's Ada highlight package and made > the modifications for> pure. Is this legal? > > Well you gave them credit, and I don't think that anyone in their right > mind would want to claim copyright in a silly little list of keywords. I get nervous when it comes to copyright, trademark, and other legal matters. > I suppose that you don't mind if I include this in the Pure > distribution? Let me add in their blurb at the top of the syntax file and sure, do whatever you want with it. e.r. |
From: Albert G. <Dr....@t-...> - 2008-08-29 00:24:41
|
Eddie Rucker wrote: > It has functions for initializing to zero, idenity, or all the entries the same value. However, since the data is laid out as an > array of doubles, ints for gsl_matrix_int, (you get the picture) Yes, I see. So it's just a blob with dimensions and stride attached to it. Well, I could easily generate data compatible with that in Pure, along with the usual access operations and support in the runtime. Memory management would be provided by Pure. I could then add the necessary marshalling so that these thingies could be passed either as is to GSL, or the underlying gsl_block to the BLAS routines, or just the pointer to the blob to int*, double* etc., so that they could be used with graphics and audio software just as easily. Of course we need to fix a syntax for those arrays. I'd suggest the following: {x1,x2,...} is a vector (compatible with gsl_vector struct layout), {x11,x12,...; x21,x22,...; ...} is a matrix (compatible with gsl_matrix struct layout). Elements would be either integers or doubles, promoting all ints to double in the mixed case. We can think about complex numbers later. Using some macro hackery, it should also be possible to provide some kind of array comprehensions. I still have to think about this. Does that proposal sound reasonable? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: Albert G. <Dr....@t-...> - 2008-08-28 23:37:27
|
John Cowan wrote: > How about some syntax, loosely analogous to Common Lisp's #' that > indicates that the following symbol is to be interpreted as a function > in this particular use? This would make the symbol locally nullary. That would be a possibility, but I don't like that syntax, and anyway we don't have any special symbols to spare since they might all be defined as operators by the user. Also, frankly I don't think it's an issue since that usage is not all that common and you can just use a guard like f===int instead. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: Albert G. <Dr....@t-...> - 2008-08-28 23:14:04
|
Eddie Rucker wrote: > This is the beginnings of a keyword highlight file for gedit. I think > Libor wanted one of these? Cool. Mind you, there's a typo in that file: s/othrwise/otherwise/. Does gedit support folding? I think that's one of the coolest features of Kate's Pure highlighting. > I ripped it off from Marco Barision and > Emanuela Aina's Ada highlight package and made the modifications for > pure. Is this legal? Well you gave them credit, and I don't think that anyone in their right mind would want to claim copyright in a silly little list of keywords. I suppose that you don't mind if I include this in the Pure distribution? Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: Eddie R. <er...@bm...> - 2008-08-28 23:05:29
|
On Thu 28/08/08 5:25 PM , Albert Graef Dr....@t-... sent: > Coming to think of it, it's even better if you write a wrapper function > for each type of matrix in C, which takes a list (as a pure_expr*) as > argument and returns a matrix. That would execute *much* faster since > you only have a single function call per matrix. (You don't initialize a > big matrix with n^2 function calls in C either, or do you? If GSL > doesn't provide a direct way to initialize a big matrix then that'd be a > major performance hog.) It has functions for initializing to zero, idenity, or all the entries the same value. However, since the data is laid out as an array of doubles, ints for gsl_matrix_int, (you get the picture) all I have to do is flatten a list of lists and memcpy'em in. struct { unsigned int size1; //number of rows; unsigned int size2; //number of cols; unsigned int tda; //number of entries per row double * data; //here is where the data is ... } gsl_matrix; A matrix m's cell is accessed like m->data[row*size2+col]. > Yes, it is. The Q modules work that way, too. When you have a complex C > library, almost invariably you need some additional support routines for > accessing the data, and that stuff is best written in C. Then you have a > little Pure module which hides away all the complexity, loads the > necessary C libraries and provides any high-level definitions > (overloading operators etc.) that you want. All the Pure programmer ever > sees is that Pure script. Ok. You made up my mind for me. The C wrapper is not difficult to make for Pure. You are right it is still faster to make a call to a call to a call than go through all the support within Pure. I noticed that even optimized gcc makes a call for a cos operation when it could plainly use a direct CPU fcos call. e.r. |
From: Albert G. <Dr....@t-...> - 2008-08-28 22:24:14
|
Eddie Rucker wrote: > What about complex? So I still have to have a setter function for double > and complex, so I might as well include integers. Yes, sure. I didn't suggest that you should throw the int setter routine out of the window. You have an int setter routine that takes an int matrix and int values. Then you have a double setter routine which takes a double matrix and either an int (which gets promoted to double) or a double value. Etc., you get the idea. No need for that type argument to the setter routines. Coming to think of it, it's even better if you write a wrapper function for each type of matrix in C, which takes a list (as a pure_expr*) as argument and returns a matrix. That would execute *much* faster since you only have a single function call per matrix. (You don't initialize a big matrix with n^2 function calls in C either, or do you? If GSL doesn't provide a direct way to initialize a big matrix then that'd be a major performance hog.) Well, obviously I don't have an idea how you initialize a matrix in GSL. Can you point me to some C code which shows how to do this? Then I'll be able to sketch out how you can make it work using the Pure API. It should really be easy. > Now, if I could only find a portable way of determining the size of word > boundaries for different machines and OSs ... I still don't understand why you need that. Just to access the dimensions of the matrix? As I suggested earlier, all accesses to the matrix struct can and should be wrapped up in C routines, then you don't need that kind of hack. > I really hate to add a C > wrapper on top of a C interface and then a Pure wrapper on top of the C > wrapper but it's definitely looking to be the best route. Yes, it is. The Q modules work that way, too. When you have a complex C library, almost invariably you need some additional support routines for accessing the data, and that stuff is best written in C. Then you have a little Pure module which hides away all the complexity, loads the necessary C libraries and provides any high-level definitions (overloading operators etc.) that you want. All the Pure programmer ever sees is that Pure script. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
From: John C. <co...@cc...> - 2008-08-28 22:16:27
|
Albert Graef scripsit: > The problem is how to decide which symbols on the lhs of that equation > are literal (function or constant) symbols, and which are the variables > which are to be bound by the equation. How about some syntax, loosely analogous to Common Lisp's #' that indicates that the following symbol is to be interpreted as a function in this particular use? This would make the symbol locally nullary. -- What asininity could I have uttered John Cowan <co...@cc...> that they applaud me thus? http://www.ccil.org/~cowan --Phocion, Greek orator |
From: Eddie R. <er...@bm...> - 2008-08-28 21:38:32
|
This is the beginnings of a keyword highlight file for gedit. I think Libor wanted one of these? I ripped it off from Marco Barision and Emanuela Aina's Ada highlight package and made the modifications for pure. Is this legal? (1) copy the pure.lang file into the directory /usr/share/gtksourceview-2.0/language-specs (2) get out of all gedit processes. (3) fire up gedit on you pure file and Shazam! e.r. |
From: Eddie R. <er...@bm...> - 2008-08-28 20:20:04
|
On Thu, 2008-08-28 at 17:51 +0200, Albert Graef wrote: > Eddie Rucker wrote: > > Actually the thingy I sent was bad. (m, setter) should have been (m, > > set) like in the following. Since set is local to matrix and we have > > lexical scoping, I see no problem. > > Yes, I missed that. But you could still simplify your definition, by > just making gsl_matrix_set promote integer arguments to double. I don't > see why you need that type argument to the setter function at all. What about complex? So I still have to have a setter function for double and complex, so I might as well include integers. Maybe people studying combinatorics might need integer matrices, no? If I only had doubles, things would certainly be easier to implement. By the way, I have to go through the BLAS interface to multiply matrices so I guess I should do everything through the BLAS interface. I read somewhere that I should combine GLS with ATLAS because it is a faster BLAS. Oh well, I think I'm going to stick with double matrices first until I work out the quirks and then add in the complex and integer matrices. Now, if I could only find a portable way of determining the size of word boundaries for different machines and OSs ... I really hate to add a C wrapper on top of a C interface and then a Pure wrapper on top of the C wrapper but it's definitely looking to be the best route. e.r. |