Question about language setting

Discussion in 'Perl Misc' started by Dave Saville, Dec 23, 2013.

  1. That's what you have to do (and use the number instead of a string)
    because there's no way to get access to the symbolic names without
    loading the Perl part. However, what I was thinking was actually rather
    something like this:

    /* includes */
    #include "EXTERN.h"
    #include "perl.h"
    #include "XSUB.h"

    #include <locale.h>

    MODULE = set_lc_all

    char *set_lc_all(what)
    char *what
    RETVAL = setlocale(LC_ALL, what);

    This is code written in the Perl eXtenSion language. It can be turned
    into C with xsubpp, compiled into a shared object/ DLL and the
    individual funtion can then be made available via DynaLoader. This
    requires a certain one-time effort (I don't think I can legally post the
    code I'm using but all in all, it is a lot less than 100 LOC) but I
    found it more than occasionally useful that I can combine Perl and C
    Rainer Weikusat, Jan 11, 2014
    1. Advertisements

  2. I'm usually building (pretty bare bones) Debian packages, so that's not
    an issue. ATM, there are 51 one them, with the 52nd in development. The
    initial attempt to manage all of this manually (on about a dozen
    different installations spread all around the globe) broke down a few
    years ago :).
    This had helped here but I'm actually really writing C code and linking
    that with Perl, the code I posted upthread was just the simplest example
    I'm presently using (there's no way to get access to __builtin_clz by
    using a library as this is really a 'built-in' gcc function which gets
    replaced by the corresponding machine instruction for the target

    There is

    (which I found by 'creatively' typing 'Perl FFI' in a Google search box)
    but I'm unsure if I'd want to use that (would need to have a look at the
    internals), considering that XS works nicely enough.
    Rainer Weikusat, Jan 11, 2014
    1. Advertisements

  3. Considering that you don't do anything with XSLoader, should this
    perhaps have been

    require Dynaloader;


    Also, the 5.10.0 POSIX.whatever should have XS__setlocale, considering
    that the 5.10.1 one has it.
    Rainer Weikusat, Jan 12, 2014
  4. The correct name is XS_POSIX_setlocale. For the sake of completeness,
    here's an executable example (Tested on Linux. Will need to be changed
    on platforms which don't use .so as extension for 'dynamically loadable
    library files) showing how to import just the setlocale routine into the
    current package without running any of the 'module init code',

    BEGIN {
    my ($path, $lib, $sym);

    require DynaLoader;

    # add the perl include path to the DynaLoader library path
    # so that dl_findfile will find
    local @DynaLoader::dl_library_path = (@DynaLoader::dl_library_path, @INC);
    $path = DynaLoader::dl_findfile('auto/POSIX/');
    unless ($path) {
    print STDERR ("didn't find\n");

    # load the library
    $lib = DynaLoader::dl_load_file($path, 0);
    unless ($lib) {
    print STDERR ("failed to load $path\n");

    # locate the setlocale interface routine
    $sym = DynaLoader::dl_find_symbol($lib, 'XS_POSIX_setlocale');
    unless ($sym) {
    print STDERR ("didn't find XS_POSIX_setlocale\n");

    # install it into the current package
    DynaLoader::dl_install_xsub('setlocale', $sym);

    # print a 'German floating point number'
    setlocale(1, 'de_DE'); # LC_ALL == 1
    printf("%f\n", 2.5);

    It should also be noted that locally extending an existing array with
    some values couldn't work in the way it is done here without being able
    to access the previous incarnation of some symbol while creating a new
    Rainer Weikusat, Jan 12, 2014
  5. [...]
    Is there some rationale for that beyond "it breaks existing code"?
    Rainer Weikusat, Jan 12, 2014
  6. A comment regarding that is available below the page break as this
    question is really besides the point. I assume the XSUB change had some
    technical objective, ie, someone thought something could be gained in
    this way. But I can't imagine what (wich may be entirely my fault). The
    wording in the corresponding changes document,

    The EXPORT_XSUB_SYMBOLS: keyword is likely something you will never

    suggests that whoever wrote that didn't believe anyone actually uses
    DynaLoader for anything, yet I do. Hence, the immediate effect is that I
    can't use 5.16 and onwards (not exactly an immediate danger) without
    either changing all the affected code or (more likely) restoring the old

    An immediate (although weak) argument for the old behaviour which comes
    to mind would be: If the XSUBs are externally visible symbols, they can
    be installed on demand. Especially for large modules providing access to
    'diverse facilities', eg, POSIX, this should reduce the startup time of
    code using the module, may reduce the total time needed to use some
    parts of the module for a given situation (if only a few symbols are
    ever used) and should use somewhat less memory.

    Considering that I know that not every report made to the Perl
    foundation in the course of some development grant is technically
    accurate -- whether this happened because the guy who wrote them didn't
    understand the matter himself or banked on the fact that the people
    getting the reports won't understand it I don't know -- 'malice [aka
    "some political agenda"] or stupidity' might be an interesting question
    on its own right, but a rather tangential one: People who subscribe to
    p5p are people, hence, they're bound to make mistakes and prone to
    inventing technical justifications which don't really hold water in order
    to push this or that pet agenda of them, just like all other people.

    But beyond this general statement ('even the wisest man is no God'),
    speculations about other people's hidden motives are (IMHO) unpleasant
    and useless.
    Rainer Weikusat, Jan 13, 2014
  7. As far as I know, the term 'idiot' ('idiotus', actually) was invented by
    Cusanus to describe people he referred to as 'eigensinnig Wissende' in
    German, whose main trait was supposed to be that they won't - under any
    circumstances - accept anything from anyone else and who are thus bound
    to progress slowly and circuitiously towards understanding the world but
    who might eventually gain such understanding nevertheless.
    Rainer Weikusat, Jan 13, 2014
  8. Dave Saville

    Dave Saville Guest

    Yes *I* am but other users will almost certainly be using earlier
    versions. I suppose one could switch on the perl version.

    I appreciate all the help guys but I really think the simple answer is
    to check the perl version for before 5.16.3 and for 2.5 ne "2.5" and
    put out a message telling them to change the locale before running the
    script and quit.
    Dave Saville, Jan 13, 2014
  9. I've located the corresponding p5p thread,

    but I'm still at a loss regarding what this is supposed to accomplish. A
    couple of quotes from the thread and the original commit:

    This is [...] generally preferable

    the symbols are already all internal by default on Windows (and AIX)

    I doubt that many (any?) existing modules intentionally export
    XS symbols [...] It is much easier to call plain C code from a different module
    than XS code, which really should only be called through Perl.

    Exporting the C symbol corresponding to an XS sub body is a pretty bizarre

    'perl -MGtk2 -eexit' is now twice as fast as before: 0.036s with 5.14.1,

    "A little less than 0.02s speedup for a program which loads a seriously
    large module and does nothing" doesn't seem to be much of an improvement
    to me, especially considering that Gtk2 would likely be used for an
    interactive application and '0.02s during startup' is irrelevant noise
    for that. The idea that this "bizarre requirement" enables on demand
    creation of of XSUBs instead of creating them all at once (a benchmark
    on how omitting boot_ from the Gtk2 load sequence in favour of this
    affects execution time would be interesting) doesn't seem to have
    crossed anyone's mind and the "It is much easier to call plain C code
    [...]" strongly suggests that the guy who wrote this doesn't even know
    that Perl provides an API for accessing invividual XSUBs.
    Rainer Weikusat, Jan 13, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.