www.parrot.org | Improve test coverage for FixedPMCArray and NameSpace / Fix Segfaults for Coke / Port Tests to PIR / Merge Stable Branches for 1.6 SOON
Set by moderator on 1 September 2009.
bacek_at_work hi again 00:00
Whiteknight adding a VTABLE_depends_on() that returns a PMC dependency would go a long way towards providing this functionality
purl oh, you're back!
chromatic I don't want another vtable for this.
It seems like the wrong place.
Whiteknight yeah, that relationship is probably backwards anyway
darbelo Whiteknight: That would be rather hard for the implementor to actually know in advance. 00:01
Whiteknight we don't need to know what a PMC depends on, we need to know what is depended on by it
So for instance we need to know that the library PMC is depended on by the dynpmc it implents
or that the Scheduler is depended on by various tasks and timers
chromatic I don't trust dynpmc writers to know that they have to depend on the Library PMC, especially as that's an implementation detail. 00:02
Whiteknight right, that's something we could set in dynpmc load
chromatic: but if their dynpmc was causing segfaults, they would figure it out and do whatever they needed to do 00:03
chromatic Why should we make them figure it out when we *know* what the problem is now and can fix it for them without causing that pain? 00:04
Whiteknight we can fix this instance, yes. But this isn't the only order-of-destruction problem we have 00:05
the specific solution is a good interim fix, but a general order-of-destruction fix is ultimately needed 00:06
chromatic Yes, that's what I'm talking about.
darbelo Whiteknight: Exposing things to pmc writer to gc internals means that they'll subject to the deprecation policy. A 6-month wait for a gc bugfix is too damm long.
Whiteknight We need an API where we can specify a dependence relation 00:09
no interaction with GC internals whatsoever
chromatic I can't think of any cases besides scheduler and dynpmc. 00:10
darbelo Whiteknight: Oh. Then I totally misread you earlier, sorry. 00:11
Whiteknight chromatic: no cases currently, or no casses possibly?
chromatic The only possible case is where destroying a PMC of a specific type relies on a PMC of another type being undestroyed. 00:12
In the scheduler case, that's where we destroy a PMC even though the interpreter still has a pointer to it.
00:13 darbelo joined
chromatic In the dynpmc case, that's where we destroy a PMC and finalize its resource (dlclose a shared library) even though other PMC vtables have pointers to some of its functions. 00:13
Whiteknight If that's true, we don't even need a general solution, just a quick fix for these two issues 00:18
chromatic I'm not sure how to make a quick fix without fixing the whole thing.
dalek tracwiki: v95 | whiteknight++ | WikiStart 00:20
tracwiki: Adding link to page about the JIT replacement effort
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
Whiteknight chromatic: I'm stumped for ideas then. How do you suggest we fix it? 00:23
chromatic We have to identify all PMCs of the appropriate types and destroy them in the appropriate order. 00:24
Coke FIND THEM AND DESTROY THEM! 00:28
nopaste "jrtayloriv" at 96.238.199.12 pasted "Programming question ..." (9 lines) at nopaste.snit.ch/17778 00:29
jrtayloriv In code like that I just pasted, is there any reason to keep 'cc' around? Why not just do 'PMC *cont = PARROT_CONTINUATION(SELF)->to_ctx->current_cont;' and skip the allocation of the local var and the assignment operation?
darbelo chromatic: But what is the appropiate order if a PMC allocated in the constatnt pool depends on thomething that isn't?
Coke msg util that's not unheard of; check out docs/spectest-progress.csv for my timings.
purl Message for util stored.
Coke (man is partcl slow)
darbelo Coke: Is it "slow all over" or does it just rely heavily on something parrot does particularly slowly ? 00:36
bacek_at_work jrtayloriv: you can do it. But any decent compiler will do it for you.
jrtayloriv bacek_at_work, ok thanks 00:37
darbelo If it makes the line longer than 72 chars, let the compiler fold it for you :) 00:38
jrtayloriv++ # kill_parrot_cont reports "All tests successful" on OpenBSD amd64
Coke darbelo: there is virtually no optimization. 00:39
and everything is runtime dispatch. there is A LOT of runtime invocation of the PIR compiler. 00:40
(but even rakudo is slow, and it's a real compiler.)
jrtayloriv darbelo, I see (about the line length) -- thank you. 00:41
Coke darbelo: hopefully the profiler will help id hot spos. 00:43
darbelo jrtayloriv: As a rule of thumb: When any decent compiler can optimize away the difference between two pieces of code, the more readable one is better. 00:44
Coke: So, it's slow all over, but some places are slower thatn the rest? 00:46
dalek tracwiki: v1 | whiteknight++ | JITRewrite 00:47
tracwiki: Initial draft
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
TT #963 created by coke++: segfault in Parrot_HashIteratorKey_get_string 00:56
nopaste "darbelo" at 200.49.154.172 pasted "[PATCH] Remove needless struct-poking from the fixedbooleanarray.pmc. All tests PASS." (25 lines) at nopaste.snit.ch/17780 01:00
darbelo Whiteknight: if you are interested I can turn the example posted at TT#956 into a test. 01:01
Also, if anyone cares to review/commit, nopaste.snit.ch/17780 is the first step in the total erradication of needless poking into STRING internals. 01:03
I'll go hunting for food now. See y'all later. 01:04
01:04 darbelo left
dukeleto food++ 01:05
jrtayloriv karma food 01:07
purl food has karma of 179
jrtayloriv that's definitely not high enough
food++
Coke msg darbelo Without profiling, who can tell? 01:09
purl Message for darbelo stored.
dalek TT #964 created by coke++: segfault in Parrot_str_new_COW 01:10
jrtayloriv How can I call one of my PMC's METHODs from one of its VTABLEs? Would I just do SELF.the_method(SELF), or something similar? 01:12
And actually, it's SUPER()'s method -- i.e. I've got a METHOD called continuation_check() in the Continuation PMC that I want to call from the init() in the RetContinuation PMC (which extends Continuation) 01:15
or rather, I want to call it from the invoke VTABLE, but that doesn't really matter, as far as the question is concerned. 01:18
Whiteknight Parrot_PCCINVOKE(interp, pmc, CONST_STRING("Method name"), "signature", ...) 01:20
(I may have mixed up the order of those arguments)
01:20 Eevee joined
Whiteknight Actually, you should probably use Parrot_pcc_invoke_method_from_c_args() instead 01:20
food++ definitely! I may go find some right now 01:22
jrtayloriv Whiteknight, thanks -- I'm currently moving Parrot_continuation_check() and Parrot_continuation_rewind_environment from sub.c into RetContinuation (since that's only place they are used) 01:23
hmm ... nm -- used in a few other places as well, but still doesn't belong in sub.c I think ... 01:24
belongs in Continuation actually -- brain fart 01:25
dalek TT #965 created by coke++: segfault in Parrot_convert_arg 01:26
01:29 kid51 joined
kid51 msg wayland76 trac.parrot.org/parrot/ticket/509#comment:16 01:32
purl Message for wayland76 stored.
kid51 seen infinoid?
purl infinoid was last seen on #parrot 8 days, 21 hours, 25 minutes and 16 seconds ago, saying: hmm, I seem to have forgotten to go to bed. night [Aug 24 04:00:35 2009]
dalek TT #966 created by coke++: segfault in Parrot_string_mark 01:33
TT #967 created by coke++: segfault in utf8_set_position 01:40
rtcl: r664 | coke++ | wiki/SpecTestStatus.wiki:
Edited wiki page through web user interface.
 01:43
