Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-03

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

All times shown according to UTC.

Time Nick Message
02:18 vendethiel joined #moarvm
02:49 flaviusb joined #moarvm
06:29 flaviusb joined #moarvm
06:38 brrt joined #moarvm
06:44 FROGGS joined #moarvm
07:23 brrt joined #moarvm
07:24 brrt \o
07:24 Ven joined #moarvm
07:42 zakharyas joined #moarvm
08:05 lizmat joined #moarvm
08:12 lizmat joined #moarvm
08:50 Ven joined #moarvm
09:44 dalek MoarVM: c4c7ebd | brrt++ | src/ (2 files):
09:44 dalek MoarVM: Revert "Eliminate 100% core use for async things."
09:44 dalek MoarVM:
09:44 dalek MoarVM: This reverts commit 58226af4aad0d36517dfb8c250770b8438fdc6d0.
09:44 dalek MoarVM: Unfortunately, this caused a bit more fallout than downstream
09:44 dalek MoarVM: was prepared to deal with. This patch will be reapplied to branch
09:44 dalek MoarVM: 'async_wakeups' so development can continue.
09:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c4c7ebdbf8
09:45 dalek MoarVM/async_wakeups: 357e65a | jnthn++ | src/ (2 files):
09:45 dalek MoarVM/async_wakeups: Eliminate 100% core use for async things.
09:45 dalek MoarVM/async_wakeups:
09:45 dalek MoarVM/async_wakeups: Use async wake-ups instead of an idle handler. For this to work out we
09:45 dalek MoarVM/async_wakeups: also need a semaphore to avoid a race in sending the first task to the
09:45 dalek MoarVM/async_wakeups: event loop. GC is also far better handled, using prepare/check handles
09:45 dalek MoarVM/async_wakeups: so another thread can work-steal the event loop thread for GC purposes
09:45 dalek MoarVM/async_wakeups: when it is sleeping awaiting an I/O notification etc.
09:45 dalek MoarVM/async_wakeups: review: https://github.com/MoarVM/MoarVM/commit/357e65af8b
10:08 Ven joined #moarvm
11:37 timotimo i'm glad we're allowed to put our newest work under the noses of our fellow perl6ians with this ^
13:12 FROGGS joined #moarvm
14:33 zakharyas joined #moarvm
14:35 vendethiel joined #moarvm
15:29 vendethiel joined #moarvm
16:49 brrt joined #moarvm
17:56 vendethiel joined #moarvm
18:50 brrt joined #moarvm
19:02 Peter_R joined #moarvm
19:08 brrt hmmpf
19:08 brrt i want to do something like MVMIODescriptable which has a single method descriptor()
19:08 nwc10 good hmmpf?
19:08 nwc10 or hmmpf morning?
19:09 brrt good evening :-)
19:10 jnthn brrt: That seems reasonable
19:10 brrt but i find that a): in all cases uv_file is just an int
19:10 * jnthn just successfully used new appartmnet's kitchen to make noms o/
19:11 brrt which means that i should be able to put it into a MVMint64 field, i'd think
19:11 nwc10 yay
19:11 nwc10 is the beer fridge fully operational too?
19:11 brrt good busy jnthn :-)
19:11 jnthn nwc10: Not yet fully stocked
19:11 jnthn nwc10: But yes, my refrigerator is running :)
19:11 brrt shouldn't be so hard to stock a beer fridge in .cz
19:12 jnthn Yesterday I discovered the train to .cz actually had beer on tap.
19:13 jnthn Draught beer. On a train!
19:13 jnthn (It was morning, so I didn't test it out.)
19:13 nwc10 yay. that's better than the train to Dresden, which merely had .cz beer.
19:14 nwc10 (at Hungarian prices. I wasn't complaining)
19:14 brrt unbelievable :-o
19:23 * jnthn wonders if a Gulaschprogrammiernacht is a night where you eat gulash and hack, 'cus that sounds awesome...
19:24 FROGGS jnthn: I think so
19:25 FROGGS gulash+hack+talks IIRC
19:25 jnthn wow :)
19:26 FROGGS ohh, it starts tomorrow
19:27 nwc10 I'd just worked this out
19:28 brrt to make matters considerably more confusing, libuv has uv_file and uv_os_fd_t, and as near as I can tell these are exactly equivalent
19:31 brrt i'm wrong; uv_file is always an int; uv_os_fd_t is an int on unix and a HANDLE on windows
19:31 japhb jnthn: So what made you pick Prague for your next home base?
19:31 FROGGS jnthn: is there a way for an op to return more than one thing?
19:32 FROGGS jnthn: or write to an obj attribute it became?
19:32 brrt FROGGS - what do you want to do
19:33 FROGGS brrt: get the stdout and stderr filehandle back from nqp::openpipe
19:33 FROGGS the filehandles from the child process
19:34 brrt i don't see a reason why you couldn't do an op that had two write registers
19:35 timotimo jnthn: there's only actual gulasch on one of the days
19:35 * brrt bbiab
19:35 timotimo but there's con-carne and vegan gulasch to choose from
19:36 FROGGS what is vegan gulash?
19:36 FROGGS that does not sounds sane to me
19:36 timotimo it contains "saitan"
19:37 timotimo we're expecting about 500 people to show up
19:37 jnthn japhb: I like central/east Europe and wanted to come back to the region, and Prague is a very nice mix of well connected, beautiful, and appealing to wife. :) Plus language is close to others I know some of.
19:37 timotimo last year there were more than 500 pre-registrations ... and those are voluntary
19:38 FROGGS hmpf
19:39 japhb Slovene and Russian, I'm guessing?  (the similar languages that you know some of)
19:39 jnthn Slovak, not Slovene. :)
19:39 FROGGS somebody should port tools/update_ops.p6 to nqp
19:39 japhb Duh, yes, sorry
19:40 nwc10 same word for beer?
19:40 jnthn Yes, though the word for "draught" is slightly different from in Slovak :)
19:40 timotimo so far i thought "draught" was "a period of very dry weather"
19:40 jnthn That's a drought :)
19:41 timotimo oh!
19:41 timotimo of course
19:41 jnthn A beer drought would be indeed highly unfortunate...
19:41 nwc10 or a measure of a successul evening
19:41 japhb Which, by the way, shows yet again why 'gh' in English basically sounds like 'whatever the heck you want'
19:43 jnthn FROGGS: Why do we need to port it to NQP? It's already in Perl 6...
19:43 FROGGS jnthn: because I rebuild nqp after changing moar, and now my perl6-m is outdated and cant regenerate the oplist :o)
19:43 japhb On actual topic:  I thought I remembered some reason that multiple write registers in an op was not fully supported -- optimizer or specializer didn't recognize the extra write register or some such, and so lost track of the register during analysis.
19:45 FROGGS it at least seems that a write register at the end does not work
19:45 FROGGS my variable in nqp stays NQPMu
19:46 FROGGS the alternative is to return a list...
19:48 FROGGS if there is a nicer option... dont hesitate to write it in the clogs :o)
19:48 FROGGS gnight
19:48 japhb o/
19:55 timotimo hmm. what exactly do we need that for?
19:55 jnthn .tell FROGGS I think quite a few things rely on you only having writes to one register, and it being the first one.
19:56 jnthn I'm not especially inclined to change that...
20:05 brrt joined #moarvm
20:23 lizmat jnthn: https://gist.github.com/lizmat/5ae61833fe735865f1fa   # trying to implement $=finish
20:23 lizmat the approach is setting the lines in $*FINISH in the compunit
20:23 lizmat and when $=finish is seen, create access to it
20:23 lizmat of course, we have a timing / serialization issue
20:24 lizmat as the ops for $=finish are made well before $*FINISH is set
20:24 lizmat jnthn: suggestions?
20:27 jnthn lizmat: I'd create a $=finish variable in UNIT right from the start and install a Mu there
20:27 jnthn lizmat: With install_lexical_symbol or so
20:27 jnthn lizmat: And if we really get a finish, then update it again with the value
20:27 jnthn lizmat: And then $=finish is just a normal variable lookup
20:27 lizmat ok, I think I can work with that
20:28 jnthn lizmat: I think on a previous patch we worked on together we noted that you can call install_lexical_symbol twice for the same symbol and it just updates it
20:28 jnthn Anyway, you'll emit a QAST::Var for the lookup
20:28 jnthn You get rid of the $*FINISH this way too :)
20:28 lizmat yup
20:29 jnthn (And you already have $*UNIT available to find the scope to pass to the symbol installer)
20:30 brrt joined #moarvm
20:30 brrt huh, i couldn't connect to #moarvm for some time
20:30 jnthn odd
20:31 brrt rather
20:34 colomon joined #moarvm
20:43 zakharyas joined #moarvm
21:04 colomon joined #moarvm
21:27 brrt ok, as i've just informed over at #libuv, turns out that only a syncfile exposes an uv_file, all the others exponse a uv_handle
21:27 brrt an uv_handle *can* be converted to an int on unix, but only to a HANDLE in windows
21:27 brrt i'm not sure exactly how large a HANDLE is?
21:28 brrt or even what it is in the first place
21:31 brrt a handle is basically a pointer
21:31 brrt (windows handle)
21:32 jnthn brrt: https://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx
21:32 jnthn typedef PVOID HANDLE;
21:32 brrt damnit to hell
21:32 brrt ok, that can't be helped, then
21:32 jnthn Amd typedef void *PVOID;
21:33 jnthn Well, but it's opaque
21:33 jnthn So you can treat it as an integer if you like
21:33 brrt actually, i cannot
21:33 brrt or rather, i'm unsure i can treat it as a fd
21:34 brrt which is what i really need for  isatty()
21:34 jnthn ah
21:34 lizmat jnthn: if I want to catch usage of __END__ or __DATA__ , which method in Actions should I look at ?
21:34 lizmat defterm doesn't seem to be it, nor identifier
21:34 jnthn m: __END__
21:34 camelia rakudo-moar c2a57e: OUTPUT«===SORRY!=== Error while compiling /tmp/gTO0MJ_WAV␤Undeclared name:␤    __END__ used at line 1␤␤»
21:35 brrt anyway, that means only syncfile can use isatty
21:35 brrt (i'm wondering. can sockets be tty-ish?)
21:35 jnthn lizmat: In Perl 5, do they have to be followed by a semi?
21:35 lizmat brrt: afaik, no
21:35 brrt hmmm
21:35 lizmat jnthn: they're usually the whole line
21:36 lizmat so no semi
21:36 brrt but i suppose one can redirect a tty to a socket
21:36 colomon joined #moarvm
21:36 jnthn lizmat: Hmm. Trouble is that we probably wind up in syntax error land 'cus we'll try to parse what's after them
21:36 jnthn lizmat: You could maybe add them as terms in the grammar and call <.obs: ...>
21:36 lizmat well, I want to panic as soon as __END__ or __DATA__ are seen
21:37 lizmat that would be taking it too far, no?
21:37 lizmat I mean, I know how you feel about adding terms to the grammar :-)
21:37 jnthn token term:sym<p5end> { ^^ __END__ $$ <.obs: ...> }
21:37 lizmat ok, I'll try that
21:38 jnthn lizmat: Yeah, I'm not entirely thrilled with this solution
21:38 jnthn lizmat: but I can't think of one that won't be tripped up otherwise
21:38 jnthn TimToady++ is worth consulting for better ideas.
21:38 jnthn I pondered vws for a moment but...that's worse :)
21:39 jnthn At least this way the LTM-er can rule it out early
21:39 jnthn I suspect it may be worth doing if only 'cus it's not entirely obvious what the replacement is...
22:20 timotimo i experimented with making moar.h a "precompiled header"; that didn't seem to change build performance a single bit
22:20 timotimo hm, actually
22:20 timotimo i should make doubly sure i didn't do it worng
22:22 timotimo also, i should turn off ccache :)
22:25 timotimo yeah, seems like 0 change in performance
22:25 timotimo so maybe gcc does it automatically anyway ... or it refuses to use my .h.gch file
23:58 flaviusb joined #moarvm

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