Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere
Set by moderator on 2 June 2010.
cotto_work wacky: You don't have permission to access /parrot/chrome/common/css/wiki.css 00:00
whiteknight nice 00:01
ash_ that loads for me... hmmm
cotto_work I guess we have to keep our css secret.
ash_ i can even curl it
whiteknight protect it from ze germans 00:02
cotto_work trac.parrot.org//parrot/chrome/comm.../search.js <- how does that look?
whiteknight forbidden
cotto_work js or forbidden
ash_: ^? 00:03
ash_ works if you take out the extra /
with // it is forbidden
(for me) 00:04
kid51 forbidden for me with either one slash or two
ash_ i might be logged into trak? let me check
no, not logged in... hmm 00:05
works in FF, Safari and Chrome (on OS X), if i only have 1 /, with the // it always gives me forbidden 00:06
cotto_work seems to deny when I'm logged in, otherwise not 00:07
ash_ thats backwards... 00:10
you'd think when your not logged in you'd get access denied
cotto_work no, just broken
It's denying access to js and css files.
ash_ when your logged in? 00:12
cotto_work when my^H^HI'm logged in
00:27 ash_ joined 00:32 mikehh joined
dalek parrot: d02c64e | dukeleto++ | plparrot (2 files):
Attempt to fiddle with open() mocking
 00:33
parrot: 3d41ad7 | dukeleto++ | t/sql/test.sql:
Add a test for FileHandle.open in PL/PIRU
tcurtis Hm... I just got a make fulltest pass on trunk at r47316(last change at 47310). I thought there were some problems being had? 00:45
cotto ohai 00:46
dalek rrot: r47317 | tcurtis++ | branches/gsoc_past_optimization (2 files):
All PAST::Node and PCT::Node "attributes" exact match tests pass.
 01:10