TT #773 closed by coke++: Can't override vtables of a PMC from PIR 01:47
01:57 dukeleto joined
dalek TT #831 closed by coke++: segfault in clone_key_arg 01:57
02:07 payload joined 02:22 rhr joined
jrtayloriv Two questions: (1) What am I doing wrong here? ---> Parrot_pcc_invoke_method_from_c_args(interp, SELF, CONST_STRING(interp, "continuation_check"), CONST_STRING(interp, "v")); <--- I am trying to invoke a METHOD of the PMC from it's invoke() VTABLE, and the method does not return anything or take any arguments? 02:26
and (2) Why can't I put this ridiculously long function call on multiple lines without getting an error about CONST_STRING being on multiple lines?
Oops -- I shouldn't be declaring this as a method anyway, since it is only used internally. 02:38
pmichaud CONST_STRING requires that the statement be all on one line, I think. 02:39
02:42 janus joined
jrtayloriv pmichaud, I had each of the CONST_STRING(interp, "string") on their own line -- I didn't split up either of them over multiple lines. That is, I had CONST_STRING(interp, "string_1") on one line, and CONST_STRING(interp, "string_2") on another ... oh well, doesn't matter right now -- I realized that I was supposed to be putting these functions in the "Functions" section, rather than trying to make them into methods. 02:43
bacek_at_work jrtayloriv: don't try to put them as methods in Continuation anyway. Chicken and Egg problem 02:44
jrtayloriv bacek_at_work, I was going to put them as Functions in the Continuation PMC 02:45
pmichaud jrtayloriv: CONST_STRING requires that the *statement* be all one line, not just the CONST_STRING part
jrtayloriv bacek_at_work, that would work, right?
pmichaud, OK thank you.
bacek_at_work jrtayloriv: probably no. But I don't quite understand what are you trying to achieve. 02:48
jrtayloriv bacek_at_work, I'm trying to move the Parrot_continuation_check() function out of sub.c and into the Continuation PMC. Because the only place that the function is used is inside of the Continuation PMC and the PMCs that extend it. 02:49
bacek_at_work jrtayloriv: ah. ok. Just move it into beginning of continuation.pmc before 'pmclass Continuation' 02:50
But it will not be visible in inherited PMCs.
jrtayloriv bacek_at_work, I need it visible in the inherited PMCs, or I will have to duplicate the logic in each of them. 02:52
bacek_at_work, And you are saying that I cannot declare it as a method in Continuation PMC to accomplish this?
bacek_at_work then just keep in sub.c
jrtayloriv bacek_at_work, OK.
bacek_at_work yes, because calling of methods require new continuations. 02:53
jrtayloriv oh, I see.
treed kinda OT, but I figure this is a good place to ask: I'll need to learn Perl (5) for my new job (assuming that it all comes through); best book or whatever for that? 03:14
jrtayloriv treed, Do you know Perl at all? How much, if so? 03:17
treed Very, very little. 03:18
jrtayloriv Learning Perl and Intermediate Perl are great for starters.
treed And what I do know has been slightly tainted by my exposure to Perl 6.
03:20 donaldh joined
jdv79 treed: maybe just put another target in your rakefile to upload the report file? 03:23
treed: smolder.plusthree.com/app/public_pr...reports/16
i just pushed the first report
03:28 theory joined
jdv79 what's goin on with the svn server's cert? 03:31
treed jdv79: What's the upload like, just an HTTP PUT? 03:33
jdv79 just a post
treed To what URL? Is there a doc for this stuff? 03:34
jdv79 emulate what the form does at smolder.plusthree.com/app/public_pr..._report/16
basically post to that url with a report_file param - normal form file upload 03:35
treed k
jdv79 i don't think there's doc
Coke: partcl still isn't compiling here:( 03:37
04:10 cotto joined
cotto hello 04:10
purl what's up, cotto.
04:13 dukeleto joined 04:15 kyle_l5l joined 04:40 beta left
dalek TT #968 created by jrtayloriv++: Rename PObj_active_destroy_foo to PObj_custom_destroy_foo 04:50
jdv79 Coke: i'd like to get partcl into smolder. but that kinda means it needs to compile:) 04:58
05:06 snarkyboojum joined
dukeleto 'ello 05:07
05:09 slavorgn joined 05:14 theory joined
kyle_l5l If I add a printf() call inside hash.c's hash_freeze(), I get a failed assertion before hash_freeze() is ever called. Is this expected? 05:54
06:07 chromatic joined
cotto I've had interesting experiences putting printfs in certain places. 06:07
gdb might be a better bet if you want to poke around
test coverage? 06:08
purl test coverage is probably cv.perl6.cz
kyle_l5l It seems to be doing strange things to the visit_info struct that is passed around, making the visit_info->io->bufused go below zero. 06:17
cotto That code is special and ripe for replacing. 06:18
chromatic Oh, freeze and thaw. That's special indeed. 06:20
cotto You can figure it out if you really want to, but there's a cost. 06:22
kyle_l5l heh. I've been trying to figure it out...but it's, hm, yeah, special. 06:25
dalek kudo: 30ffa60 | mberends++ | tools/test_summary.pl:
[tools/test_summary.pl] add hints to change "plan *;" to "plan $number;"
 06:27
kudo: c6d5941 | mberends++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
cotto If you want something simpler, more tests for the FixedPMCArray and Namespace PMCs would be a good place to start.
06:33 bacek joined
cotto hio, bacek 06:35
bacek hi cotto, howizgoin'
treed Hm. 06:54
Need to figure out how to relate the failure of test files to compile to smolder.
bacek treed: (lineof in String) looks like a bug in PCT. 06:59
treed: it create String instead of CodeString 07:01
treed nods. 07:05
07:15 skv_ joined
dalek rdinal: 870ad48 | treed++ | Rakefile:
Add a smolder target to the Rakefile to submit report.tar.gz to the appropriate website.
 07:20
rdinal: 7d77922 | treed++ | Rakefile:
Refactor the Rakefile a little.
07:21 donaldh joined
dalek rrot: r40918 | mikehh++ | trunk/src/pmc/string.pmc:
fix codetest failure - no trailing spaces
 07:33
mikehh messages
kyle_l5l ack, isn't limited to just hash.c, happens in all sorts of neat places. 07:36
mikehh need to reboot - still can't get VirtualBox to work with wireless connection :-{ (or kvm for that matter) - bbl 07:39
07:47 iblechbot joined
cotto chromatic, ping 08:10
08:10 mberends joined
chromatic pong 08:10
cotto I'm still working on making the postprocessing script not be unmaintainable, but would you have time to look over the C part of the code if I committed it now? 08:12
chromatic Yes, I should have plenty of time tomorrow and Thursday. 08:13
cotto ok
there 08:16
dalek rrot: r40919 | cotto++ | branches/pluggable_runcore (2 files):
[profiling] update runcore to what's likely to be the format pprof2cg can use
 08:17
08:21 HG` joined
moritz can we ship parrot with LGPL licensed code? 08:37
both libjit and gnu lightning are LGPLed
chromatic Allison's against it. 08:39
moritz but linking against LGPL code is fine? 08:41
chromatic She doesn't want any core components under a non-artistic license, as best I understand it. 08:43
moritz then we just declare the JIT system non-core :-)
08:44 MoC joined
chromatic Based on her comments earlier, I suspect she won't like us deleting the existing pseudo JIT. 08:44
... if we declare JIT non-core. 08:45
08:46 mikehh joined
mikehh on Ubuntu 9.04 i386 - anyone need any testing done on this platform? 08:47
08:53 cono joined 08:55 jsut joined 09:00 skv_ joined 09:15 cognominal joined 09:16 cognominal joined
mikehh All tests PASS - (pre/post-config, smoke, nqp_test, fulltest) at r40919 - Ubuntu 9.04 i386 (gcc) 09:20
09:35 mikehh_ joined 09:43 masak joined 09:47 mikehh joined
mikehh rakudo (c6d5941) builds on parrot r40919 - make test PASS / make spectest (up to 28165) 3 failures - Ubuntu 9.04 i386 ...(more) 09:49
rakudo - t/spec/S03-operators/arith.rakudo - Failed test: 120 - Non-zero wait status: 8 09:51
09:51 HG` joined
mikehh rakudo - t/spec/S12-attributes/class.rakudo & t/spec/S14-roles/basic.rakudo - Segmation fault on exit 09:52
09:54 gaz joined
mikehh BTW I just tried to log in to trac.parrot.org/parrot from my i386 setup and it reports the certificate still has not been renewed 10:01
10:15 rbaumer joined
mikehh partcl r664 builds on parrot r40919 - make test PASS - Ubuntu 9.04 i386 (gcc) 10:25
cardinal (7d77922) builds on parrot r40919 (rake) - rake test:all - same 3 failures - but now fails with Method 'lineof' not found for invocant of class 'String' - Ubuntu 9.04 i386 (gcc) 10:37
cardinal 3 complete failures - gen_08-class.pir, gen_alias.pir, gen_freeze.pir 10:39
join cardinal
idjut 10:40
cotto now it's time for sleeps. 10:45
10:48 bacek joined
dalek rrot: r40920 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
[profiling] initial refactor of (incomplete) postprocessing script
 10:48
