02:29 vendethiel joined 06:02 dalek joined 07:04 domidumont joined 07:09 domidumont joined 07:21 dalek joined 07:54 dalek joined 08:30 kjs_ joined 08:32 geekosaur joined 08:41 zakharyas joined 09:13 brrt joined
brrt good * 09:18
moritz \o brrt 09:20
brrt \o moritz 09:21
GPW done yet?
moritz no, still running
and tomorrow is hackathon
act.yapc.eu/gpw2016/wiki?node=Hackathon several p6 wolks have signed up
brrt cool 09:23
brrt should look up whoever thomas mann really was
moritz a giant of German literature 09:28
contemporary
kinda
erm, no, died 1955
Nobel Prize winner 09:29
brrt i see his name on lots of streets 09:30
so that explains
jnthn But how many verbs could be stack up at the end of a sentence? :)
brrt they're germans, you have to be tolerant about grammar 09:31
:-P
damnit 10:00
the break is not as predictable as i had assumed
jnthn "the break"? 10:04
10:07 FROGGS joined
brrt json-fast breaks under the expr jit 10:13
i already see the problem
or, i think i do
can i temporarily shut off precompilation?
jnthn "no precompilation;" at the top of the script 10:14
brrt hmm 10:15
env var maybe
?
hmm, oh well 10:32
hmmm 10:37
tis as i expected 10:38
not handling frame handler labels correctly
annoying
jnthn ah..."fun"
brrt not really 10:39
i can't make as strong claims about the ordering of labels etc 10:40
jnthn Ah, and the order can matter
brrt it's actually the end of multiple frame handler blocks 10:41
that explains the sequence of dynamic control labels
why would a getlex have a deopt_one annotation 10:42
jnthn brrt: Anything we can insert a guard after gets one 10:43
brrt but we're not doing anything with that it seems 10:44
except for on actual guards 10:45
FROGGS jnthn: when I pass an &foo to a nativecall function... how do I know it is callable? I only see it as a P6Opaque
jnthn "know" in what sense?
moritz ~~ Callable? 10:46
jnthn See the isinvokable op's implementation for one answer though...
FROGGS moritz: does C have smartmatch now? :o)
brrt thinks inspecting the REPR is the answer
moritz FROGGS: I misread "nativecall function" as a funtion within NativeCall.pm, I think 10:48
FROGGS yeah
jnthn Why do you want to check, ooc? 10:49
FROGGS I'm attempting at making function pointers work btw
jnthn In structs?
FROGGS src/core/nativecall.c:496 P6opaque invokable=1 \o/
jnthn: no, currently like this:
sub ForeignFunction() returns int32 is native('./19-function-pointers') { * } 10:50
sub ReturnFunctionPointer() returns Pointer is native('./19-function-pointers') { * }
my $ptr = ReturnFunctionPointer();
nativecast(&ForeignFunction, $ptr);
jnthn ah
FROGGS dunno if that concept can work out though
but I'll try and learn something
(I'm doing this now because the inlined+sized arrays in Structs are a bit too big for me currently) 10:51
so I think I need to duplicate the logic of MVM_nativecall_build... 11:00
or, hmmm 11:01
brrt is kind of annoyed at the uselessness of smart-grid literature 11:13
long story short, i need a trip back to the drawing table to deal with many-labeled things correctly 11:17
moritz and here I though you meant smart enegery transport grids (which is what I associate with "smart grid") :-) 11:18
jnthn You've got the power!
brrt yeah, i menat that too, i'm looking into the topic for my second thesis 11:19
moritz ah 11:21
brrt (to be pedantic, 'smart power transmission' != 'smart grid'; the former is about using power lines cleverly, the second is about matching load and generation in a distributed fashion) 11:22
whereby matching means both 'managing distributed generatorion, dispatchable loads, and storage 11:23
FROGGS lol, it works /o\ 11:25
brrt and the uselessness is in that smart grid literature is always a): some guy from a compsci background that wants to play with distributed systems, b):some guy from a utility that wants to have permission to shed loads whenever he feels like it, c): an economist who wants to talk about price signals
FROGGS is it some sort of record to implement function pointers within 45 minutes (the hacky way) ?
brrt not bad :-) 11:26
FROGGS :o) 11:27
brrt and none of these things comes near solving the central problem, which is, how do we ensure that distributed generators and consumers _collaborate_. </rant>
jnthn FROGGS++ 11:30
moritz brrt: sounds very much like something my father in law would say (who has been building dams for power plants and pump storage stations for 35 years or so) 11:31
FROGGS problem is that I somehow need to return a fresh/copied function from nativecast...
brrt that's a cool job moritz :-)
FROGGS currently it messes with the original function definition, which is the "target type" of the cast
jnthn FROGGS: A straight clone should do it, I think 11:32
FROGGS nqp::clone in NC.pm?
moritz brrt: ... except when it takes you to Teheran during the first Gulf war, for example :/ 11:33
but in general, yes
brrt was iran involved in that?
moritz that was between Iran and Iraq, yes
(unless I miscounted the Gulf wars, but that's the one I'm talking about)
FROGGS jnthn: \o/ 11:34
brrt thought it was between iraq and kuwait 11:35
but i'm not all that familiar with it
moritz oh
brrt well, my familiarity extends to 'desert strike'
moritz en.wikipedia.org/wiki/Iran%E2%80%93Iraq_War that's the one I meant 11:36
brrt a lot of countries against iraq, anyway
anyway,, lunch & 11:37
jnthn
.oO( Sad dam Hussein )
FROGGS if I want to change the signature of an op... shall I add a new one these days? 11:41
I need to pass an extra arg
jnthn Which op? 11:42
FROGGS nativecallbuild
jnthn Why does it need an extra arg, when it already takes a hash describing what to do?
FROGGS ahh, of course 11:43
I looked at that already but only spotted the arg_info hash
12:24 kjs_ joined 13:01 geekosaur joined
dalek arVM: c20b5a3 | (Simon Ruderich)++ | src/io/sync (2 files):
syncpipe: implement .native_descriptor introspection
 14:06
