github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 8 September 2013.
00:09 cognominal joined 01:08 LWA joined 01:42 benabik joined 02:45 {amon} joined 02:54 raiph2 joined 06:01 LWA joined 06:11 FROGGS joined 06:13 sorear joined
FROGGS o/ 06:19
.tell diakopter Wut? irclog.perlgeek.de/moarvm/2013-09-09#i_7563809 06:21
yoleaux FROGGS: I'll pass your message to diakopter.
06:21 LWA joined
diakopter FROGGS: well I took that part back sortof 06:52
FROGGS yeah 06:53
diakopter I think it needs to call unwind from where it is to the start frame of the throw
06:53 not_gerd joined
FROGGS what I'd like to know is how I could make the usage of ah here safe: github.com/MoarVM/MoarVM/commit/9d...4b5#L3R329 06:53
not_gerd o/ 06:54
diakopter (and then swap back in the old stack, so to speak)
FROGGS diakopter: it does that (unwind)
diakopter oh; I missed that
FROGGS in the last link at line 340
err, 339
body.origin is the frame of the throw 06:55
diakopter I don't see it
FROGGS github.com/MoarVM/MoarVM/commit/9d...4b5#L3R339
diakopter I think it needs to call unwind_to_frame
FROGGS and the activehandler takes this frame (and the goto_offset) when leaving the CATCH
that happens in `unwind_after_handler` or what the function is called 06:56
diakopter oh.. /me looks
JimmyZ \\o not_gerd 06:57
FROGGS github.com/MoarVM/MoarVM/blob/mast...ons.c#L178
diakopter: ^^
jnthn "(and then swap back in the old stack, so to speak)" - no, the old stack is still there...
We run exception handlers *on the top of the stack* and then unwind. In the resume case, we just don't unwind to where the handler was found. :)
FROGGS at line 160ff the handler gets registered, and when we hit a nqp::resume, I just update the frame and goto_offset 06:58
jnthn didn't look at patch yet, gotta teach...
FROGGS jnthn: moarning, you were able to sleep?
not_gerd I assume it would be bad to do type conversions via get_boxed_ref?
diakopter oic
jnthn FROGGS: kinda :/ 06:59
FROGGS :/
diakopter not_gerd: yeah, coerce.c is best
FROGGS the only unsafe thing I see is this: github.com/MoarVM/MoarVM/blob/mast...ons.c#L338 07:00
it just expects that a handler was already registered for that frame 07:02
diakopter not_gerd: though some of those can call back into bytecode
not_gerd trying to figure out how best to do the conversion from a generic CPointer to more specific reprs like CScalar, CArray, ... 07:03
custom ops it is
diakopter well, whatever you choose needs to be implementable on jvm, and arnsholt needs to be on board (not to mention jnthN), and all that :)
not_gerd I'm still figuring out the details 07:04
I believe I'm on the right track here
diakopter though sorear++ has proven that almost any non-local control flow can be implemented on the jvm
not_gerd one CPointer repr that can box/unbox to int (for manual pointer arithmetics) and can be converted to/from the more specific reprs CScalar, CArray, CStruct, CUnion, CFlexibleStruct 07:05
diakopter but as long as whatever custom ops you add are either also implemented on the jvm in nqp::, or hidden behind each's qast compiler for other existing/new functions... 07:06
not_gerd they don't exist on JVM yet, but if I can get arnsholt on bord, that won't remain so ;)
diakopter I wonder how much the struct ones will reproduce p6opaque
not_gerd to some degree, they will 07:07
diakopter is it possible to simply use p6opaque instead?
(with the other types inlined) 07:08
since you can control every bit in a p6opaque body
not_gerd might or might not be a good idea
diakopter I suspect jnthn would prefer that sort of approach
the thing about p6opaque is it uses the copy_to and other body-oriented "repr functions" to inline other types' bodies 07:09
so in most cases you'd be inlining CPointers and such 07:10
the interesting thing there is you wouldn't want to allow inlining any reference/container types.. you wouldn't want any managed pointers in those bodies 07:12
to ensure the managed pointers could never escape to unknown native code
I mean, if we're talking about native code that uses the moarvm public .h, then it should be integrating using extops 07:13
(or its own custom reprs)
er, *and* 07:14
oh, hm
actually you couldn't pass a pointer to the body of the CStruct if it was a p6opaque
unless it was in the "body pointer" slot... 07:15
which would be fine, since it'd already be a malloc'd area
yeah, the body pointer slot approach would work nicely 07:16
you wouldn't have to worry about pinning managed memory
not_gerd note that the way I'm doing it, CStruct is the name of the repr that references a C struct, same as it is right now 07:18
diakopter TimToady: ahoy
not_gerd I'm going to add something like CBlob that is inlineable
these could be managed by p6opaque
diakopter it's just CStruct... well does it know about its slots? 07:19
not_gerd yes
diakopter so its already reproducing much of p6opaque
arnsholt What's the use case you're aiming for here?
I'm all for suggestions, but what is the motivation for a complete reworking of the internals? 07:20
not_gerd arnsholt: it's more of a cleanup than a complete reworking 07:21
the existing types are reference types
diakopter sounds like not_gerd has grand schemes for writing C-equivalent in nqp/p6 :D
not_gerd ;)
the types I'm implementing are CPointer, CScalar, CArray, CStruct, CUnion, CFlexibleStruct, CBlob 07:22
all but the last to point to the actual C memory
CBlob gets managed by p6opaque to do inlining
FROGGS I just hope we are not trying to do too much in this early stage (don't wanna see MoarVM becoming the next Parrot)
not_gerd sounds sane? 07:23
arnsholt But why? What's the use case at the NativeCall level this should enable?
not_gerd writing C structures in Perl6?
hasn't that always been a goal? 07:24
arnsholt But most of that already works
diakopter well.. of people who dream of porting the runtime to HLL eventually, like me
but most people don't dream of that
not_gerd arnsholt: how does inlining structures work?
arnsholt What new functionality requires a complete do-over?
07:24 odc joined
FROGGS I like the "create a Perl 6 class with int8-attr for example, and unpack somthing to it"-approach 07:24
not_gerd it's a re-implementation, not a completely new factoring
07:25 cognominal joined
not_gerd take out CBlob, and we reproducethe existing system 07:25
arnsholt Inlining doesn't, I know. But there's a certain amount of design work to do before we can start worrying about the implementation of that
not_gerd add CBLob, and we can do inlining
arnsholt Re-implementing it differently from Parrot and JVM means that NativeCall won't work with your version, you do realize that? 07:26
NativeCall relies on all the different NQP backends exposing the same API 07:27
JimmyZ NativeCall.pm6 is about 250 lines code?
arnsholt JimmyZ: That's just the code exposing the Perl 6 interface 07:28
All of the heavy lifting is done in NQP
FROGGS we don't need to force backend-spefic rakudo-modules, do we?
not_gerd arnsholt: who said anything about changing the API?
(aside from adding to it)
arnsholt You are. The REPRs are a core part of the API 07:29
not_gerd I'm adding reprs, not removing them
arnsholt JimmyZ: There's about 3000 lines of C for the Parrot backend, for example 07:31
Adding REPRs for one backend means that the other backends have to add them as well
And I just don't see why you're adding all this stuff right now 07:32
not_gerd so, you *don't* want to add CUnion, CScalar?
why?
arnsholt Sure, I want to add them eventually
But there's no need to implement lots of internals when we have no idea how the externals are going to work
And I'm not even sure what CScalar is supposed to do 07:33
not_gerd CStruct and CArray right now are implemented as reference types
they don't inline the C memory, they point to it
the same should be done for C scalar types
07:34 donaldh joined
not_gerd a C scalar is just a pointer and a type annotation in the repr data 07:34
arnsholt Right, so it's a non-array int* or whatever
not_gerd yes
arnsholt Might be a good idea, I agree
But again, we should figure out the externals here as well 07:35
FROGGS might it make sense to just satisfy NativeCall now and talk about extensions after that?
not_gerd well, then consider my work a prototype that we might ultimately throw away
I'll do the work anyway, regardless of anyone else's approval ;) 07:36
arnsholt That'll work, I guess
not_gerd if it turn out not to be useful, tough luck for me
arnsholt Even if I'd rather not throw lots of code away =)
not_gerd ;)
well, just trying to make the parrot version compile is quite a bit of work, and boring at that 07:37
re-implementation is more fun ;)
FROGGS I fully understand that :o)
JimmyZ revise it or re-implementation with the experience 07:38
FROGGS but in the shelf behind me is a book called 'The Myth of a Man Month', it tends to remind me of not doing too much
diakopter arnsholt: don't think of it as throwing code away. 07:40
I'm sure all the existing code contributed much to new design and undertanding 07:41
so, it lives on. :)
JimmyZ as revising it will be much better 07:42
diakopter FROGGS: ah->frame = (void *)ex->body.origin; # does this need the frame ref incr? 07:45
FROGGS diakopter: it does it here already: github.com/MoarVM/MoarVM/blob/mast...rp.c#L3365 07:46
diakopter: is that enough?
diakopter well I see how it gets it for teh ex/ex_obj object 07:47
but is the ah object always destroyed at the exact same time as that?
FROGGS I think the ah gets destroyed before the exception object 07:48
diakopter probably needs its own refcount
to be safe, for sure
FROGGS yeah
then I have to refcnt_inc this one too, to be able to refcnt_dec it later: github.com/MoarVM/MoarVM/blob/mast...s.c#L338it 07:49
diakopter that line is the ah assignment..
you mean the line after? 07:50
FROGGS sorry, meant this one: github.com/MoarVM/MoarVM/blob/mast...ons.c#L154
diakopter if jnthn wrote that he might have been mentally optimizing it away if he could guarantee certain things 07:51
but generally yeah it needs it
not_gerd btw, is there a reason why we malloc() reprs instead of just initializing a static C var? 07:52
FROGGS I mean, I cant decide whether I have to refcnt_dec in `unwind_after_handler`, so when I decrease always, I have to increase always before
diakopter not_gerd: b/c they can store instance-specific data I think 07:53
(and the ideal is to allow multiple instances per process eventually I think.... though libuv will need some coaxing to enjoy that)
not_gerd but we still store the pointer to the repr in a static var
is that going to change?
diakopter oh.
hm 07:54
not sure.
not_gerd if reprs are supposed to be immutable after initialization, it makes sense to store them directly as static vars 07:55
avoids runtime allocation
diakopter not_gerd: interestingly, reprs themselves could have their own repr O_O 08:00
not_gerd dodges the logic bomb 08:01
JimmyZ Isn't it $x.HOW.HOW.HOW?
diakopter sorta 08:02
not_gerd reprs aren't object, but they could be
after I'm done, you can do pointer arithmetics by unboxing a CPointer to int
which means you could write your own reprs in P6 if they were objects 08:03
diakopter well...
not_gerd note that this wasn't a serious proposal ;)
diakopter not_gerd: did you notice CCode repr?
(function pointer)
MVMCCode perhaps 08:04
er. MVMCFunction
JimmyZ MVMCode.c
diakopter no 08:05
it's not for arvitrary C functions... just ones that can be called with that signature
*arbitrary 08:06
like its comment says, it's for internals stuff
so we can have HLL "methods" implemented as C functions directly 08:07
namely, find_meth, new_type, and other extremely performance critical things
not_gerd we could interface with dyncall that way 08:08
diakopter I thought that's what nativecall *does* 08:09
(for arbitrary C functions)
not_gerd I mean instead of adding ops for dyncall, we could make it conform to that interface
diakopter oh. hrm.
it's certainly compilable that way 08:10
not_gerd ie there's a dyncall dispatch CFunction constant that does arg marshalling
diakopter would that be more or less object overhead than what nativecall on parrot does? 08:12
not_gerd not sure yet what would be the better approach 08:15
I'll take a look at what arnsholt does on the JVM before I decide anything
08:33 not_gerd joined
jnthn I didnt' intend the MVMCFunction thing to be anything to do with FFI, fwiw. 08:34
I'm not sure we should dual-purpose it for that either.
Also, no, REPRs aren't objects and they shouldn't be. 08:36
Add REPR inheritance and you screw the whole performance design of 6model.
Well, we could maybe cope but anyway, we aren't going there.
not_gerd: On nativecall stuff, I'd really rather start out in Moar just implementing what we use today from the Perl 6 NativeCall module. 08:38
MoarVM is about the worst possible place to prototype anythinjg else righjt now because we can't try out the Perl 6 level bit 08:39
dalek arVM/nativecall2: 0f0ed84 | (Gerhard R)++ | / (18 files):
Add CBlob and implement CPointer
 08:40
not_gerd jnthn: I'm planning to conform to existing API 08:41
jnthn CBlob sounds terribly like CArray... :)
not_gerd: OK. I'm certainly open to giving NativeCall more featuers and capabilities. I just feel the Perl 6 level needs to be worked on alongside the guts.
not_gerd but CArrayBody contains a pointer to the storage instead of *being* the storage 08:42
my idea is have have a CBlob which is just a sized memory blob that can be inlined
jnthn It still has to be held at a level of indirection.
But yes, you could have one less
You can't pass C-land a pointer to memory managed by the Moar GC as it may move 08:43
not_gerd well, my idea was to only allow pointers to MVMObject (and not within theirs bodies) and keep a bitmap of where they are located within the C blob 08:45
would that be workable?
I guess not because there's no place to hang off the bitmap 08:46
jnthn Aye, and anything we pass to native code, we can no longer keep track of 08:47
FROGGS must suppress puns >.<
jnthn It may stash copies of that pointer all over and we can't keep them up to date.
JimmyZ not_gerd: ptr_obj->st->REPR->ID could be written as REPR(ptr_obj)->ID, FYI :) 08:50
jnthn And probably should be... :)
not_gerd sure, but REPR lacks an MVM 08:51
I guess that's no reason to not use it right now
JimmyZ MVM?
not_gerd headers will need a reorganization if we want to be installable 08:52
anything not prefixed with MVM should reside in private headers
which we don't have right now
JimmyZ oh, you're right. I wanted to talk about it before. 08:53
headers-reorganization
dalek arVM/nativecall2: 3704ab4 | (Gerhard R)++ | src/native/ops.c:
Use REPR macro
 08:55
