Camelia, the Perl 6 bug

IRC log for #parrot, 2010-06-03

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 cotto_work wacky: You don't have permission to access /parrot/chrome/common/css/wiki.css
00:01 whiteknight nice
00:01 ash_ that loads for me... hmmm
00:01 cotto_work I guess we have to keep our css secret.
00:01 ash_ i can even curl it
00:02 whiteknight protect it from ze germans
00:02 cotto_work http://trac.parrot.org//parro​t/chrome/common/js/search.js <- how does that look?
00:02 whiteknight forbidden
00:02 cotto_work js or forbidden
00:03 cotto_work ash_: ^?
00:03 ash_ works if you take out the extra /
00:03 ash_ with // it is forbidden
00:04 ash_ (for me)
00:04 kid51 forbidden for me with either one slash or two
00:04 ash_ i might be logged into trak? let me check
00:05 ash_ no, not logged in... hmm
00:06 ash_ works in FF, Safari and Chrome (on OS X), if i only have 1 /, with the // it always gives me forbidden
00:07 cotto_work seems to deny when I'm logged in, otherwise not
00:10 ash_ thats backwards...
00:10 ash_ you'd think when your not logged in you'd get access denied
00:10 cotto_work no, just broken
00:10 cotto_work It's denying access to js and css files.
00:12 ash_ when your logged in?
00:12 cotto_work when my^H^HI'm logged in
00:27 ash_ joined #parrot
00:32 mikehh joined #parrot
00:33 dalek plparrot: d02c64e | dukeleto++ | plparrot (2 files):
00:33 dalek plparrot: Attempt to fiddle with open() mocking
00:33 dalek plparrot: review: http://github.com/leto/plparrot/commit/d​02c64ea62501dfeeb68ce6a24a6ff00e47a5039
00:33 dalek plparrot: 3d41ad7 | dukeleto++ | t/sql/test.sql:
00:33 dalek plparrot: Add a test for FileHandle.open in PL/PIRU
00:33 dalek plparrot: review: http://github.com/leto/plparrot/commit/3​d41ad773dfe277d3e67e5c961083d679cfda6f7
00:45 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:46 cotto ohai
01:10 dalek parrot: r47317 | tcurtis++ | branches/gsoc_past_optimization (2 files):
01:10 dalek parrot: All PAST::Node and PCT::Node "attributes" exact match tests pass.
01:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47317/
01:18 plobsing joined #parrot
01:32 ash_ ping plobsing
01:33 plobsing ash_: pong
01:33 ash_ hi
01:33 plobsing so how goes it?
01:34 ash_ the robot competition is over, so now I am working on GSoC full time
01:34 ash_ 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
01:35 ash_ 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:36 plobsing can I convince you to either stop hand-coding your parser or reduce the structure your signatures allow?
01:36 plobsing matching braces require at least a pushdown automaton IIRC
01:36 ash_ sure?
01:36 purl sure are a lot of joels in perl
01:37 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:38 ash_ yeah, bison could do that
01:39 plobsing pick your favorite tool and go for it
01:39 plobsing Bison is a good choice
01:39 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...
01:40 plobsing well if it is working, stay the course. But I'd watch out for the matching braces you gave in examples.
01:41 cotto any reinvented wheels should at least be round
01:42 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 ash_ those are the two complicated cases
01:43 ash_ { } 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 ash_ 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
01:43 dalek parrot: r47318 | jkeenan++ | trunk (135 files):
01:43 dalek parrot: Merge tt1452_configure_debug branch into trunk.  Implements Parrot::Configure::debug().
01:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47318/
01:43 dalek parrot: r47319 | jkeenan++ | branches/tt1452_configure_debug:
01:43 dalek parrot: Branch has been merged into trunk and is no longer needed at HEAD.
01:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47319/
01:44 plobsing purl: Branch has been merged into trunk and?
01:44 purl plobsing: i don't know
01:44 plobsing aw
01:44 aloha joined #parrot
01:45 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
01:46 plobsing ah. that *is* black magic
01:46 ash_ are the gen things pretty one off ish? or is it generic?
01:47 plobsing ash_: we have a decent general-case framework, but it is a little eccentric
01:47 plobsing are you a) trying to conditionally compile files? b) trying to conditionally generate cpp #defines? c) trying to insert arbitrary text into a template?
01:49 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 ash_ i think that would be a good way of doing it
01:49 ash_ if thats not how things are normally done though i am fine with a different method
01:50 plobsing that seems like the simplest thing to do. which is the best IMHO.
01:51 ash_ so they probably wouldn't have to have any real parsing of their content, just a move or copy would do
01:52 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:53 plobsing or you could just use the ExtUtils module that it winds up using half the time
01:55 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 ash_ are there any issues you forsee with the llvm?
01:56 plobsing LLVM provides excellent targets for probing if I am not mistaken, so none from a config perspective.
01:57 plobsing 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)
01:58 ash_ detect_llvm branch i mean
01:59 plobsing the author may not have been aware of the tool. or perhaps it isn't always installed or something.
01:59 plobsing my money's on the first though
02:00 ash_ i'll check on some other systems to see if its installed by default, but i think it is
02:01 ash_ 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:02 plobsing ash_: sure.
02:03 plobsing 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?
02:03 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
02:03 tcurtis Fun. I have a segfault that disappears when I insert some extra says to see where exactly it happens.
02:04 pmichaud tcurtis: Welcome to my hell.
02:04 plobsing ash_: yes, that's the meat of the project.
02:04 sorear tcurtis: --trace=1
02:04 pmichaud oh, that's another part of my hell.  Turning on tracing causes the segfault to disappear.  :-/
02:05 pmichaud 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!
02:05 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
02:05 sorear also, you're not a parrot expert until you can generate a backtrace using gdb from a core dump
02:05 ash_ the only complicated data structure i might have to implement is a union type pmc
02:05 sorear protip: pbc_disassemble to map PC numbers into lines
02:05 ash_ s/might/will
02:07 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:09 ash_ i also need to figure out if 64 bit ints, since $I0 registers are all only 32 bits
02:10 petdance joined #parrot
02:10 plobsing some parrot operations use 2 INTVALs to handle overflow. For example the tell op
02:11 plobsing or you could use a PMC
02:13 ash_ I noticed http://github.com/ashgti/parrot/blob/gsoc​_nci/config/gen/config_h/config_h.in#L118 which seems like there should be some sort of portable way of doing 64 bit ints
02:14 preflex joined #parrot
02:17 sorear you mean like int64_t?
02:17 sorear HAHA THAT'S C99
02:18 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:19 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.
02:19 ash_ an int register could be at least 32 bits, maybe more if your system supports it
02:19 plobsing I thought that was the unwritten standard now.
02:20 plobsing 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
02:20 plobsing really? I thought parrot would break in a number of places if you couldn't fit a pointer in an intval.
02:21 bacek_at_work pmichaud, http://github.com/perl6/nqp-rx/tree/multis
02:22 abqar joined #parrot
02:23 ash_ well, unless my long is 64 bits... is long 64 bits on OS X? hmm, i'll check
02:23 ash_ i thought it had to be long long before it was 64 though, one sec
02:25 tcurtis I think long is 64 bit on 64 bit OS X. Not on i386, though.
02:26 ash_ yeah, long is 64 bits with -m64 and 32 bits on -m32
02:26 ash_ so it is a 64 bit register then on os x, neat, i am completely wrong
02:29 plobsing neat is not the first word I'd use to describe the arbitrary sizing of C's integer types
02:29 TiMBuS joined #parrot
02:31 ash_ lol, true
02:38 ash_ 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:39 plobsing this is true. but we like to give the illusion that we can work with smaller intval types :p
02:49 dalek parrot: r47320 | tcurtis++ | branches/gsoc_past_optimization (2 files):
02:49 dalek parrot: PAST::Pattern.blocktype matching works.
02:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47320/
03:05 sorear ash_: that might work, except for the oh so minor detail that we can't use stdint.h
03:05 sorear stdint.h isn't specified by C89
03:06 ash_ ah, dang, i didn't realize that was part of c99 too
03:09 cotto It's an 11 year old standard.  I'm sure all the most commonly used compilers will implement it.
03:09 theory joined #parrot
03:12 ash_ well, Microsoft's compiler only supports bits of C99 not all of it
03:12 ash_ which is the trouble
03:13 cotto forgot the sarcasm tags
03:13 cotto though they're usually implicit in discussions about standards and their implementation
03:14 ash_ going to bed, be back later
03:18 Coke trac looks better again. I think there might have been a site update earlier today that was supposed to be unnoticable. :|
03:20 cotto yup. 0.11.6 to 0.11.7
03:21 cotto still looks broken though
03:21 Coke cotto: you're caching the failure.
03:21 Coke ?
03:21 Coke BOOYAH, no you're not.
03:22 Coke I'll open a ticket.
03:23 cotto silly webs
03:23 aloha joined #parrot
03:23 cotto so useful yet so stupid
03:23 cotto aloha, aloha
03:24 cotto aloha, status
03:26 parthm joined #parrot
03:26 Coke ticket opened. :P
03:26 cotto coke++
03:39 cotto also, test site ticket pinged
03:44 janus joined #parrot
04:20 kurahaupo joined #parrot
05:30 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 cotto http://trac.parrot.org/parrot/wiki/LoritoRoadmap
05:30 bacek joined #parrot
05:30 cotto ohai
05:35 szabgab joined #parrot
05:38 dalek tracwiki: v14 | cotto++ | LoritoRoadmap
05:38 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Lor​itoRoadmap?version=14&amp;action=diff
05:42 kurahaupo joined #parrot
06:06 uniejo joined #parrot
06:07 frodwith joined #parrot
06:07 * Coke grumbles at cmp_str being removed.
06:09 Coke cmp_str_iss, that is. (and cmp_num_iii)
06:11 dukeleto i am attempting to load perl6.pbc in PL/Parrot and getting this message: http://gist.github.com/423516
06:11 dukeleto if anybody can throw me a bone, i would greatly appreciate it
06:12 plobsing Coke: it didn't do anything different from cmp
06:13 parthm left #parrot
06:18 eternaleye joined #parrot
06:24 Coke plobsing: danke.
06:24 dalek parrot: r47321 | tcurtis++ | branches/gsoc_past_optimization (2 files):
06:24 dalek parrot: Block attributes other than symtable are now tested for exact matches.
06:24 plobsing I removed it because "$I0 = cmp_str $P0, $I1" did the *exact* wrong thing
06:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47321/
06:24 dalek parrot: r47322 | plobsing++ | trunk/t/pmc/freeze.t:
06:24 dalek parrot: fix a coretest
06:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47322/
06:30 Coke ah, crap. I tried to leapfrog from immutable strings to the end, and partcl is unhappy.
06:30 Coke will have to go back and step through again. :P
06:33 Coke dukeleto: random guess :dynops.
06:42 aukjan joined #parrot
06:46 viklund joined #parrot
06:50 frodwith joined #parrot
06:57 dalek parrot: r47323 | plobsing++ | trunk (4 files):
06:57 dalek parrot: 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.
06:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47323/
06:57 dalek parrot: r47324 | plobsing++ | trunk/docs/pdds (2 files):
06:57 dalek parrot: mark some POD-PIR as invalid (core doesn't contain 'perl5_group' or 'tcl_group' libraries)
06:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47324/
07:00 Coke arrrrgh.
07:01 Coke 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 Coke yes?
07:02 Coke (that is, replace__ssiis is not a dropin replacement for substr__ssiis)
07:03 Coke 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.
07:04 bacek_at_work Coke, substr+replace combo
07:06 Coke so I have to do the same work /twice/?
07:06 bacek_at_work no. It's different work :)
07:06 Coke too zzz now. will grumble at you later.
07:17 tcurtis joined #parrot
07:22 tcurtis msg ash_ Have you seen http://blogs.perl.org/users/doubi/20​10/05/introduction-and-api-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 #parrot
07:41 clinton joined #parrot
08:04 tcurtis joined #parrot
08:05 Essobi joined #parrot
08:13 JimmyZ joined #parrot
08:34 dalek rakudo: a1140cc | moritz++ | build/PARROT_REVISION:
08:34 dalek rakudo: bump PARROT_REVISION to get latest nqp-rx fixes
08:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​1140cc736a9028574eb5d976265db69efa56bb8
08:37 eternaleye joined #parrot
08:53 snarkyboojum joined #parrot
08:54 dalek parrot: r47325 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
08:54 dalek parrot: Simplify TMS.is_owned
08:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47325/
08:54 dalek parrot: r47326 | fperrad++ | trunk/examples/languages/squaak (2 files):
08:54 dalek parrot: [squaak] refactor without dynops IO
08:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47326/
08:54 dalek parrot: r47327 | fperrad++ | trunk/examples/pir/befunge (3 files):
08:54 dalek parrot: [befunge] remove opcodes getstdin/getstdout
08:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47327/
09:14 dalek cardinal: b22731f | fperrad++ | src/builtins/ (2 files):
09:14 dalek cardinal: remove opcodes getstdin/getsdout/getstderr
09:14 dalek cardinal: review: http://github.com/cardinal/cardinal/commit​/b22731fba94f818a88622c4d1c666c695c1c99fe
09:34 ruoso joined #parrot
09:46 purl joined #parrot
09:53 dalek unlambda: ca471cc | fperrad++ | unl.pir:
09:53 dalek unlambda: remove some IO opcodes
09:53 dalek unlambda: review: http://github.com/bschmalhofer/unlambda/comm​it/ca471cc7cad481a48a01ee82ca9aa23d8df902c9
09:53 dalek unlambda: 904f2d2 | fperrad++ | setup.pir:
09:53 dalek unlambda: chmod +x setup.pir
09:53 dalek unlambda: convert CRLF to LF
09:53 purl I don't know how to convert CRLF to LF.
09:53 dalek unlambda: review: http://github.com/bschmalhofer/unlambda/comm​it/904f2d21ba2a8cc10f35089704a0593c7dc93953
10:01 dalek lazy-k: d09d73d | fperrad++ | setup.pir:
10:01 dalek lazy-k: chmod +x setup.pir
10:01 dalek lazy-k: convert CRLF to LF
10:01 purl I don't know how to convert CRLF to LF.
10:01 dalek lazy-k: review: http://github.com/bschmalhofer/lazy-k/commi​t/d09d73d48f4de2603ab8e58f796178e623727e76
10:01 dalek lazy-k: f09651e | fperrad++ | lazy.pir:
10:01 dalek lazy-k: remove some IO opcodes
10:01 dalek lazy-k: review: http://github.com/bschmalhofer/lazy-k/commi​t/f09651ef7a194009ab5b9979c628d82c74dc6c86
10:03 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
10:04 bacek Yay. She've got her memory back
10:20 dalek lua: 3defd23 | fperrad++ | lua/lib/lua (3 files):
10:20 dalek lua: remove opcodes getstdin/getstdout/getstderr
10:20 dalek lua: review: http://github.com/fperrad/lua/commit/3d​efd23d436791af66294a3c0611555235103649
10:20 dalek lua: 3cb3b32 | fperrad++ | t/pmc/function_hll.t:
10:20 dalek lua: fix test
10:21 dalek lua: review: http://github.com/fperrad/lua/commit/3c​b3b322ce18a948d3cf2e4f8df1941b587f25f6
10:25 zibri joined #parrot
10:25 mikehh_ joined #parrot
10:28 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 #parrot
10:33 dalek parrot: r47328 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
10:33 dalek parrot: Pacify compiler.
10:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47328/
10:33 dalek parrot: r47329 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
10:33 dalek parrot: Speed-up testing on TMS.is_pmc by checking "pmc" flags.
10:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47329/
10:33 dalek parrot: r47330 | bacek++ | branches/gc_massacre/src/gc (2 files):
10:33 dalek parrot: Speed up PoolAllocator.is_owned by caching lo/hi bounds of arenas.
10:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47330/
10:33 dalek parrot: r47331 | bacek++ | branches/gc_massacre/src/gc (2 files):
10:33 dalek parrot: Poor-man templates: implement macros for manipulating lists
10:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47331/
10:33 dalek parrot: r47332 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
10:33 dalek parrot: Use list macros instead of functions
10:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47332/
10:33 dalek parrot: r47333 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
10:33 dalek parrot: Skip marking already live or dead objects.
10:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47333/
10:33 dalek parrot: r47334 | bacek++ | branches/gc_massacre/src/gc/gc_tms.c:
10:33 dalek parrot: Reimplement TMS.free_pmc_header.
10:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47334/
10:38 lucian_ joined #parrot
10:50 dalek parrot: r47335 | gerd++ | trunk/tools/docs/filename_and_chapter.pl:
10:50 dalek parrot: Add the PIR documentation to be generated as PDF
10:50 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47335/
11:09 bacek msg chromatic List based TMS doesn't work... It's freaking slow.
11:09 purl Message for chromatic stored.
11:47 JimmyZ joined #parrot
11:49 whiteknight joined #parrot
11:58 dalek rakudo: 3a6b43f | moritz++ |  (2 files):
11:58 dalek rakudo: First shot at pure-Perl Cool.trans
11:58 dalek rakudo: It handles simple ranges and only literals as patterns.
11:58 dalek rakudo: The range unpacking is greatly inspired by (David Green)++'s p6c mail.
11:58 dalek rakudo: Also pyramidine++ for his initial implementation.
11:58 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​a6b43feb3f9f948ac989f49a3cddc214cfd1788
12:02 whiteknight good morning, #parrot
12:03 bacek aloha, whiteknight
12:03 whiteknight hello bacek
12:03 whiteknight so we're not eliminating constant PMCs in this iteration?
12:03 whiteknight I do think that's something we should do soon, if not right now
12:05 whiteknight We should be able to either register all PMCs, or anchor them somewhere in the object graph.
12:06 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?
12:08 bacek It's lower priority now. I've got workarounds in both TMS and MS2 for zombi^W constant pmcs.
12:08 bacek I think proper encapsulation of PMC Attributes allocator will help more.
12:09 bacek And hairy-hairy string compact pool...
12:10 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
12:11 bacek whiteknight, was it your idea to split string allocator into separate "class"?
12:11 whiteknight yeah
12:12 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
12:12 dalek parrot: r47336 | bacek++ | branches/gc_massacre (5 files):
12:12 dalek parrot: Add dumb M&S GC based on GCMassacre wiki page.
12:12 dalek parrot: It's slightly faster than original M&S GC in allocating PMC headers.
12:12 dalek parrot: Overall performance isn't so great due absence of fast Attributes
12:12 dalek parrot: allocator.
12:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47336/
12:12 dalek parrot: r47337 | bacek++ | branches/gc_massacre/examples/b​enchmarks/stress_integers.pir:
12:12 dalek parrot: Add GC stress test for almost pure PMC allocator speed.
12:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47337/
12:13 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:14 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
12:15 bacek We just have to figure out proper interaction between PMC GC and String GC. Just because PMC GC is driving.
12:16 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 whiteknight at least, that's how it is now, we could change it if you have a better ida
12:16 whiteknight idea
12:16 bacek I do want GenGC.
12:17 bacek And it will be not so easy...
12:17 bacek But... Let me think for few minutes.
12:17 whiteknight maybe we need to change strings over to a proper refcount.
12:17 whiteknight every STRING* header has a pointer to the buffer. str->buffer[-1] could contain a refcount
12:17 bacek no way!
12:18 whiteknight why not? Then buffer deallocation would be an automatic part of normal GC
12:18 bacek we do want compacting.
12:18 whiteknight I have to run an errand. I'll be back in a little while
12:19 whiteknight we can compact after the GC run. Anything that is still alive with a positive refcount gets compacted
12:19 whiteknight everything else, not so much
12:19 whiteknight be back in a bit
12:19 * whiteknight leaves
12:23 cognominal joined #parrot
12:27 JimmyZ_ joined #parrot
12:32 bluescreen joined #parrot
12:40 jsut joined #parrot
12:46 mikehh joined #parrot
12:49 pmichaud bacek: reviewing multi code is my first task after taking daughter to school
12:50 pmichaud (was going to do it last night but fell asleep)
12:50 bacek pmichaud, I'll probably fell asleep soon.
12:50 bacek or it's "fall"
12:51 bacek anyway, everything in C<multis> branch in main nqp-rx repo
12:51 pmichaud bacek: excellent.
12:51 bacek want me to sync it with master?
12:52 pmichaud bacek: no thanks, I can review it okay as-is
12:52 bacek pmichaud, ok
12:58 lucian joined #parrot
13:01 lucian__ joined #parrot
13:09 dalek rakudo: 2242efb | (Solomon Foster)++ | src/core/metaops.pm:
13:09 dalek rakudo: Implement the new rules for handling hypers of different lengths.
13:09 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​242efb89371a83c389536b84e1f438e872e145e
13:17 atrodo joined #parrot
13:17 whiteknight I don't like it when bacek falls asleep
13:18 whiteknight so much work stops getting done until he comes back :)
13:18 bacek I do need to recharge my batteries
13:18 bacek Unfortunately there is no compact nuclear power reactors yet
13:19 whiteknight certainly none approved for use with humans
13:20 bacek I don't need such approval
13:21 Coke \o/ yay, partcl should be fixed by this evening.
13:21 Coke ... now stop  breaking it. =-)
13:22 whiteknight Coke: far more likely is that you just stop fixing it :)
13:25 Coke ... well, I've discovered that makes me grumpy, so I'll try to avoid that in future.
13:25 whiteknight haha, yeah.
13:25 whiteknight pmichaud: ping
13:25 pmichaud whiteknight: pong
13:26 Coke PING PONG!
13:26 purl hmmm... ping pong is for everybody
13:26 whiteknight pmichaud: does NQP-RX support functions with multiple return values?
13:26 whiteknight I know it didn't used to, I'm wondering if that has changed
13:27 bacek good night. humans
13:27 bacek Time for recharge
13:27 Coke good night, bacbok.
13:27 whiteknight goodnight
13:28 pmichaud whiteknight: it does, but not in the parrot sense of multiple return values
13:28 pmichaud because there's not really a way to put multiple return values into a return exception
13:28 pmichaud (in the parrot sense)
13:29 pmichaud 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?
13:29 pmichaud return ($a, $b, $c)
13:29 pmichaud but you get back a single RPA with three elements
13:29 pmichaud whiteknight: what's a "return continuation"?
13:29 Coke whiteknight: by return continuation, you mean a normal parrot return?
13:30 Coke 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
13:30 whiteknight by "return continuation" I meant a continuation pointing to the label of some kind of return logic
13:30 whiteknight or even the continuation that points back to the caller
13:31 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 pmichaud how does that return continuation carry the return values?
13:31 whiteknight pmichaud: yes, basically. The benefit there is that you can invoke that continuation with any number of return values
13:31 pmichaud how does the nested Parrot sub locate the return continuation it's supposed to use?
13:32 pmichaud how does the label that the return continuation targets obtain the return values?
13:32 JimmyZ_ joined #parrot
13:32 whiteknight you can locate anything if you store it in a sufficiently odd-named lexical
13:33 whiteknight 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
13:33 pmichaud $P0 = find_lex '!return_continuation'
13:33 pmichaud $P0(1, 2, 3, 4)
13:33 pmichaud ?
13:34 pmichaud (short answer to your earlier question is that PAST has no problem with doing things with multiple return values.)
13:35 pmichaud (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:38 whiteknight yes, that's exactly what I was thinking
13:38 whiteknight I'm sure i'm missing some feasibility details
13:39 whiteknight so long as PAST can support it, I guess I really don't care how the sausage is made
13:41 pmichaud the problem is on the receiver side
13:41 pmichaud in the outer sub that sets up !return_continuation, I get
13:41 pmichaud $P0 = new ['Continuation']
13:41 pmichaud set_addr $P0, label
13:41 pmichaud ...
13:41 pmichaud label:
13:41 pmichaud # we get here because someone invoked a 'return'
13:42 pmichaud # how do we get the arguments?
13:42 pmichaud i.e., how do we get the return values?
13:42 pmichaud that's the part I don't know how to handle.
13:43 pmichaud 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:45 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:47 whiteknight unless there is cleanup to do a the end of the function
13:47 pmichaud right... I'm interested in the cleanup case.
13:47 jnthn Not to mention that in Perl 6 you may need to type check and/or coerce the value.
13:48 jnthn Before returning it.
13:48 jnthn So a general solution needs us to be able to do something before returning.
13:48 Coke tcl specifically deals with returns as control exceptions, so this isn't a cross-HLL portable thing, either.
13:48 whiteknight ...in which case we would need to unpack the context, do cleanup/postprocesing, and pass them to the next continuaton
13:48 pmichaud ...unpack the context?
13:48 pmichaud how does one do that (in PIR)?
13:49 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.)
13:49 whiteknight so this idea needs more consideration
13:49 pmichaud sure.
13:49 jnthn I'm not convinced that we'd end up with a cleaner result by doing some continuation based thing rather than exception based.
13:49 jnthn In both cases you need to clear up a bunch of contexts.
13:49 hudnix joined #parrot
13:49 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
13:50 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
13:50 whiteknight jnthn: it doesn't clone the contexts, I don't believe. Just takes a reference
13:50 pmichaud but as yet, continuations don't have payloads afaik
13:50 jnthn In the ideal case, yes.
13:50 pmichaud and there doesn't seem to be a way to grab any parameters from an invoked continuation
13:50 jnthn You have to know it's safe to do that though.
13:51 whiteknight continuations do take argument lists, and a call to get_args can retrieve them
13:51 pmichaud whiteknight: from PIR?
13:51 whiteknight from PIR
13:51 pmichaud example, please?
13:51 whiteknight that's something that I either need to hunt for or create
13:51 pmichaud ah
13:51 whiteknight but I know that, at least after the PCC refactors, it is very possible
13:51 jnthn pmichaud: I guess if we did stash a lexical continuation, we get lexical return semantics for free. ;-)
13:51 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?
13:52 pmichaud 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:53 whiteknight $P0 = new ['Continuation']
13:53 whiteknight set_addr $P0, exit_routine
13:53 whiteknight exit_routine:
13:53 whiteknight .param pmc args :slurpy
13:53 whiteknight .param pmc args_n :named :slurpy
13:53 whiteknight ...
13:53 whiteknight .return (args :flat, args_n :flat)
13:53 whiteknight I haven't tested that, but something like it should work
13:53 pmichaud whiteknight: that works today?  or you're proposing it?
13:53 pmichaud I'm pretty sure that doesn't work today.  I bet it doesn't even parse.
13:54 whiteknight the .param syntax may be the sticking point.
13:54 pmichaud iirc, imcc only accepts .param immediately after .sub declarations
13:54 pmichaud it doesn't even allow blank lines or comments
13:54 whiteknight yeah, so we probably need to call the raw get_args opcode directly
13:54 jnthn Dunno if the .get_arg hack we use for exception handlers would work.
13:54 jnthn Or whatever it's called.
13:54 whiteknight .get_result?
13:54 jnthn Maybe
13:54 * jnthn checks
13:55 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:
13:55 jnthn .get_results ($P0)
13:55 jnthn That one, yeah.
13:56 pmichaud I thought that just got me the exception object
13:56 pmichaud not any payload
13:56 pmichaud in the  exit_routine case above, I already have the continuation object
13:56 jnthn pmichaud: Indeed, and I've no clue what it does in the continuation case.
13:56 pmichaud that's not what I need.
13:56 jnthn pmichaud: I was guessing it might get the actual argument(s).
13:56 jnthn pmichaud: Since the invoke of the continuation woulda set up a callsig.
13:56 jnthn iirc
13:57 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.
13:57 jnthn I ran over it the other day when fixing backtraces.
13:57 whiteknight pmichaud: if this is the functionality you are waiting on, I'll gladly try and get it put together soon
13:59 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
13:59 pmichaud ideally where the routine (the outermost block) can intercept the return to do any cleanups it needs before doing the real return
13:59 pmichaud I'm writing a short framework example... just a sec
14:00 whiteknight ok
14:04 nopaste "pmichaud" at 192.168.1.3 pasted "example with return handling" (36 lines) at http://nopaste.snit.ch/20879
14:04 pmichaud see nopaste.  The XXX step is the part that isn't entirely clear at this point.
14:05 * pmichaud tries .get_results
14:05 pmichaud hmm, .get_results seems to work
14:06 nopaste "pmichaud" at 192.168.1.3 pasted "initial working example with return handling" (53 lines) at http://nopaste.snit.ch/20880
14:06 pmichaud now to see if it works with :slurpy
14:07 nopaste "pmichaud" at 192.168.1.3 pasted "initial working example with return handling and :slurpy" (51 lines) at http://nopaste.snit.ch/20881
14:08 pmichaud now to see what is happening with the caller stack.
14:10 pmichaud looks like invoking the continuation "rolls up" the caller stack
14:11 pmichaud oh, maybe not.
14:11 pmichaud ummm....
14:12 pmichaud so, can someone explain exactly what happens with contexts when a continuation is invoked?
14:14 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 whiteknight any contexts that aren't being referenced by anything at that point will get GC collected
14:15 whiteknight 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
14:15 pmichaud Parrot_continuation_check(INTERP, SELF);
14:15 pmichaud Parrot_continuation_rewind_environment(INTERP, SELF);
14:15 pmichaud I don't know what "rewind_environment" means here.
14:15 whiteknight _rewind_environment doesn't walk the list of contexts or anything
14:16 whiteknight if I remember correctly, it doesn't do a hell of a lot
14:16 pmichaud ok.
14:17 whiteknight http://trac.parrot.org/parrot​/browser/trunk/src/sub.c:502. All it appears to do is set the current signature object
14:17 whiteknight http://trac.parrot.org/parrot​/browser/trunk/src/sub.c#L502
14:18 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 pmichaud we'd want to support both options, because there are some languages for which returns really do need to be dynamic and exception based
14:18 pmichaud (e.g., Perl 6)
14:18 JimmyZ joined #parrot
14:19 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.
14:19 jnthn pmichaud: The way I had it in alpha was horrible.
14:19 jnthn OK, great.
14:20 jnthn (I didn't put return value type checks back into master yet, mostly for not having a clean way.)
14:20 jnthn The alpha way made even me go "ick". ;-)
14:21 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.
14:21 pmichaud Coke: ah yes, I remember seeing that.  Coke++
14:21 Coke plobsing++
14:21 Coke plobsing++
14:22 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 #parrot
14:23 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 jnthn But, well, wasteful.
14:24 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 pmichaud still, a specialized PAST structure for the whole thing would likely work.
14:24 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.
14:25 jnthn pmichaud: (e.g. a Parcel)
14:25 pmichaud PAST::Op.new( :pasttype<return_handler>, $mainline_past )
14:25 pmichaud sets up a return handler, uses the value from $mainline_past if no return continuation invoked
14:26 pmichaud or perhaps it's more of a PAST::Control node
14:26 pmichaud I dunno.
14:26 pmichaud or it's another special-purpose marker in PAST::Block
14:27 pmichaud 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.
14:27 Coke is it just an implementation issue, like with methods?
14:27 pmichaud Coke: because you have to walk the chain of callers looking for exception handlers
14:28 pmichaud whereas with a continuation, you jump directly to the point registered with the continuation
14:28 pmichaud no need to look up the call chain for handlers and figure out which ones are designed to handle the return exception.
14:30 Coke given that tcl (and perl6) explicitly support returning specific levels up the chain, that needs to be taken into account too.
14:30 plobsing joined #parrot
14:31 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 pmichaud so,  &sub.leave actually invokes the return continuation
14:31 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.
14:32 Coke (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"
14:33 pmichaud i.e., an do-this-on-exit sort of thing.
14:34 pmichaud 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 pmichaud the real cost is in setting up the exception/continuation, not in handling it.
14:34 Coke (on exit handlers) tcl's needs are even worse there. =-)
14:35 Coke (I need enter, leave, enterstep, and leavestep granularity.)
14:35 hudnix joined #parrot
14:36 Coke (though i suspect in my case, I'm going to just recompile the sub and generate a new AST for that case)
14:39 nopaste "pmichaud" at 192.168.1.3 pasted "another working example, invoke routine's return continuation directly" (45 lines) at http://nopaste.snit.ch/20884
14:40 pmichaud usefully, here's an example that doesn't involve creating an exception handler or continuation at all
14:40 pmichaud this would work if you don't care about intercepting the return values
14:40 pmichaud i.e., you're willing to return them directly to the caller.
14:40 pmichaud more importantly, PAST already supports this.  :-)
14:41 pmichaud I might switch NQP to use it.
14:41 pmichaud (instead of the exception-based return)
14:42 pmichaud the downside is that it does involve making an otherwise invisible entry in the lexpad
14:44 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.
14:44 pmichaud Coke: yes, that's correct.
14:46 pmichaud jnthn: I agree -- I may want to re-examine S04 with this new information in mind.
14:52 Draco joined #parrot
14:52 Draco Hello, people!
14:54 moritz hello Draco
14:56 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"
14:57 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?
14:57 Coke ah, that's the build dir.
14:57 moritz Draco: the tutorial assumes that you have a source directory of parrot lying around
14:57 moritz if you see a Configure.pl, you're likely there
14:58 Draco Ah, that is the one that I download, then run the make install-dev from?
14:59 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....
15:00 Draco But I can't find the parse directory in the Squaak/src
15:00 Draco parser*
15:01 Draco There is a squaak directory inside squaak/src...... But there is no grammar.pg inside, but I can find grammar.pm
15:01 bubaflub joined #parrot
15:04 theory joined #parrot
15:04 Draco So... Is the grammar.pg same as Grammar.pm?
15:05 particle yes, that's another but of unupdated history
15:06 Draco Okies, thanks....
15:07 Draco 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:08 patspam joined #parrot
15:09 Draco But the next line mentioned about renaming rule "integer" as "integer_constant" .... That rule is not there either...
15:09 Draco Or does that merely means rename the "integer_constant" in the rule "expression"?
15:10 Draco Sorry for so many questions :D
15:11 khairul joined #parrot
15:11 ruoso joined #parrot
15:13 pmichaud afk, errand
15:14 Coke draco - if you're reading off the blog posting, those docs are now ancient.
15:14 Coke and I don't think they were ever updated. (so questions are inevitable, don't worry)
15:17 Coke Draco: not that it helps you, but http://trac.parrot.org/parrot/ticket/1673
15:18 Coke the just created ZOMG please update those docs ticket.
15:24 Draco Thanks much, Coke....
15:25 Draco I was reading from Wikibook, but I supposed it doesn't differ much from the blog
15:28 whiteknight The wikibook is older too
15:28 whiteknight I haven't updated that in some months
15:32 whiteknight 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"
15:32 dalek TT #1673: http://trac.parrot.org/parrot/ticket/1673
15:37 cognominal joined #parrot
15:42 fperrad karma fperrad
15:42 purl fperrad has karma of 2379
15:48 dalek parrot: r47338 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
15:48 dalek parrot: [distutils] add a 'Hello World' example
15:48 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47338/
15:52 Coke hello, François
15:57 sorear bacek: I am a fan of the proposal that we eliminate the substr "optimization".  substr copies and no buffers are ever shared...
15:58 davidfetter joined #parrot
16:03 theory joined #parrot
16:06 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:08 Maddingue joined #parrot
16:11 sorear memory requirements get lower because random strings in parse trees no longer retain the original
16:11 sorear memory requirements get lower because the "start" field can be scrapped
16:11 sorear substrings get cheaper because compact_pool has less numbers to work with
16:12 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)
16:12 Coke I was under the impression bacek had already ripped out that optimization.
16:12 Coke er, imagine I used the finger-quotes there.
16:13 tcurtis joined #parrot
16:14 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:36 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 parrot: r47339 | mikehh++ | branches/gc_massacre/MANIFEST:
16:36 dalek parrot: re-generate MANIFEST
16:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47339/
16:36 dalek parrot: r47340 | mikehh++ | branches/gc_massacre (2 files):
16:36 dalek parrot: add svn properties
16:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47340/
16:36 Coke but any memory improvements ++. =-)
16:37 whiteknight Coke: well that certainly sounds like a bug. Any substrings should point into the original buffer and require no additional storage allocation
16:41 NotFound We are still getting used to immutable strings, many things we were used to are not longer true.
16:43 whiteknight Yes, there are some growing pains
16:43 whiteknight but overall, I would say it was a very easy transition
16:44 NotFound Yeah, and helped a lot to clear some long-running mistakes.
16:53 dalek parrot: r47341 | NotFound++ | trunk/t/pmc/resizableintegerarray.t:
16:53 dalek parrot: tests for RIA delete_keyed_int
16:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47341/
16:53 dalek parrot: r47342 | mikehh++ | branches/gc_massacre/src/gc/list.h:
16:53 dalek parrot: fix codetest failure - there should be at least one space between a C keyword and any subsequent open parenthesis
16:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47342/
16:53 theory_ joined #parrot
17:01 cotto_work joined #parrot
17:05 Coke hurm. git status on master showed how far ahead of origin I was. the branch doesn't seem to provide that info.
17:10 whiteknight is the branch tracking the origin?
17:11 theory joined #parrot
17:26 jsut joined #parrot
17:53 dmalcolm joined #parrot
17:56 Coke *blank stare*
17:57 Coke (how do I check that?)
18:06 mikehh make corevm/make coretest FAIL - 37 subtests fail, 208 subtests and 1 test not even run
18:06 mikehh t/compilers/imcc/syn/clash.t - Failed test:  13 in testr
18:06 mikehh all other tests PASS (pre/post-config, smoke (#34197), fulltest) at r47342 - Ubuntu 10.04 amd64 (g++)
18:06 mikehh t/op/annotate-old.t - TODO passed:   1 in testf
18:07 mikehh get a couple of TODO passes on i386 which don't on amd64
18:09 bubaflub Coke: you could try `git branch -a`
18:09 bubaflub to see all branches
18:53 dalek rakudo: a0b6d74 | jimmy++ | src/Perl6/Actions.pm:
18:53 dalek rakudo: fixed #75114: Can't augment class Int
18:53 dalek rakudo: Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
18:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​0b6d74db23a48768fc962863bfaf6f42f5d77b1
18:54 Coke bubaflub: that doesn't really show me anything.
18:54 Coke I mean, I get a list of branches, with a * next to the active one.
18:56 Coke but that's it.
18:56 bubaflub Coke: ah, i thought you wanted to see your branches
18:56 ruoso joined #parrot
18:57 bubaflub Coke: did you want to setup your local branch to track a remote branch?
18:58 Coke bubaflub: in the past, "git status" has shown me how many commits ahead of the origin I am.
18:58 Coke 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.
18:59 bubaflub Coke: it may be the way that the branch is set to track
18:59 bubaflub can you nopaste the relevant section from your .git/config
19:00 bubaflub should be something like
19:00 bubaflub [branch "topic"]
19:00 bubaflub and then a line below that that says merge =
19:02 Coke ENOSECTIONLIKETHAT
19:02 bubaflub yikes
19:02 Coke oh, .git/config, not ~/.gitconfig. =-)
19:02 bubaflub ah, yes
19:02 Coke there is no [branch "<branchname>"] there.
19:03 bubaflub what do you see in there?  perhaps it's in a section [remote ...]
19:04 nopaste "coke" at 192.168.1.3 pasted "git config" (15 lines) at http://nopaste.snit.ch/20890
19:04 Coke the branch is 'revive'
19:05 gbacon joined #parrot
19:07 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:08 atrodo Coke> Your current branch is "revive" and the branch that will tell you are N commits ahead is master?
19:24 Coke atrodo: yes.
19:24 Coke not that I'm ahead on my local copy of master atm to double check.
19:28 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 atrodo would be my guess
19:31 cotto_work joined #parrot
19:33 jsut_ joined #parrot
19:33 pjcj joined #parrot
19:46 whiteknight joined #parrot
19:47 NotFound mikehh: What TODOs? It passes just one for me.
19:49 NotFound Oh, you mean with testf...
19:49 mikehh NotFound - t/pmc/packfile.t - TODO passed:   34 in coretest, smoke, testb, testf and testr
19:49 mikehh NotFound: t/op/exit.t - TODO passed:   6 in testf
19:50 mikehh 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"
19:51 whiteknight 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 #parrot
19:51 NotFound whiteknight: Internet is for porn!
19:51 whiteknight NotFound: well, I certainly haven't found another use for it
19:52 NotFound http://video.google.com/videop​lay?docid=5430343841227974645#
19:53 * cotto_work avoids clicking
19:53 NotFound cotto_work: Is just a funny video
19:53 cotto_work sfw?
19:53 purl sfw is safe for work or safe for wife or sun freeware but you knew that.
19:54 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.
19:55 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.
19:55 cotto_work I think it's nice to have purl back.  I'm not entirely sure though.
19:56 * NotFound don't know who Glenn Danzig is
19:56 cotto_work maybe you should see that video
19:56 NotFound purl: Glenn Danzig?
19:56 purl notfound: bugger all, i dunno
19:59 NotFound purl: Internet?
19:59 purl Internet is for porn or Serious Business.
20:03 Psyche^ joined #parrot
20:24 bacek Good morning, humans
20:26 bacek sorear, whiteknight, I've got feeling that removing "shared buffers" will actually speed-up parrot.
20:27 bacek And reduce memory usage because compact_pool can be precise
20:29 dalek nqp-rx: a68924f | pmichaud++ | src/Regex/P6Regex/ (2 files):
20:29 dalek nqp-rx: Update ** quantifier a bit, recognize trailing spaces as request to
20:29 dalek nqp-rx: add <.ws> between each element.  (This isn't completely what S05
20:29 dalek nqp-rx: specifies, but it's a good first cut.)
20:29 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/a​68924fd3dbe3f4b392f6460f28b99df3a482d28
20:29 dalek nqp-rx: 9e955a4 | pmichaud++ | build/PARROT_REVISION:
20:29 dalek nqp-rx: Bump PARROT_REVISION to get FileHandle.tell.
20:29 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/9​e955a4984fe0eb51307415a42127fb0c64ed919
20:29 dalek nqp-rx: 38fc6e9 | pmichaud++ | src/Regex/P6Regex/Actions.pm:
20:29 dalek nqp-rx: Add :sigspace handling to range quantifiers (e.g., <x> ** 0..3)
20:29 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/3​8fc6e9a2c4d12504ce450c282fc2a3c6e701e93
20:31 pmichaud bacek: still trying to get to review multi branch :)
20:31 bacek pmichaud, :)
20:31 darbelo bacek: I did some thinking on 'unshared buffers' and it shouldn't be too hard to do.
20:32 bacek darbelo, just ripping a lot of code.
20:33 whiteknight bacek: I would like to see an experiment without shared buffers, but I'm not hopeful
20:34 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:35 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 #parrot
20:36 darbelo whiteknight: If anything benefits from precise compaction, it'll be that.
20:36 whiteknight darbelo: maybe. I'm open to data
20:38 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 darbelo ;)
20:39 bacek darbelo, just create unshared_buffer branch then :)
20:40 bacek It will take couple of hours to implement
20:40 bluescreen joined #parrot
20:40 darbelo And, COW complicates NFG.
20:41 dalek nqp-rx: 5fb2d58 | pmichaud++ |  (3 files):
20:41 dalek nqp-rx: Add \e in quoted strings, refactor 46-charspec.t .
20:41 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/5​fb2d58d196347d29e64ece94c6adee80e2e93ec
20:41 * whiteknight has to go to the store. be back later
20:44 bacek slacker!
20:44 purl slacker is like lazy bum
20:47 joeri joined #parrot
20:49 mikehh bacek: got a couple of problems with gc_massacre
20:51 bacek mikehh, only couple??? :)
20:52 mikehh g++ don't like src/gc/pool_allocator.c - assigning (size_t) - 1 to a pointer
20:53 bacek change it to something like MAX_INT
20:53 purl bacek: that doesn't look right
20:53 cotto_work toxic botsnack
20:53 purl thanks cotto_work :)
20:53 bacek (I'm not sure that it's in C89)
20:54 mikehh bacek: and t/op/string_mem.t hangs on test 6
20:54 bacek mikehh, because test is stupid...
20:55 bacek And we didn't implement GC.get_info yet :)
20:56 particle INT_MAX is C89, limits.h
20:56 Coke purl, i hope you choke on that botsnack.
20:56 purl thanks Coke :)
20:57 mikehh bacek: yeah that test is a hangover for COW and stuff
20:58 mikehh from
21:06 mikehh bacek: in make test the opsc tests seem to go out-to-lunch as well
21:07 bacek mikehh, let me check
21:09 gbacon joined #parrot
21:10 cotto_work http://code.google.com/events/io/2010/sess​ions/jit-compiler-androids-dalvik-vm.html (video is up now)
21:16 bacek mikehh, yeah... String part of GC isn't implemented yet.
21:19 lucian joined #parrot
21:19 cotto_work opsc tests are really slow in gc_massacre but they appear to be running ok so far
21:19 dalek parrot: r47343 | gerd++ | trunk/tools/docs/filename_and_chapter.pl:
21:19 dalek parrot: make necessary changes to integrate "ch04_variables.pod" and to improve the table of contents
21:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47343/
21:19 bacek untill OOM killer will kill it
21:20 cotto_work true.  It does seem to have an unusual love for my delicious memory.
21:21 mikehh stopped t/compilers/opsc/02-parse-all-ops.t after 10 minutes and after it grabbed over 2GB at 10/20
21:22 cotto_work I'd prefer that it eat my memory rather than my brains.
21:22 cotto_work neither would be ideal
21:23 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
21:23 darbelo Have it eat cotto's brain or my memory? Tough choice there.
21:24 hudnix joined #parrot
21:25 theory joined #parrot
21:27 dukeleto 'ello
21:28 atrodo Interesting.  Kylix messes with the FPU which causes parrot to die on divide by zeros or invalid floating point operations
21:30 darbelo ...why does it mess with the FPU?
21:31 atrodo :shurg: No idea.  Probably a vestage from it's Windows roots
21:31 atrodo Thankfully, now that I know what it does (masks some FP excetptions), it does give an easy way to undo them
21:31 darbelo And, mostly out of curiosity, does mess it up enough that we should be dying?
21:31 darbelo :)
21:32 atrodo Probably.  It turns divide by zero's into a SIGFPE
21:32 darbelo Ouch.
21:34 davidfetter joined #parrot
21:36 GeJ Good morning everyone.
21:37 everyone Good morning GeJ.
21:37 dukeleto davidfetter: howdy
21:37 davidfetter what's new & good, dukeleto ?
21:38 dukeleto davidfetter: hanging out at OSBridge, hacking on PL/Parrot
21:38 davidfetter got new compadres for that?
21:39 dukeleto davidfetter: telling people about it and drumming up interest
21:39 davidfetter :)
21:39 dukeleto davidfetter: trying to get PL/Perl6 to work, hitting some brick walls
21:40 davidfetter do you have some idea where those are?
21:40 purl those are fairly generic
21:41 dukeleto davidfetter: loading the perl6 PBC errors out now
21:42 davidfetter hrm. is there some parrot sha1 (or whatever svn uses) that doesn't do this?
21:44 pmichaud nqp now supports primitive multisubs.  bacek++
21:44 dukeleto davidfetter: what exactly do you mean? i am using Parrot trunk and rakudo master
21:45 davidfetter did any recent parrot commits break this?
21:45 davidfetter rakudo ones?
21:46 dukeleto davidfetter: i don't think so. "parrot perl6.pbc" works, but I am not doing something correctly, most probably
21:47 bluescreen joined #parrot
21:47 darbelo dukeleto: rakudo can be fairly libreal with it's uses of parrot guts, sometimes.
21:48 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 ;)
21:48 dukeleto darbelo: indeed :)
21:49 dalek nqp-rx: eba2f2b | pmichaud++ |  (3 files):
21:49 dalek nqp-rx: Merge branch 'multis'
21:49 pmichaud bacek: multis branch merged and updated in parrot.  enjoy.  :-)
21:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/e​ba2f2be9c5af703fb4c0a2a8d4464b5032dc75f
21:49 dalek nqp-rx: 7006d42 | pmichaud++ | t/nqp/49-multis.t:
21:49 dalek nqp-rx: Rename multi tests.
21:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​006d4280514c3575247c28f08aeeec1a87b5a45
21:49 dalek nqp-rx: 9612a72 | pmichaud++ | src/NQP/ (2 files):
21:49 dalek nqp-rx: [nqp]: Eliminate $*METHODTYPE from grammar and actions.
21:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/9​612a72d93b2c78a72c8836579df192be1c53b59
21:49 dalek nqp-rx: 9d44980 | pmichaud++ | src/stage0/ (4 files):
21:49 dalek nqp-rx: Update bootstrap.
21:49 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/9​d44980671ef25bb323442df4d5c2841c4ff5e60
21:50 dukeleto pmichaud: i am getting this when attempting to load perl6.pbc from Parrot's C API : http://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.
21:51 pmichaud 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)
21:51 jnthn perl6;Perl6;Compiler;main
21:51 jnthn main?
21:51 purl hmmm... main is the package of the test script
21:51 * jnthn wonders if we should be in :main
21:51 jnthn (on a library load)
21:52 pmichaud yeah, seems like :main shouldn't be invoked there either.
21:52 cotto_work joined #parrot
21:52 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 #parrot
21:52 patspam joined #parrot
21:52 pmichaud which likely means that the :load :init subs from the perl6.pbc file aren't being invoked
21:52 jnthn Most probably
21:52 pmichaud or, if they are, that the load_bytecode that they do (in order to load the other libraries) aren't being honored somehow.
21:53 jnthn Note taht we don't laod P6object explicitly, but other things we do load will in turn load it.
21:53 pmichaud correct
21:53 pmichaud P6object gets loaded by PCT, which is loaded by HLL.pbc
21:53 pmichaud (or something like that)
21:53 pmichaud there's a reasonably long chain of library loads that happen early on in any pct-based environment.
21:53 dukeleto jnthn, pmichaud: yeah, i loa P6object manually, but some other dependency must be missing
21:54 dalek parrot: r47344 | pmichaud++ | trunk/ext/nqp-rx/src/stage0 (4 files):
21:54 dalek parrot: [nqp-rx]:  Update nqp-rx with multisub support (bacek++), other fixes.
21:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47344/
21:54 pmichaud or it could be loading things into the wrong place.
21:54 pmichaud afk for a while
21:55 NotFound dukeleto: if the problem is related to dynops loading, anything can fail in the most bizarre ways.
21:56 dukeleto NotFound: yes, lots of dynops are involved.
21:56 darbelo I would investigate pbc load order first. Rule out the obvious suspects first.
21:57 bacek pmichaud, hooray!
21:57 bacek next step - traits parsing :)
21:58 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 ;)
21:58 dalek winxed: r488 | julian.notfound++ | trunk/winxedst1.winxed:
21:58 dalek winxed: more refactor of simple argument list
21:58 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=488
21:59 dukeleto darbelo: i have a skeleton C file which attempts to load perl6.pbc and fails
22:01 silug joined #parrot
22:05 snarkyboojum joined #parrot
22:07 dukeleto seems like perl6_group is not getting .loadlib'ed correctly, probably because it can't be found
22:08 dukeleto i see the light!
22:08 whiteknight dont walk into it
22:10 dukeleto parrot perl6.pbc only works from the directory that perl6.pbc is in
22:10 darbelo Is that an installed perl6?
22:10 dukeleto if you try parrot /some/dir/perl6.pbc, you get the error about "Null PMC access in find_method('new_class')"
22:11 dukeleto oh noes!
22:11 dukeleto it is not
22:11 dukeleto whiteknight: trying an installed perl6 now
22:11 darbelo An non-installed rakudo can't function out of the build dir IIRC.
22:12 darbelo It used to be a note in some SHOUTING FILE or another.
22:12 jnthn darbelo: Correct.
22:12 jnthn It probably is in one, but of course nobody reads them...unless you call them IGNOREME :-)
22:14 dukeleto using an installed rakudo is the way to go
22:15 darbelo Until this step is performed, the "perl6" executable
22:15 darbelo created by C<make> above can only be reliably run from the root of
22:15 darbelo Rakudo's build directory.
22:15 darbelo That's on the README ;)
22:16 darbelo 'this step' == make install
22:18 dukeleto darbelo: that is what I get for not reading the README :)
22:19 dukeleto i get: Class '[ 'ClassToBe' ]' not found now
22:19 darbelo I wonder if symlinking it to README.NOT would make more people read it...
22:20 darbelo 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...
22:21 * darbelo said 'progress' not 'perfection' ;)
22:42 dukeleto now i get this: http://gist.github.com/424624 when loading perl6.pbc from C
22:44 theory joined #parrot
22:49 kid51 joined #parrot
22:54 whiteknight Anybody have objections if I merge in the ns_func_cleanup branch?
22:54 whiteknight I was hoping for feedback, but no
22:54 cotto_work Does it need a deprecation cycle?
22:54 cotto_work +1 if not
22:54 kid51 What does it do?
22:54 kid51 Has it been described at all on parrot-dev?
22:55 whiteknight kid51: yeah, I sent out an email about it a few days ago
22:55 whiteknight warnocked
22:55 purl warnocked is http://en.wikipedia.org/wiki/Warnocked
22:56 * kid51 reads parrot-dev
22:56 cotto_work Yay.  trac.parrot.org is unbroken
22:56 sorear What was wrong?
22:56 cotto_work coke++ for complaining about it through the proper channel
22:56 kid51 sorear:  My impression was that it wasn't loading its CSS
22:57 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.
22:57 whiteknight http://lists.parrot.org/pipermail​/parrot-dev/2010-May/004335.html
22:57 darbelo whiteknight: Cleanup is always good. Non-breaking cleanups are best.
22:57 whiteknight it's a breaking cleanup, but the function renames have been deprecated for a long damn time
22:58 cotto_work fire at will, then
22:59 whiteknight working...
22:59 purl working is a good approximation.
22:59 cotto_work just don't make Rakudo cry
22:59 cotto_work or partcl
22:59 * kid51 reads whiteknight's post ...
22:59 kid51 src/global.c -> src/namespace.h
22:59 kid51 a .c file became a header file?
22:59 whiteknight I make no promises
22:59 whiteknight kid51, no. Might be a typo
23:00 * Coke plays with his new ubuntu netbook
23:01 cotto_work I don't see any such change
23:01 cotto_work just some x.c -> y.c and x.h -> y.h changes
23:05 whiteknight if Rakudo uses any of these functions, it's going to need a patch
23:08 * whiteknight is building now
23:09 kid51 whiteknight:  you are belatedly dewarnocked; check mail
23:11 dngor joined #parrot
23:11 whiteknight kid51++
23:12 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 kid51 make coretest still doing badly:  http://smolder.plusthree.com/ap​p/projects/report_details/34202
23:13 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.
23:14 kid51 Now, this is somewhat of a philosophical position on my part, which we've touched on before.
23:15 kid51 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 kid51 In particular, unless the TODO is consistent with a design decision that we continue to hold, we shouldn't be bound for it.
23:15 kid51 s/for/by/
23:16 kid51 As far as I am concerned, such RTs are technical debt.
23:17 workbench joined #parrot
23:17 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 kid51 But, as we well know, other committers have different opinions.
23:18 darbelo_ joined #parrot
23:18 kid51 And there have been times when I have gone on a ticket-closing rampage only to have my knuckles rapped thereafter.
23:19 kid51 That being said, we currently have 690 open tickets (Report 10)
23:19 kid51 That's at the high end of what we have historically been willing to tolerate.
23:19 kid51 700 open tickets is a red flag
23:19 cotto_work joined #parrot
23:19 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.
23:20 whiteknight pmichad: yes, I just tried building. I'll submit a patch or something
23:20 whiteknight pmichaud*
23:20 whiteknight how do you prefer I go about it, send you a patch? fork rakudo on github and make changes there for you to pull?
23:21 pmichaud we generally prefer patches still
23:21 pmichaud or, you could create a branch in the rakudo repository
23:21 pmichaud but anything will work, really -- we now have enough git-fu to be able to figure out how to deal with merging :)
23:21 pmichaud just know that github "pull requests" still tend to get ignored :)
23:22 dalek TT #1219 closed by whiteknight++: Parrot's default namespaces should be fully typed
23:22 dalek TT #1219: http://trac.parrot.org/parrot/ticket/1219
23:22 dalek TT #1220 closed by whiteknight++: Stop depending upon typed namespaces in internal_ns_keyed()
23:22 dalek TT #1220: http://trac.parrot.org/parrot/ticket/1220
23:22 dalek TT #1221 closed by whiteknight++: Match HLL of enclosing namespace in internal_ns_keyed()?
23:22 dalek TT #1221: http://trac.parrot.org/parrot/ticket/1221
23:22 dalek TT #1222 closed by whiteknight++: Use the untyped interface in Parrot_find_global_n()
23:22 dalek TT #1222: http://trac.parrot.org/parrot/ticket/1222
23:22 dalek TT #1224 closed by whiteknight++: Fix temporary hack for cache invalidation; should be a namespace function; ...
23:22 dalek TT #1224: http://trac.parrot.org/parrot/ticket/1224
23:22 dalek TT #1225 closed by whiteknight++: Method cache invalidation should be a namespace function
23:22 dalek TT #1225: http://trac.parrot.org/parrot/ticket/1225
23:22 cotto_work It's a tracpocalypse!
23:25 Coke some of those old NS tickets were from chip
23:25 Coke whiteknight: I'll have partcl master working shortly so you can test against that too.
23:28 sorear you mean partcl-not-nqp?
23:30 bacek_at_work whiteknight, cheap karma for closing http://trac.parrot.org/parrot/ticket/655
23:31 pmichaud Coke: have you had to give up on partcl-nqp?
23:33 Coke pmichaud: no. But partcl was so broken it needed some lvoe
23:34 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.
23:35 bacek_at_work I've got an idea for some internal cleanups.
23:35 bacek_at_work Let's remove "buffers" (and all related stuff). PMC and STRING are enough.
23:35 pmichaud bacek_at_work: your multis brance was awesome.  great work.
23:36 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
23:36 bacek_at_work Currently it's used in freeze/thaw only.
23:36 bacek_at_work pmichaud, I almost blindly copied stuff from rakudo :)
23:37 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 pmichaud s/sometimes/often/
23:37 bacek_at_work And create Buffer PMC with .push_byte, .encode, .decode, etc methods.
23:37 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?
23:37 bacek_at_work pmichaud, yes
23:37 pmichaud bacek_at_work: excellent.
23:37 pmichaud +1 from me, then :)
23:38 bacek_at_work It will solve few problems at once.
23:38 bacek_at_work 1) Currently "buffers" are not accessible from pir
23:38 bacek_at_work 2) There is a lot of logic in GC to handle them.
23:38 pmichaud it sounds like a nice win to me
23:38 bacek_at_work 3) "buffers" are mutable by nature. Strings are not
23:38 pmichaud gotta run -- bbl
23:38 dalek TT #1081 closed by bacek++: segfault in Parrot_HashIteratorKey_get_string
23:38 dalek TT #1081: http://trac.parrot.org/parrot/ticket/1081
23:43 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:46 cotto_work http://trac.parrot.org/parrot/ticket/655 is closed
23:49 dalek parrot: r47345 | tcurtis++ | branches/gsoc_past_optimization (2 files):
23:49 dalek parrot: Added PAST::Pattern::Op attribute exact matching.
23:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47345/
23:49 dalek parrot: r47346 | tcurtis++ | branches/gsoc_past_optimization (2 files):
23:49 dalek parrot: PAST::Pattern::Val tests for attributes matching exactly pass.
23:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47346/
23:49 jnthn bacek_at_work: See also something I started hacking up to help masak++ last night - http://github.com/rakudo/rakudo/commit/3​9bd4e0e07075d52f9d305ce7a2051eceefe99e0. 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.
23:49 jnthn bacek_at_work: But for the "look at the bytes" only case, it's more efficient than copying right off.
23:50 jnthn bacek_at_work: Didn't get very far with it yet though, and ended up with ETOOMUCHDAYJOB today.
23:51 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
23:51 whiteknight the code is all there, in any case
23:51 bacek_at_work whiteknight, it do not.
23:51 whiteknight I'm not sure I believe that. I know it used to at some point
23:52 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)
23:52 whiteknight Some point recently
23:52 jnthn We...don't trace the C stack? :-S
23:52 sorear if not the C stack, what *do* we use as roots?
23:52 sorear opbots trust jnthn
23:52 slavorgn Ok
23:52 slavorg Ok
23:53 bacek_at_work sorear, "interp"
23:54 dalek tracwiki: v15 | cotto++ | LoritoRoadmap
23:54 dalek tracwiki: put primary design questions in the approximate order they'll need to be answered
23:54 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Lor​itoRoadmap?version=15&amp;action=diff
23:55 sorear Actually, this is great.
23:55 sorear We have a _precise GC_
23:55 jnthn I thought we also had code that relied on the C stack being traced, but maybe I'm wrong.
23:55 dalek TT #655 closed by cotto++: Kill non-working GC cores
23:55 dalek TT #655: http://trac.parrot.org/parrot/ticket/655
23:56 whiteknight jnthn: I'm with you. I think bacek must be missing something
23:57 whiteknight Last time I really scrutinized the code, we were tracing it
23:58 bacek_at_work whiteknight, do you have valgrind?
23:59 bacek_at_work or gdb?
23:59 purl it has been said that gdb is the command line debugger from the gnu project (common on unix platforms)
23:59 jnthn whiteknight: I've done little Parrot core hacking for a while, it's entirely possible I'm rusty on the latest. :-)
23:59 bacek_at_work just run "hello.pir" and set breakpoint into trace_mem_block.
23:59 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".

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced