Parrot 3.1.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Get more GSoC ideas on wiki; close tickets; stable 3.2 release; assess status of roadmap goals for 3/15 meeting.
Set by moderator on 9 March 2011.
cotto_work Is this idea workable: 00:10
nopaste "cotto_work" at 192.168.1.3 pasted "trivial M0 FFI concept" (5 lines) at nopaste.snit.ch/36594
whiteknight looks a lot like what I have been envisioning 00:20
of course, that kind of example is trivial. How do you pass arguments and receive a return value?
keeping in mind that floating point return values are passed in a different place on x86, and other platforms may have even weirder systems
cotto_work whiteknight: yes, there's a lot of extra complexity in argument and callbacks. 00:25
00:28 bubaflub joined
whiteknight so ignoring those complexities, what do you think the M0 syntax looks like for passing args and receiving returns from C? 00:30
that's the much more interesting problem
00:36 lucian left 00:37 tcurtis joined
cotto_work whiteknight: that's what I'm thinking about. 00:40
00:43 tcurtis left
dalek sella: a73456f | Whiteknight++ | / (2 files):
Don't fail as hard when we have a null expectation (one with no options set). Add in some new quantifiers. Add in some tests for Expectations
 00:49
sella: f74a400 | Whiteknight++ | / (3 files):
Add in a will_do expectation modifier to execute a sub for side-effects. Add in a test file for several Will variants
plobsing_ cotto_work: if M0 is what we're going to be writting most of our VM in, we shouldn't be doing dlfunc for every C call we need to make. we need a way to express static calls and library dependancies to allow the native code generator and OS to do what they do best. 00:52
whiteknight the compiler can probably take function calls to "Parrot_*" and turn them into static cals 00:53
plobsing_ not if we're dlfuncing them. 00:54
cotto_work that sounds magical. I don't like the idea of the extra complexity of having two ways to call a function, but plobsing_ makes sense.
00:54 kid51 is now known as kid51_at_dinner
whiteknight Parrot should recognice that calls to itself don't need dlfuns 00:54
my fingers are stupid tonight
cotto_work goes home with things to think about 00:55
plobsing_ I'm not sure this is a resolvable issue given the current design. The only approach I can see (I'm not very imaginative) is having some kind of "big table of compilation context", which the compiler has available. Any function we'd want to use would exist in that table. It is basically the M0 analog of the GOT. 00:57
I'm not sure that would work either, but it's the best I can come up with. 00:58
ShaneC what is M0? 01:02
the pir replacement? 01:03
sorear no
M0 is our C replacement
PIR replacement will be M1 or maybe M2
if PIR is M2, M1 will be more PASM
ShaneC is it similar to the .pmc syntax or something different?
01:07 plobsing_ left
whiteknight the .pmc file syntax is like a really bad mismash of C 01:10
01:11 woosley joined
whiteknight and the .ops file is an equally bad, but different mismash of C 01:11
and PIR is a really really bad mismash of everything everybody ever suggested they must want
the idea of M0 is that we create a new, common base language that is used to implemnt everything at the lowest level 01:12
and then we can start building up all the other thigns we need: PIR, PMCs, Ops, etc, on top of that common layer 01:13
in the process, we can cut out a lot of marshalling logic to switch between C/PIR calling conventions, and we can expose everything from top-to-bottom to the JIT and other optimzers 01:14
similar in many respects to the PyPy project: Write everything in Python, and compile, JIT, and optimize it all as one
01:19 davidfetter left
cotto ~~ 01:19
01:20 kid51_at_dinner is now known as kid51
cotto plobsing++ for the answers on parrot-users 01:23
dalek rrot: f4feafc | petdance++ | / (2 files):
The mem_sys_allocate and related functions cannot take a zero-length size any more. They also are guaranteed to not return NULL.
 01:29
rrot: 94c5359 | petdance++ | / (3 files):
Merge branch 'master' of github.com:parrot/parrot
01:37 bubaflub left 01:39 mtk left
kid51 Darwin/PPC: make fulltest PASS at commit 792a139882 01:39
01:46 mtk joined
Coke msg kid51 that file did actually have more than just debugging tips. 01:49
aloha OK. I'll deliver the message.
kid51 Coke: I'm looking at it right now. 01:50
It has 5 subheads -- but the only 2 sections of those that are well developed both start out "Debugging" 01:51
and two others have Profiling in their names.
So why is debugging_profiling.pod not a good name? 01:52
cotto requested a better name; is there something better still we have not thought of yet?
I'm not wedded to that name. If you have something better, I won't object. 01:54
cotto "debugging_profiling" implies that it's about debugging profiling. I was thinking more like "advanced tips for hacking on parrot" 01:56
kid51 So, how about "advanced_hacking_tips.pod"? 01:58
I just think "protips" sounds like a variation on "Qtips"
01:59 whiteknight left
cotto knowyourmeme.com/memes/protip 01:59
kid51 cotto: I have never heard of that usage/meme
or perhaps simply "advanced_hacking.pod" 02:00
cotto: You have a preference?
cotto thinking 02:01
02:01 plobsing_ joined
cotto hacking_tips wfm 02:02
"advanced" means too many different things to different people
I can change that 02:04
dalek TT #2037 closed by jkeenan++: darwin/ppc build failure 02:06
TT #2037: trac.parrot.org/parrot/ticket/2037
rrot: e3b4b86 | cotto++ | / (4 files):
change name of hacking tips doc
 02:07
kid51 cotto: docs/index/developer.json -- Is that a file that needs to be edited manually when we add/subtract/rename files under docs? 02:08
cotto yes 02:09
I'm pretty sure, at least
dalek rrot: e39cc22 | petdance++ | src/hash.c:
consting pointers. Much progress at making hashes const-happy.
 02:18
rrot: 646eacd | petdance++ | / (4 files):
Merge branch 'master' of github.com:parrot/parrot
02:30 sigue left 02:42 sigue joined 02:47 bubaflub joined 02:49 tcurtis joined 02:52 tcurtis left 03:04 kid51 left 03:29 bubaflub left
dalek rrot: 1cad94c | petdance++ | src/longopt.c:
make optlen be a size_t
 03:36
rrot: c02eba5 | petdance++ | / (2 files):
Note that Parrot_vsnprintf() could possibly leave the buffer untouched. This means the buffer is ARGMOD(), not ARGOUT()
 03:52
