[Haskell-cafe] Re: ANNOUNCE: usb-safe-0.1

Bas van Dijk v.dijk.bas at gmail.com
Wed Dec 9 18:04:54 EST 2009


On Wed, Dec 9, 2009 at 3:50 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
> On Wed, Dec 9, 2009 at 2:35 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
>> Hello,
>>
>> My usb library provides a standard Haskell abstracting layer over
>> bindings-libusb providing: abstract types instead of Ptrs, automatic
>> marshalling and unmarshalling, automatic garbage collection,
>> exceptions instead of integer return codes, etc..
>>
>> While all that is very nice there are still some things that you can
>> do wrong. For example doing I/O with a closed device or reading from
>> or writing to an endpoint which doesn't belong to the claimed
>> interface. Or reading from an Out endpoint or writing to an In
>> endpoint.
>>
>> I released the usb-safe package to prevent you making these errors. See:
>>
>> http://hackage.haskell.org/package/usb-safe-0.1
>>
>> usb-safe provides the following guarantees:
>>
>> -  You can't reference handles to devices that are closed. In other
>> words: no I/O with closed handles is possible.
>>
>> - The programmer specifies the region in which devices should remain
>> open. On exit from the region the opened devices are automatically
>> closed.
>>
>> - You can't reference handles to configurations that have not been set.
>>
>> - You can't reference handles to interfaces that have not been claimed.
>>
>> - You can't reference handles to alternates that have not been set.
>>
>> - You can't reference endpoints that don't belong to a setted alternate.
>>
>> - You can't read from an endpoint with an Out transfer direction.
>>
>> - You can't write to an endpoint with an In transfer direction.
>>
>> - You can't read from or write to endpoints with the unsupported
>> transfer types Control and Isochronous. Only I/O with endpoints with
>> the Bulk and Interrupt transfer types is allowed.
>>
>> The primary technique used in usb-safe is called "Lightweight monadic
>> regions" which was invented by Oleg Kiselyov and Chung-chieh Shan.
>> See:
>>
>> http://okmij.org/ftp/Haskell/regions.html#light-weight
>>
>> Note that I consider this a preview release. In fact, I haven't tested
>> the package at all. I can only guarantee you that it will pass the
>> type-checker.
>>
>> As always: questions, comments and patches are more than welcome.
>>
>> Please don't look at the hscolour generated source code from the
>> haddock documentation because it screws up the nice unicode symbols I
>> used. If you want to read the source download the package or go
>> straight to the darcs repos:
>>
>> darcs get http://code.haskell.org/~basvandijk/code/usb-safe
>>
>> regards,
>>
>> Bas
>>
>
> I just released a new 0.2 version of usb-safe which adds the type synonym:
>
> type TopDeviceRegion s = DeviceRegionT s IO
>
> and the function:
>
> runTopDeviceRegion ∷ (∀ s. TopDeviceRegion s α) → IO α
>
> I changed the name of 'forkDeviceRegionT' to 'forkTopDeviceRegion' and
> changed its type accordingly.
>
> Because these are API changes and additions I bumped the version from
> 0.1 to 0.2 following the PVP[1].
>
> See:
>
> http://hackage.haskell.org/package/usb-safe-0.2
>
> darcs get http://code.haskell.org/~basvandijk/code/usb-safe
>
> regards,
>
> Bas
>
> [1] http://haskell.org/haskellwiki/Package_versioning_policy
>

And yet another major release for usb-safe-0.3

* This time I renamed the type 'EndpointHandle' to 'FilteredEndpoint'
because it's not really a handle to an endpoint but more of an
endpoint which got filtered and therefor got some more type
information.

* I also renamed lots of type variables to better reflect their
intended meaning.

* Finally I added some documentation.

See: http://hackage.haskell.org/package/usb-safe-0.3 or the darcs
repos for details.

Maybe one major 0.4 release will follow shortly where I remove the
region variables from: ConfigHandle, Interface, InterfaceHandle,
Alternate, AlternateHandle, Endpoint and FilteredEndpoint. I think
these region variables are not strictly necessary in these types
because they are already imprisoned (for lack of a better term) by all
the respected 'with*' functions using their 's' type variables.
However I have to think about if this is a wise change.

regards,

Bas


More information about the Haskell-Cafe mailing list