Mirror of forum.nim-lang.org

488 :: libusb / making a nimrod wrapper

• skyfex (orginal) [2014-07-05T10:46:36+02:00] view original

  I started on a libusb wrapper for a project I'm working on, and I thought I would try to make it into a working Babel package soon. First I have some questions though.

  You can see what I currently have right here: https://github.com/skyfex/kiosk/blob/master/libusb.nim

  • I thought I would separate the above code into a pure libusb wrappers (same names, no new code, etc), and a "usb" package, which will have a more Nimrodic interface (exceptions, iterators, garbage collection, all the goodies) and perhaps "batteries included", with code to deal with basic card readers, cameras, thermal printers...
  • I (and nim2c) had a problem with an enum (libusb_error) where the values were negative, i.e. SUCCESS was 0, and the various errors were negative numbers. Since Nimrod requires enum to be listed in strict ascending order, I had to flip the definition which was a bit tedious. Will Nimrod allow descending definitions, or is this just the way we have to do it?
  • In the function definition in the pure wrapper, should the functions take/return ints or enums?
  • For the pure wrapper, I want to use the original struct names (e.g. libusb_device_descriptor) while for the nimrodic library I want to use a nimrodic name (DeviceDescriptor). But I couldn't just alias the type, because then it wouldn't work for the types of the fields of the struct. So I had to redefine it and do a cast. Is there a better way to do this, or should I just use the nimrodic names in the wrapper?
  • There is of course the whole TFoobar/PFoobar thing.. I dropped the P in my code, but I will follow whatever convention is established.
  • When making the nimrodic interface, what I did was wrap pointers in a ref, and attach a finalizer to the ref which will close/free the pointer. That seems to have worked very well for me so far.
  • Dealing with code that can send/recieve binary data felt a bit awkward at the moment in Nimrod. What I ended up doing there was implementing the "packed" pragma in the compiler, and I defined generic functions which could take any object and would write to that, in additions to ones that takes a byte-array. See for instance the three versions of "bulkTransfer". I stumbled into problems when I was unpacking data from the device though, because of endianess. In the future what I'd like to do here is to have some kind of DSL for defining the data packing of an object, and to have the code pack/unpack the data for you.

  Any other comments to the code is welcome.

---

• gradha (orginal) [2014-07-05T12:29:22+02:00] view original

  The separate c2nim which is available through babel should provide a version which sorts enums. Hmm... the nimrod tree still has c2nim.

  It seems finalizers are deprecated and the future is the destructor pragma.

  I did the low level C vs high level nimrod split for midnight_dynamite and it works very well. But that's an implementation detail I decided to help me update the underlaying C library in the future with less pain. Since you are planning on offering the module through babel I think it would be enough to mark only the higher level as exported procs and then through nimdoc you document those bits. Most users won't look at the c2nim generated versions so it won't matter much if they are all mixed up in the same source file.

  The alias issue you mention is weird, you mean that type type DeviceDescriptor* = libusb_device_descriptor somehow prevents you from accessing the fields? Aliasing is used in various places of the standard library and seems to work fine

---

• Stefan_Salewski (orginal) [2014-07-05T20:50:03+02:00] view original

  and a "usb" package, which will have a more Nimrodic interface (exceptions, iterators, garbage collection, all the goodies)

  Fine -- would be a nice example for a high level wrapper. (I used the old libusb some years ago from C.)

  The separate c2nim which is available through babel should provide a version which sorts enums.

  Interesting -- it took me some hours to do the manually sorting for GTK3 :-(

---

• skyfex (orginal) [2014-07-06T21:12:29+02:00] view original

  Gradha:

  I just meant that if I have a struct

  type:
    libusb_bar = object
      ...
    libusb_foo = object
      name: libusb_bar
  Run

  And i do

  type Bar = libusb_bar
  type Foo = libusb_foo
  Run

  Then the type of Foo.name is libusb_bar, not Bar as I wanted. It shouldnt cause any restrictions I suppose, but Im thinking it could cause confusion to users (in error messages and so on). Also might be problem when generating documentation for the nimrodic wrapper.

---

• gradha (orginal) [2014-07-06T23:20:46+02:00] view original

  That's essentially the same problems you get with C's typedef aliasing. You could also write the aliases in the original block to use them if you consider them so important.

  
  type:
    libusb_bar = object
      ...
    libusb_foo = object
      name: Bar
    Bar = libusb_bar
  Run

---