03:57 particle left
dalek rrot: 0fc3c4c | petdance++ | / (2 files):
Parrot_ns_find_global_from_op can return NULL
 03:57
03:58 particle joined
dalek rrot: d20e406 | petdance++ | config/gen/makefiles/root.in:
remove the splint-all target. make SPLINT_SOURCE not quite so crazy inclusive
 04:06
04:42 ShaneC left 04:46 particle1 joined 04:49 particle left 05:00 ShaneC joined
cotto ~~ 05:11
dalek rrot: 636b42a | petdance++ | / (4 files):
shimming unused interps. Changed an int to size_t.
 05:13
05:21 benabik left 05:24 davidfetter joined 05:36 arnsholt left 05:39 arnsholt joined
ShaneC any particular reason why all nci types are signed? 05:47
plobsing_ not really 05:50
we just haven't got around to adding those types
ShaneC fair enough, shouldn't harm anything i'm doing, just curious 05:51
plobsing_ you can fairly easily convert signed to unsigned using StructView's 'Union' view
ShaneC i do have one question about nci though
i'm trying to call a function that takes a pointer to a char buffer, i assume 't' is the right nci prototype for that, but how can i set the buffer size of a parrot string? 05:52
plobsing_ 't' is deprecated for a number of reasons that fall directly out of what you just said 05:53
ShaneC any planned workaround or will i need to write some c?
plobsing_ 1) Parrot strings are *immutable*. You cannot pass them to C code which modifies them internally without breaking *everything*.
ShaneC ah, makes sense 05:54
even if the buffer were large enough im guessing parrot keeps track of string length at least
which would then be wrong
plobsing_ 2) the things C programmers want to do with strings don't match what Parrot strings are. the concept of "setting the buffer size" does not make sense for Parrot strings.
05:54 jsut_ joined
ShaneC i imagine you could do sort of a perl-5-esque $string = ' ' x $bufferSize; to reserve space 05:55
plobsing_ the workaround is to use a buffer type. And not the suggestively-named but ill-suited "ByteBuffer" type.
PtrBuf is probably what you want
you can allocate these with StructView
although you could NCI to any allocator you choose. 05:56
ShaneC would that require me to change any c or recompile parrot?
i have no problem with doing that, but just trying to understand if this can be pure-pir or not 05:57
plobsing_ no recompilation or patching necessary.
ShaneC with a PtrBuf, would i be able to convert that to a parrot string?
sorear parrot strings are not strings of 'char' 05:58
plobsing_ Parrot provides the means of translating between native buffers and Parrot strings
sorear they are strings of Unicode characters in an unspecified encoding
plobsing_ you will have to use NCI to access them however
I intend to provide some utilities to make this easier at some point
ShaneC thanks, i'll dig into the PtrBuf stuff now 05:59
05:59 jsut left
plobsing_ because I see this is something people want to do frequently (which is why we have a couple of ways built into the NCI to do it, even though these are each wrong in their own special way) 05:59
06:03 petdance left
ShaneC addressing this seemingly simple ticket has led me down quite a few rabbit holes ;-) 06:05
plobsing_ what ticket? 06:06
ShaneC trac.parrot.org/parrot/ticket/955 06:07
bacek ~~ 06:09
plobsing_ the ticket suggests that implementation as a dynop is a good idea. any reason you aren't going with that?
ShaneC after a little discussion here it seemed like it really doesn't belong with FileHandle.open, and doing it as a pure-pir class seemed like a straightforward approach 06:11
plobsing_ sounds like a good reason
ShaneC create a file on init, provide access to its filename, delete it on destroy 06:12
bacek ShaneC, there is a pitfall with .destroy methods of PIR classes. 06:13
ShaneC ?
could be moved to an explicit method for now
bacek This is one of not-overriden methods.
ShaneC what do you mean?
bacek With "explicit" method it's less-than-awesome. 06:14
plobsing_ so we're talking about the equivalent of insecure mktemp?
bacek ShaneC, .destroy will not be invoked automatically from GC.
ShaneC plobsing_: if mktemp's behavior is preferred, i figured that ticket would not exist 06:15
plobsing_ ShaneC: mk *S* temp's behaviour should be preferred.
ShaneC in either case, if there exists a standard function that does exactly what is needed, why the ticket? 06:16
plobsing_ because it is not exposed to parrot at the current time 06:17
hence the ticket
ShaneC bacek: is there a proper way to delete the file at the proper automagical time? 06:18
bacek ShaneC, use mkstemp?
ShaneC that handles deleting the file? 06:20
bacek actually, open file, remember fd, remove file. 06:21
store fd in FileHandle
FileHandle.destroy will close it.
ShaneC the windows version of mkstemp does not return a filehandle and does not create the file 06:22
which doesn't mean mkstemp couldn't be used elsewhere, but windows will need code to clean up the file somewhere 06:23
bacek: earlier discussion about the ticket also suggested that some places may open/close the same temp file multiple times 06:24
or pass it to an external process
bacek pass filename of filehandle? 06:25
plobsing_ Security isn't a priority for the testsuite, which is the use-case that reveals the need for such a feature. 06:26
But many use cases should be concerned with security.
ShaneC (apologies for my poor understanding of the *nix behavior of this, but) didn't you say mkstemp removed the file?
bacek erm. Is there way to delete file from parrot? I couldn't find one
ShaneC so the only way to get at it would be through the existing handle
plobsing_ ShaneC: no, mkstemp does not automagically remove the file. It creates and opens the file in a secure, race-condition free way. 06:27
mktemp is very easily attackable
bacek: we have os.rm(file) 06:28
bacek ah, ok 06:29
cotto I've wondered why that's a method on OS and if there's a better place for it.
bacek so, why don't just expose mkstemp via dynops? 06:30
ShaneC mkstemp is different on windows
although that could be hidden i suppose
plobsing_ cotto: OS is a collection of things that don't really fit well anywhere right now 06:31
ShaneC any tips on where to look to learn about implementing a new dynop?
bacek ShaneC, src/dynops/io.ops
ShaneC thanks
src/dynoplibs? 06:32
plobsing_ cotto: I've been thinking that functionality would be better provided by an NCI collection inspired by Perl 5's POSIX module. 06:33
cotto plobsing_, I wouldn't object to that, given a smooth transition for users.
plobsing_ cotto: it's nothing more than a pipe(3) dream at the moment 06:34
06:35 fperrad joined
cotto plobsing++ 06:35
bacek ShaneC, yes, dynoplibs
06:35 Khisanth left
cotto ShaneC, welcome to yak-shaving 101 06:39
ShaneC i just hope i can actually have a patch to submit one of these days!
definitely seems to be getting closer though ;-)
gradually making my way up the steep slope of becoming familiar with a large code base 06:40
06:47 Khisanth joined
dalek rrot: 7ede0e1 | bacek++ | / (2 files):
Remove useless commented out stuff from ops
 06:53
