Parrot 2.3.0 Released | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: apply deprecations, merge branches, test exceptions_refactor branch | welcome our GSoC students
Set by moderator on 27 April 2010.
tcurtis I stand corrected. 00:02
Or answered, I suppose, given that I did use a question mark. 00:03
cotto_work Interesting. I was wondering if you'd be frustrated that I gave you a related link instead of answering your question. 00:04
tcurtis The link did answer my question, though. 00:14
Coke yawns. 00:16
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33616), fulltest) at r46258 - Ubuntu 10.04 amd64 (g++)
00:16 eternaleye joined
Coke ponders a reply to kid51's massive tome. 00:27
Coke thinks it boils down to "we already tried that."
bacek_at_work Coke, "tried" what? 00:28
dalek rrot: r46259 | coke++ | trunk (13 files):
Migrate File and OS PMCs to dynamic PMCs.
 00:29
Coke bacek_at_work: explaining exactly why we like git better. 00:31
ISTR there are many wiki pages to that effect.
bacek_at_work Yeah...
Didn't work...
purl But it DID do exactly what you told it do. :D
Coke I agree that we might as well wait until yapc.
(to change anything. we should be ready to pull the trigger then, though.) 00:32
bacek_at_work Why? One of proposal for GSoC development is independent git/svn repos
Coke I also don't particular care for the swipe at "parrot's leadership".
bacek_at_work: because at YAPC we'll have at least a dozen of us in one place who can have a f2f conversation. 00:33
chromatic I don't want to change anything until after Rakudo Star.
bacek_at_work Then just discuss it. And made good decision. Like "move it NOW" :)
Coke msg kid51 board elections coming up at some point. You could put your name in the ring. Also, if you'd like to see something get done and it's not getting done, you can talk about it, or even do it yourself. 00:34
purl Message for kid51 stored.
Coke chromatic: so, yapc is a good point, methinks.
Coke closes a very old ticket.
chromatic YAPC is only a good point if we can move the discussion past "I can't work like this" and "I'm a super genius, and I can use SVN effectively without making the mess you make." 00:36
cotto_work is making a concerted effort to move to "I can make this work but there are better ways." 00:37
dalek TT #448 closed by coke++: [TODO] Migrate non-essential PMCs to dynpmcs 00:38
TT #448: trac.parrot.org/parrot/ticket/448
sorear I still need to learn to properly hate svn 00:42
darbelo There is one problem here. You can't convince allison that svn doesn't work: It works for her.
cotto_work sorear: you could try to clean up the ops_pct branch
Coke we don't have to convince allison that she is having trouble.
00:43 snarkyboojum joined
chromatic allison's not the only person we have to convince of anything either. 00:43
Coke I'm not entirely convinced we need to convince her /we're/ having trouble at this point.
00:44 ruoso joined
Coke If we have people willing to shoulder the administrative burden of updating, and some large %-age of people that prefer and or don't care about the switch... 00:44
darbelo And yet, the debates I've seen degenerate into 'It sucks and is broken' vs 'works for me, you are using it wrong'
cotto_work Yeah. Getting past that point is key to making progress (fsvo progress).
chromatic I don't know how to argue that any model that throws away commit history is anything other than wrong. 00:45
sorear I need a character sheet, I can't remember who the git users are anymore
darbelo svn haters? 00:46
purl i think svn haters is cotto or plobsing or darbelo or *really* sorear or (but only if he's not core)
Coke on a /positive/ note, I've opened a ticket with OSU OSL to setup an experimental git/trac/svn setup. 00:47
Tene sorear: you mean "cheat sheet"? Been RPGing lately? 00:48
darbelo Another data point: We have at least one active contributor who is against git.
sorear no, I'm not really sure what I mean
I'm just joking about how we don't actually have any "git is 100% good" or "git is 0% good" people 00:49
Coke darbelo: aside from allison?
chromatic NotFound, I think.
darbelo From what I remember NotFound doesn't use git at all.
Coke msg NotFound Hey, what are your feelings about a potential switch to git? 00:52
purl Message for notfound stored.
Coke (since the last "person doesn't want git" reference we had was just debunked...)
darbelo For the record, I'm perfectly happy with !svn. Anything that can do speedy, clean branch merges and runs on OpenBSD is fine by me. 00:55
svn doesn't, so it has to go. Replacing it with anything else is fine by me.
On the note, I'm going out for food. 00:56
Coke mmm, fud.
ttbot Parrot trunk/ r46259 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/293076.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 01:02
Coke someone needs to regen the pbcs, btw. 01:03
Whiteknight I'm a git preferrer, though it's a small preference. All my personal projects are done in git. I won't create a project in SVN anymore 01:05
of course, I'm terribly bad at git, I don't understand much of it and I can only competently use about 4 commands
If I used it more, especially in projects with multiple contributors, I suspect my skills would improve 01:06
...or my ineptitude would become more obvious 01:07
01:07 eternaleye joined
chromatic You don't need more than a handful of commands. 01:07
That's what surprises me about the discussion.
Windows support? That's a legitimate question. 01:08
Ease of learning? I just don't see it.
Coke I cannot duplicate that taptinder failure. 01:10
learning git? 01:12
Whiteknight I don't know if it's easy to learn, I might have a learning disability 01:13
plus, I don't know any more SVN commands
Coke www.syntevo.com/smartgit/index.html (windows git client) ?
chromatic The basic operations of git and svn have almost identical syntax. There's one difference: git has an index where you stage commits. 01:14
Whiteknight What I need to find is a really good git client for VisualStudio 01:15
chromatic How about a really good compiler for Windows? 01:16
Whiteknight Everything I do at work is C#, and VisualStudio is pretty damn good with that
chromatic Yeah, but no one expects the bear to dance well. 01:17
Whiteknight C# has quickly become my language of choice for most things
Coke ... I /think/ that fixes the taptinder error. I also thought I already did that loadlib. 01:26
dalek rrot: r46260 | coke++ | trunk (2 files):
OS is a dynpmc - use the dynpmc and depend on it.
 01:34
Coke src/pmc/threadinterpreter.c needs to be manual or auto attrs. which one? 01:35
(what's the default?)
sorear they're basically the same 01:37
all auto_attrs does is automate malloc in VTABLE new and free in VTABLE destroy
(well, it's actually a FixedSizePool call)
Coke ... if they were the same, there wouldn't be 2 different options. =-) 01:39
(I hope.)
(can someone on the right platform regen the native pbcs?) 01:41
cotto manual_attrs looks right 01:45
Coke that's what I guessed. 01:46
(though potentially it should inherit from the parent.) 01:47
anyway, committed.
why did "method lower on string" get put as 3.1 and not 2.7 ? 01:48
dalek rrot: r46261 | coke++ | trunk (3 files):
make auto or manual _attrs required, closing TT #1506
 01:50
01:53 Andy joined
Coke ANDY 01:53
Andy COKE
sorear Coke: Make sure you have the right andy. 01:54
Andy HE KNOWS WHO IS WHO
I AM THE ORIGINAL.
Coke hurm. I think from my standpoint, yes, you are the original. 01:55
Coke finds more crap to rip out...
chromatic++ # all the work he did making our test suite ||-izable. 01:56
++<anyone else>
Andy COKE: DID YOU NEED SOMETHING 01:57
OVER
chromatic Mostly other people; I only fixed a few problems.
01:59 Psyche^ joined
Coke Andy: NO STANDARD GREETING, OVER. 02:00
Andy NEXT PROJECT FOR ME: CONSTING VIRTUAL FUNCTIONS
dalek TT #1506 closed by coke++: PMC attribute allocation flags design and evolution 02:01
TT #1506: trac.parrot.org/parrot/ticket/1506
TT #876 closed by coke++: Deprecate pushaction, pushmark, popmark
TT #876: trac.parrot.org/parrot/ticket/876
02:07 JimmyZ joined
dalek rrot: r46262 | coke++ | trunk (7 files):
Remove pushaction, pushmark, and popmark opcodes.
 02:07
rrot: r46263 | coke++ | trunk/DEPRECATED.pod:
These were removed in r46055.
cotto Coke, have you given Rakudo a patch for auto/manual attrs? 02:11
Coke nope. 02:12
cotto might make life simpler for them
Coke do our public headers fall under the support policy or no?
cotto: no doubt. 02:13
(i'd like to change, e.g. sub_flags_enum)
sorear 'FOO'() # After IMCC compiles this code, where does Parrot search for the name?
Current namespace?
HLL root namespace? 02:14
Lexpad?
purl it has been said that Lexpad is related to a Sub - not to a Continuations
sorear Dynamic chain?
All of the above?
Coke msg NotFound I took one of your tickets and closed it. sorry, Didn't check first; feel free to beat me up if I did I wrong. 02:18
purl Message for notfound stored.
dalek rrot: r46264 | coke++ | trunk/include/parrot/sub.h:
Remove unneeded enum element, patch Courtesy Bob Rogers.
 02:24
chromatic sub.h isn't a public header 02:26
02:36 janus joined
Coke good. 02:40
dalek rrot: r46265 | gerd++ | trunk/config/gen/makefiles (2 files):
make the pdf target also available for Windows
 02:56
02:58 plobsing joined 03:01 snarkyboojum joined 03:02 Andy joined
Coke "Moral of the story: even insane-looking problems are sometimes real." 03:03
03:03 Andy joined
Coke Andy: hey, can you whip up a list of all functions marked with PARROT_API for me? 03:06
Andy There's this fine programming language you might have heard of called Perl. 03:07
It is able to parse text easily.
Aaaactually, I think there's a switch in the headerizer for it.
Coke Andy: nevermind.
Andy did you find it? 03:08
I'm about to go look for it.
Coke Andy: nevermind.
Andy Even still, you can say "make apilist" which is everythign PARROT_EXPORT 03:13
chromatic We might need to bikeshed that name when we make a strong distinction between PARROT_API and PARROT_EXPORT. 03:16
Coke spif. danke. 03:17
Andy I was thinking that, too, chromatic 03:18
making change now
chromatic Excellent! 03:19
purl plays air guitar
dalek TT #1585 closed by coke++: rename STRING_is_null to Parrot_str_is_null 03:23
TT #1585: trac.parrot.org/parrot/ticket/1585
03:26 JimmyZ_ joined
dalek rrot: r46266 | coke++ | trunk (3 files):
"rename STRING_is_null to Parrot_str_is_null"
 03:29
rrot: r46267 | coke++ | trunk/DEPRECATED.pod:
follow marking standard for experimentals...
03:42 JimmyZ_ joined
dalek rrot: r46268 | coke++ | trunk (7 files):
rename Parrot_string_cstring to Parrot_str_cstring
 03:45
Coke thinks he's done now. 03:52
dalek TT #1586 closed by coke++: rename Parrot_string_cstring to Parrot_str_cstring 03:56
TT #1586: trac.parrot.org/parrot/ticket/1586
tcurtis chromatic: I probably will be able to attend #ps tomorrow. Have to go see a doctor. I might possibly be able to catch the end of it, but that's uncertain. 04:01
Will not, rather.
dalek rrot: r46269 | petdance++ | trunk/config/gen/makefiles/root.in:
Makefile target apilist lists PARROT_API functions, and exportlist lists PARROT_EXPORT. But headerizer has to support the apilist target yet.
 04:02
04:02 parthm joined 04:10 JimmyZ_ joined
GeJ I have several errors like "PackFile_unpack: This Parrot cannot read bytecode files with version 6.12." while testing after a realclean, is there something I forgot to do? Do I need to regenerate something? 04:15
bacek_at_work GeJ, just update to r46270 04:21
cotto also, reconfig 04:24
nm. just update
dalek rrot: r46270 | bacek++ | trunk/t/native_pbc (4 files):
Rebuild native PBC
 04:34
rrot: r46271 | plobsing++ | branches/pbc_frozen_strings1:
branch merged
04:43 LoganLK joined
dalek rrot: r46272 | petdance++ | trunk (5 files):
adding headerizer macros
 04:51
05:01 szabgab joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33618), fulltest) at r46271 - Ubuntu 10.04 amd64 (gcc with --optimize) 05:05
Coke partcl-nqp's vtable overrides are not functioning. 05:22
05:24 eternaleye joined
dalek rrot: r46273 | coke++ | trunk/MANIFEST.generated:
Install our new dynpmcs.
 05:24
Coke blargh, exceptions got renumbered. 05:35
that's going to break a bunch of NQP users. 05:40
(though I may be late to the party here) 05:41
partcl-nqp passes 'make testj' against trunk again. whee.
dalek rtcl-nqp: 5b9b672 | Coke++ | src/Partcl/commands/string.pm:
update from deleted opcode.
 05:43
rtcl-nqp: 148c88f | Coke++ | src/init.pm:
these are now dynpmcs, load them.
rtcl-nqp: b973ff1 | Coke++ | src/Tcl (2 files):
Post TT#389, these methods are no longer stored in the namespace. Find them explicitly.
rtcl-nqp: 2e00896 | Coke++ | build/PARROT_REVISION:
Track latest parrot
rtcl-nqp: ec2c800 | Coke++ | src/Partcl/commands/ (2 files):
Track exception renumbering.
mikehh Coke: haven't done any testing on partcl-nqp - where's it at now?
ok I see 05:44
Coke needed some love after 2.3.0 05:47
-> abed.
mikehh cu
All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33619), fulltest) at r46273 - Ubuntu 10.04 amd64 (g++) 05:53
sorear How is super. spelled in PIR? 05:56
Austin diy 05:57
sorear How?
Austin (or have a look at kakapo)
05:57 Coke joined
sorear kakapo is NQP though. 05:58
Austin gitorious.net/kakapo/kakapo/blobs/m...Syntax.nqp 05:59
06:04 uniejo joined 06:24 iblechbot joined
cotto dukeleto++ 06:37
(parrot-dev post)
06:41 aukjan joined 06:44 jsut joined 06:45 eternaleye joined 06:46 riffraff joined
moritz rakudo can't build on current parrot 06:58
PMC has attributes but no auto_attrs or manual_attrs at /nocrypt-home/moritz/source/rakudo/parrot_install/lib/2.3.0-devel/tools/build/../lib/Parrot/Pmc2c/PMCEmitter.pm line 746.
make: *** [src/pmc/perl6_group.so] Error 255
and of course it doesn't tell me which pmc 06:59
sorear that has been a warning for a long time... did it get upgraded? 07:01
moritz seems like
I'm currently patching the PMC emitter to include the PMC name in the error message 07:02
which one used to be the default? auto_attrs or manual_attrs? 07:07
cotto the old default is manual_attrs
That's if the PMC manually allocates space for the ATTR struct. 07:08
For PMCs that extend Parrot core PMCs and don't have any extra ATTRs, go with auto_attrs. 07:09
moritz I'm updating all pmcs in rakudo to manual_attrs, since it worked that way so far 07:10
I'll open a ticket and ask to investigate if auto_attrs could/should be used
cotto ok. That part of Parrot could use some smartening. 07:11
07:11 AzureStone joined
moritz ... and if I do that, rakudo segfaults while compiling the setting 07:12
sorear double malloc or no malloc 07:13
moritz no malloc, it seems 07:14
cotto MutableVAR should definitely be manual 07:15
same for ObjectREF
07:16 parthm left
cotto s/EF/ef/ 07:16
same for p6invocation
and P6LowLevelSig
P6opaque should be auto 07:17
moritz most seem to cotain PMC_data(SELF) = mem_allocate_zeroed_typed(Parrot_ObjectRef_attributes);
cotto same for p6role
yeah. Those should be manual
Perl6MultiSub should be manual 07:18
dalek rrot: r46274 | moritz++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] mention PMC name in some of the error messages, since one call to pmc2c can process many of them
moritz cotto: thanks - compiling now 07:19
cotto perl6str should be auto 07:20
sorear I tried to DIY a superclass call, but... methods don't live in namespaces anymore 07:21
cotto I need to sleep. NotFound added the auto/manual attr stuff, so he and chromatic (among others) should know what to do if you get disoriented. 07:23
night
coke too, probably
moritz cotto++ # very helpful so far 07:30
07:33 eternaleye joined 07:50 fperrad joined
dalek rrot: r46275 | jimmy++ | trunk (14 files):
random consting, removed unused vars, localize, etc.
 07:51
08:02 eternaleye joined
bacek_at_work ~~ 08:06
moritz, what is current policy for getting rakudo's commit bit?
moritz bacek_at_work: some measure of accepted patches, a TPF CLA and thumbs up from jnthn&pmichaud 08:07
bacek_at_work "P" in "TPF" stand for "Perl" or "Parrot"?
moritz Perl 08:08
bacek_at_work ookey.
moritz Parrot Foundation is not "The" :-)
dalek rrot: r46276 | jimmy++ | trunk/src/pmc/hash.pmc:
changed SELF to STATICSELF and consting, ALL TESTs PASS
sorear Why does pbc_to_exe need 402 MB of RAM? 08:11
08:30 fperrad joined, riffraff joined, iblechbot joined, JimmyZ joined, Patterner joined, chromatic joined, confound joined, alexn_org joined, dngor joined, wagle joined, treed joined, Infinoid joined, sri joined, Hunger joined, dukeleto joined, GeJ joined, silug joined, estrabd_ joined, Maddingue joined, arnsholt joined, purl joined
dalek kudo: 961589a | moritz++ | (10 files):
build on latest parrot

   * loading 'os' and 'file', which are now DynPMCs it seems - Coke++
   * marking all PMCs as either manual_attrs or auto_attrs - cotto++
   * bumping PARROT_REVISION		 08:50
kudo: 168024a | moritz++ | src/pmc/objectref_pmc.template:
fix attribute specification in objectref
 08:56
kudo: e3153ad | moritz++ | perl6.pir:
rm perl6.pir since it is not used anywhere
 09:13
09:45 ruoso joined
cosimo where can I get a parrot v2.3 debian/ubuntu package? 09:46
moritz cosimo: debian unstable still seems to contain 2.0... you could download the parrot tarball and follow the instructions in docs/project/debian_packaging_guide.pod to build one 09:50
cosimo: the important files should all be in ports/debian 09:51
09:51 kurahaupo joined
cosimo moritz: will do, thanks 09:51
10:02 parthm joined 10:04 fperrad_ joined
dalek rrot: r46277 | fperrad++ | trunk/runtime/parrot/library/osutils.pir:
[osutils] OS is now a dynpmc, so load it (see TT#448)
 10:19
nopaste "bacek" at 192.168.1.3 pasted "moritz, there is small patch for auto_attrs for Rakudo." (73 lines) at nopaste.snit.ch/20458 10:26
bacek ~~
Hello, humans.
moritz bacek: will test and push after lunch, thanks
dalek rrot: r46278 | jimmy++ | trunk/src/pmc/callcontext.pmc:
random consting
 10:35
bacek moritz, btw, what is biggest rakudo's blocker/problem on parrot side? 10:41
10:43 aukjan joined 11:02 gaz joined 11:06 gaz_ joined
moritz bacek: currently memory 11:23
bacek: and random segfaults
purl random segfaults are realy annoying :-(
bacek moritz, sigh...
moritz pbc_to_exe seems to use quite some memory
bacek I can't reproduce segfaults on my Linux/i386... 11:26
moritz bacek: if you run a 'make spectest' in rakudo, do you see no exit status of 11 at all? 11:28
bacek nope...
moritz bacek: I can give you shell access to an amd64 linux box
bacek: the server will be shut down in three days, but until then you can use it for development if you want 11:29
bacek moritz, I can't work with 600ms ping :)
11:29 slavorgn joined
moritz :( 11:29
bacek We do need faster light speed :) 11:30
Infinoid don't ask me, sounds like a hardware problem
11:30 khairul joined 11:42 bkuhn joined 11:54 gaz joined 12:00 bluescreen joined 12:05 lucian joined
bacek msg chromatic I removed external_FLAG from PF_fetch_string r46279. We do need better handling of packfiles for this optimization. 12:09
purl Message for chromatic stored.
12:10 gaz joined
bacek moritz++ # Perl6/Rakudo "contribution weeks" 12:11
dalek rrot: r46279 | bacek++ | trunk/src/packfile/pf_items.c:
Remove PObj_external_FLAG from PF_fetch_string. This assumption not always hold.
 12:13
bacek msg fperrad Can you test Lua on r46279? It should solve segfaults in t/strings 12:15
purl Message for fperrad stored.
12:17 gaz joined 12:18 parthm left 12:22 darbelo joined
nopaste "bacek" at 192.168.1.3 pasted "moritz, no single failure in latest rakudo on my box... (Bit slow anyway)" (6 lines) at nopaste.snit.ch/20459 12:35
12:36 Mokurai1 joined
moritz envies bacek 12:36
bacek Sigh... I do want to reproduce your bugs... 12:37
moritz I'm getting a segfault in nearly every spectest run in t/spec/S03-junctions/autothreading.rakudo
bacek: did you see the backtraces I nopasted yesterday? 12:38
bacek moritz, yes. Looks like GC-heap corruption.
moritz, do you build optimized parrot? 12:40
moritz wonders idly if we could get a hague grant for hardwware for bacek
bacek: yes
bacek Oook. Let me try it
And I don't need "grant for hw" :) I just don't see any real value in 64-bits on "consumer" device. 12:42
moritz my desktop PC has more RAM than you can conveniently address with 32bit 12:43
for me that's a very good reason :-)
bacek it's... a reason 12:44
Do you need more than 4Gigs for single app?
moritz seldom, but it happens 12:45
for my last university project I did
bacek (Because linux kernel can use more than 4GB even in 32 bits mode, afaik)
Sigh...
moritz and enblend can use up quite some memory if you render huge image files
bacek My first personal computer had 16 KB of RAM... 12:46
12:46 ruoso joined
bacek My last professional C++ project was XQuery. I was able to handle 1GB XML in less than 1MB of active memory :) 12:47
moritz I needed to do some heavy numerical calculations 12:48
with matrices with millions to billions of non-zero entries 12:49
bacek 1GB XMLs are usually very dense :) 12:50
But I see the point.
moritz, can you try very latest parrot vs autothreading.rakudo? I can't reproduce any failure even with optimized build... 13:00
moritz bacek: I'm on it... 13:01
bacek moritz, r46279?
moritz yes
darbelo Unholy cow. The rakudo build is hungry resource devouring beast. 13:02
Something, somewhere needs to get more memory efficient by yesterday. 13:03
moritz darbelo: it used to be much less memory hungry
and I think it's a parrot regression that it can't build in a 1GB virtual mem ulimit 13:04
darbelo Failed allocation of 31910920 bytes 13:06
Parrot VM: PANIC: Out of mem!
bacek moritz, hang on. When it happened? (I suspect compact_pool_revamp merge, but want to be sure)
darbelo OpenBSD amd64
I don't test rakudo often enough to know when it stopped building here. 13:07
moritz bacek: hard to tell... rakudo didn't build for a long time after the 2.3 release
bacek moritz, let me rebuild rakudo on .5GB ulimit. 13:09
I think it should be good enough test for 32 vs 64 bits
moritz 31910920 / 1024
purl 31163.0078125
darbelo i386 *will* build on less memory.
moritz 31910920 / 1024 / 1024 13:10
purl 30.4326248168945
darbelo It's pretty much a gurantee.
bacek 32 megs is _additional_ allocation
On top of currently allocated mem 13:11
(building core.pm now...)
moritz yes, I understand that
bacek (core.pir built...) 13:13
darbelo moritz: OpenBSD has a hard limit of 1Gb of RAM per process. 13:15
moritz darbelo: ie it's not a computing platform 13:16
bacek It's just very good firewall/routers platform
moritz no doubt about that
darbelo All other features can be sacrificed on the altar of the tin god Security.
pmichaud seen kid51
purl kid51 was last seen on #parrot 2 days, 21 hours, 26 minutes and 3 seconds ago, saying: Those two files should have been governed by an svn:ignore property. Committed fix in r46204. [May 1 15:50:42 2010]
Coke pmichaud: mornin' 13:18
bacek pmichaud, aloha!
pmichaud good morning, Coke
pmichaud needs to correct some misinformation in kid51++'s post re: YAPC 13:19
bacek moritz, successfully built in half gig...
Coke msg jimmy - why the change from SELF to STATICSELF?
purl Message for jimmy stored.
13:26 atrodo joined
darbelo Coke: jimmy goes by JimmyZ on IRC. 13:30
13:37 JimmyZ joined
dalek tracwiki: v1 | particle++ | Parrot_Virtual_Machine_Workshop_2010 13:40
tracwiki: trac.parrot.org/parrot/wiki/Parrot_...ction=diff
13:43 plobsing joined
moritz bacek: still segfaults in r46279 13:47
dukeleto 'ello
Coke msg jimmyz - why the change from SELF to STATICSELF? 13:48
purl Message for jimmyz stored.
darbelo 'sup dukeleto
dalek nxed: r464 | julian.notfound++ | trunk/ (2 files):
Update driver and harness to OS pmc->dynpmc
 13:49
13:49 whiteknight joined
JimmyZ Coke: nevermind, I think I revert it. It make parrot slower. 13:50
s/I r/I will r/
Coke slower bad, typically. =-)
r46280 looks suspicious to me. 13:51
dalek rrot: r46280 | gerd++ | trunk/tools/docs/filename_and_chapter.pl:
fixed to work again; if the filehandle "OUT_FH" will be replaced with a variable then the script do not work
 13:52
JimmyZ purl: erase 13:53
purl erase is, like, borar
JimmyZ purl: how to eraseļ¼Ÿ
purl JimmyZ: huh?
moritz purl: messages erase
purl moritz: sorry...
moritz purl: erase messages
purl Use "messages erase" instead.
bacek moritz, erm... I will probably install Linux/amd64 to investigate it.
particle pmichaud: thanks, i tried to do the same 13:54
JimmyZ thanks, moritz++
13:58 Andy joined
pmichaud particle++ 14:01
moritz pmichaud++ # de-confusing
dalek parrot: e6d4ab1 | (Joshua Tolley)++ | IDEAS:
Some ideas about exposing functions
 14:07
14:07 aukjan joined
dalek rrot: r46281 | mikehh++ | trunk/src/misc.c:
fix codetest failure - trailing spaces
 14:10
14:14 JimmyZ joined
mikehh perlcritic does noy like 46280 - why does the scripty not work with $OUT_FH? 14:18
s/noy/not/ 14:19
Coke I tried running 'make pdf', but it barfs all over me.
mikehh s/scripty/script/
Coke I prefer to see print {$OUT_FH} "stuff" - wonder if the () is confusing it. 14:20
moritz mikehh: try { $OUT_FH } (with curlies around the handle
Coke also, there's a 2 arg open in there that should be easily fixable.
14:21 bacek joined
particle vomits in his mouth a little 14:21
moritz doesn't like thoughtless use of perlcritic 14:22
bacek doesn't like moritz... 14:23
Especially after reboot and running debootstrap --arch amd64
moritz has no problems with robots not liking him 14:24
davidfetter is there a reason to keep the 2-arg open()?
Coke Is that german for "the boot strap" ?
davidfetter: no.
davidfetter i mean just generally in the language
moritz davidfetter: backward comp 14:25
Coke: debian bootstrap, actually
davidfetter thinks that's not always a *compelling* reason
pmichaud Coke: would it be fair to say that you prefer git over svn?
Coke moritz: danke. though I hope you know I was kidding. =-)
moritz Coke: I thought so; but in the absence of a smiley I wasn't sure 14:26
Coke pmichaud: "I prefer git over svn."
pmichaud Coke: danke
dalek rrot: r46282 | coke++ | trunk/DEPRECATED.pod:
remove redundant line
 14:27
