Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
Set by moderator on 23 December 2008.
coke is unhinged to see "this is hacky" commits going into pirc. 00:00
coke though the point of pirc was to be all non-hacky.
00:03 particle1 joined
cotto Is it possible that a PMC could have a PMC_x_val that's not referred to in src/pmc/x.pmc? 00:09
(x != x)
00:09 AndyA joined 00:12 alvar joined, tetragon joined 00:19 Tene joined 00:21 TiMBuS joined
Tene Okay, it's time to make a presentation for tomorrow. 00:40
I forgot that I was presenting at all.
Also, I'm scheduled to work on a contracting job at the same time. I need to find a way to get around that... 00:41
moderator →← 00:41
jonathan Useful topic! ;-) 00:42
jonathan needs sleep...see y'all tomorrow.
00:42 purl joined
Tene The topic was blank for me... was there an error in my client? 00:43
I don't remember what the topic was before
Infinoid Parrot 0.8.1 "Tio Richie" Released | parrot.org | 24 TT | 648 RT 00:44
or Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
or something 00:45
moderator Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2 00:47
00:48 ask- joined
cotto got stuck in an infinite loop on the last topic 00:48
Infinoid my client didn't want to render multi-column characters in the topic line, here 00:49
not sure if it was irssi's fault or screen's
00:49 gravity joined 00:51 allison joined 00:54 Whiteknight joined 01:30 Fayland joined 02:13 particle joined 02:17 jimmy joined 02:18 TiMBuS joined
coke pokes mdiep. 02:43
02:50 bacek joined 02:56 kid51 joined 02:58 tetragon joined
coke if a function takes SHIM_INTERP, and I actually use the interp, do I need to change the function def? 02:59
jimmy yes. 03:07
coke ah, to PARROT_INTERP. 03:12
anyone familiar with the "remove pmc union" ticket?
kid51 TT or RT? 03:13
This one: rt.perl.org/rt3/Ticket/Display.html?id=48014 03:14
?
coke yes. 03:17
and I already know your answer. =-) 03:18
coke comments on the list.
coke sees that cotto claimed the ticket 16 hours ago.
coke does a revert -R . 03:20
03:56 rurban_ joined
coke is a smidge surprised that annotations seem to stay in effect until you override them. 04:02
coke shouldn't be.
04:14 particle1 joined 04:25 Fayland joined 04:53 japhb joined 05:00 masak joined
cotto Coke-away, if you want to help with the PMC union deprecation, please do. It's a big project. 05:14
05:23 MariachiElf joined
dalek r35515 | tene++ | trunk/tools/dev: 05:30
: [mk_language_shell]: Generate new languages in their own .HLL
review: www.parrotvm.org/svn/parrot/revision?rev=35515
05:32 petdance joined
jimmy can anyone helps to reopen trac.parrot.org/parrot/ticket/84 ? 05:52
cotto jimmy, done 05:53
jimmy cotto++ 05:54
05:54 Theory joined
dalek r35516 | petdance++ | trunk/src: 05:55
: minor consting
review: www.parrotvm.org/svn/parrot/revision?rev=35516
r35517 | petdance++ | trunk/config/auto:
: -Wunused-parameter is too noisy right now
review: www.parrotvm.org/svn/parrot/revision?rev=35517
cotto UnManagedStruct extends default. I thought everything did that. 05:56
as does Undef 06:01
I smell hysterical raisins. 06:02
petdance My build is failing and it is highly tragic. 06:06
cotto delicious raisins (although about to be removed) 06:11
dalek r35518 | cotto++ | trunk/src/pmc (2 files): 06:13
: [pmc] everything extends default, so it doesn't need to be explicit
review: www.parrotvm.org/svn/parrot/revision?rev=35518
06:24 particle joined
cotto perl++ 06:44
graphviz++
Infinoid cotto++ 06:48
jimmy /me wonders why 07:04
cotto it probably has something to do with taking on the ticket that coke mentioned, but I never question free karma 07:05
masak cotto++
petdance my build segfaults 07:10
/bin/sh: line 1: 14766 Segmentation fault ./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
suggestions? 07:11
purl suggestions are welcome.
cotto svn diff?
purl i think svn diff is clean
cotto make reconfig?
petdance I've rerun config 9,000,000 times so far. 07:12
moritz purl, forget svn diff
purl moritz: I forgot svn diff
moritz purl, forget suggestions
purl moritz: I forgot suggestions
cotto is the backtrace useful? 07:13
Andy, ping 07:23
petdance yessir 07:24
cotto I found an apparent bug in ack. should I tell you here or post a report? 07:25
petdance tell me here, and then post a report
if I don't say "that's not a bug"
cotto highlighting screws up the terminal if you press ctrl-c while ack is printing some highlighted/colored text 07:26
petdance I'd hardly call that a bug
It's output. 07:28
It's ANSI output
and yeah, it'll mess up your screen if you stop it in the middle.
07:31 namenlos joined
jimmy cotto: I re-edited PMCUnionDeprecationTasklist 07:32
cotto jimmy++ 07:34
jimmy cotto++, for creating it. 07:35
petdance ok bed time for me 07:36
jimmy the image is useful to me.
cotto that's the idea 07:38
masak what's the URL to the Parrot Trac? 07:40
purl i think the Parrot Trac is trac.parrot.org/parrot/
masak purl: an actually useful response! imagine that!
purl masak: excuse me?
GeJ any Win32 user available? 07:46
jimmy me 07:50
me 07:52
07:52 Tene joined
GeJ jimmy: Do you know if the Express edition of Visual Studio is enough to build Parrot? 07:54
jimmy Sorry, I don't know.
I'm using Microsoft Visual C++ 2008 Express Edition. 07:55
but I have never used it to build parrot. 07:56
GeJ Well, I guess I'll give it a try and see. Thanks. 07:57
jimmy Gej++
cotto GeJ, istr that it is 07:58
GeJ cotto: Oh, good to know. 08:00
nopaste "GeJ" at 202.22.229.231 pasted "Remove STM reference in HTML doc generation. Fix `make html` target." (13 lines) at nopaste.snit.ch/15301 08:02
GeJ hum, Whiteknight seems to be gone. :( 08:03
I think he did the stm removal, right?
jimmy yep 08:04
GeJ I'll ping him tomorrow.
GeJ goes back to "Learn C# in 21 hours" :~( 08:05
jimmy GeJ: there were more to do. like, _class->vtable_cache = PMCNULL; /* only used for STM */ 08:08
08:08 iblechbot joined
GeJ jimmy: it looks like the t/stm directory has been removed already, and when calling `make html` perl b0rks because it is nowhere to be found. 08:11
jimmy GeJ: Gej++, and I found other codes that mentioned stm. 08:12
cotto jimmy, nopaste a patch 08:27
jimmy is testing now. 08:32
jimmy wonders is there a stm op in AIX
nopaste? 08:39
purl nopaste is, like, at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
nopaste "jimmy" at 220.232.135.194 pasted "removing stm codes, but not docs(should we remove stm docs?)" (61 lines) at nopaste.snit.ch/15302
08:44 particle1 joined 08:46 register joined
jimmy cotto: should I create a ticket for it? 08:53
jimmy found trac.parrot.org/parrot/ticket/6 is that 08:58
cotto jimmy, do you mean for the patch you nopasted? 09:01
jimmy yes 09:02
dalek r35519 | cotto++ | trunk/lib/Parrot/Docs/Section:
: [docs] remove an STM reference and fix make html
: GeJ++ for noticing
review: www.parrotvm.org/svn/parrot/revision?rev=35519
cotto if it doesn't cause any explosions, I'll just apply it now 09:03
jimmy it is listed in DEPRECATED.pod too.
cotto tesing... 09:04
jimmy I don't know whether cause any explosions, but all test is passed here on win32
cotto all tests passing == no explosions (although it doesn't hurt for me to verify) 09:06
jimmy and there is vtablecache.pmc file too.
this is should be removed.
09:07 mj41 joined
cotto your patch will help 09:07
jimmy cotto: I think my patch cann't be applied. 09:09
cotto why not? it applied cleanly and you said there were no failures 09:10
jimmy actually, it is part patch of TT #6
vtablecache.pmc is used in pmc.num and I don't how to remove it. 09:11
dalek r35520 | cotto++ | trunk/src:
: [oo] replace a couple PMC_x_val macros with VTABLE functions
review: www.parrotvm.org/svn/parrot/revision?rev=35520
09:13 russell_h joined
dalek r35521 | cotto++ | trunk/src/pmc (2 files): 09:13
: [pmc] remove a couple STM and VTABLECache references
: patch courtesy of jimmy++
review: www.parrotvm.org/svn/parrot/revision?rev=35521
jimmy cotto: I uploaded another patch 09:19
trac.parrot.org/parrot/ticket/6
cotto tesing... 09:23
jimmy ah, forgot to remove test case file. 09:26
cotto the build looks good, now running the test suite 09:27
jimmy there is a test case file that should be removed
cotto t/pmc/vtablecache.t? 09:28
jimmy yes
09:28 tomyan joined
cotto I'll take care of it if the tests are happy 09:28
thanks for your work on this
jimmy seems that patch2.patch can't remove files. 09:30
vtablecache.pmc should be also removed. 09:31
cotto yup 09:32
done 09:34
dalek r35522 | cotto++ | trunk (6 files): 09:35
: [pmc] remove the vtablecache PMC and tests
: patch courtesy of jimmy++
review: www.parrotvm.org/svn/parrot/revision?rev=35522
09:36 alvar joined
cotto There really should be a script to renumber pmc.num 09:37
jimmy yep
cotto easy karma if you feel like submitting one, jimmy
;)
an additional make target (make pmcrenum) would be ideal 09:38
similar to make opsrenum
09:40 donaldh joined
cotto I'll do it if you don't want to. Do you? 09:43
jimmy I'm not good at perl :(
cotto Ok. Let's see how long this takes. 09:44
jimmy guessed there were less than 3 lines. 09:45
cotto it has to be a little nicer to be committable 09:52
09:54 kj joined 09:59 mberends joined
cotto seems to work 10:01
jimmy cotto++
karma cotto
purl cotto has karma of 255
cotto very nice number 10:02
255++
jimmy karma 255
purl 255 has karma of 1
szbalint 8 bit wonder 10:03
=)
cotto one more, and a NES won't be able to handle my karma 10:04
10:08 tomyan left
cotto There it is. 10:08
dalek r35523 | cotto++ | trunk (4 files):
: [pmc] add make pmcrenumber to take care of pmc.num when needed
review: www.parrotvm.org/svn/parrot/revision?rev=35523
10:09 jimmy joined
masak I thought 255 might be prime, but it isn't. it's 3 * 5 * 17. 10:09
10:09 jimmy joined
cotto maybe 256 is 10:09
;)
kj masak: it's also mod 5 == 0
moritz no number that ends in 5 (except 5) is prime
masak kj: ouch. yes.
kj hehe. still early morning eh? :-) 10:10
masak seems so.
10:10 tomyan joined
masak I guess I also was thinking of 255 as 0xFF, and that muddled my thinking somewhat. 10:10
cotto pipp: <?=cotto?><?=--?> 10:12
polyglotbot OUTPUT[Couldn't find constant cotto␤=--?>]
cotto pipp: <?="cotto"?><?="--"?>
polyglotbot OUTPUT[cotto="--"?>]
jimmy pipp: <?php echo 'hello,world';?>
polyglotbot OUTPUT[hello,world]
jimmy <?="--"?> 10:13
pipp:<?="--"?>
pipp: <?="--"?>
polyglotbot OUTPUT[--]
jimmy pipp: <?="cotto"?><?="--"?>
polyglotbot OUTPUT[cotto="--"?>]
jimmy pipp: <?="cotto"?>
polyglotbot OUTPUT[cotto]
jimmy why?
cotto Pipp's tag parsing is br0ken 10:14
I have the grammar fixed, but I haven't taken the time to figure out the actions
moritz rakudo: say (i+2i) * (i-2i) 10:24
polyglotbot OUTPUT[Could not find non-existent sub i␤current instr.: '_block14' pc 53 (EVAL_16:38)␤called from Sub '!UNIT_START' pc 17255 (src/builtins/guts.pir:321)␤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 950 (src/PCT/HLLCompiler.pir:527)␤called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1275
..(src/PCT/HLLCompiler.pir:688)␤called from Sub 'parr...
moritz rakudo: say (1+2i) * (1-2i)
polyglotbot OUTPUT[5+0i␤]
Tene Scheme is an interesting language to implement. 10:25
moritz that's why there are so many implementations :-)
I played with scheme in school, but I never got around doing something useful with it 10:27
(as with most languages, I might add)
cotto time for sleep 10:28
10:29 kj joined
jimmy time for going home 10:33
10:42 gaz joined
Tene I was hoping to use it for a presentation tomorrow. It might not be very nice, though, as I had to implement so much at once to implement (let 10:46
although I guess it's actually let*
Eh, I guess I could have faked it better. 10:49
I really should start experimenting with my idea for making interactive mode and eval work in the appropriate lexical environment... 10:50
11:00 ruoso joined, elmex joined 11:01 barney joined 11:05 particle joined 11:20 krunen joined 11:49 braceta joined 11:57 rurban_ joined
dalek r35524 | bernhard++ | trunk (4 files): 12:04
: [eclectus] Add a Configure.pl. Add variable $hll.
review: www.parrotvm.org/svn/parrot/revision?rev=35524
r35525 | cotto++ | trunk/src: 12:14
: [cage] another PMC_x_val removal
review: www.parrotvm.org/svn/parrot/revision?rev=35525
jonathan hi hi 12:17
kj good morning 12:18
jonathan We have more snow! Pretty. :-D
jonathan will start hacking on Rakudo in a bit...after lunch.
12:19 jimmy joined
dalek r35526 | cotto++ | trunk/src: 12:43
: [key] remove a few PMC_int_val instances
review: www.parrotvm.org/svn/parrot/revision?rev=35526
12:43 TiMBuS joined
dalek r35527 | bernhard++ | trunk (5 files): 12:50
: [docs] Remove LANGUAGES_STATUS.pod, it's now in the wiki
review: www.parrotvm.org/svn/parrot/revision?rev=35527
13:01 jimmy joined
Coke-away cotto: ping 13:14
13:26 particle1 joined 13:28 Whiteknight joined 13:32 jimmy joined
Whiteknight when is SVN going down today? 13:36
jonathan 19:00 UTC 13:37
Coke we're sure it's UTC and not Pacific? =-)
jonathan Ano. 13:39
Whiteknight okay, so I guess I have to get all my mad haxxoring skillz out in the next 7 hours
Casan jonathan: those slovak class come in quite useful :) 13:46
heh maybe I should take some English typing clasSES
jonathan Casan: slovak?
purl slovak is like a car crash. it SOUNDS like a car crash anyway.
jonathan OH!
s/ano/yes/ 13:47
Casan heh
jonathan is flicking between #slovakia.pm and #parrot
Casan jonathan: I was just surprised that whitenight understood. 13:48
szbalint until there is electricity or gas
jonathan I'm lucky. My heating is electric, and Slovakia has a spare nuclear power station or two... ;-) 13:49
(Though Austria will hate us for using 'em.)
Feel bad for the folks down in Bulgaria etc though. :-( 13:50
Casan jonathan: hehe, this is a good time to watch "The Saint" with Val Kilmer and Elisbeth Shue again :)
14:04 gryphon joined
szbalint jonathan: I'm in Vienna atm and I can see the hatred :P 14:05
jonathan szbalint: OH NOES! Please don't invade! 14:06
;-)
szbalint heheh
jonathan Good relations with Austria are important. I need my regular Vienna Schnitzel. :-) 14:07
14:14 Lorn joined
szbalint indeed 14:17
Coke (bulgaria) zdrasti! 14:20
dober vecher? 14:24
jonathan Coke: Maybe. That's close enough to Slovak that I understand it.
:-)
14:26 davidfetter joined
pmichaud okay, _why_ is svn.parrot.org migrating today. 14:33
?
It would've been nice to have more than 11 hours notice.
PerlJam today?
purl i heard today was pretty close to planting day
pmichaud Also, my plan had been for Rakudo to remain on the perl.org servers.
PerlJam Hmm. I thought it was some nebulous time in the future. I hadn't heard it was today until just now. 14:34
jonathan This fun means we migrate to svn.parrot.org....only to migrate Rakudo back. :-|
14:34 ruoso joined
pmichaud and *not* be migrated to svn.parrot.org... EXACTLY. 14:34
I had even requested (of particle) that we not do a migration until Rakudo could get its house in order.
and the plan/expectation was that this would be happening *after* the Jan 2009 release. 14:35
jonathan I was rather surprised to see the announcement today too.
I don't think it was mentioned in yesterday's parrotsketch.
pmichaud I didn't see it.
jonathan Me either.
Hmm. This is a pain.
Coke I think we've been targeting this week (before the release) since a month ago. 14:36
pmichaud Why is this the first I've heard of it? 14:37
Coke that is presumably my fault, allison's fault, or very unlikely, your fault.
pmichaud and I've even talked to particle about the need for Rakudo to move out of the parrot repo before Parrot moves.
and I mentioned it in the weekly conference calls as well.
Coke allison and I were on the thread for the move. not sure if partcle was.
PerlJam pm: seems to me that you're talking to the wrong person.
pmichaud PerlJam: thus my comment yesterday about "who's in charge of the infrastructural stuff" 14:38
Coke pmichaud: I would have to say allison at this point.
I think this move will include an svn mirror living at perl.org
pmichaud Coke: so, does that mean that people can continue commits to svn.perl.org ? 14:39
Coke if that's the case, then perhaps there's no issue.
pmichaud: I don't know how that works.
pmichaud I would *really* like to halt this today if at all possible.
Or at least get a chance to figure out how it affects Rakudo without being under a five hour gun.
Coke worst case, you have to change your svn urls temporarily and then again when you move. 14:41
pmichaud *and* I have to announce it to everyone who is using Rakudo.
jonathan Twice in this case.
Coke I hate english.
"all y'all"
purl "all y'all" is something quite different from just plain "y'all"
14:41 AndyA joined
Coke unless the mirror does what I think it might. 14:42
I'll ask robrt, since he's the one that mentioned that.
pmichaud I still don't find this acceptable.
Coke ah. not a mirror. a redirect is what he said. 14:43
barney pmichaud: Is the Rakudo plan to stay with svn or to switch to git? 14:46
pmichaud barney: that was also one of the things I was planning to look at. 14:47
I'm sorry, I just feel royally dissed by this.
on the one hand, people in the "move parrot to git" ticket say that we shouldn't move to git because it'll cause bumps for current developers, then within just a couple of days we have "oh, we'll move the repository without telling anyone, regardless of what that might do to the languages" 14:49
14:49 register joined
Whiteknight I do feel like it's a little short notice 14:53
and especially so close to the release, I don't like having down-time that could be used to close tickets
kj Whiteknight: you can work offline, right?
pmichaud not only that, but I've been bringing up the topic for a month now
Whiteknight I probably can work offline, but who would want to? 14:54
kj dunno. I'm not saying it's as good, but it works
Whiteknight any roadbumps so close to a release is a bad idea I think
pmichaud Allison even said in one of the conference calls that it would occur *after* the January release. 14:56
(okay, she said "probably".)
Casan ok, so whats the problem with postponing the move, until rakudo is ready? 14:57
purl I AM WOMAN! HEAR ME ROAR!
pmichaud I don't have a problem with postponing, but I'm apparently not the person who gets to make those decisions </fume>
Casan heh, seems like we could benefit from a little mandatory communication when it comes to infrastructure changes. 14:58
jonathan pmichaud: This is the first I knew of it to. It's certainly been badly communiciated. 14:59
I'm in favor of postponing it too.
pmichaud jonathan: perhaps add a comment to that effect to the parrot-dev thread, then? 15:00
jonathan: so I'm not a lone voice ? ;-)
jonathan pmichaud: Mailing it now.
Coke as I recall, we shot for post-january but are constrained because we needed a time that both perl.org and parrot.org admins were available. 15:02
(communication) yup
dalek r35528 | bernhard++ | trunk/languages/pipp (4 files): 15:03
: [Pipp] Set $?NS. Document divergence of allowing 'const' outside
pmichaud that constraint wasn't communicated
dalek : namespaces.
review: www.parrotvm.org/svn/parrot/revision?rev=35528
pmichaud actually, none of this has been coordinated with me.
Whiteknight that could very well be the issue: it happens when the admins are available and not when we want
pmichaud admins should be like lawyers -- they exist to find ways to achieve what you want, not to tell you what you can have. 15:05
Whiteknight so we want our admins to be blood-sucking liars? 15:06
pmichaud (and I say this having been a former admin.)
Whiteknight apologizes to any lawyers present, he was just making a joke
Coke pmichaud: btw, jerry is on the conversation thread with the OSU/perl.org folks.
pmichaud why am I not on this thread, then? 15:07
Casan also admins should assist in defining you needs. the deliverable is a match between supply and demand.
Coke pmichaud: I think he was wearing his foundation hat.
pmichaud regardless, it feels to me as though Parrot foundation is ignoring the existence of Rakudo. 15:08
or worse, doesn't care.
Casan pmichaud: think you just feel a little offended now which is natural. but I am sure they recognize the importance of rakudo. it is an obvious asset. 15:09
Coke My hope is that the redirect will do what you need; if so, then there's no user visible change aside from the downtown. 15:10
...
down *time*
Whiteknight can we get a ballpark estimate for the amount of downtime? 15:11
pmichaud Whiteknight: five hours, I think.
Whiteknight those are usually the most productive hours of my day: right after I get home from work but before my wife wants my "attention" 15:12
Coke the hope is that it won't take that long, and that it's better to advertise the worst case and come in better.
Casan but then again, maybe its not too bad after all, rakudo developers get 5 hours off to fetch inspiration from $other_life 15:13
Coke looks like we didn't get confirmation on the time until about 8 hours ago.
(and allison's email is about 7 hours ago.)
(just providing what little data I have)
pmichaud Casan: (importance of rakudo) -- my point is that nobody thought to include me on the migration discussions.
Casan: even though I had explicitly brought them up multiple times in December. 15:14
Casan: with multiple representatives of the Parrot Foundation
Casan pmichaud: yep is a serious slip, need to take advantage of the problem and implement actions to ensure it will happen natural in the future. 15:15
donaldh Hmmm, I'd have expected a large warning message on trac for this kind of upheaval. In commerceville you'd be hanged for less than 30 days notice of mandatory downtime. 15:18
15:23 hercynium joined, AndyA joined
Coke ObviousPoint: We're in VolunteerShantyTown. 15:23
15:24 bacek joined
Infinoid pmichaud: when I asked about it, the answer I got was "after the january release" too 15:24
15:24 AndyA joined
Infinoid also, I guess it constitutes a "no" answer to TT #138's feature request (git). 15:25
pmichaud Infinoid: I was pretty sure that we wouldn't see a migration to git in January.
in some ways that also impacts Rakudo, though, since we don't necessarily want people to have to do both subversion and git. 15:26
Infinoid it doesn't bother me much. but I can see how it would be a pain for rakudo
(uncoordinated server migration, I mean)
pmichaud so we'd need to have clear instructions for Rakudo users in place before we do a migration
Infinoid yeah. or just "make rakudo" to do a checkout from the appropriate place :)
(speaking of which, I'm surprised we aren't doing that for partcl as well) 15:27
Coke (partcl) what now?
pmichaud "make partcl" fetches partcl from its repo and builds
(proposed) 15:28
Coke I'd rather have folks go to /partcl/ to get parrot.
pmichaud good answer. :-)
Coke but would not be opposed to having a shortcut if it helped people test out partcl on parrot.
my experience, however, is that having that sort of easy access to test partcl... doesn't help at all. =-)
Infinoid test exposure is the only reason I thought of it
I think moving partcl out of the repository decreased its visibility somewhat... 15:29
Coke Infinoid: It was invisible /in/ the repository. =-)
I moved it out so it would stop getting broken.
Infinoid fair enough.
PerlJam Infinoid: it's just as visible before and after I think. (Coke didn't stop babbling about it at all! ;-)
Infinoid hah
Coke++ # partclbabble 15:30
Coke so I certainly sympathize with rakudo's pain on this migration thing. I certainly apologize for my lack of
(more)
communication skills on this one.
(I'm very certain today, apparently)
pmichaud you certainly are! :-)
(apology) -- thanks, that helps a bit. 15:31
PerlJam okay ... will there eventually be a migration to git?
pmichaud PerlJam: of which?
PerlJam parrot
(or rakudo)
pmichaud PerlJam: parrot -- probably not before 1.0
rakudo -- depends on how difficult it is to manage rakudo/git and parrot/svn 15:32
Infinoid PerlJam: the main argument against it seems to be distraction of developer resources.
pmichaud for rakudo we'd also need a repository somewhere
PerlJam okay, I volunteer to help setup a git repo for rakudo. someone just needs to point me in the right direction. :-) 15:33
But I'm slightly confused about parrot + git though.
pmichaud PerlJam: what confuses you about parrot+git ?
PerlJam Here's a direct quote from allison (via email): I haven't heard any talk of moving Parrot to git, but it's something we could talk about for future years (too risky to change source control systems before 1.0). I don't find git appealing, though.
barney Perljam: It would help to have an uptodate Git Mirror of Parrot's svn 15:34
Infinoid and an "official" one, at that
PerlJam barney, Infinoid: indeed.
pmichaud PerlJam: I don't see the confusion.
Infinoid threatens to export his (again)
barney I suppose that languages can easily be split off from there
PerlJam pm: I see people talking about parrot+git, but I get the distinct impression that it's not going to happen from allison. 15:35
barney I want to do this for eclectus. plumhead and pipp
pmichaud PerlJam: I think what I said matches what allison said -- not before 1.0
Infinoid I got the same response from particle
pmichaud lots of people speculate on #parrot that perhaps Parrot should move to git, but I haven't seen any foundation person say that. 15:36
PerlJam well, certianly not before 1.0 (everyone agrees on that)
pm: right. So ... who needs convincing? :)
Coke if the url is http in both cases, a redirect should be pretty transparent, I think.
PerlJam in any case, whatever the "official" repo is, as long as there's a way to query it via svn/git/svn/bzr/hg/darcs or whatever the major SCMs are, it's all good. 15:38
oops, s/svn/svk/
pmichaud PerlJam: You'd need to convince the core development team, which doesn't seem likely anytime soon. (And I would include myself in that group, on both respects.)
Infinoid wants to put together a semipublic bidirectional git gateway 15:39
PerlJam Infinoid: me too (ish).
pmichaud PerlJam: as far as moving the rakudo repo, I already own the rakudoperl.org domain, so perhaps we could set something up there.
15:39 mberends joined
Infinoid driving to work & 15:39
pmichaud I wonder if we could/should host rakudo on feather.... 15:40
15:41 particle joined
moritz we certainly could 15:41
but feather isn't very secure
that's not a problem if we use git
pmichaud if it's good enough for pugs/synopses/std, it might be good enough for rakudo. 15:42
PerlJam There are multiple feathers. One could be made more secure than the others.
pmichaud indeed, we could just put rakudo into the pugs repo.
otherwise people have to deal with *three* repositories
(pugs, parrot, and rakudo)
moritz pmichaud: do you want the same liberal commit policies for rakudo as there are in the pugs repo? 15:43
pmichaud moritz: I haven't decided that yet.
moritz: I see some value in both approaches.
PerlJam pm: pretend rakudo was in a liberal commit repo like pugs. When *wouldn't* you want someone to commit to it? 15:45
pmichaud PerlJam: I've noticed that a lot of people submit patches without having read the spec first.
PerlJam: a liberal commit kinda goes against that.
PerlJam pm: but doesn't that end up correcting itself? 15:46
(or you just want to short circuit all of the "that's not per the spec" messages?)
pmichaud PerlJam: it corrects itself if there are sufficient numbers of "editors" available.
PerlJam: but if not corrected, it spreads.
PerlJam: I.e., an incorrect meme ends up replicating itself throughout the codebase.
PerlJam right
pmichaud :et 15:47
(oops)
Let's just say that I've seen more than a few patches where I think "boy, I'm glad that wasn't committed."
PerlJam so, you like having "gatekeepers" who review patches with an eye towards making sure there are no bad memes and that the code fits the spec ?
pmichaud PerlJam: for Rakudo, yes. 15:48
Not to pick on jonathan++ here, because his work is indeed outstanding, but we just spent the better part of two weeks refactoring in the rvar branch because of things going in differently than I thought they should. 15:49
dalek r35529 | bernhard++ | trunk/languages/pipp/src/pct:
: [Pipp] NAMESPACE_NAME shan't be empty.
: Constant names can be with namespace.
review: www.parrotvm.org/svn/parrot/revision?rev=35529
pmichaud (Clarification for those reading: I'm very happy that jonathan put those in, and he had my full permission to do so because I was largely unavailable at the time. But it did make for some heavy-duty cleanup work later.) 15:50
Coke I think pugs can work well. i think you'd drive pmichaud crazy if we tried it for rakudo. =-) 15:53
s/drive him crazy/eat up all his tuits/
PerlJam pm: So ... I don't see how you really mitigate that unless you're the arbiter of all commits but then the rakduo truck-number is 1 (not good) 15:54
donaldh it does make rakudo a difficult project to contribute to as well.
Does no commit bit in svn mean no ability to experiment on a branch?
PerlJam donaldh: I was just about to mention that. 15:55
I guess it all boils down to who can commit to trunk
pmichaud PerlJam: I'm not the arbiter of all commits
PerlJam: that's not even the present case, nor do I expect it to be
PerlJam branches are okay. changes can be vetted there and then merged to trunk as they get into shape.
barney With github.com you can set up collaborators in a convenient way
Coke You can avoid a lot of technological restraints if there is a good social framework.
but I suppose we could theoretically limit commit access to trunk. 15:56
pmichaud we have multiple committers to Rakudo, and moritz/masak/jonathan/PerlJam/others are able to commit just fine, and commit patches
donaldh PerlJam: yes, all of us need to learn the codingstd and other expectations. a branch is a better place for that than patches attached to tickets.
pmichaud But that's a far cry different from "anyone can commit"
PerlJam Hmm.
Only interested people *actually* commit, though anyone may (in pugs) 15:57
pmichaud PerlJam: People who submit patches are "interested"
PerlJam: in many cases, they're also eager to commit
that doesn't mean that they *should*
or that they know the difference. 15:58
jonathan I'd agree with pmichaud that a completely open commit policy wouldn't be the best way for Rakudo.
Coke I think we are getting close to a time when folks on the left coast might be able to respond to my question about the redirect.
PerlJam jonathan: me too. I'm just thinking of the flip side out loud :-) 15:59
jonathan Oh, it's worth considering.
I do very much want to have more people contributing.
But review is important too.
pmichaud well, one advantage of rakudo moving out of the parrot is that we no longer are constrained by parrot's commit policy
s/the parrot/the parrot repo/ 16:00
jonathan *nod*
PerlJam has it been a constraint?
Casan reasonable. put a control on commits to the trunk, but support an open flow of patches, and support streamlining the expecting programming standards and educate committers. when they have demonstrated they can handle, give them a test period and then..
pmichaud Casan: that's parrot's and rakudo's current approach.
Casan its natural.. can't we keep it :)
pmichaud PerlJam: (has it been a constraint) only slightly, in that we require CLAs for anyone contributing to the parrot repo. 16:01
Infinoid rakudo also won't be constrained by parrot's codingstd tests.
jonathan I haven't felt our current approach has been a problem really.
pmichaud but I agree, I'm comfortable with the current approach.
jonathan Infinoid: OH YES! :-D
*chuckles*
(On the whole I don't mind them. I just have a stormy relationship with trailing whitespace. :-)) 16:02
PerlJam Infinoid: so ... I can commit code with trailing whitespace all I want? ;-)
Infinoid yep!
PerlJam jonathan++
Infinoid the majority of codingstd commits I've made in the last month (other than the ASSERT_ARGS mess) was to rakudo.
not that I mind, of course :) 16:03
masak pmichaud++ # annoyed email
donaldh tbh the real problem with contributing to rakudo is not a patch/commit bit issue. It's more a problem of understanding what pmichaud++ and jonathan++ think is done right versus plan to refactor real soon. 16:04
I understand some code. Next time I look the goalposts have moved. 16:05
pmichaud Coke: *If* the subversion migration is completely transparent to Rakudo, such that people continue to use svn.perl.org/parrot/trunk to obtain Rakudo *and* such that migrating Rakudo later is no more difficult than it would've been under perl.org, then I'm much less miffed about the move.
somehow I think that's unlikely, though, since a Rakudo migration would seem to involve the OSU and perl.org admins a second time.
PerlJam Who is actually going to do the "move"? 16:06
pmichaud PerlJam: I don't know.
Casan donalh: ticket++ have the codingstd masters of rakudo define the codingstd's, loop until sufficient
pmichaud yes, we will be establishing codingstds for Rakudo in the very near future.
it's part of that "features versus docs" balance.
(until now we've been largely adopting Parrot's codingstds, because (1) they're good enough and (2) we've been part of the Parrot repo) 16:07
dalek r35530 | jonathan++ | trunk/languages/perl6 (3 files): 16:08
: [rakudo] class C does R[param1, ...] { ... } now works insofar as it chooses the correct role.
review: www.parrotvm.org/svn/parrot/revision?rev=35530
pmichaud hmmm, for some reason I'm not receiving messages from parrot-dev 16:09
Coke (involve the OSU again) but if that's the only downside, we just make allison buy them cake.
PerlJam Having the commit log output here is like watching magic happen.
"nothing up my sleeve ... *bam* parametric roles!" 16:10
pmichaud "That trick never works!"
jonathan PerlJam: Oh, calm down. This is just one small part of parametric roles. :-)
PerlJam jonathan: I realize that, it
's still quite cool
jonathan pmichaud: Am I going to make your day go from bad to worse if I ask to talk about lexicals? :-)
Casan stumbled over this on parrotskettch: particle: allison and i have an open relationship with osuosl and perl.org. i'll take ownership of any infrastructure tickets.
pmichaud jonathan: not at all 16:11
jonathan pmichaud: Whew!
Coke Casan: the 15 year old in me is ROTFLING.
pmichaud jonathan: although I guess it depends on the question :-)
jonathan OK, so where we're at now is that a Perl6Role does a multi-dispatch on the role signatures.
Casan Coke: hehe
PerlJam Coke: you ate a 15 year old?!? 16:12
jonathan And that in turn runs code to produce a Parrot role.
So essentially a role Foo[$x, $y] { ... } is like a (but not visible as a) multi Foo($x, $y) { make a role and return it } 16:13
And thus $x and $y are parameters, a normal sig gets built, and so forth.
pmichaud okay.
jonathan Inside that block are the methods.
role Foo[$x] { method x { say $x } }
And attributes etc. 16:14
Thing is, for these methods, they need to end up referring to the correct lexical scope.
Essentially, we need to capture them each time the body runs.
Questions.
purl well, questions is Dumper $data? What implementations have you made? You aren't trying to optimize prematurely, are you?
pmichaud wait, I have a question first. 16:15
jonathan (1) Do I need to clone all of the tested blocks inside the methods too? I'm hoping not.
pmichaud in role Foo[$x] { ... } does the block still act like a BEGIN ?
jonathan I don't see how it quite can. 16:16
pmichaud agreed.
jonathan role Foo[$x] { say $x }
pmichaud So, here's the answer.
if you create the role as if it's a multi, as you described
jonathan class A does Foo[1] { }; class B does Foo[2] { }
# I'd expect 1\\n2\\n
pmichaud and that multi gets invoked at the point of the role creation
then the methods end up with a capture_lex at the point of the creation 16:17
PCT handles that automatically
(more)
jonathan Right, capture_lex is getting emitted.
pmichaud how do the methods end up in the newly-created Role now ? 16:18
inherited? add_method?
jonathan The role would look them up in the namespace.
Thing is, if you re-create the role a second time, it doesn't find them again. :-|
pmichaud doesn't that role have a different namespace than the "original" one?
jonathan For a particular role signature there is one namespace. 16:19
However, we may create many Parrot roles from the methods within that namespace.
pmichaud and each of those roles share that common namespace?
jonathan Right.
Coke PerlJam: (15 year old) that would explain the weight gain.
jonathan However, the methods within each role should capture the lexical scope at the time the role was created. 16:20
pmichaud that confuses me a bit (because allison says that classes and namespaces are isomorphic), but I think the answer is that the methods will have to be cloned as part of creating the role.
jonathan pmichaud: I kinda see a way to do this though.
(As in, cloning the methods.)
Which I hadn't thought of before, which actually makes it easier. :-) 16:21
pmichaud note that newclosure still exists -- it's a capture_lex + clone operation.
jonathan OK.
My question from above still stands.
pmichaud of course, you still have to do it from the outer scope.
you do not need to clone the blocks inside the methods
jonathan OK, good.
pmichaud those blocks get capture_lex'd when the methods are invoked. 16:22
Whiteknight hey where was that list of things in Rakudo that were done and things that needed to be done?
jonathan That was what was going to scare me.
Have we thought about how capture_lex will play out under multi-threading?
pmichaud each outer block is responsible for capturing its immediate children upon invocation. The children's children are handled by invocations of the children blocks (if they ever occur)
moritz Whiteknight: ROADMAP
Whiteknight moritz: I thought there was a page online somewhere?
PerlJam Whiteknight: you'd think it would be on rakudo.org somewhere wouldn't you?
pmichaud Whiteknight: it's on the perl foundation wiki 16:23
Whiteknight I dont know where I think anything would be
pmichaud this is another reason I'm thinking of activating rakudoperl.org
so that I can get all of the rakudo-related stuff into one place.
jonathan pmichaud: OK. You spent a lot more time thinking about this than I have, so I trust your answer. :-)
moritz pmichaud: we should have all the rakudo stuff on rakudo.org, and news.rakudo.org as the blog
pmichaud: or something like that
pmichaud moritz: except I don't own rakudo.org
if Andy wants to turn it over to me, then we can do that. 16:24
moritz pmichaud: that's bad
jonathan pmichaud: I'm sure we could get whoever does to be co-operative.
I'd pitch in an hour or two for writing some site content and doing some bits on that.
moritz Whiteknight: www.perlfoundation.org/perl6/index....ure_status
shorten moritz's url is at xrl.us/bebd7u
Andy I'm thinking of making rakudo.org be Drupal rather than MT
Whiteknight thanks moritz, I just found it 16:25
Andy More content-y.
jonathan Andy: Would we be able to migrate over the current posts?
Andy of course.
purl Indubitably.
jonathan Could be a good plan.
PerlJam Andy: I think the site lies a little bit -- rakudo.org: Your one stop for Rakudo Perl, Parrot and Perl 6 news: Development, blogs, docs and more 16:26
There is no "one stop"
Casan as for rakudo.org wouldn't the correct approach be to turn it over to the foundation, and have them mandate a maintainer to secure its use for the community.
Andy PerlJam: sure
pmichaud Casan: things happen slowly within the foundation.
Infinoid japhb: ping 16:27
Casan hence the maintainer
pmichaud Casan: to be quite honest, I'm a little frustrated at not controlling my own destiny in some respects. The fact that Parrot's repo is moving without any consultation with me is yet another example of that. 16:28
Casan know the feeling
pmichaud so, simply saying "turn it over to the foundation" would seem to me to just bring me back to the status quo. 16:29
(and beyond that, rakudo.org isn't "mine" to turn over. :-) 16:30
Andy: if you want to make rakudo.org be Drupal instead of MT I'm all in favor of it.
Andy But we still need people to create content for it. 16:31
pmichaud what does it take to start granting "content creator" access for it?
I know that there are several of us who would happily do so.
Casan pmichaud: my concern was main in relation to rakudo.org, having everything related to one domain would ease information management and understanding. and with ownership of the domain belongs to the foundation, maintainer(s) can be mandated. eg. andy&|you.
Andy I don't know from Drupal, but it can't be any less odious than MT.
pmichaud my experience with Drupal on parrot.org hasn't been too bad.
and I do like that there's a wiki available, even if it's a particularly sucky on. 16:32
*one
PerlJam heh
Casan pmichaud: I tend to stay system independent, I was mainly referring to the dns level.
Andy parrot.org is drupal?
purl i already had it that way, Andy.
pmichaud Casan: I'd much rather deal with Andy for dns than TPF :-)
PerlJam My experience with drupal is that as long as you aren't trying to customize it, it works well for the things it does.
pmichaud Andy: yes, I think it's drupal.
Andy casan: Are you concerned about my management of rakudo.org?
pmichaud Andy: I think Casan is speaking idealistically, not with respect to any particular person's abilities or biases. :-) 16:33
Casan Andy: heh absolutely not, things look to fine :)
Andy It's OK ifyou do.
nopaste "Infinoid" at 96.238.213.50 pasted "Another batch of Configure.pl header parsing errors from mesa-7.3rc1 (care of gentoo's "x11" overlay)" (134 lines) at nopaste.snit.ch/15306
pmichaud I'm not sure which wiki I dislike more -- the perlfoundation wiki (SocialText) or the one that is in drupal on parrot.org . 16:34
Casan Andy: yes as pmichaud mentioned, pure idealistically.
jonathan pmichaud: Is there a wiki you do like? ;-)
pmichaud jonathan: actually, the trac wiki is pretty darn good.
Andy pmichaud: We are not the target audience for Socialtext
pmichaud and yes, there's at least one other wiki I'm fond of, but I'm not sure the Perl 6 community would accept it :-)
jonathan pmichaud: I've been using Trac on one of the other projects I hack on. 16:35
Andy It's also sadly abandonware
as far as the open source version.
jonathan pmichaud: And have liked it and its wiki. Especially integration with tickets and revisions.
pmichaud jonathan: yes, I've also been having thoughts about moving rakudo tickets off of rt.perl.org
for similar reasons 16:36
dalek r35531 | jonathan++ | trunk/languages/perl6/src/parser:
: [rakudo] Parse does Foo[] (STD.pm does).
review: www.parrotvm.org/svn/parrot/revision?rev=35531
jonathan pmichaud: If we're going to stick with SVN, that makes sense.
PerlJam there's a git plugin for trac
(not sure how mature it is though)
jonathan Oh, really?
purl well, really is it bad?
jonathan In that case, if it works, my above point is happily moot. :-) 16:37
16:40 Tene joined
Whiteknight pmichaud, is there any indication about which builtins will be implemented in PIR and which will be in the prelude? 16:42
russell_h PerlJam: the Trac git plugin has some performance issues, but they can mostly be worked around afaik
Whiteknight because I would like to try my hand at writing a few of the more mundane builtins, but don't want to do it in the wrong place
pmichaud Whiteknight: those that can be done well in the prelude will be there
those that cannot won't.
basically, any builtin that can be written in terms of other primitives should probably do so, whether it's in PIR or prelude 16:43
we're really close to prelude in p6, though.
Whiteknight I was looking at Num.floor, Num.round, and Num.ceiling. Any idea where those should go?
PerlJam That sounded suspiciously like "write it in the prelude and if you come up against any roadblocks, that's probably where some PIR is needed" :-) 16:44
pmichaud Whiteknight: any-num.pir for now
if they don't exist already
because .floor, .round, and .ceiling are likely methods on Any
Whiteknight oh nevermind, they already are implemented there
(I was looking in classes/Num.pir) 16:45
pmichaud yes, lots of things that look like they belong in Num/Int/Str/List/Hash really go in Any
jonathan plays spot the difference with Rakudo and STD.pm's parameter rule 16:50
pmichaud bbiab
barney Is there a way to get all package scoped variables? I might want to get rid of the constant table and use package vars instead. 16:51
Coke_away pmichaud: per robert, the redirect will not be transparent, but will provide a "repository moved" message to clients. 16:53
... but I think you need a recent client to see the nice message. 16:56
Infinoid barney: (regarding your recent email) if all you need is a readonly repository, git://squawk.glines.org/parrot-trunk is a mirror updated once every 10 minutes 16:58
just trunk though, no branches
Coke_away looks like 1.3.2 client gives ugly message. 1.5.1 actually tells you where to redirect. 16:59
so this won't be completely transparent.
16:59 Theory joined
Coke_away So, feel free to update your threat assessment. Regards. Errands, here. 16:59
barney Infinoid: That's perfect. Im cloning it 17:00
17:05 sjn joined
pmichaud Coke_away: thanks for the update. I stand by my earlier assessments then -- moving today in this manner is a very bad idea and we should postpone. 17:07
Coke_away: it would also be nice if I could start being cc'ed on these communications.
(e.g., the message to and response from robert) 17:08
jonathan pmichaud: Is there an easy way to grab unique names/IDs?
(Only have to be unique within a sub...)
(er, a PAST::Block that is. 17:09
And in fact only within a signature...
pmichaud jonathan: you mean from actions.pm ?
jonathan Yes.
pmichaud PAST::Val( :value($block) )
returns the reference to the block.
(that's new in rvar) 17:10
jonathan pmichaud: Ah, no. I need many unique ones within a block.
pmichaud where $block is the PAST::Block structure
jonathan Ah, does it just have to be PAST::Blocks that I put in there?
pmichaud yes.
jonathan Ah
That won't quite cut it.
pmichaud using PAST::Val in this way doesn't generate the block code, it just returns a .const 'Sub' .... for whatever block you give it 17:11
jonathan sub foo(::T) { } is what i'm trying to make work.
japhb Infinoid: pong
pmichaud in that case, ::T is just a lexical within foo, yes?
jonathan Yeah, but the problem is that it's a type capture.
pmichaud just give it a dummy scalar 17:12
jonathan And we need to generate a parameter
Right, but it's what to *name* that dummy scalar. :-)
We need a unique name for each one.
Infinoid japhb: hi, I got some parse errors from a new version of opengl, and was wondering if you could take a look at them
jonathan Otherwise sub foo(::A, ::B) gets confused. :-)
pmichaud oh. You can use .unique on any PCT node to get a unique thingy.
japhb Infinoid: yeah, just got the msg from purl, looking now
Infinoid ok, thanks
pmichaud my $name = $block.unique('fakeparam');
er, := 17:13
I *think* you can also have nameless parameter nodes
dalek r35532 | bernhard++ | trunk:
: [docs] Add news about HQ9+ and Pipp
review: www.parrotvm.org/svn/parrot/revision?rev=35532
pmichaud and they're unique.
at least, I'm planning that parameters can be nameless.
jonathan oh awesome
japhb Infinoid: can you tar up your GL headers and send them to me? I think the fix is simple, but it I need to go spelunking.
jonathan .uniq works
pmichaud (i.e., you can use a parameter as an operand without that parameter having to have a lexical name) 17:14
jonathan pmichaud: Nameless won't quite work either, since we need to make an entry in @?BLOCK so the binding of ::T can work.)
But .unique does it just great. Thanks!
17:14 register left
pmichaud you just need an entry in @?BLOCK for T, right? 17:14
jonathan Sadly not. :-(
pmichaud okay.
.unique then
Infinoid japhb: can do, one moment 17:15
(sent) 17:16
japhb Infinoid: OK, waiting for mail server to have it. 17:18
Infinoid: just arrived. Damn, that took a while. 17:28
Infinoid probably greylisting 17:29
poor feather
japhb 'typedef void GLCchar;' ? Seriously? That's ... odd. 17:32
Hmmm, at least it's always used as a pointer. Now to figure out *why* this contortion ... 17:37
Infinoid someone probably thought it would be neat to redo all the typedefs again. 17:47
I sometimes doubt doubt much more thought goes into it than that
s/doubt //
japhb heh 17:49
Unfortunately, in order to make the binding not completely suck, I now need to understand the API. Sigh. 17:50
japhb shaves a yak
17:51 pdcawley joined, particle1 joined
Infinoid japhb++ # making a binding that doesn't suck 17:51
japhb well, trying to, at least. :-)
Well, the nice thing is that QuesoGLC is claiming to actually be performant enough for real apps. Which is damn good to hear, because back in the day there were no font renderers for GL that weren't either slow as molasses or bound to a particular desktop stack. 17:59
Infinoid yeah. last time I tried to render text in opengl, I think I used sdl for rendering it 18:01
18:01 particle joined
japhb ... and SDL's font rendering is, as I recall, relatively limited ... unless you like hand-drawing all your fonts into a big image. 18:02
Infinoid it kinda worked ... somehow. the interactions of those things are kinda spooky for me (not being too familiar with it all)
I had libgtk in there somewhere, too. what a mess
japhb I ended up designing my own stroke and bitmap fonts for drawing stats and debugging info on my GL windows, because everything available at the time (several years ago) was awful. 18:03
:-)
Oh. My. 18:11
Looks like characters are defined as void, because they are unicode, but can be represented as unsigned bytes, shorts, or ints in UCS1, UCS2, or UCS4, depending on the setting of a state variable. 18:12
(At least, that's what I'm reading in the semi-related GLS spec)
Infinoid uh 18:15
how does that even compile? 18:16
18:20 dalek joined, polyglotbot joined
dalek r35539 | Whiteknight++ | trunk/docs/book: 18:21
: [Book] Remove some stuff about the optimizer which was out of place, rework some sections about compilation units to offer more explanations and use up-to-date info.
review: www.parrotvm.org/svn/parrot/revision?rev=35539
Whiteknight I assume dalek is not working today?
haha, and as soon as I say something...
18:21 jonathan joined
Infinoid opbots, believe polyglotbot 18:21
clunker3 But I do not trust you Infinoid
slavorg Ok
slavorgn Ok
18:22 leo joined 18:23 ask_ joined, PerlJam joined, wolverian joined
japhb Infinoid: that's why the funky typedef of GLCchar to void. 18:24
Every string is a 'void *', interpreted based on runtime state. 18:25
Infinoid japhb: yeah, I just wouldn't expect passing void variables around to be very useful. (void* I could understand, but I didn't see a * in the typedef.)
guess it's added later 18:26
18:26 pmichaud joined
japhb Infinoid: Yup, and typedefing the pointer would have made sense. But instead, they always refer to 'GLCchar *'. 18:26
18:27 slavorg joined
Infinoid cool. not quite as nice as our STRINGs tho 18:27
dalek r35540 | Whiteknight++ | trunk/docs/book: 18:28
: [Book] Add a little footnote about .emit and .eom
review: www.parrotvm.org/svn/parrot/revision?rev=35540
Infinoid ask_: Last month, you mentioned playing with a git mirror for parrot. Was this just for fun, or is there a plan to go public with something like that? 18:29
japhb Nodnod. Well, it was defined a dozen years ago. Still, the GLS spec talks about how all API is done through the funky polymorphic UCS encoding, but the binary streams are always transcoded to UTF-8. So clearly they had a *hint* that that might be easier to work with .... 18:30
*cough* We should just switch to git entirely, like (say) Perl 5 did ... *cough* 18:31
PerlJam perks his ears
Infinoid japhb: I already tried that. see TT #138. :)
Are these strings ever read in from the opengl libraries? From the bindings' standpoint, if they're write-only, I think that makes things substantially easier.
barney Eclectus is now at \t git://github.com/bschmalhofer/eclectus.git 18:32
Coke_away barney: you're ripping out everything! =-)
Coke barney++
PerlJam yeah, barney++
japhb I know, and I'm unhappy that it was implicitly dismissed. The GNOME project did a study on what to change their source control to, and the top three were git (large lead), then Mercurial and Bazaar -- and apparently the number of people already using git for some other project was massive.
PerlJam (and Coke++ for starting the ball rolling) 18:33
jonathan ah, back...feather seemed to lose it's connection
Infinoid well, I don't intend to stop using git on the *client* side, in any case. though now I'm looking for tools to make that easier
particle japhb: it was not implicitly dismissed *for now*.
er,
moritz s/not/only/? 18:34
particle it was not implicitly dismissed. in was explicitly postponed.
japhb Infinoid: well, I suppose you could glGetString() and pass that into GLC, sure. But glGetString returns 'GLubyte *', so they've already crossed that bridge.
PerlJam japhb: Well ... why should parrot switch to git in any case? Why not hg or bzr or one of the other distributed SCMs?
(I'm pro-git, but I want to hear other opinions :)
Infinoid I haven't tried hg or bzr. I'm a big fan of monotone, but I haven't really considered using it for parrot 18:35
particle give me a client for a distributed vcs running on parrot, and i'll use that
japhb PerlJam: My personal reasons? 1) I know git more, 2) more people know git than the others, and 3) git is faster in the hot-cache case than either of the others, and that's the way we normally work.
PerlJam particle: so ... provide git bindings for parrot. /me adds an item to an ever-growing list. 18:36
japhb: what do you think would preclude parrot from staying in svn? (people can still use git clients all they want)
particle we have two releases before we go 1.0. i don't want to change our release procedures one bit unless we *must*. 18:37
Coke particle: then we probably should have delayed the svn move. =-)
PerlJam japhb: or, put another way, what problem does git solve?
donaldh www.gitcasts.com/ </troll> 18:38
PerlJam likes asking the questions a lot more than answering them :)
japhb particle, Coke: exactly. If we're going to be moving repos anyway, might as well take the opportunity to get on a modern source control system.
particle coke: the original plan was for conversion *after* 0.9.0
japhb: no. "svn switch -relocate" is much easier than "paradigm shift"
Infinoid ... when it works. which isn't always. (but I've already described that in detail in the ticket) 18:39
dalek r35541 | Whiteknight++ | trunk/docs/book:
: [Book] more info about strings, charsets/encodings, and escape sequences (some info stolen cold from PDD19)
review: www.parrotvm.org/svn/parrot/revision?rev=35541
Infinoid I don't feel too strongly about this at the moment. I just do all my work in git branches, and avoid svn branches like the plague. 18:40
so I hope you don't feel like I'm complaining too loudly :)
PerlJam reads the ticket ...
particle nobody's complaining too loudly
PerlJam Does that really mean, no one is complaining loud enough? :-) 18:41
japhb PerlJam: The thing that originally got me switching to git was that it worked offline like SVK, but it didn't constantly get corrupted, like SVK did. Then after using it for a while, I realized how much I loved the git mindset, and I switched other repositories I work with from SVN to git. And now I'm a happier person. Merges JUST WORK. rebasing is oh so nice, and so on.
Infinoid indeed, merge commits are a beautiful thing that svn still needs work on
PerlJam japhb: that's exactly my experience so far. I suspect almost everyone who has made the switch has had such experience. 18:42
japhb I find it ridiculous that I still need to keep an SVN checkout of Parrot just to do the silly SVN properties.
PerlJam japhb: you don't
Infinoid I do a svn checkout once a month, the day before a release, to make sure codingstd passes
japhb PerlJam: git-svn supports properties now? Oh happy day! 18:43
japhb aims a small nuclear device at ~/svn/ ...
PerlJam Hrm.
japhb looking at Infinoid's posted git-svn-dcommit patch to support auto-props ... 18:47
japhb boggles at writing an app in Perl and then writing all the tests for it in raw shell ... 18:48
18:48 iblechbot joined
PerlJam Infinoid: so ... that bi-directional gateway. That requires collusion from the svn side of things I think. 18:49
Infinoid yeah. the cheap way (just doing a dcommit whenever the log has commits that aren't tagged with git-svn-id:) has the problem of always showing up as commits from the same user 18:50
PerlJam a one-way gateway would be nice, but unfortunately, it would have to go the wrong way as git can handle random patches, but svn not so much.
Infinoid one-way gateway? meaning, readonly?
I have that right now. the problem is that you'd have to set up your repository to do commits directly, or use a script or somesuch 18:51
PerlJam right.
(I have a git-svn clone of parrot myself)
Infinoid and the readonly mirror I have is really just my git-svn bounce dir, so plan to adjust my commit methodology anyway
PerlJam A bidirectional gateway would also have to be very careful about what it was gatewaying. git supports "parallel history" while svn only supports "linear history" 18:53
Infinoid the mirror could map from Author emails to svn usernames when doing the commit, which wouldn't require any help on the svn server side of things, but then it would need password hashes for the committers 18:54
Infinoid isn't sure where git-svn stores that. 18:55
dalek r35542 | jonathan++ | trunk/languages/perl6/src (2 files):
: [rakudo] Parametric roles now clone methods, meaning that we get them attached to the right parameters.
review: www.parrotvm.org/svn/parrot/revision?rev=35542
Infinoid PerlJam: yeah, it would have to flatten it somehow. I think dcommit is used to that though
moritz Infinoid, PerlJam: are you sure that such a thing doesn't already exist?
Infinoid moritz: a simple google search didn't turn up any code 18:56
moritz given the wide spread of both git and svn, I'd be fairly disappointed if not
Infinoid most people just use git-svn on the client side, directly
PerlJam moritz: why have a gateway when there's git-svn?
Infinoid yeah, that.
purl Sure, that.
japhb Found the GNOME DVCS survey results analyses: github.com/blog/287-gnome-dvcs-survey (shorter), blogs.gnome.org/newren/2009/01/03/g...y-results/ (longer)
shorten japhb's url is at xrl.us/becinu
PerlJam moritz: I've *never* run across someone who wants to go the other way
Infinoid having an svn interface to a git repository would solve a lot of the problems with having to learn new tools, shifting paradigms, etc. 18:57
PerlJam The only reason we would want that is to make the transitional as gradual as necessary (or if the gateway worked well enough, those svn-lovers would never have to switch)
japhb A two-way mirror is definitely a smell to me -- it means that people doing work on the project are working around project management.
dalek r35543 | Whiteknight++ | trunk/docs/book: 18:58
: [Book] Add small bit about :unique_reg and the register allocator
review: www.parrotvm.org/svn/parrot/revision?rev=35543
Infinoid japhb: from a certain perspective, anyone who uses git-svn is doing that.
my interest in a two-way mirror is just to consolidate that effort somewhat
PerlJam japhb: no, it just means there's a schism in preferred SCM
japhb Infinoid: yes, I know. But then so is SVK, to a lesser extent, which used to be the recommended way.
Infinoid it doesn't actually solve any of the merging problems, it's just a time saver. 18:59
PerlJam svk is great as far as off-line commits go
merging is the real problem.
svn 15. makes the merging fiasco less painful, but there are still some odd limitations. 19:00
s/15\\./1.5/
dalek r35544 | Whiteknight++ | trunk/docs/book:
: [Book] Quick mention of .globalconst in the section about constants.
review: www.parrotvm.org/svn/parrot/revision?rev=35544
lathos So, how do I "register for trac", then? 19:01
Infinoid lathos: trac.parrot.org/parrot/register
japhb My point is that if so many of us say "We really want to be using git so bad that we'll take a brain-damaged version of it over raw SVN, or even SVK", then that should be a clue that we really need to change the master repo, not build up increasingly large workarounds (and two-way mirrors, unlike a client change, have the potential to really frack things up, thus giving the git haters something to hang an argument on -- I'd prefer not to g
ive them that.)
Infinoid true, I don't want to introduce any breakage 19:02
moritz japhb: but how many of us do really want to switch to git that badly?
PerlJam moritz: I'd like to.
lathos Right then. Done that, how do I get svn access?
japhb moritz: as far as I've been following things, quite a large percentage of those who have used git more than trivially. 19:03
PerlJam lathos: email allison or particle I think
Infinoid moritz: I'm using it already. I'm just proposing to make my existing infrastructure more public
dalek r35545 | Whiteknight++ | trunk/docs/book:
: [Book] A brief section about .loadlib and load_lib. Needs expanding.
review: www.parrotvm.org/svn/parrot/revision?rev=35545
particle "get svn access"?
lathos "Commit access on the new servers is managed through Trac, so if you're a
committer and haven't registered on Trac yet, please do so now, so we
can grant you svn permissions."
Infinoid or PerlJam's, or something like that. 19:04
japhb And again, though Parrot is certainly not a "Perl project", I think it's extremely telling that Perl 5 switched.
lathos I want to continue being able to commit to svn tomorrow, that's all.
Infinoid lathos: I think that just means get an account, which you've done
particle afaik, the parrot.org admins will do their best to give access to the same ids that perl.org had
PerlJam lathos: you could lend public support to the "don't switch yet!" crowd. 19:05
lathos DON'T SWITCH YET.
And egads don't switch to git.
particle i'm part of that crowd, too
PerlJam email parrotdev
lathos: what don't you like about git?
japhb lathos: what PerlJam just asked. ;-) 19:06
lathos It's another knowledge barrier to contribution.
Infinoid I've already gotten my answer about not switching to git, and am not pushing that argument any more.
moritz git doesn't fit my development well. I always forget to start a branch before doing changes, and that always results in (to me) weird errors when I pull 19:07
s/development/development model/
PerlJam lathos: so you would advocate staying with svn rather than changing to a "better" SCM?
japhb chromatic++ # An excellent rant on this subject via email
lathos PerlJam: Yep, definitely.
PerlJam fair poitn.
lathos Worse is better in this respect.
PerlJam er, point
particle git on windows needs some work. 19:08
japhb OK, so just to be clear lathos: You're advocating that we stick with a dumb VCS, because our developers are not as educated as Perl 5's developers?
lathos No.
Coke japhb: way to troll. awesome.
PerlJam heh 19:09
lathos And that's such a loaded question I'm not going to bother answering it.
Coke +1 for troll, -100 for helpfulness.
japhb Coke: thank you, thank you very much
Coke japhb: if you want to advocate for git, I recommend putting your thoughts down on the trac ticket.
barney Anything speaking against creating a .gitignore file in tools/dev/mk_manifest_and_skip ? Just a small convenience for git-svn users. 19:10
lathos I guess it's better than advocating that we always switch to whatever happens to be the newest shiny object and make our developers spend less time writing Parrot code and more time learning support systems.
PerlJam The smarter git-svn gets, the less "need" there will be for an "official" git repo of parrot.
japhb Seriously though ... yes, I worded that with malice aforethought I suppose, but my underlying question is still there: Why are we admitting (as a larger community) it's the right thing for Perl 5, but too high a barrier for Parrot. I really don't get that argument.
Coke Whiteknight: is .emit even legal syntax anywhere anymore? 19:11
lathos It's not the right thing for Perl 5, it's just what the Perl 5 people have done. Big difference.
japhb lathos: Interesting!
PerlJam Why did p5p switch? (Is there a mail thread about it?)
lathos Because Leon. 19:12
moritz japhb: perl 5 didn't switch from svn to git, and it has a different development model than parrot
japhb PerlJam: because it's not Perforce.
moritz PerlJam: because p4 isn't free. Because the pumpkings didn't like p4. Because it makes patch integration between branches easier
... because users without p4 access didn't have access to meta data 19:13
Whiteknight Coke: I'm not sure it if is or not. It was in IMCC last time I looked, but I haven't checked that there was any logic to back it up
japhb Or rather, someone thought it was a good idea to get off Perforce, did all the necessary work, and presented a beautiful working repo.
moritz (and there was no anonymous p4 checkout)
Coke Whiteknight: I thought it was ripped out years ago; .emit\\nsay 'hi'.eom fails.
Whiteknight Coke: I'm pretty sure that .emit just moves Flex into the PASM mode and not into PIR mode
lathos Yes, inded; Leon did it as a fait accompli. (Often the best way to do things; often the worst.)
Whiteknight I could be wrong, I'll do some tests and remove it if not
Coke Whiteknight: .emit isn't in t/
PerlJam okay, my question was really "why did p5p switch to git as opposed to something else?" (I know they needed to switch)
barney A good reason for switching to git, is that commit history in branches is easily available. 19:14
lathos PerlJam: Because Leon.
Infinoid I've never used perforce, but it seems quite rare that I hear anything good said about it 19:15
lathos I rather liked it, but there you go.
japhb And the reason for switching to git (aside from the personal preference of the repo creator), is that it is generally agreed to be the top dog DVCS.
lathos Generally agreed by its supporters. :)
PerlJam japhb: by who?
particle i heard good things about p4
Infinoid barney: yes, I really miss that with svn
japhb Infinoid: it was actually quite nice ... when it came out.
lathos SVN is pretty much the new CSV new. git isn't quite yet.
s/CSV/CVS/
Maybe in a few years. 19:16
PerlJam git is VC done right (but so is hg and bzr and others)
Infinoid from a newbie's perspective, git is VC done incredibly weirdly
lathos I thought arch was VC done right.
Infinoid but still not as weird as darcs/tla/whatever its called nowadays. 19:17
japhb PerlJam: See the links I posted earlier. The GNOME survey determined that lovers of every DVCS loved their own first, git second (if their favorite was not git), and all the other DVCS's less than SVN. So not only is git the most commonly loved DVCS, it is respected by the other DVCS lovers ... who otherwise all hate each other.
Whiteknight Coke, I think you're right. I can't find ".emit" in imcc.l anymore
lathos (And HURD is kernel done right. :)
PerlJam LOL
Infinoid well, git also has one hell of a reference project to work with. 19:18
(and it has done incredible things for it)
japhb Infinoid: YES.
Personally, I love git, I respect hg, and generally think of everything else as ranging from "meh" to "DEAR GOD LET ME FLEE". I mean, darcs had some great ideas. They were incorporated into the newer DVCS, without also bringing the slow. 19:19
PerlJam honestly, the main reason I use git today is because of who created it. a while back I was getting frustrated with svn and started looking for a replacement I saw hg, bzr, darcs, and git. I chose git based on name-recognition and "heck, he created linux, didn't he?"
Since git was far and away what I needed, I didn't really look at the others. 19:20
I suppose had I put an honest effort into learning bzr or hg or something, I'd be advocating one of those today 19:21
japhb lathos: arch, darcs, etc. helped set the stage, but like the early cars and planes, the general concept was good -- the implementation, often not so much. 19:22
Infinoid nowadays, git just seems to have more social inertia than the others. the common first reaction of someone reading a guide on obtaining a checkout with hg or bzr is like "so, that works like git, right?"
lathos I don't know why you're telling me. I don't give a shit.
PerlJam heh
japhb LOL
Casan VCS is like religion, thread carefully. 19:23
PerlJam vi!
emacs!
japhb I was waiting for that ...
Infinoid ne!
japhb padre ?
purl padre is, like, padre.perlide.org
lathos Casan: Not really; religion choice actually makes some difference to your life. 19:24
19:24 Robrt joined
PerlJam padre is almost a contender for the title 19:24
Robrt svn going down now, unless someone scream really loud.
japhb (Haven't actually used Padre yet, but it's definitely rising on the "interesting stuff" meter what with STD syntax highlighting and all ...)
moritz padre is thankfully not a religion ;-)
PerlJam Robrt: is this "the switch"?
Robrt PerlJam: so other people were supposed to have announced.
moritz Robrt: was pmichaud's scream on the mailing list loud enough?
Robrt moritz: I don't read the mailing list.
lathos Padre will be interesting when I can run it.
Casan lathos: in relation to emotions.. can become a steamed topic.
Infinoid and a neverending one :) 19:25
PerlJam Robrt: pmichaud would rather the switch not happen.
masak Robrt: something about that comment is vaguely worrying.
Robrt At all? Wow.
masak: which one?
masak Robrt: that you don't read the list.
lathos Also chromatic would rather the switch happens after the next release.
moritz Robrt: lists.parrot.org/pipermail/parrot-d...00943.html
shorten moritz's url is at xrl.us/beciqn
japhb lathos: VCS choice *does* make a difference to your life. It saves time and reduces stress.
Robrt PerlJam: Let me see if I can find Coke or Allison
PerlJam Robrt: "Can we please postpone this until we get a chance to decide how
Rakudo should transition in all of this?"
lathos japhb: You seem to have no sense of humour. 19:26
PerlJam quoting Pm
lathos This often happens with advocates.
Robrt Ugh.
I wish y'all could get your story together.
Also, Hi Simon. Long time.
japhb lathos: Sure I do. I'm smiling as I type.
lathos Hey Robert. Yes.
Robrt masak: I don't really have time or intereste to follow Parrot development right now.
masak Robrt: but you're involved in the switch? 19:27
lathos Robrt: If you don't have time or interest to follow Parrot development, please don't fucking get involved in breaking it.
japhb Robrt: actually, a couple of the complaints on the mailing list were that people didn't even know something was happening today, so didn't get a chance to get said story together.
Robrt masak: I run the infrastructure.
masak Robrt: that's the worrying part, then.
moritz Robrt: I know you have no part in this, but most of us imagined the transition (and communication before it) quite differently
masak this affects devs.
Robrt japhb: Don't blame me.
moritz japhb: Robrt is just doing what he was asked to, and so far did a great job
Infinoid wow. guys, this isn't Robrt's fault. 19:28
Robrt I'll hold off for now and fire off an email to the involved. No skin off my back if we wait.
japhb Robrt: I wasn't. Er, just trying to let you know re: "Ugh. I wish y'all could get your story together."
masak I'm also not blaming Robrt
Robrt japhb: yes. "communication is hard"
masak but clearly there has been too little consensus about the move.
Robrt Anyway, I have come here, seen the screams of anguish, will go back and ask the people who asked me to do this what they want.
lathos Good plan.
japhb Robrt: exactly. And for what it's worth, I agree with moritz and Infinoid -- not blaming you.
Infinoid thanks for your help, Robrt 19:29
PerlJam Yeah, Robrt++ for putting up with the flak even
japhb OK, so anyway, I think I've said my peace for the moment on the git issue. Now back to trying to solve Infinoid's OpenGL problems ... 19:30
19:31 particle left
Whiteknight great, I've spent the last few hours mentally preparing for a move that isn't happening. It's like SVN blueballs over here 19:33
japhb LOL 19:36
Casan well then.. what is the outcome of all this? (though I assume it is not finalized). should the developers prepare for a change that is already defined but the time, or a change which will be defined after a more thorough evaluation by pmichaud et al. ?
Infinoid I don't know. I assume the switchover will happen at some point; I don't really mind either way. 19:37
moritz Casan: allison seems to be fairly determined on moving to a svn server at parrot.org 19:38
Infinoid will keep working locally, and defer worrying about how to commit
moritz Casan: apart from that, nothing is clear
Casan ok, intentions exist, definitions do not.
barney I plan to move Pipp after the January release 19:39
Robrt Because of how we're doing the switch, you shouldn't need to re-checkout after the move. (if/when we move) 19:42
just svn switch --relocate
Coke Robrt: I called it off. 19:43
Whiteknight Are there any languages in languages/ that are basically abandoned?
19:43 braceta joined
Coke Whiteknight: most of them? 19:43
purl i heard most of them was because of the stupid 01_request failure
Coke Whiteknight: anything that doesn't build is a good candidate.
Robrt Coke: cool. standing down from red alert.
Coke Robrt: sorry about the fire drill. we'll do better next time. Thanks for putting up with us. 19:44
pmichaud Robrt: sorry for the inconvenience
Whiteknight because I would start moving a few of them out to new repos, but I dont wan to step on any toes
pmichaud Robrt: and thanks for your ongoing support/help
Coke Whiteknight: if a maintainer is listed, ping them.
if they don't care, we can move it over to squawk.
Robrt nods.
no problemo
Coke no point in creating a brand new repo for something that doesn't have a lot of commits.
(honestly, no point in doing that, even, i suppose.) 19:45
we can always just say "look in the repo at version foo"
thalhammer?
pmichaud Coke: thank you for calling off the switch.
Coke Robrt: as long as you're here... 19:46
Robrt ... 19:47
Coke has anyone talked to you about carving out languages/perl6 into svn.perl.org/rakudo ? (or something similar) ?
barney Whiteknight: There should also be a MAINTAINER file within the language
Robrt Nope.
Nobody's discussed it.
pmichaud Coke: we're still looking at whether we want to do git or svn.
Coke Ok. I suspect patrick will be doing that shortly if they pick svn.
Robrt nods.
pmichaud and my expectation was that we'd have that discussion around the January release.
Robrt We've been moving a lot of our other stuff towards git. 19:48
it's the current hotness.
pmichaud Robrt: while we're on the subject, do you have a preference from an admin perspective?
Robrt At the moment we don't have a hosted git solution, iirc.
Coke (is there a conversion path from svn to git?)
ah.
Robrt There is a very good conversion path.
japhb Coke: yes, it works quite well.
Robrt We're in the middle of converting qpsmtpd, which will be our test case.
Coke pmichaud: is your plan to just take those things in languages/perl6 and have that be the top level of your new repo? 19:49
pmichaud Coke: well, I needed to look a bit more at how to handle a separate Parrot (e.g., follow partcl's lead)
Coke (I presume you want to keep your version history, e.g.)
pmichaud but yes, I'd like to keep version history.
If it's likely that Rakudo will move to git at some point in the next ~6 months, I'd like to do that now instead of having two repo moves in that period of time. 19:50
Coke I suppose worst case you could just clone the repo, and then rip out everything and move your directory up two levels.
pmichaud but there's also the question of what web site we want people to go to for rakudo stuff. 19:51
Robrt Coke: I'm heading to lunch, and then a meeting, will try and keep this window open if I can. But at the moment the short version is: We don't have a scheme for supporting git, although I think we know how we'd do it. But moving git repositories around is a lot easier than moving svn repositories, so even if the repo was on github or something, it's easy to change later with no loss.
pmichaud Robrt: that's extremely useful and helpful information, thank you.
barney git filter-branch --subdirectory-filter languages/eclectus/ worked fine 19:52
Robrt To luch I go.
Infinoid lunch, great idea.
bbl &
Coke pmichaud: our next window to do this may very well be shortly after the release next week. 19:55
pmichaud Coke: that is okay. 19:56
Coke: there's a big difference between "1 week notice" and "4 hours notice". I can at least have a plan in place and alert people it's coming.
There are a lot of people who use Parrot now who are *not* on parrot-dev, and have no desire to be.
Coke so how would we announce things to them? (I'm adding something to the website now.) 19:57
moritz Coke: through p6-announce, the blogs, p6u, #perl6, ... 19:58
pmichaud perl6-compiler is a good start.
So are the use.perl blogs, Planet Perl 6, Rakudo.org, etc.
19:58 rurban_ joined
pmichaud the rakudoperl twitter feed 19:58
tewk Whiteknight: can/is generational_ms.c used? where is the memory barrier code?
Whiteknight tewk, generational_ms.c is not used and is probably broken very very badly 19:59
memory barrier code used to be in include/parrot/dod.h, but I think that file has been renamed
tewk :q 20:00
Whiteknight include/parrot/gc_api.c
tewk, I wanted to ask you what was the status of the ecmascript language?
TimToady phone
Coke note added to www.parrot.org/download 20:01
20:02 particle joined
tewk Whiteknight: I just tried to work on it a little lately, it does very little right now. I really don't have time to spend on it. :( 20:03
Whiteknight okay 20:04
tewk I don't claim ownership, anyone can do as they please with ecmascript 20:05
Whiteknight I'm just thinking about where/when to move it out of the parrot repo 20:06
tewk git, github if nothing else. I'm kinda sad to see languages leave the repo, I think they will rot. 20:07
Coke tewk: they need a champion to work on them.
tewk It be nice if parrot.org could start a langauge incubator repo or something.
Coke or they'll rot /in/ the repository.
japhb tewk: I agree ... but unfortunately, the are already. :-(
Coke tewk: squawk.googlecode.com
japhb It's not git, but it's still nice to see a combined, relatively obvious repo for various HLLs to share. ++ to whomever set that up. 20:09
Coke particle.
purl mailto:jerry.gay@gmail.com
Coke wve.
wave.
wave is mailto:jerry.gay@gmail.com
japhb
.oO( Maybe we should set up a similar repo on github, and let language owners decide where they want to work. Then again, maybe that just makes things worse. Hmmm. )
 20:12
Coke if this is just a place for languages to go so we don't kill them, then here is fine. 20:13
if they want git, they can move it there on their own.
git: as in, "you stupid git." 20:14
Whiteknight yeah, this seems like a great place for language projects that aren't self-sustaining
once language projects to become more popular, of course they are going to want their own development environment 20:16
Coke yup. 20:17
we might want to eschew squawk.googlecode.org and just leave them at the old version of the repository. 20:18
and put up a wiki page on trac pointing at them;
then if someone wants it, they can just /start/ it, instead of /move/ it.
Whiteknight can you make me a member of that squawk project? 20:19
tewk Whiteknight: Gc_gms_hdr seems like a lot of overhead per object.
Whiteknight Gc_gms_hdr is a lot of overhead per object
Coke Whiteknight: what's your googleid?
Whiteknight the GMS collector isn't the one I wrote over the summer
Coke: wknight8111@gmail.com 20:20
Coke Whiteknight: done
Whiteknight w00t
Coke I think the top level dir in trunk here should be as it is under languages/
japhb Coke: The downside of leaving the languages in the old version of the repo is that people who *do* decide to pick up a language will be left with false expectations -- namely, that when they revive the language, it will be part of the master parrot repo again, and can assume that directory structure, etc.
Coke so languages/tcl is "tcl/" in squawk.
japhb: fair enough.
doesn't hurt to make a snapshot copy in squawk. 20:21
japhb nodnod
Whiteknight and the old repo will probably contain an old version of Parrot
japhb yup
Coke rdice++
japhb Coke: what happened? 20:23
purl We don't know what happened, so tell everyone nothing happened.
Coke is on a con call that richard is talking on right now. 20:24
japhb ah 20:25
Infinoid purl: nothing happened, and we loved every minute of it.
purl Infinoid: what?
Coke what? 20:32
what is <reply>What?
what?
Coke smacks purl.
purl Oh baby, you do it so *good*!
Whiteknight is very disturbed by this bot 20:33
purl what is <reply> What? 20:34
purl no idea, whiteknight
Whiteknight purl, what is <reply> What?
purl whiteknight: no idea
Whiteknight purl, what? is <reply> What?
purl <reply> is maybe... or
Whiteknight what?
Coke give up. =-) 20:37
moritz that /thing/ is just not logical 20:38
Coke purl, your mother.
purl purl's mother is the root of all evil.
20:39 mberends joined 20:45 donaldh joined
Whiteknight purl is probably written in some goofy programming language, like perl 20:46
lathos Some obsolete version of it too, no doubt.
Whiteknight a bunch of silly pseudocode line noise
dalek r35546 | bernhard++ | trunk (2 files): 20:47
: [codingstd] delete trailing whitespace
review: www.parrotvm.org/svn/parrot/revision?rev=35546
r35547 | bernhard++ | trunk/languages/perl6/src (3 files): 20:48
: [codingstd] trailing spaces
review: www.parrotvm.org/svn/parrot/revision?rev=35547
Coke TimToady: dropping off call due to $DAYJOB 20:50
dalek r35548 | jonathan++ | trunk/languages/perl6/src/parser: 20:52
: [rakudo] Try to fix END blocks to work with pre-compiled modules and with lexicals.
review: www.parrotvm.org/svn/parrot/revision?rev=35548
r35549 | jonathan++ | trunk/languages/perl6/t/pmc: 20:53
: [rakudo] Fix make test by tracking roles change in PIR tests for Perl6MultiSub.
review: www.parrotvm.org/svn/parrot/revision?rev=35549
r35550 | moritz++ | trunk/languages/perl6/t: 20:55
: [rakudo] add test for bare 'say' being an error to t/spectest.data
review: www.parrotvm.org/svn/parrot/revision?rev=35550
r35551 | bernhard++ | trunk/tools/dev: 21:05
: [codingstd] make Perl::Critic happy
review: www.parrotvm.org/svn/parrot/revision?rev=35551
r35552 | fperrad++ | trunk/languages/lua/config/makefiles: 21:20
: [Lua]
: - some libraries are conditional
review: www.parrotvm.org/svn/parrot/revision?rev=35552
nopaste "barney" at 84.154.4.83 pasted "strange 'loadlib' effect" (4 lines) at nopaste.snit.ch/15310 21:22
21:22 Tene_ joined
Coke eclectus was removed, right? 21:27
barney yes, moved to github 21:28
Coke (ack -al eclectus still shows a lot of removable hits)
dalek r35553 | simon++ | branches/strings/pseudocode (2 files): 21:33
: Finish copying the function signatures into the Perl code, now time to implement them all.
review: www.parrotvm.org/svn/parrot/revision?rev=35553
Coke makes "make TEST_JOBS=3" work for tcl's core tests. 21:38
dalek r35554 | fperrad++ | trunk/languages/lua (2 files): 21:40
: [Lua]
: - add a Configure.pl
review: www.parrotvm.org/svn/parrot/revision?rev=35554
r35555 | fperrad++ | trunk/languages/markdown (2 files): 21:42
: [Markdown]
: - add a Configure.pl
review: www.parrotvm.org/svn/parrot/revision?rev=35555
r35556 | fperrad++ | trunk/languages/WMLScript (2 files): 21:43
: [WMLScript]
: - add a Configure.pl
review: www.parrotvm.org/svn/parrot/revision?rev=35556
r35557 | bernhard++ | trunk/languages/t: 21:44
: Don't mention eclectus in languages/t/harness
review: www.parrotvm.org/svn/parrot/revision?rev=35557
r35558 | bernhard++ | trunk: 21:45
: Don't mention eclectus in MANIFEST.generated
review: www.parrotvm.org/svn/parrot/revision?rev=35558
r35559 | jonathan++ | trunk/languages/perl6/src/builtins:
: [rakudo] When composing attributes into a role, we need to carry any properties along with them, otherwise default values and traits and so forth don't work.
review: www.parrotvm.org/svn/parrot/revision?rev=35559
Coke whee. make test with jobs=3 takes 116s, down from 200+ single threaded.
(for partcl)
dalek r35560 | jonathan++ | trunk/languages/perl6/src/parser: 21:47
: [rakudo] Since when we are parsing a signature we may be doing it for a package now (e.g. a parameterized role), we may already have got a block created. So check for this and use the existing one if so (otherwise we lose $block<pkgdecl>).
review: www.parrotvm.org/svn/parrot/revision?rev=35560
barney Coke: for some reason svn might not remove languages/eclectus
dalek r35561 | fperrad++ | trunk: 21:48
: update MANIFEST
review: www.parrotvm.org/svn/parrot/revision?rev=35561
moritz if there are user-generated files in the dir, like Makefile, it's not removed
dalek r35562 | bernhard++ | trunk: 21:49
: Show 'eclectus' and 'hq9plus' in 'svn status' if they are there.
review: www.parrotvm.org/svn/parrot/revision?rev=35562
r35563 | bernhard++ | trunk: 21:50
: remove eclectus and hq9plus from MANIFEST.SKIP
review: www.parrotvm.org/svn/parrot/revision?rev=35563
barney Ah I did a 'ack-grep -il' not a 'ack-grep -ial' when removing eclectus 21:56
lathos How do I alias one method to another in P6? 22:00
&B := &A does not do what I expect.
("A method named 'A' already exists in class 'Foo'. It may have been supplied by a role.")
pmichaud Binding has some issues in Rakudo.
I don't know about method binding, though.
lathos OK. For now I'll just call it directly. 22:01
jonathan I don't even know what the syntax is for that.
&B := &A relies on the methods being look-up-able in the namespace...
Or are they meant to be? 22:02
jonathan can never quite remember that one
22:03 Whiteknight joined
dalek r35564 | bernhard++ | trunk/config/gen/makefiles: 22:04
: Remove moved languages from config/gen/makefiles/languages.in
review: www.parrotvm.org/svn/parrot/revision?rev=35564
r35565 | bernhard++ | trunk: 22:05
: Remove hq9plus from MANIFEST.generated
review: www.parrotvm.org/svn/parrot/revision?rev=35565
22:05 iblechbot joined 22:12 particle1 joined, Robrt left
tewk Whiteknight: ping 22:28
Whiteknight Tewk: pong! 22:29
22:29 gryphon joined
dalek r35566 | bernhard++ | trunk/tools/dev: 22:36
: [codingstd] svn props for new file
review: www.parrotvm.org/svn/parrot/revision?rev=35566
japhb Oh dear heavens, the GLC string handling is crazy: quesoglc.sourceforge.net/group__con...5b2f2af9d9 22:42
shorten japhb's url is at xrl.us/becjkt
Whiteknight Where's the PMC Unionval ticket? RT or TT?
barney trac.parrot.org/parrot/wiki/PMCUni...onTasklist 22:43
cotto rt
the wiki page has a link to the rt
22:44 Casan joined 23:26 Tene joined
Whiteknight thanks barney, I posted a note there 23:26
23:28 Limbic_Region joined
Infinoid japhb: yep, that's insane 23:33
parrot++ # stashing encoding info in the string structure
japhb Infinoid: hmm. I'm tempted to say that for the time being, I'll just leave it as is (void pointers back and forth). In the longer term I see three options to do better: 23:40
1. Force UTF-8 mode, and use NCI's native cstring conversion. 23:41
2. Add explicit extra routines to do the conversions.
23:42 TiMBuS joined
japhb 3. Rewrap each routine that touches GLCchar * with something that introspects parrot's string structures and autoconverts. 23:42
Infinoid option #1 doesn't seem so bad. if I understand their motivation correctly, it's to adapt to systems which normally use this or that string format, right? handling encodings on a per-string basis is probably a bit overboard for the typical QuesoGLC user.
japhb That last one involves additional magic to watch for context and string type changing out from under the library, sigh. 23:43
GeJ Good morning everyone
Coke_away does PCT give an easy way to track line numbes of source?
Infinoid hi GeJ 23:44
GeJ heya Infinoid
purl i guess Infinoid is Mark Glines <mailto:mark@glines.org>
Coke (without that, the annotation stuff isn't as useful. =-)
GeJ purl: I knew that, but thanks
purl de nada GeJ
jonathan Coke: I believe after the Cursor refactor that is forthcoming shortly, PGE should help with that.
Infinoid ohnoes, my true identity is exposed
Coke (PGE) awesome. then I don't have to do PCT yet. =-)
GeJ msg Whiteknight The CLA has been snail-mailed. 23:45
purl Message for whiteknight stored.
japhb Infinoid: yes, in general, that's the motivation for the string format craziness. As for option #1, there's a part of me that doesn't like dumbing down the library unnecessarily -- what if someone's running on Windows and has UTF-16 string translation files? 23:46
Hmmm, Option 3a: Rewrap with something that checks if the parrot-side string is in same format as the current GLC string type -- if so, just pass through; if not, temporarily GLC string type to match, if possible; otherwise, ask Parrot to do a conversion. 23:48
Wait, does Parrot know how to do inter-encoding conversions?
"temporarily *set* GLC string type to match" 23:49
Infinoid I would say "yes", but...
/* XXX Apparently unwritten RT #58188 */
Parrot_ex_throw_from_c_args(interp, NULL, EXCEPTION_UNIMPLEMENTED,
"Can't find encoding converters yet.");
japhb oh bleah. 23:50
Infinoid you could also do this in stages. passing every string format with full performance for full profit doesn't have to happen on day one :)
japhb nodnod 23:51
lathos I'm working on it. :)
japhb lathos: you mean the encoding converters?
lathos Yes.
japhb Ah cool, thank you.
lathos Or, well, strings as a whole.
japhb even better.
lathos Gonna take a month or so though.
japhb I'd be really surprised if it was much quicker than that .... 23:52
23:54 Whiteknight joined, galf joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!