Parrot 0.9.0 | parrot.org/ | 500 unresolved RTs left.
Set by moderator on 7 February 2009.
dalek rrot: [pcc] Auxillary changes for calling convention file moves.
review: trac.parrot.org/parrot/changeset/36512/		 00:00
mikehh I also must folloe dalek: a little more closely 00:01
follow 00:02
Whiteknight VTABLE_morph is turning out to be huge headache. Plus, all PMCs appear to implement it in the same way (by not implementing it and passing it to default:morph) 00:04
so I'm thinking we kill the VTABLE method entirely since it's worthless
NotFound Whiteknight: +1
purl 1
Whiteknight we can keep the morph opcode, since that will pass through directly to pmc_reuse. 00:05
00:09 AndyA joined
Whiteknight unfortunately, I'm having to rip out several VTABLE_morph calls just to get things to work right and preserve sanity 00:31
allison Whiteknight: sensible, morph is only really useful for Perl 5 scalars, and they all do morphing internally to other VTABLE functions, don't really need a separate morph 00:34
dalek rrot: r36513 | chromatic++ | trunk/ext/Parrot-Embed/lib/Parrot/Embed.xs:
[Parrot::Embed] Tidied code; no functional changes.
NotFound allison: a pointer in the vtable struct will be a good place for the inheritable arg list? 00:39
allison NotFound: that could work (something along the same lines as the pmc_class struct member) 00:41
mikehh allison: the changes you made to the pdd*.pod files need to be made to the draft/pdd*,pod files 00:47
would you like me to work on that or have you done so already
allison mikehh: please, go ahead, and thanks 00:48
Infinoid yay, I'm finally home. Now I can start digging into the I/O bug 00:58
00:58 Khisanth joined 01:04 TiMBuS joined
allison curious, pbc_to_exe is truncating parrot_config.c about 8000 bytes into the file. I wonder if it's related to pmichaud's changes? 01:08
rg see TT#296. hopefully infinoid++ will have a fix shortly ;) 01:09
01:12 Andy_ joined
allison rg: got it, thanks, will comment out of my makefile (I don't need parrot_config.c for what I'm working on) 01:14
Whiteknight allison: There was a big stink about that this morning, pbc_to_exe was having some kind of buffering problem with Parrot IO
01:14 Andy joined
Whiteknight file was being truncated to 8192 bytes, don't know if it's been resolved, or if anybody has worked on it 01:14
allison but only on 64-bit platforms
Whiteknight i don't really know much about it, there was some email traffic flying around earlier oday 01:15
Infinoid Whiteknight: I'm digging into it now
allison: so far it seems like a bug that was exposed somehow by pmichaud's changes 01:16
(the changes themselves look innocent.)
allison Infinoid: have you been able to extract the bug into a simple test case? 01:18
01:19 gryphon joined 01:25 Fayland joined
Infinoid allison: Actually, executing pbc_to_exe is a pretty simple test case. I'm just learning parrot's I/O stack as I go. 01:26
I'm in gdb right now, and I've verified that Parrot_io_putps() is called with more data than gets emitted to the file 01:27
01:32 gerd joined 01:33 kid51 joined
dalek rrot: r36514 | whiteknight++ | branches/vtable_morph_change:
fix a bunch of VTABLE_morph calls to redirect to pmc_reuse, and fix a few tests to use the new opcode
 01:33
rrot: r36515 | chromatic++ | trunk/ext/Parrot-Embed/lib/Parrot/Embed.xs:
[Parrot::Embed] Allowed multi-level namespaces in find_global(). Pass in a

delimiter. This is a temporary hack, but it's a decent one.		 02:09
rrot: r36516 | Infinoid++ | trunk/src/io/buffer.c:
[io] Fix Parrot_io_write_buffer()'s buffer rotation case

flushed it, and then put the rest of the data into the (now empty) buffer. However, it didn't set the "buffer has data in it and needs to be flushed" flag (which had been unset by Parrot_io_flush), and the extra data was dropped. Set the flag. This fixes TT #296.		 02:10
Infinoid I've no idea why that bug wasn't universally reproducible. 02:11
chromatic Buffer size?
purl Buffer size is, like, set in SysRW
Infinoid The bug was apparently reproducible on x86-64 but not x86-32. 02:12
For that to work, the buffer would have to be *smaller* on x86-64...
Should work now in any case. 02:13
rg: Fix is in, feel like testing?
Whiteknight allison++ on the runloops idea. Going to require some careful thought, but a very interesting idea
rg already compiling ;)
Infinoid rg++
rg and it got through
02:15 tetragon joined
Infinoid So now I can see t/native_pbc/integer.t fail again, hooray. 02:15
Coke_afk throws fperrad under the ticket bus.
rg is it me or is the test suite actually more verbose about todo tests? 02:17
Coke rg: it's the test harness. 02:18
at some point, you probably switched from T::H 2 to T::H 3.
which has different defaults.
rg ah. I've installed Test::Harness with Test::Harness::Archive for running smoke tests 02:20
Coke that would do it.
dalek rrot: r36518 | Infinoid++ | trunk/examples/pir/pirric.pir:
[cage] Remove some trailing spaces.
 02:21
NotFound allison: I've added a new patch to TT #299 that implements the attribute adding during pmcproxy creation. 02:26
02:26 leto_ joined 02:28 cognominal joined
allison NotFound: looks good. change 'inh_args', to 'attr_defs'. It will likely also be used for introspection into low-level PMCs 02:34
NotFound Urgh, the intention was to write attrs, no args... what a confusion 02:37
02:49 HG` joined
Coke allison: is rt.perl.org/rt3/Ticket/Display.html?id=46007 resolved to your satisfaction? 02:52
(I see a reference to the GPL in NEWS, docs/faq.pod, and a spurious match in src/malloc.c; there's a bunch of matches in languages/urm, but we can boot urm out. 02:53
I'll just comment on the ticket.
allison Coke: in all, I'd say move language/regex and languages/urm out of the core repository 02:55
Coke languge/regex is clean.
(at least before a build)
allison Coke: okay, and looks like the Copyrights have been cleaned up on languages/regex too, so I'm removing the notice from ports/debian/copyright 02:57
Coke opening a TT for urm, closing the original ticket.
dalek rrot: r36519 | allison++ | trunk/ports/debian/copyright:
[debian] Removing copyright exception that's no-longer true.
 02:58
allison Coke: compilers/imcc is the other problem child
Coke allison: has Melvin assigned copyright to the TPF? 02:59
allison Coke: which could be resolved by getting a contribution agreement from Melvin
Coke s/the//
Ok. I will open a trac for that.
allison Coke: And Pod::Simple will be taken care of if we shift to a PIR-based Pod parser 03:00
Coke: so, yes, satisfied with that ticket closing 03:01
Coke Or if we don't ship Pod::Simple. =-)
(see also the ticket about getting stuff in CPAN out of core.)
allison Coke: yes, we could also call it an external dependency
Pod::Simple is only used for HTML generation
Coke: and, agreed on getting stuff in CPAN out of core. There's absolutely no reason for us to maintain separate versions of that stuff 03:02
Coke are you ok with requiring Bundle::Parrot for developers?
allison Coke: yes 03:03
Coke well, not requiring it specifically, but you know what I mean.
03:03 HG` joined
allison Coke: yes. It's along the same lines as "you need lex/yacc or flex/bison to rebuild imcc" 03:03
Coke some of the items we need for the build. 03:04
like File::Which, I think.
allison Coke: is there any way we can remove that build dependency?
Coke dunno. I just notice that one of our Configure pm's is using it. 03:05
Seems like something a perlish cage cleaner could attack.
dalek rrot: r36520 | jkeenan++ | trunk/config/gen/makefiles/dynpmc_pl.in:
Deleting comment referring to TT #289, which we are resolving.
allison Coke: okay, a note for the ticket, then that when moving stuff out of core we need to check our build dependencies 03:06
(building should require nothing beyond core perl)
Coke looks for unclosable RTs that only have the original post. 03:13
kid51 Are these files doomed to start failing again once a week: t/native_pbc/integer.t ? 03:14
chromatic Probably. 03:15
purl Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
Coke until the underlying issue is fixed I would not be surprised by intermittent failures. I'd report them as followups on the original ticket.
the more reports rurban has, the sooner he can fix it.
chromatic If only someone had thought to disable those tests until we had them fixed.
That would have been brilliant.
Coke chromatic: this is the path of least resistance to getting feedback. 03:16
kid51 In the ticket, rurban said he would TODO them.
Coke kid51: I thought he had and then had un-todone them.
(based on further work he did)
chromatic Yes, but we have TODO and SKIP and branches for a reason. 03:17
kid51 un-todone ?
chromatic That reason has a lot of similarities to the problem right now.
03:17 HG` joined 03:24 TiMBuS joined
kid51 Trac detected an internal error: 03:31
OperationalError: database is locked
Got this 3x in a row
chromatic File a tick... oh wait. 03:32
dalek rrot: r36523 | coke++ | trunk:
Close out several language-specific RTs from parrot's queue, but list them for the language maintainer if needed.
Coke does the "stalled" status on a RT really tell us anything interesting as we try to close out the remaining tickets?
moderator Parrot 0.9.0 | parrot.org/ | 484 RTs remain 03:32
kid51 Coke: I don't think so, but then I have rarely classified a ticket as 'stalled'. 03:34
allison Coke: to a certain extent, yes. a ticket that's been 'stalled' for 4 years, it's worth reexamining to see if we actually ever plan to implement the request
Coke allison: if that were the case, we shouldn't have stalled them, but rejected htem 4 years ago. =-)
allison Coke: yes, we should have, but in many cases the person who marked it as stalled didn't feel like they had the authority to reject it 03:35
kid51 allison: But that applies to a *vast* number of tickets, including most TODO tickets.
allison kid51: yes it does
I've started rejecting tickets that fall in that category
Coke I guess my point is, the 38 tickets that are stalled are, at this point, not much different than the 445 that aren't.
*officially stalled 03:36
kid51 Coke: agreed
allison Coke: yes, I agree
Coke: pretty much anything left in RT at this point could be marked as "stalled"
Coke allison: ayup.
kid51 I've noticed several patterns in what remains in RT
Coke I just closed out all the language-specific tickets.
languages/-specific, that is. 03:37
kid51 Vast amounts of tickets created by PTC in mid-2007 to guarantee that every TODO FIXME XXX has a ticket.
allison Coke: good, that helps
kid51 But it's likely that many of those TODOs were random musings by early (i.e., pre-kid51) Parrot developers.
NotFound kid51: and probably lots of them no longer exists 03:38
Coke kid51: yup. unfortunately, now they need to be reviewed.
kid51 So there are many cases where, yes, I don't feel I have the knowledge to reject a ticket.
Coke you can reject them if the comment/function has been deleted.
there were a lot that didn't survive subsystem refactorings.
allison kid51: yes, many of those I've found refer to dead code paths, especially after the refactors
kid51 NotFound: Well, where I have found RTs about TODOs and I can no longer locate them, I've closed them.
Coke speaking of dead code, I saw some #if 0 .... code get checked in recently. mreh.
kid51 But I feel I've got most of the low hanging fruit there.
Coke allison: you might be able to reject this one: 03:39
rt.perl.org/rt3/Ticket/Display.html?id=55210
allison kid51: yes, many of the ones I found needed some careful thought, but I mostly ended up rejecting them and removing the TODO comment from the code
NotFound Coke: some is mine, thing in the debugger that are semi-done and undertested
Coke shouldn't that go in a branch, then/ 03:40
?
(following in chromatic's thoughts from earlier.)
NotFound Coke: nobody uses the debugger except me X-)
allison Coke: mmm... yes 55210 can be rejected, PGE is our pattern matching 03:41
kid51 Speaking of the debugger ... When I run 'make test' and get to the test for the debugger, it always says, "Parrot debugger hasn't been built yet." Does that mean we don't have a debugger?
Coke kid51: no, just that the default target doesn't build it.
03:41 janus joined
Coke I would argue that the default target should build the debugger. 03:41
kid51 There are a whole bunch of tickets about PDD13 which Infinoid should look at. 03:42
allison I can see some potential for an opcode or set of opcodes that make interfacing with PGE simpler, but that's along the lines of "Patrick may add someday", not ticket-worthy
NotFound kid51: make worl
kid51: make world
purl i guess make world is not for release managers only
kid51 There are a whole bunch of tickets about PIR that Barney should look at.
Coke kid51: you can probably take all the 'TODO DEBUGGER' tickets and convert them into a wiki page on trac instead of N trac tickets.
we have a precedent for FooTaskList now on the wiki that we can probably convert a few hundred RTs into 4 or 5 pages on the new wiki.
anyone know what 'make distcheck' is supposed to do? 03:43
rt.perl.org/rt3/Ticket/Display.html?id=38190
NotFound BTW that message just means that the parrot_debugger executable is not built, but the debugger is in the core anyway.
Coke if it's not built, then it's not tested, and therefore doesn't count. =-) 03:45
(we should build it with 'make', IMO)
NotFound allison: the corrections and some improvements of the ARGS inheritance thing are ready. Do you want to review the patch, or can I commit it right now?
allison NotFound: go for it, I'll look over the commit log 03:48
NotFound Ok. Be ready for realclean, boys
03:49 MagnusShortwave joined
kid51 must sleep 03:52
purl $kid51->sleep(8 * 3600);
03:54 leto_ joined
Coke allison: can we delete the unified testing branch? 03:58
allison Coke: yes, I believe so 04:04
Coke: IIRC, that was migration to a new version of core Perl testing modules, which has been completed 04:05
Coke even if it's not done, that branch is /old/
purl Hmm. No matches for that, Coke.
Coke roger.
allison Coke: so nuke it. It's always recoverable later 04:06
dalek rrot: r36527 | coke++ | branches/unified_testing:
Resolve RT #45601 by removing branch.
 04:09
rrot: r36528 | NotFound++ | trunk/t/pmc/exceptionhandler.t:
[test] fixed an untodoed a exceptionhandler test, TT #154
 04:10
tracwiki: v5 | coke++ | BranchDescriptions 04:11
Coke rakudo-folks: there's a few branches that appear to be rakudo specific. Are they still active?
dalek tracwiki: trac.parrot.org/parrot/wiki/Branch...?version=5
shorten dalek's url is at xrl.us/befovb
Coke hurm. didn't tracwiki used to show who made the edit?
moderator Parrot 0.9.0 | parrot.org/ | 479 RTs remain 04:16
Coke allison: if you could weigh in on rt.perl.org/rt3/Ticket/Display.html?id=61286, I am thinking it's rejectable. 04:22
(sorry, fperrad)
Infinoid Coke: it does, there's a coke++ in there 04:34
allison Coke: agreed 61286 can be rejected 04:37
Coke: we don't need to add opcodes for things that can already be easily accomplished with existing opcodes 04:38
04:47 NotFound joined
Coke Infinoid: whoops, missed it, my bad. 05:07
05:08 tetragon joined 05:11 Tene joined 05:15 jsut|work joined
dalek rrot: r36530 | allison++ | branches/kill_pccinvoke:
[pcc] Add the subsystem prefix to the function for building call
 05:42
purl signature objects are the parameter list.
06:08 petdance joined 06:25 eternaleye joined
TiMBuS /home/timbus/parrot/parrot -o perl6.pbc perl6.pir 06:59
make: *** [perl6.pbc] Segmentation fault
oh dear
07:00 masak joined
TiMBuS masak, does rakudo have a bug tracker? 07:04
masak TiMBuS: yes, it does. 07:07
purl stays quiet
masak TiMBuS: rt.perl.org/rt3/
TiMBuS oh, it stayed on rt 07:08
07:08 alinbsp joined
masak TiMBuS: it did, because RT is for Perl, and Rakudo is a Perl implementation, albeit 6. 07:09
TiMBuS i see.. well, rakudo is segfaulting for me on build and it wasnt last night 07:10
masak TiMBuS: I've heard this form a few people.
TiMBuS i dont think rakudo has updated since then, so its a parrot thing?
masak please submit a bug report.
TiMBuS: there are speculations as to what the cause is.
nothing conclusive. 07:11
TiMBuS should i start rolling back parrot revisions to pinpoint it? 07:12
masak TiMBuS: that would be awesome.
TiMBuS just got a backtrace and its happening from Parrot_ResizableStringArray_push_pmc 07:13
chromatic Did you do a 'make realclean' recently? 07:16
TiMBuS yes 07:18
i had to do a big clean since parrot has been producing a parrot_setting.c what won't compile when i make 07:19
that*
chromatic NotFound had a checkin a couple of hours ago that looked like it needed one. 07:20
TiMBuS ok, clean checkout, clean rakudo, it's working. all is well 07:24
moritz TiMBuS: current rakudo is excluded for parrot's 'make realclean', so you have to do a 'make clean' in rakudo as well 07:28
07:46 Theory joined 07:47 iblechbot joined 08:14 Fayland_ joined 08:33 leto_ joined 08:54 alvar joined 10:14 kj joined 10:38 mikehh joined 10:49 bacek joined
bacek hi there 11:14
11:28 iblechbot joined 11:35 masak joined 11:47 jimmy joined
dalek rrot: r36531 | fperrad++ | trunk:
[mingw] fix build (dynpmc & dynops) & tests in t/src/*.t, see r36404.
 12:06
rrot: r36532 | fperrad++ | trunk/src/pmc/exceptionhandler.pmc:
[codingstd] fix tabs
 12:29
jimmy make html failed. 12:30
dalek rrot: r36533 | fperrad++ | trunk:
[codingstd] fix SVN properties
 12:31
12:32 rg1 joined 12:58 jimmy_ joined 13:04 kid51 joined 13:23 Whiteknight joined
dalek rrot: r36535 | fperrad++ | trunk/docs/pdds:
[codingstd] fix PDD format
 13:33
mikehh fperrad: I was about to submit a patch for that but you beat me to it 13:49
Infinoid fperrad isn't on IRC much 13:51
mikehh++ for working on it though
mikehh I am also working on the darft/pdd's - my first cut passes t/codingstd/pdd_format.t 13:52
purl okay, mikehh.
mikehh draft that is 13:54
14:02 guru joined
Whiteknight are people still using parrotblog? 14:05
like, if I post an update there, will anybody see it?
or should I try to write a post to parrot.org instead? 14:06
Infinoid most recent post on both sides is from Coke :) 14:07
Whiteknight yeah 14:08
okay, I uploaded a post there anyway 14:23
14:29 alinbsp joined
Whiteknight and now my plea for help has officially been transmitted into the blogosphere 14:29
TEH-INTERNETZ++
Infinoid The intarblogs have been updated. Your intarwebs must be rebooted for the change to take effect. Reboot now? Y/n 14:30
Whiteknight: if those docs are turned into html and posted somewhere, that make it easier to link random people to. 14:34
s/that make/that would make/ 14:35
Whiteknight Yeah, we definitely have to fix the online documentation
I don't have access to alter the website, and I don't even know exactly where the online docs are being generated from. 14:36
kj Whiteknight: a clear plan for doing so would help definitely
Whiteknight starts writing up a ticket
Infinoid as a quick hack, I can always just stick a cron job on my server that does a find, runs pod2html and puts the result in a web folder, once every 10 minutes 14:37
it won't say "parrot" in the hostname, but as a consolation prize, it *will* say "squawk".
szbalint it will say things like "*croak* polly wants a cracker!" 14:39
Infinoid that part will have to go into the .pod :) 14:40
14:41 galf joined
Whiteknight that sounds like a nice idea, but I would prefer it be fixed on parrot.org properly 14:42
rg1 whiteknight: can you fix two typos in the announcement?
Whiteknight of course, beggars can't be choosers
I MAKE NO TYPOS!
but sure, I'll be happy to fix them
rg1 "the doorway though which"
+r please ;) 14:43
Infinoid I don't know who runs parrot.org, but I can send them a cron script I suppose
rg1 "help us to idenfity the"
Whiteknight done 14:45
rg1 great. :) now if i only had time to read all that documentation :/ 14:46
14:47 gryphon joined
Whiteknight every little bit counts 14:53
hell, you read one blog post and caught two typos. 14:54
kj Whiteknight++ # help wanted post 14:55
Whiteknight thanks! We needed something
Infinoid Whiteknight: what's wrong with "make html"? It emitted some failure messages about bignum, but otherwise seems to have worked 14:58
Whiteknight i don't think there is any problem with "make html" 14:59
at least, no problems that I've seen
Infinoid oh, oops. I was following up to a comment on TT #305, but Coke posted that, not Whiteknight 15:00
Coke_afk: hi :)
Coke hi.
yes, we can eventually automate it to track svn-latest. for now, let's worry about getting releases available.
"wrong with make html". perhaps nothing. 15:01
Whiteknight I'm happy with however we do it, so long as we do something 15:02
the current online docs are shitcrapular
Coke yup. been on the todo list since about 0.5.0
Whiteknight: most of the online docs are from the reop.
"repo"
so you can fix them in the repo, and they get fixed online. 15:03
Whiteknight I know, but their current status is lousy: being on parrotcode.org, using the lousy formatting, not all the files are uploaded, etc
moritz do they alread appear on parrot.org? or still limited to parrotcode?
Coke just parrotcode.
Whiteknight: feel free to assign me that ticket since I have privs on parrot.org 15:04
Whiteknight I'd ask to get privs on there myself, but I already have too many other things to work on 15:05
I hope you don't mind if the partcl/PCT projects gets pushed down in my queue a little bit, this calling conventions thing exploded into importance yesterday 15:09
15:16 particle joined
dalek rrot: r36536 | cotto++ | trunk/t/compilers/imcc/syn/pcc.t:
[imcc] add test for ridiculous number of params
 15:21
15:24 buildbot joined
cotto What's the non-deprecated spelling of "DOD"? 15:28
GC?
purl GC is the boehm conservative garbage collector at reality.sgi.com/boehm/cg.html or a really really bad perl "programmer" or GrandCentral.com or branches/gsoc_pdd09 or a travesty against god
Whiteknight cotto: GC
Coke Whiteknight: getting the calling conventions faster will help partcl more than a conversion to PCT. 15:32
Whiteknight yeah, I figured as much
dalek rrot: r36537 | fperrad++ | trunk/tools/install/smoke.pl:
[install] remove perl6, mark lisp as broken
 15:38
pmichaud improving calling conventions will be a Win for everyone. 15:40
and for anything that uses PCT, a huge win.
15:40 wknight8111 joined
pmichaud (and for anything that uses PGE, a huge win) 15:40
15:41 Theory joined
whiteknight I've been staring at this code for quite a while now, I'm convinced there are some major improvements to be made 15:41
dalek rrot: r36538 | cotto++ | trunk:
[gc] update names of dod_register_pmc and dod_unregister_pmc
 15:43
15:45 Tene joined
whiteknight this trac "browse source" really helps give a sense about how old and stale some things are 15:46
especially branches, we have some branches that are years old
15:54 bkuhn joined
cotto Hi, bkuhn 15:58
dalek rrot: r36540 | whiteknight++ | branches/vtable_morph_change/src/pmc:
[vtable_morph_change] update bignum.pmc and bigint.pmc to use pmc_reuse for most cases where morph had been used. Some refactors still needed in both these two
 16:03
rrot: r36541 | cotto++ | trunk:
[gc] update various function and variable names from "dod" to "gc"
 16:04
whiteknight hmmm... dalek appears to have skipped r36539 16:05
cotto I think dalek's sick. 16:07
Infinoid huh, thought I fixed that.
clearly, I need a test suite. 16:08
dalek rrot: r36542 | NotFound++ | trunk:
[io] report close errors back to callers, TT #297
 16:15
Infinoid in the meantime...
rrot: r36539 | whiteknight++ | branches/vtable_morph_change:
[vtable_morph_change] Update to trunk from r36538 to get past the IO buffering problem. Branch builds now
whiteknight haha, thanks Infinoid! 16:16
particle sees Infinoid removed the "skip whiteknight's commits" code from dalek
Infinoid whispers "it only skips his commits when the rev number modulo 5 == 4" to particle 16:18
whiteknight if you've taken the effort to write that code in the first place, by all means keep it in 16:21
dalek rrot: r36543 | cotto++ | trunk:
[gc] update do_dod_run to do_gc_run
particle $haze_the_new_guy->() 16:22
whiteknight am I still the new guy?
particle if you have to ask... 16:23
whiteknight damnit
Coke <nelson/>
16:25 hercynium joined, gryphon joined
particle ok, so why am i getting unresolved external PMCNULL when i try to link to the dynamic libparrot.lib, but not the static one? 16:26
or, should i expect this to be the case? t/src/compiler.t is failing with msvc because of this
whiteknight $haze_the_old_guy->()
:)
particle :P
Infinoid another problem with PARROT_DATA?
particle should PMCNULL be externally available? 16:27
PMC_IS_NULL() i expect
Infinoid I would assume so, as you can't have PMC_IS_NULL() without it
yeah, that.
purl Sure, that.
dalek rrot: r36544 | whiteknight++ | trunk/docs/book/ch03_pir_basics.pod:
[Book] a few misc fixes in chapter 3
 16:28
Infinoid NotFound and I have been hatching an evil plan to get rid of the Parrot_*_encoding_ptr and Parrot_*_charset_ptr global variables, due to another PARROT_DATA-related failure on win32.
particle the part of interpreter.h that defines PMCNULL is inside #ifdef PARROT_IN_CORE
Infinoid something to do with lazy linking and values showing up as 0x0 to code outside the dll, I don't really understand the details. 16:29
particle well, heck, i don't see PMCNULL defined for extensions 16:33
Infinoid PMC_IS_NULL() defines to a function call when PARROT_IN_CORE isn't defined
so I guess that should work. 16:34
particle ok, that seems appropriate
Infinoid where exactly is it failing?
particle # Failed to build 't\\src\\compiler_5.exe': compiler_5.obj : error LNK2001: unresolved external symbol _PMCNULL 16:35
i'm checking compiler.t now
of course PMCNULL isn't mentioned anywhere
Infinoid time to look at some preprocessor output, methinks 16:36
particle i wonder where PARROT_IN_CORE is set...
parrot.h
purl well, parrot.h is still not installed? 16:37
particle forget parrot.h
purl particle: I forgot parrot.h
Infinoid as opposed to embed.h, I suppose
particle yep, not defined in embed or extend, as expected
Infinoid but if we're going to all the trouble of getting linker stuff right to access these things internally, it makes me wonder, what exactly is PARROT_IN_CORE supposed to mean? "gimme all the nifty things that we can get, but we don't want to give to our users"?
or is it an attempt to avoid namespace pollution? 16:38
particle separate the external/internal api, i think
NotFound _PMCNULL? That thing is not supposed to exist.
particle yeah, i'm wondering how it got there 16:39
NotFound PARROT_IN_CORE is supposed to be used for things than gets linked into the parrot dynamic library 16:40
whiteknight I think it's defined as part of a compiler flag
16:40 hercynium left
NotFound So if you are in core you can access several things without depending of runtime linking. 16:41
Namespace poluution we have a lot, BTW
Infinoid but if you're getting linked into libparrot.so, you don't need the special linker fixups anyway 16:42
NotFound: so if its for things that get linked into the parrot dynamic library, as you said, then why have PARROT_DATA at all?
NotFound Infinoid: supposedly for things that are not in core 16:44
Better said, things that needs to be accessed from the outside. 16:45
Infinoid ...which wouldn't have PARROT_IN_CORE defined, and thus, don't get the PMCNULL definition anyway
that's why I'm wondering if I misunderstand PARROT_IN_CORE, because it seems like the PARROT_DATA stuff will never be used in this case 16:46
particle aargh.
Infinoid sorry, I'll stop asking hard questions.
particle too early for headaches! i hate compilers.
NotFound PMCNULL is a macro, it gets defined in one way for usage within core, and other for the outside. The rationale for that is speed. 16:47
Uh, i was mistaken PMCNULL with PMC_IS_NULL 16:48
Infinoid yes, and I'm ok with that. But the *variable* PMCNULL is declared as PARROT_DATA, yet is protected from external access by PARROT_IN_CORE
which seems like it wouldn't need PARROT_DATA 16:49
NotFound Forgive me, I don't sleep much tonight
Infinoid particle: I've got preprocessor output if you want it. compiler_5.c included parrot.h so it got PARROT_IN_CORE, so it is trying to use PMCNULL in the PMC_IS_NULL() check
particle right. 16:50
i'm wondering if it should have parrot.h at all.
should extensions include parrot.h?
NotFound * Only parrot core files should include this file. 16:51
Extensions should include <parrot/extend.h>.
Programs embedding parrot should include <parrot/embed.h>.
*/
Infinoid NotFound++
particle: I was wondering the same thing. Worth a try, I think
particle and this code includes all three.
removing parrot.h isn't enough, same error 16:52
NotFound Is the head of the file, not much work ;)
particle so, these are embedding parrot. let's go with embed.h only and see....
Infinoid seems like all the tests in that script include all 3 16:53
particle yes, probably a naïve attempt to fix this
include all three, and link static
joy, a different error.
NotFound Well, if you link statically against parrot, you are in core, in that sense. 16:54
particle right, which is why it worked before
NotFound But if is a test, is no testing very well the intended usages
particle now cl fails
actually, ccache cl fails
Infinoid are you getting failures from all 5 tests, or only #5? 16:55
particle all five
compiler_1.c 16:56
t\\src\\compiler_1.c(5) : error C2143: syntax error : missing '{' before '*'
t\\src\\compiler_1.c(7) : warning C4431: missing type specifier - int assumed. Note: C no longer supports default-int
t\\src\\compiler_1.c(10) : error C2065: 'STRING' : undeclared identifier
etc
Infinoid yeah, I see those on linux too.
particle good. misery spread equally. 16:57
Infinoid parrot.h is nice and friendly and tries to include the world for you; embed.h is far less friendly.
whiteknight how do we access the command-line arguments from PIR?
particle as it should be. however, it *should* work.
whiteknight: .sub 'main' :main ; .param pmc args 16:58
Infinoid tries adding parrot/string.h, etc to the test
PerlJam whiteknight: aren't they available as a parameter to the main routine?
particle or is it argv? i forget
ah, doesn't matter,
they're just there, call 'em what you will.
NotFound IMO better make it :optional 17:02
dalek rrot: r36545 | whiteknight++ | trunk/docs/book/ch03_pir_basics.pod:
[Book] Add some basic stubbish information about IO
Infinoid particle: wow, we need lots of work here.
particle Infinoid: it's really scary to see this. 17:04
PerlJam is suddenly glad he didn't see what Infinoid and particle are talking about.
particle how did mod_parrot ever work? it must be wrong, whatever it's doing.
Infinoid You don't get STRING. you don't get PMC. Which makes PMC_IS_NULL kind of a moot point. 17:06
NotFound Talking about io. The close opcode does not return a result code and does not throw when close fail.
Infinoid NotFound: ETESTCASENEEDED 17:07
particle Infinoid: this needs a big, fat trac ticket.
Infinoid: what do you think about "correcting" these tests to fail everywhere, and skipping them as they're all broken?
Infinoid I've no problem with that. I'd like to rename the test to embed.h, too. 17:08
particle gcc-- for not picking up the missing symbols in the first place. msvc++ for being a picky compiler.
NotFound Infinoid: A test of a really failing close? I don't know any reasonable way of doing that.
particle good idea.
Infinoid gcc works fine. its GNU ld that's being too friendly 17:09
purl couldn't get the headlines: hachi.kuiki.net/rss/randline.pl/gibi_long.txt wasn't successful
particle ah, right, ld.
gcc++ ld--
Infinoid NotFound: maybe call it on an already-closed filehandle
NotFound Infinoid: not sure if that will be marked as failed in all platforms 17:10
Infinoid I'm not even sure it returns int on all platforms.
NotFound In fact it does not, the win32 version uses CloseHandle
Infinoid particle: Uh, I meant embed.t, of course :)
NotFound Infinoid: but about the point that it does not throw, you just need to look at the code. 17:11
particle does "@echo:" on linux echo a blank line from a makefile/shell script? 17:12
er, makefile, not shell script
Infinoid Nope. That's the target name, not a command
without a :, I'd expect a blank line
particle all:\\n\\t@echo: 17:13
NotFound bash: echo:: command not found
particle make help # quotes everywhere on win32
it has @echo "" for blank lines
Infinoid particle: yeah, it tries to look for a command with a colon in its filename
particle feh. need a portable way to display help from makefile 17:14
perl, maybe?
Infinoid what's the colon for, anyway?
NotFound And the second ':' is a courtesy of bash error reporting
particle on windows, echo: echos a blank line
er, on windows nt and beyond
Infinoid does echo "" work?
particle on dos-95, it was echo.
echo "" echo's ""
Infinoid how about echo \\ 17:15
NotFound By 'windows' do you mean CMD.EXE?
Infinoid (with a trailing space)
particle i suppose cmd.exe uses echo: and command.com uses echo. for blank lines
Infinoid hrm. yeah, perl might be your best bet
NotFound Anyway, none of them uses the quoting and other punctuations the same way as the sh family 17:16
Infinoid $(ECHO_BLANK_LINE)
particle all the lines have "" in windows
Infinoid are those quotes echoed to the screen on windows? 17:17
particle ""
"Following targets are available for the user:"
""
"Executables:"
UGLY.COM
Infinoid eew.
We could always ship a make.pl. 17:18
(that'd be uglier but at least consistent)
NotFound Is this what they call the Wow! factor or something?
particle so can i create a ticket via email? parrot-tickets@lists.parrot.org 17:22
Infinoid that's the list. tickets@parrot.org is trac
once replies/followups work, we'll want to update the list config to use trac in the Reply-to: address 17:23
Coke src/bignum* was recently removed? 17:25
ah, r36461.
17:28 rurban joined
dalek rrot: r36546 | coke++ | trunk:
Fix 'make html' - the files that had this documentation were removed in r36461.
 17:28
NotFound ¿Qué la habeis hecho a Sevein para que se ponga a twitear a lo loco? 17:29
Ops, wrong channel
Infinoid as part of the whole "isolating parrot from perl" thing, are there any plans to stop uploading it to CPAN? 17:31
particle <tickets@parrotvm.osuosl.org>: Command died with status 1:
"/usr/local/bin/run_email2trac --project=parrot". Command output: TD:
saving email to /tmp/tmpjbLys8.email2trac
pmichaud I suspect that 0.9.0 (or perhaps 0.9.1) will be the last CPAN uploads of Parrot.
particle feh. time for the web interface :(
pmichaud: yes, i think we're ftp-only from now on
Infinoid hrm, looks like email2trac has regressed somewhat 17:32
dalek rrot: r36547 | cotto++ | trunk:
[gc] change all instances of lazy_dod to lazy_gc
Infinoid basic: any update on email2trac? Or anything I can do to help?
Infinoid one nice thing about having almost nothing available to embedders: it means far fewer things are subject to DEPRECATED.pod cycles 17:33
Infinoid ups a new svn-bisect to cpan 17:35
dalek rrot: r36548 | particle++ | trunk/t/src/compiler.t:
TT #306: embedding parrot fails, many symbols not exported properly
 17:36
rrot: r36549 | particle++ | trunk:
[t] rename t/src/compiler.t to aptly-named t/src/embed.t
 17:38
17:42 contingencyplan joined
dalek rrot: r36550 | cotto++ | trunk:
[gc] update names of dod_runs, dod_blocks and dod_time
 17:43
cotto whiteknight, ping 17:44
dalek rrot: r36551 | rurban++ | trunk:
TT #274: renable solaris builds for 64bit, gcc and sunpro cc

  * enable --rpath and shared linking
  * disable the 'CC -G' hack as it doesn't correctly link in
   contrast to the default perl5 linker 'cc -G'
  * update PLATFORMS		 17:47
Util I would like to take ownership of a Rakudo RT ticket. 17:48
I have privilege to change tickets, but I am not listed as a possible entry in the Owner drop-down box.
Can someone add me to the list that populates that drop-down?
pmichaud Util: what's your RT name? 17:49
(and out of curiosity, what ticket?)
Util It is util, in lowercase
whiteknight cotto: pong!
Util Ticket 63004
rt.perl.org/rt3/Ticket/Display.html?id=63004 17:50
NotFound Infinoid: that will be the right way: making available just the things absolutely required
pmichaud doesn't that ticket just need to be closed?
cotto whiteknight, there's a reference to the otherwise undefined Parrot_dod_ims_wb in include/parrot/gc_api.h 17:51
Util I suspect so; prepping an email to masak to prod him. I can no longer reproduce the bug.
whiteknight cotto, that's probably for one of the old cores
the old ims core would have used that. I think it's been deleted though
pmichaud I'm pretty sure it's been fixed and nobody's closed the ticket. We tracked the problem down to a Parrot bug (that has since been fixed).
cotto it looks like it. Is it safe to delete the macro?
masak closes #63004 17:52
no prodding needed. :)
whiteknight cotto: delete the macro
pmichaud Do you have a "resolve" link in the upper-right side of the ticket display?
or perhaps "Take"?
masak the latter. 17:53
purl the latter is done by inspection
masak purl: no, the latter is <reply>
purl okay, masak.
masak purl: and you're stupid.
purl masak: i'm not following you...
pmichaud #ps in 37.
17:54 particle1 joined
Util masak, disregard email. pmichaud: thanks, no "resolve" link after ticket is closed, now. 17:55
pmichaud Util, okay.
dalek rrot: r36552 | cotto++ | trunk/include/parrot/gc_api.h:
[gc] remove an obselete macro from a gc header
 17:58
masak Util: duly disregarded. sorry for the delay.
Util no problem
masak also, thanks for the fix itself. :) 17:59
Util Very welcome. 3 days of work (on the source Parrot bug) got me so deep in code, that I may actually be able to sustain a string of extended contribution to Parrot and Rakudo. 18:00
dalek rrot: r36553 | rurban++ | trunk:
[cage] Fix TT #254 and RT #47940

  * Fix t/native_pbc tests
  * Enhance tools/dev/mk_native_pbc to check the current
   platform and create the correct tests automatically.		 18:03
Infinoid msg jhorwitz We want to make it easier to embed parrot; any chance you could comment on trac.parrot.org/parrot/ticket/306? 18:04
purl Message for jhorwitz stored.
rurban BTW re embedding: win32 has problems with static linking and dynpmc's. this should be noted somewhere better to use shared libs 18:05
Infinoid Getting dynamic linking right should be one of our goals
wait, what? dynpmcs don't work with static linking, PMCNULL doesn't work with dynamic linking? 18:06
rurban that was my mingw bug 18:07
But it should be properly tested and verified. I have no time now. It could be that just having shared and static libs together will fail. 18:08
NotFound Linking statically dynamic shared objects can be difficult, yeah 18:13
rurban Problem is that if a embedder wants to use /usr/lib/libparrot.a but there's also a /usr/lib/libparrot.so and dynpmc's are built (using -shared) 18:14
so we have two PMCNULL's one global static anbd one global shared, and they are not equal. as in my debugger sessions, which drove me crazy
Infinoid Sounds nasty. 18:15
NotFound We must kill PMCNULL
I want to kill lots of thing these days
rurban but checking for PMCNULL is fast 18:16
or just use NULL again?
NotFound rurban: someone said that the things that don't work are never fast.
rurban well, they do work, but you have to take care 18:17
Infinoid I don't like that there isn't an easily recognisable way to detect that failure. It's a nice, hard-to-find bug just waiting to happen. 18:18
rurban I was just writing a proposal how to handle the both static+shared libparrot case 18:19
Esp. when being installed. First just to improve mingw 18:20
NotFound My proposal is: never use external data symbols out of core.
Infinoid I don't know how to fix it. But maybe you could detect it by calling PMC_is_null(PMCNULL)? If code outside the dll has its own copy of PMCNULL, that should fail
rurban Good idea
purl couldn't get the headlines: hachi.kuiki.net/rss/randline.pl/gibi_long.txt wasn't successful
NotFound Infinoid: or not, if for some reason that PMCNULL is NULL
Infinoid Oh, what a glorious mess. 18:21
NotFound I think that a saner way will be to use the appropiate linking decoration for dll for each windows compiler used.
rurban But -Wl,/usr/lib -lparrot is also problematic. It works in the static/shared case but the dynpmc+dynoplibs linkers will fail
18:22 chromatic joined
rurban because they force -shared, and then the .so is picked up 18:22
chromatic I might be a few minutes late to #ps; please carry on until I get there.
Infinoid NotFound: I think the issue occurs if you're running in code that got linked to the static copy of libparrot, and then you call some other code that was linked to the dynamic copy
you end up with two PMCNULLs then, neither of which are NULL. 18:23
18:23 allison joined
Infinoid if I'm understanding rurban correctly... 18:23
18:24 rdice joined
rurban In build_dir we seperated dll in build_dir and static lib in blib/lib, but this will be collapsed when being installed. 18:24
So I'm trying to get that right, best to disable static at all on win32 18:25
Or if static is forced to disable dynpmc and dynoplibs
Something like that 18:26
Infinoid That would e less confusing
dalek rrot: r36554 | fperrad++ | trunk/languages/lua/src/pmc:
[Lua] metatable of LuaUserdata PMC is now an ATTR
Infinoid be
Infinoid meeting &
NotFound Infinoid: I think that will be excesively compliacting the general case in favour of a minoritary usage from peopla that probaly will use his own bulding tools and flags anyway.
rurban for most other platfoms we have --rpath, don't know about AIX though. This is quite similar to win32 18:27
yeah, I just want to disable static on win32
Infinoid The Default Should Work
I'm not opposed to making everything else work, as long as they don't break the default
If the default is dynamic, and dynamic works, then everyone is happy :) 18:28
rurban embedders also?
Infinoid Yeah. We have some work to do there.
rurban Bt I believe embedders will also use prefer shared 18:29
18:29 masak joined
PerlJam allison is an airplane mechanic? 18:32
< allison> - Substantial work on airplanes this week.
:-)
cotto she has many talents 18:33
allison lol :)
NotFound With the inflatable automatic pilot?
18:35 viklund joined
pmichaud particle: ping 18:36
18:37 rhr joined
masak pmichaud: github.com/bacek/rakudo/commit/0b68...89e9029a5f looks good to me; it's a partial fix to #61824. can I commit it? 18:38
shorten masak's url is at xrl.us/befqtb
pmichaud masak: I want to check the NOTREADONLY logic. I think we might have some refactoring there. 18:39
masak ok.
pmichaud i.e., I want to see if we already have a function that does what NOTREADONLY is doing.
masak pmichaud: FWIW, I'm pretty sure git can check out based on dates.
pmichaud masak: I couldn't find the magic incantation to do that.
Coke regarding readonly, would that be better done with a readonly vtable?
masak pmichaud: I could do some doc reading and come back to you.
or someone else might know right off.
pmichaud Best I could come up with was to find the appropriate commit by using --before with git-log, and then revert back to that commit. 18:40
masak there's some date syntax for commits, methinks.
pmichaud there's a date syntax for log stuff, yes.
but I couldn't make it work for 'clone' or 'checkout' or things like that.
and google searches didn't turn up anything. 18:41
anyway, if you could find that, it would be immensely helpful.
masak looks
viklund found it
pmichaud: if you checkout with -l you can do 'git co -l master@{date}' 18:42
pmichaud ... -l ?
hmmm
viklund yep, you'll get a new branch from that though 18:43
PerlJam pm: re git date based checkouts. git checkout master@{2009-01-02} # doesn't work?
pmichaud PerlJam: it didn't work when I tried it.
pmichaud@orange:~/parrot/rak2$ git checkout master@{2009-01-31}
error: pathspec 'master@{2009-01-31}' did not match any file(s) known to git.
Did you forget to 'git add'?
viklund I think you need to checkout the branch with -l first 18:44
pmichaud pmichaud@orange:~/parrot/rak2$ git checkout -l master@{2009-01-31}
error: pathspec 'master@{2009-01-31}' did not match any file(s) known to git.
Did you forget to 'git add'?
viklund then you can checkout based on date (without the -l)
that's how I did it anyway 18:45
PerlJam works fine for me.
pm: what version of git? 18:46
masak works here as well.
pmichaud git version 1.5.4.3
viklund I have, 1.5.6.5
masak 1.6.1
PerlJam pm: upgrade to 1.6.1 :)
pm: btw, you can see how git parses the master@{..} part with "git rev-parse master@{2009-01-31}" rather than attempting a checkout. either it will give you a SHA1 or it'll complain 18:48
pmichaud pmichaud@orange:~/parrot/rak2$ git rev-parse master@{2009-01-31}
warning: Log for 'master' only goes back to Tue, 10 Feb 2009 12:43:35 -0600.
0000000000000000000000000000000000000000
PerlJam yeah, that's complaining. upgrade git (I'm using 1.6.1 too) 18:49
pmichaud which is very bizarre, because git-log has no such complaints. :-) 18:50
masak what's the easiest way to make examples/library/md5sum.pir work from Rakudo?
pmichaud I suspect there's not yet an easy way.
masak pity. :/ 18:51
pmichaud you could try doing q:PIR { ... }
and then load_bytecode 'path/to/examples/library/md5sum.pir'
masak yes, I was thinking of something like that.
was just wondering how obvious such a solution is; haven't done much q:PIR { ... }
s/much/any/ 18:52
pmichaud we should be able to switch that to Q:PIR soon, too.
and get Q to work.
masak nice. 18:54
viklund mumbles 18:58
masak pmichaud: will Rakudo release next Tuesday just like Parrot? 19:08
pmichaud masak: no, rakudo releases will be a few days after
masak oki 19:09
pmichaud I haven't decided the exact schedule, but it may be "Thursday after Parrot release" or something like that.
masak sounds good.
pmichaud That gives us a chance to update Rakudo based on whatever is actually released in Parrot.
as opposed to trying to "guess"
masak by next Rakudo release, November will target Rakudo releases.
pmichaud excellent.
structure++
masak at least master will.
moritz pmichaud: do you want changing release managers as parrot does it right now? 19:10
pmichaud moritz: eventually, yes.
dalek tracwiki: v110 | kjs++ | ParrotRoadmap 19:15
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ersion=110
shorten dalek's url is at xrl.us/befq2c
pmichaud after I do "git checkout master@{2009-01-31}", how do I get back to the current head or a later date?
masak 'git checkout master'
pmichaud none of these seem to be working for me. 19:16
pmichaud@orange:~/parrot/rak2$ git --version
git version 1.6.1.2
moritz what's the error message? 19:17
purl somebody said the error message was at the bottom
NotFound "git checkout master".... looks like the name of an end of phase boss in a big game.
masak purl: no, the error message is <reply>
purl okay, masak.
pmichaud okay, so I do a fresh clone.
masak pmichaud: it usually works here...
Infinoid tries 19:18
pmichaud then
pmichaud@orange:~/parrot/rak2$ git checkout master@{2009-02-04}
warning: Log for 'master' only goes back to Tue, 10 Feb 2009 13:17:27 -0600.
Note: moving to "master@{2009-02-04}" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example: git checkout -b <new_branch_name>
HEAD is now at 577566e... More fixes to Configure.pl and makefiles
Infinoid do "git checkout -l" first 19:19
then master@{date} should work
pmichaud pmichaud@orange:~/parrot/rak2$ git checkout -l
pmichaud@orange:~/parrot/rak2$ git checkout master@{2009-02-04}
warning: Log for 'master' only goes back to Tue, 10 Feb 2009 13:17:27 -0600.
HEAD is now at 577566e... More fixes to Configure.pl and makefiles
Infinoid uh. that warning is relevant
pmichaud except that 577566e isn't the correct version. 19:20
oh, you said it's relevant.
19:20 mikehh joined
Infinoid yeah, 577566e is -rHEAD 19:20
Coke ah. make html looks just fine if you have the resources dir in the right place.
dalek tracwiki: v111 | kjs++ | ParrotRoadmap
pmichaud the warning may be relevant but it doesn't tell me what to do to avoid it. :-)
dalek tracwiki: trac.parrot.org/parrot/wiki/Parrot...ersion=111
shorten dalek's url is at xrl.us/befq2x
Infinoid I've got a clone here, and I'm also using 1.6.1.2 19:21
I did the same commands and got:
HEAD is now at 9f84067... Modify Configure.pl to use "rakudo" instead of "perl6"
PerlJam pm: you didn't do a shallow clone did you (with --depth)?
Coke someone help me pick a URL for the rendered docs from the repository.
dalek tracwiki: v112 | kjs++ | ParrotRoadmap 19:23
allison Coke: docs.parrot.org
dalek tracwiki: trac.parrot.org/parrot/wiki/Parrot...ersion=112
shorten dalek's url is at xrl.us/befq3u
Coke allison: that doesn't seem to exist yet. 19:25
can you update your plans on the subject on the recently opened ticket? 19:26
Infinoid allison: (regarding your #276 comment) is removing global variables not a good idea for it's own D[D[D[D[D[D[D[D[D[D[D[Dsake?
uh, some extra characters got inserted into there, sorry.
allison: Those patches were from something I was working on, but I consider it more of a cage cleaning task, not necessarily a direct solution to the dynpmc problem. 19:27
allison Infinoid: it's mainly that charsets don't belong in the interpreter
Infinoid I can certainly put them somewhere else, as long as it's somewhere accessible to everything that wants to use PARROT_DEFAULT_ENCODING and PARROT_DEFAULT_CHARSET. Do you have a place in mind? 19:28
allison Infinoid: especially since we're moving away from that implementation anyway
Infinoid I don't really like having them in the interpreter either, especially as those are cloned. NotFound++ suggested a static structure, which makes more sense to me 19:29
chromatic It'd be nice to slim down the interpreter.
NotFound My patch uses the interpreter just as a hook to locate the things. 19:30
Infinoid NotFound++ has an equivalent patch which uses functions to lookup the appropriate plugin based on name. Is that a better solution?
NotFound Just the same as other things actually do.
Coke allison: i added trac.parrot.org/parrot/ticket/305#comment:3 19:31
allison Infinoid: they already are a static structure "all_charsets"
NotFound The lookup by name is just the fast implementations, can ba optimized for the more frequent usages.
Infinoid Right, but better to export the function rather than the variable, I think. 19:32
So I like your approach
whiteknight allisonI hate missing #ps, but got pulled into a meeting for work
Infinoid whiteknight: heh, me too.
whiteknight (i didn't mean to say "allisonI", that was a weird autocomplete typo)
Coke moritz: any reason to keep the stub languages/perl6 about at this point? 19:33
allison whiteknight: we all miss some weeks, no stress
NotFound Infinoid: BTW the structure I used is not static, is allocated at the main interprter creation
moritz Coke: I'd keep it for one release; people might wonder what happened to it 19:34
NotFound And then pointed to the same in all childs
Infinoid the all_charsets and all_encodings arrays would probably work equally well
NotFound One dynamic allocation for all the life of the proccess is a very little price to pay, and avoid lots of thinking about platforms and linkages 19:35
Infinoid Ok. But that structure of yours doesn't necessarily have to live in the interp, or be copied 19:36
Coke moritz: what about perl6/src ? 19:37
(and the Makefile) ?
Infinoid You could just use some local variable pointers, and return those from the lookup function.
Coke do those help, or do you just need the README ?
moritz Coke: the Makefile is generated
Coke moritz: no reason for it to be anymore, is there?
NotFound In the interpreter there is a pointer to the structure, that is copied to childs.
moritz svn info src/
src: (Not a versioned resource)
Coke: no reason, and if I can trust my svn fu it's not in the repo anymore 19:38
NotFound There are already in the interpreter other things implemented the same way.
Coke k.
pmichaud yes, I suggest keeping a languages/perl6 around for a while.
nopaste "rurban" at 212.183.53.47 pasted "untested tt238-install-devel.patch (critical for pmichaud)" (134 lines) at nopaste.snit.ch/15572
pmichaud there are quite a few blog postings and presentation slides that reference it.
Infinoid NotFound: "Moving the charsets to the interpreter structure is the wrong fix." -- Allison's latest comment to TT #276 19:39
NotFound: [11:29] <@chromatic> It'd be nice to slim down the interpreter.
NotFound: So now I'm searching for a way to do it without putting them in the interpreter
PerlJam pm: with it frozen in time or updated?
19:39 Tene_ joined
pmichaud PerlJam: with it as a reference to Rakudo's new home, as is the case now. 19:39
NotFound You can put the in the envirionment, for example X-)
PerlJam ah, okay.
Infinoid If we use the same lookup functions that your patch uses, but those lookup functions just pull the pointers from a structure declared locally to the source file the lookup functions are in, it will never have to be copied, and won't clutter up PARROT_INTERP 19:40
pmichaud afk: lunch, kids
Infinoid does that sound ok?
nopaste "rurban" at 212.183.53.47 pasted "mingw shared blib patch (fixes tt#276)" (84 lines) at nopaste.snit.ch/15573
Infinoid In fact, it could just search through all_charsets directly. If you're concerned about performance, then you can cache the result locally for next time 19:41
NotFound Infinoid: and how do they locate that file local structure, other than using the interpreter?
Infinoid NotFound: what do you mean by "they"? The callers? They call the lookup function.
Coke moritz++
dalek rrot: r36555 | coke++ | trunk:
don't bother ignoring files in this dir anymore.
Coke concerned about performance???!? parrot? 19:42
Infinoid Coke: I know, it's a big if.
NotFound Infinoid: do you mean a pure global function, without an interp argument?
allison pmichaud: looks like languages/perl6 directory needs its svn:ignore properties fixed, now that most parts have been removed
Coke allison: I just fixed that.
r36555
rurban msg particle rurban at 212.183.53.47 pasted "mingw shared blib patch (fixes tt#276)" (84 lines) at nopaste.snit.ch/15573 19:43
purl Message for particle stored.
Infinoid NotFound: yes. If charsets shouldn't live in the interp, than that's the design implied by it
NotFound Infinoid: that may work
Infinoid they are necessarily standalone 19:44
NotFound Not sure I like it, but avoids the problems with global data pointers.
Infinoid Can we live with the current situation until the new implementation arrives? If not, we can do something like what we just talked about, so linking still works 19:46
NotFound rurban says that point is important for windows work
rurban I just have the important nopaste.snit.ch/15573 patch pending. Thsi also fixes this bug 19:47
It needs not to be seperate I think. Tests pass with this patch 19:48
But it's a bigger change so I have to think about it.
Infinoid rurban: So the global variables themselves aren't blocking you? Ok, might not be worth spending much more effort on them then 19:49
NotFound Anyway I'm too tired today to think with enough clarity.
Infinoid sorry, NotFound. I tend to ask lots of questions in order to try to understand a design :) 19:50
rurban I'm not sure
I have to test static also
it's just that, if I remove static completely it works okay. 19:51
NotFound rurban: the problem was that your build resulted in linking both the static and the dymanic versions of parrotlib in the same executable? 19:52
rurban almost. the dynpmc build linked to shared, parrot to static
something like that
and the 2nd stipic ptr error was because I didn#t update static anymore 19:53
kj might confirm it.
I'm trying on msvc also now
NotFound Maybe the only sane solution to that problem is that dynpmc links at execution time the required symbols. 19:55
whiteknight allison: I just updated kill_pccinvoke to trunk, I couldn't build it earlier because of that IO buffering problem from last night 19:58
it was r36556, dalek doesn't seem to want to show it 19:59
allison whiteknight: are you on a 64-bit box? 20:00
whiteknight yeah 20:01
allison okay, good to get those fixes in
whiteknight you working on that branch right now? Can I be set loose on it today?
Coke wonders if anything /really/ needs pmc.num 20:05
chromatic Bytecode, perhaps. 20:06
whiteknight I feel like the PBC header should include a list of PMC names and their corresponding number 20:07
Coke we need pmc numbers, but at the moment, do we fix numbers that aren't in pmc.num? it doesn't look like it. 20:08
that seems like a bytecode portability risk. 20:09
seems like we should determine the order for everything and stick with it.
rurban We require the very same version anyway, so we should also assume the same pmc order 20:10
Coke at the very least, I think we can skip pmcs that don't exist. =-)
rurban user-overriden pmc's will break pbc compat only
whiteknight: yesterday I started working on bignum.pmc 20:13
whiteknight rurban++ I threw it together out of boredom, and suddenly have no time to play with it! 20:14
rurban nopaste.snit.ch/15559
I assume you just copy&paste it from bigint. because a lot is not useful for bignum
20:14 Casan joined
rurban there are several totally unneeded bignum methods, probably copy & paste from bigint, like shl, shr, mod, fdiv 20:14
I tried to accept bigint PMC's for bignum methods, but doesn't look easy. 20:15
In fact I failed to derive from bigint.h
whiteknight yeah, it was the bigint.pmc file, with a few regexes. like s/BIGINT/BIGNUM/, etc 20:16
Coke allison: is there any reason to allow people to specify which PMCs to build parrot with? or are just going to assume that they always get the core set?
rurban Ok, I'll continue fixing it then. I have some lisp experience with bignums :) 20:17
20:18 bacek joined
whiteknight thanks! I hope that it shouldn't be too much work, especially since most of the gmp function names are the same, except for the s/mpz/mpf/ prefixes 20:18
rurban exactly
whiteknight after that, it's just making sure the behavior is sane for the type
rurban I attach it to TT #280 20:19
It would be fine to have a bignum method to accept a bigint pmc. bignum_div(bigint,bigint) and such 20:20
whiteknight allison: What's the first task in this kill_pccinvoke branch? I assume s/Parrot_PCCINVOKE/Parrot_pcc_invoke_method_from_c_args/? 20:21
or is it just a generalized "fix the damned calling conventions" branch?
GeJ Good morning everyone 20:23
whiteknight good morning GeJ
rurban msvc passed with just the 3 remaining -0.0 failures 20:26
masak hej, GeJ 20:27
Coke oh, hey, the PBC tests are failing on darwin/x86. 20:28
rurban I just re-enabled them
Coke re-upping and retesting. 20:29
rurban Is there a internal freeze/thaw problem?
Coke iunno.
chromatic was mentioning yesterday, and I am beginning to agree, that we probably don't want to have the failing tests in trunk.
rurban I enabled them and made TODO's out of all tests. Only proper releases are guaranteed to pass these tests 20:30
With prove t/native_pbc all should pass. With perl t/native_pbc/integer.t you will see lots of errors 20:31
but you can do tools/dev/mk_native_pbc to update you platform pbc's now to be able to submit them for your platform 20:32
oops, I see. sorry 20:35
coke_afk ok. with a clean update, they pass. 20:37
rurban everything ok
with tools/dev/mk_native_pbc --noconf you can easily update your darwin/ppc _3.pbc files and submit it 20:38
allison Coke: yes, there's no need to select which core PMCs to build with 20:42
20:42 alinbsp joined
allison Whiteknight: no, it's more about ripping out the low-level invocation stuff. I have a large commit about to land on that branch 20:43
whiteknight okay, I'll wait for that then. I wont worry about switching out Parrot_PCCINVOKE yet (which is good, since I'm still running into a few problems with that 20:45
a few functions still complaiing about the "i" adverb modifier, etc 20:46
allison Whiteknight: yes, probably best if we keep it a one-person branch for now
Whiteknight: to avoid conflicting changes
whiteknight allison: that's fine. Maybe I'll start a second branch to do different things 20:47
allison Whiteknight: yeah, that's a good idea. What I'm doing doesn't touch on the old refactors. 20:52
Whiteknight: I'm specifically addressing the speed issues 20:53
whiteknight Okay, I'll work on the second priority then: unifiying the various conventions
actually, I shouldn't create a second branch here yet until you merge in some of your changes 20:55
the infrastructure has changed pretty good, and is going to create a huge number of conflicts if I do
masak tt? 20:57
purl i guess tt is (: Template Toolkit) or Trac Ticket
masak where's Trac?
purl Trac is probably a web-based software project management and bug/issue tracking system emphasizing ease of use and low ceremony. It provides an interface to the Subversion revision control systems, integrated Wiki and convenient report facilities. projects.edgewall.com/trac/ or Python, SQLite and ClearSilver or killing killtrac or a bug-tracking tool or at trac.parrot.org/parrot/
Infinoid killtrac? 20:58
purl i guess killtrac is a perl replacement for trac that integrates RT, subversion, and MojoMojo (and CPAN Testers, and AnnoCPAN, and ...)
Util_away Tickets at trac.parrot.org/parrot/report
Infinoid ooh 20:59
dalek kudo: 196ea50 | (Moritz Lenz)++ | build/Makefile.in:
quote URL in Makefile.in and use single slashes
 21:00
shorten dalek's url is at xrl.us/befrpe
allison Whiteknight: the branch is safe to merge right now, if you want 21:01
Whiteknight: I haven't committed any of the risky changes yet, just cleanups
whiteknight I have to head home now, could you merge it now? 21:02
rurban whiteknight: bignum.pmc works now. I've added a few more needed functions.
allison Whiteknight: I'm about to change locations, but can merge it in about an hour
whiteknight allison: I'll wait till tomorrowish then. Don't worry about it 21:03
rurban: Excellent! now we just need to add some tests and start integrating it into the core
rurban I'll look at the API first. It needs to be sound. 21:04
whiteknight true
okay, I'm heading home. talk to you people later
allison moving across town 21:05
dalek kudo: f202f7f | jnthn++ | Configure.pl:
Get Configure to work on Win32. open seems not to return false if $exe doesn't exist, this works around it somewhat. Cleaner solutions welcome, but this works.
 21:15
shorten dalek's url is at xrl.us/befrtc
moritz seen petdance 21:17
purl petdance was last seen on #parrot 3 days, 16 hours, 44 minutes and 39 seconds ago, saying: and by "good" I mean "preferably embarrassing" [Feb 7 04:32:57 2009]
rurban jonathan: .exe is also a parrot config entry 21:22
I see, you need to find parrot_config to get at that. 21:23
jonathan rurban: Aye.
Well, just want something that lets me get on with Rakudo hacking for now. :-)
It wasn't possible to do Configure.pl on Win32 before this. 21:24
If you have any better fixes, patch/fix them, if you get chance! :-)
rurban well $^O eq 'MSWin32' gives you that also. cygwin needs no .exe suffix
jonathan oh, argh, I didn't mean to commit that .exe suffix.
rurban++ # well spotted 21:26
dalek kudo: 50e135b | jnthn++ | Configure.pl:
Oops, didn't mean to hard-code an unrequired .exe suffix, was just from trying to hunt down the problem. Works fine without it.
 21:27
shorten dalek's url is at xrl.us/befrz3
dalek kudo: 58d5f2c | (Moritz Lenz)++ | Configure.pl:
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/befr2m
21:29 Andy joined
pmichaud (git checkout based on date): no, I did a normal 'git clone'; no --depth option. 21:42
'git clone git@github.com:rakudo/rakudo.git rak2' 21:43
dalek kudo: e73c958 | (Moritz Lenz)++ | CREDITS:
updated my CREDITS entry; removed svn $Id$
shorten dalek's url is at xrl.us/befr79
21:55 toddr joined, toddr left 22:03 Whiteknight joined
chromatic Coke, is TT #5 still reproducable? 22:10
Infinoid pmichaud: ok, I can see the same problem in a fresh clone; git checkout -l doesn't seem to do what it's supposed to 22:14
oh, I see. that branch@{ref} stuff is based on reflog, not commitlog. hmm 22:25
chromatic How is r35149 a fix? 22:26
Infinoid so master@{yesterday} means "the version I was playing with yesterday", not "the version master was at yesterday" 22:27
22:45 rurban_ joined
dalek rrot: r36557 | cotto++ | trunk:
[gc] fix final references to "dod" and the now nonexistent docs/dev/dod.pod
 22:46
22:47 alvar joined
cotto now to tackle "DOD" 22:54
moritz department of defense? ;-)
szbalint dangers of drinking
Infinoid Donuts On Demand 22:55
chromatic Donut Order Detection 22:56
moritz doughnuts of desaster 22:57
szbalint DOD Ought Dereference
chromatic DOD of Recursing Daemons 22:58
Infinoid devil's own doggy
deathtrap of despair 22:59
dalek rrot: r36558 | rurban++ | trunk/config/init/hints/solaris.pm:
Fix #309: use CC instead of cc to link c++ libs such as icu.
 23:00
23:00 Whiteknight joined
dalek rrot: r36559 | cotto++ | trunk/examples:
[gc] remove or replace references to DOD
 23:01
cotto DOD Object Detection
Whiteknight cotto++ that's been on my todo list for a pretty long time
cotto it's boring, but also good for lots of karma (especially if I do one change per commit, but someone might say something in that case) 23:02
pmichaud Infinoid: so, no shortcut way to get the version of the repo as of a certain date (short of inspecting logs and determining commit numbers from that)?
Infinoid you never know. if you commit 10 changes at once, dalek might drop half of them
cotto I also might finally get a palindromic revision number. 23:03
Infinoid pmichaud: if your checkout was around at the time in question, master@{iso8601 date} or master@{N days ago} will work. otherwise, I couldn't find a way in my quick search 23:04
reflogs are a bit weird, I need to research that stuff more.
pmichaud Infinoid: okay, that's what I suspected.
so, it's back to writing my "long way around" script to handle it then :-)
not hard, just another task.
afk for a while. 23:05
Infinoid the git-rev-parse manpage has a description of the stuff you can validly fill in instead of a revision, I learned some stuff from that.
e.g. git show ':/[perl6] Fix breakages'
moritz I've seen this suggested on a list: 23:06
git checkout $(git rev-list -n1 --before="Mon Dec 31 2007 23:59:59")
however it doesn't work here, because rev-list needs a commit identifier 23:07
Infinoid that might be the basis for a decent script though
moritz git rev-list -n1 --before="Feb 08 2009 23:59:59" HEAD
Infinoid yeah, that works, ± some GMT conversion stuff 23:08
moritz it also works with --before=2009-02-08 23:09
cotto can someone with pre-r36559 and a fast machine tell me if t/benchmark/benchmark.t passes? 23:12
(or a good memory)
chromatic It did as of r36556. 23:13
Let me try it there.
23:13 kid51 joined
cotto of course, smolder 23:13
smolder? 23:14
purl smolder is sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or smolder.plusthree.com/app/public_pr..._reports/8
chromatic examples/benchmarks/array_access.pir fails, but I fixed that a while ago. 23:16
Maybe I didn't check it in. 23:17
23:19 bkuhn joined
cotto I'm seeing failures there. 23:19
I'm running that test, but it's slooooow.
chromatic Try this checkin. 23:20
dalek rrot: r36560 | chromatic++ | trunk/t/benchmark/benchmarks.t:
[t] Removed IntList from array access benchmark results.
 23:21
cotto I'm more concerned that the DOD->GC changes broke something (unlikely as it is)
cotto Lots of PARROT_API functions have "DOD" in their names. Should I barge ahead and change them all, or should the go through the deprecation cycle? 23:27
chromatic I'm surprised they have PARROT_EXPORT on them.
Can you post a list to the list? 23:28
Whiteknight What would people say about the addition of a readline_p opcode, in addition to the current readline_p_p?
moritz benchmarks.t: all but test 4 passes here (r36556) 23:29
Whiteknight all the other io opcodes have variants that read/write the standard streams
23:30 wolverian joined
dalek rrot: r36561 | jkeenan++ | branches/update_pod:
Create branch for updating POD per trac.parrot.org/parrot/ticket/292.
 23:31
chromatic moritz, is test 4 the array_access test?
kid51 cotto: Are you looking at the RT re DOD?
moritz chromatic: yes
Infinoid That one failed here too. 23:32
cotto: if that's the only failure you see, you're probably safe
chromatic Okay, then 36560 fixed it. 23:33
wolverian hi, are there up-to-date .debs for debian and/or ubuntu of parrot and rakudo? I remember reading about someone looking into that, I think.
cotto kid51, yes
kid51 cotto: thanks 23:34
moritz wolverian: allison did
wolverian moritz: have an url? :)
s/an/a/ 23:35
moritz wolverian: not of any results
wolverian: although ports/debian looks promisinig 23:36
wolverian hm, thanks.
cotto should function names with "gc" have those letters capitalized? Some do, but it's ugly and I could lc them while I'm mucking around there anyway. 23:38
Infinoid jonathan: someone on parrot-dev just mentioned having a build failure on mingw due to not finding parrot_config. did you mention seeing/fixing that recently?
chromatic lc lc lc 23:40
Infinoid cotto: even though its an acronym, Parrot_gc_ seems like a good prefix for that stuff to me.
cotto good enough for me 23:41
jonathan Infinoid: I think I just replied to that one? 23:42
But basically, I had to make parrot_config myself to get it to work... 23:43
Infinoid great, hasn't come through here yet
jonathan It wouldn't entirely surprise me if there are some other issues.
23:47 mikehh joined 23:48 TiMBuS joined
Whiteknight cotto: Parrot_gc_* is what it should be 23:50
dalek rrot: r36562 | whiteknight++ | branches/vtable_morph_change/src/pmc:
[vtable_morph_change] fixed the errors in t/pmc/complex.t, but three more errors magically appeared
 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!