First of all, i have to admit that i feel that i should know this already, but i just don't.

Is it possible to add external cpp/h files when using Inline::CPP? I only need XS bindings for the stuff i'm inlining, the rest only needs to be accesible through the inlined CPP code.

Here is the simplest example i could tink of.

test.pl	use Inline CPP; for(1..3) { print "Perfect random number: ", cast_die(), "\n"; } __END__ __CPP__ #include "xkcd.h" int cast_die() { int rolled = xkcd_dice_roll(); return rolled; } [download]
xkcd.h	#ifndef XKCD_DICE #define XKCD_DICE // See https://xkcd.com/221/ for why this is absolutely perfect #define FAIRLY_GENERATED_RANDOM_NUMBER 4 int xkcd_dice_roll(); #endif [download]
xkcd.cpp	#include "xkcd.h" int xkcd_dice_roll() { return FAIRLY_GENERATED_RANDOM_NUMBER; } [download]

Is something like this even possible with Inline::CPP?

while developing a module I like to run (F5) the testsuite automatically. I'm using a moulino approach which works considerably well

#BEGIN {                         # TODO
    unless ( caller() ) {              # Modulino for development
        exec q(cd ../..; prove  ./t/); #run proove from dist root 
    }
#}
[download]

It occurred to me that I have to enclose this inside a BEGIN block to avoid the overhead and side-effects of loding all modules with use (this happens in the BEGIN phase) before the unless is executed at run time.

This doesn't work, since caller() IS defined inside BEGIN

BEGIN { warn "Caller Begin: ",defined caller(0) }
warn "Caller Normal: ",defined caller();
[download]

Caller Begin: 1 at /home/lanx/...
Caller Normal:  at /home/lanx/...
[download]

EDIT Solution

while writing this I realized that BEGIN is called 2 levels down, hence caller(2) seems to work

BEGIN {                         # TODO
    unless ( caller(2) ) {              # Modulino for development
        exec q(cd ../..; prove  ./t/); #run proove from dist root 
    }
}
[download]

Is this reliable?

(I think it is, but I already wrote this post, before finding the solution and the monastery is not overwhelmed with writeups :)

I'm developing a DBIx distribution and need to check plenty of SQL in the tests.

My approach is to use SQLite as primary engine, since it comes with the DBD::SQLite module installed and that's not much of a prerequisite (it's even comes bundled with Strawberry Perl!)

My issue is where to put the temporary SQLite file...

• in the distribution's /t directory?
• in the FS's /tmp ? What about other OSes?
• or should I restrict the SQL-testing to the authors system

Those SQLite files don't become big, but I'm not sure about writing stuff into the dist directory. On a side note:

I want to be able to switch to other DB-Servers while testing. (But now really author's side unless explicitly wanted by the user)

What's the best approach to make this configurable?

• A prove option
• an ENV setting
• a prompt while testing? (DBI can test for available DBD:: drivers)

I'm trying to parse RSS feeds with XML::RSS::Parser, and it's mostly working fine, except that I need to be able to pull the content of elements in the itunes namespace and nothing I can think of seems to work.

If I'm trying to read the element itunes:summary (it will be en object of type XML::RSS::Parser::Element), for example, I've tried:

$summary = $element->query('itunes:summary');
$summary = $element->query('{http://www.itunes.com/dtds/podcast-1.0.dt
+d}summary');
$summary = $element->query('summary')
$summary = $element->query(process_name('itunes:summary'):
$summary = $element->query(process_name('{http://www.itunes.com/dtds/p
+odcast-1.0.dtd}summary'):
[download]

Does anyone know how this works? Thanks.

I wrote the following code to modify a bunch of pandoc-generated DokuWiki formatted files in order to convert some expressions to DokuWiki internal links. That went through many iterations and I am now somewhat satisfied with the result except for one mystery I am unable to pierce through.
It does not crash my code, nor does it sends any warning, but I can't explain this result.

Here's my problem:

In this substitution part of the code: .(defined($4) ? $4 =~ tr[\/*][]dr : '.') line 44, I check if the value of $4 is defined and if it is, I apply a tr to it to remove italic (//) or bold (**) marks if they are present. If $4 is undefined (meaning there are no dot, comma or semicolon after the last word of the expression), the conditional operator sends a dot to end the substitution.

So either this data entry:

**Voir :** proton, solution hydrogénée//.//
[download]

**Voir :** proton, solution hydrogénée.
[download]

**Voir :** [[glossaire:entrees:p:proton|proton]], [[glossaire:entrees:
+s:solution_hydrogenee|solution hydrogénée]].
[download]

**Voir :** proton, solution hydrogénée
[download]

**Voir :** [[glossaire:entrees:p:proton|proton]], [[glossaire:entrees:
+s:solution_hydrogenee
|solution hydrogénée
]].
[download]

**Voir :** [[glossaire:entrees:p:proton|proton]], [[glossaire:entrees:
+s:solution_hydrogenee|solution hydrogénée]].
[download]

It may have something to do with the /x modifier I suspect.

The actual code follows

Thanks for reading through !

cpan -M https://www.cpan.org -a
[download]

For our beloved brother chatterbot, though, this isn't the case. The XML version returns nothing, which breaks the XML parser in pc-cb-g. Why is that?

There is a new nodelet, Notifications.

What this essentially does is split out the system-generated notification messages into a separate nodelet from the Chatterbox nodelet. So if you enable this nodelet, then all of the messages which come to you from the system (i.e. from root or NodeReaper) are shown in this nodelet and not in the Chatterbox nodelet.

This is structured very similarly to the Chatterbox nodelet, but with a few simplifications:

• It only shows a maximum of 16 notifications; it ignores your "Max to display in Chatterbox" setting.
• It shows a maximum of 16 entries, unless you have "Max to display in Chatterbox" set. (When viewing Notifications directly, the default max is 128.)
• It doesn't show the sender of each message. (It will only ever be root or NodeReaper anyway.) In the place of that, it shows a bullet.
• Since the sender isn't shown, to see the send time you can hover over the message preface.
• There is no 'talk box' in this nodelet. Instead, there is a 'delete' button you can press to delete any checkbox-selected messages.
• The preface from NodeReaper — "I've reaped a node you considered" — is changed to "A node you considered has been reaped".

As with all nodelets*, this one can be viewed "standalone" on its own page, simply by going to the node of the same title: Notifications.

* With just a couple exceptions.