09:21 dalek joined, japhb joined, Woodi joined, benabik joined, not_gerd joined, cognominal joined, odc joined, LWA joined, FROGGS joined, BinGOs joined, woosley joined, tokuhirom joined, masak joined, [Coke] joined, eternaleye joined, Ulti joined, lizmat joined, rblackwe joined, ggoebel joined, tadzik joined, colomon joined, woolfy joined, yoleaux joined, diakopter joined, Util joined, PerlJam joined, JimmyZ joined, gshank joined, timotimo joined, flussence joined, ChanServ joined, pmichaud joined, `patch` joined, _sri joined, arnsholt joined, ingy joined, patspam joined 09:24 foo_bar_baz joined 11:52 Woodi joined 12:18 dolmen joined 12:37 benabik joined
jnthn There's a nice bundle of Solaris patches (plus a configure related question) on the perl6-compiler mailing list, if somebody feels like processing them. 12:57
(I likely won't ahve tuits until Thu or Fri)
not_gerd and just now I thought it would be fine to use anonymous unions as we were already doing so :( 13:07
actually, solaric studio might support them if -features=extensions is passed 13:12
* solaris
nwc10 I'm confident that you will hit another compiler that can't deal with them 13:13
not_gerd gcc, msvc, clang can deal with them 13:14
nwc10 sure. xlc on AIX? HP's C compiler? 13:15
not_gerd xlc supports them 13:16
JimmyZ anonymous unions is fine. libuv is using it too 13:17
not_gerd JimmyZ: do they use them in their solaris code?
HP C for OpenVMS appears to support them as well 13:18
woolfy jnthn: as soon as I see you, you will have tuits.
I still have loads of MoarVM-tuits! 13:19
JimmyZ not_gerd: looks like not 13:20
woolfy I just wish I had some barrels of time to accompany the tuits...
JimmyZ not_gerd: libuv has an stdint-msvc2008.h 13:21
FYI
not_gerd JimmyZ: I know
but we want inttypes.h as well
diakopter jnthn: surely you didn't think I was actually proposing reprs becomes object!?!??!? 13:34
oh, not_gerd said that 13:38
13:58 jnap joined 14:00 Ulti left
diakopter not_gerd: the validation branch looks good 14:04
jnthn diakopter: Not sure who said what, I was just commenting on something I saw in backlog... :) 14:11
...while I was having my first coffee of the day :)
not_gerd diakopter: we do some re-dispatching on .j/.a that's not necessary right now 14:13
I'd leave it in - we can always remove stuff later if it stays unnecessary
jnthn .j/.a ? 14:14
oh, guess it was about validator :) 14:15
not_gerd annotations for jumplist and preparg
jnthn :)
not_gerd jnthn: is there a reason why we allocate REPROps and then put the pointer in a static var instead of using a static var for the whole structure? 14:18
as in, do we plan to get ris of those static variables?
otherwise, I'd rather get rid of the allocations
s/ris/rid/
jnthn I can't remember why we keep it around in a static... 14:19
Anyway, the repr ops tables are immutable
So there's no real problem with them being shared even betwee MVMInstance 14:20
not_gerd would probably help startup a (tiny) bit
jnthn But...
->name points to an MVMString...
Which is instance-specific...
On the third hand, that being a char* and on the tiny number of occasions we ned it we decode it ton an MVMString (only .REPR introspection, I guess) also works. 14:21
not_gerd the repr struct could just hold a C pointer and the strings would be held in some arrays indexed by REPR->ID 14:22
jnthn Especailly as then you can see what REPr you have easier in the debugger ;)
Or what, yues.
Either works for me. :)
Anything that is trying to make a decision by REPR name on a hot path is probably wrong... 14:23
I guess maybe we need the name strings for the REPR name to ID hash.
not_gerd diakopter mentioned that string constants need a proper abstraction anyway 14:24
whoever does it can take care of this as well ;)
jnthn well...I guess they kinda do-ish...but that's really into micro-opt :) 14:27
diakopter jnthn: yeah but the name strings for the hash can be instance-specific 14:28
14:28 benabik joined
diakopter I think the ->name as char * is a good idea; it makes error messages and debugging huge amounts faster 14:28
jnthn diakopter: Yes, I think that's what I was suggesting 14:33
diakopter: Oh, to be clear I meant the array of MVMString names had to be per-instance, like the REPR lookup hash is.
diakopter jnthn: I meant, we can have name strings for each repr in each instance 14:35
jnthn diakopter: Yes, me too :)
not_gerd how do I allocate immortal objects? 14:46
diakopter well you switch the allocator into gen2 mode 14:47
jnthn Wait :)
Immovable, or immortal? :)
not_gerd immortal 14:48
I need to stub some type and it would reduce boiler-plate
jnthn moment, finsihing class 14:49
diakopter not_gerd: if you just want to cache something, just create a slot for it on instance; that can get a hundred more slots or whatever 14:50
not_gerd isn't there some GC flag I could set that says 'hey, leave me alone' 14:53
diakopter what do you mean "leave me alone"
it'll still find pointers to it
what do you suggest doing with those pointers 14:54
not_gerd: why do you want special treatment from the GC? what special behavior/situation does it need? 14:55
(why does it matter that you're calling it immortal?)
not_gerd I don't want to actually implement most of the 6model bits right now 14:56
diakopter I'm beginning to suspect the answer to your question is: "add the pointer to permroots"
implement most of the 6model bits???
I don't see your implication 14:57
not_gerd I basically only need the repr parts
diakopter the repr parts of what?
I don't even know what you're working on
so I have zero context for your question
it sounds like the answer is "add a permanent root" 14:58
(after stashing its pointer on instance)
not_gerd sounds good
for testing purposes, I basically need an object that only holds a pointer to a malloc'd memory block 14:59
I never call methods on it or do anything else interesting with it
diakopter that's not CPointer?
not_gerd I just want it to not be collected prematurely
not in my factoring 15:00
diakopter yes, save the pointer somewhere, and add the address of that saved pointer to permanent roots
not_gerd thanks
diakopter so the gc knows not to collect and also where to update that pointer if it moves it
wait, what repr are you using then 15:01
if not CPointer
not_gerd I called it CBlob 15:02
a CPointer can point into that
diakopter "into"
?
not_gerd you can do 'safe' pointer arithmetic as long as you never leave the blob
diakopter oh.. I was going to add this sort of thing.. 15:03
*ask to add
not_gerd: but why would you want the blob in the body of the object? 15:05
oh, nm
not_gerd diakopter: that... probably won't work out 15:06
diakopter what won't work out
not_gerd I wanted CBlob to name the thing that can be inlined into arbitrary p6opaque objects 15:07
diakopter eh?
not_gerd you would acces the value by getting a CPointer that points into the inlined blob
now, it gets fun when objects start moving...
diakopter that's what jnthn was saying, you can't pass those pointers to untrusted code 15:08
why would you want blobs inlined?
not_gerd jnthn was talking about the flip side - putting 6model object pointers into C structures
jnthn Not having the GC support interior pointers was kinda a design simplification I knowingly made. 15:09
not_gerd I was talking about putting C structures into 6model objects
jnthn That is, I've done stuff assumign I'd never have to care for this.
diakopter yes, those are still pointers to 6model objects
which can move, so you can't do that
not_gerd well, with enough effort, you can probably make something like this work 15:10
jnthn So the GC really doesn't know what to do with pointers into the insides of objects and it'd be a decent bit of effort to teach it and I'll take a good bit of convincing to do it.
not_gerd I don't want to do it, though
jnthn 'cus the GC is complex enough already ;-)
not_gerd I want to make putting MVMObject* into 6model objects work, though 15:11
get the users enough rope to hang themselves ;)
diakopter how don't we already have that, with the gc_mark routine of each repr? 15:12
jnthn You should be able to put a P6opaque-like thing into a P6opaque-like thing
not_gerd diakopter: yes, I'll be doing it using gc_mark and a bitmap 15:14
jnthn (as in, at a 6model level that should be possible...it's not done anywhere yet...)
not_gerd but once you can pass such struct to C-land, the temptation will be there to store those MVMObject* somewhere else ;)
diakopter you can't pass anything with object pointers to C land 15:15
not_gerd you can
(see comment about hanging yourself)
diakopter (unless the C code is already aware of all the restrictions, in which case why are you writing C in the high level language in the first place)
right, but why would you want to do that
not_gerd -Ofun doesn't care about why, just *how* 15:17
diakopter frankly that's silly and you can't design based on -Ofun
not_gerd diakopter: it's design by implementation 15:18
I'm fully aware that we might just scratch the whole thing 15:19
there'S probably be bits to keep around, though
there'll
FROGGS parrot keeps bits around too
diakopter so I'm asking, why would you want to pass 6model pointers to C land unless it's code that's already written against moarvm.h
not_gerd you could have some black-box C à qsort() 15:21
put your MVMObject* in some CArray and provide an accessor
diakopter to sort what?
not_gerd the CArray
it's just an example 15:22
diakopter when we call into native/C code, we mark the thread blocked
so the GC can run *during* the call out
so you can't be looking at managed memory during that
because of the assumption that native code can't see managed memory 15:23
not_gerd that does make it far less useful
diakopter it's so you can have IO/delayed/longish-running things in native code and not block all the other threads when the gc needs to run 15:24
not_gerd: note the implications for the JIT, too 15:32
the JIT will still need gc sync point interrupt checks injected 15:33
maybe more intelligently less often, but definitely still with some frequency 15:34
and the JIT will need to know how to spill all registers to memory 15:35
(and back after the gc run)
pointer registers, anyway
15:53 FROGGS[mobile] joined
diakopter commutatoriation& 16:00
16:49 jnap joined
dalek arVM/nativecall2: 502ad30 | (Gerhard R)++ | / (12 files):
Work on CBlob and fake pointer repr inheritance
 17:17
