github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 25 September 2013.
TimToady hmm, num80's? 01:23
01:56 FROGGS_ joined
diakopter num80's? 02:23
oh, now I get it 02:59
03:04 tokuhirom joined
dalek arVM: 43d5666 | jimmy++ | src/io/procops.c:
small fix to MVM_proc_clargs
 04:55
06:06 foo_bar_baz joined 08:05 cognominal joined 08:53 FROGGS joined 10:21 jnap joined
dalek arVM: 90336d8 | (Gerhard R)++ | src/core/interp.c:
Fix getwhere
 11:16
11:18 jnap joined
dalek arVM/ctypes3: 763b768 | (Gerhard R)++ | src/native/CArray.c:
Small fix for CArray
 11:29
arVM/ctypes3: f82e61a | (Gerhard R)++ | src/native/ (3 files):
Implement CStruct
arVM/ctypes3: a835227 | (Gerhard R)++ | src/native/ops.c:
Implement coffsetof
arVM/ctypes3: e30ea8d | (Gerhard R)++ | src/core/interp.c:
Fix getwhere
11:29 not_gerd joined
not_gerd o/ 11:29
poking vm internals from userspace: gist.github.com/gerdr/c59d0365251bdec34fa6 11:30
JimmyZ \\o 11:31
not_gerd: awesome! 11:32
not_gerd not sure how useful this will be, but definitely -Ofun 11:33
JimmyZ not_gerd: I think something like instrument for MoarVM written by NQP/Perl6 will be useful? 11:36
Just my guess though
not_gerd++, it really -Ofun 11:46
not_gerd and of course it's totally safe and has zero potential for abuse ;) 11:59
JimmyZ I like it 12:02
MVM_native_ptrcast is what I wanted before :P 12:08
dalek arVM: 65abf9b | (Gerhard R)++ | Configure.pl:
Quote config args with spaces
 12:38
not_gerd bye, #moarvm 12:39
12:40 not_gerd left 13:04 jnap joined 13:08 odc joined
diakopter pretty cool reading: spin.atomicobject.com/2013/09/26/ru...1-preview/ 14:12
JimmyZ we already has that GC? 14:18
FROGGS yeah 14:20
I wanna see such a blog post for MoarVM too :o)
diakopter cool reading not just for the gc 14:27
FROGGS true
even for us humans :o) 14:28
diakopter TimToady: local monkey parching ^ 14:33
oh, also in the article ;) 14:34
TimToady yes, I know about the egregious hack to make lexical scopes seem to work :) 14:37
if that's what you're referring to; haven't read the article 14:38
having not yet backlogged even...
diakopter good luck with the chinese text in #perk6 14:39
14:41 cognominal joined
TimToady that shouldn't be much of a problem for me, given I have a program that does LTM and vocab lookup for Chinese that usually gives me the gist of it 14:43
diakopter can you hook it into moritz weeblog 14:44
TimToady google translate would be more appropriate for that, since my approach still requires you to understand the various particles and syntax 14:47
it's very raw, and intended for someone who is actually interested in learning chinese 14:48
diakopter hm 14:49
14:52 jnap1 joined 15:12 jnap joined 15:17 FROGGS joined 15:34 benabik joined 16:31 not_gerd joined
not_gerd o/ 16:31
jnthn: I need a variant of assign that doesn't decontainerize its argument 16:32
is that something generally useful or should I add a ctypes specific op?
jnthn Sounds very odd to me. 16:35
not_gerd if I want to store the address of a CInt in a CPtr and it does a DECONT, it tries to store a P6int instead of the CInt 16:36
I could add assignnodecont or something for my specific use case 16:37
the question is, do we ever want to store the container object itself in another container?
s/and it does/and if it does/ 16:38
jnthn Sounds more like you want binding rather than assignment... 16:42
We only do the double-container thing in one place in Rakudo: .VAR 16:43
not_gerd as I have it right now, conceptionally it should be assignment 16:44
diakopter not_gerd: hi :)
not_gerd all scalar C types (CInt, CUint,...) are containers
jnthn o.O 16:45
not_gerd so a typed C pointer ends up as a container containing another container
diakopter: hi
jnthn Maybe there's a good reason for those to be containers but my gut reaction is "that sounds really wrong"... 16:46
diakopter jnthn: not_gerd may be using the word "container" differently than how you're accustomed 16:47
jnthn diakopter: Maybe, but probably not if we're talking about decont and assign.
not_gerd well, 6model objects that implement ContainerSpec
jnthn I'm vaguely confused how porting the stuff we need for NativeCall has ended up with something completely unrecognizable to me. 16:48
not_gerd NativeCall isn't my main motivation
it might or might not end up being used for that (or being scrapped altogether) 16:49
diakopter jnthn: it's like exploratory surgery :) 16:50
could be dangerous. could be amazingly informative or helpful.
not_gerd diakopter: did you see gist.github.com/gerdr/c59d0365251bdec34fa6
timotimo explosive surgery? =O
not_gerd I've got the dangerous part covered ;) 16:51
diakopter not_gerd: no but I saw the other one with the for loop
not_gerd I'm reading from the Collectable object header by (ab)using nqp::where
diakopter jnthn will love that :) 16:52
you should probably reassure jnthn that this would almost certainly be in an extension...
not_gerd it it's user-exposed at all 16:53
diakopter well if it's opcode-exposed it's user-exposed
unless you want to create security fence circles and trust levels like in .NET
not_gerd just make the verifier choke on it if no magic bit is set somehow 16:54
diakopter jnthn: not_gerd should probably reassure you this would be in a separate repo/extension :)
yeah
TimToady the closer we get to C, the more we need C-style lvalues as a concept; how this works out for safety is interesting, but we do need to address the issue from a semantic point of view 16:55
aside: the C programmer in me really hates to see := used to copy native values that are not pointers :) 16:56
timotimo because that's totally what := does in C, right? :P 16:57
not_gerd as I have it now, containers correspond to pointer indirection, with the first level hidden from the user
diakopter not_gerd: I mean, maybe the JIT thread uses this as part of its representation or some intermediate form 16:58
and the JIT thread is the only one that can use the extension.. ?
who knows
jnthn A C struct with a native int in just has the int sat there in memory. As an l-value, what you're really doing is talking about a pointer to that field.
TimToady right, but our type system doesn't know about that yet, afaik 16:59
16:59 FROGGS joined
not_gerd jnthn: correct 16:59
I assumed this was similar to how you wanted to do native attributes
FROGGS o/
not_gerd of course I might ahve misunderstood
jnthn nqp::assign_i(nqp::getattrptr_i($struct, StructType, '$!foo'), 42)
Is the kinda thing I'd expect it to "naively" compile down to 17:00
Which the optimizer can spot and say
nqp::bindattr_i($struct, StructType, '$!foo', 42)
diakopter yes, yes, yes. :)
jnthn In the simple cases
TimToady wants to be able to += an int attribute with an rw accessor
jnthn TimToady: Yes, that's also right in this problem space. 17:01
not_gerd my C types correspond to whatever gets returned by nqp::getattrptr_i($struct, StructType, '$!foo')
TimToady having been told about 15 minutes ago that: Cannot create rw-accessors for natively typed attribute '$!tie'
diakopter well I think now we're talking about where to place the model of the lowest levels.. whether it should be representable in bytecode
because teh optimizer will have to model it somehow 17:02
TimToady and if we get too close to C, will it be impossible to run on the JVM :)
diakopter nah it has Unsafe that can do anything
which we already use, afaik, for something there
it has equivalent offsetof and sizeof 17:03
and unsafe casting
and un-GC malloc
TimToady but really, a pointer is just an unboxed container... 17:04
jnthn not_gerd: OK, then I kinda see where it's going, but I don't think it wants doing with a REPR explosion.
diakopter right, like I said you can do the whole thing with extensie p6opaques
jnthn not_gerd: I mean, there's one P6int REPR which we compose to different sized types
diakopter extensive
not_gerd jnthn: well, I first had a single CScalar REPR that ended up with its own private vtable 17:05
diakopter but then again, you can implement all teh other reprs with extensive p6opaques
not_gerd I did not much like the result
is there any harm in such a REPR explosion?
jnthn Well, thing is, in Perl 6 people will probably write stuff like 17:06
er, do write stuff like
TimToady
.oO( has ptr[ptr[int]] $!intref; )
jnthn class Foo is repr('CStruct') {
diakopter heh.
jnthn has int32 $.foo;
}
diakopter reprs need to enforce preventing that... 17:07
jnthn There's a Perl 6 int32 type there, which has the P6int REPR
Which is just fine.
The REPR of a reference to a native field is not equal to the REPR of the inlined value, is all I'm saying.
s/field/attribute/ # hm, am I speaking C for Perl 6 :) 17:08
not_gerd actually, it's called member in C ;)
diakopter C# then :D
jnthn has to remember not to call fields attributes in C# 'cus attributes are something else and it confuses the heck out of everybody :)
diakopter attributes are more like naively implemented perl6 attributes 17:09
TimToady paraphrase: ptr[Foo] not commensurate with ptr[int32]
even if they happen to be the same address
diakopter jnthn: I would think that if it has a different containerspec and data layout, it needs its own repr? 17:10
jnthn diakopter: containerspec hangs off STable (and is per type), and a REPR can be type generic also 17:11
not_gerd well, ContainerSpec, REPR and StorageSpec are all orthogonal to some degree
jnthn Yes.
Just as VMArray can happily be an array of objects, or an array of num32, or an array of uint8 17:12
diakopter r: my int0 $oops
TimToady: at some point the number of bits in our native ints will be too laborious to type... :) 17:13
so maybe should use the log2...
TimToady doesn't work for num80 :)
and there are always aliases :) 17:14
diakopter 2 bits, 4 bits, 6 bits, a dollar
not_gerd also, there are to different ways to arrive at a num128
diakopter a ten o' clock scholar
not_gerd real IEEE quad precision and fake one via two double-precision values
LLVM calls these fp128 and ppc_fp128 17:15
TimToady not_gerd: sure, but an implementation would generally prefer one or the other
and Perl really only means "you may use 128 bits to store this" 17:16
unless we get serious about guaranteeing ieee semantics
if so, num128 is the real one, and fake128 or so is the fake one :) 17:18
but I'm not sure we're that serious
doubtless pragmas will happen 17:19
diakopter pragmae?
TimToady the default type system should try to hide most of the madness, but make it possible to get to the madness somehow... 17:20
TimToady wonders when C will get a double double double type...
not_gerd oO( use cthulhu ) 17:21
jnthn btw, will try and sort out the outer stuffs in Moar this weekend.
Provided I can concentrate enough.
jnthn woke up with a bad headache this morning :/ 17:22
TimToady and we aren't helping... :)
jnthn After that, I guess serialization is the main bootstrap blocker.
Though diakopter++ did a lot of the work on that already :) 17:23
dalek arVM/ctypes3: d356986 | (Gerhard R)++ | / (8 files):
Implement CPtr and add assignnodecont (for now)
 17:44
