Re: Not Quite Perl
(follow-up to perl6-compil...@perl.org) Am 03.04.2012 10:02, schrieb Daniel Carrera: I've been reading a little about NQP (Not Quite Perl). I was wondering if NQP is part of the Parrot project, or if it is an independent spec. NQP exists in several versions. The earliest version lived in the parrot repository. The next iteration, called NQP-rx, was developed outside of parrot, and its compiled form (compiled to PIR, that is) was bundled with Parrot. The current version (called NQP again) is developed outside of parrot (in github.com/perl6/nqp/ repository), and not (yet?) bundled with parrot. NQP is intended to be a subset of Perl 6, use for bootstrapping the Rakudo compiler (and of use to other compiler writers as well). It doesn't have a separate spec. I'm wondering if a program written in NQP will be faster in general, or faster under Rakudo/Parrot, or not fast at all. Since NQP mostly(*) just implements stuff that maps well to parrot, it is usually much faster than Rakudo, but of course it also does much less. (*) current NQP also implements 6model, a lightweight object storage system that is flexible enough for Perl 6. Cheers, Moritz
[perl #112216] slicing a string with inifinite ranges gives LTA error message
# New Ticket Created by Moritz Lenz # Please include the string: [perl #112216] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112216 10:23 timotimo r: say foo[1..*] 10:23 +p6eval rakudo 8ead1e: OUTPUT«Method 'gimme' not found for invocant of class 'Str' in method postcircumfix:[ ] at src/gen/CORE.setting:1147 in block anon at /tmp/1ZiRf7yMZW:1»
Re: Not Quite Perl
On 3 April 2012 10:16, Moritz Lenz mor...@faui2k3.org wrote: (follow-up to perl6-compil...@perl.org) Ok. Moving discussion to per6-compi...@perl.org NQP exists in several versions... The current version (called NQP again) is developed outside of parrot (in github.com/perl6/nqp/ repository), and not (yet?) bundled with parrot. NQP is intended to be a subset of Perl 6, use for bootstrapping the Rakudo compiler (and of use to other compiler writers as well). It doesn't have a separate spec. ... Since NQP mostly(*) just implements stuff that maps well to parrot, it is usually much faster than Rakudo, but of course it also does much less. Ok. I just scanned the Wikibook on NQP. Indeed, it is quite limited. It lacks basic things like list context: @a := (1,2,3,4); # Wrong. It's a shame because lists is precisely what I wanted to work with. Reading up on Parrot I stumbled on this bit of information: Native Library Support Parrot has a robust system for interfacing with external native code libraries, such as those commonly written in C, C++, Fortran and other compiled languages. Where previously every interpreter would need to maintain its own bindings and interfaces to libraries, Parrot enables developers to write library bindings once and use them seamlessly from any language executing on Parrot. Want to use Tcl's Tk libraries, along with Python's image manipulation libraries in a program you are writing in Perl? Parrot supports that. Does that mean what I think it means? That I could, for example, get super-fast matrix operations using LAPACK simply because Rakudo talks to Parrot and Parrot talks to Fortran? There are a lot of powerful numerical libraries in C and especially Fortran, but last time I checked I think I was told that getting Rakudo to talk to Fortran would be very difficult. Cheers, Daniel. -- I'm not overweight, I'm undertall.
Re: Not Quite Perl
Am 03.04.2012 11:24, schrieb Daniel Carrera: Ok. I just scanned the Wikibook on NQP. Indeed, it is quite limited. It lacks basic things like list context: @a := (1,2,3,4); # Wrong. It's a shame because lists is precisely what I wanted to work with. But this works: @a := [1, 2, 3, 4] Note that this will store a ResizablePMCArray in @a, so if you want to know what kind of methods you can call on it, you have to consult parrot's documentation of the ResizablePMCArray. You also get the stringification behavior of a ResizablePMCArray etc. If that's not what you want, use Rakudo. Reading up on Parrot I stumbled on this bit of information: Native Library Support Parrot has a robust system for interfacing with external native code libraries, such as those commonly written in C, C++, Fortran and other compiled languages. *cough* Parrot has some limited out-of-the-box support for calling C functions, and if you have libffi installed (which doesn't work out of the box on Windows), you get decent support for calling C functions. I haven't seen a robust way to call C++ and Fortran functions yet, mainly because both use non-standard name mangling schemes at the bytecode level (I believe that newer Fortran versions have such a standard, but the scientific computing world seems to be stuck with F77). Where previously every interpreter would need to maintain its own bindings and interfaces to libraries, Parrot enables developers to write library bindings once and use them seamlessly from any language executing on Parrot. Want to use Tcl's Tk libraries, along with Python's image manipulation libraries in a program you are writing in Perl? Parrot supports that. Does that mean what I think it means? That I could, for example, get super-fast matrix operations using LAPACK simply because Rakudo talks to Parrot and Parrot talks to Fortran? That's the theory. In practice, it doesn't work like that. In practice, you have two options when crossing a language boundary. The first is to promote or wrap objects to types of the host language (ie a parrot integer becoming a Perl 6 Int), which means it can't be automated in the general case, and you get some performance penalty. The second is to simply leave the objects as-is, but you can't really call that seamlessly. It means for example that your Perl 6 Int object has a method called sqrt, but the Parrot integer does not. The cross-language interoperability advertised in the parrot documentation is mostly fiction. All attempts to get cross-language interoperation to work have bitrotted, and I'm not aware of any working, non-contrieved examples. There are a lot of powerful numerical libraries in C and especially Fortran, but last time I checked I think I was told that getting Rakudo to talk to Fortran would be very difficult. NQP (and thus Rakudo) has its own mechanism for calling C libraries. In Rakudo, this is available through NativeCall.pm in https://github.com/jnthn/zavolaj/ (Note that currently NativeCall doesn't work together with precompiled modules; should still work in the latest Rakudo Star release though). Cheers, Moritz
Re: Not Quite Perl
On 3 April 2012 11:48, Moritz Lenz mor...@faui2k3.org wrote: But this works: @a := [1, 2, 3, 4] Note that this will store a ResizablePMCArray in @a, so if you want to know what kind of methods you can call on it, you have to consult parrot's documentation of the ResizablePMCArray. You also get the stringification behavior of a ResizablePMCArray etc. If that's not what you want, use Rakudo. Ok. In practice, I'll use Rakudo. It sounds like NQP just isn't worth the effort. You lose too much of what makes Perl 6 fun to use. Parrot has a robust system for interfacing with external native code libraries, such as those commonly written in C, C++, Fortran and other compiled languages. *cough* Parrot has some limited out-of-the-box support for calling C functions, and if you have libffi installed (which doesn't work out of the box on Windows), you get decent support for calling C functions. I haven't seen a robust way to call C++ and Fortran functions yet, :-( Oh well. Thanks for clarifying that for me. mainly because both use non-standard name mangling schemes at the bytecode level (I believe that newer Fortran versions have such a standard, but the scientific computing world seems to be stuck with F77). I don't know anything about bytecode or name mangling, but I do agree with the evils of F77. I personally refuse to learn F77, but I know that most scientific libraries haven't been ported to modern Fortran. Fortran 2003 introduced interoperability with C, so you can call Fortran functions from C and vice versa, but I think it'll be a long time before this is widely used in libraries. NQP (and thus Rakudo) has its own mechanism for calling C libraries. In Rakudo, this is available through NativeCall.pm in https://github.com/jnthn/zavolaj/ (Note that currently NativeCall doesn't work together with precompiled modules; should still work in the latest Rakudo Star release though). Thanks. I'll have a look. Cheers, Daniel. -- I'm not overweight, I'm undertall.
[perl #112216] slicing a string with inifinite ranges gives LTA error message
On Tue Apr 03 01:24:47 2012, moritz wrote: 10:23 timotimo r: say foo[1..*] 10:23 +p6eval rakudo 8ead1e: OUTPUT«Method 'gimme' not found for invocant of class 'Str' in method postcircumfix:[ ] at src/gen/CORE.setting:1147 in block anon at /tmp/1ZiRf7yMZW:1» Now fixed in 1bbf9eb, needs spectests to close ticket. Thanks! Pm
Re: [perl #112216] slicing a string with inifinite ranges gives LTA error message
On 04/03/2012 06:44 PM, Patrick R. Michaud via RT wrote: On Tue Apr 03 01:24:47 2012, moritz wrote: 10:23 timotimo r: say foo[1..*] 10:23 +p6eval rakudo 8ead1e: OUTPUT«Method 'gimme' not found for invocant of class 'Str' in method postcircumfix:[ ] at src/gen/CORE.setting:1147 in block anon at /tmp/1ZiRf7yMZW:1» Now fixed in 1bbf9eb, needs spectests to close ticket. Now we have foo[2] fail(), but foo[2..*] returns the empty Parcel. Is that the intended behavior? Cheers, Moritz
Re: [perl #112216] slicing a string with inifinite ranges gives LTA error message
On 04/03/2012 11:16 PM, Patrick R. Michaud wrote: On Tue, Apr 03, 2012 at 09:22:11PM +0200, Moritz Lenz wrote: On 04/03/2012 06:44 PM, Patrick R. Michaud via RT wrote: On Tue Apr 03 01:24:47 2012, moritz wrote: 10:23 timotimo r: say foo[1..*] 10:23 +p6eval rakudo 8ead1e: OUTPUT«Method 'gimme' not found for invocant of class 'Str' in method postcircumfix:[ ] at src/gen/CORE.setting:1147 in block anon at /tmp/1ZiRf7yMZW:1» Now fixed in 1bbf9eb, needs spectests to close ticket. Now we have foo[2] fail(), but foo[2..*] returns the empty Parcel. Is that the intended behavior? Since foo acts like a list of one element, My point is that it currently doesn't really. Compare: say foo.list.[2] # Nil with say foo.[2] # Index out of range. Is: 2, should be in 0..0 which is why I'm complaining about inconsistencies. I suspect that .[2..*] should act the same as when used on an array of one element, which results in an empty Parcel: my @array = foo; say @array[2..*].elems; # 0 say foo[2..*].elems; # 0 If that's wrong, we need better spectests to get the correct behavior. No, first we need agreement on what the right behavior is. Thinking about spectests before we're positive on the right behavior is taking things out of order.