01:18 plobsing joined
ash_ ping plobsing 01:32
plobsing ash_: pong 01:33
ash_ hi
plobsing so how goes it?
ash_ the robot competition is over, so now I am working on GSoC full time 01:34
i am trying to make a parser for signatures, its a bit annoying without regular expression :P, since i'd like to keep it all in C that the core has access to, which is pretty basic string ops
right now, i think i have a strategy that works, i am making a test program to ensure that my parsing of signatures is right, then i'll work on putting it into parrot 01:35
plobsing can I convince you to either stop hand-coding your parser or reduce the structure your signatures allow? 01:36
matching braces require at least a pushdown automaton IIRC
ash_ sure?
purl sure are a lot of joels in perl
plobsing If you want to do the signatures you proposed to the list (or some close variant), I'd look into some form of state machine generator. 01:37
ash_ yeah, bison could do that 01:38
plobsing pick your favorite tool and go for it 01:39
Bison is a good choice
ash_ i was thinking, most of its pretty simple because i only limit most modifiers to 1 character, or it only takes 1 character to identify which type of modifier it is, so i only have to look ahead 1 character. If i was doing more of a look ahead i'd need something else, but i think i have a strategy thats working...
plobsing well if it is working, stay the course. But I'd watch out for the matching braces you gave in examples. 01:40
cotto any reinvented wheels should at least be round 01:41
ash_ the postfix { } and [ ] only need 1 char to identfy them, '[' and '{', then right now i am either looking for a digit (for [ ]) or for { i grab the whole string until i reach '}' 01:42
those are the two complicated cases
{ } also checks that your in a structure definition, otherwise i say its an error (which is currently just me saying in stderr that its a bad identifier 01:43
if i have problems with this strategy after i test it further i'll probably use bison, since I know it and it can produce C that should be acceptable
dalek rrot: r47318 | jkeenan++ | trunk (135 files):
Merge tt1452_configure_debug branch into trunk. Implements Parrot::Configure::debug().
rrot: r47319 | jkeenan++ | branches/tt1452_configure_debug:
Branch has been merged into trunk and is no longer needed at HEAD.
plobsing purl: Branch has been merged into trunk and? 01:44
purl plobsing: i don't know
plobsing aw
01:44 aloha joined
plobsing ash_: are there any other issues that have come up? 01:45
ash_ um, i am not sure how to use the gen configuration things to properly mix my code into the source
plobsing ah. that *is* black magic 01:46
ash_ are the gen things pretty one off ish? or is it generic?
plobsing ash_: we have a decent general-case framework, but it is a little eccentric 01:47
are you a) trying to conditionally compile files? b) trying to conditionally generate cpp #defines? c) trying to insert arbitrary text into a template?
ash_ i'd like the nci.pmc to have two separate implemenations so they can be maintained independently with a common interface and at config time pick which one to put into src/pmc 01:49
i think that would be a good way of doing it
if thats not how things are normally done though i am fine with a different method
plobsing that seems like the simplest thing to do. which is the best IMHO. 01:50
ash_ so they probably wouldn't have to have any real parsing of their content, just a move or copy would do 01:51
plobsing I don't know of any steps that do that yet, but our config does determine the system-appropriate 'cp' and 'mv' commands 01:52
or you could just use the ExtUtils module that it winds up using half the time 01:53
ash_ I'll look into it, for now i'd like to get my parser and my test cases working, then i'll make sure it responds to the configuration commands (like --without-libffi) and works with a similar interfaces as the old NCI system (or update the old NCI system if it needs to be updated) 01:55
are there any issues you forsee with the llvm?
plobsing LLVM provides excellent targets for probing if I am not mistaken, so none from a config perspective. 01:56
and I don't anticipate any trouble from LLVM for actually generating code. so not really 01:57
ash_ its odd, in the llvm_config branch whoever wrote it doesn't use llvm-config (which comes with the llvm)
detect_llvm branch i mean 01:58
plobsing the author may not have been aware of the tool. or perhaps it isn't always installed or something. 01:59
my money's on the first though
ash_ i'll check on some other systems to see if its installed by default, but i think it is 02:00
tonight/tomorrow can i send you a copy of my parsing tool to see if you think its okay? assuming i don't run into problems getting it finished 02:01
plobsing ash_: sure. 02:02
so you intend on getting the parser done within the next few days? excellent! 02:03
pmichaud bacek_at_work: can I double-check the location of the multi branch you'd like me to review?
ash_ I'd like to get the libffi stuff done by monday or tuesday? if thats at all possible... i really wana work on the llvm stuff
tcurtis Fun. I have a segfault that disappears when I insert some extra says to see where exactly it happens.
pmichaud tcurtis: Welcome to my hell. 02:04
plobsing ash_: yes, that's the meat of the project.
sorear tcurtis: --trace=1
pmichaud oh, that's another part of my hell. Turning on tracing causes the segfault to disappear. :-/
hope you don't end up in that little dead end... 02:05
plobsing ash_: OK we have what you did, where you are, and where you're going. I think that's a wrap!
ash_ the parser returns a structure that has the various parts of the libffi function builder in it, so making the libffi calls will be easy when i am done with this, its just converting pmc's to the right types, and converting the result to the right pmc when i am done that will be annoying but i don't imagine to difficult
sorear also, you're not a parrot expert until you can generate a backtrace using gdb from a core dump
ash_ the only complicated data structure i might have to implement is a union type pmc
sorear protip: pbc_disassemble to map PC numbers into lines
ash_ s/might/will
plobsing ash_: good idea. if it is too much trouble (and unions aren't *that* common), leave it (at least for now). publish early publish often. 02:07
ash_ i also need to figure out if 64 bit ints, since $I0 registers are all only 32 bits 02:09
02:10 petdance joined
plobsing some parrot operations use 2 INTVALs to handle overflow. For example the tell op 02:10
or you could use a PMC 02:11
ash_ I noticed github.com/ashgti/parrot/blob/gsoc_..._h.in#L118 which seems like there should be some sort of portable way of doing 64 bit ints 02:13
02:14 preflex joined
sorear you mean like int64_t? 02:17
HAHA THAT'S C99
plobsing I don't think that's the way to do things. Users should be able to choose smaller (and possibly platform-native) int registers. 02:18
ash_ parrot could take the c approach to int, int could be a short, or a long, or a long long, its all system dependent, but its at least the size of a short 02:19
tcurtis Well, my segfault seems to have gone away, but I don't really know why. All I did was stop explicitly specifying the signature for pir::push. And if I change the code back to specifying it, I don't get a segfault, just empty strings in the array.
ash_ an int register could be at least 32 bits, maybe more if your system supports it
plobsing I thought that was the unwritten standard now.
that INTVAL64 seems like wishful thinking to me 02:20
ash_ i don't think it is, even on 64 bit systems it defaults to a 32 bit
plobsing really? I thought parrot would break in a number of places if you couldn't fit a pointer in an intval.
bacek_at_work pmichaud, github.com/perl6/nqp-rx/tree/multis 02:21
02:22 abqar joined
ash_ well, unless my long is 64 bits... is long 64 bits on OS X? hmm, i'll check 02:23
i thought it had to be long long before it was 64 though, one sec
tcurtis I think long is 64 bit on 64 bit OS X. Not on i386, though. 02:25
ash_ yeah, long is 64 bits with -m64 and 32 bits on -m32 02:26
so it is a 64 bit register then on os x, neat, i am completely wrong
plobsing neat is not the first word I'd use to describe the arbitrary sizing of C's integer types 02:29
02:29 TiMBuS joined
ash_ lol, true 02:31
if the int register has to be the size of a pointer you could use intptr_t or uintptr_t defined in stdint.h, those are supposed to be the size of a pointer for the native system 02:38
plobsing this is true. but we like to give the illusion that we can work with smaller intval types :p 02:39
dalek rrot: r47320 | tcurtis++ | branches/gsoc_past_optimization (2 files):
PAST::Pattern.blocktype matching works.
 02:49
sorear ash_: that might work, except for the oh so minor detail that we can't use stdint.h 03:05
stdint.h isn't specified by C89
ash_ ah, dang, i didn't realize that was part of c99 too 03:06
cotto It's an 11 year old standard. I'm sure all the most commonly used compilers will implement it. 03:09
03:09 theory joined
ash_ well, Microsoft's compiler only supports bits of C99 not all of it 03:12
which is the trouble
cotto forgot the sarcasm tags 03:13
though they're usually implicit in discussions about standards and their implementation
ash_ going to bed, be back later 03:14
Coke trac looks better again. I think there might have been a site update earlier today that was supposed to be unnoticable. :| 03:18
cotto yup. 0.11.6 to 0.11.7 03:20
still looks broken though 03:21
Coke cotto: you're caching the failure.
?
BOOYAH, no you're not.
I'll open a ticket. 03:22
cotto silly webs 03:23
03:23 aloha joined
cotto so useful yet so stupid 03:23
aloha, aloha
aloha, status 03:24
03:26 parthm joined
Coke ticket opened. :P 03:26
cotto coke++
also, test site ticket pinged 03:39
03:44 janus joined 04:20 kurahaupo joined
cotto If anyone's up for a brain picking, I've got a list of Lorito questions that'll need answering during the design process. 05:30
trac.parrot.org/parrot/wiki/LoritoRoadmap
05:30 bacek joined
cotto ohai 05:30
05:35 szabgab joined
dalek tracwiki: v14 | cotto++ | LoritoRoadmap 05:38
tracwiki: trac.parrot.org/parrot/wiki/LoritoR...ction=diff
05:42 kurahaupo joined 06:06 uniejo joined 06:07 frodwith joined
Coke grumbles at cmp_str being removed. 06:07
cmp_str_iss, that is. (and cmp_num_iii) 06:09
dukeleto i am attempting to load perl6.pbc in PL/Parrot and getting this message: gist.github.com/423516 06:11
if anybody can throw me a bone, i would greatly appreciate it
plobsing Coke: it didn't do anything different from cmp 06:12
06:13 parthm left 06:18 eternaleye joined
Coke plobsing: danke. 06:24
dalek rrot: r47321 | tcurtis++ | branches/gsoc_past_optimization (2 files):
Block attributes other than symtable are now tested for exact matches.
plobsing I removed it because "$I0 = cmp_str $P0, $I1" did the *exact* wrong thing
rrot: r47322 | plobsing++ | trunk/t/pmc/freeze.t:
fix a coretest
Coke ah, crap. I tried to leapfrog from immutable strings to the end, and partcl is unhappy. 06:30
will have to go back and step through again. :P
dukeleto: random guess :dynops. 06:33
06:42 aukjan joined 06:46 viklund joined 06:50 frodwith joined
dalek rrot: r47323 | plobsing++ | trunk (4 files):
convert some raw Interp.stdhandle calls to use PIO_x_FILENO macros from stdio.pasm
 06:57
purl I don't know how to convert some raw Interp.stdhandle calls to use PIO_x_FILENO macros from stdio.pasm.
rrot: r47324 | plobsing++ | trunk/docs/pdds (2 files):
mark some POD-PIR as invalid (core doesn't contain 'perl5_group' or 'tcl_group' libraries)
Coke arrrrgh. 07:00
for those of us that were relying on the old substr that both modified the existing string AND returned the substring, we're screwed. 07:01
yes?
(that is, replace__ssiis is not a dropin replacement for substr__ssiis) 07:02
msg bacek - what is the proper replacement code for the old substr__ssiis ? (replace__ doesn't have all the side effects) 07:03
purl Message for bacek stored.
bacek_at_work Coke, substr+replace combo 07:04
Coke so I have to do the same work /twice/? 07:06
bacek_at_work no. It's different work :)
Coke too zzz now. will grumble at you later.
07:17 tcurtis joined
tcurtis msg ash_ Have you seen blogs.perl.org/users/doubi/2010/05/...-spec.html ? He's using libffi to do something like Python's ctypes for Perl 5. Might be work looking into what he's doing. 07:22
purl Message for ash_ stored.
07:33 fperrad joined 07:41 clinton joined 08:04 tcurtis joined 08:05 Essobi joined 08:13 JimmyZ joined
dalek kudo: a1140cc | moritz++ | build/PARROT_REVISION:
bump PARROT_REVISION to get latest nqp-rx fixes
 08:34
08:37 eternaleye joined 08:53 snarkyboojum joined
dalek rrot: r47325 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Simplify TMS.is_owned
 08:54
rrot: r47326 | fperrad++ | trunk/examples/languages/squaak (2 files):
[squaak] refactor without dynops IO
rrot: r47327 | fperrad++ | trunk/examples/pir/befunge (3 files):
[befunge] remove opcodes getstdin/getstdout
rdinal: b22731f | fperrad++ | src/builtins/ (2 files):
remove opcodes getstdin/getsdout/getstderr
 09:14
09:34 ruoso joined 09:46 purl joined
dalek lambda: ca471cc | fperrad++ | unl.pir:
remove some IO opcodes
 09:53
lambda: 904f2d2 | fperrad++ | setup.pir:
chmod +x setup.pir
purl I don't know how to convert CRLF to LF.
zy-k: d09d73d | fperrad++ | setup.pir:
chmod +x setup.pir
 10:01
purl I don't know how to convert CRLF to LF.
zy-k: f09651e | fperrad++ | lazy.pir:
remove some IO opcodes
bacek purl, purl? 10:03
purl rumour has it i am a retard or a trannybot or a fuckslut in GumbyBRAIN's mind or the national trannywreck champion or better than any of you #perl fucktards or very vile or the one to watch >:) or omniscient or 13 or well behaved or useless or fun or a megalomaniac or known to get testy if not fed or slacking off or gummy in scalar context or a silly bot or a stitch or a coprophiliac
bacek Yay. She've got her memory back 10:04
dalek a: 3defd23 | fperrad++ | lua/lib/lua (3 files):
remove opcodes getstdin/getstdout/getstderr
 10:20
a: 3cb3b32 | fperrad++ | t/pmc/function_hll.t:
fix test
10:25 zibri joined, mikehh_ joined
bacek seen chromatic 10:28
purl chromatic was last seen on #parrot 4 days, 12 hours, 15 minutes and 41 seconds ago, saying: That seems workable. [May 29 22:12:45 2010]
10:29 lucian joined
dalek rrot: r47328 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Pacify compiler.
 10:33
rrot: r47329 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Speed-up testing on TMS.is_pmc by checking "pmc" flags.
rrot: r47330 | bacek++ | branches/gc_massacre/src/gc (2 files):
Speed up PoolAllocator.is_owned by caching lo/hi bounds of arenas.
rrot: r47331 | bacek++ | branches/gc_massacre/src/gc (2 files):
Poor-man templates: implement macros for manipulating lists
rrot: r47332 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Use list macros instead of functions
rrot: r47333 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Skip marking already live or dead objects.
rrot: r47334 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
Reimplement TMS.free_pmc_header.
10:38 lucian_ joined
dalek rrot: r47335 | gerd++ | trunk/tools/docs/filename_and_chapter.pl:
Add the PIR documentation to be generated as PDF
 10:50
bacek msg chromatic List based TMS doesn't work... It's freaking slow. 11:09
purl Message for chromatic stored.
11:47 JimmyZ joined 11:49 whiteknight joined
dalek kudo: 3a6b43f | moritz++ | (2 files):
First shot at pure-Perl Cool.trans

The range unpacking is greatly inspired by (David Green)++'s p6c mail. Also pyramidine++ for his initial implementation.		 11:58
whiteknight good morning, #parrot 12:02
bacek aloha, whiteknight 12:03
whiteknight hello bacek
so we're not eliminating constant PMCs in this iteration?
I do think that's something we should do soon, if not right now
We should be able to either register all PMCs, or anchor them somewhere in the object graph. 12:05
bacek whiteknight, yes. I would like to get rid of them. Just because it will be much easier to implement proper Generational GC without them. 12:06
whiteknight so should we keep working in the _no_constants branch, or wait and do it later?
bacek It's lower priority now. I've got workarounds in both TMS and MS2 for zombi^W constant pmcs. 12:08
I think proper encapsulation of PMC Attributes allocator will help more.
And hairy-hairy string compact pool... 12:09
whiteknight okay. Let's shelve the idea. I'll see about stealing that NCI/ParrotLibrary patchset for use in trunk since I think it's still a good idea and we can start over later 12:10
bacek deal
whiteknight, was it your idea to split string allocator into separate "class"? 12:11
whiteknight yeah
bacek than you can start now :) 12:12
whiteknight My idea was that the GC was really two parts: a fixed-width object allocator, and a buffer allocator
dalek rrot: r47336 | bacek++ | branches/gc_massacre (5 files):
Add dumb M&S GC based on GCMassacre wiki page.

Overall performance isn't so great due absence of fast Attributes allocator.
rrot: r47337 | bacek++ | branches/gc_massacre/examples/benchmarks/stress_integers.pir:
Add GC stress test for almost pure PMC allocator speed.
whiteknight we may want to merge them together into a single allocator, but I feel like the fixed-width allocator gives us a performance boost 12:13
bacek whiteknight, I don't think that merging them is good idea. 12:14
whiteknight yeah, I don't either. I'm just presenting ideas
bacek We just have to figure out proper interaction between PMC GC and String GC. Just because PMC GC is driving. 12:15
whiteknight the PMC/STRING header GC will have to run first and clean up the headers. Then the buffer GC goes over the headers and compacts the buffers 12:16
at least, that's how it is now, we could change it if you have a better ida
idea
bacek I do want GenGC.
And it will be not so easy... 12:17
But... Let me think for few minutes.
whiteknight maybe we need to change strings over to a proper refcount.
every STRING* header has a pointer to the buffer. str->buffer[-1] could contain a refcount
bacek no way!
whiteknight why not? Then buffer deallocation would be an automatic part of normal GC 12:18
bacek we do want compacting.
whiteknight I have to run an errand. I'll be back in a little while
we can compact after the GC run. Anything that is still alive with a positive refcount gets compacted 12:19
everything else, not so much
be back in a bit
whiteknight leaves
12:23 cognominal joined 12:27 JimmyZ_ joined 12:32 bluescreen joined 12:40 jsut joined 12:46 mikehh joined
pmichaud bacek: reviewing multi code is my first task after taking daughter to school 12:49
(was going to do it last night but fell asleep) 12:50
bacek pmichaud, I'll probably fell asleep soon.
or it's "fall"
anyway, everything in C<multis> branch in main nqp-rx repo 12:51
pmichaud bacek: excellent.
bacek want me to sync it with master?
pmichaud bacek: no thanks, I can review it okay as-is 12:52
bacek pmichaud, ok
12:58 lucian joined 13:01 lucian__ joined
dalek kudo: 2242efb | (Solomon Foster)++ | src/core/metaops.pm:
Implement the new rules for handling hypers of different lengths.
 13:09
13:17 atrodo joined
whiteknight I don't like it when bacek falls asleep 13:17
so much work stops getting done until he comes back :) 13:18
bacek I do need to recharge my batteries
Unfortunately there is no compact nuclear power reactors yet
whiteknight certainly none approved for use with humans 13:19
bacek I don't need such approval 13:20
Coke \\o/ yay, partcl should be fixed by this evening. 13:21
... now stop breaking it. =-)
whiteknight Coke: far more likely is that you just stop fixing it :) 13:22
Coke ... well, I've discovered that makes me grumpy, so I'll try to avoid that in future. 13:25
whiteknight haha, yeah.
pmichaud: ping
pmichaud whiteknight: pong
Coke PING PONG! 13:26
purl hmmm... ping pong is for everybody
whiteknight pmichaud: does NQP-RX support functions with multiple return values?
I know it didn't used to, I'm wondering if that has changed
bacek good night. humans 13:27
Time for recharge
Coke good night, bacbok.
whiteknight goodnight
pmichaud whiteknight: it does, but not in the parrot sense of multiple return values 13:28
because there's not really a way to put multiple return values into a return exception
(in the parrot sense)
in other words, in NQP-rx it's perfectly legal to do 13:29
whiteknight at the risk of sounding exceptionally stupid, is there a reason why we're still using return exceptions for that, instead of something like a return continuation?
pmichaud return ($a, $b, $c)
but you get back a single RPA with three elements
whiteknight: what's a "return continuation"?
Coke whiteknight: by return continuation, you mean a normal parrot return?
because the parrot sub's .return isn't necessarily returning where the HLL is returning to. 13:30
whiteknight pmichaud: I'm being unclear. In my HLL, can I write grammar rules so my HLL allows multiple return values? Previously, PAST didn't support it
by "return continuation" I meant a continuation pointing to the label of some kind of return logic
or even the continuation that points back to the caller
pmichaud whiteknight: so, you're basically saying that we set up a return continuation at the beginning of a HLL sub, and then invoke it when we're ready to return? 13:31
how does that return continuation carry the return values?
whiteknight pmichaud: yes, basically. The benefit there is that you can invoke that continuation with any number of return values
pmichaud how does the nested Parrot sub locate the return continuation it's supposed to use?
how does the label that the return continuation targets obtain the return values? 13:32
13:32 JimmyZ_ joined
whiteknight you can locate anything if you store it in a sufficiently odd-named lexical 13:32
pmichaud: it all really depends how much cleanup work do you need to do at the end of every HLL sub? 13:33
pmichaud so, in the nested sub, we'd do
$P0 = find_lex '!return_continuation'
$P0(1, 2, 3, 4)
?
(short answer to your earlier question is that PAST has no problem with doing things with multiple return values.) 13:34
(one can create a :pirop<return> node that will generate a PIR .return(1,2,3,4) instruction. The trickier part is dealing with HLL returns.) 13:35
whiteknight yes, that's exactly what I was thinking 13:38
I'm sure i'm missing some feasibility details
so long as PAST can support it, I guess I really don't care how the sausage is made 13:39
pmichaud the problem is on the receiver side 13:41
in the outer sub that sets up !return_continuation, I get
$P0 = new ['Continuation']
set_addr $P0, label
...
label:
# we get here because someone invoked a 'return'
# how do we get the arguments? 13:42
i.e., how do we get the return values?
that's the part I don't know how to handle.
this is also the place where we have to have NotFound++'s "finalize" opcode working properly, so that we can roll back the caller stack to the correct continuation point 13:43
whiteknight pmichaud: well, we wouldn't do it that way. We can get the current continuation from the context object and invoke that directly 13:45
unless there is cleanup to do a the end of the function 13:47
pmichaud right... I'm interested in the cleanup case.
jnthn Not to mention that in Perl 6 you may need to type check and/or coerce the value.
Before returning it. 13:48
So a general solution needs us to be able to do something before returning.
Coke tcl specifically deals with returns as control exceptions, so this isn't a cross-HLL portable thing, either.
whiteknight ...in which case we would need to unpack the context, do cleanup/postprocesing, and pass them to the next continuaton
pmichaud ...unpack the context?
how does one do that (in PIR)?
whiteknight pmichaud: There may not be a good way to yet 13:49
Coke (rather; tcl deals with [return], [break], [continue], and [error] all the same way.)
whiteknight so this idea needs more consideration
pmichaud sure.
jnthn I'm not convinced that we'd end up with a cleaner result by doing some continuation based thing rather than exception based.
In both cases you need to clear up a bunch of contexts.
13:49 hudnix joined
pmichaud and keep in mind that when PAST was put together, Parrot had no ability to get hold of contexts (because they weren't PMCs) 13:49
whiteknight jnthn: it would be faster, if only marginally so
jnthn It may be more expensive to do it the continuation way since you have to clone the the chain of contexts when taking the continuation. 13:50
pmichaud it's definitely faster to invoke a continuation that jumps to the correct point than to throw an exception and go through a chain of exception handlers
whiteknight jnthn: it doesn't clone the contexts, I don't believe. Just takes a reference
pmichaud but as yet, continuations don't have payloads afaik
jnthn In the ideal case, yes.
pmichaud and there doesn't seem to be a way to grab any parameters from an invoked continuation
jnthn You have to know it's safe to do that though.
whiteknight continuations do take argument lists, and a call to get_args can retrieve them 13:51
pmichaud whiteknight: from PIR?
whiteknight from PIR
pmichaud example, please?
whiteknight that's something that I either need to hunt for or create
pmichaud ah
whiteknight but I know that, at least after the PCC refactors, it is very possible
jnthn pmichaud: I guess if we did stash a lexical continuation, we get lexical return semantics for free. ;-)
pmichaud also, when a continuation is invoked, is that considered to be a new caller in the call chain, or does that roll-back any intermediate callers?
jnthn: this is exactly what I've been asking for when I say that we need a better way to handle "leave semantics". See my messages from last November. :-) 13:52
whiteknight $P0 = new ['Continuation'] 13:53
set_addr $P0, exit_routine
exit_routine:
.param pmc args :slurpy
.param pmc args_n :named :slurpy
...
.return (args :flat, args_n :flat)
I haven't tested that, but something like it should work
pmichaud whiteknight: that works today? or you're proposing it?
I'm pretty sure that doesn't work today. I bet it doesn't even parse.
whiteknight the .param syntax may be the sticking point. 13:54
pmichaud iirc, imcc only accepts .param immediately after .sub declarations
it doesn't even allow blank lines or comments
whiteknight yeah, so we probably need to call the raw get_args opcode directly
jnthn Dunno if the .get_arg hack we use for exception handlers would work.
Or whatever it's called.
whiteknight .get_result?
jnthn Maybe
jnthn checks
pmichaud anyway, the ability to grab values from a continuation is effectively NYI in Parrot, which is one reason (among many) why PAST hasn't used them. :=) 13:55
jnthn uncaught_exception:
.get_results ($P0)
That one, yeah.
pmichaud I thought that just got me the exception object 13:56
not any payload
in the exit_routine case above, I already have the continuation object
jnthn pmichaud: Indeed, and I've no clue what it does in the continuation case.
pmichaud that's not what I need.
jnthn pmichaud: I was guessing it might get the actual argument(s).
pmichaud: Since the invoke of the continuation woulda set up a callsig.
iirc
pmichaud jnthn: does 'throw' use PCC to pass the exception? eww. 13:57
jnthn pmichaud: I'm pretty sure it does, or at least that's what the code looked like it was doing.
I ran over it the other day when fixing backtraces.
whiteknight pmichaud: if this is the functionality you are waiting on, I'll gladly try and get it put together soon
pmichaud whiteknight: what would be most useful is to see a working example where continuations are used to effect a 'return' from a nested block 13:59
whiteknight pmichaud: okay, I will try to slap that together first
pmichaud ideally where the routine (the outermost block) can intercept the return to do any cleanups it needs before doing the real return
I'm writing a short framework example... just a sec
whiteknight ok 14:00
nopaste "pmichaud" at 192.168.1.3 pasted "example with return handling" (36 lines) at nopaste.snit.ch/20879 14:04
pmichaud see nopaste. The XXX step is the part that isn't entirely clear at this point.
pmichaud tries .get_results 14:05
hmm, .get_results seems to work
nopaste "pmichaud" at 192.168.1.3 pasted "initial working example with return handling" (53 lines) at nopaste.snit.ch/20880 14:06
pmichaud now to see if it works with :slurpy
nopaste "pmichaud" at 192.168.1.3 pasted "initial working example with return handling and :slurpy" (51 lines) at nopaste.snit.ch/20881 14:07
pmichaud now to see what is happening with the caller stack. 14:08
looks like invoking the continuation "rolls up" the caller stack 14:10
oh, maybe not. 14:11
ummm....
so, can someone explain exactly what happens with contexts when a continuation is invoked? 14:12
whiteknight assuming I'm not missing anything, the continuation has a pointer to a context. When you invoke the continuation, that pointed-to context becomes current 14:14
any contexts that aren't being referenced by anything at that point will get GC collected
I don't know that any explicit unrolling happens. I'm not sure it's possible since it's not necessarily a linear path from where I am now to where I am going 14:15
pmichaud in src/pmc/continuation.pmc, we have
Parrot_continuation_check(INTERP, SELF);
Parrot_continuation_rewind_environment(INTERP, SELF);
I don't know what "rewind_environment" means here.
whiteknight _rewind_environment doesn't walk the list of contexts or anything
if I remember correctly, it doesn't do a hell of a lot 14:16
pmichaud ok.
whiteknight trac.parrot.org/parrot/browser/trun...sub.c:502. All it appears to do is set the current signature object 14:17
trac.parrot.org/parrot/browser/trun...sub.c#L502
pmichaud anyway, it wouldn't seem to be too difficult to add features to PAST::Block that would be able to set up a return handler like this 14:18
we'd want to support both options, because there are some languages for which returns really do need to be dynamic and exception based
(e.g., Perl 6)
14:18 JimmyZ joined
jnthn pmichaud: We could still use a way in PAST that makes it easy to handle performing some action on both implicit and explicit return values, fwiw. 14:19
pmichaud jnthn: this would do that.
jnthn pmichaud: The way I had it in alpha was horrible.
OK, great.
(I didn't put return value type checks back into master yet, mostly for not having a clean way.) 14:20
The alpha way made even me go "ick". ;-)
pmichaud well, it wouldn't completely handle that problem. but it would be closer 14:21
Coke pmichaud: blank lines and comments were fixed recently.
pmichaud Coke: ah yes, I remember seeing that. Coke++
Coke plobsing++
pmichaud jnthn: the "short" answer would be to have the implicit return simply invoke the continuation directly also. :-) 14:22
Coke # he's been doing a lot of IMCC upkeep lately, including the very old assignment syntax fix!
14:23 hudnix joined
jnthn pmichaud: Well, in alpha I had it just tack on to routines a last statement that essentially threw a return exception which of course was immediately caught by the code that followed it. 14:23
But, well, wasteful.
pmichaud agreed, that's a bit wasteful. but there's a bit of a mismatch in getting an implicit value versus values coming from a continuation/exception 14:24
still, a specialized PAST structure for the whole thing would likely work.
jnthn pmichaud: In PAST in general, yes. In Rakudo in general, we only ever have on return value however you look at it, in theory at least.
pmichaud: (e.g. a Parcel) 14:25
pmichaud PAST::Op.new( :pasttype<return_handler>, $mainline_past )
sets up a return handler, uses the value from $mainline_past if no return continuation invoked
or perhaps it's more of a PAST::Control node 14:26
I dunno.
or it's another special-purpose marker in PAST::Block
i.e., instead of :control<return_pir> it's :control<return_handler> or something like that. 14:27
Coke I am wondering why exceptions are more expensive than continuations here.
is it just an implementation issue, like with methods?
pmichaud Coke: because you have to walk the chain of callers looking for exception handlers
whereas with a continuation, you jump directly to the point registered with the continuation 14:28
no need to look up the call chain for handlers and figure out which ones are designed to handle the return exception.
Coke given that tcl (and perl6) explicitly support returning specific levels up the chain, that needs to be taken into account too. 14:30
14:30 plobsing joined
pmichaud well, the perl 6 case could be made slightly simpler -- we just attach the continuation as a specific property of the sub 14:31
so, &sub.leave actually invokes the return continuation
Coke pmichaud: yes, but that'll just return to the caller, yes? you're not necessarily going to know at compile time if the sub is going to do something wonky with the call chain.
(so I imagine you'd have to invoke N return continuations to get that effect.) 14:32
pmichaud right, we don't have a way for the intermediate subs to say "hey, I need this cleaned up before you jump around me"
i.e., an do-this-on-exit sort of thing. 14:33
but overall you're correct, I don't think in the general case there's going to be a significant performance difference between an exception-based return and a continuation-based one. 14:34
the real cost is in setting up the exception/continuation, not in handling it.
Coke (on exit handlers) tcl's needs are even worse there. =-)
(I need enter, leave, enterstep, and leavestep granularity.) 14:35
14:35 hudnix joined
Coke (though i suspect in my case, I'm going to just recompile the sub and generate a new AST for that case) 14:36
nopaste "pmichaud" at 192.168.1.3 pasted "another working example, invoke routine's return continuation directly" (45 lines) at nopaste.snit.ch/20884 14:39
pmichaud usefully, here's an example that doesn't involve creating an exception handler or continuation at all 14:40
this would work if you don't care about intercepting the return values
i.e., you're willing to return them directly to the caller.
more importantly, PAST already supports this. :-)
I might switch NQP to use it. 14:41
(instead of the exception-based return)
the downside is that it does involve making an otherwise invisible entry in the lexpad 14:42
jnthn The upside of that is that you then tend to get stuff having sane closure semantics. 14:44
Coke that would probably allow me to clean up partcl-nqp, since I have to avoid your exceptional returns for mine.
pmichaud Coke: yes, that's correct.
jnthn: I agree -- I may want to re-examine S04 with this new information in mind. 14:46
14:52 Draco joined
Draco Hello, people! 14:52
moritz hello Draco 14:54
Draco This may seems silly, but where is the parrot root directory, actually? 14:56
moritz depends on what you mean by "parrot root directory"
Draco I am reading through the tutorial and it mentioned that I should run the mk_language script from parrot directory 14:57
Coke the install dir?
ah, that's the build dir.
moritz Draco: the tutorial assumes that you have a source directory of parrot lying around
if you see a Configure.pl, you're likely there
Draco Ah, that is the one that I download, then run the make install-dev from? 14:58
Coke install-dev is also old directions. just 'install' works. 14:59
Draco Okies, then I get to the part where I start to add grammar....
But I can't find the parse directory in the Squaak/src 15:00
parser*
There is a squaak directory inside squaak/src...... But there is no grammar.pg inside, but I can find grammar.pm 15:01
15:01 bubaflub joined 15:04 theory joined
Draco So... Is the grammar.pg same as Grammar.pm? 15:04
particle yes, that's another but of unupdated history 15:05
Draco Okies, thanks.... 15:06
As I go down even further, I see the tutorial mentioned about changing the rule "value" to expression, but there is no rule "value".... So, I figure, maybe I just type it out myself... 15:07
15:08 patspam joined
Draco But the next line mentioned about renaming rule "integer" as "integer_constant" .... That rule is not there either... 15:09
Or does that merely means rename the "integer_constant" in the rule "expression"?
Sorry for so many questions :D 15:10
15:11 khairul joined, ruoso joined
pmichaud afk, errand 15:13
Coke draco - if you're reading off the blog posting, those docs are now ancient. 15:14
and I don't think they were ever updated. (so questions are inevitable, don't worry)
Draco: not that it helps you, but trac.parrot.org/parrot/ticket/1673 15:17
the just created ZOMG please update those docs ticket. 15:18
Draco Thanks much, Coke.... 15:24
I was reading from Wikibook, but I supposed it doesn't differ much from the blog 15:25
whiteknight The wikibook is older too 15:28
I haven't updated that in some months
it doesn't look like anybody has updated much documentation in some months 15:32
dalek TT #1673 created by coke++: need better "create a language docs"
TT #1673: trac.parrot.org/parrot/ticket/1673
15:37 cognominal joined
fperrad karma fperrad 15:42
purl fperrad has karma of 2379
dalek rrot: r47338 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add a 'Hello World' example
 15:48
