Parrot 1.3.0 "Andean Swift" released | parrot.org
Set by moderator on 23 June 2009.
dalek TT #822 closed by coke++: Using wrong libparrot. 00:00
rrot: r39966 | coke++ | trunk/lib/Parrot/Test.pm:
When running c-like tests, don't re-invent configuration.
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
(but let me finish my spectest runs first before we declare victory.)
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:03
bacek_at_work pmichaud: different memory layout :/ 00:04
same problem as changing default hash size to 4 from 16.
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.
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:07
00:09 jrtayloriv joined 00:14 jrtayloriv joined
mikehh make test now PASSes - running make spectest 00:15
00:16 patspam joined
dalek rrot: r39967 | jkeenan++ | trunk (78 files):
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 trac.parrot.org/parrot/ticket/727.
 00:17
00:18 Limbic_Region joined 00:19 jrtayloriv joined
dalek rrot: r39968 | jkeenan++ | branches/darwinhints:
Branch has been merged into trunk and is no longer needed at HEAD.
 00:21
purl i already had it that way, dalek.
rrot: r39969 | jkeenan++ | branches/darwin2hints:
Creating branch for 2nd part of work on TT #727.
TT #755 closed by jkeenan++: 'make install-dev' assumes "modern" File::Path 00:24
00:26 jrtayloriv joined 00:27 jrtayloriv joined
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:27
had this problem for a while at least with one of the tests 00:28
00:28 jrtayloriv joined
pmichaud mikehh: what os/distro/platform? 00:28
mikehh but all the tests actually PASSS
Ubuntu 9.04 amd64
pmichaud okay. I've got a couple of x86 failures. 00:29
I'm waiting for my 64-bit run to finish.
I get failure in t/spec/S32-array/end.t and t/spec/S32-array/elems.t on 32-bit 00:30
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
pmichaud Yes, but I agree with bacek++ that it's just because the memory layout changed, not because we fixed the key bug. 00:38
00:43 jrtayloriv joined 00:44 brooksbp joined
mikehh pmichaud: it looks to me like its the type of error caused by an off by one bug 00:45
00:47 jrtayloriv joined, nopaste joined 00:48 TonyC joined
bacek_at_work pmichaud: if you'll have time can you review trac.parrot.org/parrot/changeset/39960/ ? (it's stealing of quoting from Rakudo to NQP) 00:54
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.
pmichaud we might also need one for <xyz abc> 00:57
although hopefully nobody was using that.
the patch is missing tests. 00:58
bacek_at_work (tests) I start adding tests in next commits. 01:04
01:18 TiMBuS joined 01:21 NotFound joined 01:44 skids joined
Austin cotto: ping 02:38
dalek ose: r65 | Austin++ | wiki/TocCloseProgrammingLanguage.wiki:
Created wiki page through web user interface.
 02:39
ose: r66 | Austin++ | wiki/CloseIntro.wiki:
Edited wiki page through web user interface.
ose: r67 | Austin++ | wiki/TocCloseProgrammingLanguage.wiki:
Edited wiki page through web user interface.
 02:44
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.
Austin Moo.
purl?
purl Austin?
Austin WTF, no purl?
Ahh, just slow. 02:46
02:48 janus joined
dalek ose: r68 | Austin++ | wiki/TocCloseProgrammingLanguage.wiki:
Edited wiki page through web user interface.
 02:49
ose: r69 | Austin++ | wiki/TocCloseProgrammingLanguage.wiki:
Edited wiki page through web user interface.
rrot: r39970 | jkeenan++ | branches/darwin2hints/config/init/hints/darwin.pm:
Inline comments re plan of attack.
 02:54
02:56 Andy joined 03:34 dukeleto joined 03:43 dukeleto joined 04:13 hiroyuki_y joined
cotto Austin, I think you were talking to someone else. 05:05
dalek rrot: r39971 | pmichaud++ | trunk/src/runcore/trace.c:
[core] Fix a bug in the tracing runcore that would throw an exception

or Continuation were encountered in the trace output. Since continuations aren't Sub PMCs in the first place, I removed this misfeature altogether
  (and thus (Ret)Continuations are now displayed like any other PMC).		 05:14
rrot: r39972 | pmichaud++ | trunk/runtime/parrot/library/PGE/Perl6Grammar.pir:
[pge]: Fix duplicate identifier in Perl6Grammar bug (TT #772)
TT #772 closed by pmichaud++: [BUG] Duplicate identifier in PGE;Perl6Grammar.compile 05:16
rrot: r39973 | pmichaud++ | trunk/src/pmc/exceptionhandler.pmc:
[core]: Make sure ExceptionHandler PMC calls its parent class in mark().
 05:18
rrot: r39974 | cotto++ | branches/ops_pct/compilers/opsc/compiler/actions.pm:
[opsc] switch back to a normal PAST::Block for per-op info; most processing will be done by the runcores
 05:27
bacek_at_work cotto: how is your interview? 05:41
cotto exhausting 05:45
I talked with 4 people over the course of 6 hours.
I think I'll get an offer, but I also have to think carefully about accepting it.
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:46
I'm also talking with a local Perl (and Ruby, apparently) shop for a job I'd much prefer. 05:47
but for now, it's opsc hacking tiem
*haxx0ring
btw, have you looked at the way OpFile.pm does control flow instruction mangling? 05:48
I don't see much point in switching to an intermediate form like it uses, but a second opinion wouldn't hurt. 05:49
(bascially, it goes "expr OFFSET(X)" -> "{{^+X}}" -> runcore-specific final form) 05:50
bacek_at_work I don't see any reasons to do first step in processing. 05:52
cotto ok. I think it was there because the code handles nested parens specially, but it seems like more work than is necessary. 05:53
05:54 Theory joined
bacek_at_work cotto: agree 06:02
cotto I need to figure some stuff out about the current code, especially how dynops work. 06:04
Blindly reimplementing the existing code is a recipe for pain. 06:05
06:23 uniejo joined 06:24 iblechbot joined 06:26 mokurai joined
bacek_at_work cotto: all dynops go through "C" core (slow/fast) only 06:32
cotto really? There's code generated that appears to work with the other runcores 06:36
bacek_at_work look at wrapper__ 06:46
cotto That obviates a bunch of generated code. 06:50
good night 06:57
bacek_at_work cotto: good night 07:05
dalek kudo: 02d0ed2 | pmichaud++ | (2 files):
Replace string-based typecheck with class-object based typecheck.

due to something going wrong when do_dispatch (written in C) calls
  !bindability_checker (PIR) which calls typeof_s_p opcode which
calls the 'name' vtable function which itself happens to be overridden in PIR via a :vtable flagged sub. Or something like that. Anyway, we once again see that using string names as class identifiers leads to trouble. (Bad coder! No biscuit!)		 07:14
bacek_at_work pmichaud++ # niice commit message! :) 07:21
08:02 ewilhelm joined
ewilhelm github.com/notbenh/euler_bench/tree/master -- #pdx.pm is trying to get the benchmarking thing rolling 08:05
euler problems are much more approachable than the shootout ones
08:08 hiroyuk__ joined 08:09 chromatic joined
mikehh codetest FAIL at r39974 - All others PASS (pre/post config, smolder, fulltest) - Ubuntu 9.04 amd64 (PATCH to come) 08:12
nopaste "mikehh" at 90.209.117.228 pasted "codetest failure at r39974 (lib/parrot/Test.pm) PATCH follows" (31 lines) at nopaste.snit.ch/17197 08:13
"mikehh" at 90.209.117.228 pasted "PATCH for codetest failure at r39974 (lib/parrot/Test.pm - codetest PASSes after PATCH)" (15 lines) at nopaste.snit.ch/17198
08:15 dukeleto joined 08:17 clunker3 joined
dalek rrot: r39975 | fperrad++ | trunk/lib/Parrot/Test.pm:
[codingstd] remove hard tab
 08:18
rrot: r39976 | fperrad++ | trunk (16 files):
[config] add a step for thread

see TT #815		 08:21
TT #815 closed by fperrad++: Add a step for Configure: auto::thread 08:24
08:29 donaldh joined
dalek rrot: r39977 | fperrad++ | trunk/include/parrot/atomic.h:
[cage] remove useless define PARROT_HAS_NATIVE_ATOMIC
 08:38
pmichaud I'll be up again in just a few hours 08:47
chromatic wishes for a make tags-vi target in Rakudo. 08:53
09:07 bacek joined 09:11 mokurai left
bacek o hai 09:13
09:17 MoC joined 09:20 whoppix_ joined 09:32 TiMBuS joined
szbalint ewilhelm: excellent 09:35
I thought about that too, but I didn't want to make the Euler solutions publicly accessible
but yeah, parrot + rakudo desperately needs some benchmarking points of comparison 09:36
09:56 bacek joined
mikehh All tests PASS (pre/post config, smolder, fulltest) at r39977 - Ubuntu 9.04 amd64 09:59
10:04 donaldh left 10:11 iblechbot joined
bacek msg chromatic Latest MPB post has some html tags mess... 10:24
purl Message for chromatic stored.
11:13 jimmy joined 11:20 donaldh joined 11:50 whoppix joined 12:07 bacek joined 12:37 masak joined 12:41 jimmy joined, Whiteknight joined
Whiteknight good morning #parrot 12:42
jimmy good morning, Whitenight 12:43
12:44 skids joined 13:11 clinton joined 13:20 whoppix joined
dalek TT #824 created by fperrad++: [CAGE] refactor MSVC SAL with Configure 13:23
13:44 gron joined
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
i am currently looking into different VMs to get an idea about the general issues with bytecode design 13:49
parrot seems to support already a lot of stuff at this level, for instance file operations and continuations
13:50 Andy joined
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:50
13:53 skids_ joined 13:57 jsut_ joined
Whiteknight gron: I don't think any such report exists 13:57
although it's probably a good idea to put together some sort of retrospective about our design
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 13:59
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:00
14:01 skids joined
gron and does it allow to gain performance for all kind of languages with a common jit? 14:01
NotFound gron: you can take a look at this: www.linux-mag.com/cache/7373/1.html 14:02
Coke Austin: ping 14:05
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:06
Coke msg Austin it was coke you were talking to, not cotto. 14:07
purl Message for austin stored.
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.
(regarding the JIT)
pmichaud NotFound: I totally agree -- I don't think Class.isa_pmc should be calling Parrot_str_Free. 14:09
NotFound pmichaud: in fact looks like this is the only usage of that function in the reo. 14:10
repo
ewilhelm szbalint, do you think we need a "spoiler alert" for the euler problems? I think I've seen several other repositories of solutions
pmichaud NotFound: I agree with you there also. 14:11
I'm going to remove it and see if that resolves our gc problem in Rakudo.
It seems very likely -- the problems we have all seem to have to do with "isa" checks.
NotFound pmichaud: I've done it. With rakudo from yesyerday's git I have the 'succ' problem. 14:12
After a git pull, is running spectest now without problems.
The funny thing is that yesterday I wasn't having the problem.
pmichaud well, overnight I made a change to rakudo that should've gotten rid of the 'succ' problem
however, moritz++ is reporting a problem in his environment -- one moment 14:13
h
09:21 <moritz_> pmichaud: nopaste.snit.ch/17199
NotFound Anyway, all parrot test pass with those calls removed. Maybe somone must make some check with valgrind to be sure.
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.
pmichaud STRING* reclamation is normally handled by GC, not by explicit free
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.
szbalint no I/O or data manipulation on a large scale
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
so imo what would be more useful is testing those constructs directly - but then it's hard to equate them across different languages
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:19
mikehh pmichaud: I got two new failures with spectest - would you like me to paste the results? 14:20
pmichaud mikehh: yes, please 14:21
mikehh 4 test with problems - two with the seg fault and 2 others
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:22
nopaste "mikehh" at 90.209.117.228 pasted "rakudo spectest failures" (129 lines) at nopaste.snit.ch/17203 14:23
pmichaud actually, in looking at Class.isa_pmc, why-why-why are we doing string comparison of classnames in the first place?! 14:24
07:15 <dalek> rakudo: Anyway, we once again see that using string names as class identifiers
ewilhelm szbalint, if you want to, fork and send a pull request to notbenh. I think that's how he likes it
pmichaud 07:15 <dalek> rakudo: leads to trouble. (Bad coder! No biscuit!)
szbalint ewilhelm: oh ok, makes sense
NotFound pmichaud: both isa and isa_pmc in Class do things that looks unreasonable to me, 14:27
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:28
mikehh: thanks for the spectest report -- very helpful. 14:33
mikehh pmichaud: I will try and keep it up - at the moment looking at the seg fault problem 14:35
pmichaud the segfault-on-exit? 14:36
mikehh #yes
don't know where the # came from - but yes the seg fault on exit 14:38
from t/spec/S12-attributes/recursive.rakudo and t/spec/S14-roles/basic.rakudo - pass all the tests say "# FUDGED " then Segmentation fault 14:41
pmichaud okay, looks like we need 1295-1314 because of classnames in other hlls 14:45
I'm guessing we don't need the str_free though 14:46
Oops, I forgot to credit NotFound++ in my commit message. :-( 14:57
I'll make it up in another one.
dalek rrot: r39978 | pmichaud++ | trunk/src/pmc/class.pmc:
[core]: Class.isa_pmc should not be forcibly freeing STRING* values

as class identifiers leads to trouble.")
NotFound pmichaud: no problem, I'm not a buddhist ;) 14:58
Generalizing, *no one* should free STRING * values, we have a GC and must let it take care. 14:59
15:00 Theory joined
Whiteknight using string names as class identifiers is only trouble if you can't learn to ignore all the problems it causes 15:14
maybe you just need to become more tolerant of massive crashes and performance problems
:)
Coke pmichaud: I think your recent fix to class isa just fixed a few TTs and lets partcl's branches/convert_tcllist work.
(that's one of my attempts to eliminate a PMC and replace it with a class.)
pmichaud Coke: Thanks, but it's really NotFound++'s fix 15:16
although I have some more related fixes possibly on the way
It's going to bug me that isa checks create a ton of gc-able objects
(actually, it does bug me.)
Coke working first, fast later. 15:17
but yes.
I already create a ton of pmcs in my HLL, I don't need parrot doing it too. =-)
(pmc=pmc||string)
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)
pmichaud those bother me less, because (I think) they're relatively constant pmcs
Coke I imagine there are a lot of efficiencies possible, in either case. 15:19
pmichaud I could be wrong there
Coke I hope it's not just my imagination.
pmichaud In the case of isa checks, I know that they're GCables created at runtime
Coke but we had enough false starts with faux-efficiency.
pmichaud and for deeply subclassed items, they're O(n**2)
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... =-)
Coke ducks.
pmichaud wait, O(25)
Coke: we do.
the address of the class object is effectively its class id
15:20 donaldh joined
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.
pmichaud right
dalek rtcl: r522 | coke++ | branches/convert_tcllist/runtime/ (2 files):
cleanup duplicate PIR var names.
pmichaud we do use the class object address under the covers
Coke pmichaud: make sure they're deprecated and we can rip them out in 2 weeks.
pmichaud Coke: alas, it really requires a design decision from the architect, I think 15:22
Coke You can open an RFC, anyway.
or ping allison directly.
purl I can't find allison in the DNS.
Coke ping purl
purl I can't find purl in the DNS.
Coke ping your butt
purl I can't find your in the DNS.
Coke purl--
purl Coke: excuse me?
Coke ${ purl-- } 15:23
pmichaud: yup. that branch now works. whee.
NotFound++ 15:24
pmichaud++
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
I didn't know tcl was having troubles there -- what tickets?
15:24 hercynium joined
pmichaud (I want to read up and see if there are any other ramifications we might not have thought of yet) 15:25
Coke trac.parrot.org/parrot/ticket/776 for one, though that's not the branch I was just testing. 15:27
pmichaud yes, that seems likely. 15:28
The problem came about anytime a constant string PMC was being used in isa checks.
Coke trying that branch now.
15:29 ruoso joined
NotFound Good, it was looking very strange to me that such an anomaly were not actually breaking things :) 15:29
Coke Whiteknight: trac.parrot.org/parrot/attachment/..._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
Whiteknight Coke: no, that's right
that's a patch for the first deprecation stage of a multi-stage solution
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.
I'm carping against the design now :-)
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.
Coke still, another branch is working, so yah. 15:33
one down.
pmichaud It's a long-standing carp. Like, since summer 2007, I think. 15:35
15:37 dalek joined
NotFound I think we must deprecate that unuseful and confusing function from the string api. 15:37
Or even better, kill it immediately. 15:38
cotto If you want to deprecate something, now's a really good time to do it. 15:39
15:47 dalek joined
NotFound Too bad, Parrot_str_free is mentioned in pdd28. 15:47
I'll write a RFC ticket, then. 15:48
dalek TT #825 created by jrtayloriv++: PATCH: Fix incorrect references in pdd22 15:55
pmichaud arrrrrrrrrgggggggggggggghhhhhhhhhhhhhh! 15:56
nopaste "pmichaud" at 72.181.176.220 pasted "arrrrrrrrrgggggggggggggghhhhhhhhhhhhhh!" (19 lines) at nopaste.snit.ch/17205 15:57
pmichaud This code currently runs and outputs "1". Arguably it should not do that, but that's a design decision. 15:58
That's not the source of my "argh".
in the isa line, $P0 is a String PMC
dalek TT #826 created by NotFound++: Deprecate Parrot_str_free
NotFound pmichaud: yes, I was looking at isa test and wondering the same-
pmichaud we then eventually find ourselves in Class.isa_pmc, to see if the object isa "XYZ"
in Class.isa_pmc, we call Parrot_oo_get_class passing the "XYZ" String PMC as the class we're looking for 15:59
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
so then...
purl so then is the poe chat server using somepropriety code written just for it?
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!
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 16:06 particle1 joined 16:07 Psyche^ joined
Coke msg purl forget so then. 16:13
purl Message for purl stored.
Coke whoops. =-)
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?
(in C, of course) 16:39
Whiteknight i have no idea, I've wondered about that myself 16:43
I would assume interp->vtables[typenumber]->class_ or something
I can't remember all the names of things
pmichaud that's not quite sufficient
Whiteknight and that might return a PMCProxy too I think
pmichaud I know it doesn't return a PMCProxy 16:44
Whiteknight not sufficient, but definitely fast
pmichaud that _class member of vtables is.... weird.
Whiteknight yay weirdness!
pmichaud it doesn't ever point to what I expect it to hold.
same for namespaces
Whiteknight anytime we find "is weird" in one of our explanations, we should immediately start a branch and kill it
16:46 mokurai joined
Infinoid my int $foo is weird; 16:47
Whiteknight KILL IT! 16:50
Austin What is the official position of PMCs w.r.t. classes. Are PMC's considered classes? 16:52
Whiteknight no
a Class is a type of PMC
pmichaud There's not a consistent official position (more)
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
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)
Austin Okay. But I want to talk about classes, not types. 16:54
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.
pmichaud right
Whiteknight that's like magic
Austin Except that P6object wants me to talk about ::parrot::SomePmcType
pmichaud what happens is that Parrot constructs a PMCProxy object that acts like a Class interface to the underlying PMC representation
Whiteknight right, it's smoke and mirrors
pmichaud P6object wants the leading "parrot" because all PMC types end up in the 'parrot' namespace 16:56
which is likely different from your current .HLL namespace
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"
pmichaud that's currently the case, yes. That may be deprecated.
(if it's not deprecated already)
Austin Okay. That seems schizophrenic.
pmichaud officially, 'new "Iterator"' is supposed to look only in the current HLL 16:57
Austin Really?
Whiteknight because you could overload it locally
pmichaud Yes, really.
Whiteknight ORLY?
purl YA RLY.
Austin Okay.
Whiteknight SRSLY
Austin So should PMCs be part of the namespace tree?
pmichaud if you want to be sure to get the parrot iterator, it's root_new ['parrot';'Iterator']
PMCs are currently part of the parrot namespace tree, yes. 16:58
Austin Are they? 16:59
Whiteknight well...sort of
pmichaud Yes.
Austin If you can just ask for one by shortname, they're not really namespace-ified, are they?
Whiteknight I don't know if they are actually "in" the namespace
so much as they are searchable from there
pmichaud They're actually "in" the namespace.
Austin WhiteKnight: they are
Whiteknight okay, that's fine too
pmichaud If you add a method to ['parrot';'Integer'], then all 'Integer' objects get that method.
Austin You can query the root namespace for symbols, and get them back. 17:00
pmichaud er, all Integer PMCs get that method.
Austin: the ability to ask for PMCs by shortname is the thing I mentioned that is likely deprecated.
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"?
pmichaud where PMCs belong is an open question at the moment. Currently they all go into 'parrot' hll_root 17:02
shortname doesn't need to go away, it just needs to be more rigorous
Austin By rigorous, you mean hll-mapping?
pmichaud currently there are some legacy pieces to keep the existing (incorrect) uses of shortname working
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
it's the "fall back" operation that needs to be eliminated
PerlJam Does all PMCs going into 'parrot' hll_root mean that there could be collisions between 2 HLLs?
Austin Is that what's causing some of your proxy woes?
pmichaud Austin: yes.
PerlJam: it does, but there would be collisions (at the C level) anyway 17:05
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 :-)
Austin pmichaud: How so, shouldn't dynamic pmcs go into the hll root, or wherever?
pmichaud Austin: currently the C function names are tied to the non-HLL PMC name 17:06
so I suspect there would be linker conflicts.
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.
So perhaps that's not a collision.
Austin Cool.
pmichaud at any rate, there are undoubtedly a variety of collisions that will occur in the current design.
beyond just the clobbering of the namespace.
My personal opinion is that per-HLL PMCs probably belong in the hll namespace or hll-private namespace 17:08
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.
(not likely to happen *soon*, that is)
Austin pmichaud: thanks. 17:09
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
so we use "Perl6Scalar"
Austin Yeah, I wondered about that.
pmichaud and then P6object does various tricky things to make it look like "Scalar"
17:11 buildbot joined 17:12 chromatic joined
dalek ose: r70 | Austin++ | wiki/CloseIntro.wiki:
Added intro section on hll and namespace directives.
 17:16
