perl.xs http://www.nntp.perl.org/group/perl.xs/ ... Copyright 1998-2017 perl.org Sat, 25 Mar 2017 07:43:00 +0000 ask@perl.org Topics for C::Blocks Advent? by David Mertens Hello everyone,<br/><br/>Many of you are probably aware that I&#39;ve been attempting to write an Advent<br/>Calendar for C::Blocks this year. While I&#39;ve fallen woefully behind, I&#39;m<br/>having a lot of fun and I still plan on writing 24 entries overall. I have<br/>a slate of topics to get me to 24 topics. I will be happy to alter these<br/>planned topics if anybody had questions about C::Blocks that might serve as<br/>good topics for an Advent entry. Please let me know!<br/><br/>In case you are not sure about what I&#39;m talking about, I introduce the<br/>library on Day 1,<br/>http://blogs.perl.org/users/david_mertens/2016/12/cblocks-advent-day-1.html.<br/>A reasonably useful synopsis of the whole calendar can be found in my<br/>December archives: http://blogs.perl.org/users/david_mertens/2016/12/.<br/><br/>Thanks!<br/>David<br/><br/>-- <br/> &quot;Debugging is twice as hard as writing the code in the first place.<br/> Therefore, if you write the code as cleverly as possible, you are,<br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2016/12/msg2806.html Sat, 24 Dec 2016 04:02:01 +0000 RE: loadable library and perl binaries are mismatched by bulk 88 <br/> <br/>---------------------------------------- <br/>&gt; To: perl-xs@perl.org <br/>&gt; Subject: loadable library and perl binaries are mismatched <br/>&gt; From: esquel@sommarskog.se <br/>&gt; Date: Wed, 13 Jul 2016 18:18:24 +0200 <br/>&gt; <br/>&gt; I have an XS module to permit Perl scripts access SQL Server through OLE DB. <br/>&gt; Besides a source-code only distribution, I also maintain a binary <br/>&gt; distribution for ActivePerl and for 5.18 and 5.20 I have also supported <br/>&gt; Strawberry Perl. <br/>&gt; <br/>&gt; Up to Perl 5.16 it was easy - since ActivePerl was labeled to have been <br/>&gt; built with Visual Studio (MSVC), I could build my module with Visual <br/>&gt; Studio as well. <br/>&gt; <br/>&gt; With Perl 5.18, ActiveState switched to gcc. What I did was to build Perl <br/>&gt; from sources with MSVC and build my module in that Perl environment. The <br/>&gt; binary produced runs well with ActivePerl and Strawberry Perl. <br/>&gt; <br/>&gt; I am not trying to redo that stunt with Perl 5.22 and 5.24 and it works <br/>&gt; for 64-bit Perl. However, for 32-bit Perl, I get this error message when <br/>&gt; I try to invoke the module on ActivePerl or Strawberry Perl 5.22: <br/>&gt; <br/>&gt; SqlServer.c: loadable library and perl binaries are mismatched (got <br/>&gt; handshake key 0B080080, needed 0AF00080) <br/>&gt; <br/>&gt; (The error message for 5.24 is the same, but with different handshake <br/>&gt; keys.) <br/>&gt; <br/> <br/>Your XS DLL and perl core do not agree on -D options, or the config.h files used to compile both are different. Perl XS DLLs/SOs are not binary compatible with anything but the perl binary that built them. The high 16 bits of the handshake key are the size of the interp struct. Your XS module and perl core do NOT agree on where the memory offsets for various members in the interp struct are. <br/> http://www.nntp.perl.org/group/perl.xs/2016/07/msg2805.html Fri, 15 Jul 2016 12:40:57 +0000 Re: loadable library and perl binaries are mismatched by Erland Sommarskog Erland Sommarskog (esquel@sommarskog.se) writes:<br/>&gt; (sisyphus1@optusnet.com.au) writes:<br/>&gt;&gt; Looking at <br/>&gt;&gt; http://cpansearch.perl.org/src/SOMMAR/Win32-SqlServer-2.009/makefile.pl,<br/>&gt;&gt; I can see that you do mess with CCFLAGS, but it looks like <br/>&gt;&gt; -DPERL_IMPLICIT_SYS will still be there. Maybe there&#39;s another missing<br/>&gt;&gt; (crucial) flag introduced by your change to CCFLAGS. <br/>&gt; <br/>&gt; Could be. I might give it try. I meddle with the flags to link the<br/>&gt; run-time library statically, so that I don&#39;t have distribute them<br/>&gt; with the binary. And there is some change for the optimizer flags,<br/>&gt; because else one of my test cases fails for reasons I don&#39;t understand.<br/><br/>I tried to disable my alterations, but this lead to a number of unresolved<br/>symbols when linking and I gave it up.<br/><br/>In any case, notice that the problem is not to get the module to run<br/>with the Perl I build it under. The problem is to get the binary to<br/>run with other Perls built for the same platform.<br/> <br/>&gt;&gt; XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK is something I haven&#39;t <br/>&gt;&gt; previously encountered. Is there some documentation that suggests that<br/>&gt;&gt; defining it to 1 is a valid thing to do ? <br/>&gt; <br/>&gt; I don&#39;t think so. I figured out by reading the source code in XSUB.h. I<br/>&gt; guess it could break in any release, including 5.24 which I have not<br/>&gt; tested yet.<br/><br/>I have now tested with 5.24 and the same trick works there too.<br/> <br/>In case someone else find this thread in the future, I should point out<br/>there are several BOOTCHECK macros that all lead to Perl_xs_handshake <br/>which implements this handshake check. I found that the macro above is<br/>the one that applied to my code by looking at the generated CPP code.<br/><br/>So if you run into this, and can&#39;t find no other way to work around it,<br/>you will need to look what XS produces and in XSUB.h to figure out<br/>what to do. But first check that you don&#39;t have any major flag mismatch<br/>like PERL_IMPLICIT_SYS like sisyphus had. And don&#39;t be surprised if<br/>you kill the check like I did, that things to crash boom bang later.<br/>It has worked for me ...so far.<br/><br/>-- <br/>Erland Sommarskog, Stockholm, esquel@sommarskog.se<br/> http://www.nntp.perl.org/group/perl.xs/2016/07/msg2804.html Fri, 15 Jul 2016 11:56:11 +0000 Re: loadable library and perl binaries are mismatched by Erland Sommarskog (sisyphus1@optusnet.com.au) writes:<br/>&gt; I struck a similar problem a while back:<br/>&gt; http://www.nntp.perl.org/group/perl.perl5.porters/2015/06/msg228601.html<br/>&gt; <br/>&gt; Turned out my problem there was that the Makefile.PL was setting CCFLAGS<br/>&gt; incorrectly (though it was only perl-5.22.0 and later that were<br/>&gt; affected). As kmx had discovered in<br/>&gt; https://github.com/tsee/extutils-cppguess/issues/9, it was the missing<br/>&gt; -DPERL_IMPLICIT_SYS that was the problem. <br/><br/>I think I saw that thread when googling the problem.<br/><br/>&gt; Looking at <br/>&gt; http://cpansearch.perl.org/src/SOMMAR/Win32-SqlServer-2.009/makefile.pl, I <br/>&gt; can see that you do mess with CCFLAGS, but it looks like <br/>&gt; -DPERL_IMPLICIT_SYS will still be there.<br/>&gt; Maybe there&#39;s another missing (crucial) flag introduced by your change to <br/>&gt; CCFLAGS.<br/><br/>Could be. I might give it try. I meddle with the flags to link the<br/>run-time library statically, so that I don&#39;t have distribute them<br/>with the binary. And there is some change for the optimizer flags,<br/>because else one of my test cases fails for reasons I don&#39;t understand.<br/><br/>&gt; XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK is something I haven&#39;t<br/>&gt; previously encountered. <br/>&gt; Is there some documentation that suggests that defining it to 1 is a valid <br/>&gt; thing to do ?<br/> <br/>I don&#39;t think so. I figured out by reading the source code in XSUB.h. I<br/>guess it could break in any release, including 5.24 which I have not<br/>tested yet.<br/><br/><br/><br/>-- <br/>Erland Sommarskog, Stockholm, esquel@sommarskog.se<br/> http://www.nntp.perl.org/group/perl.xs/2016/07/msg2803.html Thu, 14 Jul 2016 07:13:20 +0000 Re: loadable library and perl binaries are mismatched by sisyphus1 -----Original Message----- <br/>From: Erland Sommarskog<br/>Sent: Thursday, July 14, 2016 2:18 AM<br/>To: perl-xs@perl.org<br/>Subject: loadable library and perl binaries are mismatched<br/><br/>&gt; I have an XS module to permit Perl scripts access SQL Server through OLE <br/>&gt; DB.<br/>&gt; Besides a source-code only distribution, I also maintain a binary <br/>&gt; distribution for ActivePerl and for 5.18 and 5.20 I have also supported <br/>&gt; Strawberry Perl.<br/>&gt;<br/>&gt; Up to Perl 5.16 it was easy - since ActivePerl was labeled to have been <br/>&gt; built with Visual Studio (MSVC), I could build my module with Visual <br/>&gt; Studio as well.<br/>&gt;<br/>&gt; With Perl 5.18, ActiveState switched to gcc. What I did was to build Perl <br/>&gt; from sources with MSVC and build my module in that Perl environment. The <br/>&gt; binary produced runs well with ActivePerl and Strawberry Perl.<br/>&gt;<br/>&gt; I am not trying to redo that stunt with Perl 5.22 and 5.24 and it works <br/>&gt; for 64-bit Perl. However, for 32-bit Perl, I get this error message when I <br/>&gt; try to invoke the module on ActivePerl or Strawberry Perl 5.22:<br/>&gt;<br/>&gt; SqlServer.c: loadable library and perl binaries are mismatched (got <br/>&gt; handshake key 0B080080, needed 0AF00080)<br/>&gt;<br/>&gt; (The error message for 5.24 is the same, but with different handshake <br/>&gt; keys.)<br/>&gt;<br/>&gt; I&#39;ve tried to identify the configuration differences, and I note that <br/>&gt; perl -V reports longblkind=0 for the Perl that I&#39;ve built with MSVC, while <br/>&gt; for ActivePerl the setting is 3. There are a few more differences, but <br/>&gt; these difference apply to 5.20 as well.<br/>&gt;<br/>&gt; I also note that there is a new feature in Perl 5.22 with USE_LONG_DOUBLE <br/>&gt; which is said not to be supported with MSVC. Am I right to suspect that <br/>&gt; this setting is the culprit?<br/><br/>That won&#39;t matter so long as nvtype/nvsize for the perl that builds your <br/>binary distribution matches the nvtype/nvsize of the perl on which that <br/>distro is being run. (Otherwise you have &quot;binary incompatibility&quot; - which <br/>will produce a different error.)<br/><br/>I struck a similar problem a while back:<br/>http://www.nntp.perl.org/group/perl.perl5.porters/2015/06/msg228601.html<br/><br/>Turned out my problem there was that the Makefile.PL was setting CCFLAGS <br/>incorrectly (though it was only perl-5.22.0 and later that were affected).<br/>As kmx had discovered in https://github.com/tsee/extutils-cppguess/issues/9, <br/>it was the missing -DPERL_IMPLICIT_SYS that was the problem.<br/><br/>Looking at <br/>http://cpansearch.perl.org/src/SOMMAR/Win32-SqlServer-2.009/makefile.pl, I <br/>can see that you do mess with CCFLAGS, but it looks like -DPERL_IMPLICIT_SYS <br/>will still be there.<br/>Maybe there&#39;s another missing (crucial) flag introduced by your change to <br/>CCFLAGS.<br/>Or maybe you&#39;ve hit an entirely different issue.<br/><br/>XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK is something I haven&#39;t previously <br/>encountered.<br/>Is there some documentation that suggests that defining it to 1 is a valid <br/>thing to do ?<br/><br/>Cheers,<br/>Rob <br/><br/> http://www.nntp.perl.org/group/perl.xs/2016/07/msg2802.html Thu, 14 Jul 2016 00:54:54 +0000 Re: loadable library and perl binaries are mismatched by Elizabeth Mattijsen Erland, <br/> <br/>&gt; On 13 Jul 2016, at 21:52, Erland Sommarskog &lt;esquel@sommarskog.se&gt; wrote: <br/>&gt; <br/>&gt; OK, so I found out that this handshake test is new to 5.22. That explains <br/>&gt; why it does not fail on 5.20. :-) <br/>&gt; <br/>&gt; Furthermore, I find that if I add this line to my .XS file: <br/>&gt; <br/>&gt; #define XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK 1 <br/>&gt; <br/>&gt; I circumvent the check, and after this I&#39;m able to run my DLL with <br/>&gt; ActivePerl. <br/>&gt; <br/>&gt; I still appreciate any hints to build my Perl so that I don&#39;t have to <br/>&gt; do this. <br/> <br/>This list is pretty dead, in my experience. Maybe you will have a better chance of getting an answer on p5p (perl5-porters@perl.org) . <br/> <br/> <br/>Liz http://www.nntp.perl.org/group/perl.xs/2016/07/msg2801.html Wed, 13 Jul 2016 19:55:04 +0000 Re: loadable library and perl binaries are mismatched by Erland Sommarskog OK, so I found out that this handshake test is new to 5.22. That explains<br/>why it does not fail on 5.20. :-)<br/><br/>Furthermore, I find that if I add this line to my .XS file:<br/><br/>#define XS_BOTHVERSION_SETXSUBFN_POPMARK_BOOTCHECK 1<br/><br/>I circumvent the check, and after this I&#39;m able to run my DLL with<br/>ActivePerl.<br/><br/>I still appreciate any hints to build my Perl so that I don&#39;t have to<br/>do this.<br/><br/><br/>-- <br/>Erland Sommarskog, Stockholm, esquel@sommarskog.se<br/> http://www.nntp.perl.org/group/perl.xs/2016/07/msg2800.html Wed, 13 Jul 2016 19:52:53 +0000 loadable library and perl binaries are mismatched by Erland Sommarskog I have an XS module to permit Perl scripts access SQL Server through OLE DB. <br/>Besides a source-code only distribution, I also maintain a binary <br/>distribution for ActivePerl and for 5.18 and 5.20 I have also supported<br/>Strawberry Perl.<br/><br/>Up to Perl 5.16 it was easy - since ActivePerl was labeled to have been<br/>built with Visual Studio (MSVC), I could build my module with Visual <br/>Studio as well.<br/><br/>With Perl 5.18, ActiveState switched to gcc. What I did was to build Perl<br/>from sources with MSVC and build my module in that Perl environment. The <br/>binary produced runs well with ActivePerl and Strawberry Perl.<br/><br/>I am not trying to redo that stunt with Perl 5.22 and 5.24 and it works<br/>for 64-bit Perl. However, for 32-bit Perl, I get this error message when<br/>I try to invoke the module on ActivePerl or Strawberry Perl 5.22:<br/><br/>SqlServer.c: loadable library and perl binaries are mismatched (got <br/>handshake key 0B080080, needed 0AF00080)<br/><br/>(The error message for 5.24 is the same, but with different handshake <br/>keys.)<br/><br/>I&#39;ve tried to identify the configuration differences, and I note that <br/>perl -V reports longblkind=0 for the Perl that I&#39;ve built with MSVC, <br/>while for ActivePerl the setting is 3. There are a few more differences,<br/>but these difference apply to 5.20 as well.<br/><br/>I also note that there is a new feature in Perl 5.22 with USE_LONG_DOUBLE<br/>which is said not to be supported with MSVC. Am I right to suspect that<br/>this setting is the culprit?<br/><br/>Before anyone suggests that I should build my module with gcc, this is <br/>not really an option for the moment. My expertise is with SQL Server,<br/>not with C++, and using gcc is way outside my comfort zone, and I am<br/>not even sure that gcc groks the include file needed - it may be <br/>peppered with MS-only syntax. A more likely option is simply not to<br/>provide binary modules for 32-bit Perl for 5.2[24].<br/><br/>-- <br/>Erland Sommarskog, Stockholm, esquel@sommarskog.se<br/> http://www.nntp.perl.org/group/perl.xs/2016/07/msg2799.html Wed, 13 Jul 2016 16:18:28 +0000 Re: Seeking more help figuring out test failures by Shlomi Fish Hi David, <br/> <br/>On Mon, 25 Apr 2016 11:29:53 -0400 <br/>David Mertens &lt;dcmertens.perl@gmail.com&gt; wrote: <br/> <br/>&gt; Hi Shlomi, <br/>&gt; <br/>&gt; Thank you very much! <br/> <br/>You&#39;re welcome. Good luck in getting this to work. <br/> <br/> Shlomi <br/> <br/>&gt; I have been working with 32-bit windows in virtualbox. <br/>&gt; I will try to get a 64-bit setup going to see if that is the source of the <br/>&gt; trouble. <br/>&gt; <br/>&gt; Any other reports or help would be much appreciated! <br/>&gt; David <br/> <br/> <br/> <br/>-- <br/>----------------------------------------------------------------- <br/>Shlomi Fish http://www.shlomifish.org/ <br/>List of Networking Clients - http://shlom.in/net-clients <br/> <br/>Chuck Norris doesn&#39;t celebrate holidays -- holidays celebrate Chuck Norris. <br/>(By sevvie: http://sevvie.github.io/ .) <br/> &mdash; http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ <br/> <br/>Please reply to list if it&#39;s a mailing list post - http://shlom.in/reply . <br/> http://www.nntp.perl.org/group/perl.xs/2016/04/msg2798.html Mon, 25 Apr 2016 16:07:39 +0000 Re: Help setting up appveyor for Windows continuous integrationtesting by David Mertens Hello Rob,<br/><br/>Thanks for all of this work! I&#39;ll go through all of this at various points<br/>throughout the week, so I may send a couple of follow-up emails later.<br/><br/>Thanks!<br/>David<br/><br/>On Sun, Apr 24, 2016 at 8:05 PM, &lt;sisyphus1@optusnet.com.au&gt; wrote:<br/><br/>&gt; From: David Mertens<br/>&gt; Sent: Monday, April 25, 2016 7:16 AM<br/>&gt; To: perl-xs@perl.org<br/>&gt; Subject: Help setting up appveyor for Windows continuous integration<br/>&gt; testing<br/>&gt; Hello everyone,<br/>&gt;<br/>&gt; The specific tcc error (given at<br/>&gt;&gt; https://ci.appveyor.com/project/run4flat/c-blocks/build/1.0.17#L47) is:<br/>&gt;&gt;<br/>&gt;&gt; C:/STRAWB~1/perl/lib/CORE/perl.h:2708: error: &#39;;&#39; expected (got<br/>&gt;&gt; &quot;perl_os_thread&quot;)<br/>&gt;&gt;<br/>&gt;<br/>&gt; What does line 2708 of perl.h contain ?<br/>&gt; I get a very similar type of error when building C-Blocks-0.03 on Windows<br/>&gt; (perl-5.16, mingw.org build of gcc-4.7.0):<br/>&gt;<br/>&gt; Building C-Blocks<br/>&gt; Creating lib/C/Blocks/PerlAPI.xs<br/>&gt; In file included from perl_h_QSJqVkp1.c:15:<br/>&gt; In file included from C:/Mingw/perl516/lib/CORE/perl.h:610:<br/>&gt; C:/MinGW/include/sys/types.h:27: error: &#39;;&#39; expected (got &quot;__time32_t&quot;)<br/>&gt;<br/>&gt; where line 27 is:<br/>&gt;<br/>&gt; typedef __int32 __time32_t;<br/>&gt;<br/>&gt; My first thought was that perl might be doing something incompatible with<br/>&gt; the __int32 symbol, as there&#39;s no problem with a C program that #includes<br/>&gt; sys/types.h.<br/>&gt; But #including sys/types.h into an Inline::C script is also fine, so I<br/>&gt; think it&#39;s unlikely that perl is the culprit<br/>&gt;<br/>&gt; Moving on .... I don&#39;t get that error when I switch to perl-522, which<br/>&gt; uses the gcc-4.9.2 compiler provided by mingw-w64 project (different<br/>&gt; vendor).<br/>&gt; Indeed, this compiler doesn&#39;t typedef __int32 at all.<br/>&gt;<br/>&gt; However, with this combo, the C-Blocks-0.03 build fails with:<br/>&gt;<br/>&gt; Building C-Blocks<br/>&gt; Creating lib/C/Blocks/PerlAPI.xs<br/>&gt; In file included from perl_h_Xd9p6ge7.c:15:<br/>&gt; In file included from C:/MinGW/perl522_64int/lib/CORE/perl.h:699:<br/>&gt; In file included from<br/>&gt; C:/_32/gcc-straw-492/i686-w64-mingw32/include/sys/types.h:13:<br/>&gt; In file included from<br/>&gt; C:/_32/gcc-straw-492/i686-w64-mingw32/include/crtdefs.h:10:<br/>&gt; In file included from<br/>&gt; C:/_32/gcc-straw-492/i686-w64-mingw32/include/_mingw.h:275:<br/>&gt; C:/_32/gcc-straw-492/i686-w64-mingw32/include/vadefs.h:35: error: #error<br/>&gt; VARARGS not implemented for this compiler<br/>&gt; Unable to serialize the header file<br/>&gt;<br/>&gt; The error implies that the symbol __WIDL__ has not been defined.<br/>&gt; It looks to me (not entirely certain) that __WIDL__ is normally *not*<br/>&gt; defined for me.<br/>&gt;<br/>&gt; Does anybody know what&#39;s going on?<br/>&gt;&gt;<br/>&gt;<br/>&gt; Not me.<br/>&gt; Note that these errors are being obtained just running &quot;cpan -i<br/>&gt; C::Blocks&quot;. Appveyor is not involved (unless, of course, it&#39;s being called<br/>&gt; in as part of the cpan build).<br/>&gt;<br/>&gt; One other odd thing:<br/>&gt; I had to set the CPATH environment variable to the location of winsock2.h<br/>&gt; - otherwise that header could not be located.<br/>&gt; In both C and Inline::C scripts that header is in the default search path<br/>&gt; - and gets #included fine.<br/>&gt;<br/>&gt; Here&#39;s the error:<br/>&gt;<br/>&gt; Building C-Blocks<br/>&gt; Creating lib/C/Blocks/PerlAPI.xs<br/>&gt; In file included from perl_h_Yryks05Z.c:15:<br/>&gt; In file included from C:/MinGW/perl522_64int/lib/CORE/perl.h:3060:<br/>&gt; In file included from C:/MinGW/perl522_64int/lib/CORE/win32thread.h:4:<br/>&gt; C:/MinGW/perl522_64int/lib/CORE/win32.h:131: warning: WIN32_LEAN_AND_MEAN<br/>&gt; redefined<br/>&gt; In file included from perl_h_Yryks05Z.c:15:<br/>&gt; In file included from C:/MinGW/perl522_64int/lib/CORE/perl.h:3060:<br/>&gt; In file included from C:/MinGW/perl522_64int/lib/CORE/win32thread.h:4:<br/>&gt; In file included from C:/MinGW/perl522_64int/lib/CORE/win32.h:419:<br/>&gt; C:/MinGW/perl522_64int/lib/CORE/sys/socket.h:21: error: include file<br/>&gt; &#39;winsock2.h&#39; not found<br/>&gt; Unable to serialize the header file<br/>&gt; lib/C/Blocks/PerlAPI.xs.PL failed at<br/>&gt; C:/MinGW/perl522_64int/site/lib/Module/Build/Base.pm line 2930.<br/>&gt;<br/>&gt; I just noticed that setting CPATH also removes the &quot;WIN32_LEAN_AND_MEAN&quot;<br/>&gt; redefinition warning.<br/>&gt; Also, win32.h #includes windows.h - and I *think* (could check if it&#39;s<br/>&gt; important) that should be enough to get winsock2.h #included.<br/>&gt; Something is not quite right.<br/>&gt;<br/>&gt; Cheers,<br/>&gt; Rob<br/>&gt;<br/><br/><br/><br/>-- <br/> &quot;Debugging is twice as hard as writing the code in the first place.<br/> Therefore, if you write the code as cleverly as possible, you are,<br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2016/04/msg2797.html Mon, 25 Apr 2016 15:33:37 +0000 Re: Seeking more help figuring out test failures by David Mertens Hi Shlomi, <br/> <br/>Thank you very much! I have been working with 32-bit windows in virtualbox. <br/>I will try to get a 64-bit setup going to see if that is the source of the <br/>trouble. <br/> <br/>Any other reports or help would be much appreciated! <br/>David <br/> <br/>On Mon, Apr 25, 2016 at 9:04 AM, Shlomi Fish &lt;shlomif@shlomifish.org&gt; wrote: <br/> <br/>&gt; Hi David, <br/>&gt; <br/>&gt; On Sun, 24 Apr 2016 18:57:25 -0400 <br/>&gt; David Mertens &lt;dcmertens.perl@gmail.com&gt; wrote: <br/>&gt; <br/>&gt; &gt; Hello everyone, <br/>&gt; &gt; <br/>&gt; &gt; My work with Alien::TinyCCx gives errors on appveyor ( <br/>&gt; &gt; https://ci.appveyor.com/project/run4flat/alien-tinyccx/build/1.0.7). I <br/>&gt; &gt; cannot reproduce these errors on my own setup. If you have a Windows <br/>&gt; &gt; machine, I would appreciate if you could try to run the test suite for <br/>&gt; &gt; Alien::TinyCCx. (I just pushed v0.08 to CPAN, but you can also get it <br/>&gt; from <br/>&gt; &gt; github at https://github.com/run4flat/Alien-TinyCCx). If you can <br/>&gt; reproduce <br/>&gt; &gt; the errors seen on appveyor, I&#39;d like to know about your setup. <br/>&gt; &gt; <br/>&gt; <br/>&gt; I am getting these test failures on a Windows 7 x86-64 Professional <br/>&gt; VirtualBox VM with strawberry perl 5.22.1.3: <br/>&gt; <br/>&gt; http://www.shlomifish.org/Files/files/images/alien-tinyccx.png <br/>&gt; <br/>&gt; Getting to the point where I was able to run this was time consuming <br/>&gt; because it <br/>&gt; involved installing many updates (VBox guest additions, Windows Update, <br/>&gt; Strawberry Perl, etc.). I hate Windows. <br/>&gt; <br/>&gt; Regards, <br/>&gt; <br/>&gt; Shlomi Fish <br/>&gt; <br/>&gt; &gt; Thanks! <br/>&gt; &gt; David <br/>&gt; &gt; <br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt; -- <br/>&gt; ----------------------------------------------------------------- <br/>&gt; Shlomi Fish http://www.shlomifish.org/ <br/>&gt; Parody of &quot;The Fountainhead&quot; - http://shlom.in/towtf <br/>&gt; <br/>&gt; &lt;Su-Shee&gt; Botje: &ldquo;you can&rsquo;t kill Botje&rdquo; isn&rsquo;t Newton&rsquo;s first law. <br/>&gt; &lt;Su-Shee&gt; It&rsquo;s not even the 5th. <br/>&gt; &mdash; http://www.shlomifish.org/humour/fortunes/sharp-perl.html <br/>&gt; <br/>&gt; Please reply to list if it&#39;s a mailing list post - http://shlom.in/reply . <br/>&gt; <br/> <br/> <br/> <br/>-- <br/> &quot;Debugging is twice as hard as writing the code in the first place. <br/> Therefore, if you write the code as cleverly as possible, you are, <br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2016/04/msg2796.html Mon, 25 Apr 2016 15:30:02 +0000 Re: Seeking more help figuring out test failures by Shlomi Fish Hi David, <br/> <br/>On Sun, 24 Apr 2016 18:57:25 -0400 <br/>David Mertens &lt;dcmertens.perl@gmail.com&gt; wrote: <br/> <br/>&gt; Hello everyone, <br/>&gt; <br/>&gt; My work with Alien::TinyCCx gives errors on appveyor ( <br/>&gt; https://ci.appveyor.com/project/run4flat/alien-tinyccx/build/1.0.7). I <br/>&gt; cannot reproduce these errors on my own setup. If you have a Windows <br/>&gt; machine, I would appreciate if you could try to run the test suite for <br/>&gt; Alien::TinyCCx. (I just pushed v0.08 to CPAN, but you can also get it from <br/>&gt; github at https://github.com/run4flat/Alien-TinyCCx). If you can reproduce <br/>&gt; the errors seen on appveyor, I&#39;d like to know about your setup. <br/>&gt; <br/> <br/>I am getting these test failures on a Windows 7 x86-64 Professional <br/>VirtualBox VM with strawberry perl 5.22.1.3: <br/> <br/>http://www.shlomifish.org/Files/files/images/alien-tinyccx.png <br/> <br/>Getting to the point where I was able to run this was time consuming because it <br/>involved installing many updates (VBox guest additions, Windows Update, <br/>Strawberry Perl, etc.). I hate Windows. <br/> <br/>Regards, <br/> <br/> Shlomi Fish <br/> <br/>&gt; Thanks! <br/>&gt; David <br/>&gt; <br/> <br/> <br/> <br/>-- <br/>----------------------------------------------------------------- <br/>Shlomi Fish http://www.shlomifish.org/ <br/>Parody of &quot;The Fountainhead&quot; - http://shlom.in/towtf <br/> <br/> &lt;Su-Shee&gt; Botje: &ldquo;you can&rsquo;t kill Botje&rdquo; isn&rsquo;t Newton&rsquo;s first law. <br/> &lt;Su-Shee&gt; It&rsquo;s not even the 5th. <br/> &mdash; http://www.shlomifish.org/humour/fortunes/sharp-perl.html <br/> <br/>Please reply to list if it&#39;s a mailing list post - http://shlom.in/reply . <br/> http://www.nntp.perl.org/group/perl.xs/2016/04/msg2795.html Mon, 25 Apr 2016 13:09:30 +0000 Re: Help setting up appveyor for Windows continuous integrationtesting by sisyphus1 From: David Mertens<br/>Sent: Monday, April 25, 2016 7:16 AM<br/>To: perl-xs@perl.org<br/>Subject: Help setting up appveyor for Windows continuous integration testing<br/>Hello everyone,<br/><br/>&gt; The specific tcc error (given at <br/>&gt; https://ci.appveyor.com/project/run4flat/c-blocks/build/1.0.17#L47) is:<br/>&gt;<br/>&gt; C:/STRAWB~1/perl/lib/CORE/perl.h:2708: error: &#39;;&#39; expected (got <br/>&gt; &quot;perl_os_thread&quot;)<br/><br/>What does line 2708 of perl.h contain ?<br/>I get a very similar type of error when building C-Blocks-0.03 on Windows <br/>(perl-5.16, mingw.org build of gcc-4.7.0):<br/><br/>Building C-Blocks<br/>Creating lib/C/Blocks/PerlAPI.xs<br/>In file included from perl_h_QSJqVkp1.c:15:<br/>In file included from C:/Mingw/perl516/lib/CORE/perl.h:610:<br/>C:/MinGW/include/sys/types.h:27: error: &#39;;&#39; expected (got &quot;__time32_t&quot;)<br/><br/>where line 27 is:<br/><br/>typedef __int32 __time32_t;<br/><br/>My first thought was that perl might be doing something incompatible with <br/>the __int32 symbol, as there&#39;s no problem with a C program that #includes <br/>sys/types.h.<br/>But #including sys/types.h into an Inline::C script is also fine, so I think <br/>it&#39;s unlikely that perl is the culprit<br/><br/>Moving on .... I don&#39;t get that error when I switch to perl-522, which uses <br/>the gcc-4.9.2 compiler provided by mingw-w64 project (different vendor).<br/>Indeed, this compiler doesn&#39;t typedef __int32 at all.<br/><br/>However, with this combo, the C-Blocks-0.03 build fails with:<br/><br/>Building C-Blocks<br/>Creating lib/C/Blocks/PerlAPI.xs<br/>In file included from perl_h_Xd9p6ge7.c:15:<br/>In file included from C:/MinGW/perl522_64int/lib/CORE/perl.h:699:<br/>In file included from <br/>C:/_32/gcc-straw-492/i686-w64-mingw32/include/sys/types.h:13:<br/>In file included from <br/>C:/_32/gcc-straw-492/i686-w64-mingw32/include/crtdefs.h:10:<br/>In file included from <br/>C:/_32/gcc-straw-492/i686-w64-mingw32/include/_mingw.h:275:<br/>C:/_32/gcc-straw-492/i686-w64-mingw32/include/vadefs.h:35: error: #error <br/>VARARGS not implemented for this compiler<br/>Unable to serialize the header file<br/><br/>The error implies that the symbol __WIDL__ has not been defined.<br/>It looks to me (not entirely certain) that __WIDL__ is normally *not* <br/>defined for me.<br/><br/>&gt; Does anybody know what&#39;s going on?<br/><br/>Not me.<br/>Note that these errors are being obtained just running &quot;cpan -i C::Blocks&quot;. <br/>Appveyor is not involved (unless, of course, it&#39;s being called in as part of <br/>the cpan build).<br/><br/>One other odd thing:<br/>I had to set the CPATH environment variable to the location of winsock2.h - <br/>otherwise that header could not be located.<br/>In both C and Inline::C scripts that header is in the default search path - <br/>and gets #included fine.<br/><br/>Here&#39;s the error:<br/><br/>Building C-Blocks<br/>Creating lib/C/Blocks/PerlAPI.xs<br/>In file included from perl_h_Yryks05Z.c:15:<br/>In file included from C:/MinGW/perl522_64int/lib/CORE/perl.h:3060:<br/>In file included from C:/MinGW/perl522_64int/lib/CORE/win32thread.h:4:<br/>C:/MinGW/perl522_64int/lib/CORE/win32.h:131: warning: WIN32_LEAN_AND_MEAN <br/>redefined<br/>In file included from perl_h_Yryks05Z.c:15:<br/>In file included from C:/MinGW/perl522_64int/lib/CORE/perl.h:3060:<br/>In file included from C:/MinGW/perl522_64int/lib/CORE/win32thread.h:4:<br/>In file included from C:/MinGW/perl522_64int/lib/CORE/win32.h:419:<br/>C:/MinGW/perl522_64int/lib/CORE/sys/socket.h:21: error: include file <br/>&#39;winsock2.h&#39; not found<br/>Unable to serialize the header file<br/>lib/C/Blocks/PerlAPI.xs.PL failed at <br/>C:/MinGW/perl522_64int/site/lib/Module/Build/Base.pm line 2930.<br/><br/>I just noticed that setting CPATH also removes the &quot;WIN32_LEAN_AND_MEAN&quot; <br/>redefinition warning.<br/>Also, win32.h #includes windows.h - and I *think* (could check if it&#39;s <br/>important) that should be enough to get winsock2.h #included.<br/>Something is not quite right.<br/><br/>Cheers,<br/>Rob <br/><br/> http://www.nntp.perl.org/group/perl.xs/2016/04/msg2794.html Mon, 25 Apr 2016 00:05:58 +0000 Seeking more help figuring out test failures by David Mertens Hello everyone,<br/><br/>My work with Alien::TinyCCx gives errors on appveyor (<br/>https://ci.appveyor.com/project/run4flat/alien-tinyccx/build/1.0.7). I<br/>cannot reproduce these errors on my own setup. If you have a Windows<br/>machine, I would appreciate if you could try to run the test suite for<br/>Alien::TinyCCx. (I just pushed v0.08 to CPAN, but you can also get it from<br/>github at https://github.com/run4flat/Alien-TinyCCx). If you can reproduce<br/>the errors seen on appveyor, I&#39;d like to know about your setup.<br/><br/>Thanks!<br/>David<br/><br/>-- <br/> &quot;Debugging is twice as hard as writing the code in the first place.<br/> Therefore, if you write the code as cleverly as possible, you are,<br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2016/04/msg2793.html Sun, 24 Apr 2016 22:57:35 +0000 Help setting up appveyor for Windows continuous integration testing by David Mertens Hello everyone,<br/><br/>I am making fairly steady progress on C::Blocks. I recently decided to set<br/>up Windows continuous integration for my projects using appveyor. (I plan<br/>to soon set up Mac CI using a &quot;generic&quot; language on Mac... wish me luck.)<br/><br/>My problem is that on my own testing virtualbox environment, I get<br/>successful builds and test passes for C::Blocks, but appveyor seems to<br/>encounter trouble. The specific tcc error (given at<br/>https://ci.appveyor.com/project/run4flat/c-blocks/build/1.0.17#L47) is:<br/><br/> C:/STRAWB~1/perl/lib/CORE/perl.h:2708: error: &#39;;&#39; expected (got<br/>&quot;perl_os_thread&quot;)<br/><br/>Does anybody know what&#39;s going on? I suspect it could be a missing<br/>command-line argument or define for the call to tcc (i.e. -D...), but I<br/>figured I would check if others had encountered an error such as this<br/>before.<br/><br/>Thanks!<br/>David<br/><br/>P. S. As far as I can tell, C::Blocks works on Windows and Linux. It might<br/>also work on Mac, but it&#39;s been a while since I checked that very carefully<br/>and I cannot speak with certainty. Feel free to give it a spin and let me<br/>know what you think!<br/><br/>-- <br/> &quot;Debugging is twice as hard as writing the code in the first place.<br/> Therefore, if you write the code as cleverly as possible, you are,<br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2016/04/msg2792.html Sun, 24 Apr 2016 21:16:52 +0000 Re: librbd ports to perl by Yonghua Peng Thanks a lot. I will check them.<br/><br/><br/>On 2015/11/16 &#x661F;&#x671F;&#x4E00; 13:34, Ben Bullock wrote:<br/>&gt; On 15 November 2015 at 09:02, Yonghua Peng &lt;pyh@cloud-china.org&gt; wrote:<br/>&gt;<br/>&gt;&gt; There are ruby/java/python/go ports for librbd (ceph&#39;s rados block device,<br/>&gt;&gt; see ceph.com), but there isn&#39;t perl&#39;s.<br/>&gt;&gt;<br/>&gt;&gt; For example,<br/>&gt;&gt;<br/>&gt;&gt; python&#39;s -<br/>&gt;&gt; https://github.com/ceph/ceph/blob/v0.48.2argonaut/src/pybind/rbd.py<br/>&gt;&gt;<br/>&gt;&gt; ruby&#39;s -<br/>&gt;&gt; https://github.com/ceph/ceph-ruby/blob/master/lib/ceph-ruby/lib/rbd.rb<br/>&gt;&gt;<br/>&gt;&gt; Can you show me how to ports that into perl language? I just want to create<br/>&gt;&gt; a module called Ceph::Lib::Rbd.<br/>&gt;<br/>&gt; If you want to just do like that Python or Ruby does, you can use Perl<br/>&gt; modules like<br/>&gt;<br/>&gt; https://metacpan.org/pod/FFI<br/>&gt; https://metacpan.org/pod/FFI::Raw<br/>&gt; https://metacpan.org/pod/FFI::Platypus<br/>&gt;<br/>&gt; (I have never tried these modules, but I looked at the Ruby and Python<br/>&gt; code and wondered if the FFI thing was on CPAN, and found the above.<br/>&gt; It seems like the Raw and Platypus versions have several votes.)<br/>&gt;<br/>&gt; Perl XS is quite tricky since it requires understanding Perl internals<br/>&gt; like reference counting.<br/>&gt;<br/> http://www.nntp.perl.org/group/perl.xs/2015/11/msg2791.html Mon, 16 Nov 2015 05:43:03 +0000 Re: librbd ports to perl by Ben Bullock On 15 November 2015 at 09:02, Yonghua Peng &lt;pyh@cloud-china.org&gt; wrote:<br/><br/>&gt; There are ruby/java/python/go ports for librbd (ceph&#39;s rados block device,<br/>&gt; see ceph.com), but there isn&#39;t perl&#39;s.<br/>&gt;<br/>&gt; For example,<br/>&gt;<br/>&gt; python&#39;s -<br/>&gt; https://github.com/ceph/ceph/blob/v0.48.2argonaut/src/pybind/rbd.py<br/>&gt;<br/>&gt; ruby&#39;s -<br/>&gt; https://github.com/ceph/ceph-ruby/blob/master/lib/ceph-ruby/lib/rbd.rb<br/>&gt;<br/>&gt; Can you show me how to ports that into perl language? I just want to create<br/>&gt; a module called Ceph::Lib::Rbd.<br/><br/>If you want to just do like that Python or Ruby does, you can use Perl<br/>modules like<br/><br/>https://metacpan.org/pod/FFI<br/>https://metacpan.org/pod/FFI::Raw<br/>https://metacpan.org/pod/FFI::Platypus<br/><br/>(I have never tried these modules, but I looked at the Ruby and Python<br/>code and wondered if the FFI thing was on CPAN, and found the above.<br/>It seems like the Raw and Platypus versions have several votes.)<br/><br/>Perl XS is quite tricky since it requires understanding Perl internals<br/>like reference counting.<br/> http://www.nntp.perl.org/group/perl.xs/2015/11/msg2790.html Mon, 16 Nov 2015 05:34:59 +0000 Re: librbd ports to perl by Sawyer X On Sun, Nov 15, 2015 at 1:02 AM, Yonghua Peng &lt;pyh@cloud-china.org&gt; wrote:<br/>&gt; Hello,<br/>&gt;<br/>&gt; There are ruby/java/python/go ports for librbd (ceph&#39;s rados block device,<br/>&gt; see ceph.com), but there isn&#39;t perl&#39;s.<br/>&gt;<br/>&gt; For example,<br/>&gt;<br/>&gt; python&#39;s -<br/>&gt; https://github.com/ceph/ceph/blob/v0.48.2argonaut/src/pybind/rbd.py<br/>&gt;<br/>&gt; ruby&#39;s -<br/>&gt; https://github.com/ceph/ceph-ruby/blob/master/lib/ceph-ruby/lib/rbd.rb<br/>&gt;<br/>&gt; Can you show me how to ports that into perl language? I just want to create<br/>&gt; a module called Ceph::Lib::Rbd.<br/><br/>There isn&#39;t one single way, and unfortunately there isn&#39;t an exact<br/>guide that shows how to write any possible bindings.<br/><br/>You can use the following guides:<br/>* http://perldoc.perl.org/perlxs.html<br/>* http://www.lemoda.net/xs/index.html<br/>* https://github.com/xsawyerx/xs-fun/<br/><br/>You will need to think of the interface. For example, the questions:<br/>* How will the API look like?<br/>* Should I use objects?<br/>* Do I use &quot;magic&quot; to store the details?<br/>* etc.<br/><br/>Otherwise, great stuff. Good luck! :)<br/> http://www.nntp.perl.org/group/perl.xs/2015/11/msg2789.html Sun, 15 Nov 2015 14:22:57 +0000 librbd ports to perl by Yonghua Peng Hello,<br/><br/>There are ruby/java/python/go ports for librbd (ceph&#39;s rados block device, see<br/>ceph.com), but there isn&#39;t perl&#39;s.<br/><br/>For example,<br/><br/>python&#39;s - https://github.com/ceph/ceph/blob/v0.48.2argonaut/src/pybind/rbd.py<br/><br/>ruby&#39;s - https://github.com/ceph/ceph-ruby/blob/master/lib/ceph-ruby/lib/rbd.rb<br/><br/>Can you show me how to ports that into perl language? I just want to create a<br/>module called Ceph::Lib::Rbd.<br/><br/>Thanks. http://www.nntp.perl.org/group/perl.xs/2015/11/msg2788.html Sun, 15 Nov 2015 00:02:57 +0000 Re: Announcing C::Blocks, a different way to interface Perl and C code by David Mertens A follow-up to this email:<br/><br/>On Fri, May 23, 2014 at 8:35 AM, David Mertens &lt;dcmertens.perl@gmail.com&gt;<br/>wrote:<br/><br/>&gt; Hey everyone,<br/>&gt;<br/>&gt; C::Blocks is a new TinyCC-based module, presently only available on<br/>&gt; github. (1) It jit-compiles blocks of C code, building and inserting OPs<br/>&gt; into the Perl OP tree, making invocation of C code essentially free. (2) It<br/>&gt; will allow different blocks of C code to share function and struct<br/>&gt; declarations, thus removing the need to always recompile perl.h, an<br/>&gt; otherwise major cost of jit-compiling C code that can interface with Perl<br/>&gt; and Perl data structures.<br/>&gt;<br/>&gt; I am currently seeking help and encouragement to squash the segfaults that<br/>&gt; currently prevent the completion of the second feature. :-)<br/>&gt;<br/><br/>It took a lot longer than I had expected, but I finally completed the<br/>second feature listed above and released the first &quot;alpha&quot; release of<br/>C::Blocks &lt;https://metacpan.org/pod/C::Blocks&gt; today.<br/><br/>It took a long time because ultimately I had to create my own fork of the<br/>Tiny C Compiler &lt;https://github.com/run4flat/tinycc&gt; that supports extended<br/>symbol tables. I released an Alien distribution<br/>&lt;https://metacpan.org/pod/Alien::TinyCCx&gt; with (what I believe to be a<br/>nearly complete implementation of) extended symbol table support late last<br/>week, and it seems to be passing its test suite decently well<br/>&lt;http://matrix.cpantesters.org/?dist=Alien-TinyCCx+0.06&gt; on a fair number<br/>of platforms. Alien::TinyCCx is doing particularly well on Linux and decent<br/>on Windows. I&#39;m a bit annoyed it&#39;s not passing on Macs because it works on<br/>my Mac. That&#39;ll get fixed soonish, I hope.<br/><br/>It&#39;s still rough around the edges, but it&#39;s surprisingly fast. I have a<br/>number of examples<br/>&lt;https://metacpan.org/source/DCMERTENS/C-Blocks-0.01/examples&gt; that might<br/>give you an idea of how it works. I am particularly fond of my &quot;port&quot;<br/>&lt;https://metacpan.org/source/DCMERTENS/C-Blocks-0.01/examples/libobjmg.pl&gt;<br/>of XS::Object::Magic &lt;https://metacpan.org/pod/XS::Object::Magic&gt;, which<br/>simply involved copying the top half of rafl&#39;s code from his Magic.xs<br/>&lt;https://metacpan.org/source/FLORA/XS-Object-Magic-0.04/Magic.xs&gt; file into<br/>a cshare block.<br/><br/>I plan to write more about it on blogs.perl.org, so I would encourage folks<br/>to check there if interested.<br/><br/>David http://www.nntp.perl.org/group/perl.xs/2015/08/msg2787.html Tue, 04 Aug 2015 00:53:41 +0000 Re: perlembed: Interrupt call_pv by Fedor Sumkin Hello everyone! <br/> <br/>I am using Perl to embed it in C application, I need to have an ability to <br/>interrupt Perl function which <br/>have been invoked with `call_pv`. As function is invoked, it is blocking <br/>thread where it is running. <br/> <br/>So, I see the only way to interrupt this blocking thread - via killing this <br/>thread with native &quot;thread kill&quot; functionality. <br/> <br/>But killing this thread results on program crash( (F)atal error -- Can&#39;t <br/>undef active subroutine during global destruction) <br/>and this can&#39;t be handled with exceptions or via other way. <br/> <br/>I am looking for correct way of handling the interruption of running perl <br/>function in C. <br/>So, is there any appropriate way to do this? <br/> <br/>Regards, <br/>Fedor <br/> <br/>On Sat, Jul 25, 2015 at 3:06 PM, Fedor Sumkin &lt;qosys.net@gmail.com&gt; wrote: <br/> <br/>&gt; Hello Shlomi, <br/>&gt; <br/>&gt; Thanks for your suggestion, I&#39;ll duplicate question to perl-xs and will <br/>&gt; try to answer to your second question in next reply. <br/>&gt; <br/>&gt; Regards, <br/>&gt; Fedor <br/>&gt; <br/>&gt; On Sat, Jul 25, 2015 at 12:23 PM, Shlomi Fish &lt;shlomif@shlomifish.org&gt; <br/>&gt; wrote: <br/>&gt; <br/>&gt;&gt; Hi Fedor, <br/>&gt;&gt; <br/>&gt;&gt; On Fri, 24 Jul 2015 15:17:58 +0300 <br/>&gt;&gt; Fedor Sumkin &lt;qosys.net@gmail.com&gt; wrote: <br/>&gt;&gt; <br/>&gt;&gt; &gt; Hello, <br/>&gt;&gt; &gt; <br/>&gt;&gt; &gt; I am using Perl to embed it in C application( <br/>&gt;&gt; &gt; http://perldoc.perl.org/perlembed.html). <br/>&gt;&gt; &gt; <br/>&gt;&gt; &gt; I need to have a possibility to interrupt perl function invoked from C <br/>&gt;&gt; code <br/>&gt;&gt; &gt; via `call_pv`/`call_*` methods. <br/>&gt;&gt; &gt; <br/>&gt;&gt; &gt; I tried achieving this via destroying running perl context, but this <br/>&gt;&gt; &gt; resulted on fatal error &quot;Can&#39;t undef active subroutine during global <br/>&gt;&gt; &gt; destruction&quot;. <br/>&gt;&gt; &gt; <br/>&gt;&gt; &gt; So, how can I interrupt running perl func from C? <br/>&gt;&gt; &gt; <br/>&gt;&gt; <br/>&gt;&gt; Two notes: <br/>&gt;&gt; <br/>&gt;&gt; 1. XS/C-ext/C-embed/etc. are likely out of the scope of <br/>&gt;&gt; beginners@perl.org . <br/>&gt;&gt; You may have better luck here: http://lists.perl.org/list/perl-xs.html . <br/>&gt;&gt; <br/>&gt;&gt; 2. It&#39;s not clear to me from reading your message what exactly your issue <br/>&gt;&gt; is. <br/>&gt;&gt; Can you explain? <br/>&gt;&gt; <br/>&gt;&gt; Regards, <br/>&gt;&gt; <br/>&gt;&gt; Shlomi Fish <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; -- <br/>&gt;&gt; ----------------------------------------------------------------- <br/>&gt;&gt; Shlomi Fish http://www.shlomifish.org/ <br/>&gt;&gt; The Case for File Swapping - http://shlom.in/file-swap <br/>&gt;&gt; <br/>&gt;&gt; Chuck Norris can end world hunger, but he thinks that hungry people make <br/>&gt;&gt; humanity a more challenging adversary. <br/>&gt;&gt; &mdash; http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/ <br/>&gt;&gt; <br/>&gt;&gt; Please reply to list if it&#39;s a mailing list post - http://shlom.in/reply <br/>&gt;&gt; . <br/>&gt;&gt; <br/>&gt;&gt; -- <br/>&gt;&gt; To unsubscribe, e-mail: beginners-unsubscribe@perl.org <br/>&gt;&gt; For additional commands, e-mail: beginners-help@perl.org <br/>&gt;&gt; http://learn.perl.org/ <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt;&gt; <br/>&gt; http://www.nntp.perl.org/group/perl.xs/2015/07/msg2786.html Sat, 25 Jul 2015 18:28:29 +0000 NSF Grant Solicitation in Computational Physics due Dec 3 by David Mertens Hey everyone,<br/><br/>The National Science Foundation (United States) just put out a solicitation<br/>for Computational Physics. I will be moving in the middle of 2016 and am<br/>considering another postdoc, so I wouldn&#39;t be eligible as a PI (i.e. I<br/>would not be eligible to take a grant with me if I happened to win one).<br/>But, I might be interested in helping prepare a grant if our research<br/>interests and/or tools line up well.<br/><br/>According to the solicitation:<br/><br/>Computational Physics (CP) supports research for computational and<br/>&gt; data-enabled science. The program emphasizes novel methods for<br/>&gt; high-performance computing that require significant code development.<br/>&gt; Priority will be given to proposals that, in addition to compelling<br/>&gt; scientific goals, have a computational advance or new enabling capability.<br/>&gt; Proposals should include either innovation in computing, such as algorithm<br/>&gt; development and efficient use of novel architectures, or provide<br/>&gt; significant improvement to community codes.<br/><br/><br/>http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=505206&amp;WT.mc_id=USNSF_25<br/><br/>I would like to note that my work on C::Blocks<br/>&lt;https://github.com/run4flat/C-Blocks&gt; (embedding a C JIT compiler in the<br/>Perl parser) is nearing alpha stage and will soon see the first public<br/>release to CPAN. If the presence of a fast C jit compiler would strengthen<br/>your NSF proposal, I&#39;d be happy to discuss the work in greater depth.<br/><br/>David<br/><br/>-- <br/> &quot;Debugging is twice as hard as writing the code in the first place.<br/> Therefore, if you write the code as cleverly as possible, you are,<br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2015/04/msg2785.html Wed, 29 Apr 2015 19:37:17 +0000 Want to redirect the Perl stdout and stderr by JR Heisey Greetings,<br/><br/>I have a command line Perl application.<br/>I am embedding that Perl application into a GUI application.<br/><br/>I have stdout redirect using<br/><br/>tie *SIMOUT, &quot;MyStdOutPackage&quot;;<br/><br/>Sometimes I have an issue when starting up the .pl file since I am <br/>modifying it for this usage.<br/><br/>I want to redirect Perl&#39;s stdio before I call perl_parse() using the <br/>PerlApi.<br/><br/>I found PerlIO_define_layer() which takes PerlIO_funcs pointer.<br/>So this is the only thing I found that comes close.<br/>However I don&#39;t see the PerlIO_funcs structure defined anywhere so I <br/>cannot provide my own implementation.<br/><br/>I am stumped. Is this even possible?<br/><br/>Thanks,<br/>J.R. Heisey<br/> http://www.nntp.perl.org/group/perl.xs/2015/04/msg2784.html Mon, 06 Apr 2015 17:33:48 +0000 RE: Exposing Perl objects in C by bulk 88 <br/> <br/>&gt; To: perl-xs@perl.org <br/>&gt; Date: Wed, 4 Mar 2015 18:18:29 +0100 <br/>&gt; From: jrheisey@synaptics.com <br/>&gt; Subject: Exposing Perl objects in C <br/>&gt; <br/>&gt; Hi, <br/>&gt; <br/>&gt; I have a collection of Perl objects in an application. <br/>&gt; I want a C program to have access to the data in these objects. <br/>&gt; The objects are implemented as a package <br/>&gt; <br/>&gt; The C application wants an object handle with which it can make C <br/>&gt; function calls and pass the object handle. <br/>&gt; <br/>&gt; I have limited experience writing to the PerlApi, etc. I was hoping that <br/>&gt; each perl SV has some unique identifier (UID). The goal is to retrieve <br/>&gt; the UID, pass it as an integer or void * so I don&#39;t need to manage my <br/>&gt; own list of Perl objects. <br/> <br/>The SV* is your UID. You can cast SV*s to void *s and back. The SV * should probably be the inner HV* of your ref to blessed hash (typical perl object). Unless your C library is so badly designed that a plugin&#39;s object handle/opaque pointer must be 16 or 32 bits on a 64 bit machine, there is no reason on why not to use the SV* as the opaque handle. <br/> <br/>&gt; I realize I could create new SV * and increment the reference count. <br/>&gt; I would then need to keep track of these SV pointers in order to clean <br/>&gt; them up later. <br/> <br/>Each refcount notch on a SV* must have an identifiable owner. In an XSUB, the caller of the xsub owns the SV*. When you return SV*s on perl stack, the mortal stack usually owns a notch. You may also return a package level SV *, without ++, then mortaling it, since the package tree owns the notch. In some cases, a non-perl-core C struct will be the owner of the SV* notch, in that case, it is upto you to destroy that C struct, and its members (once of which is a SV *) at the correct time. <br/> <br/>&gt; <br/>&gt; I would hoping I could use a UID to create temporary SV * objects, <br/>&gt; perform a data access then decrement the reference count. <br/>&gt; <br/>&gt; void get_dataInt(FOO * foo, int * value) <br/>&gt; { <br/>&gt; // abbreviated Perl stack stuff <br/>&gt; SV * pOjbect = newSV_VooDoo((someVooDooCast)foo); // a 32 bit value <br/>&gt; if I am lucky <br/>&gt; XPUSHs(sv_2mortal(pObject)); <br/>&gt; PUTBACK; <br/>&gt; count = call_method(&quot;getData&quot;, G_EVAL | G_SCALAR); <br/>&gt; <br/>&gt; // error checking stuff <br/>&gt; *value = POPi; <br/>&gt; } <br/>&gt; <br/>&gt; Or something conceptually like that. <br/>&gt; <br/>&gt; With out this I need to allocate my own C object with which to capture a <br/>&gt; reference to the underlying Perl objects. <br/> <br/>That code sample has many flaws <br/> <br/>read the flowchart at http://perldoc.perl.org/perlcall.html#Using-Perl-to-Dispose-of-Temporaries and if that flowchart doesn&#39;t match what you need to do, explain the flowchart/callstack that your perl module will have to us. I rewrote your code with many comments. <br/> <br/>void get_dataInt(FOO * foo, int * value) <br/>{ <br/>//required, otherwise wont compile with perl threads <br/>dTHX; <br/>//required, otherwise you have no perl stack pointer to do a SOMETHING_PUSH_OSMETHING on <br/>dSP; <br/>//required (unless you know what you are doing and you <br/>//probably dont as a beginner), enter new perl scops <br/>ENTER; <br/>SAVETEMPS; <br/>//X required since I (bulk88) dont know what the caller is, and therefore cant <br/>//compute minimum free space on perl stack, so use X to be safe <br/>//also dont mess around with converting a number to a pointer through a lookup <br/>//table, make the object &quot;handle&quot; be the SV*, the C library wont care, its just <br/>//an opaque pointer right? <br/>XPUSHs((SV*)foo); <br/>PUTBACK; <br/>count = call_method(&quot;getData&quot;, G_EVAL | G_SCALAR); <br/>//you forgot SPAGAIN <br/>SPAGAIN; <br/>// error checking stuff <br/>*value = POPi; <br/>//pop the mortal and save stack scops we push earlier, this has to be done <br/>//after the POPi, since FREETMPS will free everything on our frame on Perl stack <br/>FREETMPS; <br/>LEAVE; <br/>} <br/> <br/> = http://www.nntp.perl.org/group/perl.xs/2015/03/msg2783.html Thu, 05 Mar 2015 01:53:44 +0000 Exposing Perl objects in C by JR Heisey Hi,<br/><br/>I have a collection of Perl objects in an application.<br/>I want a C program to have access to the data in these objects.<br/>The objects are implemented as a package<br/><br/>The C application wants an object handle with which it can make C <br/>function calls and pass the object handle.<br/><br/>I have limited experience writing to the PerlApi, etc. I was hoping that <br/>each perl SV has some unique identifier (UID). The goal is to retrieve <br/>the UID, pass it as an integer or void * so I don&#39;t need to manage my <br/>own list of Perl objects.<br/><br/>I realize I could create new SV * and increment the reference count.<br/>I would then need to keep track of these SV pointers in order to clean <br/>them up later.<br/><br/>I would hoping I could use a UID to create temporary SV * objects, <br/>perform a data access then decrement the reference count.<br/><br/>void get_dataInt(FOO * foo, int * value)<br/>{<br/> // abbreviated Perl stack stuff<br/> SV * pOjbect = newSV_VooDoo((someVooDooCast)foo); // a 32 bit value <br/>if I am lucky<br/> XPUSHs(sv_2mortal(pObject));<br/> PUTBACK;<br/> count = call_method(&quot;getData&quot;, G_EVAL | G_SCALAR);<br/><br/> // error checking stuff<br/> *value = POPi;<br/>}<br/><br/>Or something conceptually like that.<br/><br/>With out this I need to allocate my own C object with which to capture a <br/>reference to the underlying Perl objects.<br/><br/>Thanks,<br/>J.R.<br/> http://www.nntp.perl.org/group/perl.xs/2015/03/msg2782.html Wed, 04 Mar 2015 17:18:39 +0000 Re: Two XS modules linked to one .a library. by sisyphus1 <br/>From: Bill Moseley<br/>Sent: Wednesday, October 01, 2014 1:12 AM<br/>To: perl-xs@perl.org<br/>Subject: Re: Two XS modules linked to one .a library.<br/><br/>&gt; Just to clarify I was meaning the symbols in the shared third-party .a <br/>&gt; library.<br/><br/>Afterthought:<br/><br/>The 3rd party .a library is not really &quot;shared&quot;.<br/>When you build a module against it, the .a library&#39;s functionality gets <br/>incorporated into the functionality of the module&#39;s .so file.<br/>After the build, you can rename the .a file or entirely remove it from the <br/>system, and the module will remain fully functional.<br/><br/>Cheers,<br/>Rob<br/><br/> http://www.nntp.perl.org/group/perl.xs/2014/10/msg2781.html Wed, 01 Oct 2014 01:50:22 +0000 Re: Two XS modules linked to one .a library. by sisyphus1 <br/>From: Bill Moseley<br/>Sent: Wednesday, October 01, 2014 1:12 AM<br/>To: perl-xs@perl.org<br/>Subject: Re: Two XS modules linked to one .a library.<br/><br/>&gt; Just to clarify I was meaning the symbols in the shared third-party .a <br/>&gt; library. Where two separate Perl (XS) modules link to the same static .a <br/>&gt; library and those two Perl modules are then used in the same program.<br/><br/>Yep - that&#39;s as I took it to be.<br/>Neither of those perl modules knows (nor needs to know) anything about the <br/>contents of the other module&#39;s .so.<br/>The linking to the .a library is all done when the module is compiled. As <br/>long as that worked, your only concern is avoiding having both modules <br/>export a sub of the same name - in which case you&#39;ll get a &quot;subroutine <br/>redefined&quot; warning, anyway (if you&#39;ve turned warnings on).<br/><br/>&gt; We are going to try and get the .a library built as a .so file (or really <br/>&gt; many .so libraries). As it is right now it&#39;s kind of a beast so the <br/>&gt; resulting Perl XS-build .so files are quite big. Seems like a cleaner <br/>&gt; approach, and that would allow patching the third-party library w/o having <br/>&gt; to rebuild the Perl modules.<br/><br/>One interesting side note about using 2 perl modules (that access the same <br/>library) being used in the *same process*:<br/><br/>Let&#39;s call the modules FOO and BAR, and assume they both contain a <br/>set_global() function and a get_global() function.<br/>The set_global() function sets a *C library* global to some value, and the <br/>get_global() function returns the current value of that library global.<br/><br/>If you&#39;ve built both FOO and BAR against a static library, then altering the <br/>value of the global by running FOO::set_global($newval) won&#39;t have any <br/>effect on the value returned by BAR::get_global(), which will remain <br/>unchanged. (And vice-versa.)<br/>But if you&#39;ve built FOO and BAR against a shared library, then both <br/>BAR::get_global() and FOO::get_global() will always return identical <br/>values - and the value returned will be whatever the most recent <br/>set_global() call specified (irrespective of which module made that call).<br/><br/>If your modules happen to both be capable of setting a particular library <br/>global, you should be able to verify that quite easily.<br/><br/>Of course, if both FOO and BAR are being run in separate processes, then <br/>there&#39;s no such issue. (Not sure what happens when FOO and BAR, built <br/>against the same shared library, are run in different threads of the same <br/>process ... I&#39;m guessing it might depend upon the thread-safety of the <br/>shared library.)<br/><br/>Math::GSL is one module where this is a consideration. There&#39;s an option to <br/>set an error handling global - but that turns out to be not at all global if <br/>Math::GSL is built against a static gsl library, because all of the <br/>Math::GSL sub-modules have their own .so linked to the static gsl library. <br/>This is just like the situation you&#39;ve outlined for your current setup, <br/>except Math::GSL has about 30 modules, not just 2.<br/><br/>Cheers,<br/>Rob <br/><br/> http://www.nntp.perl.org/group/perl.xs/2014/10/msg2780.html Wed, 01 Oct 2014 01:14:57 +0000 Re: Two XS modules linked to one .a library. by Bill Moseley On Tue, Sep 30, 2014 at 7:36 AM, &lt;sisyphus1@optusnet.com.au&gt; wrote:<br/><br/>&gt;<br/>&gt; No.<br/>&gt; It should not be possible for the set up you described to result in a<br/>&gt; &quot;clash&quot; of XS symbols, no matter how hard you try. The XS symbols are<br/>&gt; private to both modules - it doesn&#39;t matter if identical symbols exist.<br/>&gt;<br/><br/>Thanks for the quick reply, Rob.<br/><br/>Just to clarify I was meaning the symbols in the shared third-party .a<br/>library. Where two separate Perl (XS) modules link to the same static .a<br/>library and those two Perl modules are then used in the same program.<br/><br/>We are going to try and get the .a library built as a .so file (or really<br/>many .so libraries). As it is right now it&#39;s kind of a beast so the<br/>resulting Perl XS-build .so files are quite big. Seems like a cleaner<br/>approach, and that would allow patching the third-party library w/o having<br/>to rebuild the Perl modules.<br/><br/>Thanks again.<br/><br/><br/>-- <br/>Bill Moseley<br/>moseley@hank.org http://www.nntp.perl.org/group/perl.xs/2014/09/msg2779.html Tue, 30 Sep 2014 15:13:19 +0000 Re: Two XS modules linked to one .a library. by sisyphus1 <br/>From: Bill Moseley<br/>Sent: Tuesday, September 30, 2014 10:39 PM<br/><br/>&gt; Is there potential for symbols to &quot;clash&quot; in this situation?<br/><br/>No.<br/>It should not be possible for the set up you described to result in a <br/>&quot;clash&quot; of XS symbols, no matter how hard you try. The XS symbols are <br/>private to both modules - it doesn&#39;t matter if identical symbols exist.<br/><br/>IIUC, you&#39;d have to have one module&#39;s .so also load the other module&#39;s .so <br/>(which, I think, can be achieved using ExtUtils::Depends in the build <br/>process) in order to stand a chance of creating a clash.<br/><br/>Cheers,<br/>Rob <br/><br/> http://www.nntp.perl.org/group/perl.xs/2014/09/msg2778.html Tue, 30 Sep 2014 14:37:38 +0000 Two XS modules linked to one .a library. by Bill Moseley I have a simple, if not basic, question.<br/><br/>We have a static archive (*.a) library provided to us that we have written<br/>an XS interface for. So, the resulting .so that XS builds contains that<br/>library (or whatever the linker decided to include, I suppose).<br/><br/>New functionality was added to that static library and we created a<br/>*separate* XS module for just that functionality. It also pulls in much<br/>(all?) of that .a library when building the Perl XS .so module.<br/><br/>Is there potential for symbols to &quot;clash&quot; in this situation? Or is that<br/>not a problem as long as the .a library was compiled with -fPIC?<br/><br/>We are using both the XS Perl modules in the same process and seems to work<br/>fine. So, not sure if that is just luck or if there&#39;s no problem doing<br/>this.<br/><br/>If we can get the library rebuilt as a .so would that make much of a<br/>difference?<br/><br/><br/>I&#39;m running on CentOS and non-threaded Perl, if that makes a difference.<br/><br/>Thanks,<br/><br/><br/>-- <br/>Bill Moseley<br/>moseley@hank.org http://www.nntp.perl.org/group/perl.xs/2014/09/msg2777.html Tue, 30 Sep 2014 12:39:56 +0000 How to combine "embedded Perl" and XS to call from Perl to C? by Manuel Reimer Hello,<br/><br/>there are good examples on how to embed perl:<br/><br/>http://perldoc.perl.org/perlembed.html<br/><br/>And there are good examples on how to use XS:<br/><br/>http://perldoc.perl.org/perlxstut.html<br/><br/>My problem: The first tutorial only shows how to call from C to Perl and <br/>the second one only shows how to call C functions and libraries.<br/><br/>What I&#39;m searching for is some example that shows how I can allow my <br/>embedded Perl interpreter to call functions in the C code that embeds <br/>the interpreter.<br/><br/>My idea is to embed an interpreter into some application that only <br/>allows plugins to be written in C. This application offers some header <br/>files that have to be used by plugin developers. The resulting plugin is <br/>a &quot;.so&quot; file which is loaded by the main application.<br/><br/>I guess embedding the interpreter will not really be a big deal and even <br/>calling from &quot;main application&quot; into the loaded Perl script seems to be <br/>pretty easy. The problem is that I somehow have to expose the API, <br/>described by the header files, into my Perl script, to allow the Perl <br/>code to call functions in the C API provided by the main application.<br/><br/>Maybe the second problem will be that the API is written in C++, but <br/>maybe I&#39;ll just wrap this into a function oriented interface if it is <br/>too difficult to expose a C++ class to Perl code.<br/><br/>Can someone give me some information on how to do this?<br/><br/>Thank you very much in advance.<br/><br/>Greetings,<br/><br/>Manuel<br/> http://www.nntp.perl.org/group/perl.xs/2014/08/msg2776.html Sat, 23 Aug 2014 09:06:51 +0000 RE: How to use sv_dup_inc() ? by Jeremy Hi, <br/>Not sure if this helps or not: <br/>Are the contexts across threads? Are the contexts using a different instance of the interpreter that created the SV&#39;s? If the answer is yes to either, then you will have problems. <br/>I use a similar design approach in one of my apps (the contexts are running in different threads and interpreters) and the only way I could get this working was to serialize the data before sending it over (I used storable to serialize , which I call from XS). The contexts are connected together with C based event queues. <br/>I was using an old version of Perl, so perhaps things have changed... <br/>Regards, <br/> <br/> <br/>Date: Tue, 22 Jul 2014 10:17:28 +0200 <br/>From: tristan.darricau@inria.fr <br/>To: perl-xs@perl.org <br/>Subject: How to use sv_dup_inc() ? <br/> <br/>Hi, <br/>I am working on a XS module in which I have to transmit and share data between multiples contexts. <br/>To simplify, this system is constructed around two methods: <br/> - send(&lt;name&gt;, &lt;data&gt;) <br/> - receive(&lt;name&gt;) : &lt;data&gt; <br/>Send and receive are called from two different contexts and the destination context can&#39;t be known in advance. (I have the insurance that the data will be used in the destination context before the destruction of the sender context). <br/>In my initial code I have some problems of double free during the destruction of the contexts (panic: free from wrong pool). I think that I have to use sv_dup_inc() to solve this issue but I may have miss something because I get a Seg. fault in S_ptr_table_find (tbl=0x0, sv=0xa0b5a8) at sv.c:12197 <br/>So could you help me to find how to use sv_dup_inc() correctly? <br/> <br/>Thanks! <br/>Tristan = http://www.nntp.perl.org/group/perl.xs/2014/07/msg2775.html Tue, 22 Jul 2014 09:00:09 +0000 How to use sv_dup_inc() ? by Tristan Darricau Hi, <br/><br/>I am working on a XS module in which I have to transmit and share data between multiples contexts. <br/>To simplify, this system is constructed around two methods: <br/>- send(&lt;name&gt;, &lt;data&gt;) <br/>- receive(&lt;name&gt;) : &lt;data&gt; <br/>Send and receive are called from two different contexts and the destination context can&#39;t be known in advance. <br/>(I have the insurance that the data will be used in the destination context before the destruction of the sender context). <br/><br/>In my initial code I have some problems of double free during the destruction of the contexts (panic: free from wrong pool). <br/>I think that I have to use sv_dup_inc() to solve this issue but I may have miss something because I get a Seg. fault in S_ptr_table_find (tbl=0x0, sv=0xa0b5a8) at sv.c:12197 <br/>So could you help me to find how to use sv_dup_inc() correctly? <br/><br/>Thanks! <br/>Tristan http://www.nntp.perl.org/group/perl.xs/2014/07/msg2774.html Tue, 22 Jul 2014 08:17:38 +0000 Re: Announcing C::Blocks, a different way to interface Perl and C code by David Mertens Thanks Rob, and thanks Ingy. Any and all words of encouragement are much<br/>appreciated.<br/><br/>By the way, it&#39;s possible to write a similar keyword-based wrapper for<br/>Inline::C. In fact, I plan to eventually build something like<br/>C::Blocks::Cache (or something like that) which generates a .xs and .pmc<br/>file from a single .pm file. In principle, one could then pass this along<br/>to the Inline machinery to compile.<br/><br/>Eventually. :-)<br/>David<br/><br/>On Fri, May 23, 2014 at 11:34 PM, &lt;sisyphus1@optusnet.com.au&gt; wrote:<br/><br/>&gt; Sounds pretty cool, David.<br/>&gt; A plodder like me is probably just going to stick with Inline, but it<br/>&gt; would be great to see C::Blocks takes off. And it has the attractiveness to<br/>&gt; do so.<br/>&gt; (I like the way you can so easily just plonk the C code right in there<br/>&gt; amongst the perl code .... makes Inline look not-so-inline :-)<br/>&gt;<br/>&gt; Cheers,<br/>&gt; Rob<br/>&gt;<br/>&gt; *From:* David Mertens &lt;dcmertens.perl@gmail.com&gt;<br/>&gt; *Sent:* Friday, May 23, 2014 10:35 PM<br/>&gt; *To:* perl-xs@perl.org ; Perl Inline Mail List &lt;inline@perl.org&gt;<br/>&gt; *Subject:* Announcing C::Blocks, a different way to interface Perl and C<br/>&gt; code<br/>&gt; Hey everyone,<br/>&gt;<br/>&gt; tl;dr: C::Blocks is a new TinyCC-based module, presently only available on<br/>&gt; github. (1) It jit-compiles blocks of C code, building and inserting OPs<br/>&gt; into the Perl OP tree, making invocation of C code essentially free. (2) It<br/>&gt; will allow different blocks of C code to share function and struct<br/>&gt; declarations, thus removing the need to always recompile perl.h, an<br/>&gt; otherwise major cost of jit-compiling C code that can interface with Perl<br/>&gt; and Perl data structures.<br/>&gt;<br/>&gt; I am currently seeking help and encouragement to squash the segfaults that<br/>&gt; currently prevent the completion of the second feature. :-)<br/>&gt;<br/>&gt; ----<br/>&gt;<br/>&gt; I like Perl, but I like C, too. I would like to be able to write and call<br/>&gt; C code from Perl in about as painless a way as possible. Inline::C is nice,<br/>&gt; as are XS::TCC and C::TinyCompiler, but we can do better. C::Blocks is my<br/>&gt; attempt to do better.<br/>&gt;<br/>&gt; *Pain point 1*. C code should be a first class citizen. With XS::TCC and<br/>&gt; C::TinyCompiler, you pass your code to the compiler via a string. With<br/>&gt; Inline::C, you either place your code at the bottom of your script in a<br/>&gt; __DATA__ section, or you enclose it in a string. Steffen&#39;s module is<br/>&gt; probably the most transparent in this sense. Still, working with an<br/>&gt; interface that requires me to compile a string to get my product feels the<br/>&gt; same as compiling a regex from a string. This is Perl! We can do better!<br/>&gt;<br/>&gt; C::Blocks does better by using a keyword parser hook. Blocks of code that<br/>&gt; you want executed are called like so:<br/>&gt;<br/>&gt; print &quot;Before cblock\n&quot;;<br/>&gt; cblock {<br/>&gt; printf(&quot;In cblock\n&quot;);<br/>&gt; }<br/>&gt; print &quot;After cblock\n&quot;;<br/>&gt;<br/>&gt; If stdio.h is included, you get the output<br/>&gt;<br/>&gt; Before cblock<br/>&gt; In cblock<br/>&gt; After cblock<br/>&gt;<br/>&gt; Because it uses a parser hook, the C code really is inline with your Perl<br/>&gt; code.<br/>&gt;<br/>&gt; *Pain point 2*. Calling C code should be obvious and cheap. All three<br/>&gt; modules discussed so far provide a mechanism for calling C functions. This<br/>&gt; means that for a simple, small operation, I must wrap my idea into a<br/>&gt; function one place and invoke it in another. Furthermore, if I want to<br/>&gt; repeatedly call a block of C code in a loop, I must define that block of<br/>&gt; code somewhere outside of the loop, potentially very far from the call<br/>&gt; site. C::TinyCompiler suffers further because it uses a complicated and<br/>&gt; rather slow calling mechanism.<br/>&gt;<br/>&gt; C::Blocks solves this by extracting and jit-compiling the C code at Perl<br/>&gt; parse time, generating an OP and inserting it into the Perl OP tree. This<br/>&gt; means that you can insert your C code exactly where you want it and not<br/>&gt; worry about repeated re-compiles. If you were to wrap the example given<br/>&gt; above in a for loop, you would see how this works.<br/>&gt;<br/>&gt; *Pain point 3*. Sharing C code should be as easy as sharing Perl code.<br/>&gt; C::TinyCompiler provides a fairly complex mechanism to allow modules to add<br/>&gt; declarations and symbols to a compiler context. Any string that uses that<br/>&gt; will need to recompile those declarations, however, tempting me to<br/>&gt; prematurely optimize by placing all of my C code in one giant string<br/>&gt; instead of interspersed among my Perl code. Neither XS::TCC nor Inline::C<br/>&gt; provide much (if any) automated machinery to share code.<br/>&gt;<br/>&gt; C::Blocks provides a mechanism to share function declarations, struct<br/>&gt; definitions, and other identifiers with other cblocks in the current<br/>&gt; lexical scope, as well as to share them on a per-package basis. It is even<br/>&gt; more versatile than normal Perl function scoping, allowing you to correctly<br/>&gt; correlate functionality with lexical scope. (It is also somewhat buggy, as<br/>&gt; discussed next.)<br/>&gt;<br/>&gt; *Pain point 4*. Changing C code should not cost anything. Inline::C can<br/>&gt; take seconds to recompile a changed set of C code. In contrast, there is no<br/>&gt; cost associated with changing code when using XS::TCC and C::TinyCompiler<br/>&gt; because they jit-compile their code. That comes at the cost, however, of<br/>&gt; always compiling everything each time you invoke your Perl script. If your<br/>&gt; C code needs the Perl C API, you will have to re-parse perl.h every time<br/>&gt; you *compile* a code block, which can happen many times with each<br/>&gt; execution of your script. Inline::C&#39;s caching mechanism provides a big win<br/>&gt; in that respect, unless you change your code. It would be nice if we could<br/>&gt; somehow cache the result of parsing ``#include &quot;perl.h&quot;&#39;&#39;.<br/>&gt;<br/>&gt; C::Blocks uses a fork of tcc that I&#39;ve been working on for many months<br/>&gt; aimed at allowing one compiler context to share its symbol table with other<br/>&gt; compiler contexts. This is related to the previous point. The sharing<br/>&gt; mechanism discussed in the previous point applies to preprocessor includes,<br/>&gt; so once I have compiled a block that uses the Perl headers, I can share all<br/>&gt; of those declarations with later compilation units, without recompiling. In<br/>&gt; future work, I plan to store these symbol tables to disk so that they don&#39;t<br/>&gt; even need to be re-parsed each time you run your script.<br/>&gt;<br/>&gt; ----<br/>&gt;<br/>&gt; C::Blocks currently addresses, completely, pain points 1 and 2 above. It<br/>&gt; has taken many months to hack on tcc to reach this point. I have now<br/>&gt; encountered some segfault-causing issues when trying to share code, yet I<br/>&gt; have a hard time reproducing those segfaults with direct tests on tcc. If<br/>&gt; you think this sounds like a cool project, I would appreciate some<br/>&gt; camaraderie as I try to dig into the internals of tcc. You can find me on<br/>&gt; perl&#39;s IRC network hanging out on #pdl, #xs, and #tinycc, among other<br/>&gt; channels. You can find my work at https://github.com/run4flat/C-Blocks<br/>&gt;<br/>&gt; If you would like to help out, let me know and I will give you a tour<br/>&gt; through the codebase. :-)<br/>&gt;<br/>&gt; Any help or encouragement would be much appreciated! Thanks!<br/>&gt; David<br/>&gt;<br/>&gt; --<br/>&gt; &quot;Debugging is twice as hard as writing the code in the first place.<br/>&gt; Therefore, if you write the code as cleverly as possible, you are,<br/>&gt; by definition, not smart enough to debug it.&quot; -- Brian Kernighan<br/>&gt;<br/><br/><br/><br/>-- <br/> &quot;Debugging is twice as hard as writing the code in the first place.<br/> Therefore, if you write the code as cleverly as possible, you are,<br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2014/05/msg2773.html Sat, 24 May 2014 11:08:28 +0000 Re: Announcing C::Blocks, a different way to interface Perl and C code by Ingy dot Net I for one welcome our new C::Blocks overlords! :-)<br/><br/><br/>On Fri, May 23, 2014 at 5:35 AM, David Mertens &lt;dcmertens.perl@gmail.com&gt;wrote:<br/><br/>&gt; Hey everyone,<br/>&gt;<br/>&gt; tl;dr: C::Blocks is a new TinyCC-based module, presently only available on<br/>&gt; github. (1) It jit-compiles blocks of C code, building and inserting OPs<br/>&gt; into the Perl OP tree, making invocation of C code essentially free. (2) It<br/>&gt; will allow different blocks of C code to share function and struct<br/>&gt; declarations, thus removing the need to always recompile perl.h, an<br/>&gt; otherwise major cost of jit-compiling C code that can interface with Perl<br/>&gt; and Perl data structures.<br/>&gt;<br/>&gt; I am currently seeking help and encouragement to squash the segfaults that<br/>&gt; currently prevent the completion of the second feature. :-)<br/>&gt;<br/>&gt; ----<br/>&gt;<br/>&gt; I like Perl, but I like C, too. I would like to be able to write and call<br/>&gt; C code from Perl in about as painless a way as possible. Inline::C is nice,<br/>&gt; as are XS::TCC and C::TinyCompiler, but we can do better. C::Blocks is my<br/>&gt; attempt to do better.<br/>&gt;<br/>&gt; *Pain point 1*. C code should be a first class citizen. With XS::TCC and<br/>&gt; C::TinyCompiler, you pass your code to the compiler via a string. With<br/>&gt; Inline::C, you either place your code at the bottom of your script in a<br/>&gt; __DATA__ section, or you enclose it in a string. Steffen&#39;s module is<br/>&gt; probably the most transparent in this sense. Still, working with an<br/>&gt; interface that requires me to compile a string to get my product feels the<br/>&gt; same as compiling a regex from a string. This is Perl! We can do better!<br/>&gt;<br/>&gt; C::Blocks does better by using a keyword parser hook. Blocks of code that<br/>&gt; you want executed are called like so:<br/>&gt;<br/>&gt; print &quot;Before cblock\n&quot;;<br/>&gt; cblock {<br/>&gt; printf(&quot;In cblock\n&quot;);<br/>&gt; }<br/>&gt; print &quot;After cblock\n&quot;;<br/>&gt;<br/>&gt; If stdio.h is included, you get the output<br/>&gt;<br/>&gt; Before cblock<br/>&gt; In cblock<br/>&gt; After cblock<br/>&gt;<br/>&gt; Because it uses a parser hook, the C code really is inline with your Perl<br/>&gt; code.<br/>&gt;<br/>&gt; *Pain point 2*. Calling C code should be obvious and cheap. All three<br/>&gt; modules discussed so far provide a mechanism for calling C functions. This<br/>&gt; means that for a simple, small operation, I must wrap my idea into a<br/>&gt; function one place and invoke it in another. Furthermore, if I want to<br/>&gt; repeatedly call a block of C code in a loop, I must define that block of<br/>&gt; code somewhere outside of the loop, potentially very far from the call<br/>&gt; site. C::TinyCompiler suffers further because it uses a complicated and<br/>&gt; rather slow calling mechanism.<br/>&gt;<br/>&gt; C::Blocks solves this by extracting and jit-compiling the C code at Perl<br/>&gt; parse time, generating an OP and inserting it into the Perl OP tree. This<br/>&gt; means that you can insert your C code exactly where you want it and not<br/>&gt; worry about repeated re-compiles. If you were to wrap the example given<br/>&gt; above in a for loop, you would see how this works.<br/>&gt;<br/>&gt; *Pain point 3*. Sharing C code should be as easy as sharing Perl code.<br/>&gt; C::TinyCompiler provides a fairly complex mechanism to allow modules to add<br/>&gt; declarations and symbols to a compiler context. Any string that uses that<br/>&gt; will need to recompile those declarations, however, tempting me to<br/>&gt; prematurely optimize by placing all of my C code in one giant string<br/>&gt; instead of interspersed among my Perl code. Neither XS::TCC nor Inline::C<br/>&gt; provide much (if any) automated machinery to share code.<br/>&gt;<br/>&gt; C::Blocks provides a mechanism to share function declarations, struct<br/>&gt; definitions, and other identifiers with other cblocks in the current<br/>&gt; lexical scope, as well as to share them on a per-package basis. It is even<br/>&gt; more versatile than normal Perl function scoping, allowing you to correctly<br/>&gt; correlate functionality with lexical scope. (It is also somewhat buggy, as<br/>&gt; discussed next.)<br/>&gt;<br/>&gt; *Pain point 4*. Changing C code should not cost anything. Inline::C can<br/>&gt; take seconds to recompile a changed set of C code. In contrast, there is no<br/>&gt; cost associated with changing code when using XS::TCC and C::TinyCompiler<br/>&gt; because they jit-compile their code. That comes at the cost, however, of<br/>&gt; always compiling everything each time you invoke your Perl script. If your<br/>&gt; C code needs the Perl C API, you will have to re-parse perl.h every time<br/>&gt; you *compile* a code block, which can happen many times with each<br/>&gt; execution of your script. Inline::C&#39;s caching mechanism provides a big win<br/>&gt; in that respect, unless you change your code. It would be nice if we could<br/>&gt; somehow cache the result of parsing ``#include &quot;perl.h&quot;&#39;&#39;.<br/>&gt;<br/>&gt; C::Blocks uses a fork of tcc that I&#39;ve been working on for many months<br/>&gt; aimed at allowing one compiler context to share its symbol table with other<br/>&gt; compiler contexts. This is related to the previous point. The sharing<br/>&gt; mechanism discussed in the previous point applies to preprocessor includes,<br/>&gt; so once I have compiled a block that uses the Perl headers, I can share all<br/>&gt; of those declarations with later compilation units, without recompiling. In<br/>&gt; future work, I plan to store these symbol tables to disk so that they don&#39;t<br/>&gt; even need to be re-parsed each time you run your script.<br/>&gt;<br/>&gt; ----<br/>&gt;<br/>&gt; C::Blocks currently addresses, completely, pain points 1 and 2 above. It<br/>&gt; has taken many months to hack on tcc to reach this point. I have now<br/>&gt; encountered some segfault-causing issues when trying to share code, yet I<br/>&gt; have a hard time reproducing those segfaults with direct tests on tcc. If<br/>&gt; you think this sounds like a cool project, I would appreciate some<br/>&gt; camaraderie as I try to dig into the internals of tcc. You can find me on<br/>&gt; perl&#39;s IRC network hanging out on #pdl, #xs, and #tinycc, among other<br/>&gt; channels. You can find my work at https://github.com/run4flat/C-Blocks<br/>&gt;<br/>&gt; If you would like to help out, let me know and I will give you a tour<br/>&gt; through the codebase. :-)<br/>&gt;<br/>&gt; Any help or encouragement would be much appreciated! Thanks!<br/>&gt; David<br/>&gt;<br/>&gt; --<br/>&gt; &quot;Debugging is twice as hard as writing the code in the first place.<br/>&gt; Therefore, if you write the code as cleverly as possible, you are,<br/>&gt; by definition, not smart enough to debug it.&quot; -- Brian Kernighan<br/>&gt; http://www.nntp.perl.org/group/perl.xs/2014/05/msg2772.html Sat, 24 May 2014 07:16:45 +0000 Re: Announcing C::Blocks, a different way to interface Perl and C code by sisyphus1 Sounds pretty cool, David. <br/>A plodder like me is probably just going to stick with Inline, but it would be great to see C::Blocks takes off. And it has the attractiveness to do so. <br/>(I like the way you can so easily just plonk the C code right in there amongst the perl code .... makes Inline look not-so-inline :-) <br/> <br/>Cheers, <br/>Rob <br/> <br/>From: David Mertens <br/>Sent: Friday, May 23, 2014 10:35 PM <br/>To: perl-xs@perl.org ; Perl Inline Mail List <br/>Subject: Announcing C::Blocks, a different way to interface Perl and C code <br/>Hey everyone, <br/> <br/> <br/>tl;dr: C::Blocks is a new TinyCC-based module, presently only available on github. (1) It jit-compiles blocks of C code, building and inserting OPs into the Perl OP tree, making invocation of C code essentially free. (2) It will allow different blocks of C code to share function and struct declarations, thus removing the need to always recompile perl.h, an otherwise major cost of jit-compiling C code that can interface with Perl and Perl data structures. <br/> <br/> <br/>I am currently seeking help and encouragement to squash the segfaults that currently prevent the completion of the second feature. :-) <br/> <br/> <br/>---- <br/> <br/> <br/>I like Perl, but I like C, too. I would like to be able to write and call C code from Perl in about as painless a way as possible. Inline::C is nice, as are XS::TCC and C::TinyCompiler, but we can do better. C::Blocks is my attempt to do better. <br/> <br/>Pain point 1. C code should be a first class citizen. With XS::TCC and C::TinyCompiler, you pass your code to the compiler via a string. With Inline::C, you either place your code at the bottom of your script in a __DATA__ section, or you enclose it in a string. Steffen&#39;s module is probably the most transparent in this sense. Still, working with an interface that requires me to compile a string to get my product feels the same as compiling a regex from a string. This is Perl! We can do better! <br/> <br/> <br/>C::Blocks does better by using a keyword parser hook. Blocks of code that you want executed are called like so: <br/> <br/> <br/> print &quot;Before cblock\n&quot;; <br/> <br/> cblock { <br/> <br/> printf(&quot;In cblock\n&quot;); <br/> <br/> } <br/> <br/> print &quot;After cblock\n&quot;; <br/> <br/> <br/>If stdio.h is included, you get the output <br/> <br/> <br/> Before cblock <br/> <br/> In cblock <br/> <br/> After cblock <br/> <br/> <br/>Because it uses a parser hook, the C code really is inline with your Perl code. <br/> <br/> <br/>Pain point 2. Calling C code should be obvious and cheap. All three modules discussed so far provide a mechanism for calling C functions. This means that for a simple, small operation, I must wrap my idea into a function one place and invoke it in another. Furthermore, if I want to repeatedly call a block of C code in a loop, I must define that block of code somewhere outside of the loop, potentially very far from the call site. C::TinyCompiler suffers further because it uses a complicated and rather slow calling mechanism. <br/> <br/> <br/>C::Blocks solves this by extracting and jit-compiling the C code at Perl parse time, generating an OP and inserting it into the Perl OP tree. This means that you can insert your C code exactly where you want it and not worry about repeated re-compiles. If you were to wrap the example given above in a for loop, you would see how this works. <br/> <br/> <br/>Pain point 3. Sharing C code should be as easy as sharing Perl code. C::TinyCompiler provides a fairly complex mechanism to allow modules to add declarations and symbols to a compiler context. Any string that uses that will need to recompile those declarations, however, tempting me to prematurely optimize by placing all of my C code in one giant string instead of interspersed among my Perl code. Neither XS::TCC nor Inline::C provide much (if any) automated machinery to share code. <br/> <br/> <br/>C::Blocks provides a mechanism to share function declarations, struct definitions, and other identifiers with other cblocks in the current lexical scope, as well as to share them on a per-package basis. It is even more versatile than normal Perl function scoping, allowing you to correctly correlate functionality with lexical scope. (It is also somewhat buggy, as discussed next.) <br/> <br/> <br/>Pain point 4. Changing C code should not cost anything. Inline::C can take seconds to recompile a changed set of C code. In contrast, there is no cost associated with changing code when using XS::TCC and C::TinyCompiler because they jit-compile their code. That comes at the cost, however, of always compiling everything each time you invoke your Perl script. If your C code needs the Perl C API, you will have to re-parse perl.h every time you compile a code block, which can happen many times with each execution of your script. Inline::C&#39;s caching mechanism provides a big win in that respect, unless you change your code. It would be nice if we could somehow cache the result of parsing ``#include &quot;perl.h&quot;&#39;&#39;. <br/> <br/> <br/>C::Blocks uses a fork of tcc that I&#39;ve been working on for many months aimed at allowing one compiler context to share its symbol table with other compiler contexts. This is related to the previous point. The sharing mechanism discussed in the previous point applies to preprocessor includes, so once I have compiled a block that uses the Perl headers, I can share all of those declarations with later compilation units, without recompiling. In future work, I plan to store these symbol tables to disk so that they don&#39;t even need to be re-parsed each time you run your script. <br/> <br/> <br/>---- <br/> <br/> <br/>C::Blocks currently addresses, completely, pain points 1 and 2 above. It has taken many months to hack on tcc to reach this point. I have now encountered some segfault-causing issues when trying to share code, yet I have a hard time reproducing those segfaults with direct tests on tcc. If you think this sounds like a cool project, I would appreciate some camaraderie as I try to dig into the internals of tcc. You can find me on perl&#39;s IRC network hanging out on #pdl, #xs, and #tinycc, among other channels. You can find my work at https://github.com/run4flat/C-Blocks <br/> <br/> <br/>If you would like to help out, let me know and I will give you a tour through the codebase. :-) <br/> <br/> <br/>Any help or encouragement would be much appreciated! Thanks! <br/>David <br/> <br/> <br/>-- <br/>&quot;Debugging is twice as hard as writing the code in the first place. <br/> Therefore, if you write the code as cleverly as possible, you are, <br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2014/05/msg2771.html Sat, 24 May 2014 03:35:10 +0000 Announcing C::Blocks, a different way to interface Perl and C code by David Mertens Hey everyone,<br/><br/>tl;dr: C::Blocks is a new TinyCC-based module, presently only available on<br/>github. (1) It jit-compiles blocks of C code, building and inserting OPs<br/>into the Perl OP tree, making invocation of C code essentially free. (2) It<br/>will allow different blocks of C code to share function and struct<br/>declarations, thus removing the need to always recompile perl.h, an<br/>otherwise major cost of jit-compiling C code that can interface with Perl<br/>and Perl data structures.<br/><br/>I am currently seeking help and encouragement to squash the segfaults that<br/>currently prevent the completion of the second feature. :-)<br/><br/>----<br/><br/>I like Perl, but I like C, too. I would like to be able to write and call C<br/>code from Perl in about as painless a way as possible. Inline::C is nice,<br/>as are XS::TCC and C::TinyCompiler, but we can do better. C::Blocks is my<br/>attempt to do better.<br/><br/>*Pain point 1*. C code should be a first class citizen. With XS::TCC and<br/>C::TinyCompiler, you pass your code to the compiler via a string. With<br/>Inline::C, you either place your code at the bottom of your script in a<br/>__DATA__ section, or you enclose it in a string. Steffen&#39;s module is<br/>probably the most transparent in this sense. Still, working with an<br/>interface that requires me to compile a string to get my product feels the<br/>same as compiling a regex from a string. This is Perl! We can do better!<br/><br/>C::Blocks does better by using a keyword parser hook. Blocks of code that<br/>you want executed are called like so:<br/><br/> print &quot;Before cblock\n&quot;;<br/> cblock {<br/> printf(&quot;In cblock\n&quot;);<br/> }<br/> print &quot;After cblock\n&quot;;<br/><br/>If stdio.h is included, you get the output<br/><br/> Before cblock<br/> In cblock<br/> After cblock<br/><br/>Because it uses a parser hook, the C code really is inline with your Perl<br/>code.<br/><br/>*Pain point 2*. Calling C code should be obvious and cheap. All three<br/>modules discussed so far provide a mechanism for calling C functions. This<br/>means that for a simple, small operation, I must wrap my idea into a<br/>function one place and invoke it in another. Furthermore, if I want to<br/>repeatedly call a block of C code in a loop, I must define that block of<br/>code somewhere outside of the loop, potentially very far from the call<br/>site. C::TinyCompiler suffers further because it uses a complicated and<br/>rather slow calling mechanism.<br/><br/>C::Blocks solves this by extracting and jit-compiling the C code at Perl<br/>parse time, generating an OP and inserting it into the Perl OP tree. This<br/>means that you can insert your C code exactly where you want it and not<br/>worry about repeated re-compiles. If you were to wrap the example given<br/>above in a for loop, you would see how this works.<br/><br/>*Pain point 3*. Sharing C code should be as easy as sharing Perl code.<br/>C::TinyCompiler provides a fairly complex mechanism to allow modules to add<br/>declarations and symbols to a compiler context. Any string that uses that<br/>will need to recompile those declarations, however, tempting me to<br/>prematurely optimize by placing all of my C code in one giant string<br/>instead of interspersed among my Perl code. Neither XS::TCC nor Inline::C<br/>provide much (if any) automated machinery to share code.<br/><br/>C::Blocks provides a mechanism to share function declarations, struct<br/>definitions, and other identifiers with other cblocks in the current<br/>lexical scope, as well as to share them on a per-package basis. It is even<br/>more versatile than normal Perl function scoping, allowing you to correctly<br/>correlate functionality with lexical scope. (It is also somewhat buggy, as<br/>discussed next.)<br/><br/>*Pain point 4*. Changing C code should not cost anything. Inline::C can<br/>take seconds to recompile a changed set of C code. In contrast, there is no<br/>cost associated with changing code when using XS::TCC and C::TinyCompiler<br/>because they jit-compile their code. That comes at the cost, however, of<br/>always compiling everything each time you invoke your Perl script. If your<br/>C code needs the Perl C API, you will have to re-parse perl.h every time<br/>you *compile* a code block, which can happen many times with each execution<br/>of your script. Inline::C&#39;s caching mechanism provides a big win in that<br/>respect, unless you change your code. It would be nice if we could somehow<br/>cache the result of parsing ``#include &quot;perl.h&quot;&#39;&#39;.<br/><br/>C::Blocks uses a fork of tcc that I&#39;ve been working on for many months<br/>aimed at allowing one compiler context to share its symbol table with other<br/>compiler contexts. This is related to the previous point. The sharing<br/>mechanism discussed in the previous point applies to preprocessor includes,<br/>so once I have compiled a block that uses the Perl headers, I can share all<br/>of those declarations with later compilation units, without recompiling. In<br/>future work, I plan to store these symbol tables to disk so that they don&#39;t<br/>even need to be re-parsed each time you run your script.<br/><br/>----<br/><br/>C::Blocks currently addresses, completely, pain points 1 and 2 above. It<br/>has taken many months to hack on tcc to reach this point. I have now<br/>encountered some segfault-causing issues when trying to share code, yet I<br/>have a hard time reproducing those segfaults with direct tests on tcc. If<br/>you think this sounds like a cool project, I would appreciate some<br/>camaraderie as I try to dig into the internals of tcc. You can find me on<br/>perl&#39;s IRC network hanging out on #pdl, #xs, and #tinycc, among other<br/>channels. You can find my work at https://github.com/run4flat/C-Blocks<br/><br/>If you would like to help out, let me know and I will give you a tour<br/>through the codebase. :-)<br/><br/>Any help or encouragement would be much appreciated! Thanks!<br/>David<br/><br/>-- <br/> &quot;Debugging is twice as hard as writing the code in the first place.<br/> Therefore, if you write the code as cleverly as possible, you are,<br/> by definition, not smart enough to debug it.&quot; -- Brian Kernighan http://www.nntp.perl.org/group/perl.xs/2014/05/msg2770.html Fri, 23 May 2014 12:35:50 +0000 Re: how to investigate "Attempt to reload Readonly/XS.pm aborted" by Matthew Horsfall On Tue, Apr 29, 2014 at 12:56 PM, Normand &lt;normand@linux.vnet.ibm.com&gt; wrote:<br/>&gt; Hi there,<br/>&gt; I have an error as detailed in the attached tst1.t perl script where the<br/>&gt; &quot;use Readonly::XS;&quot; line is failing.I tried to use perl -d debug mode but<br/>&gt; not working as use line is part of the compile section.<br/>&gt; I do not know how to investigate such a problem, so I would appreciate any<br/>&gt; suggestion.<br/><br/>Normand,<br/><br/>One trick you can use here is to eval the &quot;use Readonly; use<br/>Readonly::XS&quot; so that it happens at runtime rather than compile time.<br/>Alternatively, you can use &quot;require&quot;, so it now looks like this:<br/><br/> #!/usr/bin/perl<br/><br/> use strict;<br/> use warnings;<br/><br/> require Readonly;<br/> require Readonly::XS;<br/><br/>And if we run it with Devel::Trace, we now get some useful output<br/>which pinpoints the real error:<br/><br/> $ perl -d:Trace tst1.txt<br/> [ LOTS OF OUTPUT ]<br/> ...<br/> &gt;&gt; /usr/local/lib/perl/5.14.2/Readonly/XS.pm:29: if<br/>($MAGIC_COOKIE ne &quot;Do NOT use or require Readonly::XS unless you&#39;re<br/>me.&quot;)<br/> &gt;&gt; /usr/local/lib/perl/5.14.2/Readonly/XS.pm:31: require Carp;<br/> &gt;&gt; /usr/local/lib/perl/5.14.2/Readonly/XS.pm:32:<br/>Carp::croak(&quot;Readonly::XS is not a standalone module. You should not<br/>use it directly.&quot;);<br/> ---<br/> [ LOTS MORE OUTPUT ]<br/><br/>So Readonly.pm is doing &quot;eval &#39;use Readonly::XS&#39;;&quot;, which croaks, and<br/>leaves things in a weird state so when tst1.txt comes along and says<br/>&quot;use Readonly::XS&quot;, you get the unhelpful error message. (Perhaps a<br/>bug in Perl, I think I&#39;ll bring this up with Perl5 Porters).<br/><br/>Hope that helps.<br/><br/>-- Matthew Horsfall (alh)<br/> http://www.nntp.perl.org/group/perl.xs/2014/05/msg2769.html Fri, 02 May 2014 12:54:34 +0000 Re: how to investigate "Attempt to reload Readonly/XS.pm aborted" by Reini Urban This has nothing to do with perl-xs, you&#39;d need to read the module<br/>documentation first.<br/>perldoc Readonly<br/>perldoc Readonly::XS<br/><br/>perl -MReadonly::XS -e0<br/>Readonly::XS is not a standalone module. You should not use it<br/>directly. at Readonly/XS.pm line 34.<br/> http://www.nntp.perl.org/group/perl.xs/2014/05/msg2768.html Fri, 02 May 2014 07:03:50 +0000 how to investigate "Attempt to reload Readonly/XS.pm aborted" by Normand Hi there,<br/>I have an error as detailed in the attached tst1.t perl script where the &quot;use Readonly::XS;&quot; line is failing.I tried to use perl -d debug mode but not working as use line is part of the compile section.<br/>I do not know how to investigate such a problem, so I would appreciate any suggestion.<br/><br/># ===============================================<br/># $perl tst1.t<br/># Attempt to reload Readonly/XS.pm aborted.<br/># Compilation failed in require at tst1.t line 26.<br/># BEGIN failed--compilation aborted at tst1.t line 26.<br/># ===============================================<br/><br/>-- <br/>Michel Normand http://www.nntp.perl.org/group/perl.xs/2014/04/msg2767.html Tue, 29 Apr 2014 16:56:18 +0000