Новости

Обновление исправляет совместимость с Freenode после обновления этой сетью версии IRCd.

Вышел второй релиз-кандидат KVIrc 4.0

Ричард Столлман дал автограф проекту и пожелал успеха в разработке.

Image:Feed.png RSS

Материал из IRC клиент KVIrc.

Перейти к: навигация, поиск

Содержание

[править] Введение

Начиная с версии 3.0.2 вы можете использовать вставки кода на perl в коде KVS, а так же вы можете использовать команды KVS из perl`а. Это свойство может использоваться только в том случае, если рабочая установленная версия perl`а была найдена в момент выполнения ./configure.

[править] Использование perl из KVS

Использовать perl из KVIrc очень просто: просто вставьте вашу часть кода на perl между perl.begin и perl.end.

perl.begin
<здесь находится код на perl>
perl.end

Например:

perl.begin
open(MYFILE,'>>myfile.txt') or die "Can't open myfile.txt!";
print MYFILE "foo!\n";
close(MYFILE);
perl.end

Код на perl может быть вставлен где угодно в код на KVS только с тем условием, что он ограничен perl.begin и perl.end. Это означает, что вы можете писать код на perl в командной строке, в алиасах, обработчиках событий, всплывающих меню... везде. Если вы уже столкнулись с командой eval в KVIrc, вы наверно знаете, как выполнить код на perl из файла :)

[править] Использование KVS из perl

KVIrc экспортирует несколько команд в пространство имён perl, которые можно вызвать изнутри кода на perl. Красивейшим примером является KVIrc::echo():

perl.begin
KVIrc::echo("Привет миру KVIrc`а из perl!");
perl.end

KVIrc::echo() это аналог echo. Точный синтаксис такой:

KVIrc::echo(<текст>[,<цветовая_схема>[,<id_окна>]])

<текст> это, понятно, текст, который будет напечатан. <цветовая_схема> это эквивалент опции -i команды echo и <id_окна> это эквивалент опции -w. И <цветовая_схема>, и <id_окна> могут быть опущены (как вариант KVIrc может использовать цвет по умолчанию в текущем окне).

[править] Perl execution contexts

The perl code snippets are executed by the means of a perl interpreter. Each perl interpreter has its own context and thus it's own variables, own function namespace etc.

In the example above KVIrc creates an interpreter when perl.begin is invoked and destroys it at perl.end parsing time. In fact, KVIrc can mantain multiple persistent interpreters that will allow you to preserve your context across perl.begin invocations. You can invoke a specific perl context by passing it as parameter to the perl.begin command.

[cmd]perl.begin("mycontext")[/cmd]
$myvariable = "mycontext";
KVIrc::echo("This perl code is executed from ".$myvariable);
perl.end

The nice thing is that at a later time you can invoke this context again and discover that $mycontext has preserved its value:

[cmd]perl.begin("mycontext")[/cmd]
KVIrc::echo("myvariable is still equal to ".$myvariable);
perl.end

The first time you invoke a named perl context it gets automatically created and it persists until KVIrc terminates or the perl context is explicitly destroyed by the means of perl.destroy.

In fact there is a third possibility to destroy a context: it's when the perlcore module is forcibly unloaded (by the means of /perlcore.unload) but this is really a rare case and should be threated just like a KVIrc restart (the user probably WANTS the contexts to be reinitialized).

The nice thing is that not only your variables will get preserved but also any perl function or class you declare in a context will persist. It's just like executing a long perl script file with pauses inside.

