Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2013-02-05

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:51 Reini joined #perl11
02:20 Reini joined #perl11
02:50 genehack joined #perl11
03:50 Reini joined #perl11
04:06 Will_the_Chill joined #perl11
04:44 Reini joined #perl11
05:50 Will_the_Chill joined #perl11
09:35 flexvault Interesting comment on PerlMonks about <a href="http://www.perlmonks.org/?node_id=1016758">Perl 6 is going to get a lot faster in 2013</a>.
09:35 flexvault Damn html!
09:36 flexvault Anyway, enjoy...Ed
14:21 bluescreen joined #perl11
14:37 Reini joined #perl11
15:42 rurban flexvault: Did you see my benchmarks? http://perl11.org/p2/
15:42 rurban p2 is running circles around p5 and p6
15:46 flexvault rurban: WOW, that looks like great!
15:47 rurban jvm will always have a superslow startup time, thats why rakudo-jvm is not suitable for perl6 as scripting language, just as server language
15:47 rurban rakudo-p2 in the other hand will beat it
16:11 flexvault rurban: how much p2 code is complete? Will it be ready for Austin?
16:14 rurban ready not. But I will be able to show benchmarks.
16:14 rurban The compiler and vm is ready, the parser and libraries not
16:15 stevan rurban: are you benchmarking straight potion then?
16:15 stevan the language _why wrote?
16:15 rurban yes
16:15 stevan how is that a reasonable comparison?
16:15 stevan are you planning on compiling the p5 down to potion?
16:15 rurban currently I'm benchmarking straight potion, the vm only.
16:16 stevan as a replacement for parrot?
16:16 rurban as replacement for p5 and parrot
16:16 rurban it should run p5 and p6
16:17 stevan through raduko?
16:17 rurban there should be ONE underlying vm only
16:17 rurban p6 through nqp/rakudo, yes
16:17 stevan what about p5?
16:18 rurban I'm parsing p5 natively and convert it to the potion vm, which is flexible enough
16:18 rurban just the regexp engine is problematic
16:18 rurban And I probably store string encodings with the strings (as in parrot)
16:18 stevan right
16:19 stevan so, mind if I ask a few more detailed questions?
16:19 rurban But I can always use p5 regcomp
16:19 rurban sure
16:19 stevan things I am facing with Moe and i am interested as to what your thinking is
16:19 stevan so, if you get p5 to parse, and i assume you mean the entire language (not a subset as i am planning with moe)
16:19 stevan this gives you pure perl CPAN
16:19 stevan but no XS
16:19 rurban most of it, and more
16:20 stevan right, with your planned additions
16:20 rurban I abandon XS, just a ffi and direct api calls
16:20 rurban some XS converter needs to be written
16:20 stevan but without XS you lose a fairly large portion of existing CPAN code and some of the most important modules too (DBI, etc)
16:21 stevan even modules which are pure perl often have an XS dependency eventually
16:21 rurban That should be covered wit a converter, but most XS modules are too p5 hackish/bound anyway.
16:21 stevan yeah
16:21 stevan Nicholas did an "informal" survey of XS on CPAN when I was talking with him
16:21 stevan fell into two camps
16:21 rurban normal XS should work OOTB or can be easily rewritten as FFI
16:22 stevan 1) make soemthing faster (DateTime)
16:22 stevan 2) bind to a C lib
16:22 rurban 1. faster is not needed with p2
16:22 stevan #2 should be easier using your plan
16:22 stevan right
16:22 stevan ok, cool
16:22 rurban 2. binding is much easier with a FFI or using native API calls
16:22 stevan so, we are both thinking the same thing then
16:22 rurban sure
16:22 stevan that XS has to die
16:22 rurban just p5p will have the whiners
16:23 stevan and the consequences of this far outweigh the drawbacks
16:23 rurban well, most XS stackhandling can be converted to function calls
16:23 rurban since the typemap gives some level of abstraction
16:23 stevan I am not familiar enough with XS to know, so I will take your word for it :)
16:23 rurban I'm just notr sure yet abotu string encoding and int sizes
16:24 stevan yeah, potion seems to be pretty strict on that
16:24 rurban currently I reserve one high bit for ints
16:24 stevan well the utf8 anyway
16:24 rurban every fast language does this
16:24 stevan yes
16:24 rurban unboxing is slow, so ints usually are marked in the high bit
16:25 rurban which violates larrys int==ptr principle
16:25 rurban but since we dont really care about IV vs UV, only in cornercases, 95% should work
16:26 rurban 98% I guess
16:26 rurban A ptr type or boxed Int type should cover the rest
16:27 rurban This could be mapped to p5
16:28 stevan so, next question :)
16:28 rurban go on
16:28 stevan you mention that you plan to support a metamodel
16:28 rurban it already is supported
16:28 stevan right, what potion has
16:29 stevan are you also planning on supporting blessed refs/packages, meaning, the old object model?
16:29 rurban I have to, yes
16:29 stevan right
16:29 stevan yeah, this is where I am torn with moe
16:29 stevan I really dont want to
16:29 rurban hmm...
16:30 rurban The problem is that nobody will use it then.
16:30 stevan yeah
16:30 stevan cause we lose CPAN
16:30 rurban There are already much better and faster languages out there which nobody uses
16:30 stevan I am punting for the moment, because I am more interested in prototyping the new features
16:30 stevan then supporting the old ones
16:31 rurban And the p2 metamodel will not be a MOP
16:31 rurban So no prototype OO
16:31 rurban but anonymous classes
16:31 stevan yup, I read _whys spec
17:15 bluescreen rurban: why not using perlito to compile perl5 to bytecode?
17:16 rurban yes, but I rather want to do it fast from the beginning on.
17:16 rurban I could use perlito to convert p5 to potion and excute potion.
17:17 rurban If I run into trouble with tree-transformations I'll probably prototype it in QAST ot perlito
17:18 bluescreen rurban and stevan: if you guys can agree on the same ffi interface you would do a lot of good to the perl community
17:18 rurban :) not there yet
17:18 rurban but sure.
17:18 stevan yeah
17:18 stevan same here
17:18 stevan not there yet
17:18 rurban ffi interfaces are not a technical problem thanksfully
17:19 bluescreen right, but sometimes there are details that make people take their own route
17:19 rurban I'm completely with larry here: It just has to look good
17:20 rurban The problem will be the function definition/declaration only
17:20 bluescreen absolutely, but keep in mind that perfect is the enemy of good :D
17:20 rurban we already have the perfect FFI, dylan
17:20 rurban and the bad: perl
17:20 bluescreen lol
17:20 rurban and the median: ctypes
17:21 bluescreen is dylan something that can be backported to perl5?
17:21 rurban I believe Visual Basic is the way to go
17:21 rurban sure
17:21 rurban it's all just sugar
17:21 bluescreen with a reasonable effort
17:22 rurban no, ctypes seems to be the best candidate so far.
17:22 bluescreen if so that would help bridging the gaps and encourage people to get off XS
17:22 bluescreen damn. there is always a catch
17:23 rurban you can start fixing ctypes now: https://gitorious.org/perl-ctypes/
17:25 rurban everybody wants that
17:25 bluescreen what is it broken, and is that what you guys would use for moe/p11 ?
17:31 rurban doubi fixed some stuff lately, I haven't checked. run the tests
17:31 rurban we would love to use the interface, not the implementation
17:32 bluescreen ugly code?
17:32 bluescreen or you saying for p11?
17:33 rurban I call it p2
17:33 bluescreen ok
17:33 rurban The code is halfway not good OO style yet
17:37 bluescreen and is that like a CPAN module or needs to be part of the interpreter?
17:38 rurban ctypes needs to go to CPAN, so people can adopt it and start liking it
17:39 rurban I'll add a similar language to the parser (I want to parse c types natively)
17:39 rurban The fun and struct declarations should be in the language. That's easier
18:09 Reini joined #perl11
18:39 Reini joined #perl11
18:59 Reini joined #perl11
19:28 Will_the_Chill joined #perl11
19:44 Reini joined #perl11
20:55 bulk88_2 joined #perl11
21:10 Reini joined #perl11
23:40 rurban Nice parser rundown by Rob Pike: http://www.youtube.com/watch?v=HxaD_trXwRE&amp;feature=share
23:42 rurban I don't agree with his concurrency emphasis: <-/select which should be really inserting items into a global AST

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary