Re: [POC] nci interface using ffcall library
On Oct 31, 2005, at 7:49, John Lenz wrote: On Fri, October 28, 2005 2:22 pm, Nick Glencross said: Guys, As mentioned on the list yesterday I started evaluating ffcall as a way of providing NCI functionality. http://www.haible.de/bruno/packages-ffcall.html I am a SWIG (www.swig.org) developer, and I recently started looking at what it will take to add a parrot module to SWIG. I will post some of the issues I ran into, but I was wondering if there would be any interest for SWIG to become one of the official way to do NCI? SWIG isn't a replacement for NCI. Parrot NCI is fully dynamic and doesn't need any compiler, linker, interface definition file and what not. SWIG has a whole bunch of other benefits which I won't list here. I think, it would need good reasons to include another ffi-alike. But that doesn't preclude SWIG of course. The main issue resolves around the problem that there isn't a standard way to just register a function as callable from parrot (that I can see). Any PMC that provides the 'invoke' vtable is a callable. SWIG can easily generate functions of the form void* _wrap_foo(Interp* interpreter, PMC* pmc, void * next) one for each function being wrapped. Can we inject that function directly into the vtable somehow? Or just create a class that passes on the invoke function? I presume that would be a NCI_SWIG PMC. If this callable is inserted into the vtable or dynamically looked up is an implementation detail. One of the existing SWIG modules (CHICKEN) deals with a continuation passing language, so SWIG can deal with continuation-aware languages. Sounds interesting SWIG does not require any code besides what it generates... think lex or yacc... Well, it's fully static, while NCI is dynamic: $ cat n.pir .sub main :main .local pmc l, f .local string fn .local float v l = loadlib "libm" loop: (fn, v) = input_func_and_val() f = dlfunc l, fn, "dd" v = f(v) print v print "\n" goto loop .end .sub input_func_and_val .local pmc in, out out = getstdout print "> " out."flush"() .local string fn, v in = getstdin fn = readline in chopn fn, 1 v = readline in chopn v, 1 .return (fn, v) .end $ ./parrot n.pir > sin 2 0.909297 > cos 2 -0.416147 John leo
[perl #37563] [BUG] Parrot m4 has problems with PGE
> [bernhard - So 30. Okt 2005, 04:35:45]: > > Hi, > > it looks like recent PGE changes broke 'Parrot m4'. > I have boiled it down to a 20 line test cast and added it > as test 4 in t/library/pge.t. This test case fails, at least under my > Linux installation, with a segmentation fault. > > My setup: > > [EMAIL PROTECTED]:~/devel/Parrot/local/parrot> uname -a > Linux linux 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown > [EMAIL PROTECTED]:~/devel/Parrot/local/parrot> gcc --version > gcc (GCC) 3.4.2 > > CU, Bernhard I have trace the failure t/library/pge_4.pir with valgrind. It looks like p->pmc_ext ends up with a value of 0x5 in src/dod.c. This looks not healthy to me. More about that once I have 'gdb' and 'ddd' running on my friends machine. CU, Bernhard Process terminating with default action of signal 11 (SIGSEGV) ==4409== Access not within mapped region at address 0x5 ==4409==at 0x80CB662: pobject_lives (src/dod.c:223) ==4409==by 0x808D5FB: mark_stack (src/stacks.c:72) ==4409==by 0x8163263: mark_context (src/sub.c:41) ==4409==by 0x80CB90A: Parrot_dod_trace_root (src/dod.c:365) ==4409==by 0x80CB9B0: trace_active_PMCs (src/dod.c:390) ==4409==by 0x80CC496: Parrot_dod_ms_run (src/dod.c:1236) ==4409==by 0x80CC566: Parrot_do_dod_run (src/dod.c:1275) ==4409==by 0x80CA07D: more_traceable_objects (src/smallobject.c:114) ==4409==by 0x80CA0FF: gc_ms_get_free_object (src/smallobject.c:162) ==4409==by 0x808DC7A: cst_new_stack_chunk (src/stack_common.c:92) ==4409==by 0x808DCE8: stack_prepare_push (src/stack_common.c:117) ==4409==by 0x808D960: stack_push (src/stacks.c:253) -- /* [EMAIL PROTECTED] */
RE: [POC] nci interface using ffcall library
Nick Glencross wrote: > > As mentioned on the list yesterday I started evaluating ffcall > as a way of providing NCI functionality. > > http://www.haible.de/bruno/packages-ffcall.html > > I actually really like the current NCI implementation, although > it suffers from a large nci.c file and all the usable prototypes > need to be specified at compile time in call_list.txt. Over time > as more libraries become supported this list will quickly grow. Here's a reference to the last time this thread came up: http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/8b1b5e 7e343ce3c4/ and a shortened URL forwarded version: http://ffcall-perl6-internals.notlong.com Here's the tail end: 8. Dan Sugalski Jan 12 2004, 12:49 pm At 10:13 AM -0600 1/12/04, Garrett Goebel wrote: > >Tim Bunce wrote: >> >> I see Dan says in his blog "Yeah, I know, we should use libffi, and >> we may as a fallback, if we don't just give in and build up the >> function headers everywhere." >> >> I'm not familiar with libffi so this may be a dumb question, >> but why the apparent reluctance to use it? > >The reluctance probably doesn't have anything to do with its very liberal >licensing terms... Nope. The two issues were portability and the prospect of a library which isn't ours that we'd need to maintain if we were distributing it. I'm fine with someone taking a stab at teaching Configure to probe for it on platforms that don't have the JIT building up function headers already, and teaching nci.c to use it in that case. (As long as the order of preference is "JIT building functions", "libffi", "current hackish NCI scheme" is maintained) -- Dan 9. Garrett Goebel Jan 12 2004, 1:48 pm Tim Bunce wrote: > > Tim Bunce wrote: > > > > I see Dan says in his blog "Yeah, I know, we should use libffi, > > and we may as a fallback, if we don't just give in and build up > > the function headers everywhere." > > > > I'm not familiar with libffi so this may be a dumb question, > > but why the apparent reluctance to use it? > > > > In http://www.nntp.perl.org/group/perl.perl6.internals/253 I see > Garrett Goebel quotes Bruno Haible saying "I could agree to the > LGPL license. Perl could then use ffcall as a shared library > (linked or via dlopen)" > > And I see http://www.parrotcode.org/docs/faq.pod.html says > "Code accepted into the core interpreter must fall under the same > terms as parrot. Library code (for example the ICU library we're > using for Unicode) we link into the interpreter can be covered by > other licenses so long as their terms don't prohibit this." > > So it seems there's no licensing issue preventing parrot using libffi. > > Is that right? > Are there any others? My bad. In my comments on Dan's blog, I confused libffi with ffcall. Both do roughly the same thing... The libffi was originally produced by Cygnus, but is now part of GCC. http://sources.redhat.com/libffi/ http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/LICENSE ffcall was produced by Bruno Haibel as part of his CLISP package. http://www.haible.de/bruno/packages-ffcall.html ffcall used to be considered more mature/stable, but since libffi was included in GCC the general impression true or not is that libffi is more actively maintained. From mailing lists and csv logs, it looks like both are actively maintained... 10. Tim Bunce Jan 13 2004, 9:49 am And since it seems both are usable for parrot from a licencing perspective we're free to use whichever suits best on a given platform - assuming someone implements the relevant interface code. Tim. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Proposed Kwalitee tests: has_license and/or has_meta_yml_license
In the last year as a Fink maintainer (Mac OS X debian-like package manager), I've come across a couple CPAN modules that have no license information at all. It's very frustrating. I've submitted RT bugs, but one of them has been fixed (thanks Ken Williams). To encourage authors to correct this oversight, I propose a new pair of Kwalitee tests. Both would be nice, but if either of them were implemented, I'd be thrilled. I'd prefer that someone else implement the test (lack of tuits), but if there is approval for the idea without a motivated implementer I will take a hack at it. 1) has_license -- check for the presence of a file named something like LICENSE or COPYING or COPYLEFT or GPL or ... (each test case insensitive, with or without .txt extensions). Alternatively, the test can be more liberal by looking for the string "copyright" in README, *pm and *.pod. 2) has_meta_yml_license -- check for a META.yml field named "license". Module::Build supports this. These tests should not care which license is claimed, just that there is a license present. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Proposed Kwalitee tests: has_license and/or has_meta_yml_license
Hi!
On Mon, Oct 31, 2005 at 08:34:09AM -0600, Chris Dolan wrote:
> To encourage authors to correct this oversight, I propose a new pair
> of Kwalitee tests. Both would be nice, but if either of them were
> implemented, I'd be thrilled. I'd prefer that someone else implement
> the test (lack of tuits), but if there is approval for the idea
> without a motivated implementer I will take a hack at it.
>
> 1) has_license -- check for the presence of a file named something
> ..
> 2) has_meta_yml_license -- check for a META.yml field named
Nice ideas. I would add them to CPANTS, but at the moment I haven't got
*one* spare minute, as we are in the finishing stage of renovating our
new appartment and moving there. You might have noticed that there
wasn't a CPANTS update in the last weeks, for the same reason...
I'll be back to to (semi-)serious CPANTS-work after 13th Nov. (BTW, If
you're in/near Vienna and fancy some free workout (carry our stuff down
4 floors and then up 3) drop me a line. :-)
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Re: [perl #37563] [BUG] Parrot m4 has problems with PGE
Bernhard Schmalhofer via RT wrote: it looks like recent PGE changes broke 'Parrot m4'. I have boiled it down to a 20 line test cast and added it as test 4 in t/library/pge.t. This test case fails, at least under my Linux installation, with a segmentation fault. It looks like a GC bug, kind of an ABA problem due to chunk reusage. OTOH I tried to clear chunk->u.date, but this did *not* help. The remarkable thing here is: both stacks seen in the trace are Control stacks (used by bsr, ret, and exceptions). And that the visible PMC address here: ==4409==at 0x80CB662: pobject_lives (src/dod.c:223) ==4409==by 0x808D5FB: mark_stack (src/stacks.c:72) is the same as the bsr address seen in chunk->prev. And above chunk has the same botton, as the TOS of the stack_p ==4409==by 0x808DCE8: stack_prepare_push (src/stack_common.c:117) ==4409==by 0x808D960: stack_push (src/stacks.c:253) ... used here in the C opcode (visible in gdb backtrace). Anyway, I've put in a workaround by clearing the entry_type of popped stack entries (r9678). But further investigation is welcome. leo
Re: [POC] nci interface using ffcall library
Garrett Goebel wrote: Nick Glencross wrote: As mentioned on the list yesterday I started evaluating ffcall as a way of providing NCI functionality. http://www.haible.de/bruno/packages-ffcall.html I actually really like the current NCI implementation, although it suffers from a large nci.c file and all the usable prototypes need to be specified at compile time in call_list.txt. Over time as more libraries become supported this list will quickly grow. Here's a reference to the last time this thread came up: http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/8b1b5e 7e343ce3c4/ and a shortened URL forwarded version: http://ffcall-perl6-internals.notlong.com Thanks for that Garrett. It's great that you've talked to Bruno in the past about this! Although I had planned to look at both ffcall and libffi, ffcall has so far looked more compelling to me. I started looking for the latest version of libffi, couldn't be sure which it was so I put it on the backburner. Then I looked at ffcall, instantly thought 'perfect' because it provided a really usable API, and then knocked up a quick POC. I certainly agree about what was being said about supporting multiple backends as it protects us against future nasty platforms. However, I'm unclear what the benefits of the favoured option of using JIT code was; that sounds like reinventing a ff library. One thing that would be nice would be extend build_native.pl so that it builds the other supported NCI layers; that way they would all support the same types and not get out of sync with one another. I'd be interested in trying this if no one objects... My word of the week seems to be 'callbacks' because the current implementation doesn't seem to cut it (in my opinion), which is really the driving reason for looking at other alternatives. Cheers, Nick
win32 can't make realclean
Getting the following error on 'nmake realclean', a popup (why on earth can't I cut and paste this error!#$#) with: perl.exe: Application error: The instruction at "0x7c93426d" referenced memory at "0x". The memory could not be "read". Click on "OK". Get a second popup: perl.exe - Application Error The instruction at "0x7c9114b6" referenced memory at "0x000461ed". The memory could not be "written". This error persists after a reboot of the PC. Last things in the build window are: C:\Perl\bin\perl.exe -MExtUtils::Command -e rm_f classes\ \*.c classes\\* .h classes\\*.dump vtable.dump C:\Perl\bin\perl.exe -MExtUtils::Command -e rm_f *.def *.lib *.exp NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xc005' Stop. The only file that matches that last one is "libparrot.def". If I remove this file by hand... the nmake happily continues past this point. (with no errors mentioned during the 'del') Does this point to an issue with ExtUtils::Command on windows?
Re: [POC] nci interface using ffcall library
On Mon, 2005-10-31 at 20:12 +, Nick Glencross wrote: > I certainly agree about what was being said about supporting multiple > backends as it protects us against future nasty platforms. However, I'm > unclear what the benefits of the favoured option of using JIT code was; > that sounds like reinventing a ff library. Having a JIT was a goal anyway. It avoids potential license conflicts. It removes one dependency. It potentially reduces executable size and memory use. It's something we can patch and test and customize as we need, especially with regard to our calling conventions. Those might not all be current benefits; I'm just going by memory and not arguing for or against ffcall or libffi. -- c
