Camelia, the Perl 6 bug

IRC log for #parrot, 2010-04-23

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 allison joined #parrot
00:00 Whiteknight bacek_at_work: why do we need deep copy on immutable strings?
00:00 Whiteknight isn't that hugely wastefull?
00:01 bacek_at_work Whiteknight, It's just helper method for creating new strings.
00:02 Whiteknight so the string that gets cloned there isn't immutable?
00:03 bacek_at_work no... Original string is immutable.
00:03 bacek_at_work Cloned string - not yet.
00:06 bacek_at_work Anyway, str_clone used _only_ in charset/encoding handling. And I was too tired to clean it up.
00:11 estrabd_ joined #parrot
00:11 elmex joined #parrot
00:11 rurban_ joined #parrot
00:11 mj41_ joined #parrot
00:11 arnsholt joined #parrot
00:12 ZeroForce joined #parrot
00:12 dmagnus_ joined #parrot
00:12 mikehh_ joined #parrot
00:12 dalek joined #parrot
00:13 patspam joined #parrot
00:15 particle joined #parrot
00:15 Maddingue joined #parrot
00:19 cotto_work pmichaud++ for epic troll refutation (http://use.perl.org/~pmicha​ud/journal/40322?from=rss)
00:19 mikehh joined #parrot
00:45 dukeleto Whiteknight: i am working on a patch for what want the open opcode to do
00:47 dukeleto Whiteknight: got it working!
00:53 cotto_work sounds like you need to nopaste
00:58 abqar joined #parrot
01:03 dukeleto cotto_work: sent to the list
01:07 pmichaud cotto_work: (troll refutation)  Thanks.  :-)
01:08 sorear joined #parrot
01:15 bacek_at_work pmichaud++ # kick 'em harder!
01:16 cotto_work s/kick/educate/
01:17 bacek_at_work Ok, teach 'em by kicking! :)
01:18 tcurtis joined #parrot
01:21 dukeleto pmichaud++
01:26 cotto_work Is Rakudo building with trunk atm?
01:31 cotto_work cotto_work: no
01:31 cotto_work p6role.c:83: error: too many arguments to function ‘Parrot_str_substr’
01:33 Whiteknight yay! I've finally made a commit
01:40 cotto_work Heh.  Rakudo's only building its dynops for the C and switch runcores.
01:42 dalek parrot: r45933 | whiteknight++ | trunk/src/string/api.c:
01:42 dalek parrot: [string] a random series of small fixes and cleanups in the string api.c
01:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45933/
01:42 cotto_work The more I think about it, the more convinced I am that there's nobody who's going to miss cgoto, cgp and switch.
01:47 hercynium joined #parrot
01:52 bacek_at_work cotto_work, there is "immutable_strings" branch in rakudo.
01:58 Psyche^ joined #parrot
02:03 sorear joined #parrot
02:20 Andy joined #parrot
02:39 tetragon_ joined #parrot
03:00 janus joined #parrot
03:03 theory joined #parrot
03:17 Khisanth joined #parrot
03:52 davidfetter joined #parrot
04:08 dalek parrot: r45934 | petdance++ | trunk/src/string/encoding/ucs2.c:
04:08 dalek parrot: flag unused args
04:08 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45934/
04:34 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33393), fulltest) at r45933 - Ubuntu 10.04 RC amd64 (g++ with --optimize)
05:00 rurban_ joined #parrot
05:13 dalek parrot: r45935 | petdance++ | trunk/src/string/encoding/utf16.c:
05:13 dalek parrot: handle unused interps, and remove a block of dead code
05:13 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45935/
05:45 dalek parrot: r45936 | petdance++ | trunk/src/pmc (2 files):
05:45 dalek parrot: random consting
05:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45936/
05:49 Maddingue joined #parrot
06:27 bacek_at_work joined #parrot
06:34 uniejo joined #parrot
06:36 iblechbot joined #parrot
06:38 aukjan joined #parrot
06:58 Khisanth joined #parrot
07:14 wagle joined #parrot
07:22 fperrad joined #parrot
07:25 fperrad_ joined #parrot
07:26 dalek rakudo: 6783b52 | moritz++ | build/Makefile.in:
07:26 dalek rakudo: remove switch ops from Makefile.in. cotto++
07:26 dalek rakudo: they are about to be removed from parrot. This patch prevents build failures
07:26 dalek rakudo: when that actually happens.
07:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​783b52bd34ab2309423c054a5a0201c1761d6b4
07:40 sorear woah, blizkost works unmodified on immutable-strings parrot
08:12 slavorg joined #parrot
08:13 particle joined #parrot
08:45 dalek parrot: r45937 | fperrad++ | trunk/src/string/encoding (2 files):
08:45 dalek parrot: fix build, ISO C90 forbids mixed declarations and code
08:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45937/
08:49 smash joined #parrot
08:49 smash hello everyone
08:52 riffraff joined #parrot
09:14 slavorgn joined #parrot
09:34 dalek parrot: r45938 | gerd++ | trunk (2 files):
09:34 dalek parrot: add one news; expand the documentation of the mk_manifest_and_skip.pl script to make the use plain
09:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45938/
09:57 sorear Is it possible to extend a corepmc in a dynpmc?
09:57 sorear today, Iterator
10:04 Infinoid tomorrow, the world?
11:31 aukjan1 joined #parrot
11:32 viklund joined #parrot
11:45 viklund left #parrot
11:52 bluescreen joined #parrot
12:12 Coke sorear: sure, HLLs do that all the time.
12:14 Coke e.g. http://github.com/partcl/partcl/​blob/master/src/pmc/tclfloat.pmc
12:37 dalek digest-dynpmcs: 2ca9f4e | fperrad++ | t/digest_t.in:
12:37 dalek digest-dynpmcs: minor PIR refactor
12:37 dalek digest-dynpmcs: review: http://github.com/fperrad/digest-dynpmcs/com​mit/2ca9f4e35757c7554a4ad080ce596e52cd546710
12:37 tetragon joined #parrot
12:40 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33401), fulltest) at r45938 - Ubuntu 10.04 RC amd64 (gcc with --optimize)
12:49 Coke deleted mike3050--, spammer (@#&*$#.
12:52 darbelo joined #parrot
12:54 Mokurai1 joined #parrot
12:58 ruoso joined #parrot
13:00 rurban joined #parrot
13:02 cognominal joined #parrot
13:04 dalek tracwiki: v10 | coke++ | TracSpammers
13:04 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Tr​acSpammers?version=10&action=diff
13:05 slavorg joined #parrot
13:05 Coke hey, it's chromatic: http://cdn1.kingdomsofcamelot.com/f​b/e2/src/img/feeds/feed_marshal.jpg
13:15 Mokurai1 joined #parrot
13:21 atrodo joined #parrot
13:22 bacek o hai
13:24 JimmyZ joined #parrot
13:25 bakkdoor joined #parrot
13:26 mikehh hi bacek
13:26 bacek aloha mikehh
13:26 JimmyZ hello #parrot
13:26 plobsing joined #parrot
13:26 mikehh bacek: what's new in your parrot world?
13:27 mikehh i.e testing?
13:27 bacek mikehh, going to scrap string_consting branch... It's way too big.
13:27 bacek mikehh, nothing ready for testing yet...
13:31 mikehh ok - re-booting bbl
13:31 Coke when checking dependencies, we should be explicit about a .O depending on its own .c, yes?
13:31 patspam joined #parrot
13:31 plobsing joined #parrot
13:31 Coke (at least when not using the implicit rule)
13:35 darbelo making what is already handled correctly by implicit rules explicit doesn't sound like a win to me.
13:36 Coke darbelo: eventually we will have no implicit rules, because it doesn't handle any dependencies.
13:36 Coke we'll have auto-generated ones.
13:37 Coke sorry, any dependencies other than the one implicit one.
13:38 darbelo Oh. Auto generated rules are cool with me.
13:38 Coke but, in the mean time, if a rule is already explicit for a .o, it should mention the .c, yes?
13:38 darbelo Anything that keeps me from editing makefiles is a good thing.
13:39 darbelo Coke: probably, yes. If it's already explicit it won't hurt.
13:42 darbelo Coke: Technically, it's not necessary. But if it helps our tools, there's no harm in putting it there.
13:42 AzureStone joined #parrot
13:43 Coke no? what if the .c changes and we have an explicit rule for the .o that doesn't depend on the .c?
13:43 Coke does the implicit rule cover that?
13:44 darbelo AFAIK, yes. you can have several 'rules' specifying the deps of a target and make will 'merge them' for you.
13:48 Coke must have added a few explicit ones incorrectly during the last cleanup. fixing...
13:49 darbelo Unless the explicit rule is more than a simple dep specification.
13:49 darbelo file.o: file.c
13:49 darbelo command file.c > file.o
13:50 darbelo would 'override' the implicit rule and *I think* would need to have the .c listed.
13:52 darbelo But I don't know how cross-platform that is. The only make I'm really familiar with is BSD.
14:04 Coke Then I will probably err on the side of overspecification.
14:07 darbelo My rule of thumb is to never assume make will do the right thing.
14:07 Coke heh
14:15 davidfetter joined #parrot
14:17 * cotto_work yawns
14:19 mikehh joined #parrot
14:28 darbelo Is anyone else seeing failures in t/compilers/imcc/syn/regressions.t?
14:29 cotto_work wfm if I run it with prove
14:29 darbelo IMCC sefaults on my box.
14:30 cotto_work That's the expected behavior.
14:30 cotto_work You need a better computer.
14:31 nopaste "darbelo" at 192.168.1.3 pasted ""IMCC segfault on OpenBSD amd64"" (22 lines) at http://nopaste.snit.ch/20342
14:32 darbelo It could be happening since a long time ago. I haven't built parrot on amd64 in a while.
14:33 cotto_work Do you have the patience to bisect?
14:34 cotto_work http://search.cpan.org/~infinoid/​App-SVN-Bisect-0.9/bin/svn-bisect
14:34 darbelo Not really. I'll try debugging it first.
14:34 cotto_work http://search.cpan.org/~infinoid/App-​SVN-Bisect-1.0/lib/App/SVN/Bisect.pm
14:37 bubaflub joined #parrot
14:39 bluescreen joined #parrot
14:40 theory joined #parrot
14:47 * darbelo chuckles after reading the test file
14:47 darbelo TT #641
15:10 Andy joined #parrot
15:17 JimmyZ joined #parrot
15:36 dukeleto trac is getting spammed again
15:37 dukeleto some looks to have taken care of it. them++
15:37 Coke mike3050? he's dead.
15:37 Coke er, gone.
15:38 atrodo karma them
15:38 purl them has karma of 4
15:38 dukeleto Coke++
15:38 darbelo karma everyone
15:38 purl everyone has karma of 20
15:38 dukeleto i met the guy who works on this last night: http://github.com/jvoorhis/ruby-llvm
15:39 dukeleto looks like maybe there are some things for Parrot to learn from ruby-llvm
15:39 * JimmyZ still can't build parrot because of TT#888
15:39 Coke checking...
15:40 Coke JimmyZ: I'll try to fix that this weekend if no one beats me to it.
15:40 Coke (claiming ticket so I don't forget.)
15:41 JimmyZ Coke++, thanks.
15:41 Mokurai joined #parrot
16:03 darbelo Huh? The SymReg chain is two links shorter than it should be.
16:03 darbelo I wonder how that happened.
16:03 * Coke whistles innocently.
16:21 sri dukeleto: http://rubini.us # this seems to be more interesting when it comes to ruby on llvm
16:23 dukeleto sri: both of those projects are local to Portland, OR
16:23 dukeleto sri: it seems that Portland has lots of VM hackers
16:23 sri haha
16:24 * dukeleto lives in PDX as well
16:40 rbuels joined #parrot
16:45 whiteknight joined #parrot
16:46 nopaste "darbelo" at 192.168.1.3 pasted "Look ma! I can screw up the stack!" (51 lines) at http://nopaste.snit.ch/20343
16:52 particle darbelo: nice trick. now make it come back.
16:53 nopaste "darbelo" at 192.168.1.3 pasted "Done ;)" (13 lines) at http://nopaste.snit.ch/20344
16:56 darbelo I find it surprising that the compiler would place the pointer *after* the array in the stack.
16:56 darbelo I expected it to be smarter than that.
17:15 darbelo OTOH, he probably wasn't expecting us to write past the end of the array.
17:15 darbelo It expected us to be smarted than that...
17:16 brrant joined #parrot
17:29 nopaste "darbelo" at 192.168.1.3 pasted "Fine, fine. I'll solve it for real now." (42 lines) at http://nopaste.snit.ch/20345
17:30 darbelo Anyone care to +/-1 http://nopaste.snit.ch/20345 ?
17:31 aukjan joined #parrot
17:32 Coke darbelo: why are there 2 constants that seem to be multiples?
17:33 darbelo The old magic numbers were multiples?
17:35 darbelo Or maybe I should keep MAX_KEY_LEN at 21.
17:36 darbelo The upside is whatever size we pick now we know it won't trample the stack :)
17:38 japhb joined #parrot
17:39 ZeroForce joined #parrot
17:41 particle darbelo: looks good here, but that imcc error message stinks. even a well placed colon would make it better
17:41 cotto_work just going to say that
17:42 cotto_work either that or translate it into very very rude Russian
17:43 darbelo I'll leave that to bacek.
17:45 darbelo "Key too long; increase MAX_KEY_LEN.\n"?
17:47 cotto_work Why not.  If someone wants keys that long I don't feel too bad telling them to recompile Parrot.
17:49 Coke that's the current behavior. =-)
17:51 cotto_work That fact ipso facto doesn't necessarily make it a good idea.
17:52 darbelo It's a fixed-size buffer on the stack. There's not much you can do about it's size at runtime.
17:53 darbelo Of course, we could allocate it dynamically, but that would undo the hard work of previous optimizers.
17:53 cotto_work the premature ones?
17:55 darbelo Previous, premature, precognizant, I don't know, English is only my fourth language.
17:55 Coke ORLY?
17:55 purl YA RLY.
17:57 darbelo Coke: Yeah, I speak rude spanish, very rude spanish, incredibly rude spanish, english.
17:57 darbelo Back to the patch, I'm willing to assert that if you are nesting stuff 10 levels deep you are very likely to be doing *something* wrong.
17:58 cotto_work +1.  Apply it and move on to something of equal or greater awesomeness.
18:03 * atrodo now hates parsing fortran
18:03 atrodo Maybe I should move on to parsing c.  That should be easier.
18:06 NotFound darbelo: not so hard, this is the second bug in that piece of code in few time.
18:07 darbelo NotFound: Technically, I think it's the same bug ;)
18:07 darbelo It just manifests on OpenBSD/amd64 due to stack weirdness.
18:08 NotFound darbelo: colloquialy, is optimized for bugability ;)
18:09 darbelo Who cares if it's wrong? It's *fast*.
18:10 darbelo Do you think ferrari owners complain whe the car doesn't steer? No! They just accelerate more and crash hard.
18:10 NotFound darbelo: I knew a guy that optimized for speed a key waiting loop.
18:11 darbelo "Nobody waits faster!" makes for a wonderful slogan.
18:11 dukeleto darbelo++ # /me appreciates your work on openbsd
18:11 particle c has ambiguities in parsing.
18:12 dukeleto atrodo: where is your fortran parsing code?
18:12 NotFound I knew we need a good PR
18:14 atrodo dukeleto> http://github.com/atrodo/draak .  I'm getting a lot of parsing done, but the "Whitespace is insignificant" rule of fortran is slowing me down a lot
18:15 atrodo http://github.com/atrodo/dr​aak/blob/master/gmr/FOR.gmr is the actual parsing rules
18:18 dukeleto atrodo: good stuff
18:18 NotFound Withespace is infignificant next to the power of theForcetran.
18:20 dalek parrot: r45939 | darbelo++ | trunk/compilers/imcc/pbc.c:
18:20 dalek parrot: Rename KEYLEN to MAX_KEY_LEN and use to indicate actual key length instead of available buffer space and make key[] big enough to *always* hold MAX_KEY_LEN items.
18:20 dalek parrot: This fixes the stack corruption issues in OpenBSD/amd64.
18:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45939/
18:21 atrodo NotFound++ ; I have yet to figure out what theForcetran is, and why it makes whitespace insignifcant
18:22 NotFound atrodo: sometimes I don't even understand myself.
18:34 * darbelo ponders the dark side of the punch card.
18:36 dalek parrot: r45940 | darbelo++ | trunk/t/compilers/imcc/syn/regressions.t:
18:37 dalek parrot: Update t/compilers/imcc/syn/regressions.t after r45939.
18:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45940/
18:37 dalek parrot: r45941 | fperrad++ | trunk (2 files):
18:37 dalek parrot: [GzipHandle] implements it
18:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45941/
18:38 ttbot Parrot trunk/ r45941 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/276432.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
18:42 ttbot Parrot trunk/ r45942 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/276448.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
18:44 jan joined #parrot
18:53 dalek parrot: r45942 | fperrad++ | trunk/runtime/parrot/library (2 files):
18:53 dalek parrot: [TAP] use GzipHandle PMC (instead of gzip)
18:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45942/
19:03 joeri joined #parrot
19:21 cotto_work joined #parrot
19:25 dalek parrot: r45943 | fperrad++ | trunk/src/dynpmc/gziphandle.pmc:
19:25 dalek parrot: [GzipHandle] fix build with gcc 4.4.1
19:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45943/
19:25 dalek parrot: r45944 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
19:25 dalek parrot: [distutils] use GzipHandle PMC (instead of gzip),
19:25 dalek parrot: remove target sdist_bztar which uses bzip2
19:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45944/
19:25 fperrad joined #parrot
19:26 lucian joined #parrot
19:27 dalek TT #515 reopened by coke++: Remove old parrot versions from CPAN
19:27 dalek TT #515: http://trac.parrot.org/parrot/ticket/515
19:35 sorear Coke: I think I've found the problem.  $PREFIX/src/parrot/2.3.0-devel/pmc - there's a finite set of PMCs which HLLs are allowed to extend, and Iterator isn't one of them
19:35 sorear Why?
19:36 Coke typo.
19:36 Coke all core pmcs should be put out there, I imagine.
19:38 NotFound iterator isn't used directly, is just a base for the iterators, isn't it?
19:38 sorear atrodo: You're not using PCT/PGE?
19:39 cotto_work We're not Apple.  He doesn't have to use our tools. ;)
19:39 Coke NotFound: you should still be able to extend it.
19:39 Coke unless I'm missing something in the new (last year) iterator world.
19:39 sorear cotto_work: No, but our tools are supposed to be better than the competition
19:39 sorear That's what makes us Parrot
19:40 sorear Coke: there are 83 *.pmc files in src/pmc/; 15 *.dump files are installed
19:40 sorear Coke: pretty big typo
19:40 NotFound Coke: by 'HLL are allowed to' I understood to HLLmap it.
19:40 darbelo sorear: Pfft. I've seen 'em bigger.
19:40 Coke NotFound: two different things.
19:41 Coke often hllmap'd versions extend their core counterparts.
19:41 Coke (always?)
19:41 Coke (all of tcl's do, anyway)
19:42 NotFound As far as I know there is no difference between extending in a HLL and extending in parrot space.,
19:42 Coke right. but if that stuff isn't installed, you can't do it.
19:43 NotFound iterator isn't installed?
19:43 darbelo NotFound: The .dump files aren't.
19:44 NotFound Now I see it.
19:44 Coke sounds like a bug to me. +1 on fixing that.
19:44 * Coke ponders combining the -dev and -tickets lists. :P
19:45 NotFound +1
19:45 purl 1
19:45 moritz Coke: please don't
19:45 moritz Coke: I've only subscribed the -dev list
19:46 moritz the -tickets are so uninformative: many lines of header, most of which haven't changed since the last mail on the same ticket
19:46 Andy Yeah, I would cry.
19:47 Coke was just looking for a cheap solution to "get more people looking at tickets."
19:47 Coke guess that's too cheap. Hokay.
19:47 Andy s/looking at/caring about/
19:47 NotFound Coke: make an iphone app X-)
19:47 cotto_work make ticket email less useless?
19:47 NotFound iLookTickets
19:47 Coke cotto_work: ?
19:48 Coke NotFound: oh, just a generic trac client for the phone?
19:48 Coke I am not sure that's at all useful. =-)
19:48 cotto_work having a diff when someone makes a change instead of showing the old and new versions would be a huge improvement
19:49 NotFound Coke: that's no reason to not try to sell it X-)
19:49 Coke cotto_work: given how infrequently the summary is changed, meh.
19:49 cotto_work not sending out a message for trivial changes would also be nice
19:55 atrodo sorear> No, I'm using what I got and know.  Still have to figure out how to make the jump to generating pbc's
19:56 darbelo atrodo: The pbc format is pretty volatile. Better to emit PIR/PASM.
19:56 Coke I wouldn't say it's volatile.
19:56 Coke i would say it's hard to target, though.
19:57 darbelo Coke: How often do we need to regenerate our pbcs?
19:57 NotFound const volatile
19:58 atrodo darbelo> That's the question.  Do I just emit PIR/PASM, or do I embed a version of parrot that ends up emitting the pbc.  Either way, the end result is a pbc
19:59 Coke you're going to have (atm) regen PBC whenever some set of things occurs. (different core pmc list, op list...)
19:59 darbelo atrodo: I'd go for emitting PIR.
19:59 Coke so I would just emit PIR (not PASM) and use whatever parrot is handy to run it.
20:00 atrodo Well, the other half of the problem is my current macro system that generates output is, well, it sucks
20:00 atrodo so replacing it is also on the list
20:00 purl okay, atrodo.
20:01 atrodo replacing it?
20:01 atrodo so replacing it?
20:01 purl somebody said so replacing it was trivial or on the list
20:03 Spreadsheet_ joined #parrot
20:11 tcurtis joined #parrot
20:23 Coke forget replacing it
20:23 purl Coke, I didn't have anything matching replacing it
20:23 Coke forget replacing it?
20:23 purl Coke, I didn't have anything matching replacing it
20:23 Coke boggle.
20:23 darbelo forget so replacing it
20:23 purl darbelo: I forgot so replacing it
20:23 * Coke re-reads.
20:23 Coke OH.
20:37 sorear Coke: Should I file a ticket for extends Iterator?
20:39 cotto_work anyone have thoughts on merging the runcore_purge branch?
20:40 darbelo +1
20:40 purl 1
20:40 sorear +1 it'll make fulltest faster
20:40 darbelo Code-wise, anything with the word 'purge' on it has my aproval.
20:41 cotto_work svn cp https://svn.parrog.org/parrot/trunk https://svn.parrot.org/parro​t/branches/everything_purge
20:41 darbelo svn rm https://svn.parrot.org/parrot​/branches/everything_purge/*
20:42 darbelo svn merge https://svn.parrot.org/parro​t/branches/everything_purge/ .
20:42 darbelo svn ci
20:42 cotto_work -m "Everyone go find another project.  We're optimal."
20:45 Coke sorear: yes, please.
20:45 cotto_work seen allison
20:45 purl allison was last seen on #parrot 2 days, 41 minutes and 0 seconds ago, saying: is anyone else having trouble getting in to the conf call?  [Apr 21 20:04:32 2010]
20:45 cotto_work seen the architect
20:47 Coke I am the Architect. I created the matrix. I've been waiting for you. You have many questions, and although the process has altered your consciousness, you remain irrevocably human. Ergo, some of my answers you will understand, and some of them you will not. Concordantly, while your first question may be the most pertinent, you may or may not realize it is also irrelevant.
20:47 dalek parrot: r45945 | fperrad++ | trunk (6 files):
20:47 dalek parrot: [test] generate valid TAP comment (ie. with # in first column)
20:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45945/
20:51 Coke msg fperrard - anything that's doing a print "#" for comments should probably just be using diag, no?
20:51 purl Sorry, I've never seen fperrard before.
20:52 Coke msg fperrad - anything that's doing a print "#" for comments should probably just be using diag, no? (I see some were converted to diag, but not all)
20:52 purl Message for fperrad stored.
20:55 sorear Is MANIFEST.generated a generated file?
20:55 Coke no.
20:55 sorear ok, it's just out of date then.
20:56 sorear that's weird, attempting to log in to parrot-trac has no effect
20:56 * Coke wonders why we're installing a private .h file from src/
20:57 Coke sorear: WFM.
20:57 cotto_work sorear: you may need to refresh
21:00 rurban_ joined #parrot
21:02 dalek tracwiki: v12 | coke++ | DevelopmentPriorities
21:02 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Develop​mentPriorities?version=12&action=diff
21:02 dalek tracwiki: v166 | coke++ | WikiStart
21:02 dalek tracwiki: remove old priorities section.
21:02 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​ikiStart?version=166&action=diff
21:03 sorear ah, I'm in
21:03 sorear the solution involved activating the Parrot logo link
21:03 cotto_work s/2\.0/3\.0/g and it still makes sense.
21:06 dalek TT #1578 created by sorear++: Iterator.dump (among others) not installed
21:06 dalek TT #1578: http://trac.parrot.org/parrot/ticket/1578
21:23 NotFound t/dynpmc/gziphandle.t                     (Wstat: 0 Tests: 2 Failed: 0)
21:23 NotFound Parse errors: Bad plan.  You planned 3 tests but ran 2.
21:30 cotto_work are there any hlls other than rakudo that use dynops?
21:33 sorear this is interesting
21:33 sorear is there a way to propagate #includes into pmc*.h ?
21:34 Mokurai joined #parrot
21:36 dalek parrot: r45946 | NotFound++ | trunk/t/dynpmc/gziphandle.t:
21:36 dalek parrot: keep num of tests and skipped tests in sync
21:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45946/
21:36 cotto_work sorear: I don't understand your question.
21:39 cotto_work what are you trying to accomplish?
21:39 sorear cotto_work: suppose I'm writing PMCs which interface with external libraries
21:39 sorear suppose these external libraries use typedefs
21:39 sorear in the .pmc, I can say
21:39 sorear #include <perl.h>
21:39 sorear pmclass ... {
21:39 sorear SV *sv_attr;
21:39 sorear ...
21:39 sorear }
21:40 cotto_work not unlike the recently checked-in gziphandle pmc?
21:40 sorear however, the #include never makes it into blizkost_group.c
21:40 sorear so... I get a syntax error
21:40 sorear this would be fixed if the #include made it into pmc_whatever.h
21:40 sorear if I could get it into, that is
21:41 cotto_work blizkost?
21:41 purl blizkost is http://github.com/jnthn/blizkost/tree/master or the last Jonathan's project, an embedding of Perl 5 in Perl 6
21:41 sorear gzip_handle doesn't have any attributes
21:41 sorear yes
21:41 sorear *GzipHandle
21:42 NotFound sorear: if we put foreign includes in .h files we'll run into all sorts of name collisions.
21:44 sorear no worse than putting them into the .pmc ...  and I'm asking if this is an existing feature, not requesting one
21:45 bubaflub joined #parrot
21:45 NotFound sorear: in the pmc is the pmc business. In a header than can included by other components, the problem expands.
21:48 sorear interesting
21:49 sorear this is... not an easy problem
21:49 sorear since the alternative is to break encapsulation and directly talk about struct sv
21:50 cotto_work We'll have to solve it one way or another.  Blizkost is valuable.
21:51 sorear struct sv works for now
21:51 sorear they might break it in perl 5.16
21:52 sorear (of course, the real solution is to reimplement Parrot in a less braindead language...)
21:52 sorear (and the rest of the world...)
21:52 NotFound Why the group file needs the include? I never looked at dynpmc handling
21:53 cotto_work sorear: less braindead than c?
21:56 sorear the include declares the vtables and class init functions
21:56 sorear the group file declares the function loadlib actually calls, which needs to call the class init functions
21:57 sorear cotto_work: yes.  I'd love to see one
21:57 cotto_work That's the plan.  We just have to implement it first.
22:03 NotFound sorear: to declare a function you don't need whatever that function calls
22:03 sorear NotFound: it's a monolithic header
22:07 NotFound PARROT_DYNEXT_EXPORT Parrot_PMC Parrot_lib_blizkost_group_load(PARROT_INTERP); ?
22:16 Coke cotto_work: partcl original uses dynops.
22:17 cotto_work do we care about it?
22:17 sorear NotFound: yes
22:18 sorear Are dynops on the chopping block? :(
22:18 cotto_work no.  just the non-C runcores
22:18 cotto_work switch, cgoto and cgp
22:18 NotFound I see the problem now... is not the group file, but the .h itself.
22:18 davidfetter joined #parrot
22:21 Coke seen sfink?
22:21 purl I haven't seen 'sfink', Coke
22:21 cotto_work Only a fairly small change to the build is needed for HLLs that use dynops.
22:23 Coke happy to give someone a commit bit on partcl to fix it. Same terms as parrot itself.
22:27 NotFound There is no easy solution. All times we had a problem like that we used the 'struct .... *' solution.
22:28 sorear Coke: does that refer to licensing, or to the Parrot Contributor Agreement?
22:29 NotFound sorear: the ugly workaround is to use void * and a lot of casts.
22:35 Coke sorear: copyright, license and CLA.
22:38 tcurtis joined #parrot
22:42 Spreadsheet_ left #parrot
23:00 dalek rakudo: 7a1409b | jonathan++ | src/glue/subset.pm:
23:00 dalek rakudo: Fix subset types involving subset foo of Mu.
23:00 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​a1409ba2ec8753478d8b7e6fb79f087eb344856
23:00 dalek rakudo: 2405a0b | jonathan++ | src/Perl6/Actions.pm:
23:00 dalek rakudo: Fix a tricky init ordering issue that meant we could not use where clauses in parametric role signatures.
23:00 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​405a0bca019886df80e37db4a2382ac77636f66
23:00 dalek rakudo: a1159c7 | jonathan++ | src/Perl6/ (2 files):
23:00 dalek rakudo: Rework our handling of blocks and their interaction with packages somewhat. We were running into problems with parametric role signature variables ending up with the wrong scoping. This replaces the buggy fix I put in yesterday. We do diverge from STD, but STD gets this wrong also at the moment.
23:00 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​1159c7029e1b784ba9f9d626a8c4577227ce67d
23:01 iblechbot joined #parrot
23:03 tetragon joined #parrot
23:21 Coke msg chromatic - at least it isn't perl 6 slashFic.
23:21 purl Message for chromatic stored.
23:30 dalek parrot: r45947 | coke++ | trunk/tools/dev/checkdepend.pl:
23:30 dalek parrot: Require this dep all the time (even though we only need it some of the time)
23:30 dalek parrot: When this turns into 'make depend', it won't matter.
23:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45947/

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

Parrot | source cross referenced