Camelia, the Perl 6 bug

IRC log for #parrot, 2009-07-10

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 dalek TT #822 closed by coke++: Using wrong libparrot.
00:00 dalek parrot: r39966 | coke++ | trunk/lib/Parrot/Test.pm:
00:00 dalek parrot: When running c-like tests, don't re-invent configuration.
00:00 dalek parrot: Patch courtesy doughera++ (TT #822)
00:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39966/
00:02 pmichaud omg.... removing the cached_type attribute that bacek++ found appears to have cleaned up the gc problems.  Now the question is.... why?
00:02 pmichaud (but let me finish my spectest runs first before we declare victory.)
00:03 pmichaud my 64-bit box is again running the spectests, where it was failing earlier.  afaict the only significant change is the cached_type one.
00:04 bacek_at_work pmichaud: different memory layout :/
00:04 bacek_at_work same problem as changing default hash size to 4 from 16.
00:06 pmichaud right... but so far it appears to have cleared up *all* of them
00:06 chromatic I'll review the commit for anything suspicious.
00:07 pmichaud it seems like it should've been pretty innocuous.  It's an attribute of the ObjectRef PMC, that was always being initialized to PMCNULL, never set or used after that, and not being marked by ObjectRef's mark() vtable
00:09 jrtayloriv joined #parrot
00:14 jrtayloriv joined #parrot
00:15 mikehh make test now PASSes - running make spectest
00:16 patspam joined #parrot
00:17 dalek parrot: r39967 | jkeenan++ | trunk (78 files):
00:17 dalek parrot: Merging darwinhints branch into trunk.  This moves the configuration steps tests to a better directory structure and revises Parrot::Configure::Options::Test::Prepare accordingly.  This is partial progress toward https://trac.parrot.org/parrot/ticket/727.
00:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39967/
00:18 Limbic_Region joined #parrot
00:19 jrtayloriv joined #parrot
00:21 dalek parrot: r39968 | jkeenan++ | branches/darwinhints:
00:21 dalek parrot: Branch has been merged into trunk and is no longer needed at HEAD.
00:21 purl i already had it that way, dalek.
00:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39968/
00:21 dalek parrot: r39969 | jkeenan++ | branches/darwin2hints:
00:21 dalek parrot: Creating branch for 2nd part of work on TT #727.
00:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39969/
00:24 dalek TT #755 closed by jkeenan++: 'make install-dev' assumes "modern" File::Path
00:26 jrtayloriv joined #parrot
00:26 jrtayloriv joined #parrot
00:27 jrtayloriv joined #parrot
00:27 mikehh pmichaud: make spectest FAIL- just two tests - t/spec/S12-attributes/class.rakudo and t/spec/S14-roles/basic.rakudo which PASS the tests then exit with a Segmentation fault
00:28 mikehh had this problem for a while at least with one of the tests
00:28 jrtayloriv joined #parrot
00:28 pmichaud mikehh: what os/distro/platform?
00:28 mikehh but all the tests actually PASSS
00:28 mikehh Ubuntu 9.04 amd64
00:29 pmichaud okay.  I've got a couple of x86 failures.
00:29 pmichaud I'm waiting for my 64-bit run to finish.
00:30 pmichaud I get failure in t/spec/S32-array/end.t and t/spec/S32-array/elems.t on 32-bit
00:36 pmichaud in 64-bit I get the same failures you just mentioned
00:36 mikehh just that one change (src/pmc/objectref_pmc.template) moved from 14202 passing to 14373 passing
00:36 patspam joined #parrot
00:38 pmichaud Yes, but I agree with bacek++ that it's just because the memory layout changed, not because we fixed the key bug.
00:43 jrtayloriv joined #parrot
00:44 brooksbp joined #parrot
00:45 mikehh pmichaud: it looks to me like its the type of error caused by an off by one bug
00:47 jrtayloriv joined #parrot
00:47 nopaste joined #parrot
00:48 TonyC joined #parrot
00:54 bacek_at_work pmichaud: if you'll have time can you review https://trac.parrot.org/parrot/changeset/39960/ ? (it's stealing of quoting from Rakudo to NQP)
00:56 pmichaud bacek_at_work: I'll make time a bit later.  I agree that we'll need a deprecation cycle for "..."
00:56 bacek_at_work pmichaud: ok.
00:57 pmichaud we might also need one for <xyz abc>
00:57 pmichaud although hopefully nobody was using that.
00:58 pmichaud the patch is missing tests.
01:04 bacek_at_work (tests) I start adding tests in next commits.
01:18 TiMBuS joined #parrot
01:21 NotFound joined #parrot
01:44 skids joined #parrot
02:38 Austin cotto: ping
02:39 dalek close: r65 | Austin++ | wiki/TocCloseProgrammingLanguage.wiki:
02:39 dalek close: Created wiki page through web user interface.
02:39 dalek close: review: http://code.google.com/p/close/source/detail?r=65
02:39 dalek close: r66 | Austin++ | wiki/CloseIntro.wiki:
02:39 dalek close: Edited wiki page through web user interface.
02:39 dalek close: review: http://code.google.com/p/close/source/detail?r=66
02:44 dalek close: r67 | Austin++ | wiki/TocCloseProgrammingLanguage.wiki:
02:44 dalek close: Edited wiki page through web user interface.
02:44 dalek close: review: http://code.google.com/p/close/source/detail?r=67
02:45 Austin purl msg cotto I think I told you the other night that GoogleCode was using SVN 1.4, so merge tracking support was unavailable. That was based on out-of-date docs (theirs). According to their wiki, they've since moved on to svn 1.5, so merge tracking *is* available on GoogleCode projects.
02:45 purl Message for cotto stored.
02:45 Austin Moo.
02:45 Austin purl?
02:45 purl Austin?
02:45 Austin WTF, no purl?
02:46 Austin Ahh, just slow.
02:48 janus joined #parrot
02:49 dalek close: r68 | Austin++ | wiki/TocCloseProgrammingLanguage.wiki:
02:49 dalek close: Edited wiki page through web user interface.
02:49 dalek close: review: http://code.google.com/p/close/source/detail?r=68
02:49 dalek close: r69 | Austin++ | wiki/TocCloseProgrammingLanguage.wiki:
02:49 dalek close: Edited wiki page through web user interface.
02:49 dalek close: review: http://code.google.com/p/close/source/detail?r=69
02:54 dalek parrot: r39970 | jkeenan++ | branches/darwin2hints/config/init/hints/darwin.pm:
02:54 dalek parrot: Inline comments re plan of attack.
02:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39970/
02:56 Andy joined #parrot
03:34 dukeleto joined #parrot
03:43 dukeleto joined #parrot
04:13 hiroyuki_y joined #parrot
05:05 cotto Austin, I think you were talking to someone else.
05:14 dalek parrot: r39971 | pmichaud++ | trunk/src/runcore/trace.c:
05:14 dalek parrot: [core] Fix a bug in the tracing runcore that would throw an exception
05:14 dalek parrot: "Attempt to do sub operation on non-Sub." whenever a RetContinuation
05:14 dalek parrot: or Continuation were encountered in the trace output.  Since continuations
05:14 dalek parrot: aren't Sub PMCs in the first place, I removed this misfeature altogether
05:14 dalek parrot: (and thus (Ret)Continuations are now displayed like any other PMC).
05:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39971/
05:14 dalek parrot: r39972 | pmichaud++ | trunk/runtime/parrot/library/PGE/Perl6Grammar.pir:
05:14 dalek parrot: [pge]:  Fix duplicate identifier in Perl6Grammar bug (TT #772)
05:14 dalek parrot: Patch courtesy bacek++ .
05:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39972/
05:16 dalek TT #772 closed by pmichaud++: [BUG] Duplicate identifier in PGE;Perl6Grammar.compile
05:18 dalek parrot: r39973 | pmichaud++ | trunk/src/pmc/exceptionhandler.pmc:
05:18 dalek parrot: [core]:  Make sure ExceptionHandler PMC calls its parent class in mark().
05:18 dalek parrot: Reported by bacek++ .
05:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39973/
05:27 dalek parrot: r39974 | cotto++ | branches/ops_pct/compilers​/opsc/compiler/actions.pm:
05:28 dalek parrot: [opsc] switch back to a normal PAST::Block for per-op info; most processing will be done by the runcores
05:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39974/
05:41 bacek_at_work cotto: how is your interview?
05:45 cotto exhausting
05:45 cotto I talked with 4 people over the course of 6 hours.
05:45 cotto I think I'll get an offer, but I also have to think carefully about accepting it.
05:46 cotto It sounds like a nice job, but it wouldn't give me much in the way of dev experience and it sounds like I'd need to jump through some hoops to use OSS.
05:47 cotto I'm also talking with a local Perl (and Ruby, apparently) shop for a job I'd much prefer.
05:47 cotto but for now, it's opsc hacking tiem
05:47 cotto *haxx0ring
05:48 cotto btw, have you looked at the way OpFile.pm does control flow instruction mangling?
05:49 cotto I don't see much point in switching to an intermediate form like it uses, but a second opinion wouldn't hurt.
05:50 cotto (bascially, it goes "expr OFFSET(X)" -> "{{^+X}}" -> runcore-specific final form)
05:52 bacek_at_work I don't see any reasons to do first step in processing.
05:53 cotto ok.  I think it was there because the code handles nested parens specially, but it seems like more work than is necessary.
05:54 Theory joined #parrot
06:02 bacek_at_work cotto: agree
06:04 cotto I need to figure some stuff out about the current code, especially how dynops work.
06:05 cotto Blindly reimplementing the existing code is a recipe for pain.
06:23 uniejo joined #parrot
06:24 iblechbot joined #parrot
06:26 mokurai joined #parrot
06:32 bacek_at_work cotto: all dynops go through "C" core (slow/fast) only
06:36 cotto really?  There's code generated that appears to work with the other runcores
06:46 bacek_at_work look at wrapper__
06:50 cotto That obviates a bunch of generated code.
06:57 cotto good night
07:05 bacek_at_work cotto: good night
07:14 dalek rakudo: 02d0ed2 | pmichaud++ |  (2 files):
07:14 dalek rakudo: Replace string-based typecheck with class-object based typecheck.
07:14 dalek rakudo: This appears to avoid the -G bugs for Rakudo, which appear to occur
07:14 dalek rakudo: due to something going wrong when do_dispatch (written in C) calls
07:14 dalek rakudo: !bindability_checker (PIR) which calls typeof_s_p opcode which
07:14 dalek rakudo: calls the 'name' vtable function which itself happens to be
07:15 dalek rakudo: overridden in PIR via a :vtable flagged sub.  Or something like that.
07:15 dalek rakudo: Anyway, we once again see that using string names as class identifiers
07:15 dalek rakudo: leads to trouble.  (Bad coder!  No biscuit!)
07:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​2d0ed20644bfe92a104f32efc7e6a48a8fabfa5
07:21 bacek_at_work pmichaud++ # niice commit message! :)
08:02 ewilhelm joined #parrot
08:05 ewilhelm http://github.com/notbenh/euler_bench/tree/master -- #pdx.pm is trying to get the benchmarking thing rolling
08:05 ewilhelm euler problems are much more approachable than the shootout ones
08:08 hiroyuk__ joined #parrot
08:09 chromatic joined #parrot
08:12 mikehh codetest FAIL at r39974 - All others PASS (pre/post config, smolder, fulltest) - Ubuntu 9.04 amd64 (PATCH to come)
08:13 nopaste "mikehh" at 90.209.117.228 pasted "codetest failure at r39974 (lib/parrot/Test.pm) PATCH follows" (31 lines) at http://nopaste.snit.ch/17197
08:13 nopaste "mikehh" at 90.209.117.228 pasted "PATCH for codetest failure at r39974 (lib/parrot/Test.pm - codetest PASSes after PATCH)" (15 lines) at http://nopaste.snit.ch/17198
08:15 dukeleto joined #parrot
08:17 clunker3 joined #parrot
08:18 dalek parrot: r39975 | fperrad++ | trunk/lib/Parrot/Test.pm:
08:18 dalek parrot: [codingstd] remove hard tab
08:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39975/
08:21 dalek parrot: r39976 | fperrad++ | trunk (16 files):
08:22 dalek parrot: [config] add a step for thread
08:22 dalek parrot: and a new option --without-threads
08:22 dalek parrot: see TT #815
08:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39976/
08:24 dalek TT #815 closed by fperrad++: Add a step for Configure:  auto::thread
08:29 donaldh joined #parrot
08:38 dalek parrot: r39977 | fperrad++ | trunk/include/parrot/atomic.h:
08:38 dalek parrot: [cage] remove useless define PARROT_HAS_NATIVE_ATOMIC
08:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39977/
08:47 pmichaud I'll be up again in just a few hours
08:53 * chromatic wishes for a make tags-vi target in Rakudo.
09:07 bacek joined #parrot
09:11 mokurai left #parrot
09:13 bacek o hai
09:17 MoC joined #parrot
09:20 whoppix_ joined #parrot
09:32 TiMBuS joined #parrot
09:35 szbalint ewilhelm: excellent
09:35 szbalint I thought about that too, but I didn't want to make the Euler solutions publicly accessible
09:36 szbalint but yeah, parrot + rakudo desperately needs some benchmarking points of comparison
09:56 bacek joined #parrot
09:59 mikehh All tests PASS (pre/post config, smolder, fulltest) at r39977 - Ubuntu 9.04 amd64
10:04 donaldh left #parrot
10:11 iblechbot joined #parrot
10:24 bacek msg chromatic Latest MPB post has some html tags mess...
10:24 purl Message for chromatic stored.
11:13 jimmy joined #parrot
11:20 donaldh joined #parrot
11:50 whoppix joined #parrot
12:07 bacek joined #parrot
12:37 masak joined #parrot
12:41 jimmy joined #parrot
12:41 Whiteknight joined #parrot
12:42 Whiteknight good morning #parrot
12:43 jimmy good morning, Whitenight
12:44 skids joined #parrot
13:11 clinton joined #parrot
13:20 whoppix joined #parrot
13:23 dalek TT #824 created by fperrad++: [CAGE] refactor MSVC SAL with Configure
13:44 gron joined #parrot
13:47 NotFound There is some reason to call Parrot_str_free in Class.isa_pmc ? Looks like is freeing string header that don't even are his propoerty.
13:47 gron hello, looks like parrot has already come quite a successful, hope I am right here to ask some questions about the experiences with parrots design and especially its approach with PASM
13:49 gron i am currently looking into different VMs to get an idea about the general issues with bytecode design
13:49 gron parrot seems to support already a lot of stuff at this level, for instance file operations and continuations
13:50 Andy joined #parrot
13:50 gron if there is anyone here who can point me to an experience report on the benefits of this approach, I would be very grateful
13:53 skids_ joined #parrot
13:57 jsut_ joined #parrot
13:57 Whiteknight gron: I don't think any such report exists
13:57 Whiteknight although it's probably a good idea to put together some sort of retrospective about our design
13:59 gron yes, unfortunately it does not seem like there are any research publications about parrot out there, even though you have a somehow unusual/new approach
14:00 gron what do you think is the general feeling about it, does it pay of in terms of simplicity for implementing languages on top of it
14:01 skids joined #parrot
14:01 gron and does it allow to gain performance for all kind of languages with a common jit?
14:02 NotFound gron: you can take a look at this: http://www.linux-mag.com/cache/7373/1.html
14:05 Coke Austin: ping
14:06 gron well, a nice read, but still, missing the evaluation part i would be interested in, some "hard" facts, benchmarks, or some lessons learned
14:07 Coke msg Austin it was coke you were talking to, not cotto.
14:07 purl Message for austin stored.
14:08 gron very interesting is the last statement thought "plans on experimenting with concurrency features" my personal interest is in bringing concurrency instructions to the bytecode level, i.e., STM/thread&locks/message-passing
14:08 Coke gron: that's the theory. I would posit there are some... implementation hurdles to overcome before that's a reality.
14:08 Coke (regarding the JIT)
14:09 pmichaud NotFound: I totally agree -- I don't think Class.isa_pmc should be calling Parrot_str_Free.
14:10 NotFound pmichaud: in fact looks like this is the only usage of that function in the reo.
14:10 NotFound repo
14:10 ewilhelm szbalint, do you think we need a "spoiler alert" for the euler problems?  I think I've seen several other repositories of solutions
14:11 pmichaud NotFound: I agree with you there also.
14:11 pmichaud I'm going to remove it and see if that resolves our gc problem in Rakudo.
14:11 pmichaud It seems very likely -- the problems we have all seem to have to do with "isa" checks.
14:12 NotFound pmichaud: I've done it. With rakudo from yesyerday's git I have the 'succ' problem.
14:12 NotFound After a git pull, is running spectest now without problems.
14:12 NotFound The funny thing is that yesterday I wasn't having the problem.
14:12 pmichaud well, overnight I made a change to rakudo that should've gotten rid of the 'succ' problem
14:13 pmichaud however, moritz++ is reporting a problem in his environment -- one moment
14:13 pmichaud h
14:13 pmichaud 09:21 <moritz_> pmichaud: http://nopaste.snit.ch/17199
14:13 NotFound Anyway, all parrot test pass with those calls removed. Maybe somone must make some check with valgrind to be sure.
14:14 pmichaud Given that these are the only occurrences of Parrot_str_free() in the entire repo, I think we're pretty safe in assuming they shouldn't be there.
14:14 szbalint ewilhelm: I don't think spoilers are that big of a deal, it's a learning exercise anyway, so if someone cheats they are only cheating themselves.
14:14 pmichaud STRING* reclamation is normally handled by GC, not by explicit free
14:15 szbalint The shootout exercises suck, but the Euler ones aren't that much better either, they're all maths
14:15 NotFound pmichaud: looks like an attempt of premature optimization.
14:15 szbalint no I/O or data manipulation on a large scale
14:17 szbalint I think it's beating around the bush really. Behind a lot of the shootout tests the benchmark is really measuring looping constructs and some very basic mathematical operations
14:17 szbalint so imo what would be more useful is testing those constructs directly - but then it's hard to equate them across different languages
14:19 NotFound The rakudo spectest is the only task that has put at full speed the fans of my new system for a now X-)
14:20 mikehh pmichaud: I got two new failures with spectest - would you like me to paste the results?
14:21 pmichaud mikehh: yes, please
14:21 mikehh 4 test with problems - two with the seg fault and 2 others
14:22 szbalint ewilhelm: I have about ~50 p5 solutions for Euler btw, want me to commit some? If so, just hit me with a commit bit - szbalint@github
14:23 nopaste "mikehh" at 90.209.117.228 pasted "rakudo spectest failures" (129 lines) at http://nopaste.snit.ch/17203
14:24 pmichaud actually, in looking at Class.isa_pmc, why-why-why are we doing string comparison of classnames in the first place?!
14:24 pmichaud 07:15 <dalek> rakudo: Anyway, we once again see that using string names as class identifiers
14:24 ewilhelm szbalint, if you want to, fork and send a pull request to notbenh. I think that's how he likes it
14:24 pmichaud 07:15 <dalek> rakudo: leads to trouble.  (Bad coder!  No biscuit!)
14:24 szbalint ewilhelm: oh ok, makes sense
14:27 NotFound pmichaud: both isa and isa_pmc in Class do things that looks unreasonable to me,
14:28 pmichaud I think we should be able to get rid of lines 1295-1314 altogether.  I'm going to try that on my system.
14:33 pmichaud mikehh: thanks for the spectest report -- very helpful.
14:35 mikehh pmichaud: I will try and keep it up - at the moment looking at the seg fault problem
14:36 pmichaud the segfault-on-exit?
14:36 mikehh #yes
14:38 mikehh don't know where the # came from - but yes the seg fault on exit
14:41 mikehh from t/spec/S12-attributes/recursive.rakudo and t/spec/S14-roles/basic.rakudo - pass all the tests say "# FUDGED " then Segmentation fault
14:45 pmichaud okay, looks like we need 1295-1314 because of classnames in other hlls
14:46 pmichaud I'm guessing we don't need the str_free though
14:57 pmichaud Oops, I forgot to credit NotFound++ in my commit message.  :-(
14:57 pmichaud I'll make it up in another one.
14:57 dalek parrot: r39978 | pmichaud++ | trunk/src/pmc/class.pmc:
14:57 dalek parrot: [core]:  Class.isa_pmc should not be forcibly freeing STRING* values
14:57 dalek parrot: it doesn't own.  ("... we once again see that using string names
14:57 dalek parrot: as class identifiers leads to trouble.")
14:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39978/
14:58 NotFound pmichaud: no problem, I'm not a buddhist ;)
14:59 NotFound Generalizing, *no one* should free STRING * values, we have a GC and must let it take care.
15:00 Theory joined #parrot
15:14 Whiteknight using string names as class identifiers is only trouble if you can't learn to ignore all the problems it causes
15:14 Whiteknight maybe you just need to become more tolerant of massive crashes and performance problems
15:14 Whiteknight :)
15:14 Coke pmichaud: I think your recent fix to class isa just fixed a few TTs and lets partcl's branches/convert_tcllist work.
15:14 Coke (that's one of my attempts to eliminate a PMC and replace it with a class.)
15:16 pmichaud Coke: Thanks, but it's really NotFound++'s fix
15:16 pmichaud although I have some more related fixes possibly on the way
15:16 pmichaud It's going to bug me that isa checks create a ton of gc-able objects
15:16 pmichaud (actually, it does bug me.)
15:17 Coke working first, fast later.
15:17 Coke but yes.
15:17 Coke I already create a ton of pmcs in my HLL, I don't need parrot doing it too. =-)
15:17 Coke (pmc=pmc||string)
15:18 pmichaud if you stop and think that every :multi()  ultimately does isa checks, you get an idea of the cost.
15:18 Coke our entire PCC system bothers me from that standpoint (using strings to manage our signatures)
15:18 pmichaud those bother me less, because (I think) they're relatively constant pmcs
15:19 Coke I imagine there are a lot of efficiencies possible, in either case.
15:19 pmichaud I could be wrong there
15:19 Coke I hope it's not just my imagination.
15:19 pmichaud In the case of isa checks, I know that they're GCables created at runtime
15:19 Coke but we had enough false starts with faux-efficiency.
15:19 pmichaud and for deeply subclassed items, they're O(n**2)
15:20 pmichaud so something tht is five subclasses deep from its root will produce O(32) gcables
15:20 Coke If only we had something... like... integer-based class ids... =-)
15:20 * Coke ducks.
15:20 pmichaud wait, O(25)
15:20 pmichaud Coke: we do.
15:20 pmichaud the address of the class object is effectively its class id
15:20 donaldh joined #parrot
15:21 pmichaud what is killing us is legacy code that used to rely on string comparisons (and now applications and libraries that depend on that legacy)
15:21 Coke pmichaud: I was referring to the old $I0 = typeof "foo" syntax, but if we have something effective we can use under the covers, sure.
15:21 pmichaud right
15:21 dalek partcl: r522 | coke++ | branches/convert_tcllist/runtime/ (2 files):
15:21 dalek partcl: cleanup duplicate PIR var names.
15:21 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=522
15:21 pmichaud we do use the class object address under the covers
15:21 Coke pmichaud: make sure they're deprecated and we can rip them out in 2 weeks.
15:22 pmichaud Coke: alas, it really requires a design decision from the architect, I think
15:22 Coke You can open an RFC, anyway.
15:22 Coke or ping allison directly.
15:22 purl I can't find allison in the DNS.
15:22 Coke ping purl
15:22 purl I can't find purl in the DNS.
15:22 Coke ping your butt
15:22 purl I can't find your in the DNS.
15:22 Coke purl--
15:22 purl Coke: excuse me?
15:23 Coke ${ purl-- }
15:23 Coke pmichaud: yup. that branch now works. whee.
15:24 Coke NotFound++
15:24 Coke pmichaud++
15:24 pmichaud That gives me confidence that it's the ultimate source of the Rakudo bugs as well, if similar problems were being observed in tcl
15:24 pmichaud I didn't know tcl was having troubles there -- what tickets?
15:24 hercynium joined #parrot
15:25 pmichaud (I want to read up and see if there are any other ramifications we might not have thought of yet)
15:27 Coke https://trac.parrot.org/parrot/ticket/776 for one, though that's not the branch I was just testing.
15:28 pmichaud yes, that seems likely.
15:28 pmichaud The problem came about anytime a constant string PMC was being used in isa checks.
15:28 Coke trying that branch now.
15:29 ruoso joined #parrot
15:29 NotFound Good, it was looking very strange to me that such an anomaly were not actually breaking things :)
15:30 Coke Whiteknight: https://trac.parrot.org/parrot/attac​hment/ticket/218/new_label_ops.patch seems to be on the wrong ticket.
15:30 pmichaud NotFound: I suspect that there aren't many cases where String PMCs get used to identify classes, except (inadvertently) in HLLs
15:30 Whiteknight Coke: no, that's right
15:30 Whiteknight that's a patch for the first deprecation stage of a multi-stage solution
15:31 NotFound Anyway, if the fix makes work things that were broken, I'm sure it was as wrong as it looked.
15:31 pmichaud yes, freeing the strings directly was definitely wrong.
15:31 pmichaud I'm carping against the design now :-)
15:32 Coke pmichaud: nope. 776 is still broken.
15:32 NotFound Yes, better to fix the design than trying to make it faster with scary tricks.
15:33 Coke still, another branch is working, so yah.
15:33 Coke one down.
15:35 pmichaud It's a long-standing carp.  Like, since summer 2007, I think.
15:37 dalek joined #parrot
15:37 NotFound I think we must deprecate that unuseful and confusing function from the string api.
15:38 NotFound Or even better, kill it immediately.
15:39 cotto If you want to deprecate something, now's a really good time to do it.
15:47 dalek joined #parrot
15:47 NotFound Too bad, Parrot_str_free is mentioned in pdd28.
15:48 NotFound I'll write a RFC ticket, then.
15:55 dalek TT #825 created by jrtayloriv++: PATCH: Fix incorrect references in pdd22
15:56 pmichaud arrrrrrrrrgggggggggggggghhhhhhhhhhhhhh!
15:57 nopaste "pmichaud" at 72.181.176.220 pasted "arrrrrrrrrgggggggggggggghhhhhhhhhhhhhh!" (19 lines) at http://nopaste.snit.ch/17205
15:58 pmichaud This code currently runs and outputs "1".  Arguably it should not do that, but that's a design decision.
15:58 pmichaud That's not the source of my "argh".
15:58 pmichaud in the isa line, $P0 is a String PMC
15:58 dalek TT #826 created by NotFound++: Deprecate Parrot_str_free
15:58 NotFound pmichaud: yes, I was looking at isa test and wondering the same-
15:58 pmichaud we then eventually find ourselves in Class.isa_pmc, to see if the object isa "XYZ"
15:59 pmichaud in Class.isa_pmc, we call Parrot_oo_get_class passing the "XYZ" String PMC as the class we're looking for
15:59 pmichaud Parrot_oo_get_class can't find a class by that name in the namespace (XYZ is in a different HLL), but it is able to find "XYZ" in the classhash
15:59 pmichaud so then...
15:59 purl so then is the poe chat server using somepropriety code written just for it?
16:00 pmichaud so then... since it's able to find an entry for "XYZ" in the classhash, Parrot_oo_get_class CONSTRUCTS A PMCPROXY FOR THE foo;XYZ CLASS AND RETURNS IT!
16:00 NotFound Uh, I didn't realize that!
16:01 pmichaud so now we have PMCProxy objects being created for PIR classes   B-(
16:01 NotFound Now I understand the  arrrrrrrrrgggggggggggggghhhhhhhhhhhhhh!
16:04 darbelo joined #parrot
16:06 particle1 joined #parrot
16:07 Psyche^ joined #parrot
16:13 Coke msg purl forget so then.
16:13 purl Message for purl stored.
16:13 Coke whoops. =-)
16:38 Whiteknight well I think it's pretty obvious that PMCProxy objects are not being used in a disciplined way
16:38 pmichaud what's the easiest way to go from a type number to the corresponding class object?
16:39 pmichaud (in C, of course)
16:43 Whiteknight i have no idea, I've wondered about that myself
16:43 Whiteknight I would assume interp->vtables[typenumber]->class_ or something
16:43 Whiteknight I can't remember all the names of things
16:43 pmichaud that's not quite sufficient
16:43 Whiteknight and that might return a PMCProxy too I think
16:44 pmichaud I know it doesn't return a PMCProxy
16:44 Whiteknight not sufficient, but definitely fast
16:44 pmichaud that _class member of vtables is.... weird.
16:44 Whiteknight yay weirdness!
16:44 pmichaud it doesn't ever point to what I expect it to hold.
16:44 pmichaud same for namespaces
16:44 Whiteknight anytime we find "is weird" in one of our explanations, we should immediately start a branch and kill it
16:46 mokurai joined #parrot
16:47 Infinoid my int $foo is weird;
16:50 Whiteknight KILL IT!
16:52 Austin What is the official position of PMCs w.r.t. classes. Are PMC's considered classes?
16:52 Whiteknight no
16:52 Whiteknight a Class is a type of PMC
16:52 pmichaud There's not a consistent official position (more)
16:53 pmichaud the best explanation is that PMCs are types
16:53 Whiteknight PMCs are a type of doodad from which classes and other thingies are made
16:53 pmichaud there are two special types of PMCs known as "Class" and "Object", and those are used as the basis for classes created from PIR (e.g., via newclass or subclass)
16:54 Austin Okay. But I want to talk about classes, not types.
16:55 Whiteknight then you're looking at the Class PMC and the Object PMC
16:55 Austin If I call P6object's new_class with parent => SomePmcType, it sort of works.
16:55 pmichaud right
16:55 Whiteknight that's like magic
16:55 Austin Except that P6object wants me to talk about ::parrot::SomePmcType
16:55 pmichaud what happens is that Parrot constructs a PMCProxy object that acts like a Class interface to the underlying PMC representation
16:55 Whiteknight right, it's smoke and mirrors
16:56 pmichaud P6object wants the leading "parrot" because all PMC types end up in the 'parrot' namespace
16:56 pmichaud which is likely different from your current .HLL namespace
16:56 Austin So as I understand it, PMC names are visible everywhere -- that is, if I set namespace=FOO and HLL=Howard, I can still say "$P0  = new Iterator"
16:56 pmichaud that's currently the case, yes.  That may be deprecated.
16:56 pmichaud (if it's not deprecated already)
16:56 Austin Okay. That seems schizophrenic.
16:57 pmichaud officially,    'new "Iterator"'  is supposed to look only in the current HLL
16:57 Austin Really?
16:57 Whiteknight because you could overload it locally
16:57 pmichaud Yes, really.
16:57 Whiteknight ORLY?
16:57 purl YA RLY.
16:57 Austin Okay.
16:57 Whiteknight SRSLY
16:57 Austin So should PMCs be part of the namespace tree?
16:57 pmichaud if you want to be sure to get the parrot iterator, it's     root_new ['parrot';'Iterator']
16:58 pmichaud PMCs are currently part of the parrot namespace tree, yes.
16:59 Austin Are they?
16:59 Whiteknight well...sort of
16:59 pmichaud Yes.
16:59 Austin If you can just ask for one by shortname, they're not really namespace-ified, are they?
16:59 Whiteknight I don't know if they are actually "in" the namespace
16:59 Whiteknight so much as they are searchable from there
16:59 pmichaud They're actually "in" the namespace.
16:59 Austin WhiteKnight: they are
16:59 Whiteknight okay, that's fine too
16:59 pmichaud If you add a method to  ['parrot';'Integer'], then all 'Integer' objects get that method.
17:00 Austin You can query the root namespace for symbols, and get them back.
17:00 pmichaud er, all Integer PMCs get that method.
17:00 pmichaud Austin: the ability to ask for PMCs by shortname is the thing I mentioned that is likely deprecated.
17:01 pmichaud officially,   new 'Iterator'   is supposed to find the class/type associated with the 'Iterator' namespace in the current hll_root
17:01 Austin So perhaps I should ask two questions: (1) should PMCs be in the root namespace, instead of some other nsp; and (2) should shortname go away, or by replaced by a "system"?
17:02 pmichaud where PMCs belong is an open question at the moment.  Currently they all go into 'parrot' hll_root
17:02 pmichaud shortname doesn't need to go away, it just needs to be more rigorous
17:02 Austin By rigorous, you mean hll-mapping?
17:02 pmichaud currently there are some legacy pieces to keep the existing (incorrect) uses of shortname working
17:04 pmichaud currently, if I do     new 'Iterator'  in some HLL other than Parrot, and that HLL doesn't have its own 'Iterator' class, then the class lookup function falls back to searching for something named 'Iterator' in the classhash and then tries to get the class object for that
17:04 pmichaud it's the "fall back" operation that needs to be eliminated
17:04 PerlJam Does all PMCs going into 'parrot' hll_root mean that there could be collisions between 2 HLLs?
17:04 Austin Is that what's causing some of your proxy woes?
17:04 pmichaud Austin: yes.
17:05 pmichaud PerlJam: it does, but there would be collisions (at the C level) anyway
17:05 pmichaud if I try to create my own PMC named "Integer" or "TclInteger", then I'm going to have a conflict long before we ever reach the namespace :-)
17:05 Austin pmichaud: How so, shouldn't dynamic pmcs go into the hll root, or wherever?
17:06 pmichaud Austin: currently the C function names are tied to the non-HLL PMC name
17:06 pmichaud so I suspect there would be linker conflicts.
17:07 Austin Ahh. And there's no way to map from C-name to "string we pass to parrot" ?
17:07 pmichaud although, now that I'm looking at it, it appears that the vtable functions are all "static" at least.
17:07 pmichaud So perhaps that's not a collision.
17:07 Austin Cool.
17:07 pmichaud at any rate, there are undoubtedly a variety of collisions that will occur in the current design.
17:07 pmichaud beyond just the clobbering of the namespace.
17:08 pmichaud My personal opinion is that per-HLL PMCs probably belong in the hll namespace or hll-private namespace
17:08 pmichaud but that's not likely to happen, and even if we had that there are likely to be other problems that have to be resolved before it can work.
17:08 pmichaud (not likely to happen *soon*, that is)
17:09 Austin pmichaud: thanks.
17:10 pmichaud but this is part of the reason why Rakudo's PMCs are all called "Perl6Foo" instead of just "Foo".  For example, we can't have a "Scalar" PMC because that name is already taken.
17:10 pmichaud so we use "Perl6Scalar"
17:10 Austin Yeah, I wondered about that.
17:10 pmichaud and then P6object does various tricky things to make it look like "Scalar"
17:11 buildbot joined #parrot
17:12 chromatic joined #parrot
17:16 dalek close: r70 | Austin++ | wiki/CloseIntro.wiki:
17:16 dalek close: Added intro section on hll and namespace directives.
17:16 dalek close: review: http://code.google.com/p/close/source/detail?r=70
17:16 dalek close: r71 | Austin++ | wiki/CloseIntro.wiki:
17:16 dalek close: Edited wiki page through web user interface.
17:16 dalek close: review: http://code.google.com/p/close/source/detail?r=71
17:27 Tene pmichaud: check out what I just ran on Parrot: http://imgur.com/kgDVS.png
17:27 pmichaud niiiiiice
17:27 particle tene: written in?
17:28 nopaste "tene" at 24.10.252.130 pasted "Little dialog utility source, could use some OO and abstraction..." (78 lines) at http://nopaste.snit.ch/17206
17:28 Tene particle: PIR, for now.  I'm just wrapping the 'Elementary' library from the enlightenment guys.
17:28 pmichaud not bad!
17:29 particle never heard of it.  not bad at all
17:29 Tene The only issue right now is the signature that its callbacks use...
17:29 pmichaud well, if anyone can tell me how to get from a type number to the corresponding namespace or class object, that'd be a huge help
17:29 pmichaud otherwise I'll just write an email to parrot-dev describing the current sub-optimalness and let someone else deal with it.
17:29 chromatic Hm, I wonder if r39351 was the source of succ woes in Rakudo.
17:30 Tene pmichaud: isn't it $I0 = classobj.'type'() ?
17:30 pmichaud Tene: in C
17:30 Tene Ah.
17:30 pmichaud Tene: from a type number
17:30 pmichaud chromatic: we've been seeing succ woes in rakudo for weeks
17:30 Tene Oh, I misread.
17:31 chromatic Five weeks?
17:31 pmichaud no, just about that long
17:31 pmichaud let me look at 39351
17:31 dalek close: r72 | Austin++ | trunk/src/parser/ (2 files):
17:31 dalek close: Refactored adverbs away from declarations
17:31 dalek close: review: http://code.google.com/p/close/source/detail?r=72
17:32 pmichaud chromatic: I think it's the change that introduced the Parrot_str_free() into Class.isa_pmc
17:32 pmichaud (which I took out earlier)
17:33 chromatic I disagree; I think that papers over a bug.
17:33 pmichaud Why would Parrot_str_free() be correct?
17:33 chromatic Because the name of the class should always be a *copy* of the STRING containing the class's name.
17:33 chromatic Otherwise anything can modify it.
17:33 pmichaud yes, but it's "copy" in the COW sense, yes?
17:34 pmichaud nothing in the isa_pmc code appears to be making a copy of it
17:34 pmichaud and in this case we're not modifying the string anyway, are we?
17:34 chromatic That's because the get_name vtable entry is responsible for making the copy.
17:34 pmichaud oh
17:35 chromatic Otherwise anything that gets the name of a class can modify that name in place.
17:35 pmichaud anyway, I'm after two bugs at the moment, then (more)
17:36 Tene pmichaud: the only way I see to do it is to walk the interp->class_hash
17:36 pmichaud first, I don't think that isa_pmc should be using strings to check class identity in the first place.  As written now, every failing isa check results in $n*($n-1) GCables, where $n is the number of parent classes
17:36 Tene pmichaud: look at src/oo.c lines 730 to 735
17:36 pmichaud Tene: doesn't interp->class_hash just give me the type number?  I already have that.
17:37 chromatic Sure, I agree with not using strings for class identity.
17:37 pmichaud chromatic:  the second bug will then be fixing the VTABLE_name that I know of that doesn't return a copy of the name
17:38 chromatic That may be the PIR version.  Sigh.
17:38 pmichaud correct.
17:38 pmichaud it didn't occur to me that VTABLE_name would need to return a copy of the name.
17:38 pmichaud although I'm not entirely convinced that's our bug in rakudo's case, because rakudo doesn't modify strings in place
17:39 pmichaud (they're treated as immutable for the most part)
17:39 chromatic Who knows what happens elsewhere?
17:39 pmichaud agreed
17:39 pmichaud otoh, I'm pretty sure I disagree with using Parrot_str_free on the strings.
17:39 pmichaud that really would explain why things were being collected prematurely whenever 'isa' was called.
17:40 chromatic Indeed.
17:40 pmichaud anyway, if we can avoid the strings altogether, it'll be a huge win.
17:41 pmichaud did you see my analysis above about the extra pmcproxy objects being created?
17:41 chromatic I haven't backlogged yet.  I will.
17:41 pmichaud I can describe it here
17:41 pmichaud given
17:41 pmichaud $P0 = box 'Foo'
17:41 pmichaud $I0 = isa $P99, $P0
17:41 pmichaud we eventually get to Class.isa_pmc
17:42 pmichaud that in turn calls Parrot_oo_get_class   in order to get the class corresponding to 'Foo'
17:42 pmichaud if 'Foo' was defined in another HLL namespace
17:42 pmichaud then the initial lookup for 'Foo' fails, and we look for 'Foo' in the classhash
17:42 pmichaud we find it there, so we get its type number
17:42 urkle joined #parrot
17:42 pmichaud and then create a PMCProxy for that type
17:42 pmichaud and return that back to isa_pmc
17:43 pmichaud note that this results in creating a PMCProxy for a class that was created in PIR
17:43 chromatic That last sentence surprises me.  The rest doesn't.
17:44 pmichaud assume 'Foo'  was created as     $P0 = newclass 'Foo'
17:44 pmichaud the rest of what I said above holds.
17:45 pmichaud I wonder if a possible solution is to make sure that PIR-defined classes don't get entered in the classhash.  I wonder what would break.
17:46 chromatic May I suggest, tongue in cheek, leaving that as idle curiosity for just under two weeks?
17:47 pmichaud as in "don't even try it", or as in "don't commit it"?
17:47 chromatic The latter for sure.
17:48 pmichaud so, along the lines of "don't open boxes you aren't sure you want to be looking into"?  ;-)
17:49 chromatic More "I don't want to think about tracking down the implications before 1.4"
17:51 pmichaud it looks like disabling src/oo.c:743 would be sufficient to test it :-)
17:51 pmichaud and that function only appears to be called for PIR classes
17:52 pmichaud anyway, I'm certainly going to wait until at least after lunch to try anything like that
17:53 pmichaud oh, hmmm.
17:53 pmichaud I don't actually need to go from the type number to a class object, I just need to be able to figure out if the type number corresponds to an instance of type Class
17:54 pmichaud oh, wait. false.
17:54 pmichaud I do need the class object.
17:54 pmichaud grrr.
17:54 pmichaud oh well.
17:54 pmichaud lunchtime -- bbl
17:54 Tene So, if I can figure out how to write a custom library to invoke callbacks for me with an extra parameter... I can make this work.
17:56 iblechbot joined #parrot
17:59 Tene Making a .so that calls into Parrot functions is a bit beyond my c-fu
18:07 cotto pmichaud, opsc needs to process all .ops files into one past.  What's the best way to get a PCT-based compiler to do this?
18:16 Tene So, anyone feel up to helping me get a modified version of Parrot_callback_C into a .so as is referred to in pdd16?
18:16 NotFound chromatic: the strings that were str_free'd come from VTABLE_get_string, so you can't be sure that they can be freed unless we completely forbid inherit from the Class PMC.
18:17 chromatic Yes, but they have to be COW strings coming from VTABLE_get_string, otherwise anything can modify the Class's name *in place*.
18:17 chromatic THAT is the bug.
18:19 NotFound Anyway, I don't see the point for explicitly free things, suppossedly we let the GC take care of that.
18:20 chromatic I agree; it's just a performance hack.
18:21 chromatic But if these strings aren't safe to free there, we have a deeper problem elsewhere.
18:21 Whiteknight joined #parrot
18:21 chromatic Sometimes STRINGs need pass-by-reference semantics.  Sometimes they need pass-by-value semantics.
18:22 NotFound If we wont to check that we can fill his content with some identifiable garbage. That way the result will not be strange GC fails.
18:22 chromatic If you get a Class's name, manipulate it, and change what the Class thinks its name is at a distance, you have a bug because you have reference semantics where you wanted value.
18:22 chromatic True, that would be an easy test to write.
18:23 NotFound We can make class name strings RO, and make better checks of RO in all string modifying functions.
18:24 chromatic I don't know how to make RO strings.
18:24 NotFound I think several functions lack that check.
18:25 NotFound Actually we have no way, given that al string internals are exposed and used.
18:25 NotFound Well, constant, not RO.
18:25 chromatic Constant (now) doesn't mean you can't modify it.
18:28 jdv79 joined #parrot
18:29 NotFound Then what PObj_constant_FLAG means?
18:30 chromatic The GC won't sweep it.
18:32 jdv79 am i the only one that the phrase "...seems to change
18:32 jdv79 the memory layout such that..." scares?
18:33 particle all code changes potentially change the memory layout of a process
18:33 jdv79 well, i left off the part about it "fixing some failures"
18:33 jdv79 that's what i was getting at
18:34 particle gc bugs are hard.
18:34 particle gigeresque
18:36 chromatic Imagine solving differential equations topologically to try to prevent the Great Old Ones from breaking through and eating the moon, and you have some idea of the problem.
18:37 NotFound Let them eat the moon, we hae electric light ;)
18:37 chromatic Electricity comes from moonbeams.
18:37 jdv79 i guess i don't understand enough to grasp why its so hard.
18:38 chromatic Imagine you want to know "Which memory objects in my system am I currently using?  Which ones am I not using?"
18:38 chromatic How do you figure that out?
18:39 NotFound jdv79: because minimal changes in unrelated parts of the code can make the bug have no visible effect, or fails in strange ways.
18:39 jdv79 i get the general gist of it.
18:39 chromatic For every simple answer to that, there's a complication.
18:39 jdv79 i think NotFound is more onto what i mean
18:39 jdv79 i guess if i tried to chase a gc bug i'd learn alot
18:42 Whiteknight if we pretend it doesn't exist, things are easier
18:42 Whiteknight but the string system being so poorly encapsulated has always bugged me
18:42 Whiteknight (along with the poor encapsulation of nearly every other subsystem)
18:43 jdv79 is there a goal for subsystem boundry defining or hardening?
18:43 Whiteknight not a written one, no
18:43 Whiteknight but that would still be quite a nice thing to do
18:44 cotto Using only the STRING API would mean a lot of changes, not that they'd be unwelcome.
18:45 NotFound The problem is to keep parrot working in the process
18:45 Whiteknight well, the GC API got completely redone a while back and parrot still works
18:45 Whiteknight ...mostly
18:45 Whiteknight (actually, the GC is probably a bad example right now)
18:48 Whiteknight in either case, it should be easy to keep Parrot working through the process
18:48 cotto Is there some way we could write tests that would expose bugs if the GC didn't do exactly the right thing rather than maybe exposing brokenness like this?
18:48 chromatic For the get_name bug, yes.
18:48 Whiteknight cotto: that's quite a good question
18:49 chromatic Loop through the core types (and any language core types), instantiate objects, get their names, modify those strings, look them up by name.
18:49 Whiteknight We have some GC tests, but obviously not enough
18:49 Whiteknight what would be nice is an introspection interface where we can take a value and determine if the GC thinks it's alive or dead
18:50 Whiteknight so create some classes and objects, call "collect" several times in a loop, and then go through to verify that every property and string and associated value is not collected
18:50 Whiteknight interp.'is_collected', or even an
18:50 NotFound Whiteknight: I'm almost sure that no one touched gc internals just to open a file. With strings, we do that.
18:50 Whiteknight is_collected op or dynop would be nice
18:52 Whiteknight I can tell you that nobody is touching GC internals anywhere, at least not as of a few weeks ago
18:53 * Whiteknight has to host a remote desktop session and it would be bad if they saw me chatting on IRC. So...later.
18:56 cotto pmichaud, ping
18:56 cotto actually, unping.  It's lunchtime.
18:57 jdv79 maybe Whiteknight or someone else knowledgable in gc affairs could writeup some useful tests/metrics/whatever.
18:58 jdv79 i mean do a writeup describing them.  not code them.
19:09 pmichaud cotto: unpong
19:16 pmichaud 18:07 <cotto> pmichaud, opsc needs to process all .ops files into one past.  What's the best way to get a PCT-based compiler to do this?
19:16 pmichaud PCT::HLLCompiler supports a --combine option that says that multiple input files are to be treated as a single source
19:19 athomason joined #parrot
19:22 darbelo cotto: ping
19:44 bacek joined #parrot
19:49 darbelo msg cotto Remember those failing tests I metioned to you? Forget about them. It's the library that's feeding us the wrong result.
19:49 purl Message for cotto stored.
19:50 Whiteknight joined #parrot
19:50 * darbelo trimmed that message to half of it's original length just by removing the word "fuck" and it's derivatives.
19:51 Whiteknight d(fuck)/dt?
19:52 * Whiteknight is going to read the logs now to see what he missed
19:52 Whiteknight irclogs?
19:52 purl irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
19:54 Whiteknight jdv79: I'll see if I can write something up tonight
20:12 dalek lua: b334705 | fperrad++ |  (2 files):
20:12 dalek lua: handle ambiguous function call
20:12 dalek lua: review: http://github.com/fperrad/lua/commit/b3​34705ddcf67b8f53d3dabfb6bdf17b06c0cf5e
20:22 allison joined #parrot
20:28 Whiteknight good afternoon allison
20:28 allison hi Whiteknight
20:30 Whiteknight We've been seeing lots of interested new users recently, it's really quite exciting
20:35 allison Whiteknight: excellent!
20:35 * purl zwooshes
20:36 Tene allison: if I have a C function in a .so that accepts Parrot data types (PMC, interp, etc), should I still be loading it with dlfunc to call?
20:36 Tene Or is there a better option?
20:36 Tene I think i might be doing something wrong here. :)
20:37 allison Tene: the only other option is to statically compile it into parrot
20:37 allison Tene: so, depends if it's core or not
20:38 allison Tene: it's not you that's wrong, it's C, which is decidedly *not* a dynamic language :)
20:38 donaldh joined #parrot
20:38 Tene allison: specifically, I'm trying to write some C that build a callback for a function with more than two args.
20:39 allison Tene: mmm... which dlfunc won't do, since it has two fixed signatures
20:39 Tene So it's a modified and renamed Parrot_make_cb
20:39 allison (for callbacks)
20:39 Tene it's not dlfunc that won't load it, it's new_callback that won't work with it.
20:40 Tene and new_callback just calls Parrot_make_cb
20:40 Tene The issue is that it calls vtable functions, which require the interpreter, and I'm not sure I'm passing that correctly.
20:41 Tene I just did a $P0 = getinterp, and passed that as the first argument.
20:43 brianwisti joined #parrot
20:43 Tene allison: can you tell me what the nci sig should be for "Parrot_Interp interp, Parrot_PMC sub, Parrot_PMC user_data, Parrot_String cb_signature"?
20:44 NotFound Tene: I think there is a signature letter that automatically pass the current interpreter as first argument.
20:44 cotto pmichaud, thanks.  I was hoping there'd be something like that.
20:44 Tene NotFound: It looked like it might have been 'J', but when I tried J, it failed.
20:44 allison Tene: J is the interpreter argument
20:44 Tene Ah, yes, it does work.
20:45 Tene i mus thave done something wrong earlier.
20:45 NotFound Tene: I think I had some test, but in a computer that I don't have connected now.
20:45 NotFound Ah, good.
20:46 allison Tene: I want to say JPPS
20:46 Tene My function is being called correctly now.  I still get segfaults when it tries to call the callback, though...
20:46 Tene allison: it returns a PMC... so PJPPS ?
20:46 allison Tene: aye
20:46 NotFound I can't help with that, didn't even started to understand the callback mechanics.
20:47 allison Tene: the callbacks are *very* restrictive
20:47 Tene allison: so if I can make this work by patching Parrot, that's something valid to commit?
20:48 allison Tene: maybe, depends on the patch
20:48 Tene Okay. :)
20:49 allison Tene: it may be a simple matter of modifying your code to use the callback interface as it expects
20:49 Tene allison: I'm wrapping a native library
20:49 allison Tene: but if it is an actual bug in the callback code, then yes, patches welcome
20:50 pmichaud what's the purpose/meaning of  .PARROT_CLONE_CLASSES when dealing with interpreters and threads?
20:50 Tene The library requires that callbacks have signature "*user_data, *object, *event_info"
20:52 Tene allison: I got this gui library working for creating windows and widgets, but I can't do anything with it until I get callbacks working: http://imgur.com/kgDVS.png
20:53 Tene pmichaud: you running into that ASSERT fail now too?
20:53 allison pmichaud: whether cloning an interpreter clones all the user-defined classes too
20:53 pmichaud Tene: no, I'm trying out a patch that eliminates string comparisons for doing isa checks
20:53 pmichaud allison: afaict, that flag just controls the cloning of the class_hash itself, not the actual classes.
20:53 pmichaud i.e., the classes aren't cloned.
20:54 pmichaud or if they are, I'm not sure when/where it happens.
20:54 Tene pmichaud: tt757 documents a fail with CLONE_CLASSES that is related to string comparisons, iirc.
20:55 pmichaud Tene: I'm not getting the assert failure, no.
20:56 allison pmichaud: cloning hashes used to be a deep copy
20:56 pmichaud allison: they still are
20:56 pmichaud I think what has changed is that the class_hash now hold type numbers instead of pointers to class objects
20:56 allison pmichaud: mmm... that could be
20:57 allison pmichaud: so they're never truly cloned
20:57 pmichaud I'm very unfamiliar with the class_hash, fwiw.  But the only places I see it used, it's getting and setting integers
20:57 pmichaud the CLONE_CLASSES flag seems to cause the new interpreter's clash_hash to have all of its entries deleted.
20:58 pmichaud *class_hash
20:58 pmichaud in eliminating string checks for isa membership, everything passes except this one test in threads.t
20:58 pmichaud which appears to be related to CLONE_CLASSES
20:59 chromatic That doesn't surprise me.  I don't think it's ever worked.
20:59 pmichaud which is doing funny things to the destination's class_hash
20:59 pmichaud so I'm wondering if I can todo/skip that test, or otherwise not worry about the one error from my patch
21:00 pmichaud (2015-1778)/2015
21:00 purl 0.117617866004963
21:00 pmichaud 11% speedup
21:00 pmichaud (for rakudo's spectest)
21:01 chromatic Seems about right.
21:01 pmichaud as well as getting rid of the string manipulation bogosity in isa_pmc
21:01 chromatic +1 to todo the test; I don't believe it worked robustly.
21:02 donaldh chromatic: your nci optimizations broke my nci :-/
21:02 chromatic On x86?
21:02 chromatic 32-bit?
21:02 chromatic JIT enabled?
21:02 donaldh chromatic: I'll explain.
21:02 Whiteknight allison: are the callbacks restricted by design, or can they be made more usable?
21:02 donaldh 'V' is broken in JIT.
21:03 Tene Okay, I've got my callback called. :)
21:04 donaldh So I had a patch applied from RT #551 to force JIT to fallback to generated thunks for any NCI signature containing a 'V'
21:04 allison Whiteknight: they're restricted by design, but it's not my design, it's much older. At some point we'll do a thorough review and revise on NCI.
21:04 donaldh I think your optimizations have totally defeated that by removing all the generated thunks when CAN_BUILD_CALL_FRAMES is enabled.
21:05 allison Whiteknight: (mmm... but not this week)
21:05 Whiteknight allison: no worries, I'm just trying to get an idea about long-term roadmap items
21:06 donaldh The problem is that nobody has managed to fix JIT for 'V' signatures. I have a work in progress on that, but have far too little time.
21:06 chromatic donaldh, we can reenable those thunks; that's no problem.
21:06 chromatic Give me a patch with a failing test case and I'll make it happen.
21:08 donaldh tests 66, 69 and 70 are disabled in t/pmc/nci.t
21:08 Tene allison: would it make any sense to add verify_CD in src/interp/inter_cb.c to PARROT_EXPORT ?
21:09 chromatic donaldh, I'll take a look.
21:09 donaldh https://trac.parrot.org/parrot/atta​chment/ticket/551/donthandle.patch is the patch to not handle 'V' in JIT.
21:10 allison Tene: isn't it only used internally by a callback?
21:10 donaldh The patch re-enables the tests in t/pmc/nci.t
21:11 Tene allison: pdd16 recommends writing your own callback function when you need to handle more than two arguments, and the easiest way to do that is to just call the same thing that the parrot builtin callbacks call.
21:11 pmichaud I think I'll submit my patch as a ticket, to let others get a chance to review it.  As it stands now it seems to evoke a few Rakudo failures, which makes me think it's not a likely candidate for inclusion before 1.4
21:11 pmichaud (unless I can figure out exactly where those failures are coming from)
21:12 pmichaud (the Rakudo failures all deal with Roles.)
21:13 bacek joined #parrot
21:13 bacek Good morning, #parrot
21:13 allison Tene: it does seem to make sense to have a public interface way to do that
21:14 allison Tene: though, it should be something like Parrot_nci_handle_callback
21:14 Tene Hmm.  I added PARROT_EXPORT to it, and I'm still getting undefined symbol errors... :(
21:14 allison Tene: you'd have to remove 'static', and rerun the headerizer
21:14 Tene ah
21:16 allison Tene: does Parrot_callback_C or Parrot_callback_D not work for you?
21:17 allison Tene: they're pretty much just public interface functions for verify_CD
21:17 Tene allison: The library that I'm wrapping calls its callbacks with *three* arguments.
21:17 Tene oh, you mean call one of those instead.
21:18 Tene Yeah, I could do that.
21:18 allison Tene: instead of calling verify_CD directly, aye
21:18 Tene Clever.
21:18 NotFound allison: Can you take a look at TT #826?
21:18 Tene Yay, failed assertion!
21:19 allison NotFound: sure
21:19 allison Tene: in the number of arguments?
21:19 Tene src/interp/inter_cb.c:389: failed assertion 'external_data'
21:20 Tene dunno what that means yet.
21:20 Tene it's failing the ARGIN(char *external_data)
21:20 Tene I passed a void *
21:20 chromatic and it's NULL
21:21 Tene Yeah, looks like.
21:22 Tene If I fudge it and pass "oh noes" instead, I get a PANIC: callback gone to wrong interpreter
21:27 allison NotFound: comment added to TT #826, I'm in favor
21:28 NotFound allison: ok, but I don't think is so important to maintain a behavior that is just an attempt of optimization.
21:29 allison Tene: did you store the interpreter as an '_interpreter' key of your user_data PMC?
21:30 donaldh joined #parrot
21:30 donaldh chromatic++
21:30 allison NotFound: aye, but an inconsistent deprecation policy isn't much use in reassuring users
21:30 Tene allison: I just copied Parrot_make_cb, which does do that.  Could this have something to do with the runloop boundaries and pcc stuff?
21:30 allison NotFound: and, we're talking 2 weeks of delay, hardly painful
21:31 Tene If I comment out that assert... it just does nothing at all.
21:31 NotFound allison: not so important to discuss it too much time, certainly.
21:32 allison Tene: potentially, are you running multi-threaded?
21:32 allison Tene: and, make sure the interpreter you stored actually had a value
21:32 Tene No, I haven't done anything with threads.  I'm not sure whether the library I'm using uses threads or not, but that shouldn't matter.
21:33 allison Tene: what it's doing there is checking that the current interpreter is the same object as the one stored in the "_interpreter" key
21:33 * Tene nods.
21:33 allison Tene: so, if nothing is stored, you get the same error as if a different interpreter object is stored
21:34 allison NotFound: but we do want to make sure to get the deprecation notice in before 1.4
21:34 Tene is a PMC_IS_NULL check sufficient?
21:35 allison Tene: sufficient as a replacement for the interpreter object pointer comparison? Or?
21:35 NotFound allison: we can discuss it at #ps, if not having some more +1 before
21:36 Tene allison: "make sure that the interpreter I stored actually has a value"
21:37 allison Tene: aye, PMC_IS_NULL is a good first check
21:37 Tene That passes fine.
21:37 allison Tene: if it's not null, check that the object that was stored was of type Interpreter
21:38 allison Tene: or base_type enum_class_ParrotInterpreter
21:39 dalek parrot: r39979 | bacek++ | branches/tt761_keys_revamp/src (7 files):
21:39 dalek parrot: Bah
21:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39979/
21:39 clunker9_ joined #parrot
21:40 bacek Looks like I screwed my git-svn checkout...
21:46 Tene allison: looks like it's a Parrot_Null ?
21:47 allison Tene: stored in "_interpreter"? that's not good
21:47 Tene at least by the time it gets to callback_CD
21:47 allison Tene: but it does explain why it doesn't match the current interpreter
21:47 allison Tene: mmm... yeah, makes you wonder where it's getting lost
21:47 Tene Rather.
21:48 Tene What would I get if I ran getprop on something that had never been setprop'd?
21:48 Tene Would I get a Null?
21:48 allison Hmmm... potentially
21:49 allison Tene: yes
21:49 Tene I figured CONST_STRING wouldn't work in my .so, so I used Parrot_str_new_constant, which was the first reasonable-looking thing I came across.  Would that work properly here?
21:49 dalek parrot: r39980 | bacek++ | branches/tt761_keys_revamp/src (7 files):
21:49 dalek parrot: Revert previous commit.
21:49 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39980/
21:49 chromatic Tene, yes.  It's mostly the same thing, just not at compile time.
21:49 allison Tene: getprop in the default PMC runs a set of standard checks, then returns PMCNULL
21:51 allison Tene: maybe put in some debug checks earlier in the code to see if you can pin down the last point where you had a real interpreter object
21:52 Tene It's definitely an interpreter when I set it.
21:53 Tene Can I get to properties from gdb easily?
21:53 allison what happens between that point and the point the callback is run?
21:53 allison Tene: aye, you can call vtable functions from within gdb
21:53 allison Tene: you just can't use the fancy macro syntax
22:02 Tene hmm...
22:05 Tene How do I assign to a variable and run a function from within gdb?
22:06 allison Tene: assign to a variable?
22:06 Tene Eh... bad choice of wording.
22:06 allison Tene: running a function is just like typing an extra line of C code
22:07 Tene Trying to run Parrot_default_getprop() gives me "Undefined command"
22:07 allison Tene: the annoying thing is that you can't use VTABLE_getprop(interp, pmc)
22:07 Tene Ah, nm, I didn't say what to do with it.
22:08 allison Tene: you have to unroll it to: (pmc)->vtable->getprop(interp, pmc, key)
22:09 Tene Ah.
22:09 Tene My problem was leaving off the 'p' on the front.
22:09 Tene off
22:12 Tene In my callback helper, it's definitely set.  Later on, it's definitely not.
22:12 Tene ... ><
22:13 Tene I wasn't calling it with the same user_data.
22:13 Tene Okay, now it's making it far enough to schedule the callback, but it never actually gets run.
22:14 dalek parrot: r39981 | bacek++ | branches/tt761_keys_revamp (85 files):
22:14 dalek parrot: Bring branch up-to-date with trunk.
22:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39981/
22:15 allison Tene: that's progress
22:16 Tene and... the problem was that my callback was trying to run a non-existant sub.
22:16 Tene dlfunc/setglobal the sub, and everything works.
22:16 Tene :D
22:17 Tene Well, FSVO "everything"
22:17 Tene I still can't pass the event info, because it's null.
22:18 Tene I need to find something to wrap it in...
22:18 Tene I could stuff it all in a Parrot Hash, I guess. :)
22:19 Tene :/ and it still doesn't work when i let it schedule a run, but it does when I force it to be synchronous.
22:19 Tene ... but then when I ^C Parrot, all of the scheduled callbacks run at once.
22:20 Tene So, yes, I guess it must be synchronous.
22:20 allison Tene: events are run when certain "safe" opcodes are run
22:21 allison Tene: or at cleanup
22:21 Tene yes, which won't happen here, because the program is in the library's runloop at the time.  I can set a _synchronous property, though.
22:21 Tene so that it's always run synchronously.
22:21 Tene for my callbacks
22:22 allison Tene: makes sense
22:27 Tene And to wrap stuff in a hash...
22:27 Tene ... I don't have an interp in the cb_helper
22:27 Tene ... unless I pull it out of the user_data!
22:30 Tene ... but to do that, I need an interp!
22:30 Tene allison: any ideas?
22:31 allison Tene: where are you losing the interp?
22:31 allison Tene: you're passing the interp into the original function call?
22:32 Tene allison: the C callback is called only with my user data and some library data.
22:32 allison Tene: aye, and expects the interpreter passed in as "_interpreter"
22:32 allison Tene: (attached to user_data, I mean)
22:33 nopaste "tene" at 24.10.252.130 pasted "C interpreter for Allison++" (5 lines) at http://nopaste.snit.ch/17211
22:33 Tene allison: Yes, it's attached to user_data, but I don't know how to get it out without already having an interpreter.
22:33 allison Tene: ah, I see, yes
22:34 allison Tene: yes, you need an interpreter to call a vtable function on the object to get the interpreter
22:36 rg joined #parrot
22:42 Tene I could always cheat and shove the interp in a global. ;)
22:49 kid51 joined #parrot
22:56 Limbic_Region joined #parrot
23:00 Whiteknight joined #parrot
23:01 allison Tene: mmm... but globals are stored in the interpreter
23:01 allison Tene: or, a C global?
23:01 Tene Yes, a C global.  I'll think about othe roptions.  I don't really need those args for now...
23:02 allison Tene: another option would be expanding the possible callback signatures
23:02 Tene The only issue left is that this program segfaults randomly on startup, even with -G.
23:02 Tene I have to try it several times to get it to actually run.
23:02 Tene once it's started, it runs fine, and it always runs perfectly in gdb.
23:03 Tene I'm really pleased.  This is fun.  :)
23:03 allison Tene: :)
23:03 allison Tene: non-gdb-able segfaults are annoying
23:05 Tene especially nondeterministic ones.
23:06 Tene core dump!
23:06 purl core dump is not the problem.  the three thousand lines later is the problem. or SEVEN LAYER BURRRRRRRRRRRRRRRRRITO
23:06 Whiteknight Tene: what's the program?
23:06 purl rumour has it the program is too big
23:06 Whiteknight purl forget the program
23:06 purl Whiteknight: I forgot program
23:07 nopaste "tene" at 24.10.252.130 pasted "The Program for whiteknight++" (118 lines) at http://nopaste.snit.ch/17212
23:07 chromatic sudo echo 0 > /proc/sys/kernel/randomize_va_space
23:08 Tene segfault is in strlen
23:09 skids joined #parrot
23:09 Tene It's not in Parrot, it's in the library I'm using.
23:09 Whiteknight oh great
23:10 Tene That's SO COOL.
23:13 Tene But no, seriously, I've been wanting some nice gui libs on Parrot for a while.  Now to write some OO wrappers...
23:13 Tene gonna try to work on Curses this weekend too.
23:14 Tene allison: is there any part of this that you'd like me to document?  If so, where?
23:15 allison Tene: heh, nice (external segfault)
23:15 allison Tene: how about docs/pir/using_nci.pod?
23:16 nopaste "tene" at 24.10.252.130 pasted "helper file for allison++" (70 lines) at http://nopaste.snit.ch/17213
23:17 Tene allison: the second C function in that file woudl be useful in Parrot somewhere to support using C callbacks with more than two args
23:17 Tene the sync variable should probably be an argument.
23:18 Tene Wait... hm.  Depends on whether there's a way to get the function pointer in there as an arg too.
23:18 Tene I couldn't quite figure out if I could get that from an NCI object or not.
23:18 Tene I don't reall yunderstand the issues in F2DPTR
23:19 allison Tene: aye, looks like something like that could be a useful addition
23:20 Tene I'll try to get it cleaned up, abstracted, work out C function pointers from PIR... looking at my track record on following through, though, I'm not hopeful. :)
23:22 allison Tene: hey, whatever you manage to collect into a ticket increases the chances of someone else working on it
23:22 allison Tene: no stress
23:26 Tene Oh, right!  Tickets!
23:26 Tene Clever.
23:28 Whiteknight yay tickets!
23:28 * Whiteknight installed trac at work, and is up to his armpits in tickets
23:28 Tene AFK shopping.
23:30 Whiteknight I'm looking for a list of systems or subsystems that need better encapsulation
23:30 Whiteknight I've got the strings system and the Contexts subsystem, any others that are in desperate need?
23:31 mikehh_ joined #parrot
23:31 Whiteknight and it doesn't have to be C either, messy Perl libraries would make great projects for this too
23:31 chromatic I thought we'd pointed you at something else first.
23:32 Whiteknight oh, this isn't for me, I'm writing up a blog post of small tasks for new hackers to get involved with
23:32 Whiteknight and encapsulating messy interfaces seems like a good task for people to get started on
23:32 chromatic I had one in mind, but I've forgotten it now.
23:33 Whiteknight bacek was working on keys/hashes, that was the other big one I was thinking about
23:34 Whiteknight okay, I'll put that post off for now, maybe ask about it on list
23:35 Whiteknight so what am I supposed to be working on right now?
23:36 * Whiteknight has too many projects up in the air to remember which one is most pressing
23:36 Tene AIO, iirc from your blog?
23:36 Whiteknight Tene: that's something I *want* to do, but not necessarily something I *need* to do before the release
23:36 elmex joined #parrot
23:36 Tene Ah, right.
23:37 Whiteknight after the release I'm going through some deprecations like a tornado
23:38 chromatic Delete you like a hurricane.
23:39 Whiteknight sometimes I like deleting code as much as I like writing it
23:42 Whiteknight so what am I doing now? Still tracking down that GC bug?
23:42 Tene I wonder if my GC bug is still around...
23:45 Whiteknight I don't like tracking down rakudo bugs because rakudo takes so long to build and test
23:50 dalek parrot: r39982 | jkeenan++ | branches/darwin2hints/t/ste​ps/init/hints/darwin-01.t:
23:50 dalek parrot: Create some tests for _precheck().
23:50 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39982/

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

Parrot | source cross referenced