ose: r71 | Austin++ | wiki/CloseIntro.wiki:
Edited wiki page through web user interface.
Tene pmichaud: check out what I just ran on Parrot: imgur.com/kgDVS.png 17:27
pmichaud niiiiiice
particle tene: written in?
nopaste "tene" at 24.10.252.130 pasted "Little dialog utility source, could use some OO and abstraction..." (78 lines) at nopaste.snit.ch/17206 17:28
Tene particle: PIR, for now. I'm just wrapping the 'Elementary' library from the enlightenment guys.
pmichaud not bad!
particle never heard of it. not bad at all 17:29
Tene The only issue right now is the signature that its callbacks use...
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
otherwise I'll just write an email to parrot-dev describing the current sub-optimalness and let someone else deal with it.
chromatic Hm, I wonder if r39351 was the source of succ woes in Rakudo.
Tene pmichaud: isn't it $I0 = classobj.'type'() ? 17:30
pmichaud Tene: in C
Tene Ah.
pmichaud Tene: from a type number
chromatic: we've been seeing succ woes in rakudo for weeks
Tene Oh, I misread.
chromatic Five weeks? 17:31
pmichaud no, just about that long
let me look at 39351
dalek ose: r72 | Austin++ | trunk/src/parser/ (2 files):
Refactored adverbs away from declarations
pmichaud chromatic: I think it's the change that introduced the Parrot_str_free() into Class.isa_pmc 17:32
(which I took out earlier)
chromatic I disagree; I think that papers over a bug. 17:33
pmichaud Why would Parrot_str_free() be correct?
chromatic Because the name of the class should always be a *copy* of the STRING containing the class's name.
Otherwise anything can modify it.
pmichaud yes, but it's "copy" in the COW sense, yes?
nothing in the isa_pmc code appears to be making a copy of it 17:34
and in this case we're not modifying the string anyway, are we?
chromatic That's because the get_name vtable entry is responsible for making the copy.
pmichaud oh
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)
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
Tene pmichaud: look at src/oo.c lines 730 to 735
pmichaud Tene: doesn't interp->class_hash just give me the type number? I already have that.
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
chromatic That may be the PIR version. Sigh. 17:38
pmichaud correct.
it didn't occur to me that VTABLE_name would need to return a copy of the name.
although I'm not entirely convinced that's our bug in rakudo's case, because rakudo doesn't modify strings in place
(they're treated as immutable for the most part) 17:39
chromatic Who knows what happens elsewhere?
pmichaud agreed
otoh, I'm pretty sure I disagree with using Parrot_str_free on the strings.
that really would explain why things were being collected prematurely whenever 'isa' was called.
chromatic Indeed. 17:40
pmichaud anyway, if we can avoid the strings altogether, it'll be a huge win.
did you see my analysis above about the extra pmcproxy objects being created? 17:41
chromatic I haven't backlogged yet. I will.
pmichaud I can describe it here
given
$P0 = box 'Foo'
$I0 = isa $P99, $P0
we eventually get to Class.isa_pmc
that in turn calls Parrot_oo_get_class in order to get the class corresponding to 'Foo' 17:42
if 'Foo' was defined in another HLL namespace
then the initial lookup for 'Foo' fails, and we look for 'Foo' in the classhash
we find it there, so we get its type number
17:42 urkle joined
pmichaud and then create a PMCProxy for that type 17:42
and return that back to isa_pmc
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.
pmichaud assume 'Foo' was created as $P0 = newclass 'Foo' 17:44
the rest of what I said above holds.
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:45
chromatic May I suggest, tongue in cheek, leaving that as idle curiosity for just under two weeks? 17:46
pmichaud as in "don't even try it", or as in "don't commit it"? 17:47
chromatic The latter for sure.
pmichaud so, along the lines of "don't open boxes you aren't sure you want to be looking into"? ;-) 17:48
chromatic More "I don't want to think about tracking down the implications before 1.4" 17:49
pmichaud it looks like disabling src/oo.c:743 would be sufficient to test it :-) 17:51
and that function only appears to be called for PIR classes
anyway, I'm certainly going to wait until at least after lunch to try anything like that 17:52
oh, hmmm. 17:53
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
oh, wait. false. 17:54
I do need the class object.
grrr.
oh well.
lunchtime -- bbl
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
Tene Making a .so that calls into Parrot functions is a bit beyond my c-fu 17:59
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:07
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.
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
THAT is the bug.
NotFound Anyway, I don't see the point for explicitly free things, suppossedly we let the GC take care of that. 18:19
chromatic I agree; it's just a performance hack. 18:20
But if these strings aren't safe to free there, we have a deeper problem elsewhere. 18:21
18:21 Whiteknight joined
chromatic Sometimes STRINGs need pass-by-reference semantics. Sometimes they need pass-by-value semantics. 18:21
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.
True, that would be an easy test to write.
NotFound We can make class name strings RO, and make better checks of RO in all string modifying functions. 18:23
chromatic I don't know how to make RO strings. 18:24
NotFound I think several functions lack that check.
Actually we have no way, given that al string internals are exposed and used. 18:25
Well, constant, not RO.
chromatic Constant (now) doesn't mean you can't modify it.
18:28 jdv79 joined
NotFound Then what PObj_constant_FLAG means? 18:29
chromatic The GC won't sweep it. 18:30
jdv79 am i the only one that the phrase "...seems to change 18:32
the memory layout such that..." scares?
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"
that's what i was getting at
particle gc bugs are hard. 18:34
gigeresque
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:36
NotFound Let them eat the moon, we hae electric light ;) 18:37
chromatic Electricity comes from moonbeams.
jdv79 i guess i don't understand enough to grasp why its so hard.
chromatic Imagine you want to know "Which memory objects in my system am I currently using? Which ones am I not using?" 18:38
How do you figure that out?
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.
chromatic For every simple answer to that, there's a complication.
jdv79 i think NotFound is more onto what i mean
i guess if i tried to chase a gc bug i'd learn alot
Whiteknight if we pretend it doesn't exist, things are easier 18:42
but the string system being so poorly encapsulated has always bugged me
(along with the poor encapsulation of nearly every other subsystem)
jdv79 is there a goal for subsystem boundry defining or hardening? 18:43
Whiteknight not a written one, no
but that would still be quite a nice thing to do
cotto Using only the STRING API would mean a lot of changes, not that they'd be unwelcome. 18:44
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
...mostly
(actually, the GC is probably a bad example right now)
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?
chromatic For the get_name bug, yes.
Whiteknight cotto: that's quite a good question
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
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
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
interp.'is_collected', or even an
NotFound Whiteknight: I'm almost sure that no one touched gc internals just to open a file. With strings, we do that.
Whiteknight is_collected op or dynop would be nice
I can tell you that nobody is touching GC internals anywhere, at least not as of a few weeks ago 18:52
Whiteknight has to host a remote desktop session and it would be bad if they saw me chatting on IRC. So...later. 18:53
cotto pmichaud, ping 18:56
actually, unping. It's lunchtime.
jdv79 maybe Whiteknight or someone else knowledgable in gc affairs could writeup some useful tests/metrics/whatever. 18:57
i mean do a writeup describing them. not code them. 18:58
pmichaud cotto: unpong 19:09
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
PCT::HLLCompiler supports a --combine option that says that multiple input files are to be treated as a single source
19:19 athomason joined
darbelo cotto: ping 19:22
19:44 bacek joined
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
darbelo trimmed that message to half of it's original length just by removing the word "fuck" and it's derivatives. 19:50
Whiteknight d(fuck)/dt? 19:51
Whiteknight is going to read the logs now to see what he missed 19:52
irclogs?
purl irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
Whiteknight jdv79: I'll see if I can write something up tonight 19:54
dalek a: b334705 | fperrad++ | (2 files):
handle ambiguous function call
 20:12
