Camelia, the Perl 6 bug

IRC log for #parrot, 2009-09-02

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 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
00:00 purl oh, you're back!
00:00 chromatic I don't want another vtable for this.
00:00 chromatic It seems like the wrong place.
00:00 Whiteknight yeah, that relationship is probably backwards anyway
00:01 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
00:01 Whiteknight So for instance we need to know that the library PMC is depended on by the dynpmc it implents
00:01 Whiteknight or that the Scheduler is depended on by various tasks and timers
00:02 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
00:03 Whiteknight chromatic: but if their dynpmc was causing segfaults, they would figure it out and do whatever they needed to do
00:04 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:05 Whiteknight we can fix this instance, yes. But this isn't the only order-of-destruction problem we have
00:06 Whiteknight 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.
00:06 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.
00:09 Whiteknight We need an API where we can specify a dependence relation
00:09 Whiteknight no interaction with GC internals whatsoever
00:10 chromatic I can't think of any cases besides scheduler and dynpmc.
00:11 darbelo Whiteknight: Oh. Then I totally misread you earlier, sorry.
00:11 Whiteknight chromatic: no cases currently, or no casses possibly?
00:12 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 chromatic 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 #parrot
00:13 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:18 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.
00:20 dalek tracwiki: v95 | whiteknight++ | WikiStart
00:20 dalek tracwiki: Adding link to page about the JIT replacement effort
00:20 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=95&action=diff
00:23 Whiteknight chromatic: I'm stumped for ideas then. How do you suggest we fix it?
00:24 chromatic We have to identify all PMCs of the appropriate types and destroy them in the appropriate order.
00:28 Coke FIND THEM AND DESTROY THEM!
00:29 nopaste "jrtayloriv" at 96.238.199.12 pasted "Programming question ..." (9 lines) at http://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?
00:29 darbelo chromatic: But what is the appropiate order if a PMC allocated in the constatnt pool depends on thomething that isn't?
00:29 Coke msg util that's not unheard of; check out docs/spectest-progress.csv for my timings.
00:29 purl Message for util stored.
00:29 Coke (man is partcl slow)
00:36 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.
00:37 jrtayloriv bacek_at_work, ok thanks
00:38 darbelo If it makes the line longer than 72 chars, let the compiler fold it for you :)
00:38 darbelo jrtayloriv++ # kill_parrot_cont reports "All tests successful" on OpenBSD amd64
00:39 Coke darbelo: there is virtually no optimization.
00:40 Coke and everything is runtime dispatch. there is A LOT of runtime invocation of the PIR compiler.
00:40 Coke (but even rakudo is slow, and it's a real compiler.)
00:41 jrtayloriv darbelo, I see (about the line length) -- thank you.
00:43 Coke darbelo: hopefully the profiler will help id hot spos.
00:44 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:46 darbelo Coke: So, it's slow all over, but some places are slower thatn the rest?
00:47 dalek tracwiki: v1 | whiteknight++ | JITRewrite
00:47 dalek tracwiki: Initial draft
00:47 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​JITRewrite?version=1&action=diff
00:56 dalek TT #963 created by coke++: segfault in Parrot_HashIteratorKey_get_string
01:00 nopaste "darbelo" at 200.49.154.172 pasted "[PATCH] Remove needless struct-poking from the fixedbooleanarray.pmc. All tests PASS." (25 lines) at http://nopaste.snit.ch/17780
01:01 darbelo Whiteknight: if you are interested I can turn the example posted at TT#956 into a test.
01:03 darbelo Also, if anyone cares to review/commit, http://nopaste.snit.ch/17780 is the first step in the total erradication of needless poking into STRING internals.
01:04 darbelo I'll go hunting for food now. See y'all later.
01:04 darbelo left #parrot
01:05 dukeleto food++
01:07 jrtayloriv karma food
01:07 purl food has karma of 179
01:07 jrtayloriv that's definitely not high enough
01:07 jrtayloriv food++
01:09 Coke msg darbelo Without profiling, who can tell?
01:09 purl Message for darbelo stored.
01:10 dalek TT #964 created by coke++: segfault in Parrot_str_new_COW
01:12 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:15 jrtayloriv 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:18 jrtayloriv 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:20 Whiteknight Parrot_PCCINVOKE(interp, pmc, CONST_STRING("Method name"), "signature", ...)
01:20 Whiteknight (I may have mixed up the order of those arguments)
01:20 Eevee joined #parrot
01:20 Whiteknight Actually, you should probably use Parrot_pcc_invoke_method_from_c_args() instead
01:22 Whiteknight food++ definitely! I may go find some right now
01:23 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:24 jrtayloriv hmm ... nm -- used in a few other places as well, but still doesn't belong in sub.c I think ...
01:25 jrtayloriv belongs in Continuation actually -- brain fart
01:26 dalek TT #965 created by coke++: segfault in Parrot_convert_arg
01:29 kid51 joined #parrot
01:32 kid51 msg wayland76 https://trac.parrot.org/pa​rrot/ticket/509#comment:16
01:32 purl Message for wayland76 stored.
01:32 kid51 seen infinoid?
01:32 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]
01:33 dalek TT #966 created by coke++: segfault in Parrot_string_mark
01:40 dalek TT #967 created by coke++: segfault in utf8_set_position
01:43 dalek partcl: r664 | coke++ | wiki/SpecTestStatus.wiki:
01:43 dalek partcl: Edited wiki page through web user interface.
01:43 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=664
01:47 dalek TT #773 closed by coke++: Can't override vtables of a PMC from PIR
01:57 dukeleto joined #parrot
01:57 dalek TT #831 closed by coke++: segfault in clone_key_arg
02:07 payload joined #parrot
02:22 rhr joined #parrot
02:26 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 jrtayloriv 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?
02:38 jrtayloriv Oops -- I shouldn't be declaring this as a method anyway, since it is only used internally.
02:39 pmichaud CONST_STRING requires that the statement be all on one line, I think.
02:42 janus joined #parrot
02:43 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:44 bacek_at_work jrtayloriv: don't try to put them as methods in Continuation anyway. Chicken and Egg problem
02:45 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
02:45 jrtayloriv bacek_at_work, that would work, right?
02:45 jrtayloriv pmichaud, OK thank you.
02:48 bacek_at_work jrtayloriv: probably no. But I don't quite understand what are you trying to achieve.
02:49 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:50 bacek_at_work jrtayloriv: ah. ok. Just move it into beginning of continuation.pmc before 'pmclass Continuation'
02:50 bacek_at_work But it will not be visible in inherited PMCs.
02:52 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 jrtayloriv bacek_at_work, And you are saying that I cannot declare it as a method in Continuation PMC to accomplish this?
02:52 bacek_at_work then just keep in sub.c
02:52 jrtayloriv bacek_at_work, OK.
02:53 bacek_at_work yes, because calling of methods require new continuations.
02:53 jrtayloriv oh, I see.
03:14 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:17 jrtayloriv treed, Do you know Perl at all? How much, if so?
03:18 treed Very, very little.
03:18 jrtayloriv Learning Perl and Intermediate Perl are great for starters.
03:18 treed And what I do know has been slightly tainted by my exposure to Perl 6.
03:20 donaldh joined #parrot
03:23 jdv79 treed: maybe just put another target in your rakefile to upload the report file?
03:23 jdv79 treed: http://smolder.plusthree.com/app/​public_projects/smoke_reports/16
03:23 jdv79 i just pushed the first report
03:28 theory joined #parrot
03:31 jdv79 what's goin on with the svn server's cert?
03:33 treed jdv79: What's the upload like, just an HTTP PUT?
03:33 jdv79 just a post
03:34 treed To what URL? Is there a doc for this stuff?
03:34 jdv79 emulate what the form does at http://smolder.plusthree.com/ap​p/public_projects/add_report/16
03:35 jdv79 basically post to that url with a report_file param - normal form file upload
03:35 treed k
03:35 jdv79 i don't think there's doc
03:37 jdv79 Coke: partcl still isn't compiling here:(
04:10 cotto joined #parrot
04:10 cotto hello
04:10 purl what's up, cotto.
04:13 dukeleto joined #parrot
04:15 kyle_l5l joined #parrot
04:40 beta left #parrot
04:50 dalek TT #968 created by jrtayloriv++: Rename PObj_active_destroy_foo to PObj_custom_destroy_foo
04:58 jdv79 Coke: i'd like to get partcl into smolder.  but that kinda means it needs to compile:)
05:06 snarkyboojum joined #parrot
05:07 dukeleto 'ello
05:09 slavorgn joined #parrot
05:14 theory joined #parrot
05:54 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?
06:07 chromatic joined #parrot
06:07 cotto I've had interesting experiences putting printfs in certain places.
06:07 cotto gdb might be a better bet if you want to poke around
06:08 cotto test coverage?
06:08 purl test coverage is probably http://cv.perl6.cz
06:17 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:18 cotto That code is special and ripe for replacing.
06:20 chromatic Oh, freeze and thaw.  That's special indeed.
06:22 cotto You can figure it out if you really want to, but there's a cost.
06:25 kyle_l5l heh.  I've been trying to figure it out...but it's, hm, yeah, special.
06:27 dalek rakudo: 30ffa60 | mberends++ | tools/test_summary.pl:
06:27 dalek rakudo: [tools/test_summary.pl] add hints to change "plan *;" to "plan $number;"
06:27 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​0ffa60bd472d7a0716b37ef1567a4f2b9708b4b
06:27 dalek rakudo: c6d5941 | mberends++ | :
06:27 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
06:27 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​6d5941a3c93c609c59112b778e8a7faad96ecea
06:27 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 #parrot
06:35 cotto hio, bacek
06:35 bacek hi cotto, howizgoin'
06:54 treed Hm.
06:54 treed Need to figure out how to relate the failure of test files to compile to smolder.
06:59 bacek treed: (lineof in String) looks like a bug in PCT.
07:01 bacek treed: it create String instead of CodeString
07:05 * treed nods.
07:15 skv_ joined #parrot
07:20 dalek cardinal: 870ad48 | treed++ | Rakefile:
07:20 dalek cardinal: Add a smolder target to the Rakefile to submit report.tar.gz to the appropriate website.
07:20 dalek cardinal: review: http://github.com/cardinal/cardinal/commit​/870ad48af64d5127a1ad189167c5a65c3bf763cd
07:20 dalek cardinal: 7d77922 | treed++ | Rakefile:
07:20 dalek cardinal: Refactor the Rakefile a little.
07:20 dalek cardinal: review: http://github.com/cardinal/cardinal/commit​/7d77922e2403b4720986ceebea8659cf9e760153
07:21 donaldh joined #parrot
07:33 dalek parrot: r40918 | mikehh++ | trunk/src/pmc/string.pmc:
07:33 dalek parrot: fix codetest failure - no trailing spaces
07:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40918/
07:33 mikehh messages
07:36 kyle_l5l ack, isn't limited to just hash.c, happens in all sorts of neat places.
07:39 mikehh need to reboot - still can't get VirtualBox to work with wireless connection :-{ (or kvm for that matter) - bbl
07:47 iblechbot joined #parrot
08:10 cotto chromatic, ping
08:10 mberends joined #parrot
08:10 chromatic pong
08:12 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:13 chromatic Yes, I should have plenty of time tomorrow and Thursday.
08:13 cotto ok
08:16 cotto there
08:17 dalek parrot: r40919 | cotto++ | branches/pluggable_runcore (2 files):
08:17 dalek parrot: [profiling] update runcore to what's likely to be the format pprof2cg can use
08:17 dalek parrot: It's terribly inefficient for now.  Efficiency can come once it's working and well-tested.
08:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40919/
08:21 HG` joined #parrot
08:37 moritz can we ship parrot with LGPL licensed code?
08:37 moritz both libjit and gnu lightning are LGPLed
08:39 chromatic Allison's against it.
08:41 moritz but linking against LGPL code is fine?
08:43 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 #parrot
08:44 chromatic Based on her comments earlier, I suspect she won't like us deleting the existing pseudo JIT.
08:45 chromatic ... if we declare JIT non-core.
08:46 mikehh joined #parrot
08:47 mikehh on Ubuntu 9.04 i386 - anyone need any testing done on this platform?
08:53 cono joined #parrot
08:55 jsut joined #parrot
09:00 skv_ joined #parrot
09:15 cognominal joined #parrot
09:16 cognominal joined #parrot
09:20 mikehh All tests PASS - (pre/post-config, smoke, nqp_test, fulltest) at r40919 - Ubuntu 9.04 i386 (gcc)
09:35 mikehh_ joined #parrot
09:43 masak joined #parrot
09:47 mikehh joined #parrot
09:49 mikehh rakudo (c6d5941) builds on parrot r40919 - make test PASS / make spectest (up to 28165) 3 failures - Ubuntu 9.04 i386 ...(more)
09:51 mikehh rakudo - t/spec/S03-operators/arith.rakudo - Failed test:  120 - Non-zero wait status: 8
09:51 HG` joined #parrot
09:52 mikehh rakudo - t/spec/S12-attributes/class.rakudo & t/spec/S14-roles/basic.rakudo - Segmation fault on exit
09:54 gaz joined #parrot
10:01 mikehh BTW  I just tried to log in to https://trac.parrot.org/parrot from my i386 setup and it reports the certificate still has not been renewed
10:15 rbaumer joined #parrot
10:25 mikehh partcl r664 builds on parrot r40919 - make test PASS - Ubuntu 9.04 i386 (gcc)
10:37 mikehh 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:39 mikehh cardinal 3 complete failures - gen_08-class.pir, gen_alias.pir, gen_freeze.pir
10:39 mikehh join cardinal
10:40 mikehh idjut
10:45 cotto now it's time for sleeps.
10:48 bacek joined #parrot
10:48 dalek parrot: r40920 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
10:48 dalek parrot: [profiling] initial refactor of (incomplete) postprocessing script
10:48 dalek parrot: It doesn't produce anything that Callgrind can use quite yet, but it has most of what's needed.
10:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40920/
10:49 mikehh decnum_dynpmcs r181 builds on parrot r40919, make test PASS - Ubuntu 9.04 i386 (gcc)
10:53 Zak joined #parrot
10:53 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)
11:06 mikehh context_pmc3 branch r40920 - fails to build - jit errors - Ubuntu 9.04 i386 (g++)
11:16 mikehh context_pmc3 branch r40920 - fails to build - gets further with gcc butstill fails - Ubuntu 9.04 i386 (gcc)
11:18 mikehh 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
11:19 mikehh bacek - there are loads of jit warnings in the gcc build
11:19 bacek mikehh: yeah. Looks like they all related.
11:20 bacek Found it. Apparently ack skipped .jit files.
11:21 mikehh bacek: I have the builds logged if you need any info - gonna head back to amd64 unless you need anything on i386
11:22 donaldh joined #parrot
11:23 bacek mikehh: can you wait few minutes. I'm testing commit locally
11:23 mikehh ok - will hang around here for a bit
11:28 bacek dcommiting first chunk
11:30 bacek mikehh: should be clear at r40924
11:31 bacek mikehh++ # kicking lazy developers
11:31 dalek parrot: r40921 | bacek++ | branches/context_pmc3/src/jit/i386/core.jit:
11:32 dalek parrot: [cage] Remove last references to CURRENT_CONTEXT_FIELD macros. mikehh++
11:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40921/
11:32 dalek parrot: r40922 | bacek++ | branches/context_pmc3/src/jit/i386/jit_defs.c:
11:32 dalek parrot: [cage] Fix CONTEXT vs CURRENT_CONTEXT usage.
11:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40922/
11:32 dalek parrot: r40923 | bacek++ | branches/context_pmc3/src/jit.c:
11:32 iblechbot joined #parrot
11:32 dalek parrot: [cage] Fix CONTEXT vs CURRENT_CONTEXT usage.
11:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40923/
11:32 dalek parrot: r40924 | bacek++ | branches/context_pmc3/src/jit.c:
11:32 dalek parrot: [cage] More CONTEXT vs CURRENT_CONTEXT fixes.
11:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40924/
11:40 mikehh bacek: ok she builds (on gcc) - make test PASS - running some other tests
11:40 bacek mikehh: thanks!
11:41 bacek hang on. Why "she"? :)
11:42 * bacek start suspecting that mikehh is Russian :)
11:43 mikehh sounds better than he :-}
11:43 bacek It's just very Russian to refer bird "she" :)
11:44 mikehh bacek: got some ancestors from there - well lithuania and latvia and my great grandmother spoke russian more than english - but not really
11:47 * bacek vote to call our bird "she" from now :)
11:47 * moritz thinks that 'parrot' is a more appealing name than 'she'
11:48 mikehh well she is a female parrot
11:50 cono +1
11:50 purl 1
11:58 dalek TT #969 created by flh++: Convert t/pmc/float.t to PIR
12:08 rba joined #parrot
12:09 mikehh bacek: fulltest - testj - loads of failures - seems to be in an endless loop at the moment
12:10 bacek testj == test JIT... And JIT is badly broken.
12:11 whiteknight joined #parrot
12:16 mikehh bacek: right - and src/jit/i386/jit_defs.c has c++ comments
12:16 bacek mikehh: yes. It's marker for JIT failure.
12:23 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.
12:23 bacek Good morning whiteknight
12:23 whiteknight 'moring bacek
12:23 whiteknight how are you today?
12:24 payload joined #parrot
12:24 bacek whiteknight: sharpening knife to kill JIT :)
12:24 mikehh bacek - all other tests pass
12:25 whiteknight bacek: you and me both!
12:25 mikehh anyway rebooting to amd64 now - bbl
12:25 bacek mikehh: see you!
12:26 bacek whiteknight: yeah. Only one problem. Someone have to convince allison :)
12:27 whiteknight Allison is not stubborn or difficult. I suspect she wants us to make sure we have a good replacement ready
12:27 whiteknight 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
12:28 * bacek is very good at breaking stuff. Not fixing it :)
12:28 masak msg austin I can't seem to build Close: http://gist.github.com/179687
12:28 purl Message for austin stored.
12:28 whiteknight We need both kinds of people!
12:28 whiteknight masak: last I heard, Close was known to be broken. Major refactors
12:29 masak oh.
12:29 masak in trunk? why? :)
12:29 moritz close?
12:29 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 http://code.google.com/p/close/
12:29 masak the latter link.
12:29 purl the latter link is the right one for PEP.  http://emailproject.perl.org
12:29 whiteknight masak: when the project only has one developer, no reason not to make big changes in trunk
12:29 masak moritz: that project excites me much.
12:29 moritz unless it has users :-)
12:30 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
12:30 masak it does now.
12:30 masak as soon as I get it running, that is.
12:30 whiteknight oh really? who is using Close? What projects?
12:30 masak ok, so I back down a few revisions, then.
12:30 bacek masak apparently
12:31 masak whiteknight: I plan to become both a user and committer. as you said in a post, that language looks great.
12:31 masak much easier to write than PIR.
12:32 bacek Why not NQP?
12:32 dalek parrot: r40925 | bacek++ | trunk (2 files):
12:32 dalek parrot: Use OrderedHash in PackfileDirectory to prevent putting debug segment first. PBCs are too fragile...
12:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40925/
12:32 masak I guess NQP is quite nice, too. I should look into that more, as well.
12:33 mikehh joined #parrot
12:35 masak ok, Close builds fine from r96.
12:37 whiteknight I don't like people saying "why not NQP?". Parrot is all about using any language and giving the programmer choices
12:38 whiteknight NQP is just fine, but some people would rather use a C-like language then a Perl-like language
12:38 whiteknight and vice-versa
12:39 masak +1
12:39 purl 1
12:46 Coke "there's more than one way to do it" makes a lot less sense for parrot than it does for perl.
12:46 Coke I'm coming in late here and haven't reviewed. =-)
12:49 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
12:49 masak and both are often preferable to PIR.
12:49 whiteknight Close strikes me as being a little "closer to the machine" then NQP is, which is beneficial in many situations
12:50 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 #parrot
13:00 whiteknight (I don't recommend you stop working on partcl, of course. I was just making a point)
13:10 dalek parrot: r40926 | bacek++ | trunk (3 files):
13:10 dalek parrot: [pmc] Revert previous commit. Actually preserve type of unpacked segment. Add setter/getter to PackfileRawSegment.type
13:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40926/
13:14 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 #parrot
13:16 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 http://code.google.com/p/partcl/issues/list
13:16 purl Message for jdv79 stored.
13:16 jrtayloriv jonathan, what are you trying to get it to insert?
13:16 Coke (glad I checked the backsroll)
13:16 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.
13:16 whiteknight Coke: Oh yes, I don't recommend we add Close to the Parrot core distribution
13:17 jonathan Otherwise, the .h file breaks.
13:17 jonathan oh, actually...if I re-order the #include's in the thing including the header file it may work out a bit better...
13:17 jrtayloriv jonathan, You can just #include things in the .pmc file.
13:18 Coke anyone know what jdv79's partcl bug was?
13:18 * Coke wonders if it's just a g++ thing.
13:18 jonathan oh no, sadly not...
13:18 jonathan jrtayloriv: I know but the includes aren't also in the .h file
13:19 jonathan e.g.
13:19 jonathan ATTR SV *sv;
13:19 jonathan This in the .h file generates
13:19 jonathan typedef struct Parrot_P5Scalar_attributes { SV * sv;
13:19 jonathan } Parrot_P5Scalar_attributes;
13:19 jonathan But the #include needed doesn't make it into the .h file, so it complains about the SV there.
13:21 TonyC joined #parrot
13:23 nopaste joined #parrot
13:23 jrtayloriv johnathan, Where is SV defined?
13:28 Coke partcl?
13:28 purl i heard partcl was tcl on parrot or http://code.google.com/p/partcl
13:33 bacek jonathan: just use explicit "struct"
13:33 bacek "ATTR struct SV *sv" should work.
13:33 jonathan bacek: ooh
13:33 * jonathan tries it
13:34 dalek parrot: r40927 | bacek++ | trunk (4 files):
13:34 dalek parrot: [t] Add tests for PackfileSegment.type (and fix PackfileRawSegment.type implementation)
13:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40927/
13:34 jonathan bacek++ # thanks! :-)
13:34 Coke I'm getting tired of telling google that it's ok to post messages from google to google.
13:34 bacek karma me
13:34 purl bacek has karma of 1000
13:34 bacek Bah! Anniversary :)
13:35 bacek Can I freeze it somehow? I like this number :)
13:36 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 :-)
13:36 jrtayloriv s/if it is a struct/if SV is a struct/;
13:37 moritz jrtayloriv: I think you meant jonathan, not yourself :-)
13:37 jrtayloriv moritz, :)
13:37 moritz bacek++ # committing like hell
13:37 jrtayloriv jonathan, ^^
13:37 bacek moritz: :)
13:38 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 #parrot
13:44 bacek Anyway, Util++ for bringing my attention to Packfile* PMCs.
13:46 bacek Can anyone review TT#969? Patch looks good, but I don't trust myself much at this point of time...
13:48 Infinoid hmm.
13:48 Infinoid trac.parrot.org uses an invalid security certificate.
13:48 Infinoid The certificate expired on 08/29/2009 12:54 PM.
13:48 bacek topic?
13:48 purl i think topic is IRC topics don't auto propagate on server reconnect
13:48 bacek Ah. It was changed...
13:49 bacek Infinoid: iirc someone already across expired certificate.
13:55 HG` joined #parrot
14:07 bacek .oO( Did I say something disgusting?)
14:08 * bacek taking off TimToady's hat and departing to bed.
14:12 Coke Infinoid: particle is on it.
14:13 jsut_ joined #parrot
14:16 Psyche^ joined #parrot
14:16 * Coke wonders why some internal parrot exceptions are showing up as CONTINUE exceptions in parrot.
14:17 Coke (like "method not found")
14:19 Coke 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 #parrot
14:19 Coke bacek: continue is, imo, a pretty specific type of exception.
14:20 Coke (I added the method, so now it's (mostly) doing the right thing, though.)
14:20 Coke (PGE) trying to figure out why this doesn't parse:
14:20 Coke $ ./tclsh -e "puts [expr 1eq4>3]"
14:20 Coke syntax error in expression "1eq4>3": extra tokens at end of expression
14:20 Coke (that should print out "1")
14:21 bacek Coke: LTM ftw...
14:22 Coke ok. any idea how I can shuffle http://code.google.com/p/partcl/source/br​owse/trunk/src/grammar/expr/expression.pg around so that the longest tokens are matched first?
14:22 Coke (eq only appears in the grammar as a proto infix.
14:24 bacek Coke: not now. It's Tomorrow already and I need some sleep...
14:25 bacek But try to play with something like <!before...> in your grammar.
14:25 * bacek must sleep
14:25 purl $bacek->sleep(8 * 3600);
14:26 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 Coke see you tomorrow.
14:26 bacek Coke: have a good day.
14:27 * bacek wave from future
14:29 einstein joined #parrot
14:31 * Coke hurls http://code.google.com/p/p​artcl/issues/detail?id=100 for anyone with PGE smahts.
14:51 pmichaud oh, I think I know this one
14:52 payload joined #parrot
14:53 pmichaud actually, I think the problem might be the 'eq4'
14:53 Coke pmichaud: check out the ticket, yah.
14:53 Coke (that's when it goes south.)
14:54 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?)
14:55 Coke (it's so nice to be able to addres actual partcl issues instead of chasing segfaults. =-)
14:56 pmichaud proto 'infix:eq' is wb(0) is precedence('08=') { ... }
14:56 pmichaud the 'wb(0)' disables the check for a word boundary
14:57 kjeldahl joined #parrot
14:58 pmichaud afk for a bit
15:02 Coke pmichaud++
15:13 Coke 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:14 Coke (so when I tried to add a new one, the count was off.)
15:15 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:17 pmichaud Code vs CodeString issue...?
15:18 treed Cardinal's current testfailures result from some parrot code using String instead of CodeString.
15:18 treed (Sorry, miswrote)
15:18 treed So it tries to call lineof and that fails.
15:19 pmichaud okay
15:19 treed bacek determined that for me last night
15:19 treed Said it looks like a bug in PCT.
15:20 pmichaud I wonder what PCT could be making into a String that it then tries to call .lineof on
15:20 pmichaud PCT normally only calls .lineof on things in Match objects, and those are CodeString
15:20 treed Want the backtrace?
15:20 pmichaud sure
15:21 treed One sec.
15:21 purl one sec is, like, not a long time
15:21 treed Thanks, purl.
15:21 purl bitte treed
15:22 donaldh joined #parrot
15:23 nopaste "treed" at 66.215.91.229 pasted "backtrace for pmichaud++" (17 lines) at http://nopaste.snit.ch/17783
15:24 pmichaud hmmm
15:24 pmichaud that doesn't quite tell me why we got a String in the first place
15:24 pmichaud I think what we'll do though is not generate line number information when it's not available
15:24 * treed nods.
15:24 pmichaud i.e., if .lineof fails, we just ignore it
15:25 pmichaud I'll work on that a second
15:25 treed Cool, thanks.
15:40 particle why is parrotcode.org still live?
15:40 particle there are *OLD* docs there
15:40 particle and sfink still has parrot 0.0.11.2 on cpan
15:40 particle sigh.
15:41 particle this all started with a google search for 'parrot vtable'
15:41 particle the first two links are less than helpful
15:42 particle oh come on!
15:42 purl EVERYBODY TO THE LIMIT!
15:42 particle i can't search for 'parrot pdd', it brings me to http://www.funnyfarmexotics.com/IAS/tpdd.htm
15:42 particle 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).
15:42 particle PDDs are killing parrot. how ironic.
15:44 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 solarion joined #parrot
15:46 dalek parrot: r40928 | pmichaud++ | trunk/compilers/pct/src/POST/Compiler.pir:
15:46 dalek parrot: [pct]:  Compute 'lineof' information only if we can.
15:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40928/
15:46 pmichaud treed:  see if r40928 helps
15:47 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
15:47 japhb excellent
15:47 whiteknight I have a few emails out to people from Lightning and libJIT, and am hunting down links for them
15:49 treed pmichaud: Testing.
15:49 purl rumour has it testing is the best thing ever ZOMG
15:49 particle parrotcode.org should redirect, once everything has been transferred.  i don't know if there's anything left worth saving there
15:49 particle coke: do you still have parrotcode.org admin rights?
15:49 pmichaud how can we know when "everything has transferred"?
15:49 Coke I have svn commit access, probably.
15:49 pmichaud i.e., what's our criteria for that?
15:50 * Coke sighs again at the giant TIME SUCK the transfer away was.
15:50 pmichaud sunk cost, alas.
15:51 pmichaud my suggestion:  Let's assume for the moment that parrotcode.org doesn't have any important information.  If true, we can redirect now.
15:52 pmichaud 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
15:52 purl 1
15:53 hercynium joined #parrot
15:53 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)
15:53 particle ayep
15:54 pmichaud (and that that subversion repo is still accessible)
15:54 particle btw get_repr is listed as a deprecation candidate in pdd17
15:54 particle as it is the same as get_string
15:54 Coke here's the list of what's still out there:
15:54 Coke https://svn.perl.org/viewvc/p​erl.org/docs/live/parrotcode/
15:55 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 pmichaud in particular, I think that get_repr should've produced a string that could recompile back into the original structure
15:55 pmichaud anyway, I'm fine if get_repr dies
15:56 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
15:56 pmichaud it might be worth squirreling away an export of that subdir in case it gets admin'ed out
15:57 particle we could copy the repo to svn.parrot.org
15:57 pmichaud we can do that also, yes.
15:57 Coke if we copy it, then we have one more half dead thign to maintain.
15:57 particle uh, no
15:58 particle we can move the parrotcode repo to parrot.org
15:58 pmichaud for archival, not for maintenance
15:58 particle right.
15:58 Coke I don't see the point.
15:58 pmichaud you don't see value in having archived versions of old stuff?
15:58 particle redirect parrotcode to parrot as a 301
15:58 Coke not that old, no.
15:59 pmichaud hmmm.  why do we keep tagged versions of Parrot 0.0.8 around, then?
15:59 Coke excellent qustion.
15:59 particle tags are cheap. move along.
15:59 pmichaud anyway, I think it's worthwhile and relatively cheap.
15:59 Coke <shrug> if someone wants to go through the trouble, by all means.
15:59 HG` joined #parrot
16:00 particle maybe someone wants to fork an old release of parrot
16:01 Coke I'm more concerned about our current website. particle, any progress?
16:01 particle no progress
16:01 particle i need to generate a csr
16:01 treed pmichaud: New error now, same place.
16:01 treed Method 'iterator' not found for invocant of class 'String'
16:01 particle hoping to get in touch with osuosl now to get access to the box
16:02 pmichaud treed: that's almost certainly an error with Cardinal, then
16:02 pmichaud it's putting a String somewhere that PCT expects a PAST::Node
16:03 treed Huh.
16:03 treed We didn't change anything.
16:03 pmichaud perhaps you can bisect to find out when things broke?
16:03 treed Tried that before.
16:03 treed It was at some parrot revision.
16:03 pmichaud what revision?
16:03 purl revision is 0, unless it's an svn co, then it's whatever svn reports
16:03 pmichaud right
16:03 treed sec'
16:04 treed 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 theory joined #parrot
16:04 treed I assume that means that he bisected all the way back to 40799, and found that the problem manifested at r40824
16:05 pmichaud well, nothing significant changed in pct in that period of time either
16:05 treed Hm.
16:05 * treed looks at the PAST.
16:05 pmichaud have you tried running with the -G option ?
16:07 dalek partcl: r665 | coke++ | trunk/docs/spectest- (2 files):
16:07 dalek partcl: Update spec test progress (NotFound++ for fixing most of our segfaults)
16:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=665
16:07 dalek partcl: r666 | coke++ | trunk/ (4 files):
16:07 dalek partcl: Allow conversion of ints to lists (+add test).
16:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=666
16:07 dalek partcl: r667 | coke++ | trunk/t/cmd_expr.t:
16:07 dalek partcl: Fixup this test file;
16:07 dalek partcl: a failure after test 324 was preventing many other tests from being run.
16:07 dalek partcl: now that we're running them, fix up bugs in the tests.
16:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=667
16:07 dalek partcl: r668 | coke++ | trunk/ (2 files):
16:07 dalek partcl: Don't require whitespace after an alpha operator. (pmichaud++)
16:07 dalek partcl: Add test.
16:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=668
16:08 treed No, what does -G do?
16:09 treed Turn off GC pops out at me.
16:09 pmichaud turns off garbage collection
16:09 pmichaud sometimes that causes strange errors to disappear
16:09 pmichaud whenever I have types mysteriously changing and it looks like "I didn't change anything", I try -G just to see what happens.
16:13 treed Where does -G go? Seems like I can't pass it to cardinal.
16:14 treed (tries to open it as a file)
16:14 * treed runs parrot directly.
16:14 treed Nah, same issue.
16:14 pmichaud okay
16:14 treed And I can't find anything in that PAST output where anything but a PAST node is occupying a spot in the true.
16:14 pmichaud I don't have much idea what might've caused the problem
16:15 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
16:15 treed So is the error occuring after the PAST is generated?
16:15 treed Hm.
16:16 pmichaud it could also be in converting PAST to POST
16:16 pmichaud try --target=post
16:16 treed Completes fine.
16:17 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)
16:17 pmichaud okay
16:17 pmichaud I've had a server fail here -- I have to deal with it first.
16:18 * treed nods.
16:28 jrtayloriv particle, Maybe something like this could solve the issue with diseased birds -- http://parrotsearch.bbbot.net/. Should I further refine it, or you think it won't be useful?
16:30 particle jrtayloriv: http://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 :)
16:31 particle i don't know the details, only that it exists
16:31 particle i don't think i've ever used it, as google rarely fails me :)
16:33 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 jrtayloriv anyhow, thanks for pointing me to that.
16:33 particle thank you for your enthusiasm and your contributions.
16:35 jrtayloriv thanks :) -- I'm enjoying it -- the people here are all very pleasant to work with.
16:35 mokurai joined #parrot
16:36 dalek rakudo: 47a6ae6 | (Solomon Foster)++ | src/setting/Rat.pm:
16:36 dalek rakudo: Add Rat.prefix<->.
16:36 dalek rakudo: Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
16:36 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​7a6ae629ef4f7381983db47d147ea0b431b27e1
17:07 cotto joined #parrot
17:10 cotto good hello
17:16 dalek tracwiki: v2 | whiteknight++ | JITRewrite
17:16 dalek tracwiki: Add inforation I've gathered about Lightning
17:16 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​JITRewrite?version=2&amp;action=diff
17:16 dalek tracwiki: v3 | whiteknight++ | JITRewrite
17:16 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​JITRewrite?version=3&amp;action=diff
17:17 chromatic joined #parrot
17:33 dalek tracwiki: v4 | whiteknight++ | JITRewrite
17:33 dalek tracwiki: Add info about  libJIT that I heard from some of their developers.
17:33 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​JITRewrite?version=4&amp;action=diff
17:35 hercynium joined #parrot
17:37 dalek rakudo: c9a9300 | pmichaud++ | docs/spectest-progress.csv:
17:37 dalek rakudo: spectest-progress.csv update: 435 files, 13245 pass, 0 fail
17:37 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​9a93000b76a9078a60abc82ce1c5fc9a9dc7f72
17:37 dalek tracwiki: v5 | whiteknight++ | JITRewrite
17:37 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​JITRewrite?version=5&amp;action=diff
17:37 dalek tracwiki: v6 | whiteknight++ | JITRewrite
17:38 dalek tracwiki: + small con about libJIT
17:38 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​JITRewrite?version=6&amp;action=diff
17:39 chromatic Almost 700 tests yesterday.
17:39 chromatic Good for the Rats.
17:44 einstein small notification: the certificate of trac.parrot.org has expired
17:45 darbelo joined #parrot
17:50 Topic for #parrotis now HTTPS CERT EXPIRED | http://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:51 Coke ... 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:53 joeri joined #parrot
17:56 einstein ok
18:15 PacoLinux new platform, I have compiled parrot in haiku without problems : http://smolder.plusthree.com/app/pu​blic_projects/report_details/26789
18:15 Coke 16 - 181 -
18:15 Coke 16 - 181 -  8
18:15 purl -173
18:16 Coke excellent!
18:16 purl EGG-see-lent!
18:16 PacoLinux tree months ago was impossible
18:16 Coke PacoLinux: can we get a patch for PLATFORMS ?
18:16 PacoLinux Coke: sure
18:24 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?
18:25 whiteknight It's entirely possible that my blog has misquoted chromatic on occasin
18:25 PacoLinux darbelo: I think is named BFS
18:25 jrtayloriv whiteknight, I got it from a IRC log that you linked to from your blog.
18:25 whiteknight oh, okay then.
18:26 chromatic jrtayloriv, that's exactly what I meant.
18:26 jrtayloriv chromatic, ok thanks
18:26 PacoLinux darbelo: http://en.wikipedia.org/wiki/Be_File_System
18:26 whiteknight jrtayloriv: the idea is that PASM ops will themselves be written in Lorito (Lorito == L1)
18:26 darbelo PacoLinux: does it suport hard links?
18:27 PacoLinux darbelo: I dont know, Im new in haiku
18:30 jan joined #parrot
18:32 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
18:32 whiteknight some people were suggesting that it look like the smalltalk bytecode
18:32 whiteknight any kind of very-low-level LIR should be fine
18:33 whiteknight a small codeset is preferred, but I don't think we need to aim for any kind of crazy minimum
18:35 rbaumer joined #parrot
18:37 chromatic I think we can get away with 128 ops or fewer.
18:38 mikehh treed ping
18:41 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 rbaumer joined #parrot
18:42 treed mikehh: pong
18:43 chromatic Possibly.  I can think of two: those that can call C functions and those that don't.
18:48 mikehh treed - in cardinal
18:48 treed Yeah, replied.
18:54 treed pmichaud: There was a mistake before, the actual parrot commit wherein the issue started is r40788
18:55 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:56 * Coke yays as he finds the bug that caused the regressions.
18:59 chromatic Squeak's slang comes up because they did it well.
19:05 PacoLinux darbelo: I can't find anything about hardlinks (but maybe I dont know where to look) : http://www.haiku-os.org/legacy-do​cs/bebook/BSymLink_Overview.html
19:07 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:08 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:09 cotto joined #parrot
19:11 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:21 donaldh joined #parrot
19:23 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-engi​ne-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:25 darbelo ls
19:26 chromatic Yes.
19:26 darbelo Sorry, wrong window.
19:29 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 #parrot
19:50 whiteknight joined #parrot
19:54 * Coke reclaims another partcl spec test.
19:54 whiteknight yay!
19:55 darbelo Does anyone know of a way to fet at a STRING's encoding without poking into the struct?
19:55 darbelo s/fet at/get at/
19:55 whiteknight darbelo, you mean like an API function to retrieve it?
19:56 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
19:57 darbelo None of the Parrot_str_* funcions there look very promising.
19:58 cotto You can always write one.
19:59 darbelo Ah, I found it, it's string_rep_compatible()
19:59 darbelo Obvious, right?
20:00 TimToady phone
20:02 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.
20:04 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//
20:04 whiteknight yeah, it doesn't need a "rewrite", it needs a "write"
20:04 whiteknight Oh noes! coke beat me to it!
20:05 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.
20:06 cotto It'd be nice if there were something as easy-to-use as ->strstart.
20:07 darbelo Heh. ack for '-Zstrstart' in src/  gives 260+ usages
20:07 darbelo s/Z/>/
20:07 whiteknight ... so what you're saying is that Parrot needs an intern to do repetitive work?
20:09 darbelo Nah, I'm doing that already. What parrot needs is a clean and consistent API for STRINGs.
20:09 whiteknight this is true
20:09 whiteknight feel free to start writing that API as you work
20:09 chromatic Someone should ask Simon about its status.
20:09 Coke please see what simon did first.
20:10 whiteknight whatever whoever did what, we can still start writing API functions now and mark them as experimental
20:10 NotFound joined #parrot
20:10 NotFound hi
20:10 whiteknight hello NotFound
20:11 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
20:11 whiteknight we certainly don't have a working one in trunk
20:11 Coke whiteknight: which is why i said "see what simon did"
20:12 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
20:13 dalek parrot: r40929 | mikehh++ | trunk/src/pmc/packfilerawsegment.pmc:
20:13 dalek parrot: fix codetest failure - trailing spaces
20:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40929/
20:13 dalek partcl: r669 | coke++ | trunk/src/class/tclint.pir:
20:13 dalek partcl: Avoid recursion - don't add our PMC, just our int value.
20:13 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=669
20:13 dalek partcl: r670 | coke++ | trunk/runtime/builtin/uplevel.pir:
20:13 dalek partcl: Clone result to avoid self-referential lists in uplevel.test
20:13 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=670
20:13 dalek partcl: r671 | coke++ | wiki/SpecTestStatus.wiki:
20:13 dalek partcl: This test now runs to completion (+17 spec tests)
20:13 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=671
20:14 whiteknight is github down?
20:14 whiteknight (I finally get around to creating a github account, and it goes down that very day)
20:15 chromatic It's built on Twitter, which is powered by DHH's sense of self satisfaction and axe body spray.
20:16 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. =-)
20:16 whiteknight my gitub brings all the girls to the yard and they're like, "beats svn by far"
20:17 whiteknight Coke: not ignore it, but don't be held hostage by it.
20:18 whiteknight 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.
20:18 Coke just like you wouldn't go write a JIt from scratch.
20:18 Coke We already have an insane amount of NIH in parrot. I'd hate to extend that to things that /other parrot contributors/ did.
20:19 Coke 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
20:20 whiteknight tuits, inclination, and working code are all trump cards
20:20 Coke I disagree in degree. design first, code second.
20:20 Coke so if darbelo has a better /design/, sure.
20:21 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:22 * 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
20:22 Coke darbelo: is there a function that does what you want in PDD28 ?
20:23 whiteknight DARBELO YOU ARENT HELPING
20:23 whiteknight actually, you're very helpful
20:24 NotFound Did we have a strings design?
20:24 * Coke hurls http://news.perlfoundation.org/2008/0​9/parrot_grant_update_for_march.html
20:24 * Coke quotes, "Simon Cozens worked with Allison on the design for character sets and strings (PDD28)"
20:25 NotFound Yeah, a branch no one has looked at for months
20:25 Coke I think the design was in trunk's pdd28.
20:25 Coke If not, that at least should be merged back, as the design was created and reviewed.
20:26 whiteknight I haven't heard anything about that grant in a long time
20:26 darbelo Coke: Just started looking at the pdd now.
20:27 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?
20:27 whiteknight darbelo: yes sir
20:29 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
20:29 particle if anyone notices things in parrot that can only be reached via poking into structs, please ticket them
20:30 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!
20:30 NotFound darbelo: have fun if trying to kill it
20:31 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
20:32 jrtayloriv 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.
20:32 whiteknight moritz: we need to implement a sane API to replace it. Suggestions welcome
20:32 * whiteknight is leaving now. Layer
20:32 whiteknight Later*
20:32 darbelo moritz: My guess: Parrot_str_to_cstring(), and pair it with a Parrot_str_free_cstring()
20:32 jrtayloriv darbelo, (TT #958)
20:32 Coke at least, it was /theoretically/ completed.
20:32 moritz uhm, that's quite a lot work for simple tests
20:33 jonathan moritz: You won't - I'm sure - find strstart in the Rakudo source.
20:33 moritz src/pmc/perl6str.c
20:33 moritz 133:    if (s && s->strstart) {
20:33 moritz 134:        const char *s1         = s->strstart;
20:33 jonathan ...erm, in the bits I wrote...damm.
20:33 jonathan :-)
20:33 moritz that's generated code, I think
20:33 jonathan ah
20:33 jonathan Look at the pmc file
20:33 darbelo if( s ) {
20:34 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
20:34 jonathan Oh well
20:34 jonathan At least it's in a PMC that is meant to be dealing with strings...
20:35 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.
20:35 Coke ISTR that allison signed off on it, for what's that worth.
20:37 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:40 darbelo Coke: (pdd has what I need) Only in the 'deprecated' section :)
20:43 darbelo But I consider using deprecated functions a step above direct struct member access, so it's good enough for me.
20:45 * Coke is very confused.
20:46 Coke compromise?
20:46 purl compromise is that you promise not to change the metaclass
20:46 Coke no, compromise is an agreement that means no one is happy.
20:46 purl okay, Coke.
20:46 NotFound Did we need a deprecation cycle or something to add a new PObj flag?
20:48 * Coke notes that ops2c seems to be generating CONTEXT() ...
20:51 darbelo joined #parrot
20:53 hercynium joined #parrot
20:53 darbelo NotFound: "Never to add, always to remove" is the way I read the current policy.
20:54 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.
20:54 chromatic Not at all.
20:54 Coke I'm sure I was talking about my koohii.
20:54 chromatic ALL existing code MAY have to change.
20:55 chromatic 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.
20:55 NotFound Will 'active' be a good name?
20:56 * 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 #parrot
20:56 NotFound darbelo: I was trying to avoid having to write code that looks like: "Wanted PObj, dead or alive"
20:57 darbelo NotFound: I would advocate the rewrite of fundamental core subsystems, just to allow code like that.
20:58 NotFound darbelo: code like that is a must if we want to catch GC errors
20:59 * darbelo wasn't talking about the error :)
20:59 darbelo find_pmc_dead_or_alive();
21:03 Coke speaking of segfaults.... =-)
21:06 cotto With the proper application of libsigsegv we'll never see a segfault again.
21:07 cotto 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-)
21:07 mikehh ha - wouldn't want to discredit cotto++ but ...
21:10 workbench joined #parrot
21:13 rbaumer joined #parrot
21:18 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40929 - Ubuntu 9.04 amd64 (gcc)
21:18 mikehh also wioth g__
21:19 mikehh that was supposed to be g++ - hit the wrong key - need some sleep cul8r
21:19 NotFound karma g
21:19 purl g has karma of 623
21:19 darbelo g--
21:21 Tene karma g__
21:21 purl g__ has neutral karma
21:21 Tene g__++
21:21 Tene karma g++
21:21 purl g++ has karma of -1
21:21 darbelo karma c
21:21 purl c has karma of 7982
21:21 Tene karma c++
21:21 purl c++ has karma of -86
21:21 darbelo karma c99
21:21 purl c99 has karma of -2
21:21 darbelo karma c89
21:21 purl c89 has karma of 1
21:22 darbelo karma objc
21:22 purl objc has neutral karma
21:23 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.
21:26 cotto karma getting back to work
21:26 purl getting back to work has neutral karma
21:26 cotto clearly
21:27 darbelo (getting back to work)++
21:27 bacek Good morning
21:27 purl And good moroning to you, bacek.
21:27 bacek cotto: found new job?
21:29 * particle heads out for lunch and errands &
21:30 joeri left #parrot
21:31 cotto bacek, funny you should ask.  I just got one today!
21:31 Coke (16+17)/3363
21:31 purl 0.00981266726137377
21:31 Whiteknight joined #parrot
21:31 bacek cotto: congratulations
21:32 cotto It's a good day.
21:32 darbelo cotto: Cool! You can start eating again!
21:32 cotto and I won't have to lean on you so hard for that GSoC kickback
21:33 cotto unrelatedly, did you get your final payment yet?
21:33 Coke hey, I'm starving.
21:33 Coke ->
21:33 cotto <-
21:34 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 #parrot
21:35 beta left #parrot
21:36 workbench joined #parrot
21:45 cotto workbench, owner
21:45 workbench That contained a sentence with fewer than three words.
21:45 cotto workbench, who is your owner
21:45 workbench Factoid 18099926 = (who) (is) (your owner)
21:46 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?)
21:51 jonathan workbench, help
21:51 workbench There's no help for topic 'help'.
21:51 jonathan well that's helpful
21:52 nopaste joined #parrot
22:00 cotto workbench, purl
22:00 purl somebody said workbench was a robot or keeping norris's cock all to himself
22:00 workbench That contained a sentence with fewer than three words.
22:00 cotto purl, antibotsnack
22:00 purl thanks cotto :)
22:03 dngor joined #parrot
22:05 dalek parrot: r40930 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
22:05 dalek parrot: [profiling] split pprof2cg into functions for greater sanity, testing and refactoring
22:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40930/
22:05 theory joined #parrot
22:13 skv joined #parrot
22:30 Coke if we have a nonresponsive bot, we should boot 'im.
22:32 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.
22:32 darbelo it's in src/pmc/string.pmc
22:33 Coke 6651 / 60 / 60
22:33 purl 1.8475
22:36 * 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:37 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:38 darbelo I think that calls for a Parrot_str_replace_grapheme() function.
22:40 darbelo Well, Parrot_str_replace_character(), since the grapheme functions aren't implemented.
22:41 rg joined #parrot
22:41 treed Coke: You could set up a private remote with a post-commit hook.
22:41 treed Push to it to test.
22:42 Coke note that the repo running the 2 hour process is a git-svn repo.
22:42 Coke I had trouble when that was factored in the last time.
22:42 Coke not a huge deal, as I can just work temporarily in a straight svn checkout
22:42 bacek Coke: mkdir tmp; git clone ../orig; ...; git commit; git push
22:44 chromatic I'd make a temporary, short-lived branch.
22:46 dalek parrot: r40931 | bacek++ | branches/context_pmc3/src/jit/i386/jit_defs.c:
22:46 dalek parrot: Partially unbroke jit. Returning values from calls still broken.
22:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40931/
22:47 * 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?
22:47 Coke nope
22:47 bacek ctrl-alt-reset :)
22:47 Coke this library computer must be VERY locked down.
22:47 Coke brb
22:47 darbelo F11?
22:47 purl F11 is, like, mapped to the escape key
22:48 chromatic Hmm, that makes me think I could fix that part of the JIT... but do I want to?
22:49 bacek chromatic: up to you. I've spent about 4 hours on this 3 lines already...
22:50 chromatic My problem is I think it's the WRONG policy.
22:50 chromatic I think Allison's interpretation of our deprecation policy is actively harmful.
22:51 Tene chromatic: would you rather work on that segfault I had from rakudo when trying to use the Mysql library?
22:51 Tene I saw some of that discussion in #ps...
22:51 skv joined #parrot
22:51 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...
22:52 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?
22:52 chromatic It doesn't help anyone, is the problem.
22:52 chromatic Any HLL that uses CONTEXT(interp) directly needs source code review to make sure it won't crash.
22:53 chromatic Someone needs to review all uses of the macro.
22:53 chromatic Every one.
22:53 purl every one is broken
22:53 treed Wouldn't it be reasonable to convene a sort of HLL council which could be asked "Hey, are you guys using this?"
22:53 Tene So... what happens if we just merge it in, fix rakudo, and nobody complains?
22:53 chromatic No, because she's invoking the DarkPAN nuclear argument.
22:53 * treed has no idea what that is.
22:54 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 chromatic Even though THEY HAVE TO MODIFY THEIR CODE ANYWAY.
22:55 * treed isn't terribly enthusiastic about the deprecation policy as it sits.
22:55 NotFound Tene: What Mysql library?
22:55 ruoso joined #parrot
22:55 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
22:55 treed Which don't seem to be required under the deprecation policy as I've seen it.
22:56 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"
22:56 chromatic I can think of several options.
22:56 NotFound Tene: It doesn't work since some changes in nci broke it, I lacked the time to fix it
22:56 * treed would just prefer to see more communication about deprecation.
22:57 duk3leto treed++
22:57 chromatic I'm tempted to release 1.4.1 with only that deprecation notice added.
22:57 treed "This will be marked deprecated." "This is being removed as of $date."
22:57 Tene NotFound: even trying to instantiate a Mysql object from rakudo causes segfaults.
22:57 treed "This is what you use instead."
22:57 NotFound Our deprecation policies have a problem: for example, the random thing, we deprecated and deleted it before having a replacement.
22:58 treed Exactly.
22:58 duk3leto NotFound: hmm, close but not exactly. I had the random dynops written before deleting the random PMC
22:58 treed It needs to be: Propose deprecation. Create alternative, mark as deprecated. Wait a bit, then remove."
22:58 nopaste "tene" at 97.117.70.208 pasted "This segfaults, and the equivalent pir doesn't. NotFound++" (4 lines) at http://nopaste.snit.ch/17787
22:58 treed With the exception of shit that can't do that.
22:58 duk3leto NotFound: but your point still stands
22:58 chromatic Some things just don't work.  JIT for example.
22:58 treed Which maybe should just have a longer guaranteed transition time.
22:58 Coke treed: alternatives are not always necessary.
22:58 Coke we can just say "we're not doing that anymore."
22:59 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.
22:59 Coke NotFound: I thought rand() was added before RANDOM was removed.
22:59 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
23:00 chromatic Yes, we should be a lot better about that.
23:00 duk3leto and other HLL's too, of course
23:01 duk3leto 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.
23:01 Coke NotFound: ah, I see your point. yes.
23:01 duk3leto NotFound: or before ;)
23:01 NotFound "same time" == "same release"
23:01 chromatic I disagree.
23:02 Coke chromatic: certainly it's preferable.
23:02 Coke (er, wait, who are you talking to?)
23:02 duk3leto NotFound: that ties having a solution to deprecating something, which is a lot more work.
23:02 chromatic I'm disagreeing with NotFound.
23:02 Coke I think it would certainly be nice if we had the new API in place before removing the old one.
23:02 bacek We can't adjust our release cycle to release cycles of all HLLs.
23:02 chromatic Sure, but that's not always possible.
23:02 duk3leto NotFound: if we must have a solution before deprecating, JIT would never get fixed
23:03 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.
23:03 duk3leto bacek: no, they should sync up to ours :)
23:03 NotFound Not always, but when is possible it must be the prefered way.
23:03 Tene And who benefits by holding back the context_pmc work?
23:03 chromatic The DarkPAN benefits.
23:03 Coke (in random's case, the problem was the huge delay in deciding on what the replacement should look like. =-)
23:03 duk3leto Tene: not me
23:03 chromatic If it exists.
23:03 Coke I have a hard time believing parrot has a PAN Of any kind.
23:03 bacek Tene: DarkPANers of Parrot...
23:03 chromatic Rakudo doesn't benefit.  Partcl doesn't benefit.
23:04 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 ;)
23:04 chromatic Remember though, we are talking about the EXTERNAL CODE POKING DIRECTLY INTO PARROT DATA STRUCTURES.
23:04 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
23:04 chromatic Our deprecation policy explicitly *disclaims* that we support that.
23:05 * Coke is now getting "Object must be created by a class."
23:05 * Coke thought those were all fixed. :|
23:05 NotFound Note that the auto_attrs in fact can break some code, and we allowed it to pass ;)
23:06 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!
23:06 * Coke wishes the parrot debugger works.
23:06 Coke duk3leto: you were the latest to hack on that, yes?
23:06 bacek duk3leto: it's already there :)
23:06 cotto chromatic++ for that clarification
23:06 duk3leto Coke: yes, I wish breakpoints worked
23:06 NotFound Coke: it works for some value of "works" ;)
23:06 treed A debugger would be so damned handy.
23:07 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.
23:07 NotFound duk3leto: a year ago they worked, but I think only in the simplest pbc's
23:07 chromatic We're two weeks from the next release, right?
23:07 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
23:07 bacek chromatic: something like this
23:07 chromatic Let's just merge the damn branch and be done with it.
23:08 duk3leto chromatic+++
23:08 Tene +1
23:08 purl 1
23:08 * treed wants to be able to stop code at arbitrary points and examine the state of variables.
23:08 treed Which branch is this? bacek's?
23:08 Coke I'm getting that error, I have no idea where in the several thousand lines of tcl I'm running that error is.
23:08 chromatic Yes.
23:08 * treed has no opinion on the matter, other than what he's seen here. If it breaks Cardinal, I'll fix it.
23:08 duk3leto treed: you can examine the state of variables now in the debugger, but you have trace/step manually. no breakpoints :(
23:09 bacek I can do it. Tonight.
23:09 chromatic If we have to yank it before the next release, so be it.
23:09 bacek It's $dayjob time. And it will take some time to sync branch with trunk.
23:09 chromatic We have a repository for a reason.
23:09 bacek But JIT still broken.
23:09 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
23:09 duk3leto or stop at all, for that matter
23:10 treed duk3leto: I didn't know there was a debugger.
23:10 duk3leto treed: ./parrot_debugger
23:10 treed Huh.
23:10 treed Works like parrot, except that it has a debugger interface?
23:10 duk3leto treed: i added mosts of the tests and updated the docs recently. it is still a mess, but basically useable, other than breakpoints
23:10 cotto It'll be interesting once allison gets back.
23:10 duk3leto treed: ./parrot_debugger foo.pir
23:10 treed Neat!
23:11 * treed tries it out.
23:11 chromatic bacek, do you think fixing the JIT will take more than a day or two?
23:11 duk3leto treed: then type "t" to trace a single line of code, or "c" to run everything
23:11 duk3leto treed: p P will print all PMC variable, p N2 will print $N2, etc...
23:11 treed does it start out stopped?
23:11 duk3leto treed: yes
23:11 treed So, I just hit t until I get to where I want to look at it.
23:11 Tene chromatic: wasn't there discussion of dropping JIT?
23:11 duk3leto treed: try doing "t 5" to trace the first 5 instructions
23:11 treed ASsuming that once you hit c, you can't stop it.
23:12 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
23:12 duk3leto treed: yes, currently, c will just run the entire code
23:12 treed Huh.
23:12 bacek chromatic: I have no idea about how JIT works and why it's broken.
23:12 treed It just ran and gave me a backtrace.
23:12 duk3leto treed: please pastebin
23:13 chromatic bacek, given what I've seen so far, I think it's possible to fix.
23:13 treed pastebin what?
23:13 purl pastebin is, like, see nopaste. or see shadowpaste
23:13 treed Or can you not do it with pbc files?
23:13 duk3leto treed: a good backtrace or a bad backtrace ?
23:13 treed It's the normal backtrace that occurs when I try to run it normally.
23:13 dalek partcl: r672 | coke++ | trunk/docs/spectest- (2 files):
23:13 dalek partcl: Passing another 33 tests, with one more file running to completion.
23:13 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=672
23:13 bacek chromatic: it will be good.
23:13 treed The backtrace that I'm trying to debug on cardinal's end.
23:13 duk3leto treed: should work with pbc, i thought there was a test for that
23:13 treed (In the iss41 branch, which has been stagnant for a couple days.)
23:14 treed ../parrot/parrot_debugger cardinal.pbc
23:14 treed Acts just like ../parrot/parrot cardinal.pbc
23:14 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
23:14 treed How do you view registers and whatnot, thougH?
23:14 * treed doesn't know much about parrot internals.
23:15 duk3leto treed: p I0 should print the I0 register
23:15 treed Even in gdb?
23:15 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
23:15 duk3leto treed: oh. not in gdb. viewing regs in gdb is a very good question
23:16 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.
23:16 duk3leto chromatic: git checkout context_pmc ?
23:17 duk3leto chromatic: perhaps git checkout svn/context_pmc
23:17 bacek git checkout context_pmc3_local; git reset --hard remotes/context_pmc3
23:17 bacek git checkout -b context_pmc3_local; git reset --hard remotes/context_pmc3
23:17 duk3leto chromatic: it depends how you set up your git-svn
23:17 Tene chromatic: depends on whether you copied the entire repo or just /trunk
23:17 chromatic [svn-remote "svn"]
23:17 chromatic url = https://svn.parrot.org/parrot
23:17 chromatic fetch = trunk:refs/remotes/trunk
23:17 chromatic branches = branches/*:refs/remotes/*
23:17 chromatic tags = tags/*:refs/remotes/tags/*
23:18 bacek chromatic: you'll probably have to "git svn fetch" before checking out
23:18 Tene git checkout context_pmc3
23:19 chromatic git svn fetch definitely checks out branch commits.
23:19 Tene better would probably be: git checkout -t -b context_pmc3 context_pmc3
23:19 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
23:19 chromatic Ah, I see.
23:20 donaldh joined #parrot
23:22 TonyC joined #parrot
23:22 chromatic I think that's done it.  Thanks.
23:23 bacek chromatic: https://trac.parrot.org/pa​rrot/wiki/git-svn-tutorial "Tracking SVN branches with GIT".
23:23 bacek It's brain-dump of my workflow. Can't be improved, apparently.
23:24 cotto Your brain is perfect.
23:24 * bacek ~~ $dayjob
23:24 bacek cotto: may be. But dump looks ugly enough :)
23:28 dalek partcl: r673 | coke++ | trunk/runtime/builtin/info.pir:
23:28 dalek partcl: make [info exist] work as well as [info exists]
23:28 dalek partcl: Bug introduced with switch to inline'd subcommands.
23:28 dalek partcl: This re-enables at least one spec test file.
23:28 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=673
23:30 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 /
23:33 dalek partcl: r674 | coke++ | wiki/SpecTestStatus.wiki:
23:33 dalek partcl: This test runs to completion now.
23:33 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=674
23:45 skv_ joined #parrot
23:47 Whiteknight joined #parrot
23:49 chromatic Looks like this does it.
23:51 bacek_at_work hi again
23:51 purl oh, you're back!
23:53 davidfetter wb!
23:56 dalek parrot: r40932 | chromatic++ | branches/context_pmc3/src/jit/i386 (2 files):
23:56 dalek parrot: [JIT] Fixed JIT to find the right current_results member in the new Context PMC.
23:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40932/
23:56 chromatic make testj passes on 32-bit Linux for me with that.
23:56 darbelo Merge that sucker!
23:57 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++
23:59 jonathan OH NOES but what if it breaks Rakudo's use of undocumented "APIs"? ;-)
23:59 dalek parrot: r40933 | chromatic++ | branches/context_pmc3/src/jit (4 files):
23:59 dalek parrot: [JIT] Attempted to fix up context accesses for AMD64, PPC, and Sparc JITs as
23:59 dalek parrot: well.  This might be unfruitful, because they probably don't work anyway... but
23:59 dalek parrot: why not try?
23:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40933/
23:59 chromatic Then we rip it out until January 2010.

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced