Main index > Perl programming > perl problem @ recording

By schlum (User), on Fri Apr 28 09:04:53 2006: perl problem @ recording.

Hey,
I put the thread here cause theres no Perl Forum :-)
well i have a lil problem with start_recording() and load_image():

Code:

#!/usr/bin/perl -w
use adesklets;
adesklets::open_streams();
print 1;
adesklets::start_recording();
print 2;
my $image = adesklets::load_image('frog.png');
adesklets::context_set_image($image);
print 3;
adesklets::stop_recording();
print 4;
print "\n$image\n";
adesklets::close_streams();
So the ouput is like this:

Code:

1234
load_image frog.png
the load_image() returns "load_image imagename" within recording and no image ID
Probably a Bug ? Or am I doing something wrong ?

Best regards
schlum

By syfou (Core Developer & Desklet Author), on Fri Apr 28 15:52:49 2006.

Hi schlum,

so far, the behavior you describe is perfectly normal: basically, you try doing something that cannot work.

In the manual, I wrote:


Of course, no command is ever evaluated while the interpreter is in indirect mode; commands are only stored in the history for future replay

This means that you cannot mix high-level dynamic evaluation in Perl with adesklets indirect mode of execution, because in this mode commands are not evaluated right away: they are delayed. Look at this raw, Perl-independent adesklets session:

Code:


$ adesklets :
adesklets 0.6.1 (Mon Apr 24 02:04:48 EDT 2006), on Linux 2.6.16
[gcc 4.1.0 (Gentoo 4.1.0)]
Press TAB for hints.
0 >>> load_image frog.png 
command 0 ok: new image 2
1 >>> start_recording 
command 1 ok: start_recording 
2 >>> load_image frog.png 
command 2 ok: load_image frog.png 
3 >>> stop_recording 
command 3 ok: recorded_commands 2 2
4 >>> images_info 
3 images
id 0 width 1 height 1 alpha 1 filename (null)
id 1 width 1 height 1 alpha 1 filename (null)
id 2 width 183 height 138 alpha 1 filename frog.png
command 4 ok: images_info 
5 >>> play 2 2 
command 5 ok: play 2 2
6 >>> images_info 
4 images
id 0 width 1 height 1 alpha 1 filename (null)
id 1 width 1 height 1 alpha 1 filename (null)
id 2 width 183 height 138 alpha 1 filename frog.png
id 3 width 183 height 138 alpha 1 filename frog.png
command 6 ok: images_info


Notice the behavioral difference between command 0 and command 2: command 0 is in direct mode, so it is processed right away and an ID is returned. Command 2 is in indirect mode (because of command 1): the command is merely echoed back. On command 5, command 2 is finally played: see how only the fact that the replay went smoothly is returned, and how the images stack changed.

I hope this shed some light on the subject.... To summarize, only use indirect mode on sequences of commands that do not need any direct intervention from the driving Perl script.. ;-) Yours,

By schlum (User), on Sat Apr 29 07:52:48 2006.

ah ok i see.
that means commands, that give you something back like load_image are direct commands?
or how do i know what are indirect and direct commands ?

//EDIT
Another thing:
adesklets::adesklets::context_set_image($myImage);
$clonedImage = adesklets::clone_image();

$clonedImage ist " " why i dont get an ID back ?

By syfou (Core Developer & Desklet Author), on Sat Apr 29 12:53:07 2006.

Please re-read the doc. There are no such things as direct or indirect commands, there are only direct and indirect modes, and all commands can successfully be used in both, as illustrated above for command load_image.

Quote:


that means commands, that give you something back like load_image are direct commands?

Well, not exactly. That means that you cannot dynamically evaluate return values in indirect mode: it doesn't means you cannot successfully invoke the commands. ;-) adesklets is a stateful, stack-based console, and many image manipulation sequences can easily be performed "blindly" without intervention from the driving script -- that's when indirect mode might be handy (animations, optimization for "heavy" desklets).

As for a potential problem with command clone_image, everything seems working fine:

Code:


use strict;
use adesklets;

adesklets::open_streams();

adesklets::context_set_image(1); 
my $img =  adesklets::clone_image();
print "Image ID: $img\n";

Output:

Code:


Do you want to (r)egister this desklet or to (t)est it? t

Now testing...
============================================================
If you do not see anything (or just an initial flicker
in the top left corner of your screen), try `--help',
and see the FAQ: `info adesklets'.
============================================================
Image ID: 2


Of course, the Perl bindings are pretty new, and I don't guarantee there are no API glitches -- I don't think this is one though: please share reproducible evidence (i.e. runnable, short code showing the problem) if you think otherwise. Yours,

By schlum (User), on Wed May 3 03:51:58 2006.

syfou wrote:

Please re-read the doc. There are no such things as direct or indirect commands, there are only direct and indirect modes, and all commands can successfully be used in both, as illustrated above for command load_image.
Well, not exactly. That means that you cannot dynamically evaluate return values in indirect mode: it doesn't means you cannot successfully invoke the commands. ;-) adesklets is a stateful, stack-based console, and many image manipulation sequences can easily be performed "blindly" without intervention from the driving script -- that's when indirect mode might be handy (animations, optimization for "heavy" desklets).
ah ok now i understand. thanx :)

syfou wrote:

As for a potential problem with command clone_image, everything seems working fine:

Code:

...

Output:

Code:

...


Of course, the Perl bindings are pretty new, and I don't guarantee there are no API glitches -- I don't think this is one though: please share reproducible evidence (i.e. runnable, short code showing the problem) if you think otherwise. Yours,
mhm hum well i have to look into my code if i have time and post back :)

adesklets is proud to be hosted on:

SourceForge.net Logo

Back to adesklets.sf.net.