mikehh decnum_dynpmcs r181 builds on parrot r40919, make test PASS - Ubuntu 9.04 i386 (gcc) 10:49
10:53 Zak joined
mikehh lua fails to build on parrot r40919 - error:imcc:make_pmc_const: no such pmc - in file 'lua.pir' line 307 - Ubuntu 9.04 i386 (gcc) 10:53
context_pmc3 branch r40920 - fails to build - jit errors - Ubuntu 9.04 i386 (g++) 11:06
context_pmc3 branch r40920 - fails to build - gets further with gcc butstill fails - Ubuntu 9.04 i386 (gcc) 11:16
context_pmc3 branch - /home/mhu/context_pmc3/blib/lib/libparrot.so: undefined reference to `CURRENT_CONTEXT_FIELD' - collect2: ld returned 1 exit status - make: *** [miniparrot] Error 1 11:18
bacek mikehh: let me check
mikehh bacek - there are loads of jit warnings in the gcc build 11:19
bacek mikehh: yeah. Looks like they all related.
Found it. Apparently ack skipped .jit files. 11:20
mikehh bacek: I have the builds logged if you need any info - gonna head back to amd64 unless you need anything on i386 11:21
11:22 donaldh joined
bacek mikehh: can you wait few minutes. I'm testing commit locally 11:23
mikehh ok - will hang around here for a bit
bacek dcommiting first chunk 11:28
mikehh: should be clear at r40924 11:30
mikehh++ # kicking lazy developers 11:31
dalek rrot: r40921 | bacek++ | branches/context_pmc3/src/jit/i386/core.jit:
[cage] Remove last references to CURRENT_CONTEXT_FIELD macros. mikehh++
rrot: r40922 | bacek++ | branches/context_pmc3/src/jit/i386/jit_defs.c:
[cage] Fix CONTEXT vs CURRENT_CONTEXT usage.
rrot: r40923 | bacek++ | branches/context_pmc3/src/jit.c:
[cage] Fix CONTEXT vs CURRENT_CONTEXT usage.
11:32 iblechbot joined
rrot: r40924 | bacek++ | branches/context_pmc3/src/jit.c:
[cage] More CONTEXT vs CURRENT_CONTEXT fixes.
mikehh bacek: ok she builds (on gcc) - make test PASS - running some other tests 11:40
bacek mikehh: thanks!
hang on. Why "she"? :) 11:41
bacek start suspecting that mikehh is Russian :) 11:42
mikehh sounds better than he :-} 11:43
bacek It's just very Russian to refer bird "she" :)
mikehh bacek: got some ancestors from there - well lithuania and latvia and my great grandmother spoke russian more than english - but not really 11:44
bacek vote to call our bird "she" from now :) 11:47
moritz thinks that 'parrot' is a more appealing name than 'she'
mikehh well she is a female parrot 11:48
cono +1 11:50
purl 1
dalek TT #969 created by flh++: Convert t/pmc/float.t to PIR 11:58
12:08 rba joined
mikehh bacek: fulltest - testj - loads of failures - seems to be in an endless loop at the moment 12:09
bacek testj == test JIT... And JIT is badly broken. 12:10
12:11 whiteknight joined
mikehh bacek: right - and src/jit/i386/jit_defs.c has c++ comments 12:16
bacek mikehh: yes. It's marker for JIT failure.
masak msg austin I'm interested in contributing to the Close project. I noticed, for example, the README refers to two files in docs/ which aren't there. I'd be happy to contribute those. 12:23
purl Message for austin stored.
bacek Good morning whiteknight
whiteknight 'moring bacek
how are you today?
12:24 payload joined
bacek whiteknight: sharpening knife to kill JIT :) 12:24
mikehh bacek - all other tests pass
whiteknight bacek: you and me both! 12:25
mikehh anyway rebooting to amd64 now - bbl
bacek mikehh: see you!
whiteknight: yeah. Only one problem. Someone have to convince allison :) 12:26
whiteknight Allison is not stubborn or difficult. I suspect she wants us to make sure we have a good replacement ready 12:27
we don't want to throw away JIT because it's inconvenient, we want to throw it away because we are replacing it with something better
bacek is very good at breaking stuff. Not fixing it :) 12:28
masak msg austin I can't seem to build Close: gist.github.com/179687
purl Message for austin stored.
whiteknight We need both kinds of people!
masak: last I heard, Close was known to be broken. Major refactors
masak oh. 12:29
in trunk? why? :)
moritz close?
purl rumour has it close is close file (or pipe or socket) handle or bad on sockets, use shutdown() instead or horseshoes or grenades or nuclear weapons or code.google.com/p/close/
masak the latter link.
purl the latter link is the right one for PEP. emailproject.perl.org
whiteknight masak: when the project only has one developer, no reason not to make big changes in trunk
masak moritz: that project excites me much.
moritz unless it has users :-)
masak whiteknight: maybe that's true for SVN. it isn't for git. :) 12:30
whiteknight It's still very early in development, I don't think it has many users yet
masak it does now.
as soon as I get it running, that is.
whiteknight oh really? who is using Close? What projects?
masak ok, so I back down a few revisions, then.
bacek masak apparently
masak whiteknight: I plan to become both a user and committer. as you said in a post, that language looks great. 12:31
much easier to write than PIR.
bacek Why not NQP? 12:32
dalek rrot: r40925 | bacek++ | trunk (2 files):
Use OrderedHash in PackfileDirectory to prevent putting debug segment first. PBCs are too fragile...
masak I guess NQP is quite nice, too. I should look into that more, as well.
12:33 mikehh joined
masak ok, Close builds fine from r96. 12:35
whiteknight I don't like people saying "why not NQP?". Parrot is all about using any language and giving the programmer choices 12:37
NQP is just fine, but some people would rather use a C-like language then a Perl-like language 12:38
and vice-versa
masak +1 12:39
purl 1
Coke "there's more than one way to do it" makes a lot less sense for parrot than it does for perl. 12:46
I'm coming in late here and haven't reviewed. =-)
masak isn't it conceivable that some problem domains fit better against something like Close than something like NQP? I think it is. 12:49
whiteknight Coke: the point is that we don't need to be creating our own "which language is better?" flamewars when we're supposed to be providing a language-agnostic VM
masak and both are often preferable to PIR.
whiteknight Close strikes me as being a little "closer to the machine" then NQP is, which is beneficial in many situations
masak 'xactly. 12:50
whiteknight Coke: if we don't need more then one way to do something, abandon partcl and start working on Rakudo instead
12:59 sri joined
whiteknight (I don't recommend you stop working on partcl, of course. I was just making a point) 13:00
dalek rrot: r40926 | bacek++ | trunk (3 files):
[pmc] Revert previous commit. Actually preserve type of unpacked segment. Add setter/getter to PackfileRawSegment.type
 13:10
Coke whiteknight: there is a difference between being agnostic about which languages we support our end users to write, and which languages are available as part of parrot. I am suggesting that the set of the latter languages be very small. 13:14
Coke now goes off and reads through the backscroll.
13:14 jrtayloriv joined
jonathan Is there a way to get pmc2c to insert stuff into the .h file it generates? 13:16
Coke msg jdv79 If partcl isn't compiling, please open a ticket a code.google.com/p/partcl/issues/list
purl Message for jdv79 stored.
jrtayloriv jonathan, what are you trying to get it to insert?
Coke (glad I checked the backsroll)
jonathan I've got an ATTR of a type from elsewhere, and I want it to include the .h file where that type is to be found.
whiteknight Coke: Oh yes, I don't recommend we add Close to the Parrot core distribution
jonathan Otherwise, the .h file breaks. 13:17
oh, actually...if I re-order the #include's in the thing including the header file it may work out a bit better...
jrtayloriv jonathan, You can just #include things in the .pmc file.
Coke anyone know what jdv79's partcl bug was? 13:18
Coke wonders if it's just a g++ thing.
jonathan oh no, sadly not...
jrtayloriv: I know but the includes aren't also in the .h file
e.g. 13:19
ATTR SV *sv;
This in the .h file generates
typedef struct Parrot_P5Scalar_attributes { SV * sv;
} Parrot_P5Scalar_attributes;
But the #include needed doesn't make it into the .h file, so it complains about the SV there.
13:21 TonyC joined 13:23 nopaste joined
jrtayloriv johnathan, Where is SV defined? 13:23
Coke partcl? 13:28
purl i heard partcl was tcl on parrot or code.google.com/p/partcl
bacek jonathan: just use explicit "struct" 13:33
"ATTR struct SV *sv" should work.
jonathan bacek: ooh
jonathan tries it
dalek rrot: r40927 | bacek++ | trunk (4 files):
[t] Add tests for PackfileSegment.type (and fix PackfileRawSegment.type implementation)
 13:34
jonathan bacek++ # thanks! :-)
Coke I'm getting tired of telling google that it's ok to post messages from google to google.
bacek karma me
purl bacek has karma of 1000
bacek Bah! Anniversary :)
Can I freeze it somehow? I like this number :) 13:35
jrtayloriv jrtayloriv, I think, if it is a struct, that you can just 'typedef struct SV SV' above the pmclass definition in your .pmc file, and include the header than has the definition for SV in the PMC file where you are declare an SV ATTR, and then it will not complain to you. For instance, 13:36
moritz bacek-- # just to encourage him to more contributions to reach 1000 again :-)
jrtayloriv s/if it is a struct/if SV is a struct/;
moritz jrtayloriv: I think you meant jonathan, not yourself :-) 13:37
jrtayloriv moritz, :)
moritz bacek++ # committing like hell
jrtayloriv jonathan, ^^
bacek moritz: :)
jonathan jrtayloriv: Thanks...and using "struct" in there works nicely. :-) 13:38
bacek moritz: I prefer to reach next level. Karma 10000 looks reasonable :)
13:40 ruoso joined
bacek Anyway, Util++ for bringing my attention to Packfile* PMCs. 13:44
Can anyone review TT#969? Patch looks good, but I don't trust myself much at this point of time... 13:46
Infinoid hmm. 13:48
trac.parrot.org uses an invalid security certificate.
The certificate expired on 08/29/2009 12:54 PM.
bacek topic?
purl i think topic is IRC topics don't auto propagate on server reconnect
bacek Ah. It was changed...
Infinoid: iirc someone already across expired certificate. 13:49
13:55 HG` joined
bacek
.oO( Did I say something disgusting?)
 14:07