rrot/opsc_llvm: 3a42442 | bacek++ | t/library/llvm/06-builder.t:
Add more tests
 06:54
06:59 rurban_ joined 07:02 rurban left, rurban_ is now known as rurban
bacek cotto, ping 07:06
cotto bacek, pong 07:07
bacek cotto, did you ever try to freeze/thaw parsed Ops::OpsFile? 07:08
It breaks horribly for me...
cotto bacek, I never played with that.
bacek ookey. 07:09
cotto What kind of application are you thinking about?
bacek "JIT" 07:10
I do need more info than in op_info_t
preferably - originally parsed op.
cotto is it not feasible or practical to add that info to op_info_t? 07:11
bacek It's feasible. But I don't know how much info I'll need yet
cotto so it easier for prototyping to just dump everything
bacek exactly 07:12
but parsing will take 60 seconds for each test run
which kind of waste of time
cotto very much
I can see why you want that.
there's some potential for build improvements if that can be made to work 07:13
bacek this is too. 07:14
sigh... I hate handling of LABELs... 07:16
07:33 davidfetter left 07:43 particle1 left 07:59 theory left 08:27 lucian joined 08:32 lucian left
dalek rrot: c361e4f | bacek++ | src/ops/ (4 files):
Don't pessimize prematurely. Use optimizable accessors.
 09:00
rrot/opsc_llvm: 7ede0e1 | bacek++ | / (2 files):
Remove useless commented out stuff from ops
rrot/opsc_llvm: c361e4f | bacek++ | src/ops/ (4 files):
Don't pessimize prematurely. Use optimizable accessors.
rrot/opsc_llvm: 4008a6b | bacek++ | / (47 files):
Merge branch 'master' into opsc_llvm
09:16 contingencyplan left 09:17 woosley left 09:26 mtk left 09:29 Khisanth left 09:33 mtk joined 09:39 Khisanth joined 10:13 dod left
dalek rrot/gerd/JSON_nqp: d92f11c | (Gerd Pokorra)++ | t/compilers/data_json/to_parrot_2.t:
change documentation in test to use the correct filename
 10:27
10:30 cosimo left
dalek rrot: 717ab39 | bacek++ | NEWS:
Update NEWS for opsc_full_parse branch merge.
 10:32
11:06 lucian joined 11:18 lateau_ joined 11:34 plobsing_ left 11:38 plobsing joined
dalek sella: 4e98e6b | Whiteknight++ | / (9 files):
Start fleshing out proxy builders for Array and Hash types
 12:21
