Hi Jens,
Jens Luedicke [20/01/02 20:34 +0100]:
> hi ...
>
> - Ruby's nil is incompatible with Perl's undef (it will crash your script)
This appears to work:
----8<----
use Data::Dumper;
use Inline Ruby => <<END;
def return_nil
nil
end
END
print Dumper return_nil();
---->8----
Can you send me an example that demonstrates the incompatibility?
> - There are delays, even if there is already an _Inline/ directory
If I delete the _Inline directory, and run this script through Inline
twice, I get these results:
----8<----
use Inline Ruby => 'require "tk"';
TkButton->new(undef,{text=>'hello',command=>sub{print"hello\n"}})->pack;
TkButton->new(undef,{text=>'quit',command=>'exit'})->pack;
---->8----
ttul:~/dev/cpan/Inline-Ruby$ rm -rf _Inline/
ttul:~/dev/cpan/Inline-Ruby$ time perl -Mblib t.pl
Using /home/nwatkiss/dev/cpan/Inline-Ruby/blib
6.28user 0.23system 0:06.64elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1031major+3112minor)pagefaults 0swaps
ttul:~/dev/cpan/Inline-Ruby$ time perl -Mblib t.pl
Using /home/nwatkiss/dev/cpan/Inline-Ruby/blib
4.34user 0.16system 0:04.60elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (635major+2085minor)pagefaults 0swaps
ttul:~/dev/cpan/Inline-Ruby$
Remember that the Ruby interpreter still has to actually parse the script
every single time your run it. Inline::Ruby doesn't have to search for
defined functions after the first run. So the difference in speed won't be
the same as a compiled language like Inline::C or Inline::CPP.
That said, I'm sure the code can be optimized. I haven't put the code through
any kind of profiler to see where most of the time is being spent. Maybe you
should first do that, and see if it's Perl that is working really hard, or
Inline::Ruby, or just Ruby. That might narrow down the scope a little.
> - There are strange segfaults
This is the very first release, ALPHA and all that. Can you send me a script
that periodically crashes?
Thanks for the bug reports,
Neil