arVM: ef19050 | jnthn++ | src/io/sync (2 files):
Merge pull request #345 from rudis/master

syncpipe: implement .native_descriptor introspection
arVM: ada3752 | FROGGS++ | src/ (3 files):
handle C function entry point in nativecall_build when supplied

With this we can now let a Perl 6 native subroutine use a given memory address of a C function.		 14:20
14:35 FROGGS[mobile] joined 15:00 brrt joined 16:06 cognominal joined 16:36 FROGGS joined 16:44 FROGGS_ joined 16:49 FROGGS__ joined
timotimo FROGGS: i find it strange to have the target of the nativecast be an actually defined sub that has an "is native" on it; have you considered just taking a Signature instead? 17:22
because if you "is native('some library')" for a function pointer target, that confuses me, because that function isn't actually likely to be defined in that native library
FROGGS hmmm 17:23
good point I guess
17:41 FROGGS[mobile] joined 18:05 domidumont joined
lizmat unicode 9.0 summary of changes (draft): unicode.org/versions/Unicode9.0.0/ 18:43
[Coke] we don't say what version of unicode we support programmatically, do we/ 18:53
?
timotimo that would be an interesting little tidbit to have 18:54
FROGGS[mobile] more "interesting" would be a "use unicode:ver(v6.3)" 19:08
lizmat isn't that somewhere in $*VM ? 19:25
[Coke] wonders why $*VM is of type VM and not something Hashy. 19:29
lizmat [Coke]: it does Systemic, and that was one of TimToady's inventions
the AT-KEY interface was actually deprecated before 6.c 19:30
[Coke] unfortunately, it means you can't .keys it.
or introspect it, that I can fight with from the REPL.
lizmat m: dd VM.^attributes>>.name # [Coke] ?? 19:31
camelia rakudo-moar b703d6: OUTPUT«("\$!config", "\$!prefix", "\$!precomp-ext", "\$!precomp-target", "\$!precomp-dir", "\$!name", "\$!auth", "\$!version", "\$!signature", "\$!desc")␤»
lizmat m: dd VM.^methods>>.name 19:32
camelia rakudo-moar b703d6: OUTPUT«("BUILD", "platform-library-name", "Str", "gist", "config", "prefix", "precomp-ext", "precomp-target", "precomp-dir", "name", "auth", "version", "signature", "desc")␤»
[Coke] lizmat: thanks. I never would have thought to try that.
20:48 cognominal joined 20:49 cognominal joined
jnthn The UAX #29 changes will impact NFG 20:54
There's some RTs already asking about emoji with regard to NFG 20:55
My answer was going to be "we define NFG by UAX #29". 20:56
But seems UAX #29 is going to make the changes that the RTs ask for.
So, that's nice.
My answer is still that I guess, but it's more like "we'll fix this as part of updating to Unicode 9"
Other than that, doesn't look like it'll be anything outside of what our scripts handle already. 20:58
*script handles
timotimo do we want to support reverting to older versions of the unicode standard in lexical environments? 21:12
jnthn No 21:13
Well, I don't :P
Maybe somebody has a really good use case
But I've yet to hear one besides "we can show it off" :P 21:14
And the infrastructure to do it would be quite annoying.
(Shipping older Unicode DBs, lazily loading them, etc.)
timotimo ensuring the behavior of a script doesn't change when updating to a newer rakudo :) 21:15
jnthn I'd think the Unicode stability policy covers most of the important bases though 21:16
timotimo good
jnthn They've constrainted themselves a good bit in what they can change.
21:25 colomon joined 21:52 mojca joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!