Coke hello, François 15:52
sorear bacek: I am a fan of the proposal that we eliminate the substr "optimization". substr copies and no buffers are ever shared... 15:57
15:58 davidfetter joined 16:03 theory joined
whiteknight sorear: what's the purpose of that? Substrings get more expensive, memory requirements get higher, and there aren't a lot of gains that I can se 16:06
16:08 Maddingue joined
sorear memory requirements get lower because random strings in parse trees no longer retain the original 16:11
memory requirements get lower because the "start" field can be scrapped
substrings get cheaper because compact_pool has less numbers to work with
NotFound That can be easily tested just by changing a function, isn't it? 16:12
sorear it needs to be attempted and profiled. (once)
Coke I was under the impression bacek had already ripped out that optimization.
er, imagine I used the finger-quotes there.
16:13 tcurtis joined
whiteknight sorear: we can do a test, but I am extremely dubious that it would have a net improvement on memory use, especially for large parse jobs 16:14
Coke sorear, whiteknight: at one point, the substr optimization was keeping very very many copies of the input file. I /thought/ that had been fixed, though. 16:36
dalek rrot: r47339 | mikehh++ | branches/gc_massacre/MANIFEST:
re-generate MANIFEST
rrot: r47340 | mikehh++ | branches/gc_massacre (2 files):
add svn properties
Coke but any memory improvements ++. =-)
whiteknight Coke: well that certainly sounds like a bug. Any substrings should point into the original buffer and require no additional storage allocation 16:37
NotFound We are still getting used to immutable strings, many things we were used to are not longer true. 16:41
whiteknight Yes, there are some growing pains 16:43
but overall, I would say it was a very easy transition
NotFound Yeah, and helped a lot to clear some long-running mistakes. 16:44
dalek rrot: r47341 | NotFound++ | trunk/t/pmc/resizableintegerarray.t:
tests for RIA delete_keyed_int
 16:53
