On Fri, Mar 20, 2020 at 5:01 PM Samuel May <ag.eit...@gmail.com> wrote:

> Hello everyone!
>
> I'm working on Haskell bindings to libcdio


I think this would be awesome!  Here's a fun fact recarding haskell: the
person whose code started this all and wrote a VCD authoring tool
vcdimager, hvr <https://github.com/hvr> also now works a lot in Haskell. I
think his natural inclination and rigor that went into vcdimager and may
have accidentally bled into libcdio steered him towards selecting Haskell
as his primary programming language later.


> (I have ~plans~ for wrangling
> my weird music library requirements and/or preferences into a generally
> usable program suite and just love that language; of course I couldn't
> simply half-ass the layers nobody cares about...), and in the process of
> writing those I've come up with a few questions:
>
> * Is there any deliberate reasoning behind 2.1.0 not adding a
>   cdtext_get_language_index(..) with cdtext_select_language_index(..)?
>   Having the means to jump exactly where you want doesn't mean that you
>   can get back to where you started with just cdtext_get_language(..) --
>   what if we just happen to have been on the /second/
>   CDTEXT_LANGUAGE_ENGLISH block by some perverse CDTEXT author, or more
>   realistically which of several CDTEXT_LANGUAGE_UNUSED?
>

If you want to define a different API ok and  we could discuss it here.


>
> * What about changing the language of a block?  I know libcdio
>   isn't primarily a disc-authoring library, though with cdtext_set(..)
>   and cdio_get_cdtext_raw(..) it can definitely be used constructively
>   -- but without cdtext_set_current_language(..) or similar, there's
>   always a little bit which would need to be tweaked afterward, or empty
>   blocks which need to be generated and piped into cdtext_data_init(..)
>   manually before starting to write anything new.
>

You are correct i -  it wasn't my intention to try to compete with existing
authoring code and libraries. However there is a fair bit of overlap which
is unavoidable.

If what you are doing easily fits within the current model it can be
extended. However if it doesn't consider libburn or whatever else is out
there.


>
> * Likewise should cdtext_set(..) really leave cdtext_get_first_track(..)
>   and cdtext_get_last_track(..) with the original bounds?  I'm sure some
>   weirdness might crop up if those don't match with the start/end tracks
>   from the disc as a whole, but on the other hand I didn't expect the
>   current behaviour and I'm sure I'm not the only one -- at the very
>   least, it should be documented.
>
> * On a less general note, is there any API or #define means to disable
>   or redirect the warning messages printed to stdout?  I still need to
>   figure out how to pass them to the user, but Haskell has a thing about
>   avoiding unexpected side effects, and text suddenly appearing in the
>   terminal certainly counts.
>

There is this global variable cdio_loglevel_default
<https://www.gnu.org/software/libcdio/doxygen/logging_8h.html#a4a2cfa6fc840a2071972a79f81de7757>
that
indicate the level of pain needed before reporting a problem.,

Also you can customize the logging routines with cdio_set_handler()
<https://www.gnu.org/software/libcdio/doxygen/logging_8h.html#ac3eed1c912be3ca91a6323e110fe6a2a>
.

>
> * More troublingly, has anyone ever run into issues with CdIo_t sessions
>   locking up your drives?  If I call some functions (I don't /think/ it
>   happens across the board, but I haven't gone looking for a pattern
>   yet) the physical button on the front of my drive stops working until
>   I call cdio_eject_media(..) or *_drive(..) from the software side.  I
>   know it's an issue with my Haskell, and likely with cdio_destroy(..)
>   not getting called by the garbage collector for some reason, but I
>   figured if anyone had come across before it in earlier development,
>   you could save me time digging to verify that.
>

The closest thing I can think of has to do with working on OS/X. If you
want to write to the drive you need to get exclusive access to the drive
which locks out any other access. And then when you do get access, you
should make sure that when the process using the drive finishes it
reliquishes exclusive access. cdio_open_am()
<https://www.gnu.org/software/libcdio/doxygen/device_8h.html#adb5f3f481d81cbf91231715c1ea9aad8>
is
the top-level function. I see the string "psz_access_mode" parameter isn't
described, I guess because this is driver specific which really means it is
OS specific. This should be documented better in the future.

Looking at the code though I see that SCSI access has been commented out
because it is in need of fixing up. However if you look at the GNU/Linux
code in lib/driver/gnu_linux.c around line 80
<http://git.savannah.gnu.org/cgit/libcdio.git/tree/lib/driver/gnu_linux.c#n80>you'll
see the different levels of access modes. In particular there is read/write
(_AM_MMC_RDWR) and read/write exclusive (_AM_MMC_RDWR_EXCL) and later
you'll see the access-mode string that correspond to this are "MMC_RDWR"
and "MMC_RDWR_EXCL".

To dig in and get more information about the instruction sequence set the
log level mentioned above to debug.

Finnally, if this turns out to requre a bunch of SCSI MMC commands that
logically acts as a single high-level function, we can add that function
in. In particular mmc_eject_media()
<https://www.gnu.org/software/libcdio/doxygen/mmc__hl__cmds_8h.html#af8ea9a156462b898c0854a95697b35cb>
works
this way.


> * Finally, is there a vetting process or anything else I should be aware
>   of for language bindings?


None that I can think of. Having done a few of these, I'll say up front
that many of the binding I've done don't cover the full set of capabilites,
just those that I wanted or needed and could easily figure out how to do.
Being lazy has paid off, many or most of the bindings are rarely used and
I've only had to make small adjustments. Or better the few that have tried
these have offered patches for the thing that they needed.


> It's not ready for prime time yet, as that
>   last question shows, but I will be hoping to release these for public
>   use once I get a bit more patching and polishing done -- at first with
>   just what an "#import <cdio/cdio.h>" will get you, but eventually with
>   the entire library.
>
> Thanks!
>
> Sam
>
>

Reply via email to