Parrot 2.3.0 Released | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: apply deprecations, merge branches | Review and vote GSoC applications
Set by moderator on 20 April 2010.
00:00 allison joined
Whiteknight bacek_at_work: why do we need deep copy on immutable strings? 00:00
isn't that hugely wastefull?
bacek_at_work Whiteknight, It's just helper method for creating new strings. 00:01
Whiteknight so the string that gets cloned there isn't immutable? 00:02
bacek_at_work no... Original string is immutable. 00:03
Cloned string - not yet.
Anyway, str_clone used _only_ in charset/encoding handling. And I was too tired to clean it up. 00:06
00:11 estrabd_ joined, elmex joined, rurban_ joined, mj41_ joined, arnsholt joined 00:12 ZeroForce joined, dmagnus_ joined, mikehh_ joined, dalek joined 00:13 patspam joined 00:15 particle joined, Maddingue joined
cotto_work pmichaud++ for epic troll refutation (use.perl.org/~pmichaud/journal/40322?from=rss) 00:19
00:19 mikehh joined
dukeleto Whiteknight: i am working on a patch for what want the open opcode to do 00:45
Whiteknight: got it working! 00:47
cotto_work sounds like you need to nopaste 00:53
00:58 abqar joined
dukeleto cotto_work: sent to the list 01:03
pmichaud cotto_work: (troll refutation) Thanks. :-) 01:07
01:08 sorear joined
bacek_at_work pmichaud++ # kick 'em harder! 01:15
cotto_work s/kick/educate/ 01:16
bacek_at_work Ok, teach 'em by kicking! :) 01:17
01:18 tcurtis joined
dukeleto pmichaud++ 01:21
cotto_work Is Rakudo building with trunk atm? 01:26
cotto_work: no 01:31
p6role.c:83: error: too many arguments to function ‘Parrot_str_substr’
Whiteknight yay! I've finally made a commit 01:33
cotto_work Heh. Rakudo's only building its dynops for the C and switch runcores. 01:40
dalek rrot: r45933 | whiteknight++ | trunk/src/string/api.c:
[string] a random series of small fixes and cleanups in the string api.c
 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
bacek_at_work cotto_work, there is "immutable_strings" branch in rakudo. 01:52
01:58 Psyche^ joined 02:03 sorear joined 02:20 Andy joined 02:39 tetragon_ joined 03:00 janus joined 03:03 theory joined 03:17 Khisanth joined 03:52 davidfetter joined
dalek rrot: r45934 | petdance++ | trunk/src/string/encoding/ucs2.c:
flag unused args
 04:08
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33393), fulltest) at r45933 - Ubuntu 10.04 RC amd64 (g++ with --optimize) 04:34
05:00 rurban_ joined
dalek rrot: r45935 | petdance++ | trunk/src/string/encoding/utf16.c:
handle unused interps, and remove a block of dead code
 05:13
rrot: r45936 | petdance++ | trunk/src/pmc (2 files):
random consting
 05:45
05:49 Maddingue joined 06:27 bacek_at_work joined 06:34 uniejo joined 06:36 iblechbot joined 06:38 aukjan joined 06:58 Khisanth joined 07:14 wagle joined 07:22 fperrad joined 07:25 fperrad_ joined
dalek kudo: 6783b52 | moritz++ | build/Makefile.in:
remove switch ops from Makefile.in. cotto++

when that actually happens.		 07:26
sorear woah, blizkost works unmodified on immutable-strings parrot 07:40
08:12 slavorg joined 08:13 particle joined
dalek rrot: r45937 | fperrad++ | trunk/src/string/encoding (2 files):
fix build, ISO C90 forbids mixed declarations and code
 08:45
08:49 smash joined
smash hello everyone 08:49
08:52 riffraff joined 09:14 slavorgn joined
dalek rrot: r45938 | gerd++ | trunk (2 files):
add one news; expand the documentation of the mk_manifest_and_skip.pl script to make the use plain
 09:34
sorear Is it possible to extend a corepmc in a dynpmc? 09:57
today, Iterator
Infinoid tomorrow, the world? 10:04
11:31 aukjan1 joined 11:32 viklund joined 11:45 viklund left 11:52 bluescreen joined
Coke sorear: sure, HLLs do that all the time. 12:12
e.g. github.com/partcl/partcl/blob/maste...lfloat.pmc 12:14
dalek gest-dynpmcs: 2ca9f4e | fperrad++ | t/digest_t.in:
minor PIR refactor
 12:37