20:22 allison joined
Whiteknight good afternoon allison 20:28
allison hi Whiteknight
Whiteknight We've been seeing lots of interested new users recently, it's really quite exciting 20:30
allison Whiteknight: excellent! 20:35
purl zwooshes
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
Or is there a better option?
I think i might be doing something wrong here. :)
allison Tene: the only other option is to statically compile it into parrot 20:37
Tene: so, depends if it's core or not
Tene: it's not you that's wrong, it's C, which is decidedly *not* a dynamic language :) 20:38
20:38 donaldh joined
Tene allison: specifically, I'm trying to write some C that build a callback for a function with more than two args. 20:38
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
allison (for callbacks)
Tene it's not dlfunc that won't load it, it's new_callback that won't work with it.
and new_callback just calls Parrot_make_cb 20:40
The issue is that it calls vtable functions, which require the interpreter, and I'm not sure I'm passing that correctly.
I just did a $P0 = getinterp, and passed that as the first argument. 20:41
20:43 brianwisti joined
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:43
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.
Tene NotFound: It looked like it might have been 'J', but when I tried J, it failed.
allison Tene: J is the interpreter argument
Tene Ah, yes, it does work.
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.
Ah, good.
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...
allison: it returns a PMC... so PJPPS ?
allison Tene: aye
NotFound I can't help with that, didn't even started to understand the callback mechanics.
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?
allison Tene: maybe, depends on the patch 20:48
Tene Okay. :)
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
allison Tene: but if it is an actual bug in the callback code, then yes, patches welcome
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"
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: imgur.com/kgDVS.png 20:52
pmichaud: you running into that ASSERT fail now too? 20:53
allison pmichaud: whether cloning an interpreter clones all the user-defined classes too
pmichaud Tene: no, I'm trying out a patch that eliminates string comparisons for doing isa checks
allison: afaict, that flag just controls the cloning of the class_hash itself, not the actual classes.
i.e., the classes aren't cloned.
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.
pmichaud Tene: I'm not getting the assert failure, no. 20:55
allison pmichaud: cloning hashes used to be a deep copy 20:56
pmichaud allison: they still are
I think what has changed is that the class_hash now hold type numbers instead of pointers to class objects
allison pmichaud: mmm... that could be
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
the CLONE_CLASSES flag seems to cause the new interpreter's clash_hash to have all of its entries deleted.
*class_hash 20:58
in eliminating string checks for isa membership, everything passes except this one test in threads.t
which appears to be related to CLONE_CLASSES
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
so I'm wondering if I can todo/skip that test, or otherwise not worry about the one error from my patch
(2015-1778)/2015 21:00
purl 0.117617866004963
pmichaud 11% speedup
(for rakudo's spectest)
chromatic Seems about right. 21:01
pmichaud as well as getting rid of the string manipulation bogosity in isa_pmc
chromatic +1 to todo the test; I don't believe it worked robustly.
donaldh chromatic: your nci optimizations broke my nci :-/ 21:02
chromatic On x86?
32-bit?
JIT enabled?
donaldh chromatic: I'll explain.
Whiteknight allison: are the callbacks restricted by design, or can they be made more usable?
donaldh 'V' is broken in JIT.
Tene Okay, I've got my callback called. :) 21:03
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.
donaldh I think your optimizations have totally defeated that by removing all the generated thunks when CAN_BUILD_CALL_FRAMES is enabled.
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
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.
Give me a patch with a failing test case and I'll make it happen.
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 ?
chromatic donaldh, I'll take a look. 21:09
donaldh trac.parrot.org/parrot/attachment/...ndle.patch is the patch to not handle 'V' in JIT.
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
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
(unless I can figure out exactly where those failures are coming from)
(the Rakudo failures all deal with Roles.) 21:12
21:13 bacek joined
bacek Good morning, #parrot 21:13
allison Tene: it does seem to make sense to have a public interface way to do that
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... :(
allison Tene: you'd have to remove 'static', and rerun the headerizer
Tene ah
allison Tene: does Parrot_callback_C or Parrot_callback_D not work for you? 21:16
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.
oh, you mean call one of those instead.
Yeah, I could do that. 21:18
allison Tene: instead of calling verify_CD directly, aye
Tene Clever.
NotFound allison: Can you take a look at TT #826?
Tene Yay, failed assertion!
allison NotFound: sure 21:19
Tene: in the number of arguments?
Tene src/interp/inter_cb.c:389: failed assertion 'external_data'
dunno what that means yet. 21:20
it's failing the ARGIN(char *external_data)
I passed a void *
chromatic and it's NULL
Tene Yeah, looks like. 21:21
If I fudge it and pass "oh noes" instead, I get a PANIC: callback gone to wrong interpreter 21:22
allison NotFound: comment added to TT #826, I'm in favor 21:27
NotFound allison: ok, but I don't think is so important to maintain a behavior that is just an attempt of optimization. 21:28
allison Tene: did you store the interpreter as an '_interpreter' key of your user_data PMC? 21:29
21:30 donaldh joined
donaldh chromatic++ 21:30
allison NotFound: aye, but an inconsistent deprecation policy isn't much use in reassuring users
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?
allison NotFound: and, we're talking 2 weeks of delay, hardly painful
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.
allison Tene: potentially, are you running multi-threaded? 21:32
Tene: and, make sure the interpreter you stored actually had a value
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.
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.
allison Tene: so, if nothing is stored, you get the same error as if a different interpreter object is stored
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?
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
Tene allison: "make sure that the interpreter I stored actually has a value" 21:36
allison Tene: aye, PMC_IS_NULL is a good first check 21:37
Tene That passes fine.
allison Tene: if it's not null, check that the object that was stored was of type Interpreter
Tene: or base_type enum_class_ParrotInterpreter 21:38
dalek rrot: r39979 | bacek++ | branches/tt761_keys_revamp/src (7 files):
Bah
 21:39
21:39 clunker9_ joined
bacek Looks like I screwed my git-svn checkout... 21:40
Tene allison: looks like it's a Parrot_Null ? 21:46
allison Tene: stored in "_interpreter"? that's not good 21:47
Tene at least by the time it gets to callback_CD
allison Tene: but it does explain why it doesn't match the current interpreter
Tene: mmm... yeah, makes you wonder where it's getting lost
Tene Rather.
What would I get if I ran getprop on something that had never been setprop'd? 21:48
Would I get a Null?
allison Hmmm... potentially
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?
dalek rrot: r39980 | bacek++ | branches/tt761_keys_revamp/src (7 files):
Revert previous commit.
chromatic Tene, yes. It's mostly the same thing, just not at compile time.
allison Tene: getprop in the default PMC runs a set of standard checks, then returns PMCNULL
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:51
Tene It's definitely an interpreter when I set it. 21:52
Can I get to properties from gdb easily? 21:53
allison what happens between that point and the point the callback is run?
Tene: aye, you can call vtable functions from within gdb
Tene: you just can't use the fancy macro syntax
Tene hmm... 22:02
How do I assign to a variable and run a function from within gdb? 22:05
allison Tene: assign to a variable? 22:06
Tene Eh... bad choice of wording.
allison Tene: running a function is just like typing an extra line of C code
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)
Tene Ah, nm, I didn't say what to do with it.
allison Tene: you have to unroll it to: (pmc)->vtable->getprop(interp, pmc, key) 22:08
Tene Ah. 22:09
My problem was leaving off the 'p' on the front.
off
In my callback helper, it's definitely set. Later on, it's definitely not. 22:12
... ><
I wasn't calling it with the same user_data. 22:13
Okay, now it's making it far enough to schedule the callback, but it never actually gets run.
dalek rrot: r39981 | bacek++ | branches/tt761_keys_revamp (85 files):
Bring branch up-to-date with trunk.
 22:14
allison Tene: that's progress 22:15
Tene and... the problem was that my callback was trying to run a non-existant sub. 22:16
dlfunc/setglobal the sub, and everything works.
:D
Well, FSVO "everything" 22:17
I still can't pass the event info, because it's null.
I need to find something to wrap it in... 22:18
I could stuff it all in a Parrot Hash, I guess. :)
:/ 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
... but then when I ^C Parrot, all of the scheduled callbacks run at once.
So, yes, I guess it must be synchronous. 22:20
allison Tene: events are run when certain "safe" opcodes are run
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.
so that it's always run synchronously.
for my callbacks
allison Tene: makes sense 22:22
Tene And to wrap stuff in a hash... 22:27
... I don't have an interp in the cb_helper
... unless I pull it out of the user_data!
... but to do that, I need an interp! 22:30
allison: any ideas?
allison Tene: where are you losing the interp? 22:31
Tene: you're passing the interp into the original function call?
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"
Tene: (attached to user_data, I mean)
nopaste "tene" at 24.10.252.130 pasted "C interpreter for Allison++" (5 lines) at 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.
allison Tene: ah, I see, yes
Tene: yes, you need an interpreter to call a vtable function on the object to get the interpreter 22:34
22:36 rg joined
Tene I could always cheat and shove the interp in a global. ;) 22:42
22:49 kid51 joined 22:56 Limbic_Region joined 23:00 Whiteknight joined
allison Tene: mmm... but globals are stored in the interpreter 23:01
Tene: or, a C global?
Tene Yes, a C global. I'll think about othe roptions. I don't really need those args for now...
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.
I have to try it several times to get it to actually run.
once it's started, it runs fine, and it always runs perfectly in gdb.
I'm really pleased. This is fun. :) 23:03
allison Tene: :)
Tene: non-gdb-able segfaults are annoying
Tene especially nondeterministic ones. 23:05
core dump! 23:06
purl core dump is not the problem. the three thousand lines later is the problem. or SEVEN LAYER BURRRRRRRRRRRRRRRRRITO
Whiteknight Tene: what's the program?
purl rumour has it the program is too big
Whiteknight purl forget the program
purl Whiteknight: I forgot program
nopaste "tene" at 24.10.252.130 pasted "The Program for whiteknight++" (118 lines) at nopaste.snit.ch/17212 23:07
chromatic sudo echo 0 > /proc/sys/kernel/randomize_va_space
Tene segfault is in strlen 23:08
23:09 skids joined
Tene It's not in Parrot, it's in the library I'm using. 23:09
Whiteknight oh great
Tene That's SO COOL. 23:10
But no, seriously, I've been wanting some nice gui libs on Parrot for a while. Now to write some OO wrappers... 23:13
gonna try to work on Curses this weekend too.
allison: is there any part of this that you'd like me to document? If so, where? 23:14
allison Tene: heh, nice (external segfault) 23:15
Tene: how about docs/pir/using_nci.pod?
nopaste "tene" at 24.10.252.130 pasted "helper file for allison++" (70 lines) at nopaste.snit.ch/17213 23:16
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
the sync variable should probably be an argument.
Wait... hm. Depends on whether there's a way to get the function pointer in there as an arg too. 23:18
I couldn't quite figure out if I could get that from an NCI object or not.
I don't reall yunderstand the issues in F2DPTR
allison Tene: aye, looks like something like that could be a useful addition 23:19
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:20
allison Tene: hey, whatever you manage to collect into a ticket increases the chances of someone else working on it 23:22
Tene: no stress
Tene Oh, right! Tickets! 23:26
Clever.
Whiteknight yay tickets! 23:28
Whiteknight installed trac at work, and is up to his armpits in tickets
Tene AFK shopping.
Whiteknight I'm looking for a list of systems or subsystems that need better encapsulation 23:30
I've got the strings system and the Contexts subsystem, any others that are in desperate need?
23:31 mikehh_ joined
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.
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
and encapsulating messy interfaces seems like a good task for people to get started on
chromatic I had one in mind, but I've forgotten it now.
Whiteknight bacek was working on keys/hashes, that was the other big one I was thinking about 23:33
okay, I'll put that post off for now, maybe ask about it on list 23:34
so what am I supposed to be working on right now? 23:35
Whiteknight has too many projects up in the air to remember which one is most pressing 23:36
Tene AIO, iirc from your blog?
Whiteknight Tene: that's something I *want* to do, but not necessarily something I *need* to do before the release
23:36 elmex joined
Tene Ah, right. 23:36
Whiteknight after the release I'm going through some deprecations like a tornado 23:37
chromatic Delete you like a hurricane. 23:38
Whiteknight sometimes I like deleting code as much as I like writing it 23:39
so what am I doing now? Still tracking down that GC bug? 23:42
Tene I wonder if my GC bug is still around...
Whiteknight I don't like tracking down rakudo bugs because rakudo takes so long to build and test 23:45
dalek rrot: r39982 | jkeenan++ | branches/darwin2hints/t/steps/init/hints/darwin-01.t:
Create some tests for _precheck().
 23:50

Powered by Cro and the Raku® Programming Language.

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

Thank you!