weekly Rakudo status meetings with phase transitions: Tue 19:00 UTC | IR clogs at irclog.perlgeek.de/phasers/today
Set by moderator on 26 April 2011.
17:10 mberends joined 18:03 masak joined 18:05 benabik joined 18:29 mikehh joined
Util Pre-report: No Perl 6 work this past week (or coming week); Working on old Parrot tickets and YAPC talk. 18:56
masak pre-report: been at YAPC::Russia and talked about parsing and DSLs. written a manifesto. not done much else to speak of. EOR 18:57
tadzik I'm not late! 19:03
jnthn either!
tadzik jnthn: I just got a ticket you would be proud of :P 19:04
that almost made me late 19:05
is anyone chairing?
jnthn A...ticket? :)
tadzik yeah, I've been found guilty of... drinking beer :) 19:06
masak \\o/
jnthn \\o/
tadzik++
tadzik I feel proud too
jnthn In Poland you get tickets for drinking beer? :)
Gee, here you only get bankrupt... P
tadzik yeah, when it's in the park
jnthn aww.
masak you're allowed to drink in the park in your country? :P 19:07
tadzik I find it _so_ wrong I actually don't mind getting the ticket
jnthn masak: You're...not in this one?
masak jnthn: technically no, but no-one cares if you behave.
tadzik smokers smoke everywhere and you can't calmly drink a beer in the wild, that's ridiculous
jnthn :)
tadzik: Yes, it's silly. :/
tadzik that's why I don't mind
masak tadzik: smoking is basically outlawed here too. 19:08
tadzik well, at least that's consistent
jnthn So, does anyone here have a beer^Wreport?
tadzik here you can smoke wherever you are (excluding indoor places not suited for smokers), but drinking beer is strictly forbidden
I has a report, yes 19:09
I could've precached it if I wasn't given a stupid beer ticket *grumble mumble*
can I?
masak go ahead.
tadzik so, I started GSoC work early. The parser in gsocmess repo is mostly done for the first two weeks of my schedule. The grammar is migrated to Rakudo, and at the moment of speaking, gsoc-podparser branch passes more spectests than master does 19:10
the action methods are not migrated yet, I need to think a bit about how to exponate the AST to the Perl 6 code, at least temporarily 19:11
I also did some minor panda tuning, and renamed the repo: it's not "Pies" anymore, it's now "panda", as panda is actual thing people care about 19:12
plans: complete GSoC week #1 and #2, preferably in week #1, the next week on the University is so "funny" I'm not sure whether I should cry, or is it already too late for crying 19:13
masak it's never too late to cry.
jnthn she...left me... :'(
tadzik honestly, compared to the next week, the exam session is going to be _so_ chillout
but I'm offtopicing. =end REPORT 19:14
jnthn tadzik: Hope exam prep/session goes well. :)
masak tadzik++
tadzik oh, and also I removed some invalid Pod from Rakudo :)
masak yay
tadzik jnthn: I hope so too, but... what can I say... compared to GSoC, the Uni work is so boaring and not-sensemaking... ah 19:15
plus moritz would probably be sad if I failed physics yet another time :) 19:16
jnthn can has report? 19:17
masak aye.
jnthn Over the last couple of weeks...
* Went to YAPC::Russia. Hacked a bit. Gave talks.
* Drank beer in Russia.
* Ate nice food in Russia.
* Did sightseeing in Russia. Saint Petersburg...quite an eyeful. :-)
* Thankfully for Rakudo, left distracting Russia, came home and resumed hacking
* nom now gets through the build
* First trait mod for inheritance is in place and works - need multi-dispatch to do more really
* Got the binder using new unified parameter/signature objects; very happy with that. More to do here but good start.
* Many other bits working towards getting Rakudo on its feet again
Next steps...
* Type lookups
* Methods
* Attributes
* Stashes, package scoped stuff
* Whatever else I have time for...got family visiting at weekend though 19:18
EOR
masak jnthn++!
jnthn Oh, and tossed named to postional binding in nom :)
tadzik nice, jnthn++ indeed
jnthn masak++ for writing up the manifesto :)
tadzik I like how nom builds now
masak (river Neva)++ for providing a nice backdrop for discussing the manifesto. and for me forgetting how sore my feet were ;) 19:19
jnthn Yeah. We should tell that guy who was complaining about the size of the perl6 executable about the improvement to its size. :)
tadzik :)
jnthn 48,640 perl6.exe
\\o/ :)
masak wow!
tadzik > duhs `which perl6` 19:20
0/home/tadzik/bin/perl6
...but I think it may be a symlink
plus it's a nom perl6 executable :P
are we done? Not that I'm accelerating, but I should be home, not the-first-place-around-with-wifi-when-#phasers-time-is-now 19:21
jnthn has nothing more :)
masak unless someone has more beers^Wreports...
tadzik masak? everyone else seems absent
mberends haz 19:22
masak tadzik: I already pre-reported
tadzik aye
masak mberends: go right ahead.
tadzik mberends: go on
mberends Report: Didn't do: write the promised native library to help zavolaj testing/troubleshooting. I'll get a round tuit, really.
Also didn't continue with 6model/JVM development, will probably never get a round tuit on that, so other interested people please volunteer.
Did do: much work on "Perlduino", a tiny Perl 6 subset to C compiler for Arduino microcontrollers (2K RAM, 32K ROM, arduino.cc) salvaged from the earlier Vill project. It should prove its feasibility in a few weeks. A brand new tokenizer and parser are beginning to work. 19:23
Plan: more Perl 6 to C work, including maybe an experimental 6model/C containing some aspects of SMOP.
My first software love was C, and getting back together with the old flame to make some Perl 6 feels very nice. 19:24
.EOR
tadzik mberends++ # yay for Perlduino
!
jnthn mberends: fwiw, the Parrot 6model rendering is mostly 6model-on-C with some Parrot wrappings. Toss the Parrot wrapping and you may be able to steal a bunch of bits :)
mberends cool! 19:25
masak \\o/
tadzik having an efficient C-level Perl 6 subset not only for Arduino seems nice-ish too
jnthn Yeah. We could write a VM in it... :) 19:26
tadzik or maybe I just think so because of the previous experiences today. Basically, a fellow student attacking his fellow students with the glass he got from the door he broke is... LTA
jnthn ouch :/ 19:27
tadzik add an ER taking him to a psychiatric hospital... I suddenly feel so down-to-earth, even looking at the calendar for the next week 19:28
masak :/
tadzik going home, bbi 40-60 mins 19:29
mberends jnthn: would it be ok with you if I made a C subtree in the 6model repo? 19:33
sorear hi #phasers
masak hi sorear. any report?
jnthn mberends: Feel free. 19:34
sorear 1. this is finals week. I have much more time now
2. I've done random hacking on niecza, largely in the back end 19:35
3. I'm seriously considering making niecza avoid appdomains (details on request)
4. the niecza backend is moving towards a "serialized metaobject blobs" model, in a slow and incremental way
5. mono run/Niecza.exe --help is down from 5.1s to 2.1s (after make reboot) 19:36
EOR I think? did other stuff last week but not much interesting stuff to comment on 19:37
maybe the design of numbers, maybe
masak sorear++
sorear did we come to a decision on what to do about trigbase?
19:38 ashleydev left 19:39 ashleydev joined
pmichaud oops, I'm late for phasers 19:51
jnthn Well, it's important to CHECK the time it'll BEGIN, INIT? :) 19:52
masak dåligt. 19:53
jnthn :P
sorear hello, pmichaud. 19:55
you aren't late
I just got here too
let's have a mini-phasers, just the two of us :) Have you made up your mind yet whether foo(1 => $x, 0 => $y) should be implemented?
pmichaud I'm sure it's legal. I'm not sure what it should do. :) 19:57
jnthn compile to foo($y, $x) iiuc
PerlJam pmichaud: magic
sorear well right now niecza compiles it to pass two Pair positionals
pmichaud *compile* to foo($y, $x) 19:58
that sounds icky magic
?
jnthn pmichaud: ?
masak it's just sugar...
jnthn pmichaud: It's a relatively straightforward transformation, imho
pmichaud: I'm not so sure I see the need for it as a language feature.
But implementing it, if it's just that transform, bothers me a little less. 19:59
sorear pmichaud: logically, it's just compiling two "named" arguments with names "1" and "0"
pmichaud I'm not thinking about it so much from a "hard to implement" standpoint
PerlJam jnthn: and foo(1 => $x, 7213 => $y) ?
jnthn PerlJam: Non-contiguous positionals error. :)
pmichaud: Oh, you meant "icky magic" from a user perspective? 20:00
OK, that I can buy much more :)
pmichaud jnthn: yes.
PerlJam jnthn: and foo(1 => $x) ?
pmichaud to me, it also relates somewhat to the notion of $/<0> being mapped to $/[0]
masak fwiw, I also don't see the need for the feature. 20:01
but it might just be lack of imagination :P
pmichaud and also feels funny in that I'm not sure if this is just for function calls or for generic parcel/capture semantics as well
my $parcel = (1 => $x, 0 => $y)
sorear it doesn't feel funny to me - I think I get it
pmichaud does that end up being the same as my $parcel = ($y, $x) ?
sorear the crux of the change is that the binder now looks for $cap<2> if it can't find $cap[2] 20:02
basically the same as what Match objects already do
pmichaud sorear: that doesn't sound compile-time-ish to me, though. I suppose it could be.
sorear one might go so far as to say that now, Captures do not have a positional part except as an optimization 20:03
they're more like Lua tables - a hash, with special storage for contiguous integer keys starting at 0
pmichaud or, that positional arguments are simply named '0', '1', '2', etc. -- same as in regex matches.
sorear now, \\(1 => $x, 0 => $y) can be optimized at compile time to \\($y, $x)
but it's just that - an optimization 20:04
jnthn sorear: That wasn't how I'd understood it at all.
sorear the unoptimized semantics feel simpler to me now
masak there's something to that.
jnthn sorear: If 0 => ..., 1 => ... exists it's a compile time transformation. The point is the binder doesn't have to ever worry about mapping nameds to positionals. 20:05
pmichaud I just have trouble seeing its utility being worth the potential confusion
jnthn pmichaud: Same, I was hoping to just get a chunk of spec ripped out rather than a chunk of spec replaced.
pmichaud jnthn: which chunk of spec?
masak the chunk talking about binding named args to positional params.
jnthn pmichaud: The bit where nameds can fill positional arguments.
masak parameters. 20:06
jnthn er, yes, parameters.
pmichaud jnthn: you're wanting to eliminate that?
jnthn Yes.
pmichaud fwiw, that was one of things that got an "oh wow cool" response at the last Perl 6 presentation I gave in April.
masak pmichaud: gist.github.com/984783 20:07
pmichaud I disagree that it's not used.
masak go on. 20:08
pmichaud I do things like that all the time in shell scripts and the like
i.e., provide for arguments to be filled in either positionally or by name
it seems like MAIN() would be a primary example of where this feature could be very very useful
sometimes when I'm calling programs/scripts/functions that have long argument lists, it's much more beneficial to specify some or all of the arguments by name instead of having to worry about their order 20:09
that said, I wouldn't want to require the arguments to be specified by name
an example: sub mysql_real_connect( OpaquePointer $mysql_client, Str $host, Str $user, Str $password, Str $database, Int $port, Str $socket, Int $flag ) 20:10
sorear I think that the ability to have arguments that are either positional or named is useful
and we've lost that from the current spec
pmichaud it'd be nice to call that as mysql_real_connect($client, $host, :$database, :$user, :$password, ...)
sorear I'm not wedded to "every positional gets a name from its variable name" 20:11
pmichaud but if we eliminate the "named fills positionals" feature, that goes away.
jnthn pmichaud: If it goes back into the spec then it should be explicitly "opt in", imo.
Not the default that you can do both.
sorear I could see something like sub foo($h is also-named<host>) {...} 20:12
pmichaud and I guarantee that mysql_real_connect($client, $host, 4=>$database, 2=>$user, 3=>$passwd) is not a good replacement
sorear pmichaud: agreed
jnthn I agree with that.
masak +1
sorear masak: +1 to my strawman syntax, really???
masak no, to pmichaud's guarantee ;) 20:13
pmichaud we already have a syntax for "is also named" iirc
sorear que?
pmichaud sub xyz($text, :abc($case)) 20:14
although maybe that's only for named parameters
still, we have :g(:$global) which is used to give $global an alias of 'g' 20:15
sorear it looks like both niecza and rakudo interpret that as being a non-positional param with 1 name
pmichaud right, I'm wondering if it makes more sense to say that it's a positional param with a name 20:16
masak I'd like to put forth the "oh, and this clashes with base conversion" paragraph in the recent S06 addition as a strong indication of ENOTTHEREYET.
sorear also, the implementation jnthn ripped out of rakudo looks way overcomplicated
adding "named parameters can fill positional slots" to niecza was a 1-line change
pmichaud I can't comment on that piece. 20:17
(at least, not at the moment)
jnthn sorear: You're probably comparing apples and oranges. 20:18
sorear jnthn: probably.
pmichaud hmm, looks like I didn't get a commit email for the latest changes to S06. Looking.
jnthn: also, note that the change says that keyed positionals isn't restricted to compile-time analysis (in commit 74b208c). Maybe you saw that already. 20:20
jnthn pmichaud: oh, ouch :/ 20:21
Then it's no help at all.
masak I think the fact that you can write :bar($foo) but not :1($foo) is a sign that either base conversion has the wrong syntax, or the new feature really wants to be something else.
pmichaud I don't think the new feature is helpful at all.
I think TheDamian would agree with me. Positions make lousy descriptors.
jnthn Aye.
pmichaud that's why we're also trying to move away from $0, $1, $2, in regexes into named forms. 20:22
I have to leave shortly, so here are my two pennies:
Being able to specify parameters either positionally or by name is very useful in some contexts.
It doesn't have to be the default (and probably shouldn't be the default)
so it would be nicer to have a syntax to say "this positional can also be filled by a named argument of '...'" 20:23
masak from what you described, pmichaud, it sounds like "some contexts" are "in MAIN".
pmichaud the example I gave of mysql_real_connect is another
masak oh, true.
pmichaud also any time there is a subroutine with lots of defaulted parameters
see, for example, IO::Prompt 20:24
(which may have parameters that make sense both positionally and by name)
anyway, I see that the change as it stands now is (1) no help, as jnthn++ says, and (2) of far less utility than what we had before. 20:26
I agree that the fact that any positional parameter implies an API is troublesome and ought to be fixed.
jnthn pmichaud: I can see the argument that some opt-in way to do this could be useful.
Equally, I value the binder simplification :) 20:27
pmichaud can someone point TimToady at the above comments, if he's not already reading them?
I have to go in a minute or two -- I'll post my #phasers report a bit later 20:29
summary: got sufficient changes into Parrot release that I think we can get zavolaj and friends working again
did a lot more benchmarking of rakudo and parrot, especially the 2011.05 release
I think we should issue a Star 2011.05 release 20:30
20:30 masak left
pmichaud I refactored the "rakbench" suite to be "rpbench" 20:30
various benchmarking results now appear in their own repository: github.com/pmichaud/rpbench-results
(and based on those results, you can see why I think we need a 2011.05 star release) 20:31
plan to finish out more benchmarking, review some reports, write some articles, and (time permitting) dive into nqp and nom a bit more.
EOR
afk, house errands 20:33
20:39 ashleydev left 20:40 ashleydev joined 20:45 spinclad joined, ashleydev left, ashleydev joined 21:42 benabik left 23:20 mikehh left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!