rrot: r47342 | mikehh++ | branches/gc_massacre/src/gc/list.h:
fix codetest failure - there should be at least one space between a C keyword and any subsequent open parenthesis
16:53 theory_ joined 17:01 cotto_work joined
Coke hurm. git status on master showed how far ahead of origin I was. the branch doesn't seem to provide that info. 17:05
whiteknight is the branch tracking the origin? 17:10
17:11 theory joined 17:26 jsut joined 17:53 dmalcolm joined
Coke *blank stare* 17:56
(how do I check that?) 17:57
mikehh make corevm/make coretest FAIL - 37 subtests fail, 208 subtests and 1 test not even run 18:06
t/compilers/imcc/syn/clash.t - Failed test: 13 in testr
all other tests PASS (pre/post-config, smoke (#34197), fulltest) at r47342 - Ubuntu 10.04 amd64 (g++)
t/op/annotate-old.t - TODO passed: 1 in testf
get a couple of TODO passes on i386 which don't on amd64 18:07
bubaflub Coke: you could try `git branch -a` 18:09
to see all branches
dalek kudo: a0b6d74 | jimmy++ | src/Perl6/Actions.pm:
fixed #75114: Can't augment class Int
 18:53
Coke bubaflub: that doesn't really show me anything. 18:54
I mean, I get a list of branches, with a * next to the active one.
but that's it. 18:56
bubaflub Coke: ah, i thought you wanted to see your branches
18:56 ruoso joined
bubaflub Coke: did you want to setup your local branch to track a remote branch? 18:57
Coke bubaflub: in the past, "git status" has shown me how many commits ahead of the origin I am. 18:58
it's not showing me this now. I'm assuming it might have something to do with the fact that I'm on a branch.
bubaflub Coke: it may be the way that the branch is set to track 18:59
can you nopaste the relevant section from your .git/config
should be something like 19:00
[branch "topic"]
and then a line below that that says merge =
Coke ENOSECTIONLIKETHAT 19:02
bubaflub yikes
Coke oh, .git/config, not ~/.gitconfig. =-)
bubaflub ah, yes
Coke there is no [branch "<branchname>"] there.
bubaflub what do you see in there? perhaps it's in a section [remote ...] 19:03
nopaste "coke" at 192.168.1.3 pasted "git config" (15 lines) at nopaste.snit.ch/20890 19:04
Coke the branch is 'revive'
19:05 gbacon joined
bubaflub Coke: i'm staring at it and not figuring out why it wouldn't give you the "you are ... commits ahead" kind of thing 19:07
atrodo Coke> Your current branch is "revive" and the branch that will tell you are N commits ahead is master? 19:08
Coke atrodo: yes. 19:24
not that I'm ahead on my local copy of master atm to double check.
atrodo Coke> Using what little I do about this black magic and what bubaflub was saying, the remote option of the master branch section in your git config makes the master branch track the origin, thus giving you the ahead N commit info 19:28
would be my guess
19:31 cotto_work joined 19:33 jsut_ joined, pjcj joined 19:46 whiteknight joined
NotFound mikehh: What TODOs? It passes just one for me. 19:47
Oh, you mean with testf... 19:49
mikehh NotFound - t/pmc/packfile.t - TODO passed: 34 in coretest, smoke, testb, testf and testr
NotFound: t/op/exit.t - TODO passed: 6 in testf
thats as well as t/op/annotate-old.t - TODO passed: 1 in testf 19:50
whiteknight misread that chromatic called David Foster Wallace a "Porno Hero" instead of a "Pomo Hero"
the internet has done bad things to my mind 19:51
NotFound The packfile one is passing since I've added lacking features in the packfile PMCs. Still don't know what is the problem in 64
19:51 theory joined
NotFound whiteknight: Internet is for porn! 19:51
whiteknight NotFound: well, I certainly haven't found another use for it
NotFound video.google.com/videoplay?docid=54...227974645# 19:52
cotto_work avoids clicking 19:53
NotFound cotto_work: Is just a funny video
cotto_work sfw?
purl sfw is safe for work or safe for wife or sun freeware but you knew that.
NotFound cotto_work: that depends of the humor sense of the coworkers and your volume level. 19:54
cotto_work I'll hold off then. If it's that WoW video, I'll have already seen it anyway.
NotFound cotto_work: yes, that video. 19:55
purl that video is the major reason why anyone still has even the faintest idea who Glenn Danzig is.
cotto_work I think it's nice to have purl back. I'm not entirely sure though.
NotFound don't know who Glenn Danzig is 19:56
cotto_work maybe you should see that video
NotFound purl: Glenn Danzig?
purl notfound: bugger all, i dunno
NotFound purl: Internet? 19:59
purl Internet is for porn or Serious Business.
20:03 Psyche^ joined
bacek Good morning, humans 20:24
sorear, whiteknight, I've got feeling that removing "shared buffers" will actually speed-up parrot. 20:26
And reduce memory usage because compact_pool can be precise 20:27
dalek p-rx: a68924f | pmichaud++ | src/Regex/P6Regex/ (2 files):
Update ** quantifier a bit, recognize trailing spaces as request to

specifies, but it's a good first cut.)		 20:29
p-rx: 9e955a4 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get FileHandle.tell.
p-rx: 38fc6e9 | pmichaud++ | src/Regex/P6Regex/Actions.pm:
Add :sigspace handling to range quantifiers (e.g., <x> ** 0..3)
pmichaud bacek: still trying to get to review multi branch :) 20:31
bacek pmichaud, :)
darbelo bacek: I did some thinking on 'unshared buffers' and it shouldn't be too hard to do.
bacek darbelo, just ripping a lot of code. 20:32
whiteknight bacek: I would like to see an experiment without shared buffers, but I'm not hopeful 20:33
darbelo The first step would have to be to disable the 'cow' parts of strings, then a global s/strstart/_bufstart/ replacement, and poof! 20:34
bacek whiteknight, do you have any preferred test for it? 20:35
whiteknight bacek: I don't know. Standard benchmarks and NQP/Rakudo builds. NQP parsing seems like it would be the ultimate test of string handling
20:35 theory joined
darbelo whiteknight: If anything benefits from precise compaction, it'll be that. 20:36
whiteknight darbelo: maybe. I'm open to data
darbelo Also, it would make it easier to do some of the stuff I've failed to do to strings in the past. 20:38
;)
bacek darbelo, just create unshared_buffer branch then :) 20:39
It will take couple of hours to implement 20:40
20:40 bluescreen joined
darbelo And, COW complicates NFG. 20:40
dalek p-rx: 5fb2d58 | pmichaud++ | (3 files):
Add \\e in quoted strings, refactor 46-charspec.t .
 20:41