bacek taking off TimToady's hat and departing to bed. 14:08
Coke Infinoid: particle is on it. 14:12
14:13 jsut_ joined 14:16 Psyche^ joined
Coke wonders why some internal parrot exceptions are showing up as CONTINUE exceptions in parrot. 14:16
(like "method not found") 14:17
any one who understands PGE operators about? 14:19
bacek Coke: because theoretically you can add method in run-time and resume from exception?
14:19 Andy joined
Coke bacek: continue is, imo, a pretty specific type of exception. 14:19
(I added the method, so now it's (mostly) doing the right thing, though.) 14:20
(PGE) trying to figure out why this doesn't parse:
$ ./tclsh -e "puts [expr 1eq4>3]"
syntax error in expression "1eq4>3": extra tokens at end of expression
(that should print out "1")
bacek Coke: LTM ftw... 14:21
Coke ok. any idea how I can shuffle code.google.com/p/partcl/source/bro...ression.pg around so that the longest tokens are matched first? 14:22
(eq only appears in the grammar as a proto infix.
bacek Coke: not now. It's Tomorrow already and I need some sleep... 14:24
But try to play with something like <!before...> in your grammar. 14:25
bacek must sleep
purl $bacek->sleep(8 * 3600);
Coke bacek: the operator table is hiding most of that from view of my grammar, so I'd have no idea where to put it. 14:26
see you tomorrow.
bacek Coke: have a good day.
bacek wave from future 14:27
14:29 einstein joined
Coke hurls code.google.com/p/partcl/issues/detail?id=100 for anyone with PGE smahts. 14:31
pmichaud oh, I think I know this one 14:51
14:52 payload joined
pmichaud actually, I think the problem might be the 'eq4' 14:53
Coke pmichaud: check out the ticket, yah.
(that's when it goes south.)
pmichaud I think that PGE's optable expects tokens ending with word characters to have a word boundary 14:54
Coke is there a way to override (like I did with the whitespace?)
(it's so nice to be able to addres actual partcl issues instead of chasing segfaults. =-) 14:55
pmichaud proto 'infix:eq' is wb(0) is precedence('08=') { ... } 14:56
the 'wb(0)' disables the check for a word boundary
14:57 kjeldahl joined
pmichaud afk for a bit 14:58
Coke pmichaud++ 15:02
whoops. apparently t/cmd_expr.t was aborting after N tests, and when last I updated the run count, I just cut it off there. haven't been running the last N tests. 15:13
(so when I tried to add a new one, the count was off.) 15:14
treed bacek_at_work: So that Code vs CodeString lineof issue. Did you want me to write a ticket for that, or did you write a ticket, or were you just going to fix it? 15:15
pmichaud Code vs CodeString issue...? 15:17
treed Cardinal's current testfailures result from some parrot code using String instead of CodeString. 15:18
(Sorry, miswrote)
So it tries to call lineof and that fails.
pmichaud okay 15:19
treed bacek determined that for me last night
Said it looks like a bug in PCT.
pmichaud I wonder what PCT could be making into a String that it then tries to call .lineof on 15:20
PCT normally only calls .lineof on things in Match objects, and those are CodeString
treed Want the backtrace?
pmichaud sure
treed One sec. 15:21
purl one sec is, like, not a long time
treed Thanks, purl.
purl bitte treed
15:22 donaldh joined
nopaste "treed" at 66.215.91.229 pasted "backtrace for pmichaud++" (17 lines) at nopaste.snit.ch/17783 15:23
pmichaud hmmm 15:24
that doesn't quite tell me why we got a String in the first place
I think what we'll do though is not generate line number information when it's not available
treed nods.
pmichaud i.e., if .lineof fails, we just ignore it
I'll work on that a second 15:25
treed Cool, thanks.
particle why is parrotcode.org still live? 15:40
there are *OLD* docs there
and sfink still has parrot 0.0.11.2 on cpan
sigh.
this all started with a google search for 'parrot vtable' 15:41
the first two links are less than helpful
oh come on! 15:42
purl EVERYBODY TO THE LIMIT!
particle i can't search for 'parrot pdd', it brings me to www.funnyfarmexotics.com/IAS/tpdd.htm
A recently recognized infectious agent is killing companion, aviary, and free-ranging birds throughout the world. At present, no birds or aviaries are known to be protected. This dreaded affliction is called Proventricular Dilatation Disease (PDD).
PDDs are killing parrot. how ironic.
pmichaud parrotcode.org should just redirect to parrot.org, yes? or is it still live because we think we might want to migrate some information across? 15:44
15:44 solarion joined
dalek rrot: r40928 | pmichaud++ | trunk/compilers/pct/src/POST/Compiler.pir:
[pct]: Compute 'lineof' information only if we can.
 15:46
pmichaud treed: see if r40928 helps
japhb whiteknight, would you mind collecting the best resource links for each JIT engine on your JITRewrite page? 15:47
whiteknight japhb: working on that already
japhb excellent
whiteknight I have a few emails out to people from Lightning and libJIT, and am hunting down links for them
treed pmichaud: Testing. 15:49
purl rumour has it testing is the best thing ever ZOMG
particle parrotcode.org should redirect, once everything has been transferred. i don't know if there's anything left worth saving there
coke: do you still have parrotcode.org admin rights?
pmichaud how can we know when "everything has transferred"?
Coke I have svn commit access, probably.
pmichaud i.e., what's our criteria for that?
Coke sighs again at the giant TIME SUCK the transfer away was. 15:50
pmichaud sunk cost, alas.
my suggestion: Let's assume for the moment that parrotcode.org doesn't have any important information. If true, we can redirect now. 15:51
If false, then something will occur at some point in which we discover we really want/need something from the old parrotcode.org. But we can always get that out of svn 15:52
japhb +1
purl 1
15:53 hercynium joined
particle pmichaud: agreed, time to set up a permanent redirect link 15:53
pmichaud (I'm presuming that parrotcode.org was combust-based and lived in a subversion repository somewhere)
particle ayep
pmichaud (and that that subversion repo is still accessible) 15:54
particle btw get_repr is listed as a deprecation candidate in pdd17
as it is the same as get_string
Coke here's the list of what's still out there:
svn.perl.org/viewvc/perl.org/docs/...arrotcode/
pmichaud (get_repr) yes, that's fine with me. All of the PMCs currently treat get_repr the same as get_string, but semantically they were to be different things 15:55
in particular, I think that get_repr should've produced a string that could recompile back into the original structure
anyway, I'm fine if get_repr dies
Coke pmichaud++ # 16 more passing tcl spec tests. 15:56
pmichaud anyway, yes, it looks as though any information we might want/need from the old parrotcode site is in svn
it might be worth squirreling away an export of that subdir in case it gets admin'ed out
particle we could copy the repo to svn.parrot.org 15:57
pmichaud we can do that also, yes.
Coke if we copy it, then we have one more half dead thign to maintain.
particle uh, no
we can move the parrotcode repo to parrot.org 15:58
pmichaud for archival, not for maintenance
particle right.
Coke I don't see the point.
pmichaud you don't see value in having archived versions of old stuff?
particle redirect parrotcode to parrot as a 301
Coke not that old, no.
pmichaud hmmm. why do we keep tagged versions of Parrot 0.0.8 around, then? 15:59
Coke excellent qustion.
particle tags are cheap. move along.
pmichaud anyway, I think it's worthwhile and relatively cheap.
Coke <shrug> if someone wants to go through the trouble, by all means.
15:59 HG` joined
particle maybe someone wants to fork an old release of parrot 16:00
Coke I'm more concerned about our current website. particle, any progress? 16:01
particle no progress
i need to generate a csr
treed pmichaud: New error now, same place.
Method 'iterator' not found for invocant of class 'String'
particle hoping to get in touch with osuosl now to get access to the box
pmichaud treed: that's almost certainly an error with Cardinal, then 16:02
it's putting a String somewhere that PCT expects a PAST::Node
treed Huh. 16:03
We didn't change anything.
pmichaud perhaps you can bisect to find out when things broke?
treed Tried that before.
It was at some parrot revision.
pmichaud what revision?
purl revision is 0, unless it's an svn co, then it's whatever svn reports
pmichaud right
treed sec'
15:57 < mikehh> I bisected the problems to r40799 - a lot of fixes since then and when I tested cardinal at r40824 it started getting those get_pmc_keyed() not implemented in class 'String' failures 16:04
16:04 theory joined
treed I assume that means that he bisected all the way back to 40799, and found that the problem manifested at r40824 16:04
pmichaud well, nothing significant changed in pct in that period of time either 16:05
treed Hm.
treed looks at the PAST.
pmichaud have you tried running with the -G option ?
dalek rtcl: r665 | coke++ | trunk/docs/spectest- (2 files):
Update spec test progress (NotFound++ for fixing most of our segfaults)
 16:07
rtcl: r666 | coke++ | trunk/ (4 files):
Allow conversion of ints to lists (+add test).
rtcl: r667 | coke++ | trunk/t/cmd_expr.t:
Fixup this test file;

now that we're running them, fix up bugs in the tests.
rtcl: r668 | coke++ | trunk/ (2 files):
Don't require whitespace after an alpha operator. (pmichaud++)
treed No, what does -G do? 16:08
Turn off GC pops out at me. 16:09
pmichaud turns off garbage collection
sometimes that causes strange errors to disappear
whenever I have types mysteriously changing and it looks like "I didn't change anything", I try -G just to see what happens.
treed Where does -G go? Seems like I can't pass it to cardinal. 16:13
(tries to open it as a file) 16:14
treed runs parrot directly.
Nah, same issue.
pmichaud okay
treed And I can't find anything in that PAST output where anything but a PAST node is occupying a spot in the true.
pmichaud I don't have much idea what might've caused the problem
treed (The really interesting thing here is that --target=past isn't bailing out) 16:15
pmichaud right, the problem is happening when it's converting POST to PIR
treed So is the error occuring after the PAST is generated?
Hm.
pmichaud it could also be in converting PAST to POST 16:16
try --target=post
treed Completes fine.
pmichaud what line is giving the "Method 'iterator'" exception? 16:17
treed current instr.: 'parrot;POST;Compiler;pir_children' pc 9669 (src/POST/Compiler.pir:77)
pmichaud okay
I've had a server fail here -- I have to deal with it first.
treed nods. 16:18
jrtayloriv particle, Maybe something like this could solve the issue with diseased birds -- parrotsearch.bbbot.net/. Should I further refine it, or you think it won't be useful? 16:28
particle jrtayloriv: parrot.org already has a custom search engine (right side, below calendar). if you can refine or improve that, it would be great 16:30
jrtayloriv particle, Ahhh .. I always just assumed that was just an in-site search. Very good then :)
particle i don't know the details, only that it exists 16:31
i don't think i've ever used it, as google rarely fails me :)
jrtayloriv particle, yes -- you can do it all w/ google, it would just be nice to have something that saves all of the inurl:s and quoting and whatnot. 16:33
anyhow, thanks for pointing me to that.
particle thank you for your enthusiasm and your contributions.
jrtayloriv thanks :) -- I'm enjoying it -- the people here are all very pleasant to work with. 16:35
16:35 mokurai joined
dalek kudo: 47a6ae6 | (Solomon Foster)++ | src/setting/Rat.pm:
Add Rat.prefix<->.
 16:36
17:07 cotto joined
cotto good hello 17:10
dalek tracwiki: v2 | whiteknight++ | JITRewrite 17:16
tracwiki: Add inforation I've gathered about Lightning
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
tracwiki: v3 | whiteknight++ | JITRewrite
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
17:17 chromatic joined
dalek tracwiki: v4 | whiteknight++ | JITRewrite 17:33
tracwiki: Add info about libJIT that I heard from some of their developers.
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
17:35 hercynium joined
dalek kudo: c9a9300 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 435 files, 13245 pass, 0 fail
 17:37
tracwiki: v5 | whiteknight++ | JITRewrite
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
tracwiki: v6 | whiteknight++ | JITRewrite
tracwiki: + small con about libJIT 17:38
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
chromatic Almost 700 tests yesterday. 17:39
Good for the Rats.
einstein small notification: the certificate of trac.parrot.org has expired 17:44
17:45 darbelo joined
moderator HTTPS CERT EXPIRED | www.parrot.org | Improve test coverage for FixedPMCArray and NameSpace / Fix Segfaults for Coke / Port Tests to PIR / Merge Stable Branches for 1.6 SOON 17:50
Coke einstein: danke, it's in progress. 17:50
... So I get 16 more spec tests passing for expr - this somehow cauess format to die with a recursion error, losing me 181 tests. 17:51
17:53 joeri joined
einstein ok 17:56
PacoLinux new platform, I have compiled parrot in haiku without problems : smolder.plusthree.com/app/public_pr...ails/26789 18:15
Coke 16 - 181 -
16 - 181 - 8
purl -173
Coke excellent! 18:16
purl EGG-see-lent!
PacoLinux tree months ago was impossible
Coke PacoLinux: can we get a patch for PLATFORMS ?
PacoLinux Coke: sure
darbelo PacoLinux: What filesystem is your parrot checkout on? 18:24
jrtayloriv chromatic, I'm reading whiteknight's blog and trying to understand one of the discussions you were having with him regarding L1. When you said "we need an L1 emitter for PCT", were you saying there should be the ability to convert from PAST to L1, instead of from PAST to PIR?
whiteknight It's entirely possible that my blog has misquoted chromatic on occasin 18:25
PacoLinux darbelo: I think is named BFS
jrtayloriv whiteknight, I got it from a IRC log that you linked to from your blog.
whiteknight oh, okay then.
chromatic jrtayloriv, that's exactly what I meant. 18:26
jrtayloriv chromatic, ok thanks
PacoLinux darbelo: en.wikipedia.org/wiki/Be_File_System
whiteknight jrtayloriv: the idea is that PASM ops will themselves be written in Lorito (Lorito == L1)
darbelo PacoLinux: does it suport hard links?
PacoLinux darbelo: I dont know, Im new in haiku 18:27
18:30 jan joined
jrtayloriv whiteknight, ok -- has any work been done to sketch out what lorito would look like? I can't seem to find anything via google. 18:32
whiteknight not a whole lot, no
some people were suggesting that it look like the smalltalk bytecode
any kind of very-low-level LIR should be fine
a small codeset is preferred, but I don't think we need to aim for any kind of crazy minimum 18:33
18:35 rbaumer joined
chromatic I think we can get away with 128 ops or fewer. 18:37
mikehh treed ping 18:38
Coke chromatic: would it be possible to implement this in stages, so we don't need all N lorito ops working at once? 18:41
18:41 rbaumer joined
treed mikehh: pong 18:42
chromatic Possibly. I can think of two: those that can call C functions and those that don't. 18:43
mikehh treed - in cardinal 18:48
treed Yeah, replied.
pmichaud: There was a mistake before, the actual parrot commit wherein the issue started is r40788 18:54
jrtayloriv whiteknight, sorry, I got distracted for a minute ... has the nanojit LIR been looked at yet? Why the smalltalk bytecode over anything else? 18:55
Coke yays as he finds the bug that caused the regressions. 18:56
chromatic Squeak's slang comes up because they did it well. 18:59
PacoLinux darbelo: I can't find anything about hardlinks (but maybe I dont know where to look) : www.haiku-os.org/legacy-docs/bebook...rview.html 19:05
darbelo PacoLinux: From what I can see, BFS doesn't have them, which is the reason behind some failing tests in your smolder report, you might have to TODO them. 19:07
PacoLinux darbelo: just found : Currently, the BeOS does not recognize hard links (although it will in the future). A hard link associates an entry in the hierarchy with a specific chunk of data (a node). The attraction of hard links is that more than one entry can be associated with the same node. 19:08
19:09 cotto joined
darbelo PacoLinux: The test is trying to create a hard link, you'll have to TODO it for BeOS/Haiku if they don't support that. 19:11
19:21 donaldh joined
jrtayloriv So ultimately, the goal is to have something like HLL->PAST->Lorito->whatever-the-best-JIT-engine-they-have-installed-is, correct? (where "whatever-the-best-JIT-engine-they-have-installed-is" any of LLVM/libJIT/Nanojit/GNULighting/roll-our-own depending on what the user has available on their system) ... Am I understanding this properly? 19:23
darbelo ls 19:25
chromatic Yes. 19:26
darbelo Sorry, wrong window.
jrtayloriv chromatic, so there would be no sense in working on anything to do PIR->LLVM/libJIT then, correct? 19:29
chromatic That's not a bad thing, but it doesn't solve our biggest problems with regard to JIT.
19:30 mokurai joined 19:50 whiteknight joined
Coke reclaims another partcl spec test. 19:54
whiteknight yay!
darbelo Does anyone know of a way to fet at a STRING's encoding without poking into the struct? 19:55
s/fet at/get at/
whiteknight darbelo, you mean like an API function to retrieve it?
darbelo Yes, that would be the ideal. 19:56
whiteknight I don't know. Best bet is to search around in src/string/api.c
darbelo None of the Parrot_str_* funcions there look very promising. 19:57
cotto You can always write one. 19:58
darbelo Ah, I found it, it's string_rep_compatible() 19:59
Obvious, right?
TimToady phone 20:00
darbelo The lack of a Parrot_str_* prefix made me overlook it the first time arround. 20:02
Coke the string API was due a rewrite. I think there's a branch describing it, but I don't know how far it got.
darbelo Coke: The way the stuff pokes into STRING internals at every chance you'd never guess there was an API. 20:04
Coke s/re//
whiteknight yeah, it doesn't need a "rewrite", it needs a "write"
Oh noes! coke beat me to it!
Coke and more efficiently. 20:05
darbelo I just started removing direct access to the struct members, but there's still a lot of wrong in there.
cotto It'd be nice if there were something as easy-to-use as ->strstart. 20:06
darbelo Heh. ack for '-Zstrstart' in src/ gives 260+ usages 20:07
s/Z/>/
whiteknight ... so what you're saying is that Parrot needs an intern to do repetitive work?
darbelo Nah, I'm doing that already. What parrot needs is a clean and consistent API for STRINGs. 20:09
whiteknight this is true
feel free to start writing that API as you work
chromatic Someone should ask Simon about its status.
Coke please see what simon did first.
whiteknight whatever whoever did what, we can still start writing API functions now and mark them as experimental 20:10
20:10 NotFound joined
NotFound hi 20:10
whiteknight hello NotFound
Coke whiteknight: i don't want us to write a NEW NEW API when we haven't incorporated teh OLD NEW api. 20:11
whiteknight Coke: I'm not aware that we had an old API
we certainly don't have a working one in trunk
Coke whiteknight: which is why i said "see what simon did"
NotFound Amazing how much has changed in the month I haven't svn up'ed this machine 20:12
whiteknight he can look, but that's a branch with a bus number of 1 and fewer active contributors then that
dalek rrot: r40929 | mikehh++ | trunk/src/pmc/packfilerawsegment.pmc:
fix codetest failure - trailing spaces
 20:13
rtcl: r669 | coke++ | trunk/src/class/tclint.pir:
Avoid recursion - don't add our PMC, just our int value.
rtcl: r670 | coke++ | trunk/runtime/builtin/uplevel.pir:
Clone result to avoid self-referential lists in uplevel.test
rtcl: r671 | coke++ | wiki/SpecTestStatus.wiki:
This test now runs to completion (+17 spec tests)
whiteknight is github down? 20:14
(I finally get around to creating a github account, and it goes down that very day)
chromatic It's built on Twitter, which is powered by DHH's sense of self satisfaction and axe body spray. 20:15
whiteknight oh, all the girls must love that 20:16
Coke whiteknight: just becaues no one implemented his design doesn't mean we should ignore it. =-)
whiteknight my gitub brings all the girls to the yard and they're like, "beats svn by far"
Coke: not ignore it, but don't be held hostage by it. 20:17
If darbelo has the inclination and tuits to actually build an API, he should do it 20:18
Coke but he should look at the prior art.
just like you wouldn't go write a JIt from scratch.
We already have an insane amount of NIH in parrot. I'd hate to extend that to things that /other parrot contributors/ did.
darbelo: if you're excited about strings, by all means. =-) 20:19
whiteknight I'm not saying ignore it, but darbelo having working code to commit > an idea about code that never got merged
tuits, inclination, and working code are all trump cards 20:20
Coke I disagree in degree. design first, code second.
so if darbelo has a better /design/, sure.
whiteknight if somebody came out of the blue with a working, home-brew JIT for Parrot to have, that satisfied what we needed, I would be inclined to take it 20:21
darbelo has no design. 20:22
whiteknight far more likely is a process where we need to make a comprehensive design and a concerted development effort to implement a wrapper around an existing library
Coke darbelo: is there a function that does what you want in PDD28 ?
whiteknight DARBELO YOU ARENT HELPING 20:23
actually, you're very helpful
NotFound Did we have a strings design? 20:24
Coke hurls news.perlfoundation.org/2008/09/par...march.html
Coke quotes, "Simon Cozens worked with Allison on the design for character sets and strings (PDD28)"
NotFound Yeah, a branch no one has looked at for months 20:25
Coke I think the design was in trunk's pdd28.
If not, that at least should be merged back, as the design was created and reviewed.
whiteknight I haven't heard anything about that grant in a long time 20:26
darbelo Coke: Just started looking at the pdd now.
whiteknight I think I was even supposed to get some money for it at one point 20:27
darbelo Say, wasn't UnionVal taken to the back yard and shot?
whiteknight darbelo: yes sir
darbelo The strings pdd didn't get the memo. It list an UnionVal member for that struct, named cache "for compatibility with PMC structures." 20:29
whiteknight KILL IT WITH FIRE
particle if anyone notices things in parrot that can only be reached via poking into structs, please ticket them
whiteknight particle: that's a great point, and probably should be a weekly focus at some point 20:30
darbelo Holy shit! "strstart" is already deprecated!
NotFound darbelo: have fun if trying to kill it
moritz so if I find it in the rakudo source, what should I replace it with? 20:31
jrtayloriv darbelo, I already posted a patch for those docs
nobody has committed it yet. 20:32
Coke notfound: right. the design was completed but not implemented. Doesn't imply anything negative about the design.
whiteknight moritz: we need to implement a sane API to replace it. Suggestions welcome
whiteknight is leaving now. Layer
Later*
darbelo moritz: My guess: Parrot_str_to_cstring(), and pair it with a Parrot_str_free_cstring()
jrtayloriv darbelo, (TT #958)
Coke at least, it was /theoretically/ completed.
moritz uhm, that's quite a lot work for simple tests
jonathan moritz: You won't - I'm sure - find strstart in the Rakudo source. 20:33
moritz src/pmc/perl6str.c
133: if (s && s->strstart) {
134: const char *s1 = s->strstart;
jonathan ...erm, in the bits I wrote...damm.
:-)
moritz that's generated code, I think
jonathan ah
Look at the pmc file
darbelo if( s ) {
NotFound Coke: I'm not sure if that completeness has been asserted by soemone that looked at the real usages in the code base 20:34
moritz it's in the .pmc file too
jonathan Oh well
At least it's in a PMC that is meant to be dealing with strings...
Coke NotFound: so let's verify that rather than throwing it out. =-) 20:35
darbelo Heh, the actual parrot String PMC is pretty tame if you compare it with others.
Coke ISTR that allison signed off on it, for what's that worth.
jonathan IMO, Simon is more than a little competent in this area. It's too bad he couldn't see the implementation through, but I strongly recommend his design be considered. 20:37
darbelo Coke: (pdd has what I need) Only in the 'deprecated' section :) 20:40
But I consider using deprecated functions a step above direct struct member access, so it's good enough for me. 20:43
Coke is very confused. 20:45
compromise? 20:46
purl compromise is that you promise not to change the metaclass
Coke no, compromise is an agreement that means no one is happy.
purl okay, Coke.
NotFound Did we need a deprecation cycle or something to add a new PObj flag?
Coke notes that ops2c seems to be generating CONTEXT() ... 20:48
20:51 darbelo joined 20:53 hercynium joined
darbelo NotFound: "Never to add, always to remove" is the way I read the current policy. 20:53
chromatic Me too, but I keep hearing "You can change, as long as it stays the same, even if it can't possibly work." 20:54
Coke ETOOBITTER.
chromatic Not at all.
Coke I'm sure I was talking about my koohii.
chromatic ALL existing code MAY have to change.
The TYPE DECLARATIONS of all existing code which deals with CONTEXTs *probably* has to change. 20:55
NotFound I'd like to add a flag that signals that the PObj is live, but the name 'live' is already taken.
Will 'active' be a good name?
darbelo likes not_dead 20:56
chromatic If code has to change, why even try to keep source level compatibility, especially when the naive and easy approach is a guarantee that SOME cases will cause segfaults?
20:56 bacek joined
NotFound darbelo: I was trying to avoid having to write code that looks like: "Wanted PObj, dead or alive" 20:56
darbelo NotFound: I would advocate the rewrite of fundamental core subsystems, just to allow code like that. 20:57
NotFound darbelo: code like that is a must if we want to catch GC errors 20:58
darbelo wasn't talking about the error :) 20:59
find_pmc_dead_or_alive();
Coke speaking of segfaults.... =-) 21:03
cotto With the proper application of libsigsegv we'll never see a segfault again. 21:06
And by "proper" I mean "improper". 21:07
NotFound cotto: don't see them is not a problem. In fact is what most people do most of the time X-)
mikehh ha - wouldn't want to discredit cotto++ but ...
21:10 workbench joined 21:13 rbaumer joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40929 - Ubuntu 9.04 amd64 (gcc) 21:18
also wioth g__
that was supposed to be g++ - hit the wrong key - need some sleep cul8r 21:19
NotFound karma g
purl g has karma of 623
darbelo g--
Tene karma g__ 21:21
purl g__ has neutral karma
Tene g__++
karma g++
purl g++ has karma of -1
darbelo karma c
purl c has karma of 7982
Tene karma c++
purl c++ has karma of -86
darbelo karma c99
purl c99 has karma of -2
darbelo karma c89
purl c89 has karma of 1
darbelo karma objc 21:22
purl objc has neutral karma
Coke msg mikehh mikehh++ # running regular spec test runs; hopefully partcl will be able to avoid regressions now. 21:23
purl Message for mikehh stored.
cotto karma getting back to work 21:26
purl getting back to work has neutral karma
cotto clearly
darbelo (getting back to work)++ 21:27
bacek Good morning
purl And good moroning to you, bacek.
bacek cotto: found new job?
particle heads out for lunch and errands & 21:29
21:30 joeri left
cotto bacek, funny you should ask. I just got one today! 21:31
Coke (16+17)/3363
purl 0.00981266726137377
21:31 Whiteknight joined
bacek cotto: congratulations 21:31
cotto It's a good day. 21:32
darbelo cotto: Cool! You can start eating again!
cotto and I won't have to lean on you so hard for that GSoC kickback
unrelatedly, did you get your final payment yet? 21:33
Coke hey, I'm starving.
->
cotto <-
darbelo cotto: Yup. Still waiting on the shirt, though. 21:34
cotto I'm feeling good. This profile postprocessing code is finally looking partly sane.
21:34 beta joined 21:35 beta left 21:36 workbench joined
cotto workbench, owner 21:45
workbench That contained a sentence with fewer than three words.
cotto workbench, who is your owner
workbench Factoid 18099926 = (who) (is) (your owner)
cotto workbench, What is the average rainfall in the Amazon basin? 21:46
workbench Factoid 35952082 = (What) (is) (the average rainfall in the Amazon basin?)
jonathan workbench, help 21:51
workbench There's no help for topic 'help'.
jonathan well that's helpful
21:52 nopaste joined
cotto workbench, purl 22:00
purl somebody said workbench was a robot or keeping norris's cock all to himself
workbench That contained a sentence with fewer than three words.
cotto purl, antibotsnack
purl thanks cotto :)
22:03 dngor joined
dalek rrot: r40930 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
[profiling] split pprof2cg into functions for greater sanity, testing and refactoring
 22:05
22:05 theory joined 22:13 skv joined
Coke if we have a nonresponsive bot, we should boot 'im. 22:30
darbelo Okay, I can find no effcient way to implement the String PMC's trans METHOD without poking into the underlying STRING's members. 22:32
chromatic If it's within src/string/*.c that should be fine.
darbelo it's in src/pmc/string.pmc
Coke 6651 / 60 / 60 22:33
purl 1.8475
Coke wonders if there is a git workflow that would allow him to check in new code somewhere while running a 2 hour test suite that required me not to change any code. 22:36
darbelo If I stick to what the pdd says I can do to a STRING, then I have to do a Parrot_str_replace() with a (temporary) STRING of length one, inside a loop. 22:37
I think that calls for a Parrot_str_replace_grapheme() function. 22:38
Well, Parrot_str_replace_character(), since the grapheme functions aren't implemented. 22:40
22:41 rg joined
treed Coke: You could set up a private remote with a post-commit hook. 22:41
Push to it to test.
Coke note that the repo running the 2 hour process is a git-svn repo. 22:42
I had trouble when that was factored in the last time.
not a huge deal, as I can just work temporarily in a straight svn checkout
bacek Coke: mkdir tmp; git clone ../orig; ...; git commit; git push
chromatic I'd make a temporary, short-lived branch. 22:44
dalek rrot: r40931 | bacek++ | branches/context_pmc3/src/jit/i386/jit_defs.c:
Partially unbroke jit. Returning values from calls still broken.
 22:46
Coke wonders how to get putty out of full screen mode when alt-esc doesn't bring up the menu, and alt-tab doesn't. 22:47
darbelo alt-enter?
Coke nope
bacek ctrl-alt-reset :)
Coke this library computer must be VERY locked down.
brb
darbelo F11?
purl F11 is, like, mapped to the escape key
chromatic Hmm, that makes me think I could fix that part of the JIT... but do I want to? 22:48
bacek chromatic: up to you. I've spent about 4 hours on this 3 lines already... 22:49
chromatic My problem is I think it's the WRONG policy. 22:50
I think Allison's interpretation of our deprecation policy is actively harmful.
Tene chromatic: would you rather work on that segfault I had from rakudo when trying to use the Mysql library? 22:51
I saw some of that discussion in #ps...
22:51 skv joined
chromatic My top priority is reviewing the profiling core. If you want me to look at that segfault, give me some code and I'll take a look afterwards. 22:51
bacek Just $0.02. I've spent about 3-4 days in context_pmc3 branch on "deprecation policy" related stuff...
chromatic I think that branch is doomed because of it. 22:52
Tene I just wonder what audience she's targetting with her interpretation of the deprecation policy. Who does she believe it helps?
chromatic It doesn't help anyone, is the problem.
Any HLL that uses CONTEXT(interp) directly needs source code review to make sure it won't crash.
Someone needs to review all uses of the macro. 22:53
Every one.
purl every one is broken
treed Wouldn't it be reasonable to convene a sort of HLL council which could be asked "Hey, are you guys using this?"
Tene So... what happens if we just merge it in, fix rakudo, and nobody complains?
chromatic No, because she's invoking the DarkPAN nuclear argument.
treed has no idea what that is.
chromatic "There may be code which we can't see and thus can't debug which relies on this, and we need to notify them with our regular deprecation policy and give them a chance to migrate to the new version." 22:54
Even though THEY HAVE TO MODIFY THEIR CODE ANYWAY.
treed isn't terribly enthusiastic about the deprecation policy as it sits. 22:55
NotFound Tene: What Mysql library?
22:55 ruoso joined
treed "When" something *can* be removed isn't nearly as useful to know as when it *will* be removed, and what's the alternative 22:55
Tene NotFound: examples/nci/Mysql.pir
treed Which don't seem to be required under the deprecation policy as I've seen it.
chromatic In other words, to introduce an API to encapsulate struct-poking behavior, we have to *add* more struct-poking macros so people can poke in structs safely until they decide that they want to rewrite their code again to use the API which we've already provided. 22:56
duk3leto i really like the idea of preemptively telling HLL's "hey, don't do that, we will break your shit soon 'cause you are using an undocumented internal-only macro"
chromatic I can think of several options.
NotFound Tene: It doesn't work since some changes in nci broke it, I lacked the time to fix it
treed would just prefer to see more communication about deprecation.
duk3leto treed++ 22:57
chromatic I'm tempted to release 1.4.1 with only that deprecation notice added.
treed "This will be marked deprecated." "This is being removed as of $date."
Tene NotFound: even trying to instantiate a Mysql object from rakudo causes segfaults.
treed "This is what you use instead."
NotFound Our deprecation policies have a problem: for example, the random thing, we deprecated and deleted it before having a replacement.
treed Exactly. 22:58
duk3leto NotFound: hmm, close but not exactly. I had the random dynops written before deleting the random PMC
treed It needs to be: Propose deprecation. Create alternative, mark as deprecated. Wait a bit, then remove."
nopaste "tene" at 97.117.70.208 pasted "This segfaults, and the equivalent pir doesn't. NotFound++" (4 lines) at nopaste.snit.ch/17787
treed With the exception of shit that can't do that.
duk3leto NotFound: but your point still stands
chromatic Some things just don't work. JIT for example.
treed Which maybe should just have a longer guaranteed transition time.
Coke treed: alternatives are not always necessary.
we can just say "we're not doing that anymore."
treed Coke: If there's no reasonable alternative, then skip that step. 22:59
NotFound duk3leto: but we don't had a release where that replacement can start to be used.
Coke NotFound: I thought rand() was added before RANDOM was removed.
duk3leto NotFound: correct. Perhaps deleting deprecated stuff should be done in the *beginning* of a dev cycle, instead of the last few days, which only gives rakudo a few days to fix their stuff before their release
chromatic Yes, we should be a lot better about that. 23:00
duk3leto and other HLL's too, of course
something along the lines of "deprecated code should be removed in the first half of a dev cycle, to give HLL's sufficient time to upgrade their code" might be a good idea 23:01
NotFound No, my point is that we must put the replacement (when one can be done) at the same time that the deprecation notice. That way people can start changing his code.
Coke NotFound: ah, I see your point. yes.
duk3leto NotFound: or before ;)
NotFound "same time" == "same release"
chromatic I disagree.
Coke chromatic: certainly it's preferable. 23:02
(er, wait, who are you talking to?)
duk3leto NotFound: that ties having a solution to deprecating something, which is a lot more work.
chromatic I'm disagreeing with NotFound.
Coke I think it would certainly be nice if we had the new API in place before removing the old one.
bacek We can't adjust our release cycle to release cycles of all HLLs.
chromatic Sure, but that's not always possible.
duk3leto NotFound: if we must have a solution before deprecating, JIT would never get fixed
treed (Note: Cardinal has no release cycle for the forseeable future. We'll just track SVN HEAD.) 23:03
chromatic If we must always have a solution before deprecating, we can't make contexts into PMCs.
duk3leto bacek: no, they should sync up to ours :)
NotFound Not always, but when is possible it must be the prefered way.
Tene And who benefits by holding back the context_pmc work?
chromatic The DarkPAN benefits.
Coke (in random's case, the problem was the huge delay in deciding on what the replacement should look like. =-)
duk3leto Tene: not me
chromatic If it exists.
Coke I have a hard time believing parrot has a PAN Of any kind.
bacek Tene: DarkPANers of Parrot...
chromatic Rakudo doesn't benefit. Partcl doesn't benefit.
treed I really think a reasonable solution to most deprecation issues is just constant contact with representatives from HLL projects. 23:04
NotFound Coke: that problem was quickly solved when people absolutely need a replacement ;)
chromatic Remember though, we are talking about the EXTERNAL CODE POKING DIRECTLY INTO PARROT DATA STRUCTURES.
duk3leto Coke: in random's case, the problem was that dynops were not being installed correctly and it took me a few days to figure out how to fix rakudo (with moritz++'s help), which *did* get a bit close for comfort to the rakudo release
chromatic Our deprecation policy explicitly *disclaims* that we support that.
Coke is now getting "Object must be created by a class." 23:05
Coke thought those were all fixed. :|
NotFound Note that the auto_attrs in fact can break some code, and we allowed it to pass ;)
duk3leto chromatic: Perhaps we should add "if you poke into our internal data structures in your code, you get what you deserve. Namely, segfaults." to our support policy? ;) 23:06
chromatic I did!
Coke wishes the parrot debugger works.
duk3leto: you were the latest to hack on that, yes?
bacek duk3leto: it's already there :)
cotto chromatic++ for that clarification
duk3leto Coke: yes, I wish breakpoints worked
NotFound Coke: it works for some value of "works" ;)
treed A debugger would be so damned handy.
duk3leto Coke: please add a ticket for making breakpoints work, if someone else seems to care, I may have more motivation :) 23:07
Coke I don't want a breakpoint. I want a backtrace.
NotFound duk3leto: a year ago they worked, but I think only in the simplest pbc's
chromatic We're two weeks from the next release, right?
duk3leto i know it is not the same, but incase anybody hasn't checked it out, there is tools/dev/parrot_shell.pl for prototyping/timing simple pir code
bacek chromatic: something like this
chromatic Let's just merge the damn branch and be done with it.
duk3leto chromatic+++ 23:08
Tene +1
purl 1
treed wants to be able to stop code at arbitrary points and examine the state of variables.
Which branch is this? bacek's?
Coke I'm getting that error, I have no idea where in the several thousand lines of tcl I'm running that error is.
chromatic Yes.
treed has no opinion on the matter, other than what he's seen here. If it breaks Cardinal, I'll fix it.
duk3leto treed: you can examine the state of variables now in the debugger, but you have trace/step manually. no breakpoints :(
bacek I can do it. Tonight. 23:09
chromatic If we have to yank it before the next release, so be it.
bacek It's $dayjob time. And it will take some time to sync branch with trunk.
chromatic We have a repository for a reason.
bacek But JIT still broken.
duk3leto treed: you can add/delete breakpoints just fine. it is that the condition doesn't make the debugger actually stop in the correct place
or stop at all, for that matter
treed duk3leto: I didn't know there was a debugger. 23:10
duk3leto treed: ./parrot_debugger
treed Huh.
Works like parrot, except that it has a debugger interface?
duk3leto treed: i added mosts of the tests and updated the docs recently. it is still a mess, but basically useable, other than breakpoints
cotto It'll be interesting once allison gets back.
duk3leto treed: ./parrot_debugger foo.pir
treed Neat!
treed tries it out. 23:11
chromatic bacek, do you think fixing the JIT will take more than a day or two?
duk3leto treed: then type "t" to trace a single line of code, or "c" to run everything
treed: p P will print all PMC variable, p N2 will print $N2, etc...
treed does it start out stopped?
duk3leto treed: yes
treed So, I just hit t until I get to where I want to look at it.
Tene chromatic: wasn't there discussion of dropping JIT?
duk3leto treed: try doing "t 5" to trace the first 5 instructions
treed ASsuming that once you hit c, you can't stop it.
chromatic I don't even want to *think* about the debate over dropping JIT right now. 23:12
duk3leto treed: trace means print out and run each line
treed: yes, currently, c will just run the entire code
treed Huh.
bacek chromatic: I have no idea about how JIT works and why it's broken.
treed It just ran and gave me a backtrace.
duk3leto treed: please pastebin
chromatic bacek, given what I've seen so far, I think it's possible to fix. 23:13
treed pastebin what?
purl pastebin is, like, see nopaste. or see shadowpaste
treed Or can you not do it with pbc files?
duk3leto treed: a good backtrace or a bad backtrace ?
treed It's the normal backtrace that occurs when I try to run it normally.
dalek rtcl: r672 | coke++ | trunk/docs/spectest- (2 files):
Passing another 33 tests, with one more file running to completion.
bacek chromatic: it will be good.
treed The backtrace that I'm trying to debug on cardinal's end.
duk3leto treed: should work with pbc, i thought there was a test for that
treed (In the iss41 branch, which has been stagnant for a couple days.)
../parrot/parrot_debugger cardinal.pbc 23:14
Acts just like ../parrot/parrot cardinal.pbc
duk3leto treed: i have found that "gdb parrot" is a lot more useful than the parrot_debugger. set a breakpoint on Parrot_break, and you are set
treed How do you view registers and whatnot, thougH?
treed doesn't know much about parrot internals.
duk3leto treed: p I0 should print the I0 register 23:15
treed Even in gdb?
duk3leto treed: note that you can only print registers while the code is running, so you have to trace into the code a bit first
treed: oh. not in gdb. viewing regs in gdb is a very good question
chromatic Hm, how do I switch to the context PMC branch with a git/svn checkout? 23:16
treed would try running parrot_debugger on a pir file, but this broken cardinal can't even compile one.
duk3leto chromatic: git checkout context_pmc ?
chromatic: perhaps git checkout svn/context_pmc 23:17
bacek git checkout context_pmc3_local; git reset --hard remotes/context_pmc3
git checkout -b context_pmc3_local; git reset --hard remotes/context_pmc3
duk3leto chromatic: it depends how you set up your git-svn
Tene chromatic: depends on whether you copied the entire repo or just /trunk
chromatic [svn-remote "svn"]
url = svn.parrot.org/parrot
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
bacek chromatic: you'll probably have to "git svn fetch" before checking out 23:18
Tene git checkout context_pmc3
chromatic git svn fetch definitely checks out branch commits. 23:19
Tene better would probably be: git checkout -t -b context_pmc3 context_pmc3
duk3leto chromatic: git svn fetch updates your git-svn will all branches. git svn rebase just updates whichever branch you are tracking, which is probably trunk
chromatic Ah, I see.
23:20 donaldh joined 23:22 TonyC joined
chromatic I think that's done it. Thanks. 23:22
bacek chromatic: trac.parrot.org/parrot/wiki/git-svn-tutorial "Tracking SVN branches with GIT". 23:23
It's brain-dump of my workflow. Can't be improved, apparently.
cotto Your brain is perfect. 23:24
bacek ~~ $dayjob
cotto: may be. But dump looks ugly enough :)
dalek rtcl: r673 | coke++ | trunk/runtime/builtin/info.pir:
make [info exist] work as well as [info exists]

This re-enables at least one spec test file.		 23:28
cotto clock? 23:30
purl cotto: LAX: Wed 4:30pm PDT / CHI: Wed 6:30pm CDT / NYC: Wed 7:30pm EDT / LON: Thu 12:30am BST / BER: Thu 1:30am CEST / IND: Thu 5:00am IST / TOK: Thu 8:30am JST / SYD: Thu 9:30am EST /
dalek rtcl: r674 | coke++ | wiki/SpecTestStatus.wiki:
This test runs to completion now.
 23:33
23:45 skv_ joined 23:47 Whiteknight joined
chromatic Looks like this does it. 23:49
bacek_at_work hi again 23:51
purl oh, you're back!
davidfetter wb! 23:53
dalek rrot: r40932 | chromatic++ | branches/context_pmc3/src/jit/i386 (2 files):
[JIT] Fixed JIT to find the right current_results member in the new Context PMC.
 23:56
chromatic make testj passes on 32-bit Linux for me with that.
darbelo Merge that sucker!
chromatic We should notify the list first, just to prepare anyone tracking HEAD for the possibility of DarkPEN breakage. 23:57
bacek_at_work Yay! chromatic++
jonathan OH NOES but what if it breaks Rakudo's use of undocumented "APIs"? ;-) 23:59
dalek rrot: r40933 | chromatic++ | branches/context_pmc3/src/jit (4 files):
[JIT] Attempted to fix up context accesses for AMD64, PPC, and Sparc JITs as

why not try?
chromatic Then we rip it out until January 2010.

Powered by Cro and the Raku® Programming Language.

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

Thank you!