arVM/nativecall2: e5639bd | (Gerhard R)++ | src/native/CScalar.c:
Add some constants for CScalar
arVM/nativecall2: b74681d | (Gerhard R)++ | / (10 files):
Fix bugs and wire up what we have so far
diakopter not_gerd: do you plan on storing sizeof() of all the MoarVM structs statically so the runtime can grab them? 17:28
also offsets of every member
diakopter thinks that would be helpful :) 17:29
not_gerd: I do think the blob has potential for other things, though 17:32
not_gerd the use case I was interested in was creating C structures 17:34
allocate a blob, than cast to the correct pointer type
* then
first, I need to figure out why I end up in an endless loop, though 17:35
diakopter I still don't understand why you want those as part of the object body
not_gerd doesn't sppear to be the runloop
I hope it's not another silly bug like `ptr = (MVMCPointer *)ptr;` instead of `ptr = (MVMCPointer *)ptr_obj;` 17:36
diakopter not_gerd: about how many nanoseconds should it take to qsort a thousand integers
not_gerd took far longer than it should have to track down 17:37
well, qsort() isn't the greatest because it can't inline the comparison function
diakopter sorry, I meant *a* quicksort 17:38
not_gerd why do you ask - to check if a custom implementation is correct? 17:39
diakopter which sort would be best for items that are probably fairly close to sorted already
not_gerd www.sorting-algorithms.com/
diakopter that's a url, not a sort algorithm 17:40
not_gerd it has pretty animations that contain the answer
hm.. 17:41
it doesn't work correctly in my FF
that used to work :(
diakopter oh, actually, very few unique is more the use case 17:42
not_gerd you might also look into hybrid algorithms like timsort or introsort which normally cover a good range of use cases 17:47
diakopter qsort3 and shell sort handle that case the best (according to those animations)? 17:48
jnthn Ther'es already a quicksort algo in Moar somewhere :) 17:49
used for fates or something i guess... 17:50
not_gerd do we need to sort linked lists, by the way? 17:51
diakopter not yet, that I know of 17:54
jnthn dinner...somewhere near, given the color of the sky... &
not_gerd should I do something special to an object before adding it as permroot? 18:07
move it out of the nursery or something? alloc it in gen2 from the start?
diakopter no 18:08
you don't add objects to permroots
you add addresses of pointers to objects
to permroots
roots aren't necessarily particular objects; they're memory locations that hold objects that should always be rooted 18:09
not_gerd well, I put a type object into a staic var and did a MVM_gc_root_add_permanent() 18:10
diakopter just a temporary static, right? 18:11
not_gerd no
do I need to set that to NULL before instance destruction?
diakopter you can't store object pointers in statics
that's why I said you have to hang it off of instance 18:12
temporary in the context of development cycle, I mean
not_gerd someday, I should probably read through the gc algorithm 18:13
MVM_gc_root_add_permanent() only cares about the variable's address, so I thought it would be fine
but that variable needs to reside in managed memory?
diakopter no, instance-specific memory 18:14
so it should hang off instance
if it's a stub type, why not add it to where all the other stub types are
MVM_gc_root_add_permanent(tc, (MVMCollectable **)&tc->instance->boot_types->BOOTIntArray); 18:15
not_gerd because I had not yet decided if it should remain a stub type
but if it breaks the gc, I should do it
(obviously) 18:16
diakopter like I said last night, you can't put instance-specific pointers in static variables because we could have multiple instances
not_gerd sure, it was only ever a temporary solution so I could get to testing more interesting stuff 18:17
diakopter (but like I said, libuv might need some convincing to enable that.. )
that's what I meant by temporary
temporary in the development cycle
it's fine to store it in a static if you're just doing it for this phase of the developement cycle
get it? 18:18
not_gerd personally, I don't hope it's fine - otherwise, there's something else that broke global destruction ;) 18:20
diakopter no, you would still have to root it 18:21
not_gerd it *is* rooted, but now MVM_gc_collect_free_nursery_uncopied loops endlessly on global destruction 18:22
diakopter well, it's probably not a problem in your code
the global destruction is quite new 18:23
oh. 18:24
yeah that's my bug
haha
not_gerd *now* you tell me ;)
diakopter well I just found it
in my mind anyway
have to actually look at the source to confirm
instead of mentally running the code 18:25
diakopter wonders if everyone does that
seriously though, it's fine to store it in a static for development purp;oses 18:26
not_gerd: I'm not going to be able to fix that for 4-5 hours; just comment out the global destrutcion for now 18:27
not_gerd what to do with CBlob depends on whether we want a proper OO interface to it 18:28
the interface right now is get a pointer to the blob and do all manipulation through that
(or it will be once I implement it ;))
diakopter 17:35 < diakopter> I still don't understand why you want those as part of the object body 18:29
not_gerd they no longer are
diakopter oh
not_gerd a CBlob is just a memory block you can point pointers at
say you want to create a CArray 18:30
you allocate a blob, get a pointer to it's start and cast the pointer to array
diakopter does the pointer know the size of the blob? 18:31
not_gerd indirectly - the blob does, and th CPOinter references the blob
diakopter (how else would the array know how big it can be)
not_gerd that's the difference between a CPointer coming from native or from 6model-land 18:32
coming from 6model-land, it knows it's blob and thus knows what pointer-arithmeticsare safe
diakopter CPointer is still immutable, right? 18:33
not_gerd no, it can be modified by boxing int 18:34
typed pointers are immutable, though 18:35
diakopter how could that possibly be safe
not_gerd because it knows the blob
diakopter when you box an int?
not_gerd you derive a pointer from a blob
diakopter you just said it can box an int
not_gerd unbox it to int and do arithmetics
diakopter does the set_int repr op throw an exception on it? 18:36
not_gerd on re-boxing, it checks if it still lies within the blob
yes do set_int throwing
(or is that a no-no?)
18:38 jnap joined
diakopter well.... where else would you be doing the check you just mentioned 18:39
not_gerd well, depends on what we want boxing semantics to be 18:40
diakopter eh?
not_gerd one could argue that just boxing should always be safe
no idea if we want that
diakopter I don't know what other repr op you're referring to other than set_int 18:42
not_gerd no, it uses set_int, but it could be made to use a custom op if so desired 18:43
I was asking if it is
sorry for being unclear
diakopter I really think set_int should throw
not_gerd then I'm happy as well as that's what it does right now 18:44
diakopter but it wouldn't do what you said on boxing
it would throw
I suggest an op that takes a pointer, integer, and returns a pointer
(new) pointer
I don't think you should try to overload the boxing op that way
I strongly suggest keeping the native types immutable with regard to all the standard ops 18:48
I doubt jnthn would accept the design otherwise (for the same reasons I'm saying)
not_gerd: do you think that can work?
not_gerd sure 18:49
diakopter otherwise it raises the complexity level of the repr ops
not_gerd would add another op and increase the number of objects neede when doing arithmetics, but that's probably not an issue
pointer arithmetics isn't really something we should optimize for 18:50
diakopter certainly not above the optimizing jit level
the optimizing jit can do all kinds of seemingly risky things :D :D 18:51
not_gerd it's a bit of a semantic mismatch that pointers need to be 6model objects, though - we dont have pointer registers, right now 18:53
diakopter no, same as int objects 18:55
the assumption is that eventually a jit will do the right thing
jnthn: make sure to read all teh backlog before replying 18:56
jnthn Everything that ain't a native int or native float ends up as a 6model object in Moar.
In general, the idea with REPRs that want special things is not to extend the REPR API for every possible use case, but to add repr-specific ops.
not_gerd well, at some level, a pointer *is* just an int 18:57
however, at the API lvel, we can do whatever we want
jnthn (ab)?using set_int for setting a pointer...hmm :)
I'm still pondering that.
It bothered me muchly in Parrot how set_integer and the like got used for all kinds of things... 18:58
otoh, yes, a pointer really is kinda an int :)
Even the CLR believes that (e.g. IntPtr) :)
diakopter yeah but it's unsafe
jnthn aye 18:59
not_gerd well, it means boxing can now throw
jnthn Well, *everything* in NativeCall is unsafe :)
not_gerd (and it is of course unsafe if the Pointer does not come from a Blob)
jnthn boxing throws anyway for reprs that don't implement that section of the REPR API...
Or did I miss something? 19:00
diakopter: Did your "set_int should throw" mean anything more than "'cus that's the default for types that don't box an int"?
not_gerd but it's more like 'I don't support that API' and not 'I throw because I don't like that particular int'
diakopter jnthn: no
jnthn: but I was also saying that cpointer shouldn't box ints 19:01
jnthn ok
not_gerd the way I have it right now, a CPointer is basically an int (with its range determined by the associated CBlob) that can be converted to typed pointers like CScalar, CStruct, ... 19:04
diakopter so it's unsafe in the sense things could be mis-casted, but it's safe in the sense that it won't trample on memory outside the blob 19:05
not_gerd correct 19:06
jnthn not_gerd: A CPointer coming back from C land doesn't know its limits, though, I guess? 19:08
not_gerd: Or we presume it's unarithmeticable?
not_gerd right now, it is if its untyped
we might want an immutable untyped type
diakopter I thought we weren't making mutable ones 19:09
jnthn CPointer is immutable, though?
not_gerd mutable via boxing 19:10
jnthn ?
As in, the result is a new CPointer object?
diakopter not_gerd: boxing *is* set_int
jnthn Just like adding two Ints in Perl 6 is a new Int?
diakopter that's why I was asking what other repr op you were referring to other than set_int when yo usaid boxing 19:11
so, I'll ask again, which op are you referring to when you say "via boxing"
jnthn I think we can fairly safely say that the Perl 6 API for pointer arithmetic is gonna want to act like the Perl 6 API for integer arithmetic, which is to say you don't mutate the inputs to the addition. 19:12
TimToady wonders if lines(IO) can ever just be an array of pointers into a readonly memory-mapped file... 19:16
not_gerd oO( is probably just confused about box_i semantics )
TimToady (modulo letting lines return something that only lazily converts to NFG)
diakopter TimToady: I'm pretty optimistic the royal optimizer will have enough information to safely optimize to that 19:17
TimToady 'course, ASCII is already NFG :)
and Latin-1, if you count uint8s 19:18
jnthn evil!!
(As in, beautiful.)
TimToady but yeah, probably we need to mostly think about UTF-8 as input 19:19
not_gerd are latin-1 strings directly mmap() from the bytecode file? 19:21
if not, can we and should we make that work?
jnthn not_gerd: Maybe one to look at after the NFG work.
Shouldn't make diakopter++'s merging work any harder :) 19:22
diakopter I'd say to push that down to the jit optimizer.. note: I'm gonna say that about nearly every optimization proposal
jnthn This feels orthogonal to the jit :P 19:23
diakopter cross-opcode optimization, I mean
jnthn oh...
diakopter how is it orthogonal?
not_gerd when the JIT starts up, we already have copied the strings to memory 19:24
jnthn diakopter: Just using the mmap's bytecode's string heap blob as the ->int8s in an MVMString sounds to me like a loading-the-bytecode time decision, but I think I was commenting on something other than you.
diakopter oh, I missed that line
not_gerd: no, but my first visual studio profile of startup showed that more than 90% of the time was spent decoding bytecode strings 19:25
jnthn o.O 19:26
I'm betting a s**tload of it was the darn serialization base-64 too!
diakopter actually no
well, yes if you mean decoding those strings to in-memory strings
jnthn diakopter: oh wait, what did you mean by "bytecode strings"?
diakopter but then doing the actual base64 decoding is trivial, less than half a millisecond on all of them 19:27
I measured them specifically
jnthn diakopter: yes, I meant decoding them to in-memory strings 19:28
diakopter: Which feels wasteful for the ser blob, but we can deal with that later on I guess :)
diakopter right, there might as well be a binary blob in the serialization
(extend the bytecode spec)
jnthn aye
That's what I've been thinking. Just not felt it was a priority yet :) 19:29
not_gerd what was the rational behind using base64 - the JVM needs it, IIRC
diakopter also, it would be best to eliminate decoding altogether and point directly into the bytecode for the strings loaded from serialization/string heap.
not_gerd any other reasons?
jnthn not_gerd: No, the JVM actually just has the binary file in the JAR now. 19:30
diakopter (like not_gerd says)
about latin1
jnthn not_gerd: The reason - and you won't believe this - was that when I tried to put a string literal with escape sequences in PIR to have it be a binary string, IMCC always screwed it up.
diakopter would be good to make an alternative string constructor (like parrot does) to create a string from a trusted blob source
jnthn not_gerd: So I base-64'd it 'cus I didn't want to debug IMCC.
:)
arnsholt =D
diakopter pir's an awesome bytecode format 19:31
jnthn I meant to go back and deal with it later. 2 years on... :)
arnsholt Yeah, Moar should totally have something like PIR! O:)
arnsholt runs away
diakopter well, nqp will be quite sufficient for that when it's fast
jnthn There's a reason I chose not to give MoarVM an IL :P 19:32
arnsholt jnthn: Which is why I said that in the first place, obviously =D
diakopter but my point was that the fact they're base64 isn't the problem; it's that they need decoded from utf8.. 19:36
(to proto-nfg)
(quasi-utf-32)
jnthn aye :)
diakopter but I still say that we should reserve all cross-opcode optimization designing for the grandaddy optimizer 19:37
19:43 foo_bar_baz joined 19:44 yoleaux joined
diakopter jnthn: see what I said about global locking on #perl6? 19:55
jnthn diakopter: Yeah. I suspect I'm too beat to sanely comment today, though my gut feeling is "this will have a deadlock risk", but I can't actually back that up with a scenario. 19:56
diakopter well no, the lock objects (tokens) wouldn't be tied to a single thread necessarily 19:57
its just like a Lock object on jvm, except integrated with all the repr ops
(through the natural "this thread owns this" locking)
(if we end up having that) 19:58
so that makes it the user's responsibility to keep it unique
er, keep it undeadlocked 19:59
(just like any other lock)
jnthn Thankfully, Promise, Channel, etc. will push a bunch of things in the "lots of single threaded pieces communicating through well-defined, composable synchronization primitives", which I hope means the typical Perl 6 developer won't encounter locks when writing their parallel/concurrent programs :) 20:00
s/",/" direction,/ 20:01
diakopter jnthn: yeah, well, while compiler-writers are the majority of Perl 6 developers... (for the foreseeable future).... :) 20:02
(I'm implying that it won't be efficient enough for a while) 20:06
[Coke] wonders if there will be rakudo-moar hacking this weekend. 20:19
20:25 cognominal joined 21:03 rblackwe joined
diakopter [Coke]: probably not time.. :P 21:04
dalek arVM/nativecall2: 460c903 | (Gerhard R)++ | src/ (5 files):
Hang CBlob_WHAT off the instance and disable global destruction
 22:42
arVM/nativecall2: 444577a | (Gerhard R)++ | / (10 files):
Native ops refactor
not_gerd that's it from me
good night 22:43
22:43 not_gerd left
diakopter g'n' not_gerd 22:43
23:24 cognominal 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!