whiteknight has to go to the store. be back later
bacek slacker! 20:44
purl slacker is like lazy bum
20:47 joeri joined
mikehh bacek: got a couple of problems with gc_massacre 20:49
bacek mikehh, only couple??? :) 20:51
mikehh g++ don't like src/gc/pool_allocator.c - assigning (size_t) - 1 to a pointer 20:52
bacek change it to something like MAX_INT 20:53
purl bacek: that doesn't look right
cotto_work toxic botsnack
purl thanks cotto_work :)
bacek (I'm not sure that it's in C89)
mikehh bacek: and t/op/string_mem.t hangs on test 6 20:54
bacek mikehh, because test is stupid...
And we didn't implement GC.get_info yet :) 20:55
particle INT_MAX is C89, limits.h 20:56
Coke purl, i hope you choke on that botsnack.
purl thanks Coke :)
mikehh bacek: yeah that test is a hangover for COW and stuff 20:57
from 20:58
bacek: in make test the opsc tests seem to go out-to-lunch as well 21:06
bacek mikehh, let me check 21:07
21:09 gbacon joined
cotto_work code.google.com/events/io/2010/sess...ik-vm.html (video is up now) 21:10
bacek mikehh, yeah... String part of GC isn't implemented yet. 21:16
21:19 lucian joined
cotto_work opsc tests are really slow in gc_massacre but they appear to be running ok so far 21:19
dalek rrot: r47343 | gerd++ | trunk/tools/docs/filename_and_chapter.pl:
make necessary changes to integrate "ch04_variables.pod" and to improve the table of contents
bacek untill OOM killer will kill it
cotto_work true. It does seem to have an unusual love for my delicious memory. 21:20
mikehh stopped t/compilers/opsc/02-parse-all-ops.t after 10 minutes and after it grabbed over 2GB at 10/20 21:21
cotto_work I'd prefer that it eat my memory rather than my brains. 21:22
neither would be ideal
mikehh cotto_work: refuse to comment on that :-} 21:23
cotto_work for the time being, the only one I can upgrade is my memory
darbelo Have it eat cotto's brain or my memory? Tough choice there.
21:24 hudnix joined 21:25 theory joined
dukeleto 'ello 21:27
atrodo Interesting. Kylix messes with the FPU which causes parrot to die on divide by zeros or invalid floating point operations 21:28
darbelo ...why does it mess with the FPU? 21:30
atrodo :shurg: No idea. Probably a vestage from it's Windows roots 21:31
Thankfully, now that I know what it does (masks some FP excetptions), it does give an easy way to undo them
darbelo And, mostly out of curiosity, does mess it up enough that we should be dying?
:)
atrodo Probably. It turns divide by zero's into a SIGFPE 21:32
darbelo Ouch.
21:34 davidfetter joined
GeJ Good morning everyone. 21:36
everyone Good morning GeJ. 21:37
dukeleto davidfetter: howdy
davidfetter what's new & good, dukeleto ?
dukeleto davidfetter: hanging out at OSBridge, hacking on PL/Parrot 21:38
davidfetter got new compadres for that?
dukeleto davidfetter: telling people about it and drumming up interest 21:39
davidfetter :)
dukeleto davidfetter: trying to get PL/Perl6 to work, hitting some brick walls
davidfetter do you have some idea where those are? 21:40
purl those are fairly generic
dukeleto davidfetter: loading the perl6 PBC errors out now 21:41
davidfetter hrm. is there some parrot sha1 (or whatever svn uses) that doesn't do this? 21:42
pmichaud nqp now supports primitive multisubs. bacek++ 21:44
dukeleto davidfetter: what exactly do you mean? i am using Parrot trunk and rakudo master
davidfetter did any recent parrot commits break this? 21:45
rakudo ones?
dukeleto davidfetter: i don't think so. "parrot perl6.pbc" works, but I am not doing something correctly, most probably 21:46
21:47 bluescreen joined
darbelo dukeleto: rakudo can be fairly libreal with it's uses of parrot guts, sometimes. 21:47
dukeleto darbelo: yes, i imagine rakudo is doing special things 21:48
darbelo It woudln't surprise me at all that all three of you, parrot and rakudo were doing something wrong ;)
dukeleto darbelo: indeed :)
dalek p-rx: eba2f2b | pmichaud++ | (3 files):
Merge branch 'multis'
 21:49