12:25 darbelo joined 12:42 sigue left 12:44 mj41 left 12:51 Kulag left
dukeleto ~~ 12:56
darbelo ~~ 12:59
13:00 sigue joined
dukeleto darbelo: howdy! 13:00
dukeleto is hanging out in Ithaca, NY for the next 1.5 weeks 13:01
13:05 sigue left, sigue joined 13:10 woosley joined 13:11 Kulag joined
Coke that's almost in my neck of the woods. 13:27
dukeleto Coke: almost :) 13:28
Coke: i will hopefully meet up with kid51 while I am here for some strategic discussions 13:29
13:34 whiteknight joined
dukeleto smolder is still down. This sucks. 13:35
whiteknight how long has it been down?
Coke it's even further away from him. ;) 13:37
dukeleto: we have keys. why don't we restart it?
(teh website is up...) 13:39
13:42 Drossel joined, Kulag left
Coke anyone mind if I kill smolder to see if I can restart it? 13:44
moritz forgiveness > permission 13:45
Coke I was willing to wait a few seconds on this one. ;)
Ok. I think I restarted smolder. No clue if it will help with any perceived problems, but now I know where the big red button is. 13:48
13:55 Drossel left 14:05 Kulag joined 14:08 particle joined 14:42 mikehh left
dukeleto Coke: looks like that helps. I just submitted a smolder result 14:43
moritz too 14:45
Coke ok. All I did was kill one of the smolder processes that was running - all of them seemed to get the hint and die, then I just sudo'd to root, su'd to nobody, and rename the daemon command. (pulled from the initial PS) 14:48
So, the next time someone reports a problem, anyone with access to parrotvm @ osu can do that. 14:49
dukeleto Coke: it needs to be a single script that somebody can run, and it needs to be in our docs somewhere, or nobody but you will ever do it
Coke: restarting it in a cron job would be better 14:50
smolder is nice, but it has horrible memory leaks in it's dependencies that no one seems to want to fix
Coke: just trying to make sure you are not the one that always get stuck doing it 14:51
whiteknight how do I call set_p_p_ki from NQP?
NQP-rx 14:52
Coke Key is an IMCC literal. I don't think you can do that without Q:PIR
whiteknight yeah, I was afraid that was the answer 14:53
Coke I could be mistaken. This is the part where'd I normally ask pmichaud. 14:55
jnthn whiteknight: What Coke said, but why do you want to do that? 14:58
Just get the thing the [$i] it. 14:59
whiteknight jnthn: I'm trying to test my new proxy library, which uses a bunch of vtable overrides
and I'm trying to write a test in NQP that can call into my get_*_keyed_int overrides
and nothing that I've tried so far does that
jnthn You can't directly call into them from PIR even, afaik.
14:59 rurban_ joined
moritz you can do thing[$I0] 14:59
which calls them 15:00
jnthn Yeah but that doesn't call get_*_keyed_int unless get_*_keyed forwards to it.
Which is stupid but that's Parrot keys.
whiteknight moritz: I've tried that, it looks like it's calling the pmc-keyed vtables instead of the int-keyed ones
yes, parrot keys are stupid all the way around
jnthn whiteknight: Yes, it does. :/
whiteknight: You can only directly call the get_*_keyed_int variant from C-land.
*variant
moritz this is even more broken than I thought :-) 15:01
whiteknight the set_*_p_ki ops look like they call the keyed_int vtables
but I can't seem to generate a call to set_p_p_ki
jnthn heh
whiteknight when I do $P0[1] = foo, I get set_p_p_kp instead, it seems
15:02 rurban left, rurban_ is now known as rurban
jnthn If you work out a way let me know...I ran into this epic bunch of broken a few weeks ago. 15:02
whiteknight which suggests to me that either those ops are dead, or there is some kind of super-secret syntax which I am missing
aloha coverage?
aloha whiteknight: coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
jnthn It actually gets worse than that too, when you realize what's inside the key is a register reference, so if you pass it to a v-table override, it now refers to the wrong register!
whiteknight FFFUUUUUU
jnthn Yes, that's what I said.
dukeleto seems like that is broken by design 15:03
whiteknight okay, according to the coverage report, it does seem like Parrot_set_p_p_ki is being hit by code somewhere 15:04
15:08 mikehh joined
whiteknight okay, nevermind. I added in some debugging statements and it looks like $P0[0]=$P1 is generating a call to Parrot_set_p_kic_p 15:11
and that should be calling VTABLE_set_pmc_keyed_int
NotFound whiteknight: you need a int register, not an Integer PMC. 15:14
If not, one vtable can call the other or not, depending on each pmc. 15:16
Coke I am reminded of bacek's "rip out keys" ticket. 15:20
NotFound I'm tempted to write a ticket: "Rip out proposals to rip out things without providing alternatives", but it will rip out itself. 15:22
moritz :-) 15:23
15:23 Kulag left
moritz so, why do we need keys? 15:24
15:24 Kulag joined
NotFound To call vtable keyed thngs. 15:24
moritz we could just redispatch foo[thing] depending on the type of 'thing' 15:25
s/redispatch/dispatch/
imcc knows if 'thing' is PMC, string or int
NotFound moritz: we already do, partially.
plobsing we need keys to be able to be able to be able to form references to registers in a controlled fashion 15:26
without keys, we would wind up creating agregates for keyed lookups
and churning the GC 15:27
moritz and keys are not GCed?
NotFound moritz: literal keys in pir are constants
plobsing keys are references to registers and can be reused
allowing PMCs to do this more generally would break encapsulation in a huge way 15:28
so we have 1 type that can do it
and anything that wants to read PBC only needs to know how to deal with that type
whiteknight Keys are aggregate pmcs
in fact, each element in the key is a separate pmc, joined together in a linked list 15:29
a single ResizablePMCArray would have less churn than a multi-level key PMC
plobsing nope. you'd need to repopulate the RPA
every lookup
NotFound whiteknight: a RPA can't point to registers.
plobsing and you'd need to create a new RPA to handle recursion
whiteknight plobsing: not if it was setup as a constant in the bytecode
NotFound whiteknight: $P0[$I0] -> Not a constant 15:30
plobsing whiteknight: translate this to an RPA $P0[$P1, 0]
whiteknight we would have to add functionality to RPA to handle register references, but that's hardly a showstopper
or, we write a subclass of RPA to handle it
plobsing whiteknight: that violates encapsulation on registers
NotFound whiteknight: if we add Key functionality to RPA the 'mess' level will be worse, not better. 15:31
plobsing encapsulation upon which tools for analysing and manipulating bytecode rely
whiteknight plobsing: if we took the same register reference logic from Key, and put it into a new array type, how would that violate encapsulation any worse than we do right now?
plobsing none. and you could even call that array type Key.
problem solved
whiteknight there is nothing fundamentally special about Keys that could not be changed or reimplemented. The only thing that sets Keys apart is how poorly they are designed
plobsing the linked-list aspect is just an implementation detail that we can remove 15:32
NotFound Then the proposition is to rework the internals of Key, not to rip it out.
whiteknight and the Key PMC type isn't even the worst part of the whole system. The keyed ops are all terrible
moritz so is a key a bit like an SV in perl5?
whiteknight differentiating between intkey and key in the ops is stupid 15:33
NotFound BTW, we may need less runtime created keys just by allowing both Keys and Arrays in some usages.
But tha may need to use iterators, then one more GCable in each usage.
whiteknight we should be able to have a set_p_p_p op, and I should be able to pass in *anything* as the key, not just a compile-time-created Key PMC 15:34
I should be able to pass in a scalar, an array type, whatever
NotFound whiteknight: we can do that right now, using pasm syntax to avoid imcc messing with the ops.
the operands
plobsing whiteknight: you can: $P0 = $P1[$P2] 15:35
or should be able to do so using that syntax
NotFound But the callee in lots of places expect only Keys
plobsing which is why we need a better encapsulating API, not to rip out keys
also I think we should have a different syntax for "single-element key" vs. "I am using this thing as a key" 15:36
eg: $P0 = $P1[$P0] vs $P0 = $P1{$P0} 15:37
NotFound plobsing: we have it, in pasm
plobsing NotFound: orly?
15:37 woosley left
NotFound set_p_p_p $P0, $P1, $P0 15:37
plobsing you can do that from PIR too 15:38
NotFound plobsing: I mean, pasm syntax without pir sugar.
plobsing ah 15:39
NotFound whiteknight: the difference between intkey and key is probably a big performance impact. 15:41
Not for HLL that never generates them, of course. 15:42
15:45 JimmyZ joined
whiteknight plobsing: In the case of $P0 = $P1[$P2], is $P2 passed in raw, or is it wrapped up into a Key PMC? 15:47
plobsing I suspect it is special-cased raw. 15:48
but you should do what NotFound suggested
NotFound I think I tested that some days ago, and it got wrapped. 15:51
whiteknight so if set_p_p_p works, why do we need set_p_p_k?
or is that just to simplify logic in IMCC
moritz to avoid the PMC in the case of constant keys? 15:52
sorear why not just have set_p_p_i, set_p_p_s, set_p_p_p and kill off Key entirely?
whiteknight that's what I keep asking
NotFound sorear: because vtables keyed expect keys 15:53
sorear we already deprecated and removed the special magic that was multidimensional keys' reason for existing
whiteknight NotFound: we can change them to not expect keys
plobsing sorear: what special magic is that?
sorear plobsing: autovivification blah blah
plobsing sorear: that was just for core PMCs
there is nothing saying some other PMC can't autoviv 15:54
NotFound The magic that Key does and no other thing does is referencing registers.
Thining better, lexpads also does it. 15:55
But not for int and string registers.
plobsing yes, and in a completely different way
NotFound Anyway, if you want to get rid of keys, first think abou how to provide its functionality, or how to remove that functionality. 15:56
plobsing I'd lean towards the former. Most arguments against Keys have been of the latter type ("Keys are dumb"), and haven't really gotten anywhere. 15:58
for extra credit, think about how to unify our variadic ops with the key-replacement functionality. 15:59
NotFound Can't we avoid variadic ops just by storing the variadic part in a constant? 16:00
16:00 theory joined
plobsing NotFound: we could. Key constants provide equivalent functionality. 16:01
NotFound I've think about that several times, but my imcc-fu is not godd enough. 16:03
plobsing the PCC part of IMCC is the worst part
whiteknight I've wanted to get rid of the variadic ops for a long time 16:10
saying that they are somehow requiring keys to stay around is not an argument which sways me 16:11
plobsing whiteknight: I'm not saying that. I'm saying they are equivalent to keys. We can replace one for the other. 16:13
16:14 ambs joined
plobsing you could eliminate keys quickly by replacing keyed ops with variadic ops that passed along an opcode_t iterator as its "Key" 16:14
you could eliminate variadic ops by referencing the variadic registers using a key
a replacement for Keys would therefore also be a replacement for variadic ops 16:15
2 birds, one really big stone
NotFound Myabe we can use some bizarre quantum effect to eliminate both while each still using each other ;) 16:16
plobsing Heisenburg's Technical Debt Principle: so long as you make everyone focus on how quickly you are eliminating technical debt, noone will know how much technical debt you have 16:17
16:19 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
NotFound We should renegotiate technical debt with financial engineering and make a bubble with it. 16:19
It will add a new meaning to "software crisis"
Maybe that is what facebook is doing now. 16:21
plobsing facebook has a PHP problem. they say "I know, I'll use C++!" now they have bigger problems. 16:24
atrodo i am just always amazed that facebook works as often as it does everytime i hear about their setup 16:25
16:27 darbelo left
NotFound They should use winxed instead. 16:30
And pay me several thousand millions for consultant service.
plobsing I always have trouble parsing long scale numbers 16:32
atrodo I think he said 30$, give or take 16:33
JimmyZ doesn't want to use winxed if parrot isn't faster than php 16:34
NotFound I've never tried a comaprative. 16:35
plobsing never wants to use PHP again. ever. even if it is faster than everything. 16:37
moritz it's like "I won't use Perl before it's fasther than Assembly" :-)
cotto_work ~~
tadzik oh, I know people like this 16:38
cotto_work I won't use assembly until it's faster than Perl.
tadzik "what do you mean dynamic typing? This can't be faster than C++ then? So why to use it?". I hope my co-students will grow up before they graduate :) 16:39
JimmyZ doesn't say slower is bad, but parrot is so slower that almost nobody want to use it on a website
plobsing try.rakudo.org/ 16:45
use parrot. on a website.
NotFound JimmyZ: given that there are people that serve static pages using frameworks backed up by a database, I doubt lack of speed disallows anything.
plobsing lack of sanity on the other hand... 16:46
atrodo cotto_work> I saw your nopaste last night, and wanted to wonder outloud, is an ffi call different than any other call at a M0 level?
NotFound JimmyZ: btw if you want to do a comparative yo can try to rewrite winxed examples/fly in php ;) 16:47
cotto_work Sadly, there are opengl bindings for php.
plobsing atrodo: dispatching to a runloop or to C based on argument type is magical
JimmyZ yes, there is phpopengl on sf.net 16:50
NotFound Then is should be an easy task.
s/is/it 16:51
I remember one time a guy told me its favourite Basic compiler was faster than C. The demonstration was a program with a few lines in Basic and lots in inline assmbler. 16:52
plobsing NotFound: that's what I call dedication to a cause 16:53
NotFound plobsing: I usually use uglier words.
cotto_work atrodo: in theory they don't have to be if the interp is smart enough to generate machine code from M0, but otherwise the difference will be jumping to other M0 code vs calling native code. 16:54
16:54 hercynium joined 16:59 darbelo joined 17:03 dngor left
atrodo hmmm. Well, here's another musing then. There has to be some kind of stub that turns the arguments passed to ffi onto the c stack, right? Or am I missing something else? 17:11
cotto_work atrodo: I don't think you're missing anything 17:12
we need thunks to be generated one way or another
atrodo Then, are all calls outside of M0 ffi? 17:13
cotto_work what else would they be?
ah
plobsing full ffi is way too much to be in M0
cotto_work atrodo: are you asking about Parrot-internal vs everything else?
17:14 mtk left
atrodo Well, if you have to call a thunk somewhere, then why not C code that acts like a thunk and bypasses the call to nativce C 17:14
to native C stack. Hmm, not sure how to word that exactly
cotto_work plobsing: I agree. The question is "What primitives can M0 supply that will be sufficient to build a full ffi?"
plobsing be able to call functions and function pointers. the signature of both is known statically and the reference of the first is known statically. these need to be exposed to M0. doing things similar to anything currently described as "ffi" runs counter to this. 17:18
atrodo cotto_work> more or less that's the path I'm going down
cotto_work plobsing: does M0 also need to expose a way to look up the name of a function? 17:19
plobsing cotto_work: pointer -> name lookup? definitely not. 17:20
17:20 mtk joined
cotto_work plobsing: no. name -> pointer lookup 17:20
atrodo cotto_work> basically dlfunc? 17:21
plobsing cotto_work: no. that can be accomplished by static ccalling dlfunc
atrodo cotto_work> or something more?
plobsing meaning a full NCI can be built on top of M0
cotto_work atrodo: basically dlfunc
plobsing M0's NCI does not need to be and should not be built around dlfunc 17:22
cotto_work plobsing: So the M0 interp would call dlfunc during compilation (or interpretation) to look up a function name without directly exposing dlfunc? 17:23
er, to look up a function poitner
*pointer
plobsing cotto_work: that could work 17:24
cotto_work plobsing: what were you thinking? 17:25
plobsing but it might make interpretation pretty slow
cotto_work: I'm not entirely sure 17:26
atrodo cotto_work> so would these function pointers would be wrapped PMCs? 17:27
cotto_work atrodo: not sure 17:28
17:30 pjcj left
plobsing cotto_work: somehow you need to limit lookups to constant reference and calls to constant signature (to enforce static knowledge of both) 17:31
17:32 contingencyplan joined
cotto_work plobsing: yes. I'm thinking about the best way to do that. 17:34
17:34 pjcj joined 17:35 pjcj left 17:36 pjcj joined
cotto_work A slow first implementation is fine if it doesn't preclude a faster implementation once we understand the problem space better. 17:44
Coke ... that sounds like parrot 17:45
17:46 JimmyZ left 17:53 lucian left, Andy left, theory left 18:03 mj41 joined
atrodo cotto_work> what if M0 only exposed a thunk API? 18:05
wrapping the function pointer/signature in a PMC 18:07
18:08 dngor joined
cotto_work atrodo: that sounds too high-level for M0 18:10
atrodo cotto_work> I was imagining it would be a call to a C level function with the context/interp 18:12
18:12 darbelo left
cotto_work atrodo: where are you thinking that the thunks would live? 18:17
18:17 davidfetter joined
whiteknight NotFound: ping 18:18
atrodo cotto_work> they'd have to be written in c, wouldn't they? Or am I missing the question? 18:20
cotto_work atrodo: right. How would those functions be accessible to M0 and how would an M0 interp know to turn a sequence of instruction into a call to the right thunk? 18:23
18:23 benabik joined
atrodo cotto_work> I would imagine it would controlled by a PMC that holds the address of the thunk (unless the thunk never changes), the function pointer and the signature 18:25
whiteknight msg NotFound: I found a winxed bug. I submitted an issue #22. 18:26
aloha OK. I'll deliver the message.
18:29 ShaneC left
cotto_work atrodo: for now I'm trying to think about this without the abstraction of PMCs. Once we know what M0 instructions need to be generated and what the interp will need to do with them, we can figure out how they'll interact with the object system. 18:30
i.e. thinking about this in the simplest terms possible 18:31
atrodo hmmm, okay. I'm at a loss at this point then
cotto_work I think we're closer to asking the right questions. 18:32
18:34 Andy joined 18:39 lucian joined
Coke Once we have M0, does there need to be any difference between a PMC and a class? 18:40
18:43 darbelo joined
cotto_work Coke: PMCs and object will be the same thign 18:43
18:45 ShaneC joined
Coke +1 18:45
NotFound whiteknight: looking 18:47
Mmmm... I thought a recent fix should caover that usage. Fail. 18:48
whiteknight I have an easy workaround now, but it was a little surprising at first 18:50
NotFound Looks like a silly mistake.
Caught! 18:52
whiteknight awesome 18:55
dalek nxed: r855 | NotFound++ | trunk/winxedst1.winxed:
fix a mistake in null call arguments, Issue 22, whiteknight++
 18:58