12:37 tetragon joined
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:40
Coke deleted mike3050--, spammer (@#&*$#. 12:49
12:52 darbelo joined 12:54 Mokurai1 joined 12:58 ruoso joined 13:00 rurban joined 13:02 cognominal joined
dalek tracwiki: v10 | coke++ | TracSpammers 13:04
tracwiki: trac.parrot.org/parrot/wiki/TracSpa...ction=diff
13:05 slavorg joined
Coke hey, it's chromatic: cdn1.kingdomsofcamelot.com/fb/e2/sr...arshal.jpg 13:05
13:15 Mokurai1 joined 13:21 atrodo joined
bacek o hai 13:22
13:24 JimmyZ joined 13:25 bakkdoor joined
mikehh hi bacek 13:26
bacek aloha mikehh
JimmyZ hello #parrot
13:26 plobsing joined
mikehh bacek: what's new in your parrot world? 13:26
i.e testing? 13:27
bacek mikehh, going to scrap string_consting branch... It's way too big.
mikehh, nothing ready for testing yet...
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, plobsing joined
Coke (at least when not using the implicit rule) 13:31
darbelo making what is already handled correctly by implicit rules explicit doesn't sound like a win to me. 13:35
Coke darbelo: eventually we will have no implicit rules, because it doesn't handle any dependencies. 13:36
we'll have auto-generated ones.
sorry, any dependencies other than the one implicit one. 13:37
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?
darbelo Anything that keeps me from editing makefiles is a good thing.
Coke: probably, yes. If it's already explicit it won't hurt. 13:39
Coke: Technically, it's not necessary. But if it helps our tools, there's no harm in putting it there. 13:42
13:42 AzureStone joined
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
does the implicit rule cover that?
darbelo AFAIK, yes. you can have several 'rules' specifying the deps of a target and make will 'merge them' for you. 13:44
Coke must have added a few explicit ones incorrectly during the last cleanup. fixing... 13:48
darbelo Unless the explicit rule is more than a simple dep specification. 13:49
file.o: file.c
command file.c > file.o
would 'override' the implicit rule and *I think* would need to have the .c listed. 13:50
But I don't know how cross-platform that is. The only make I'm really familiar with is BSD. 13:52
Coke Then I will probably err on the side of overspecification. 14:04
darbelo My rule of thumb is to never assume make will do the right thing. 14:07
Coke heh
14:15 davidfetter joined
cotto_work yawns 14:17
14:19 mikehh joined
darbelo Is anyone else seeing failures in t/compilers/imcc/syn/regressions.t? 14:28
cotto_work wfm if I run it with prove 14:29
darbelo IMCC sefaults on my box.
cotto_work That's the expected behavior. 14:30
You need a better computer.
nopaste "darbelo" at 192.168.1.3 pasted ""IMCC segfault on OpenBSD amd64"" (22 lines) at nopaste.snit.ch/20342 14:31
darbelo It could be happening since a long time ago. I haven't built parrot on amd64 in a while. 14:32
cotto_work Do you have the patience to bisect? 14:33
search.cpan.org/~infinoid/App-SVN-B...svn-bisect 14:34
darbelo Not really. I'll try debugging it first.
cotto_work search.cpan.org/~infinoid/App-SVN-B.../Bisect.pm
14:37 bubaflub joined 14:39 bluescreen joined 14:40 theory joined
darbelo chuckles after reading the test file 14:47
TT #641
15:10 Andy joined 15:17 JimmyZ joined
dukeleto trac is getting spammed again 15:36
some looks to have taken care of it. them++ 15:37
Coke mike3050? he's dead.
er, gone.
atrodo karma them 15:38
purl them has karma of 4
dukeleto Coke++
darbelo karma everyone
purl everyone has karma of 20
dukeleto i met the guy who works on this last night: github.com/jvoorhis/ruby-llvm
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
Coke checking...
JimmyZ: I'll try to fix that this weekend if no one beats me to it. 15:40
(claiming ticket so I don't forget.)
JimmyZ Coke++, thanks. 15:41
15:41 Mokurai joined
darbelo Huh? The SymReg chain is two links shorter than it should be. 16:03
I wonder how that happened.
Coke whistles innocently.
sri dukeleto: rubini.us # this seems to be more interesting when it comes to ruby on llvm 16:21
dukeleto sri: both of those projects are local to Portland, OR 16:23
sri: it seems that Portland has lots of VM hackers
sri haha
dukeleto lives in PDX as well 16:24
16:40 rbuels joined 16:45 whiteknight joined
nopaste "darbelo" at 192.168.1.3 pasted "Look ma! I can screw up the stack!" (51 lines) at nopaste.snit.ch/20343 16:46
particle darbelo: nice trick. now make it come back. 16:52
nopaste "darbelo" at 192.168.1.3 pasted "Done ;)" (13 lines) at nopaste.snit.ch/20344 16:53
darbelo I find it surprising that the compiler would place the pointer *after* the array in the stack. 16:56
I expected it to be smarter than that.
OTOH, he probably wasn't expecting us to write past the end of the array. 17:15
It expected us to be smarted than that...
17:16 brrant joined
nopaste "darbelo" at 192.168.1.3 pasted "Fine, fine. I'll solve it for real now." (42 lines) at nopaste.snit.ch/20345 17:29
darbelo Anyone care to +/-1 nopaste.snit.ch/20345 ? 17:30
17:31 aukjan joined
Coke darbelo: why are there 2 constants that seem to be multiples? 17:32
darbelo The old magic numbers were multiples? 17:33
Or maybe I should keep MAX_KEY_LEN at 21. 17:35
The upside is whatever size we pick now we know it won't trample the stack :) 17:36
17:38 japhb joined 17:39 ZeroForce joined
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
either that or translate it into very very rude Russian 17:42
darbelo I'll leave that to bacek. 17:43
"Key too long; increase MAX_KEY_LEN.\\n"? 17:45
cotto_work Why not. If someone wants keys that long I don't feel too bad telling them to recompile Parrot. 17:47
Coke that's the current behavior. =-) 17:49
cotto_work That fact ipso facto doesn't necessarily make it a good idea. 17:51
darbelo It's a fixed-size buffer on the stack. There's not much you can do about it's size at runtime. 17:52
Of course, we could allocate it dynamically, but that would undo the hard work of previous optimizers. 17:53
cotto_work the premature ones?
darbelo Previous, premature, precognizant, I don't know, English is only my fourth language. 17:55
Coke ORLY?
purl YA RLY.
darbelo Coke: Yeah, I speak rude spanish, very rude spanish, incredibly rude spanish, english. 17:57
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.
cotto_work +1. Apply it and move on to something of equal or greater awesomeness. 17:58
atrodo now hates parsing fortran 18:03
Maybe I should move on to parsing c. That should be easier.
NotFound darbelo: not so hard, this is the second bug in that piece of code in few time. 18:06
darbelo NotFound: Technically, I think it's the same bug ;) 18:07
It just manifests on OpenBSD/amd64 due to stack weirdness.
NotFound darbelo: colloquialy, is optimized for bugability ;) 18:08
darbelo Who cares if it's wrong? It's *fast*. 18:09
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.
darbelo "Nobody waits faster!" makes for a wonderful slogan. 18:11
dukeleto darbelo++ # /me appreciates your work on openbsd
particle c has ambiguities in parsing.
dukeleto atrodo: where is your fortran parsing code? 18:12
NotFound I knew we need a good PR
atrodo dukeleto> 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:14
github.com/atrodo/draak/blob/master/gmr/FOR.gmr is the actual parsing rules 18:15
dukeleto atrodo: good stuff 18:18
NotFound Withespace is infignificant next to the power of theForcetran.
dalek rrot: r45939 | darbelo++ | trunk/compilers/imcc/pbc.c:
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
atrodo NotFound++ ; I have yet to figure out what theForcetran is, and why it makes whitespace insignifcant 18:21
NotFound atrodo: sometimes I don't even understand myself. 18:22
darbelo ponders the dark side of the punch card. 18:34
dalek rrot: r45940 | darbelo++ | trunk/t/compilers/imcc/syn/regressions.t:
Update t/compilers/imcc/syn/regressions.t after r45939.
 18:36
rrot: r45941 | fperrad++ | trunk (2 files):
[GzipHandle] implements it
ttbot Parrot trunk/ r45941 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/276432.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 18:38
Parrot trunk/ r45942 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/276448.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 18:42
18:44 jan joined
dalek rrot: r45942 | fperrad++ | trunk/runtime/parrot/library (2 files):
[TAP] use GzipHandle PMC (instead of gzip)
 18:53
19:03 joeri joined 19:21 cotto_work joined
dalek rrot: r45943 | fperrad++ | trunk/src/dynpmc/gziphandle.pmc:
[GzipHandle] fix build with gcc 4.4.1
 19:25
rrot: r45944 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] use GzipHandle PMC (instead of gzip),
19:25 fperrad joined 19:26 lucian joined
dalek TT #515 reopened by coke++: Remove old parrot versions from CPAN 19:27
TT #515: trac.parrot.org/parrot/ticket/515
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
Why?
Coke typo. 19:36
all core pmcs should be put out there, I imagine.
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?
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.
unless I'm missing something in the new (last year) iterator world.
sorear cotto_work: No, but our tools are supposed to be better than the competition
That's what makes us Parrot
Coke: there are 83 *.pmc files in src/pmc/; 15 *.dump files are installed 19:40
Coke: pretty big typo
NotFound Coke: by 'HLL are allowed to' I understood to HLLmap it.
darbelo sorear: Pfft. I've seen 'em bigger.
Coke NotFound: two different things.
often hllmap'd versions extend their core counterparts. 19:41
(always?)
(all of tcl's do, anyway)
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.
NotFound iterator isn't installed? 19:43
darbelo NotFound: The .dump files aren't.
NotFound Now I see it. 19:44
Coke sounds like a bug to me. +1 on fixing that.
Coke ponders combining the -dev and -tickets lists. :P
NotFound +1 19:45
purl 1
moritz Coke: please don't
Coke: I've only subscribed the -dev list
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.
Coke was just looking for a cheap solution to "get more people looking at tickets." 19:47
guess that's too cheap. Hokay.
Andy s/looking at/caring about/
NotFound Coke: make an iphone app X-)
cotto_work make ticket email less useless?
NotFound iLookTickets
Coke cotto_work: ?
NotFound: oh, just a generic trac client for the phone? 19:48
I am not sure that's at all useful. =-)
cotto_work having a diff when someone makes a change instead of showing the old and new versions would be a huge improvement
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.
cotto_work not sending out a message for trivial changes would also be nice
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:55
darbelo atrodo: The pbc format is pretty volatile. Better to emit PIR/PASM. 19:56
Coke I wouldn't say it's volatile.
i would say it's hard to target, though.
darbelo Coke: How often do we need to regenerate our pbcs? 19:57
NotFound const volatile
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:58
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.
Coke so I would just emit PIR (not PASM) and use whatever parrot is handy to run it.
atrodo Well, the other half of the problem is my current macro system that generates output is, well, it sucks 20:00
so replacing it is also on the list
purl okay, atrodo.
atrodo replacing it? 20:01
so replacing it?
purl somebody said so replacing it was trivial or on the list
20:03 Spreadsheet_ joined 20:11 tcurtis joined
Coke forget replacing it 20:23
purl Coke, I didn't have anything matching replacing it
Coke forget replacing it?
purl Coke, I didn't have anything matching replacing it
Coke boggle.
darbelo forget so replacing it
purl darbelo: I forgot so replacing it
Coke re-reads.
OH.
sorear Coke: Should I file a ticket for extends Iterator? 20:37
cotto_work anyone have thoughts on merging the runcore_purge branch? 20:39
darbelo +1 20:40
purl 1
sorear +1 it'll make fulltest faster
darbelo Code-wise, anything with the word 'purge' on it has my aproval.
cotto_work svn cp svn.parrog.org/parrot/trunk svn.parrot.org/parrot/branches/everything_purge 20:41
darbelo svn rm svn.parrot.org/parrot/branches/eve...ng_purge/*
svn merge svn.parrot.org/parrot/branches/eve...ing_purge/ . 20:42
svn ci
cotto_work -m "Everyone go find another project. We're optimal."
Coke sorear: yes, please. 20:45
cotto_work seen allison
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]
cotto_work seen the architect
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 rrot: r45945 | fperrad++ | trunk (6 files):
[test] generate valid TAP comment (ie. with # in first column)
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.
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.
sorear Is MANIFEST.generated a generated file? 20:55
Coke no.
sorear ok, it's just out of date then.
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/
sorear: WFM. 20:57
cotto_work sorear: you may need to refresh
21:00 rurban_ joined
dalek tracwiki: v12 | coke++ | DevelopmentPriorities 21:02
tracwiki: trac.parrot.org/parrot/wiki/Develop...ction=diff
tracwiki: v166 | coke++ | WikiStart
tracwiki: remove old priorities section.
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
sorear ah, I'm in 21:03
the solution involved activating the Parrot logo link
cotto_work s/2\\.0/3\\.0/g and it still makes sense.
dalek TT #1578 created by sorear++: Iterator.dump (among others) not installed 21:06
TT #1578: trac.parrot.org/parrot/ticket/1578
NotFound t/dynpmc/gziphandle.t (Wstat: 0 Tests: 2 Failed: 0) 21:23
Parse errors: Bad plan. You planned 3 tests but ran 2.
cotto_work are there any hlls other than rakudo that use dynops? 21:30
sorear this is interesting 21:33
is there a way to propagate #includes into pmc*.h ?
21:34 Mokurai joined
dalek rrot: r45946 | NotFound++ | trunk/t/dynpmc/gziphandle.t:
keep num of tests and skipped tests in sync
 21:36
cotto_work sorear: I don't understand your question.
what are you trying to accomplish? 21:39
sorear cotto_work: suppose I'm writing PMCs which interface with external libraries
suppose these external libraries use typedefs
in the .pmc, I can say
#include <perl.h>
pmclass ... {
SV *sv_attr;
...
}
cotto_work not unlike the recently checked-in gziphandle pmc? 21:40
sorear however, the #include never makes it into blizkost_group.c
so... I get a syntax error
this would be fixed if the #include made it into pmc_whatever.h
if I could get it into, that is
cotto_work blizkost? 21:41
purl blizkost is github.com/jnthn/blizkost/tree/master or the last Jonathan's project, an embedding of Perl 5 in Perl 6
sorear gzip_handle doesn't have any attributes
yes
*GzipHandle
NotFound sorear: if we put foreign includes in .h files we'll run into all sorts of name collisions. 21:42
sorear no worse than putting them into the .pmc ... and I'm asking if this is an existing feature, not requesting one 21:44
21:45 bubaflub joined
NotFound sorear: in the pmc is the pmc business. In a header than can included by other components, the problem expands. 21:45
sorear interesting 21:48
this is... not an easy problem 21:49
since the alternative is to break encapsulation and directly talk about struct sv
cotto_work We'll have to solve it one way or another. Blizkost is valuable. 21:50
sorear struct sv works for now 21:51
they might break it in perl 5.16
(of course, the real solution is to reimplement Parrot in a less braindead language...) 21:52
(and the rest of the world...)
NotFound Why the group file needs the include? I never looked at dynpmc handling
cotto_work sorear: less braindead than c? 21:53
sorear the include declares the vtables and class init functions 21:56
the group file declares the function loadlib actually calls, which needs to call the class init functions
cotto_work: yes. I'd love to see one 21:57
cotto_work That's the plan. We just have to implement it first.
NotFound sorear: to declare a function you don't need whatever that function calls 22:03
sorear NotFound: it's a monolithic header
NotFound PARROT_DYNEXT_EXPORT Parrot_PMC Parrot_lib_blizkost_group_load(PARROT_INTERP); ? 22:07
Coke cotto_work: partcl original uses dynops. 22:16
cotto_work do we care about it? 22:17
sorear NotFound: yes
Are dynops on the chopping block? :( 22:18
cotto_work no. just the non-C runcores
switch, cgoto and cgp
NotFound I see the problem now... is not the group file, but the .h itself.
22:18 davidfetter joined
Coke seen sfink? 22:21
purl I haven't seen 'sfink', Coke
cotto_work Only a fairly small change to the build is needed for HLLs that use dynops.
Coke happy to give someone a commit bit on partcl to fix it. Same terms as parrot itself. 22:23
NotFound There is no easy solution. All times we had a problem like that we used the 'struct .... *' solution. 22:27
sorear Coke: does that refer to licensing, or to the Parrot Contributor Agreement? 22:28
NotFound sorear: the ugly workaround is to use void * and a lot of casts. 22:29
Coke sorear: copyright, license and CLA. 22:35
22:38 tcurtis joined 22:42 Spreadsheet_ left
dalek kudo: 7a1409b | jonathan++ | src/glue/subset.pm:
Fix subset types involving subset foo of Mu.
 23:00
kudo: 2405a0b | jonathan++ | src/Perl6/Actions.pm:
Fix a tricky init ordering issue that meant we could not use where clauses in parametric role signatures.
kudo: a1159c7 | jonathan++ | src/Perl6/ (2 files):
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:01 iblechbot joined 23:03 tetragon joined
Coke msg chromatic - at least it isn't perl 6 slashFic. 23:21
purl Message for chromatic stored.
dalek rrot: r45947 | coke++ | trunk/tools/dev/checkdepend.pl:
Require this dep all the time (even though we only need it some of the time)
 23:30

Powered by Cro and the Raku® Programming Language.

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

Thank you!