pmichaud bacek: multis branch merged and updated in parrot. enjoy. :-)
p-rx: 7006d42 | pmichaud++ | t/nqp/49-multis.t:
Rename multi tests.
p-rx: 9612a72 | pmichaud++ | src/NQP/ (2 files):
[nqp]: Eliminate $*METHODTYPE from grammar and actions.
p-rx: 9d44980 | pmichaud++ | src/stage0/ (4 files):
Update bootstrap.
dukeleto pmichaud: i am getting this when attempting to load perl6.pbc from Parrot's C API : gist.github.com/423516 any ideas? 21:50
pmichaud dukeleto: no immediate ideas, but I do wonder if rakudo's dynops and dynpmcs get correctly loaded.
afk for a while 21:51
dukeleto pmichaud: $P0 = get_root_global ['parrot'], 'P6metaclass' <-- this seems to return NULL (line 44 of src/Perl6/Compiler.pir)
jnthn perl6;Perl6;Compiler;main
main?
purl hmmm... main is the package of the test script
jnthn wonders if we should be in :main
(on a library load)
pmichaud yeah, seems like :main shouldn't be invoked there either. 21:52
21:52 cotto_work joined
jnthn dukeleto: That almost certainly means something that needs to be loaded isn't. 21:52
pmichaud if P6metaclass is null, that means that P6object.pbc isn't being loaded
21:52 tcurtis joined, patspam joined
pmichaud which likely means that the :load :init subs from the perl6.pbc file aren't being invoked 21:52
jnthn Most probably
pmichaud or, if they are, that the load_bytecode that they do (in order to load the other libraries) aren't being honored somehow.
jnthn Note taht we don't laod P6object explicitly, but other things we do load will in turn load it. 21:53
pmichaud correct
P6object gets loaded by PCT, which is loaded by HLL.pbc
(or something like that)
there's a reasonably long chain of library loads that happen early on in any pct-based environment.
dukeleto jnthn, pmichaud: yeah, i loa P6object manually, but some other dependency must be missing
dalek rrot: r47344 | pmichaud++ | trunk/ext/nqp-rx/src/stage0 (4 files):
[nqp-rx]: Update nqp-rx with multisub support (bacek++), other fixes.
 21:54