mikehh pmichaud: I think I do - except for revision numbers, but I think bzr is better
moritz hg also has a solution for that
and git allows you to count commits since a defined point 14:28
mikehh I can always look at logs, but it is easy to see that r46282 is after r46280 14:29
pmichaud mikehh: assuming a linear commit stream, yes. :-)
moritz mikehh: agreed 14:30
mikehh sure
Coke pmichaud: bitte
dalek parrot: d313174 | (Joshua Tolley)++ | IDEAS:
Update based on new information
Coke bacek: can you update TT # 1540 so folks can rip things out on your behalf? 14:36
bacek Coke, I think only inout ops left. 14:37
Coke checks.
bacek And they are tracked in separate ticket.
Coke which ticket?
bacek Your ticket! 14:38
1584
It's not about ops...
Coke bacek: please note those are YOUR tickets. I only opened them to track your entries in DEprecated.pod. :P
JimmyZ found a site whygitisbetterthanx.com :)
14:38 iblechbot joined
Coke 1584 is not about ops, right. so what ops are left for 1540? 14:39
bacek I do think only concat_s_s left
Coke concat_s_s looks like the only non-gc inout opcode left ins trings.pod 14:40
er, strings.ops
bacek Yes. pin_s_s and exchange_s_s should stay
Coke ... string.ops. (*&#$
excellent. I'll rip that out tonight if no one beats me to it. 14:41
bacek It will be hard...
There is a _lot_ of C<.=> inside Test::More 14:42
Coke I'm sure I will find a way.
(that just means no one will beat me to it. =-) 14:43
bacek We do need some kind of StringBuilder PMC before ripping it for seamless migration.
Coke bacek: we have a stringbuilder pmc. CodeString.
bacek It is not :)
Coke it is.
dalek rrot: r46283 | coke++ | trunk (2 files):
Ignore directory generated by 'make pdf'
Coke (at least in the codestring branch)
bacek CodeString should "has-a" StringBuilder
Not "is-a" StringBuilder 14:44
Coke it has-a RSA.
you don't need a SB in addition to an RSA.
bacek RSA is way too expensive.
Coke RSA.push, push, push, push; join RSA
bacek We need very-very low-level "character buffer manager" SB 14:45
Without storing _a lot_ of String headers
Coke ok. we don't need that to rip out concat. 14:46
bacek E.g. for 1..1_000_000 -> { $sb.push("a") } shouldn't hold 1M string headers
Coke (and I suspect that we don't want a simple buffer. we want actual strings... at which point you might as well have a STRING.
14:46 clinton joined
Coke OK. I can see that being a legit reason to have SB not RSA - but the SB could just compact strings if number of elements was > 1000 or something. 14:47
(set a max limit after which compaction must occur.)
bacek Coke, yes. It's one of possible solutions. 14:48
groups.google.com/group/parrot-dev/...eb73?pli=1
Coke Note that CodeString compacts before marking in the branch (chromatic++)
bacek And it's bad from my POV. We create GCable during GC run... 14:49
Coke so it really isa stringbuilder (with some more smarts). I think it might be worth adding an "append" method (or even just push_*) that does what .emit() does with no %% expansion.
It's evil, yes.
dukeleto may have to fiddle with some java code for $work and shudders at the thought 14:50
Coke it's heart is in the right place, though.
(that is, it's trying to reduce memory pressure.)
bacek prefers C#'s StringBuilder API vs Java 14:51
14:51 cotto joined
dalek cnum-dynpmcs: r199 | darbelo++ | trunk/src/pmc/dec (3 files):
Add manual_attrs to pmcs that need it now it's not the default anymore.
 14:51
14:52 ash_ joined
bacek finally got chrootted amd64 environment 14:56
dalek lambda: 1caed76 | fperrad++ | setup.pir:
update setup.pir
 14:58
lambda: e92e341 | fperrad++ | .gitignore:
update .gitignore
bacek moritz, core.pir topped at 520 megs in my chrootted amd64 environment... 15:01
moritz bacek: then I'm curious about pbc_to_exe 15:02
15:04 JimmyZ_ joined
bacek "/usr/local/bin/parrot -o perl6.pbc src/Perl6/Compiler.pir" is freaking slow... 15:06
moritz that's the step that compiles core.pir to pbc 15:07
(Compiler.pir .include's core.pir)
Coke moritz: I believe chromatic mentioned that was slow in backsroll.
dalek TT #1607 created by cosimo++: [PATCH] Minor updates to the debian packaging instructions 15:08
TT #1607: trac.parrot.org/parrot/ticket/1607
TT #1608 created by cosimo++: [PATCH] Minor updates to the debian packaging instructions
TT #1608: trac.parrot.org/parrot/ticket/1608
Coke I think it had to do with string-dedupification.
pmichaud response sent to kid51++'s message -- apologies to anyone for whom I've mischaracterized or spoken out of turn
Coke bacek: so the trickiest part of removing concat is, as you mentioned, fixing PIR's "a .= b" - I know where in IMCC this needs to change, but am wondering about string vs. PMCs here. 15:09
bacek pmichaud++
Coke, that's reason why I consider to put "clean statement in docs and keep concat" 15:10
Or we can introduce SB, migrate T::M into it and then remove concat_s_s
moritz, yak... 1.3G for pbc_to_exe. Something is definitely wrong here. 15:12
Coke bacek: fixing .= is much more fundamental than just our stdlib.
eliminating .= is way out of scope for this change, and I don't think it's necessary.
moritz bacek: and that's where the rakudo build fails with a ulimit 15:13
bacek Coke, "clean statement in docs" :)
Coke bacek: ?
I don't know what you mean by that.
bacek Coke, keep concat_s_s as is for now. Just clarify that something like "$S0 = 'foo'; $S1 = $S0; concat $S0, 'bar'" will _not_ update $S1 as in 2.3.0 15:15
darbelo "git is better than hg because of github", says github employee. 15:17
moritz darbelo: I've read that too :-)
darbelo At least he's honest about his biases.
bacek moritz, bad news... I still can't reproduce segfault... 15:18
ash_ i do like how github lets you checkout via svn now, but i still use git for everything currently
Coke note that that svn co is readonly.
(as we re-discovered recently) 15:19
moritz bacek: do you have a 64bit kernel running? (I feel stupid for asking that...)
bacek moritz, of course
Linux icering 2.6.32-3-amd64 #1 SMP Thu Feb 25 07:33:41 UTC 2010 x86_64 GNU/Linux 15:20
moritz bacek: I've now deleted the parrot install dir, and git clean -xdf'ed the source dir
bacek And chrooted 64bit userland
moritz in case something from the older builds was interfering 15:21
Coke pmichaud: thanks for the git commit cheatsheet. I expect someone will add branching. Remote would cover "like with svn", and then someone could local for "extra credit" 15:22
bacek omgbbq. It's almost 1:30AM again!
Coke bacek: that already doesn't work that way in parrot trunk.
(or at least a really recent parrot) 15:23
bacek Coke, yes. But original deprecation was to remove this op.
Coke, if we keep this op we have to declare it in docs somewhere. 15:24
Coke ok. I'd rather just remove it.
I'll hack on the IMMC magic tonight.
er, IMCC
bacek Coke, good luck :)
bacek departing into bed
Coke looks like a trivial change to make it always desugar to concat_xxx instead of concat_xx - might need a little more smarts to use that only in string case.
bacek: ~~ 15:25
sleep well, robot friend.
cosimo: ping
cosimo Coke: hi
Coke cosimo: ENOPATCH
cosimo Coke: i think i posted twice, did you look at #1608 ? 15:26
Coke (if it's submitted elsewhere, a link to the debian ticket would be fine.)
no, 1607.
'll kill 1607. danke.
cosimo Coke: i tried to kill it myself, but i couldn't...
Coke done. 15:27
cosimo++
cosimo thanks for the quick feedback 15:30
Coke guess I should actually /read/ the patch... 15:33
yah, +1 15:34
applied. 15:35
purl rumour has it applied is useful
Coke one thing I miss about RT - you couldn't accidentally steal a ticket. 15:36
that's 2x in the past few days I accidentally took a ticket because I didn't realize it was owned. 15:37
(though owned != assigned, so that's another confusion)
dalek TT #1607 closed by coke++: [PATCH] Minor updates to the debian packaging instructions 15:40
TT #1607: trac.parrot.org/parrot/ticket/1607
TT #1608 closed by coke++: [PATCH] Minor updates to the debian packaging instructions
TT #1608: trac.parrot.org/parrot/ticket/1608
rrot: r46284 | coke++ | trunk/docs/project/debian_packaging_guide.pod:
Note requirements/update URL for debian packagings.
 15:49
cosimo Coke: looks like the last URL wasn't applied?
15:49 bubaflub joined
cosimo here, trac.parrot.org/parrot/browser/trun...e.pod#L175 15:49
that link should have pointed to trac.parrot.org/...
?
Coke argh. I did "patch -p0" <paste> and must have not gotten a full paste. :P 15:50
pmichaud in retrospect (having now run some errands), I suspect I should've just let the git-vs-svn discussion disappear on its own. 15:53
oh well, it was a useful chance to vent a bit. Hope kid51++ doesn't take it at all personally.
Coke you should teach that boy perl6 and throw him at the spec tests. 15:57
(regarding his comment about being in maintenance mode on the perl5 stuff in the parrot repo.)
15:57 aukjan joined 15:58 theory joined
cotto_work good ~~ 15:59
16:00 fedov joined
darbelo ~~? 16:04
purl rumour has it ~~ is the ambivalence operator or also called the mumble operator
darbelo A good mumble to you too, then. 16:05
dalek rrot: r46285 | coke++ | trunk/docs/project/debian_packaging_guide.pod:
apply last part of patch from cosimo++
cotto_work mumbles something ambiguous at darbelo 16:08
ash_ about staplers? 16:09
cotto_work I don't know. It was ambiguous.
darbelo is ambibalent about the whole ambiguousness thing. 16:12
Coke ambivalent? 16:14
... of course it was.
Coke apologizes.
darbelo Ohhhh, unlambda works. That's unexpected. 16:17
ash_ unlambdas? 16:20
moritz just like lambdas, but not
ash_ ah
darbelo github.com/bschmalhofer/unlambda/ 16:21
moritz en.wikipedia.org/wiki/Unlambda
ash_ dang, there are so many little languages out there... like bf, whitespace, etc.. hard to keep them all straight, or even know about them 16:22
darbelo We need better tracking of language projects.
Coke darbelo: ... update the wiki page that tracks language projects. 16:33
trac.parrot.org/parrot/wiki/Languages 16:34
darbelo Coke: Should I include the ones I don't know about too?
Coke darbelo: how can anyone know the unknowable. update the wiki with stuff you know about. it's the best we can do. 16:35
cosimo finally managed to get a chroot + working deb for parrot 2.3.0 \\o/
needs more work on the debian patches though... 16:36
Coke inf act, it could use some care, since there is Languages, AbandonedLanguages, and a section in Language for inactive (that itself contains active stuff) A reshuffle is in order.
moritz cosimo: please upload it somewhere
darbelo That page is up to date (as far as I know). I was bitching that there is no magic unicorn that tells me about stuff I don't know.
moritz
.oO( purl? )
 16:37
ash_ .o0( purl is a unicorn? )
Coke darbelo: ... ok. as long as you realize that's crazy. =-)
I think anything that is building against 2.3.0 is safe to move into the active category. 16:38
darbelo Really? 16:39
"It doesn't depend on any stuff we removed" != "People keep it updated."
Coke darbelo: which, crazy?
darbelo Coke: Nah. I know I'm crazy. 16:40
Coke darbelo: the "active/inactive" column is pure WAG anyway.
cosimo moritz: I was thinking of building the amd64 version too
Coke conversely, how can anything that only builds against a pre 1.0 release be considered active?
cosimo moritz: is mentors.debian.net ok?
moritz cosimo: sure
cosimo: just tell me the URL when you're done, will interest other folks too 16:41
16:41 sjn_ joined 16:45 chromatic joined
cotto_work language tracking is definitely one of the places where a wiki isn't the best solution 16:50
There may be a trac plugin that'd make life simpler.
16:51 bubaflub left, bubaflub joined
darbelo Maybe. But it still feels like I'm asking for flying ponies and unicorns. 16:52
cosimo moritz: uploaded to mentors right now, i386 only
tewk chromatic: what callgrind cmdline do you use?
chromatic alias cg='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes' 16:53
cotto_work cg?
purl rumour has it cg is A MAN U HOMO! or computer graphics or nvidia's GPU shader language
darbelo alias cgp='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes ./parrot'
cosimo moritz: it might destroy the universe, i'm quite new to the debian packaging stuff. tried installing it, it works
cotto_work cgp is alias cgp='time valgrind --tool=callgrind --dump-instr=yes --trace-jump=yes ./parrot' 16:54
tewk goes and writes that down so he won't have to ask again
cotto_work That's why I told purl.
darbelo tewk: put alias realias="$EDITOR ~/.aliases; . ~/.aliases" 16:55
16:56 sjn joined
darbelo into you profile and put the cgp alias into ~/.aliases 16:56
tewk darbelo: already have something like that ;) 16:57
Thats were I put i
t
16:57 fedov joined
darbelo tewk++ # Already being awesome. 16:57
cosimo moritz: people.opera.com/cosimo/perl6/lenny/ 17:01
moritz cosimo: awesome, thanks
cosimo now on to rakudo 17:02
17:05 bluescreen joined 17:08 shockwave joined
Coke hey, chrome's JS engine is now /even faster/ 17:08
purl Hmm. No matches for that, Coke.
atrodo Did they use unicorns this time? 17:09
Coke cotto_work: cgp is also tools/dev/cgp, yeS?
purl okay, Coke.
Coke ponders porting rakudo to v8.
shockwave If I have class B, which derrives from class A, and class there are both A::foo() and B::foo(), how can I call A::foo() from within B::foo() ?
cotto_work I thought it was but apparently not. 17:10
moritz I for one would welcome our new rakudo-on-v8 overlord
chromatic -1
purl -1
shockwave What about v8?
I used it before and ....
Coke v8 is chrome's JS engine.
moritz shockwave: should be working with $obj.A::foo()
shockwave: provided that B inherits from A
shockwave @moritz, this is not from perl. 17:11
THis is from PIR.
moritz oh
shockwave: then you need find_method on A
shockwave There is no syntax to call a base class method?
moritz $P0 = get_hll_global 'B'
$P0 = find_method $P0, 'foo' 17:12
your_object.$P0(args)
or so
no syntactic sugar I know of; it's a low level language after all
shockwave But how can that be, if B is not an instance? 17:13
Be would be the class.
B would^
moritz: Did you imply to pass 'self' for the call to 'your_object.$P0(self, rest...)' 17:15
pmichaud $P0 = get_class 'B' 17:16
$P1 = $P0.'find_method'('foo')
your_object.$P1(args)
moritz shockwave: listen to pmichaud++, he knows better :-)
and no, no self needed
pmichaud note that you need to use the 'find_method' method of the class object instead of the find_method opcode (the opcode requires an instance of the class, not the class itself) 17:17
if using P6object, then one can use find_method on the protoobject
one can also do $P1(your_object, args, ...) to invoke the method
shockwave pmichaud: I'm not understanding something. get_class returns a non-instance. 17:18
So can I can call a method on a non-instance?
pmichaud yes, but then you're invoking methods of the Class PMC, not methods of the class itself 17:19
$P0 = get_class 'B'
$P0.'foo'() # fail
$P0.'find_method'('foo') # succeeds, because Class PMCs understand the 'find_method' method.
in other words, you can't invoke instance methods on the class object
the class object is itself an instance of Class, and thus has its own methods 17:20
shockwave pmichaud, right, but think about it. If my instance already has attributes values set, how would that know which instance to call?
pmichaud I don't understand the question
try it with variables.
shockwave pmichaud, I can see what you mentioned working with global functions.
But, 17:21
pmichaud nothing I mentioned above involves "global functions", afaik
shockwave When class instances, one needs to call methods on an instance, because that instances has internal values associated with it which the method will use when called.
Sorry about the spelling. 17:22
pmichaud right
so one does instance.$P1(args)
or $P1(instance, args)
if you're asking "is it possible to invoke a method on a non-instance", the answer is yes.
If you're asking "will it work", that depends on what's in the method 17:23
if the method attempts to access an attribute that is not defined in the (non-instance) invocant, then yes, you'll get a runtime exception
shockwave I think I got it. I misread this line: your_object.$P1(args)
your_object is the existing object from which the call is being made, which in this case is self.
pmichaud doesn't have to be self, but can be in this case.
shockwave yeah. 17:24
sorear pmichaud: would it be reasonable to add closure support to PAST::Compiler? ie :closure() on PAST::Block, if set (or set in any ancestral block) PAST::Compiler will call newclosure *before* capture_lex
shockwave Ok. I'll code it in. Thanks, pmichaud, moritz
pmichaud sorear: newclosure already calls capture_lex, it's not necessary to do both.
sorear: short answer -- :closure() is the wrong approach. 17:25
put another way, PAST::Compiler already has closure support, although there may be some edge cases and bugs that have to be worked out. 17:27
sorear ah. well, in that case, we'd like your advise
how do you access the closure support?
pmichaud it's there by default.
rakudo (alpha) was doing closures properly using the existing PAST::Compiler 17:28
shockwave pmichaud, that worked swell. Thanks again.
pmichaud sorear: better would be to say "here's an example that isn't working with PAST::Compiler -- how do I fix it?" 17:29
shockwave Coke, what I was saying about V8 is that I used it before.
V8 was my first choice as the scripting engine for my 3D engine, but it turned out not to be a good choice for that, for many reasons. 17:30
The most important one being the garbage collection algorithm, which would stop the world. Not good for a 3D game.
chromatic All you have to do is delay it until a level or scene change. 17:31
shockwave chromatic, you would quickly find that you will run out of memory if you do that.
chromatic Not if you're clever. 17:32
shockwave Javascript is not a good language for creating 3D engine frameworks, at least for me. I kept trying to make it do what it wasn't meant to; class hierarchies, interfaces, etc.
sorear pmichaud: my example is rakudo master. sorry, I thought the lack of /newclosure/ in Compiler.pir was evidence of lack of support
shockwave chromatic, I'm not that clever.
sorear afk
17:34 ash_ joined
pmichaud sorear: PCT supports closures by allowing :pirop<newclosure> directly as well as handling any capture_lex automatically. Where (I think) we currently run into difficulties in rakudo is that assignment now changes pointers instead of copying values (cloning subs). 17:34
so, we have to detect when the HLL is cloning a sub and explicitly newclosure it. 17:35
basically that means identifying all of the places where a sub is being used as an rvalue.
or, more likely, assuming that subs are being used as rvalues until analysis can determine otherwise. Mainly that means turning off any cloning when we have :blocktype<immediate> 17:36
ash_ pmichaud: so you know, the issue is also present in nqp, but i don't know if it needs to be addressed there or not since there are work arounds for that 17:38
pmichaud ash_: yes, nqp has the same sort of issue -- it's hard to know when a block is being used as an rvalue
might be easier to resolve it in nqp and then adapt the solution to rakudo
ash_ gist.github.com/388632 kinda is what I am talking about, so you know from an example what I mean (although i think you already understand) 17:39
pmichaud my wife is having tests run today and thursday (first set of tests since she began chemotherapy treatments in April). Based on those tests I hope to have a much better understanding of my time availability and planning for May and June. 17:40
fixing the closure issue in NQP is likely a high-priority item for me.
ash_ i know in the #rs they wanted to talk about it, because they felt like it was a R* blocker, if your busy someone else could look into it, do you think it could be handled in NQP-rx? i thought it might be possible to find when blocks where being used as rvalues in the AST and add the appriopriate changes there 17:42
pmichaud the rakudo problem can't be handled by nqp-rx alone, no.
and I think it's too difficult to detect when blocks are being used as rvalues. More likely is that you have to assume it's an rvalue and then change things when it isn't. 17:43
which might argue for a :closure attribute, but I think it's far more likely that we want :blocktype<closure> instead of :closure 17:44
it's also possible that we simply want :blocktype<declaration> to also perform a newclosure whenever it's being used in a non-void context (which PAST already knows about as well) 17:45
actually, that seems more likely
it still doesn't fix the Rakudo problem, though, because Rakudo wraps all of its Parrot subs in specialized Rakudo objects 17:46
so the thing that gets bound isn't the PAST::Block, but an object that contains a reference to a PAST::Block
PerlJam you're in a maze of twisty PAST::Blocks, all alike.
17:51 aukjan joined, mikehh joined
darbelo dukeleto: ping 18:40
dalek TT #1142 closed by mikehh++: test 12 of t/pmc/eval.t fails in testr (passes in other runcores) 18:42
TT #1142: trac.parrot.org/parrot/ticket/1142
TT #1368 closed by mikehh++: some failures with test 31 of t/op/exceptions.t
TT #1368: trac.parrot.org/parrot/ticket/1368
TT #1600 closed by mikehh++: t/pmc/resizablestringarray.t FAILS in make corevm/make coretest
TT #1600: trac.parrot.org/parrot/ticket/1600
dukeleto darbelo: pong
dukeleto is about to step out to the airport
but supposedly there is free wifi there
particle i was there last night
darbelo Feel free to run out on me. It's nothing important 18:43
particle well, not at THAT airport
Tene I was there on Sunday.
well, yet ANOTHER airport
particle there's free wifi in sea and den now
dukeleto is in Ithaca, NY and is heading back to PDX
treed Really? When did DEN get the wifi?
I didn't notice any when I was there in January.
particle ithaca is gorges! 18:45
dukeleto particle: i bought 3 of those shirts :)
dukeleto steps out, see y'all soon
particle treed: google sponsored it around xmas, and they kept it up. worked yesterday, anyway
treed Oh, neat. 18:46
I guess I just missed it.
Would have liked it, too. My reception there was shit.
Also: Confusing ass airport.
Took me way too long to figure out how to get to the pickup area.
And then I ended up at the wrong one. 18:47
particle nice.
it helps i lived there 10 years ago, i know that airport well
treed Ah.
Yeah, now that I've figured it out, it's a bit easier
But at first it's like "... where do I go?"
SFO was also slightly confusing at first. 18:48
In the "Okay, so Virgin is in aisle 10... where's that?"
kind of way.
particle i prefer oak to sfo any day
treed I haven't been to oak yet.
Usually fly out of SFO. SJC sometimes. 18:49
particle sjc's mildly confusing, thanks to construction
treed Yeah.
dalek rrot: r46286 | allison++ | trunk/ports/debian (4 files):
[debian] Update debian packaging files in the repository to match the ones that shipped in the 2.3 packaging.
treed I was trying to find a bathroom Sunday night while waiting for luggage.
I ended up holding it.
The luggage pickup is now at the new terminal b
but none of the rest is open
particle ha, you have to exit baggage and head to the taxi stand
oh, great. even better.
treed So I saw a sign that I couldn't get to saying "Bathrooms ->" 18:50
particle there were bathrooms outside in a trailer last time i was there
treed Didn't see those.
18:54 joeri joined
mikehh bbl - in time for #ps I hope 19:06
Coke seen chromatic? 19:09
purl chromatic was last seen on #parrot 1 hours, 37 minutes and 25 seconds ago, saying: Not if you're clever.
Coke rurban++ 19:11
dalek tracwiki: v26 | coke++ | GitObjections 19:14
tracwiki: update point 7 based on experience in recent months.
tracwiki: trac.parrot.org/parrot/wiki/GitObje...ction=diff
19:30 LoganLK joined
Coke moritz: we broke rakudo again? 19:35
darbelo Coke: kind of. 19:36
moritz moritz: it compiles, if that's what you're asking
cotto_work #ps in 54
Coke coke: remember, don't talk to yourself.
coke: Ok. 19:37
moritz erm, I meant Coke :-)
darbelo dukeleto: reping
dukeleto darbelo: repong
darbelo :)
19:37 kurahaupo joined
darbelo dukeleto: I want to put a link to GSoCersStartHere int th /topic once the mentors have a chance to look at it. Do you think it's worth it? 19:38
Also, are we going with the mandatory parrot.org blog? We should mention that there, the process to get one set up is different from the one to get a commit bit. 19:40
dukeleto darbelo: yes
darbelo: yes, all GSoC students have mandatory homework of 1 blog post per week
darbelo: for parrot gsoc students, those blog posts will be on the parrot.org blog
darbelo That means we have to tell them to get a drupal account set up (that's different from getting a Trac account). 19:41
dukeleto darbelo: that means that gsoc students have bonding period homework of getting their blog-stuff setup
darbelo: yes. can you add that to the wiki? 19:42
darbelo I have no recollection of how mine happened last year.
dukeleto darbelo: i would also like to see at least 1 post during the bonding period as well
darbelo I *think* the process to get a parrot.org blog involved bugging Coke (or was it particle?) 19:45
particle probably coke, but i could be suede 19:46
swayed, even ;)
sending a mail to parrot-directors or parrot-dev with details will be enough reminder to get it done 19:47
Coke bah, open a trac ticket.
particle oh, yeah, i guess that works, but i don't check trac so coke will do it then :) 19:48
Coke (they'll need to create the separate account and tell me what it is.) giving them perms takes 5s - they can ping me or open a ticket, either way. 19:51
emails as todos tend to get lost.
irc for "DO IT NOW" is fine, though.
darbelo I'll add that to the wiki now. 19:53
particle separate account? 19:54
darbelo The Drupal and Trac credentials are separate. 19:55
Students need Trac for svn access and Drupal for the weekly blogging.
particle ah, sigh 19:56
we fixed that at openefs.org
same creds, using drupal auth for trac
darbelo That would be nice to have.
Probably too short notice now, but still nice for later. 19:57
particle yes
cotto_work very yes 19:59
though it would be nice if my password didn't get sent to me every month
darbelo Of course, then tracspam would have potential to become drupalspam. 20:00
dukeleto I am fine with making students interact with us to get credentials 20:04
dalek tracwiki: v1 | allison++ | Rakudo_Workshop_YAPC_NA_2010
tracwiki: trac.parrot.org/parrot/wiki/Rakudo_...ction=diff
dukeleto I just sent an important email relating to GSoC: groups.google.com/group/tpf-gsoc-st...37b91423f5 20:05
darbelo: check that out and let me know if I missed anything
darbelo dukeleto++ # It is best 20:08
to err on the side of too much quality
moritz dukeleto: two things you could add, thought they might be obvious: 1) tell your mentors about your blog, and submit it to the ironman and perlsphere feed 2) the student should insist on weekly status meetings, even if the mentor doesn't deem them important 20:11
dukeleto moritz: could you reply to that with those things and say that I have agreed with them? I am about to board a plane and will be net-less for quite a while 20:12
moritz dukeleto: I'm not even subscribed to the mailing list... I'll see what I can do 20:13
20:13 aukjan1 joined
dukeleto moritz: i can do it 20:13
moritz: i have a few mins 20:14
moritz: thanks for the suggestions
ok, about to board, see y'all tomorrow-ish 20:17
moritz dukeleto++ # gsoc work
cotto_work seen khairul 20:19
purl khairul was last seen on #parrot 7 days, 15 hours, 10 minutes and 10 seconds ago, saying: thanks alot. i'll submit the cla later. have to read it first. [Apr 27 05:09:41 2010]
20:24 allison joined
darbelo points at www.parrot.org/content/what-nfg-why...ot-have-it and hopes the architect agrees. 20:26
cotto_work any reason that's not promoted to the front page? 20:27
darbelo I'm shy.
I thought it was still dalek-ported here.
moritz darbelo: don't be
bubaflub darbelo++ # good write up 20:28
allison darbelo: thanks, will take a look
darbelo Pushed to the front page.
chromatic #ps in 2
darbelo Somebody might want to make the big announcement sticky. So student blogs don't push it off the page. 20:29
dalek website: darbelo++ | What is NFG an why you want Parrot to have it. 20:30
website: www.parrot.org/content/what-nfg-why...ot-have-it
particle dukeleto++ # gsoctitude 20:34
allison darbelo: that's a great writeup, thanks 20:36
dalek tracwiki: v3 | darbelo++ | GSoCersStartHere 20:37
tracwiki: Mention that students should swarm Coke and demand he do stuff for them.
tracwiki: trac.parrot.org/parrot/wiki/GSoCers...ction=diff
tracwiki: v1 | particle++ | Perl_6_Workshop_YAPC_NA_2010
tracwiki: trac.parrot.org/parrot/wiki/Perl_6_...ction=diff
darbelo I'll be posting another one of those on the current state of parrot strings later this week.
allison darbelo: it goes a bit further even than that, creating combined codepoints for combining characters that don't have them in Unicode 20:38
darbelo: and also fixed width character representations (you referred to it early in the post)
darbelo I tried to work that into the last paragraph, The "no exceptions bit", but my english wasn't up to the complexity of the sentences I was writing. 20:39
allison darbelo: you really did a good job of explaining some complex concepts in plain english 20:40
darbelo I don't speak any English past "plain". So I better be able to explain stuff in it ;) 20:41
20:42 smash joined
smash hello everyone 20:42
darbelo I still have trouble maintainig tone across sentences or paragraphs though. I think it comes from borrowing too much from stuff I've read. 20:43
bubaflub darbelo: i'm curious - will the initial transformation into NFG be expensive?
darbelo bubaflub: We are trasncoding a string. That is more expensive than not doing it. 20:44
bubaflub haha. of course.
and, again, this is just my imagination running wild and perhaps out of the scope of the project
but will there be cases where we won't transcode it?
darbelo It depends on what string we are transcoding too.
bubaflub would that be an optimization? or would that just be trouble
NotFound bubaflub: Anything but plain ascii is trouble. 20:45
bubaflub i'm thinking
would it be fair to say that class names don't need to be transcoded? 20:46
would that save us a lot of string transcoding?
particle anything but latin-1 is trouble
darbelo NFG is a normalization on top of UCS-4.
NotFound particle: latin-1 is trouble if you use a utf8 locale.
darbelo In some cases, you don't have any work to do. The string is already in the shape you ned it to be, but we still have to check. 20:47
bubaflub darbelo: ah, of course.
so many cases no work will need to be done
darbelo Indeed, other than a few languages ( not counting totally wrird edge cases ) NFG is just plain UCS-4 20:49
The example used in the PDD for whre NFG is needed uses "Russified" Serbo-Croat strings. 20:50
NotFound darbelo: yeah, and if you limit to english NFG is just palin ascii with 64 bit chars ;) 20:51
darbelo NotFound: Yep, that's why it's optional ;)
NotFound s/palin/plain
20:52 jrtayloriv joined
GeJ darbelo: In the second paragraph, may I suggest : s/of it's benefits/of *its* benefits/ 20:53
shockwave This rant will probably fall on deaf ears, but it will probably make me feel good: I purchased "Parrot developer's guide: PIR" from Amazon. I got it about 2 hours ago, and I'm already done reading it. 20:55
My problem: It is a copy and paste from the online docs.
I was hoping to read some inside info that is NOT found on the online docs.
At least, if the book would have said that it is the online docs, I would have still bought it, since the donations go to the Parrot foundation. But, it makes no mention of that anywhere. 20:56
bubaflub shockwave: do you have a link to the product sold on amazon?
(i wasn't aware of any official parrot book being sold, but i could be out of the loop)
shockwave bubaflub: www.amazon.com/dp/0977920127 20:57
bubaflub shockwave: thanks
chromatic The copyright page mentions it, but I'm not sure that's on the Amazon page.
shockwave :( 20:59
NotFound =item C<void reverse(STRING *src)> Reverse the ascii STRING C<src> in place. 21:03
This shouldn't be removed?
And trans 21:04
chromatic It's safe in an immutable STRING world, but it's really not safe in a Unicode world.
NotFound Inmutable and changed in place?
darbelo If it has "in place" on the name, it's covered by the deprecations. 21:05
chromatic Oh, it reverses its single argument in place. That's covered by deprecation.
NotFound "trans" don't say it, but does. 21:07
darbelo Kill! 21:08
dalek tracwiki: v12 | allison++ | AllisonTasklist 21:10
tracwiki: trac.parrot.org/parrot/wiki/Allison...ction=diff
tracwiki: v13 | allison++ | AllisonTasklist
tracwiki: trac.parrot.org/parrot/wiki/Allison...ction=diff
Coke what is reverse? a method? 21:11
if it's a method on a PMC, immutable doesnt' really matter. 21:12
chromatic Yes.
It's basically a class method.
Coke you just throw out your original string and store your new string in your String.
ah. I hate parrot class methods. ah well.
chromatic It takes a STRING and does not return anything.
21:12 davidfetter joined
Coke yup. I'd say that counts, though a separate ticket would have been nice. 21:16
perhaps we can convert it to a non-class method that does the thing I thought was OK. =-)
NotFound Maybe what we need is a StringUtil singleton. 21:17
Coke BLARGH?
NotFound Coke: better than having method in a regular class that doesn't use the instance, IMO. 21:18
Coke my vote: either opcodes (for $S0 and or $P0) or instance methods on String (for $P0)
NotFound: that's an argument against class methods, not an entirely new helper PMC that has no data.
NotFound Did we have non-class methods? 21:19
Oh, you mean like C++ static member functions. 21:21
chromatic Right.
NotFound But non static. 21:22
If reverse is reallly wanted we need a string api function to start. 21:24
Coke updated TT#1540
Not every method requires a corresponding Parrot_XXX_function 21:25
NotFound (I suppose we don't want to have duplicated implementations in string.ops and in String.pmc)
darbelo The whole argument is kind of moot if you ask me. The only tests we fail after removing the method are those for the method.
Coke darbelo: since this is, if you squint, covered by TT#1540, yes, that's fine.
NotFound darbelo: giving that we can easiliy break languages without any comment on the test suite, that doesn't grant anything. 21:26
darbelo Hm. Good point.
Coke NotFound: yah, but we barely covered ourselves with the ticket.
in any case, most HLLs are going to want that. +1 on rewriting it to be immutable friendly. 21:27
NotFound I'm thinking we must make deprecation warnings active by defalut, and then start adding lots.
Coke (i.e. making it operate on SELF and take no args)
NotFound: the only thing that supports runtime warnings are opcodes. 21:28
functions, methods, all that has to be handrolled.
NotFound Coke: not at all, we can add Parrot_warn anywhere.
chromatic We could make method warnings free-ish.
Coke NotFound: yes, handrolled.
NotFound Coke: that's why I said "start adding lots" 21:29
Coke which if fine, but as a HLL, I can tell you that's going to be REAL annoying if the new option isn't available for me to switch to. =-)
which in a lot of cases, it's not. we rename stuff all the time without having the new name available first.
NotFound Coke: that's the intention, to be annoying eough to get somenone fixing.
Coke (see all these last minute string tickets before 2.3)
21:30 jrtayloriv joined, Whiteknight joined
Coke NotFound: causing our /users/ pain to force our /dev/s to do something is backwards. 21:30
or wrong. I'm not sure you can flip that into a sane config.
NotFound Coke: I recommend doig that when we already have a working alternative.
Coke: the assumption is that the developer will feel the pain himself first, and fix the issue. 21:33
Coke I'm not sure how that would work. not like, say, bacek runs partcl-nqp test suite often.
nor do I really expect him to.
if the pain is in the own test suite, doesn't help ; we have to support the old version anyway, warnings or not. 21:34
I would recommend creating a Parrot_xxx_deprecated() to wrap the warning with the appropriate check. that'll make dropping it in easy. 21:35
*even* easier.
I definitely agree that adding this to new things in DEP.pod is good. let's just rip out all the ones that are past due and avoid adding the warnings there, though. =-) 21:36
NotFound Yeah
darbelo nopaste.snit.ch/20464 is my stance on the debate. 21:38
Additions can be made later. The ripping out is trivial. 21:39
21:43 davidfetter joined
bacek ~~ 21:43
darbelo Whiteknight: DST?
purl somebody said DST was political, hence is localized all over the world. or daylight savings time or Devel::SimpleTrace or Daylight Saving Time or Direction de la Securite du Territoire ...
Whiteknight DST?
purl DST is political, hence is localized all over the world. or daylight savings time or Devel::SimpleTrace or Daylight Saving Time or Direction de la Securite du Territoire ...
bacek Good morning. humans
Coke darbelo: ... ok by me, but only because partcl isn't using that. you should check to see if rakudo is...
Whiteknight 00100100101110101010010111010, bacek
dalek tracwiki: v4 | darbelo++ | GSoCersStartHere
tracwiki: Add link to the tpf-gsoc-students post by dukeleto++
tracwiki: trac.parrot.org/parrot/wiki/GSoCers...ction=diff
darbelo Rakudo is broken on my platform. 21:44
bacek It's 00100100101110101010010111011, Whiteknight!
darbelo Too memory hungry.
Coke darbelo: doesn't look like it is.
(using reverse)
darbelo: with pbc_to_exe, yes? 21:45
21:47 simcop2387 joined
darbelo Coke: Trying again after bumping my ulimit. 21:49
dalek rrot: r46287 | coke++ | trunk/DEPRECATED.pod:
Try to be more helpful.
 21:50
darbelo Nopes, still dies on "/home/darbelo/parrot/instdir/bin/parrot src/gen/perl6.pbc --target=pir src/gen/core.pm > src/gen/core.pir" 21:53
bacek darbelo, try at r46288 21:54
darbelo, nm... It was for pbc_to_exe 21:55
darbelo, what is your current ulimit?
darbelo unlimited, but there might be other limits in place. Let me check. 21:56
Apparently, 512M is the cap for my login class. 21:57
I thought it was higher.
bacek you need about 560 for core.pir 21:58
on 64 bits
darbelo It used to work on i386.
bacek It's much less on 386 22:00
Something about 360 megs
darbelo I wonder where that difference comes from.
bacek Size of pointer
darbelo That much? 22:01
purl somebody said That much was certain
bacek I think so.
darbelo Wow.
Whiteknight When was the first PDS, 2008? 22:02
chromatic Double the size of PMC and STRING headers.
bacek Each PMC contains 4 pointers
chromatic Let's rip out PMC_sync()!
22:02 darbelo_ joined
bacek Which adds at least 20 bytes. 22:02
pmichaud Whiteknight: yes, November 2008 22:03
Whiteknight pmichaud++: Thanks
darbelo_ I guess I underestimated the amount of headers we generate.
chromatic I think PCT holds onto a lot of headers.
dalek nxed: r465 | julian.notfound++ | trunk/winxedst (2 files):
don't use concat_s_s, use concat_s_s_s instead to avoid depend on pir sugar
 22:04
chromatic bacek, let's make a branch to get rid of _synchronize, and we'll make PMCs 20% smaller. 22:05
darbelo_ Never dug too deep there, for all I know it could be holding on to the AST all the way through code generation.
chromatic I think it is.
bacek chromatic, deal :)
pmichaud ...how else would it work? ;-)
darbelo_ Efficiently? ;) 22:06
dalek rrot: r46288 | bacek++ | trunk/tools/dev/pbc_to_exe.pir:
Earely join codestring to avoid too much memory consumption in pbc_to_exe
bacek chromatic, is PMC_sync deprecated already? 22:08
pmichaud I suppose we can get HLL::Compiler to drop the parse tree and ast when it's done with them. We'd also have to eliminate any references we have from the PAST/POST nodes into the original parse tree
bacek chromatic, or, "Do we need deprecation for it"?
chromatic I'm sure we deprecated it a long time ago. 22:09
pmichaud ...which, I don't think there are (m)any, come to think of it.
darbelo_ pmichaud: That would probably help quite a bit with memory usage.
pmichaud darbelo_: well, I'm trying to think of what in PCT would be keeping track of the trees, and I'm not coming up with anything though. 22:10
of course, just a single reference would be enough to do it.
22:10 pjcj joined
darbelo opbots: Trust me. 22:11
slavorg Ok
slavorgn Ok
pmichaud anyway, as a general rule I don't know that "keeping the ast around through code generation" would be considered out-of-the-ordinary for a dynamic language.
darbelo If it's needed, sure. If it isn't, we gain by ditching it. 22:12
pmichaud in a dynamic language you often don't know that it's needed until runtime, though.
anyway, I'll double-check PCT and NQP and see if there are any likely places that it's keeping around unwanted references. 22:13
chromatic If it's a quick experiment to remove, we can get some sense of what's happening.
pmichaud otoh, it's very likely that it's being kept around due to uncollected contexts
and I'm not sure there's much I can do about that yet.
i.e., to some extent that's entirely out of PCT's hands. 22:14
chromatic What would cause uncollected contexts? 22:15
pmichaud each subroutine has a "current_ctx" reference, IIRC.
I know you did some work on cleaning that up, but I don't remember if it's now the case that those contexts are released on subroutine exit.
chromatic Oh right, I hate that so much I forgot about it. 22:16
bacek chromatic, r46289
pmichaud if so, then the method that handles the past->post conversion still has a reference to the ast.
chromatic bacek, check the tests.
pmichaud I suppose I could try nulling out all registers on subroutine exit.
but that seems... wrongish. 22:17
bacek chromatic, passed of course
chromatic pmichaud, that's a nasty workaround and I'm not in favor.
pmichaud me either.
chromatic bacek, that's good. They didn't last time I tried.
pmichaud and I'm not sure it would resolve the issue anyway.
chromatic Me neither.
pmichaud anyway, I'll review the PCT and NQP code to see if there are any stray references, but I suspect it's the context code that is the culprit. 22:18
bacek darbelo, can you try r46289?
pmichaud based on this and other discussions, I'm wondering if we should revamp the whole mechanism by which we handle outer contexts to avoid the current_ctx pointer (more) 22:19
when I last worked on it in November 2008, that wasn't really feasible because contexts weren't normal PMCs and had their own reference counting structure
now that they're standard PMCs, that might be emininently doable, and also solve quite a few other of our closure-related problems. 22:20
chromatic I'm not sure why we even need to close over outer contexts. Outer lexical scopes, yes. Outer exception handling scopes, yes. Contexts? I'm not sure.
darbelo bacek: Building it now...
pmichaud well, traditionally the context holds the lexicals
bacek pmichaud, (side question) Do you have any docu how to migrate oplib from PCT to NQP-rx? 22:21
pmichaud i.e., lexpads are indexes into the context's register frame
anyway, if we just eliminated the current_ctx part of the existing Sub PMC we'd clean up a lot of crufty code. 22:22
chromatic You have to figure out which lexpad is correct, at least if you want re-entrant subs with lexicals.
But I don't think you need to close over contexts to make that work.
You can recalculate the proper lexpad index, I think. 22:23
pmichaud well, the context also holds the exception handling scopes as well, so closing over the context isn't so bad.
dalek rrot: r46289 | bacek++ | trunk (12 files):
Remove PMC_sync from PMC
rrot: r46290 | darbelo++ | trunk (2 files):
Obliterate the 'reverse' method on String PMC's.
pmichaud It's trying to close using information from the (static) sub PMC instead of the current dynamic context that is a pain.
i.e., currently capture_lex and newclosure use the current_ctx pointer from a Sub for performing the closure. They really ought to be using the dynamic current context isntead. 22:24
chromatic There's probably a race condition in there too.
bacek darbelo, 545...
pmichaud anyway, food for thought. but yes, I suspect the "PCT keeps the entire tree around" is really a special-case of the general "any sub that uses lexicals keeps data around" problem. 22:25
chromatic That makes sense.
mikehh tools/docs/filename_and_chapter.pl FAILs perlcritic - Bareword file handle and Two-argument "open" 22:27
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#33628), fulltest) at r46288 - Ubuntu 10.04 amd64 (gcc with --optimize)
I can't work with that 'cause I can't test it properly (don't work for me - LaTeX failures) 22:28
chromatic I'll take a look. 22:29
darbelo So close, yet so out of mem...
Coke bacek: about how many strings are in that loop that you're flatteningn codesting? 22:32
bacek Coke, 16k 22:33
Coke, no, 32k
Coke bacek: 16k worth of string size, or 16k individual strigns?
darbelo bacek: nopaste.snit.ch/20465
bacek 32k individual strings
Coke bacek: holy (*&#$.
I think if we had a codestring that collapsed itself every <N> strings or so, that would be a reasonable middle ground. neh? 22:34
bacek darbelo, looks good. Just commit it
Coke, nope. We need StringBuilder :)
Coke say, 1K or so?
chromatic Rakudo tops out at 380M building for me.
Coke bacek: how are you going to keep the individual strings around without their headers? 22:35
bacek Coke, yes, 1K looks reasonable
Coke bacek: let me try that in the codestring branch.
bacek Coke, I'm not going to. "low-level character buffer"
Coke bacek: then you break concat.
how do you concat two arbitrary byte buffers when one is utf8 and one is ... ... ebcidic. 22:36
(or some other non obvious encoding.)
transcode on .'append' ?
bacek Coke, just convert it in StringBuilder.push_string
yes 22:37
Coke do we have any pmcs that have a per-instance c-level int? 22:38
bacek: do you think doing the conversion and storing is faster than just doing the concat?
(might be. Iunno.) as long as you keep that on the list of things to do, 'sfine.
chromatic I don't know if join at 1k is any faster than join in mark. 22:39
Coke chromatic: do you think there is a N where it'll make a difference?
if so, I can write the code and then someone can tune it.
chromatic Try 256. 22:41
Coke k.
chromatic I think you'll still run into cases where join during mark is much faster. 22:42
bacek Coke, "concat" do conversion anyway (when required)
Coke chromatic: yes, but as all of us agree, coalesce during mark is evil. =-) 22:43
chromatic I don't see why it's evil, unless you're concerned that it won't get a new STRING header.
Coke is there an implication that we're creating new GC-able objects during a time when we're looking to collect? Hurm. perhaps I was conflating mark & sweep. 22:44
tewk I think join during mark is a cool idea, but you could greatly extend mark time due to allocation and copy, possibly making pause time even more unpredicatable. 22:45
chromatic You could greatly extend mark time due to having to mark lots of headers too though. 22:46
Coke is there a ulimit I should try building rakudo under? is 1G reasonable?
darbelo 512M won't work. 1G seems reasonable. 22:47
Coke (i've got 3G of real on this box plus swap)
darbelo 1G.
Coke I seem to be topping out at about a gig without setting a hard limit.
darbelo Then you don't have to do anything! 22:48
Coke schweet. also htop++
dinner time. will report later.
dalek rrot: r46291 | darbelo++ | trunk (3 files):
Cleanup some leftovers fo the _Sync removal.
 22:56
23:00 cotto_work2 joined
cotto_work2 mibbit seems to make firefox crashy 23:00
darbelo cotto_work2: You mentioned something about the ops_pct branch being broken/unmergeable? 23:01
mikehh rakudo (e3153ad) builds on parrot r46288 - make test PASS, spectest_smolder -> #33630 (pugs r30549) PASS - Ubuntu 10.04 amd64 (gcc with --optimize) 23:02
t/spec/S05-mass/properties-general.rakudo - TODO passed: 4-6, 11-13, 544-546, 550
dalek rrot: r46292 | chromatic++ | trunk/tools/docs/filename_and_chapter.pl:
[tools] Made tools/docs/filename_and_chapter.pl pass Perl::Critic tests.
 23:12
rrot: r46293 | NotFound++ | trunk/config/auto/zlib/zlib_c.in:
fix zlib checking for C++ builds
23:22 tcurtis joined
dalek TT #1609 created by jkeenan++: tools/docs/filename_and_chapter.pl: Can we make this work with our coding ... 23:23
TT #1609: trac.parrot.org/parrot/ticket/1609
darbelo seen kid51? 23:25
purl kid51 was last seen on #parrot 3 days, 7 hours, 34 minutes and 56 seconds ago, saying: Those two files should have been governed by an svn:ignore property. Committed fix in r46204. [May 1 15:50:42 2010]
cotto_work istr that he's avoiding irc atm. 23:27
darbelo I think he just opened a ticket for the issues chromatic solved in r46292 23:28
cotto_work yeah 23:29
darbelo msg plobsing trac.parrot.org/parrot/wiki/GSoCersStartHere could use some review from mentors, feel free to point your student there and add any data you feel is relevant. 23:32
purl Message for plobsing stored.
darbelo msg Whiteknight trac.parrot.org/parrot/wiki/GSoCersStartHere could use some review from mentors, feel free to point your student there and add any data you feel is relevant.
purl Message for whiteknight stored.
Whiteknight gotcha. Will look at it soon 23:33
darbelo msg cotto trac.parrot.org/parrot/wiki/GSoCersStartHere could use some review from mentors, feel free to point your student there and add any data you feel is relevant.
purl Message for cotto stored.
Coke no change on branch - it's up to 3G of resident on pbc_to_exe
darbelo msg chromatic trac.parrot.org/parrot/wiki/GSoCersStartHere could use some review from mentors, feel free to point your student there and add any data you feel is relevant.
purl Message for chromatic stored.
Coke 4G...
cotto_work Mmmm. darbelospam
darbelo msg allison trac.parrot.org/parrot/wiki/GSoCersStartHere could use some review from mentors, feel free to point your student there and add any data you feel is relevant.
purl Message for allison stored.
Coke (granted, it's not been synced with trunk in a day or two)
darbelo Maybe a few of those msgs were redundant ;) 23:34
purl needs to learn about multiple recipients.
purl darbelo: excuse me?
treed darbelo: You've offended purl.
darbelo We've said worse to each other. We have an (mis?)understanding. 23:35
cotto_work reciprocity
darbelo There he goes, adding value to the conversation. Just as I was about to call treed a bot-liker... 23:37
Now I've lost my momentum *and* have to go find a dictionary. 23:38
23:45 bubaflub joined
tcurtis Coke: can you give the required permissions for posting on parrot.org? My username there is tcurtis, as it is here and on trac. 23:50
darbelo tcurtis++ # First victim. 23:51
Coke tcurtis: done, I think. 23:52
darbelo Blog urls are of the form www.parrot.org/#username IIRC. 23:53
s/#//
Coke IWBNI if there was a way to define c-level functions in a PMC that were automatically renamed to, e.g. Parrot_Codestring__coalesce, that used C-style args like a vtable. 23:54
tcurtis I'll probably write an initial blog post either tonight or tomorrow. 23:55
Coke (I hesitate to make a method for something that's basically just a helper function.) 23:56
darbelo Coke: You, can just use helper functions...
Coke yes, I just want sugar. 23:57
darbelo Oh. Totally misread that. 23:58
Sorry.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!