If you omit the perl context name in the perl.begin command (or if you use an empty string in it's place) then KVIrc will create a temporary context for the snippet execution and will destroy it immediately after perl.end has been called.

The major side effect of keeping persistent perl contexts is that the perl's symbol table will grow and if not used carefully the interpreter may become a memory hog. So if you're going to use persistent contexts either try to keep the symbol table clean or explicitly call perl.destroy once in a while to recreate the interpreter. If you just execute occasional perl code snippets and don't need to keep persistent variables then just use the nameless temporary context provided by perl.begin("").

[править] Passing parameters to the perl script

The easiest way to pass parameters to the perl code snippet is to put them as perl.begin arguments. In fact the complete syntax of perl.begin is:

perl.begin(<perl context>,<arg0>,<arg1>,...)

Where the <arg0>,<arg1>...<argN> parameters are passed to the perl context as elements of the $_[] array.


perl.begin("","Hello world!","Now I CAN",1,2,3)
for($i=0;$i<5;$i++)
    KVIrc::echo($_,40);
perl.end

[править] Accessing the KVIrc scripting context from perl

KVIrc exposes the following functions that manipulate the variables of the KVIrc's current KVS execution context.

KVIrc::getLocal(<x>)

Returns the value of the KVIrc's local variable %x.

KVIrc::getGlobal(<Y>)

Returns the value of the KVIrc's global variable %Y.

KVIrc::setLocal(<x>,<value>)

Sets the KVIrc's global variable %x to <value>

pre>KVIrc::setGlobal(<Y>,<value>)

Sets the KVIrc's global variable %Y to <value> The local variables interested belong to the current KVS exection context while the global variables are visible everywhere.

%pippo = test
%Pluto = 12345
perl.begin
$mypippo = KVIrc::getLocal("pippo");
$mypippo =~ s/^pi/ze/g;
$mypluto = KVIrc::getGlobal("Pluto");
$mypluto =~ s/23/xx/g;
KVIrc::setLocal("pippo",$mypluto);
KVIrc::setGlobal("Pluto",$mypippo);
perl.end
echo "\%pippo is" %pippo
echo "\%Pluto is" %Pluto

[править] Executing arbitrary KVIrc commands from perl

You can execute arbitrary KVS commands from perl by the means of:

KVIrc::eval()

This function behaves exactly like the ${ <code> } KVS construct: it executes <code> in a child context and returns it's evaluation retult. The following two code snippets have equivalent visible effects:

echo ${ return "Yeah!"; }
perl.begin
KVIrc::echo(KVIrc::eval("return \"Yeah!\""));
perl.end

You can "eval" composite command sequences and variable ones. Remember that the perl code snippet is evaluated in a child KVS context and thus the local variables are NOT visible!. The following code snippets may easily fool you:

%x = 10
perl.begin
KVIrc::eval("echo \"The value is %x\"");
perl.end

This will print "The value is " since %x is not accessible from the eval's context. If you have tried to write something like this then you probably need to rewrite it as:

%x = 10
perl.begin
$x = KVIrc::getLocal("x");
KVIrc::eval("echo \"The value is ".$x."\"");
perl.end


Note also that you must either escape the $ at the beginning of the KVIrc identifiers or use the single quotes to prevent perl from catching the $ as the beginning of a variable.

# This will not work as expected
perl.begin
KVIrc::echo(KVIrc::eval("return $window.caption"));
perl.end
# But these will do
perl.begin
KVIrc::echo(KVIrc::eval("return \$window.caption"));
KVIrc::echo(KVIrc::eval('return $window.caption'));
perl.end

A shortcut for KVIrc::eval("/say...")

Since KVIrc::eval("/say...") is a common calling pattern then say has been added to the KVIrc perl namespace. You can now call

KVIrc::say("Hi all!");

and that will mimic the behaviour of

/say Hi all!

The complete syntax for KVIrc::say() is:

KVIrc::say(<text>[,<windowid>])

and the semantics are obvious (see also /say). The perl script return values

The perl.begin command propagates the perl code return value to the KVIrc context (just like a setreturn() would do). In fact the perl snippet return value is the last "thing" that the interpreter evaluates. In this way you can write perl aliases that return values without doing any variable passing equilibrism.

[править] Executing perl scripts from files

alias(perlexec)
{
    %tmp = "perl.begin(\"\",$1,$2,$3,$4,$5)";
    %tmp .= $file.read($0);
    %tmp .= "perl.end";
    eval %tmp;
}
perlexec "/home/pragma/myperlscript.pl" "param1" "param2" "param3"
# or even
echo $perlexec("/home/pragma/computeprimelargerthan.pl","10000")

[править] Other tricks

An interesting feature of the persistent perl contexts is that you can prepare a context for a later fast execution. The idea is to declare perl functions in a single perl code snippet and to call the single functions when a fast execution is needed. For example you might parse the following snippet at KVIrc's startup:

perl.begin("persistent")
sub handler_for_event_1
{
    do_complex_perl_stuff_here
}
sub handler_for_event_2
{
    do_complex_perl_stuff_here
}
perl.end

and later simply call:

perl.begin("persistent",param1,param2)
handler_for_event_1($_[0],$_[1])
perl.end

[править] Curiosity

The perl support in KVIrc is implemented as a master-slave module pair. The perl.* module is the master while perlcore is the slave. When the perl support isn't compiled in, the perl.* commands print some warnings and exit gracefully while the perlcore module refuses to be loaded. When perl support is compiled in but for some reason the libperl.so can't be found or loaded then perlcore fails the dynamic loading stage but perl.* still fails gracefully with just some warning messages. This trick allows the scripters to check for perl support with $perl.isavailable and to embed perl code snippets in KVS even if the support is missing. The snippets will be just skipped.

Happy perl hacking :)

Личные инструменты
Инструменты
Наши кнопки
Размести кнопку KVirc у себя на сайте:
www.kvirc.ru - кроссплатформенный IRC клиент с богатым графическим интерфейсом и внутренним языком скриптинга
Друзья и спонсоры
  • Fireforge.net
Linux coutner