nxed: r856 | NotFound++ | trunk/pir/winxed_compiler.pir:
update installable compiler
18:59 benabik left
cotto_work andy++ 19:01
Andy ?
whiteknight Andy always deserves karma, whether he knows it or not
Andy what now? 19:02
cotto_work in this case, adding PARROT_CANNOT_RETURN_NULL to the malloc family functions
jfdi ftw 19:03
19:10 dodathome joined
NotFound There must be some reason for that amazing preference for zero: Parrot_ex_throw_from_c_args(INTERP, NULL, 0, 19:19
19:20 benabik joined
NotFound Don't people realize that zero is EXCEPTION_BAD_BUFFER_SIZE ? 19:20
I propose to unshift EXCEPTION_PROGRAMMER_TOO_LAZY_TO_CHECK_EXCEPTION_TYPES to exception_type_enum 19:21
cotto_work EXCEPTION_WHATEVER 19:22
NotFound No, it must be something embarrassing.
19:23 darbelo left
NotFound "the first types are real exceptions and have Python exception names" ---> Oh, nice, foreign legacy values. 19:23
plobsing EXCPTION_NO_APPROPRIATE_EXCEPTION_TYPE_FOUND 19:24
cotto_work NotFound: yeah. That's pretty great.
NotFound plobsing: that will be a lie in most cases.
plobsing I used to look for exception numbers. Then I realized I couldn't find ones that really fit half the time, and that the people submitting bug reports haven't even looked at the number yet 19:25
whiteknight one day I hope we can move away from exception type numbers and start using proper subclasses of Exception for those things 19:27
then it becomes moot, because you won't be passing a NULL type there. We'll have ASSERT_ARGS to prevent that kind of crap
NotFound The NULL in another song. 19:28
is
plobsing whiteknight: then that constant will merely become enum_class_Exception
the fact of it is that the number, or type of the exception is not being communicated to users, and that users would probably ignore it anyways 19:29
NotFound I can't imagine how that parameter might be used.
The NULL, I mean. 19:30
plobsing I thought it could be used with setjmp for resumable exceptions from C
or at least that was the intent
NotFound I completely fail to imagine how resuming to C can be used/useful. 19:34
Coupling pir handling with C level failures will be the most bizarre thing. 19:35
plobsing well we know that *now*
can you hop in your time machine and go back to say 2003 and beat some sense into whoever wrote this mess?
NotFound But I don't believe in resumable exceptions, so my view can be biased- 19:36
plobsing resumable exceptions are somewhat like inside-out AOP. considering AOP is inside-out to begin with, you'd expect to do a full 360 and get what you started with. Unfortunately, it doesn't work that way :( 19:37
19:37 Hackbinary left
whiteknight as far as I am aware, we only support resumable exceptions because Rakudo needs them 19:42
which is a pretty good reason to do it
plobsing but resume-to-C exceptions? 19:43
whiteknight no, those I'm pretty sure are stupid 19:44
especially since Parrot_ex_throw_from_c_args is marked DOES_NOT_RETURN or whatever, and much of our codebase expects that we do not resume at that point
maybe we should make it explicit that exceptions can only be resumed if thrown from PIR
and end this mess forever 19:45
plobsing if you're doing that, go all the way. Exceptions can only be resumed if they only *touch* PIR.
whiteknight no, you're right. That's what it should be 19:46
thrown from PIR, handled by PIR, resumed back to PIR
NotFound Looks sane to me.
whiteknight the less we interact with exceptions from C, the better 19:47
the embedding API has to go through a lot of contortions to prevent them leaking out into embedding code 19:48
IMCC writes its own exceptions system for basically the same reason
NotFound So we have a lot of code to prevent ugly effects of features that are impossible to use. 19:49
whiteknight right
atrodo seems totally legit to me
plobsing impossible to use sounds like a challenge ;-) 19:50
although I'll grant that they are impossible to use for anything useful 19:51
whiteknight exceptions may be something we really want to talk about overhauling this year
NotFound plobsing: given the status of the code base, I think they are imposiible to use at all. 19:52
whiteknight the embed api cleanup was a key enabling factor for that kind of work. The IMCC stuff is going to isolate and simplify a lot of exception handling there, which will be nice
plobsing whiteknight: how is the IMCC work comming? 19:53
whiteknight plobsing: I've been mulling over the last steps in my head. As soon as I can convince myself that it would be more fun to work on that than on Rosella, I'll finish it
so far, it's not an argument I've been able to win 19:54
NotFound You can fill a winxed Issue: "It's too fun"
whiteknight although now that mockobjects are working the way I want them to, I have no other big Rosella projects in mind in the near-term 19:55
atrodo whiteknight> hint, rewrite IMCC in winxed
whiteknight atrodo: It's more tempting than you think
plobsing whiteknight: IMCC compregs are some of the last things that use "J" NCI signatures (which I'm trying to rip out)
whiteknight plobsing: in the branch, those are all gone
NotFound atrodo: there is an early attempt of that in winxed examples
atrodo whiteknight> that makes those some of my favorite jokes to tell
whiteknight plobsing: if you're going to be blocking on that issue, I'll push forward on it tonight 19:56
plobsing whiteknight: I may or may not be blocking on that issue soon.
whiteknight okay, I'll definitely work on it tonight. It shouldn't be too too much more work
plobsing I'm currently struggling with pmc2c to make multis use NativePCCMethods in stead of NCI
whiteknight that's assuming that I know about all the remaining bugs
Oh, goodluck with that
plobsing I hate our tools. So much. 19:57
whiteknight tell me about it
if winxed were part of core Parrot, I would rewrite our old perl tools in winxed just for the sheer fun of it 19:58
19:58 theory joined
lucian dislikes nci 19:58
plobsing lucian: for this particular usage, or in general, and if so why?
whiteknight If I didn't mind a 37-stage recursive build with no clear bootstrapping stage, I would rewrite parrot in winxed
NotFound whiteknight: maybe someday... ;) 19:59
plobsing whiteknight: just do what Ī©Ī· does - package all the generated files 20:00
users don't need to bootstrap
lucian plobsing: in general, because it seems to claim to only support a subset of dyn lib usage
NotFound And what winxed itself does for the benefit of plumage installs 20:01
In fact we can ship winxed with parrot just by adding two pir generated files. 20:02
plobsing lucian: sure. but the same can be said of C.
or anything else that isn't assembly
lucian plobsing: i may be wrong, but i understood that nci doesn't support certain things that libffi does 20:03
20:03 benabik left
plobsing lucian: yes. that is in order to make it easier for implementations where libffi isn't available. 20:03
if you'd like, you can create a wrapper to libffi, bundle it up, and tell users that don't have it to get lost. 20:04
lucian plobsing: are there interesting platforms without libffi?
plobsing lucian: most windows platforms 20:05
lucian plobsing: uh, no
NotFound That counts as "interesting"?
plobsing NotFound: from a "how the hell do people put up with this?" perspective, yes
lucian i mean it works on windows
plobsing lucian: there are APIs that libffi is incapable of calling 20:06
lucian plobsing: like COM you mean?
plobsing some proprietary C compiler can come out tomorrow with a "best ABI yet" calling convention that is totally incompatible with anything else. boom, all of a sudden incompatible 20:07
or how about if systems start getting written in Go, and shared objects contain functions with multi-returns?
lucian plobsing: can NCI handle that better? 20:08
plobsing no, it cannot. I'm making the point that, whatever the system, it will not cover all cases, and therefore the fact that our NCI doesn't cover all cases is not much of a fault.
NotFound There's nothing I can do, a total eclipse of the ABI. 20:09
lucian plobsing: but isn't choosing the system that covers the most cases (and has the most usage already) better?
plobsing the only VM I know of that is capable of such things is Factor. but that's because they've built in their own assembler.
lucian: more is better, everything else being equal. however, if exposing libffi's capabilities add significantly to the complexity of both the API and the implementation, it is important to take that into consideration as well. 20:11
lucian plobsing: does it? i would guess it would do the opposite 20:12
plobsing Any sufficiently capable FFI system will reinvent half of C's type system. Poorly.
whiteknight more or less poorly than C's type system? 20:13
dalek rrot: 8ca9a58 | petdance++ | / (6 files):
Merge branch 'master' of github.com:parrot/parrot
rrot: c2b6ced | petdance++ | config/gen/makefiles/root.in:
ratcheting down some splint warnings
whiteknight a poor reimplementation of a poor system might turn out quite nicely
lucian plobsing: perhaps. but is NCI's poor implementation better than libffi's poor implementation?
whiteknight "oh no, we failed to fail as badly"
lucian whiteknight: the best example i know of that is wine
Andy cotto_work: The PARROT_CANNOT_RETURN_NULL stuff isn't likely to be much use, because few things acutally use them.
If I can work it into the GC API, then we've got something. 20:14
plobsing lucian: parrot's NCI is capable of bootstrapping full LibFFI, if you choose to do so. we prefer to hide the choice of library as an implementation detail.
partly because we don't want to make libffi a hard dependancy, and partly because libffi is inherently inefficient. 20:15
lucian plobsing: are there better docs on NCI?
plobsing better than what?
lucian docs.parrot.org
plobsing no idea. I haven't used those in months. probably not. mostly it is by example, or read the source. 20:16
NotFound whiteknight: talking about bootstrapping problems, I wonder if it might be possible to rewrite winxed tests using Rosella. 20:17
whiteknight NotFound: I've been treating Rosella as the "standard library" for winxed, in my head 20:18
but yes, that does create a pretty big bootstrapping problem
because Rosella itself uses most winxed syntax
NotFound As long as they are not used by the compiler nor required for programas unless they explicitly ask, there must not be problem to have a bunch of libraries declared as "standard". 20:19
whiteknight like I said, it's all in my head. Some of the libraries are starting to seem pretty useful to me 20:20
NotFound That was the intention, wasn't it?
whiteknight about 50% 20:21
the rest was me having fun (20%) and avoiding work on IMCC (30%)
:) 20:22
NotFound Avoiding to write pir was the main reason that came winxed to existence :D 20:23
Having fun... that's more or less the same. 20:24
lucian thinks programmer laziness is the biggest drive for useful programs
whiteknight yes, the amount of PIR you have to write is inversely proportional to the amount of fun you have
bacek ~~
Good morning, humans
whiteknight hello bacek
bacek aloha, whiteknight 20:25
Coke as a constrast, I find writing PIR to be much more straightforward than getting PCT to do what I want. YMMV.
20:26 benabik joined
NotFound Coke: that's why I choosed to directly generate the pir. 20:26
Coke wonders why Andy just did a merge from master to master. 20:28
ENOREBASE? 20:29
whiteknight he just wanted to show master who's the boss
Andy Coke: I don't know why that happens.
Coke that's a pretty big commit with a lot of changes then.
You might want to do "git pull -rebase" instead of "git pull" 20:30
er, --rebase 20:31
plobsing alias pullr = pull --rebase
in gitconfig
Coke I prefer 'rb', but yah. ;) 20:32
bacek bad idea
plobsing bacek: why? 20:33
bacek better to put 'rebase = "true"' into .git/config 'branch "master"' section
plobsing that's neat
tadzik and has to be done for every repo 20:34
bacek and [branch] autosetuprebase = always
than new branches will be rebased by default
benabik Don't need the '= "true"'. Just 'rebase' on a line of its own is enough.
bacek It's without quotes anyway :) 20:35
whiteknight not even. All you need is the word "rebase" in a file hidden somewhere in /opt/local/
lucian it can even be in a different language, git will try and use dictionaries 20:37
it will even deal with rot13
lucian has probably gone too far
plobsing lucian: I heard you liked version control. So I put your gitconfig in a git repo so you can commit while u commit. 20:38
whiteknight sup dawg. I herd you liek git. So I put git in a repository so you can git get git while you git git. 20:39
lucian heh
whiteknight as a general observation, I don't think we are referring to each other as "dawg" enough in the channel 20:40
cotto_work +1
er, +1 dawg
whiteknight word
20:40 lucian is now known as dawg
atrodo dawg, too true 20:41
dawg whiteknight: better?
whiteknight much better
*much better, dawg
bacek cotto, jfyi minimal freeze/thaw fail is "class Foo{}; pir::thaw__ps(pir::freeze__sp(Foo.new))" 20:43
cotto_work hard to get more minimal than taht 20:44
*that
bacek: do you know what causes it to fail?
bacek cotto_work, no idea... 20:45
whiteknight is that in master? 20:46
cotto_work ./parrot-nqp -e "class Foo{}; pir::thaw__ps(pir::freeze__sp(Foo.new))" fails nicely for me
in master
no segfaults, which I guess is nice 20:47
whiteknight Can't shift from an empty array?
cotto_work not even if you wish really hard
whiteknight no, is that the error you're getting?
cotto_work that too 20:48
bacek whiteknight, this one
20:49 plobsing left 20:50 ambs left, M_o_C joined
whiteknight I assume the problem has something to do with NQP/P6object? 20:51
or is it pure-parrot?
bacek P6object
whiteknight okay
bacek meh... Capture PMC isn't freezing properly. 20:55
whiteknight somebody actually uses Capture? 20:57
I didn't realize NQP was using it
bacek PCT is using it 20:59
PCT::Node is Capture
whiteknight it doesn't look like Capture implements VTABLE_freeze or VTABLE_thaw
21:06 fperrad left
Andy Coke: I usually DO a git pull --rebase. 21:07
I even have git pull --rebase origin master to "gprom"
dalek rrot: 47dd195 | bacek++ | t/pmc/capture.t:
Add todoed tests for Capture.freeze/thaw.
rrot: 4ca6805 | bacek++ | / (2 files):
Implement Capture.freeze/thaw. Closes #2047
bacek It was quick :) 21:08
dalek TT #2047 created by bacek++: Capture PMC doesn't freeze/thaw. 21:09
TT #2047: trac.parrot.org/parrot/ticket/2047
TT #2047 closed by bacek++: Capture PMC doesn't freeze/thaw.
TT #2047: trac.parrot.org/parrot/ticket/2047
whiteknight so quick that you fixed it before you opened the ticket, apparently 21:12
NotFound Tunnel effect commit! 21:13
bacek waves from THE FUTURE 21:15
dukeleto barfs from the past 21:18
21:20 plobsing_ joined
atrodo ponders from the present 21:20
dalek rrot: 276554b | bacek++ | src/pmc/capture.pmc:
Set custom_mark flag in Capture.thaw when needed.
 21:24
