01:48 ilbot3 joined 02:01 JimmyZ_ joined
nebuchadnezzar erf, the 2015.06 release is missing updates of the doc/ChangeLog and MoarVM FrontPage 04:48
05:34 TEttinger joined 07:41 FROGGS joined
timotimo that's correct 07:49
we put in the changelog stuff right after the release 07:50
and the front page just didn't get updated yet, i suppose
nebuchadnezzar thatk's OK, I just prepared the 2015.06 Debian package, dod has something to do before uploading it 08:05
I'll work on nqp next
timotimo \o/ 08:24
nebuchadnezzar timotimo: yes, [ptc] will need to clean up the packaging branch before. 08:43
10:16 lizmat joined 11:01 FROGGS[mobile] joined
FROGGS[mobile] btw, I started at using dyncall/libffi conditionally 11:01
I know it is not important, but I wanted to tackle it 11:02
and I want to merge openpipe3 in the next days, after adding a bunch of tests 11:03
timotimo: isnt shlex already possible with Str->Grammar->run()? 11:05
FROGGS nwc10: how long does it take to build moar+nqp+rakudo on a raspberry? 11:11
nwc10 on a Rasberry Pi B, v2 - I forget. But it was less than an evening.
FROGGS ahh, good to know :o) 11:12
a friend of mine is going to try that
nwc10 on an original B, with only 256Mb - a lot of swapping, and just over 24 hours
timotimo well, yeah, you can use a grammar for it. but it better be a pre-made grammar that has a very big test suite so that things like a very recent php bug don't happen
to our users or us
nwc10 one of the nativecall tests still failed, last I tried it 11:13
it's getting a char wrong - off by 256
FROGGS timotimo: ahh, so shlex basically is a premade grammar?
nwc10 forget whether the wanted result was positive, and the got value negative, or the other way round
timotimo yeah, exactly that
FROGGS nwc10: same as on osx perhaps
nwc10 but it looked like an (un)signed char mixup
timotimo The shlex class makes it easy to write lexical analyzers for simple syntaxes resembling that of the Unix shell. This will often be useful for writing minilanguages, (for example, in run control files for Python applications) or for parsing quoted strings.
shlex.split(s[, comments[, posix]]) 11:14
Split the string s using shell-like syntax. If comments is False (the default), the parsing of comments in the given string will be disabled (setting the commenters attribute of the shlex instance to the empty string). This function operates in POSIX mode by default, but uses non-POSIX mode if the posix argument is false.
11:15 Ven joined 12:24 Ven joined 12:53 Ven joined 14:04 brrt joined
brrt \o 14:05
timotimo o/
brrt how is life here :-) 14:06
i feel like i'm finally inching closer to understanding dynasm 14:08
although at the same time it becomes more clear why adding variable regs for x64 wasn't implemented yet
also, lua is a thoroughly funky language 14:09
jnthn o/ brrt 14:18
brrt \o jnthn
jnthn Life ain't bad, though packing is a tedious task :)
brrt yes, it is, i can imagine 14:19
although i kind of expect you to have taken the possibility of an international move into account when filling your last appartment, given your history so far :-) 14:20
14:21 Ven joined
jnthn Aye, though seems I still managed to accumulate some things. 14:22
brrt it's surprising how fast that goes, isn't it
jnthn Indeed 14:27
brrt hmm 14:31
would it be acceptable if i 'fixed' the x64-variable-register case for only a subset of cases?
as in, it's relatively easy to do for the 64-bit-gpr case
jnthn Well, depends what the upshot of that is, I guess... 14:32
brrt because they always use a rex register, which simply need a bit set
jnthn It'd restrict the number of registers we can use, iiuc? 14:33
brrt no, it restricts the ways in which we can use the registers 14:34
jnthn Ah
brrt as in
all GPR's basically require a REX bit for 64 bit mode
the register number is typically encoded in octal somewhere 14:35
so that you can only address 8 registers that way
if you want to address the upper 8 registers of the x64, you need to set a bit in the REX byte to indicate that
if you want to address a register in 32 bit mode, you don't need a REX byte at all, unless you want to address the upper registers in 32 bit mode 14:36
so in the one case you're simply OR-ing bits in, and in the other case you need to add a new byte 14:37
this is also doable, but relatively complex, and not necessary for the 64 bit case
i'm not 100% sure that this would be sufficient, though 14:38
jnthn How much impact does doing the simpler thing now have on the quality of code we'll produce? 14:39
And is it possible to do better later by doing the harder bits of the dynasm changes later, without having to come back and do a lot of re-work? 14:40
brrt well...
the consequence of doing the simpler thing is that it restricts the code generator to pick lower registers for all 32/12/8 bit operations 14:41
that is a restriction that has to be hardcoded, but i think could be removed relatively easily 14:42
the code generator picks registers based on availability (by definition) 14:43
jnthn And for 64-bit things we'd not have the restriction?
brrt not as far as i can tell
jnthn Doesn't sound so bad, given pointers and integers are 64-bit for us
brrt there are only very few operations that are 64 bit default (and hence would not have a rex byte) 14:44
if we'd ever did that we can error out in the dynasm code generator, since dynasm knows (keeps it in a table)
timotimo and nums are 64bit, too (though those are mmx registers anyway)
er, sse registers of course
fpu registers* 14:45
brrt yes.... i haven't really checked that out, though
timotimo does that make sense to say?
brrt it makes sense but for the historical use of that name to mean only the x87 co-processor 14:46
:-)
timotimo jnthn: gist.github.com/timo/a1343649c3f74b8bd6ff - this was my first instinct to put into the binding lowerer, but it gets me "cannot find method "returns" in the optimizer :\
perhaps .default is supposed to either be a value or an Op? 14:50
brrt i will admit i'm having a tremendous amount of fun deciphering the whole dynasm codebase
timotimo :)
sounds good 14:53
oh 14:55
it exploded because i had to put ( ) around my $blah := QAST::Var.new( ... )
brrt huh, i have a new, and completely evil idea 15:04
timotimo that sounds great!
do tell
brrt although, it might be a demonstration of something that 'shouldnt work' 15:05
well, if we throw an adhoc exception, from MVM_exception_throw_adhoc, we never return, don't we?
timotimo that's right 15:06
brrt that means our current stack frame is void
doesn't matter anymore what happens to it
well, in that case we can jump directly to MVM_exception_throw_adhoc using a conditional jump 15:07
actually, no, i'm wrong
you can't do that
because i'm jumping to the function as a pointer in a register 15:09
but if we'd load the pointers from a section or so, or at link time 15:10
then we could
and that'd make adhoc exceptions ever so slighlty cheaper 15:11
timotimo i cannot quite follow :S
brrt currently my routine is: do some test, jump-conditionally over the block, call exception 15:12
however, we can also do
do some test, move the arguments conditionally, jump conditionally
to the exception function 15:13
there's no reason to use call rather than jmp
it's a completely useless optimizaton that of invoking a routine that will spend a large multiple of that time in exception handling :-) 15:14
jnthn If we have hot-path code throwing adhoc exceptions, something's wrong 15:15
timotimo: Glad you found it while I was afk :)
timotimo it seems i did it kind of right 15:18
the only spec tests failing are known flappers or things that check for stderr output, which is where my diagnostics go at the moment
so i'll implement the same thing for % sigiled vars and see about the lexical lookups of types and such 15:19
jnthn: nominal_generic contains the name that i'd have to lexically look up in typevar scope? 15:26
jnthn timotimo: Sounds good.
timotimo: Um...maybe 15:27
:)
jnthn can't remember at all
I thought it was just a flag
brrt we can use the extern functionality of dynasm to deal with function pointers somewhat more elegantly 15:40
www.corsix.org/content/calling-exte...x64-dynasm <- or this, of course 15:43
i think i like that one best 15:46
or we can use jmp extern foo, which also works, but uses 32 bit immediates 15:48
and then we have to be sure the pointer difference between rip and the function pointer fits in 32 bits. good chance for this, but still 15:50
timotimo jnthn: trying to put something very similar in for handling a %-sigiled param's default value gives a whole lot of spectest fallout :\ 15:59
i'm getting P6opaque: no such attribute '%!elems' 16:00
for: submethod BUILD (:%!elems) { self }
it's inside a role, just above that line is "has %!elems" 16:01
ah, same thing for @-sigiled params, but they never seem to happen:
perl6 -e 'role Test { has @!foo; submethod BUILD(:@!foo) { self } }; class Bar does Test { }; Bar.new();'
P6opaque: no such attribute '@!foo' 16:02
jnthn I'm guessing that you're trying to use the type var rather than look up ::?CLASS 16:06
timotimo i'm not trying anything! :P 16:08
i only added a .default and removed the return 0 ;)
jnthn I mean for the bindattr 16:09
timotimo it looks like this: QAST::Var.new( :name('self'), :scope('lexical') ), 16:10
and it's a p6store rather than a bindattr
jnthn And the next line?
Ah, yeah, but it must getattr it, or have a scope attribute var?
timotimo QAST::WVal.new( :value(%info<attr_package>) ) 16:12
oh, yes, that's a Var 16:13
jnthn That'll be the issue
timotimo my bad
and it's scope attribute
jnthn That WVal will be a type var
You'll need to do something like test %info<attr_package>.archetypes.generic or so
And emit a lookup 16:14
I think you can get the name to look up
oh, .HOW before .archetypes
And maybe .HOW.name is the name to look up
timotimo i haven't heard of the archetypes thing yet 16:15
jnthn It's a kind of "what properties does this kind of type have" mechanism
timotimo ok, i'll test for the .archetypes.generic to decide whether to emit the same p6store with the val as we had it before, or something where i generate code to look up the %info<attr_package>.HOW.name lexically? 16:17
or should i be looking it up via $*W.find_symbol?
is attr_package basically going to tell me if we're inside a role or a class? or something like that? 16:18
or is it more about @ -> Array, % -> Hash? 16:19
jnthn timotimo: You can't look it up via find_symbol 'cus it's too early
That's the trouble
It's about code inside of a role 16:20
timotimo ah
it should be looked up after the composition
hm. but if i look at the .HOW.name, wouldn't that just be ClassHOW? 16:22
tbh, i don't really know what is put into the attr_package
jnthn The type object of the surroudning class
timotimo that seems like it could be a typevar scoped QAST::Var 16:23
jnthn m: role R[::T] { has $!a; method m($!a) { } }; R.^lookup('m').signature.parameter.say
camelia rakudo-moar be122a: OUTPUT«Method 'parameter' not found for invocant of class 'Signature'␤ in block <unit> at /tmp/yTCOo8jaUe:1␤␤»
timotimo or do i have to go through a PseudoStash or something heavy like that?
jnthn m: role R[::T] { has $!a; method m($!a) { } }; R.^lookup('m').signature.parameters[1].say
camelia rakudo-moar be122a: OUTPUT«Method 'parameters' not found for invocant of class 'Signature'␤ in block <unit> at /tmp/TU4zv0cY1x:1␤␤»
jnthn m: role R[::T] { has $!a; method m($!a) { } }; R.^lookup('m').signature.params[1].say
camelia rakudo-moar be122a: OUTPUT«Any $!a␤»
jnthn m: role R[::T] { has $!a; method m($!a) { } }; nqp::getattr(R.^lookup('m').signature.params[1], Parameter, '$!attr_package').say 16:24
camelia rakudo-moar be122a: OUTPUT«===============================================================================␤The use of nqp::operations has been deprecated for non-CORE code. Please␤change your code to not use these non-portable functions. If you really want␤to keep using nqp:…»
jnthn m: use nqp; role R[::T] { has $!a; method m($!a) { } }; nqp::getattr(R.^lookup('m').signature.params[1], Parameter, '$!attr_package').say
camelia rakudo-moar be122a: OUTPUT«Method 'say' not found for invocant of class '$?CLASS'␤ in block <unit> at /tmp/DcqND3S3Ky:1␤␤»
jnthn m: use nqp; role R[::T] { has $!a; method m($!a) { } }; nqp::getattr(R.^lookup('m').signature.params[1], Parameter, '$!attr_package').^name
camelia ( no output )
jnthn m: use nqp; role R[::T] { has $!a; method m($!a) { } }; nqp::getattr(R.^lookup('m').signature.params[1], Parameter, '$!attr_package').^name.say
camelia rakudo-moar be122a: OUTPUT«$?CLASS␤»
jnthn timotimo: ^^
timotimo ah
jnthn And yeah, typevar scoped QAST::Var node instead of the WVal, with that name. 16:25
timotimo excellent
jnthn And then spesh can do Nice Things :)
brrt afk 16:26
16:27 brrt left
timotimo m: use nqp; role R[::T] { has $!a; method m($!a) { } }; nqp::getattr(R.^lookup('m').signature.params[1], Parameter, '$!attr_package').^archetypes.generic.say 16:32
camelia rakudo-moar be122a: OUTPUT«Too many positionals passed; expected 1 argument but got 2␤ in any archetypes at src/gen/m-Metamodel.nqp:269␤ in block <unit> at /tmp/ogtIDu4q09:1␤␤»
jnthn .HOW.archetypes 16:33
timotimo right
jnthn It's a property of the kind of type, rather than of the type itself
timotimo i got it right in my code :)
perl6 -e 'role Test { has @!foo; submethod BUILD(:@!foo) { self } }; class Bar does Test { }; Bar.new();'
works now
jnthn A weird distinction, I know, but by this point we're talking meta-meta-programming, so... :) 16:34
timotimo :)
i'm going to have to put that on my resume 16:35
jnthn ;)
Hm, think I'm going to cook chili :)
timotimo spec testing now
that sounds nice 16:36
jnthn didn't fix the bug he set out to 'cus he found a different but related one in the process...
timotimo Hash Hash, Array! 16:38
16:41 oetiker_ joined
hoelzro timotimo: interesting historical fact: former_interactive was because I removed interactive for the Linenoise stuff, and MoarVM + NQP got really angry when I tried to remove it 18:16
timotimo hehehe 18:28
japhb hoelzro: Are you still working on C++ bindings? 18:35
hoelzro japhb: I was just trying out FROGGS' 18:36
I did a little bit of fixing on them
japhb Do you happen to know the current state? 18:37
hoelzro it works pretty well 18:40
I found an issue with it when trying to bind Xapian, but I haven't dug into it
I think people just need to start playing with it
18:45 zakharyas joined
dalek arVM: c01cbbe | hoelzro++ | ports/macports/Portfile:
Update macports Portfile to 2015.06
 18:46
japhb Oh, so it's workable, cool! I thought it was still WIP.
Are there docs, tests, and/or examples I should look at? 18:47
hoelzro japhb: it's not merged, but it's usable enough
japhb has SO much C++ to bind
Ah, OK, that's what was missing
hoelzro japhb: there's a few C++ tests in the rakudo cpp branch
[Coke]: I just updated the Portfile; could you submit that upstream to the Macports folks? 18:48
japhb hoelzro: Will the Rakudo cpp branch build the right branches of nqp and moar, or do I need to build them manually? 18:49
hoelzro japhb: I think you need to specify --gen-moar=cpp2 --gen-nqp=cpp
japhb If it's workable, now that we're just past a release, perhaps we should merge?
hoelzro: Ah, OK
japhb wonders how long since the branches have gotten merged back from the mainline 18:50
hoelzro it's been a while 18:52
I think we could probably merge them into master/nom
FROGGS would be a better judge of that, though
once he chimes in, we can either merge/rebase from master/nom, or merge into master/nom 18:53
japhb Sounds like a plan
timotimo hmm, so if nominal_generic is set, we have the $type in nominal_type ... so do i go via the nominal_type's .HOW.name and look that up locally as a typevar, just like for the generic things? but then what's the difference?
FROGGS hoelzro: I think it is mergable to master/nom 18:54
japhb excellent 18:55
FROGGS hoelzro: for one because it does not inflict other stuff, and we need more users on the cpp stuff to get it straight
hoelzro FROGGS: would you like to do the honor?
agreed
FROGGS (at rakudo level)
let me review the branches, and I'll merge in the next days 18:56
japhb Thank you, FROGGS!
hoelzro FROGGS++
FROGGS but don't tell jnthn :P
hoelzro hehe 18:57
nwc10 it's OK. yoleaux isn't here. 18:58
timotimo oh. "what's the difference?"? one is for binding values into the correct something, the other is for type-checking against the right thing 19:05
jnthn: does it sound like a good idea to inspect the postconstraint of a parameter for inline info and inlining whatever code may be in it into the generated binding code? 19:07
implementing "is copy" for hashes and arrays seems to be doable as well; at least for the array it's just nqp::create the Array, then .STORE the deconted incoming value and presto! 19:11
pretty much the exact same thing for Hash, apparently
hmpf. i implemented that and the code path only gets hit 4 times in the core setting 19:50
20:05 d4l3k_ joined 20:07 BinGOs_ joined 20:17 BinGOs joined
FROGGS lol, I can haz libffi :D 20:19
20:21 d4l3k_ joined 20:22 camelia joined
timotimo oooh way cool 20:25
FROGGS timotimo: two single tests pass 20:26
timotimo wow! that's more than one! 20:27
FROGGS :D 20:28
well, I can make all the simple tests pass, but I want to reorganize it so it is a little bit more efficient 20:29
20:35 BinGOs joined 20:37 vendethiel- joined 20:39 flussenc1 joined 20:40 flussenc1 joined, jnthn_ joined 20:41 sivoais_ joined
jnthn_ gah, messages I typed before disconnect prob got lost, since they ain't in the log. 20:46
20:37 < jnthn> timotimo: I'd leave spesh to inline post-constraints tbh
20:38 < jnthn> timotimo: In fact, I'm thinking about making compile-time
inlines of sub/multi calls be only about natives
20:38 < jnthn> timotimo: 'cus we've spesh/indy these days :)
20:38 < jnthn> FROGGS: Nice work! :)
timotimo oh! 20:47
jnthn_ Also, apparently there's two of me now
jnthn: Go away, dammit!
timotimo perl6 will be finished twice by christmas!
nwc10 no, wait, 2 of you will be twice as productive?
FROGGS jnthn: no! got more in here!
20:48 tadzik joined 20:58 pyrimidi_ joined
timotimo first stab at nominal_generic and the core setting is still compiling 21:01
it's emitting generic checks all over the setting now ... for ::?CLASS a whole bunch of times, but also for NuT, DeT, TValue, and TKey 21:04
well, in 32 places 21:05
doesn't sound like terribly much, but maybe it's all right
though that number doesn't say if the rest of these signatures got lowered properly
hm. out of these 32, only 25 signatures actually end up lowered in the end 21:08
time for a spec test and commit+push 21:09
i'm glad i've accomplished something 21:10
jnthn :) 21:11
timotimo++ 21:12
21:12 flussence joined, sivoais joined
timotimo looks very good 21:12
what should i tackle next? :)
maybe type captures?
that'd probably be something like a nqp::getwhat and bind that to the right named lexical 21:13
21:13 ggoebel2 joined
timotimo ah, it's just nqp::what 21:13
21:14 [Coke]_ joined
timotimo interesting, they can have defaults, too. but the combination of type capture and default value is probably already covered if i just implement type capture and let the default value handling take its regular course 21:15
21:16 lizmat_ joined
timotimo do we actually have something like ::T = Int $foo = 5? %) 21:17
21:18 Util_ joined, hoelzro joined, arnsholt_ joined, FROGGS joined
masak that makes some sense to me, but I'd be surprised if it parses. 21:18
std: sub foo(::T $foo = 5) {}
camelia std 28329a7: OUTPUT«Potential difficulties:␤ $foo is declared but not used at /tmp/Q0c3Q6eWI6 line 1:␤------> sub foo(::T ⏏$foo = 5) {}␤ok 00:00 139m␤»
masak std: sub foo(::T $foo = 5) { $foo #`[grr] } 21:19
camelia std 28329a7: OUTPUT«ok 00:00 141m␤»
masak std: sub foo(::T = Int $foo = 5) { $foo #`[grr] }
camelia std 28329a7: OUTPUT«===SORRY!===␤Default expression must come last at /tmp/hC3T3oJ66v line 1:␤------> sub foo(::T = Int ⏏$foo = 5) { $foo #`[grr] }␤Unable to parse signature at /tmp/hC3T3oJ66v line 1:␤------> sub foo⏏(::T = Int $foo = 5) { $foo #`[grr]…»
masak right.
timotimo well, it'd be kinda hard to have a different default value for the type compared to the type of the actual default value for the ... value
masak perhaps there's even some good reason not to allow a default there. I'd suspect so, actually. 21:20
21:20 avar joined 21:21 tadzik joined
jnthn m: sub foo(::T $foo = 5) {say T}; foo 21:22
camelia rakudo-moar be122a: OUTPUT«(Int)␤»
jnthn Even works :)
21:22 oetiker joined
timotimo i'll just have to be careful about the code path taken for ::T $foo = 5 vs ::T = Int 21:23
masak m: sub foo(::T $foo = 5) { say T }; foo "OH HAI"
camelia rakudo-moar be122a: OUTPUT«(Str)␤»
21:28 psch_ joined 21:29 oetiker joined 21:32 dagurval_ joined 21:35 ashleyde1 joined 21:38 masak_ joined
timotimo i'm getting pretty tired, maybe i'll continue this tomorrow 21:38
jnthn timotimo: Wise :) 21:40
timotimo jnthn: anything else you'd recommend i do near that piece of code? 21:41
23:05 btyler 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!