pmichaud or it could be loading things into the wrong place.
afk for a while
NotFound dukeleto: if the problem is related to dynops loading, anything can fail in the most bizarre ways. 21:55
dukeleto NotFound: yes, lots of dynops are involved. 21:56
darbelo I would investigate pbc load order first. Rule out the obvious suspects first.
bacek pmichaud, hooray! 21:57
next step - traits parsing :)
darbelo See if you can load rakudo from straight PIR. Then try again from inside pl/parrot 21:58
NotFound darbelo: a quick workaround can be to load exactly the same dynops as rakudo and in the same order... good luck finding that order ;)
dalek nxed: r488 | julian.notfound++ | trunk/winxedst1.winxed:
more refactor of simple argument list
dukeleto darbelo: i have a skeleton C file which attempts to load perl6.pbc and fails 21:59
22:01 silug joined 22:05 snarkyboojum joined
dukeleto seems like perl6_group is not getting .loadlib'ed correctly, probably because it can't be found 22:07
i see the light! 22:08
whiteknight dont walk into it
dukeleto parrot perl6.pbc only works from the directory that perl6.pbc is in 22:10
darbelo Is that an installed perl6?
dukeleto if you try parrot /some/dir/perl6.pbc, you get the error about "Null PMC access in find_method('new_class')"
oh noes! 22:11
it is not
whiteknight: trying an installed perl6 now
darbelo An non-installed rakudo can't function out of the build dir IIRC.
It used to be a note in some SHOUTING FILE or another. 22:12
jnthn darbelo: Correct.
It probably is in one, but of course nobody reads them...unless you call them IGNOREME :-)
dukeleto using an installed rakudo is the way to go 22:14
darbelo Until this step is performed, the "perl6" executable 22:15
created by C<make> above can only be reliably run from the root of
Rakudo's build directory.
That's on the README ;)
'this step' == make install 22:16
dukeleto darbelo: that is what I get for not reading the README :) 22:18
i get: Class '[ 'ClassToBe' ]' not found now 22:19
darbelo I wonder if symlinking it to README.NOT would make more people read it...
dukeleto: Failing differently can be a form of progess ;) 22:20
dukeleto darbelo: indeed. but i just borked postgres so hard it can't shut itself down...
darbelo said 'progress' not 'perfection' ;) 22:21
dukeleto now i get this: gist.github.com/424624 when loading perl6.pbc from C 22:42
22:44 theory joined 22:49 kid51 joined
whiteknight Anybody have objections if I merge in the ns_func_cleanup branch? 22:54
I was hoping for feedback, but no
cotto_work Does it need a deprecation cycle?
+1 if not
kid51 What does it do?
Has it been described at all on parrot-dev?
whiteknight kid51: yeah, I sent out an email about it a few days ago 22:55
warnocked
purl warnocked is en.wikipedia.org/wiki/Warnocked
kid51 reads parrot-dev 22:56
cotto_work Yay. trac.parrot.org is unbroken
sorear What was wrong?
cotto_work coke++ for complaining about it through the proper channel
kid51 sorear: My impression was that it wasn't loading its CSS
cotto_work It was denying access to css and js for users who were logged in. 22:57
kid51 That was approx 22 hours ago. I haven't backscrolled the channel since then.
whiteknight lists.parrot.org/pipermail/parrot-d...04335.html
darbelo whiteknight: Cleanup is always good. Non-breaking cleanups are best.
whiteknight it's a breaking cleanup, but the function renames have been deprecated for a long damn time
cotto_work fire at will, then 22:58
whiteknight working... 22:59
purl working is a good approximation.
cotto_work just don't make Rakudo cry
or partcl
kid51 reads whiteknight's post ...
src/global.c -> src/namespace.h
a .c file became a header file?
whiteknight I make no promises
kid51, no. Might be a typo
Coke plays with his new ubuntu netbook 23:00
cotto_work I don't see any such change 23:01
just some x.c -> y.c and x.h -> y.h changes
whiteknight if Rakudo uses any of these functions, it's going to need a patch 23:05
whiteknight is building now 23:08
kid51 whiteknight: you are belatedly dewarnocked; check mail 23:09
23:11 dngor joined
whiteknight kid51++ 23:11
kid51 whiteknight: After all, if *you* can't figure out WTF those tickets are talking about, no one else is likely to either. 23:12
make coretest still doing badly: smolder.plusthree.com/app/projects/...ails/34202
whiteknight kid51: I was hoping some of our longest-active members would have some intrinsic memories about them 23:13
kid51 Well, you could always try svn blame on some older versions of those files.
Now, this is somewhat of a philosophical position on my part, which we've touched on before. 23:14
While I respect the work of our predecessors in the project, I don't think we have to treat their brainstorms re TODOs as mandates for action. 23:15
In particular, unless the TODO is consistent with a design decision that we continue to hold, we shouldn't be bound for it.
s/for/by/
As far as I am concerned, such RTs are technical debt. 23:16
23:17 workbench joined
kid51 So if we don't have a PDD which supports what's in the TODO comment, I don't think we should retain the TODO or the corresponding ticket. 23:17
But, as we well know, other committers have different opinions.
23:18 darbelo_ joined
kid51 And there have been times when I have gone on a ticket-closing rampage only to have my knuckles rapped thereafter. 23:18
That being said, we currently have 690 open tickets (Report 10) 23:19
That's at the high end of what we have historically been willing to tolerate.
700 open tickets is a red flag
23:19 cotto_work joined
kid51 At the time of conversion from rT to TT, I know we got down under 600. 23:19
pmichaud whiteknight: fwiw, Rakudo uses at least some of the functions you're renaming there.
whiteknight pmichad: yes, I just tried building. I'll submit a patch or something 23:20
pmichaud*
how do you prefer I go about it, send you a patch? fork rakudo on github and make changes there for you to pull?
pmichaud we generally prefer patches still 23:21
or, you could create a branch in the rakudo repository
but anything will work, really -- we now have enough git-fu to be able to figure out how to deal with merging :)
just know that github "pull requests" still tend to get ignored :)
dalek TT #1219 closed by whiteknight++: Parrot's default namespaces should be fully typed 23:22
TT #1219: trac.parrot.org/parrot/ticket/1219
TT #1220 closed by whiteknight++: Stop depending upon typed namespaces in internal_ns_keyed()
TT #1220: trac.parrot.org/parrot/ticket/1220
TT #1221 closed by whiteknight++: Match HLL of enclosing namespace in internal_ns_keyed()?
TT #1221: trac.parrot.org/parrot/ticket/1221
TT #1222 closed by whiteknight++: Use the untyped interface in Parrot_find_global_n()
TT #1222: trac.parrot.org/parrot/ticket/1222
TT #1224 closed by whiteknight++: Fix temporary hack for cache invalidation; should be a namespace function; ...
TT #1224: trac.parrot.org/parrot/ticket/1224
TT #1225 closed by whiteknight++: Method cache invalidation should be a namespace function
TT #1225: trac.parrot.org/parrot/ticket/1225
cotto_work It's a tracpocalypse!
Coke some of those old NS tickets were from chip 23:25
whiteknight: I'll have partcl master working shortly so you can test against that too.
sorear you mean partcl-not-nqp? 23:28
bacek_at_work whiteknight, cheap karma for closing trac.parrot.org/parrot/ticket/655 23:30
pmichaud Coke: have you had to give up on partcl-nqp? 23:31
Coke pmichaud: no. But partcl was so broken it needed some lvoe 23:33
pmichaud Coke: okay, just checking. 23:34
Coke i'm not trying to add any new stuff to it, but Keeping it passing make test should be possible.
bacek_at_work I've got an idea for some internal cleanups. 23:35
Let's remove "buffers" (and all related stuff). PMC and STRING are enough.
pmichaud bacek_at_work: your multis brance was awesome. great work.
whiteknight pmichaud: okay, I'll get a patch together and send that to you before I merge. Coke, once you get partcl working I'll try to do the same 23:36
pmichaud *branch
bacek_at_work Currently it's used in freeze/thaw only.
pmichaud, I almost blindly copied stuff from rakudo :)
pmichaud whiteknight: excellent. You may have better responsiveness if you send it to moritz, jnthn, etc. in addition to me. My schedule is sometimes not my own. 23:37
s/sometimes/often/
bacek_at_work And create Buffer PMC with .push_byte, .encode, .decode, etc methods.
pmichaud bacek_at_work: does what you're suggesting likely have any relation to the work that masak++ is trying to do on a Buf type?
bacek_at_work pmichaud, yes
pmichaud bacek_at_work: excellent.
+1 from me, then :)
bacek_at_work It will solve few problems at once. 23:38
1) Currently "buffers" are not accessible from pir
2) There is a lot of logic in GC to handle them.
pmichaud it sounds like a nice win to me
bacek_at_work 3) "buffers" are mutable by nature. Strings are not
pmichaud gotta run -- bbl
dalek TT #1081 closed by bacek++: segfault in Parrot_HashIteratorKey_get_string
TT #1081: trac.parrot.org/parrot/ticket/1081
cotto_work There are quite a few design questions for Lorito. Would it be overkill to ask for volunteers to take on the various primary issues mentioned in LoritoRoadmap and have them write up LDDs on the wiki, similar to the existing PDDs? 23:43
trac.parrot.org/parrot/ticket/655 is closed 23:46
dalek rrot: r47345 | tcurtis++ | branches/gsoc_past_optimization (2 files):
Added PAST::Pattern::Op attribute exact matching.
 23:49
rrot: r47346 | tcurtis++ | branches/gsoc_past_optimization (2 files):
PAST::Pattern::Val tests for attributes matching exactly pass.
jnthn bacek_at_work: See also something I started hacking up to help masak++ last night - github.com/rakudo/rakudo/commit/39b...ceefe99e0. Idea is it just gives a byte view of a string and then when you modify it, it'll make a copy in a byte array to work with instead.
bacek_at_work: But for the "look at the bytes" only case, it's more efficient than copying right off.
bacek_at_work: Didn't get very far with it yet though, and ended up with ETOOMUCHDAYJOB today. 23:50
bacek_at_work jnthn, yeah. I'm writing proposal to maillist now. Actually rakudo-specific byteview will be unnecessary if it will be accepted :) 23:51
whiteknight bacek_at_work: GC doesn't trace C stack? I was positive it did
the code is all there, in any case
bacek_at_work whiteknight, it do not.
whiteknight I'm not sure I believe that. I know it used to at some point
jnthn bacek_at_work: Sure - feel free to use the Rakudo one as a starting point if the proposal is accepted, anyways. 23:52
bacek_at_work Code is there but we never call Parrot_gc_trace_root(GC_FULL)
whiteknight Some point recently
jnthn We...don't trace the C stack? :-S
sorear if not the C stack, what *do* we use as roots?
opbots trust jnthn
slavorgn Ok
slavorg Ok
bacek_at_work sorear, "interp" 23:53
dalek tracwiki: v15 | cotto++ | LoritoRoadmap 23:54
tracwiki: put primary design questions in the approximate order they'll need to be answered
tracwiki: trac.parrot.org/parrot/wiki/LoritoR...ction=diff
sorear Actually, this is great. 23:55
We have a _precise GC_
jnthn I thought we also had code that relied on the C stack being traced, but maybe I'm wrong.
dalek TT #655 closed by cotto++: Kill non-working GC cores
TT #655: trac.parrot.org/parrot/ticket/655
whiteknight jnthn: I'm with you. I think bacek must be missing something 23:56
Last time I really scrutinized the code, we were tracing it 23:57
bacek_at_work whiteknight, do you have valgrind? 23:58
or gdb? 23:59
purl it has been said that gdb is the command line debugger from the gnu project (common on unix platforms)
jnthn whiteknight: I've done little Parrot core hacking for a while, it's entirely possible I'm rusty on the latest. :-)
bacek_at_work just run "hello.pir" and set breakpoint into trace_mem_block.
jnthn whiteknight: I just worry a little because I know full well I've until now written code and had in the back of my mind, "the stack is traced".

Powered by Cro and the Raku® Programming Language.

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

Thank you!