Coke Andy: perhaps dukeleto knows why you're getting those merge commits, then. 21:27
dukeleto: in re: andy's commits to master today.
21:28 dmalcolm joined
Andy Coke: I think that one was an attempted rebase that failed. 21:28
I only had the one, right?
Coke a pair: one real commit, one rebase
21:29 mtk left 21:30 whiteknight left, mtk joined
dalek rrot: fabdef9 | petdance++ | config/gen/makefiles/root.in:
improve splint error messages
 21:30
21:46 Andy left
dukeleto Coke: the merge commits are from doing "git pull origin master" 21:48
21:55 hercynium left 21:56 dawg left 22:03 dodathome left
cotto_work bacek++ 22:07
22:20 jnthn left 22:28 jnthn_ joined 22:30 M_o_C left 22:52 plobsing_ left
Coke dukeleto, andy: sounds like had diagnosed it right, then, as he said he had a failed rebase. 22:59
dukeleto Coke: failed rebase?
23:00 rurban_ joined
dukeleto Coke: git_workflow.pod describes the situation in detail 23:00
Coke: meaning he gave up on the rebase and just did a pull ? 23:01
Coke: not a huge deal
Coke: just annoying when history is filled with useless merge commits
23:02 rurban left, rurban_ is now known as rurban 23:51 dmalcolm left 23:52 plobsing joined, kid51 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!