TimToady r/j seems to be testing out fine on my supercomputer at home; the ulimits are the same as host06, same arch, only difference is host06 is running 3.5.0-17-generic, while mine is running 3.8.0-19-generic 18:11
diakopter jnthn: at this rate, the entirey of Perl 6, including the entire runtime and all user code, could be compiled into this nqp-with-c-power lingo
TimToady so maybe something in the earlier kernel?
diakopter r/j? 18:12
oh.
haha.
TimToady ww
diakopter [Coke] I assume
FROGGS TimToady: I can force a spectest abort when I have a virtualbox vm running on my machine 18:13
diakopter which java do you have? host06 is ultra-latest
TimToady whatever openjdk supplies on Ubuntu
diakopter ewww 18:14
TimToady ewww, but it works better :)
diakopter mwilson@host06:~$ java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
true... it's possible we uncovered a bug in the jvm..
not likely, but...
FROGGS java -version 18:15
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
diakopter jnthn: at this rate, the entirey of Perl 6, including the entire runtime and all user code, could be compiled into this nqp-with-c-power lingo... and perhaps even a very small subset of that, at that. 18:16
... and if much of *that* can compile to C, it can be optimized ahead-of-time by real optimizers... 18:17
.oO( oh wait, much of it is already in C.. ) ;)
TimToady yeah, was gonna say, then it'll almost run as fast as it does now :)
next project, the kernel... 18:19
benabik C double double double is probably spelled `long long double` 18:22
arnsholt Is that different from a long double double? =) 18:24
benabik I would want to make long double a float128, and double double be the silly PPC thing. So a long double double would be two float 128s? 18:27
;-)
diakopter long double double double long double long double double long doublde
long double double double long double long double double long double
BinGOs shouting lager lager lager 18:28
FROGGS BinGOs++ # Underworld 18:34
nwc10 IIRC it got really quite fun on sparc linux, with compiler flags for how big you want your long double to be 18:39
TimToady orders a short long double with extra sugar 18:46
diakopter on the rocks 18:50
TimToady and char it a little while it's on the grill 18:59
dalek arVM/ctypes3: 9c89456 | (Gerhard R)++ | src/native/CStruct.c:
Small CStruct fix
 19:19
arVM/ctypes3: 8aa254c | (Gerhard R)++ | src/native/ (3 files):
Implement CUnion
19:25 grondilu joined
not_gerd bye, #moarvm 19:55
19:56 not_gerd left 20:29 FROGGS joined 21:51 moritz joined 21:54 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
22:10 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
diakopter jnthn: ping 22:14
jnthn diakopter: pong 22:27
diakopter jnthn: hi 22:31
jnthn hej
diakopter jnthn: so, I'm trying to think of a pathalogical test case that would allocate short-lived objects to try to force a GC run in the face of that optimization we discussed
jnthn: oh btw 22:32
jnthn diakopter: Hm, I wasn't thinking we'd be doing that any time soon...
diakopter oh; I thought it was a simple thing to try 22:33
jnthn Well, can try it I guess... 22:34
I'm just rather wary of donig too many clever things until Rakudo is running/spectesting
As it just gives more to debug on the way there...
diakopter yes, without a way to easily turn it off anyway 22:35
jnthn Of course, trying it in a branch hurts nothing, and tells us the actual complexity it causes (which I don't feel I can guess accurately)
diakopter you know 22:38
even more tricky
if the assign ref macro is placing the first escaping ref of an object into an object which also hasn't been flagged yet... it doesn't have to flag it! 22:39
jnthn yeah but when the outer one gets flagged...
diakopter oh yeah. :)
jnthn :)
I already pondered that one while we were discussing it :) 22:40
btw, made a start locally on working towards killing prior_invocation
With luck I can pull it off this weekend 22:41
22:46 benabik joined
diakopter jnthn: kewl :) 22:47
jnthn: 'course, if it simply recursively marks using some variant of the gc_mark thing... ;) 22:52
23:20 BenGoldberg joined 23:56 foo_bar_baz 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!