Camelia, the Perl 6 bug

IRC log for #parrot, 2011-02-04

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:09 nwellnhof https://sitewat.ch/en/Advisory/View/1
00:09 nwellnhof Send an email to majordomo's mail interface with the body of the message as follows: help ../../../../../../../../../../../../../etc/passwd
00:10 cotto_work ow
00:10 Hackbinary huh?
00:15 tadzik always funny
00:18 cotto_work I'm a little surprised nobody thought to try that earlier.
00:22 dukeleto Hopefully that motivates people to not use Majordomo
00:35 Hackbinary do ppl still majordomo?
00:39 vmspb left #parrot
00:41 kid51 joined #parrot
00:45 nwellnhof Hackbinary: it was discovered by Mozilla, they still use it.
00:50 cotto ~~
00:52 bacek_at_work cotto, ENOTMATCH :)
00:53 bluescreen left #parrot
00:54 bacek_at_work whiteknight, which branch?
00:54 whiteknight bacek: whiteknight/imcc_compeg_pmc
00:54 whiteknight but don't worry. You don't have to fix it. I'll fix it eventually
00:55 kid51 is now known as kid51_at_dinner
00:55 bacek_at_work whiteknight, ok :)
00:56 whiteknight the hard part is understanding why it's broken
01:00 dalek parrot: 09dc23b | NotFound++ | src/pmc/ (2 files):
01:00 dalek parrot: rarrange initialization and freeze/thaw of FIA and RIA to avoid redundant code and duplicated storage in RIA
01:00 dalek parrot: review: https://github.com/parrot/parrot/commit/09dc23bc3f
01:05 bacek_at_work whiteknight, because you broke it? :)
01:12 NotFound_b left #parrot
01:21 wknight-phone joined #parrot
01:28 nwellnhof left #parrot
01:36 wknight-phone left #parrot
01:43 contingencyplan left #parrot
01:44 kid51_at_dinner is now known as kid51
01:46 contingencyplan joined #parrot
01:56 dukeleto ~~
01:59 nopaste "kid51" at 192.168.1.3 pasted "comp_reg branch: src/dynoplibs/trans_ops.c: seg fault" (842 lines) at http://nopaste.snit.ch/30382
02:33 whiteknight left #parrot
03:06 shortcircuit left #parrot
03:55 benabik joined #parrot
04:02 kid51 left #parrot
04:19 mtk left #parrot
04:26 mtk joined #parrot
05:34 dalek parrot/generational_gc: 75902a0 | bacek++ | src/gc/ (3 files):
05:34 dalek parrot/generational_gc: Properly initialize GMS. I have no idea how it used to work before
05:34 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/75902a063a
05:35 KaeseEs that's a hell of a commit msg :V
05:39 * cotto is curious
05:40 cotto All it's missing is some very rude English.
05:40 cotto I completely agree with that commit message.
05:44 cotto bacek, how was your code even being run?
05:46 sorear KaeseEs: quite a lot of real world code only works by accident... parrot is sadly no exception
05:47 cotto ccache++
05:56 simcop2387_ joined #parrot
05:58 simcop2387 left #parrot
05:58 simcop2387_ is now known as simcop2387
05:59 rurban_ joined #parrot
06:02 rurban left #parrot
06:02 rurban_ is now known as rurban
06:09 bacek_at_work cotto, I have no idea... But new GC was definitely used before.
06:10 nopaste "bacek" at 192.168.1.3 pasted "Current list of test failures on gen_gc branch." (26 lines) at http://nopaste.snit.ch/30433
06:17 cotto I don't see how it's possible and it bugs me a great deal that the gen gc appears to have been somehow used.
06:18 cotto I did a quick sanity test with oofib.pir using gdb to break on something obvious (gc_gms_allocate_pmc_header) and it never got hit.
06:21 bacek_at_work cotto, I've spent last few days in gdb... It was definitely hitting GMS.
06:22 bacek_at_work Only one possible options - today's morning merge from master
06:22 cotto that's plausible.  I definitely believe you if you say it's being hit.
06:23 nopaste "bacek" at 192.168.1.3 pasted "gen_gc vs master build times" (20 lines) at http://nopaste.snit.ch/30434
06:24 bacek_at_work yes. Now rakudo's make fails on gen_gc. In generating core.pir.
06:24 cotto I like the speed.  bacek++
06:25 bacek_at_work cotto, it's kind of cheating because string part of GC isn't implemented yet. But we shouldn't loose more than 10-15%
06:25 cotto that's still a respectable bump
06:26 cotto Why do we need separate string gc code?
06:30 bacek_at_work STRINGs are slightly special
06:30 bacek_at_work And treated separately in GC.
06:31 bacek_at_work Not actually bad thing because it gives performance boost "for free"
06:31 cotto Is it documented anywhere how they're special?
06:31 bacek_at_work For example STRINGs doesn't have interior pointers.
06:31 bacek_at_work And we compact them.
06:32 bacek_at_work And can share underlying buffers.
06:32 bacek_at_work Almost encapsulated inside String_GC.
07:06 fperrad joined #parrot
07:21 cognominal left #parrot
07:28 benabik is now known as benabik_sleep
07:29 cosimo joined #parrot
07:31 cosimo left #parrot
07:31 cosimo joined #parrot
07:51 dukeleto ~~
07:52 benabik_sleep left #parrot
07:52 contingencyplan left #parrot
07:52 Infinoid left #parrot
07:52 extreme left #parrot
07:52 particle left #parrot
07:52 elmex left #parrot
07:52 estrabd left #parrot
07:52 preflex left #parrot
07:52 jasonmay left #parrot
07:52 dngor left #parrot
07:52 sECuRE_ left #parrot
07:52 hatseflats left #parrot
07:52 KaeseEs left #parrot
07:53 frodwith left #parrot
07:53 mj41 left #parrot
07:53 Util left #parrot
07:53 rblackwe_ left #parrot
07:53 confound left #parrot
07:58 particle joined #parrot
07:58 benabik_sleep joined #parrot
07:58 contingencyplan joined #parrot
07:58 Infinoid joined #parrot
07:58 extreme joined #parrot
07:58 elmex joined #parrot
07:58 estrabd joined #parrot
07:58 preflex joined #parrot
07:58 jasonmay joined #parrot
07:58 dngor joined #parrot
07:58 KaeseEs joined #parrot
07:58 confound joined #parrot
07:58 Util joined #parrot
07:58 rblackwe_ joined #parrot
07:58 mj41 joined #parrot
07:58 sECuRE_ joined #parrot
07:58 hatseflats joined #parrot
07:58 frodwith joined #parrot
08:29 theory left #parrot
08:53 cosimo left #parrot
09:19 davidfetter joined #parrot
10:55 contingencyplan left #parrot
10:58 KaeseEs left #parrot
11:26 davidfetter left #parrot
11:58 KaeseEs joined #parrot
12:06 mtk left #parrot
12:13 mtk joined #parrot
12:49 bluescreen joined #parrot
13:07 kid51 joined #parrot
13:08 plobsing_ left #parrot
13:18 kid51 left #parrot
13:34 bluescreen left #parrot
13:39 bluescreen joined #parrot
13:41 bluescreen left #parrot
13:41 whiteknight joined #parrot
13:42 bluescreen joined #parrot
13:45 whiteknight good morning, #parrot
13:47 bluescreen left #parrot
13:48 bluescreen joined #parrot
13:50 bluescreen left #parrot
13:50 bluescreen joined #parrot
13:53 cognominal joined #parrot
13:59 rurban_ joined #parrot
14:02 rurban left #parrot
14:02 rurban_ is now known as rurban
14:44 dalek TT #1996 created by NotFound++: Function Parrot_ext_try for extenders
14:44 dalek TT #1996: http://trac.parrot.org/parrot/ticket/1996
14:53 jan joined #parrot
14:55 dalek parrot: 668635f | NotFound++ | / (3 files):
14:55 nwellnhof joined #parrot
14:55 dalek parrot: add function Parrot_ext_try and use it in extend_vtable tests
14:55 dalek parrot: review: https://github.com/parrot/parrot/commit/668635fbd9
14:55 dalek parrot: ddcab21 | NotFound++ | api.yaml:
14:55 dalek parrot: experimental notice for Parrot_ext_try, TT #1996
14:55 dalek parrot: review: https://github.com/parrot/parrot/commit/ddcab21482
15:07 bluescreen left #parrot
15:11 Hackbinary hello whitenight
15:11 NotFound The first test in t/src/extend_vtable.t looks wrong. It's trying to use a Integer PMC as freeze destination.
15:11 moritz if it tests for an exception being thrown... :-)
15:12 NotFound TODO freeze + thaw are borked
15:12 NotFound IMO what's borked is the test
15:14 NotFound dukeleto: ping
15:14 whiteknight good morning HackBinary
15:15 Hackbinary it's afternoon here, 1515
15:15 Hackbinary ;)
15:16 NotFound whiteknight: please take a look at TT #1996
15:17 whiteknight seen Yuki'N?
15:17 aloha Sorry, I haven't seen Yuki'N.
15:17 whiteknight NotFound: Yes, I've been watching
15:18 NotFound With the last changes extend_vtable first test reports: Exception is: type 36 severity 2 message 'push_integer() not implemented in class 'Integer'
15:18 whiteknight Very similar to what I wanted to try with the Embedding API
15:19 NotFound Yes, but tries to be more friendly to extension code.
15:19 whiteknight yes
15:20 whiteknight I wish there was a function Parrot_ex_remove_c_handler instead of having to use Parrot_cx_delete_handler_local. If somebody else pushes on a handler, that one will not remove the correct one from the top
15:21 whiteknight otherwise, function looks good
15:21 NotFound Yes, that point should be improved later.
15:22 NotFound whiteknight: What do you think about the extend_vtable first test?
15:22 bluescreen joined #parrot
15:28 whiteknight I have to look at it
15:29 whiteknight Yes, that does look broken to me
15:29 whiteknight what does it output?
15:29 NotFound Exception is: type 36 severity 2 message 'push_integer() not implemented in class 'Integer'
15:30 whiteknight and the test passes?
15:30 NotFound Is TODOed
15:30 whiteknight okay
15:30 whiteknight The test is definitely broken
15:31 NotFound Using a RIA as freeze destination may work.
15:35 benabik_sleep is now known as benabik
15:43 whiteknight I don't know enough about that code. It's a plobsing question until I can research it more
15:44 NotFound github blames dukeleto
15:47 NotFound The following paths are ignored by one of your .gitignore files:
15:47 NotFound t/src/extend_vtable.t
15:47 NotFound WTF?
15:48 NotFound Oh, nice: /t/src/*_*
15:48 whiteknight ...lol?
15:48 whiteknight I wonder what the point of that is
15:49 NotFound The *_n.c files, I guess
15:49 whiteknight ah yes, that's probably it
15:49 whiteknight maybe rename the test file to t/src/vtableextend.t
15:50 whiteknight or change the rule to /t/src/*_*.c
15:52 dalek parrot: 555b42e | NotFound++ | / (2 files):
15:52 dalek parrot: fix and untodo extend_vtable is_equal_num test and fix a pitfall in gitignore with that file
15:52 dalek parrot: review: https://github.com/parrot/parrot/commit/555b42e551
15:53 NotFound The bug in is_equal num was funny.
15:54 NotFound Boys, don't try to mix printf and Parrot_printf at home.
15:58 whiteknight :)
16:09 Hackbinary tene: ping
16:10 plobsing joined #parrot
16:11 dalek parrot: 93a0806 | NotFound++ | t/src/extend_vtable.t:
16:11 dalek parrot: fix a mistake in Parrot_ext_try usage that breaks tests in C++ build
16:11 dalek parrot: review: https://github.com/parrot/parrot/commit/93a0806fe9
16:16 Patterner left #parrot
16:16 Psyche^ joined #parrot
16:16 Psyche^ is now known as Patterner
16:23 Kovensky left #parrot
16:23 theory joined #parrot
16:30 Kovensky joined #parrot
16:31 dalek parrot: 054e36b | NotFound++ | t/src/extend_vtable.t:
16:31 dalek parrot: fix, untodo, and improve extend_vtable freeze|taw test
16:31 dalek parrot: review: https://github.com/parrot/parrot/commit/054e36ba92
16:37 cotto_work ``
16:49 whiteknight '' indeed
16:59 dalek parrot: 50e3be1 | NotFound++ | runtime/parrot/library/NCI/Utils.pir:
16:59 dalek parrot: fix impedance decoupling between NCI/Utils and UnmanagedStruct
16:59 dalek parrot: review: https://github.com/parrot/parrot/commit/50e3be126d
17:28 dukeleto ~~
17:32 plobsing ping NotFound
17:33 NotFound plobsing: please take a look at 054e36b
17:35 Andy joined #parrot
17:41 dukeleto NotFound++ # fixing extend_vtable stuff
17:41 plobsing that is not how freeze/thaw are intended to be used. it is interesting that it should work, but not because that is the intended purpose.
17:41 whiteknight you know what they say about the best intentions....
17:41 whiteknight ....they're not usually found in Parrot
17:42 NotFound plobsing: at least looks more plausible that freezing to a Integer
17:43 dukeleto NotFound: i like Parrot_ext_try, nice!
17:43 plobsing Sure, and because RPA accepts {push,shift}_{pmc,int,float,string}, it *should* work.
17:43 whiteknight VTABLE_freeze, _thaw, and _thawfinish really shouldn't be exposed to extenders
17:43 dukeleto NotFound: i knew i was writing those freeze/thaw tests incorrectly, but i didn't quite know how to make them right
17:43 dukeleto whiteknight: i kind of agree
17:43 whiteknight We have interface functions Parrot_freeze and Parrot_thaw that do what is needed, those vtables are too low-level and primitive
17:44 plobsing whiteknight: not necessarily true. see https://github.com/plobsing/parrot-deepclone for an example of intended use.
17:45 plobsing I agree they are somewhat confusing and think they should have big nasty documentation deriding the intelligence of people considering using them.
17:45 plobsing not really sure how to put that into a generated file though
17:45 whiteknight plobsing: all well and good, but nothing I am seeing right now couldn't be rewritten by hll mapping a custom serializer PMC
17:46 whiteknight assuming the freeze/thaw mechanisms are smart enough to allow for HLL maps
17:47 plobsing hll mapping doesn't map well to freeze/thaw. in the most common use, the action happens outside of any HLL, meaning the mapping would be meaningless.
17:47 whiteknight I would disagree. The most common case is within an HLL
17:48 plobsing and hll-specificity is inappropriate to apply to the entire action. it should apply to the specific objects, which are already *entirely* controlling how the freeze/thaw process operates.
17:48 plobsing you want hll-specific freeze/thaw? build that into the objects your HLL generates.
17:48 plobsing you have that power already
17:49 whiteknight in those cases it would be trivial to pass in an optional serializer to the freeze/thaw PIR ops still not having to access the underlying vtables directly
17:49 whiteknight You wouldn't just want to overwrite the freeze/thaw vtables of your HLL object system. You still want flexibility. In C# I can user serliaizer objects to serialize an arbitrary object to various output formats
17:50 whiteknight Parrot has that mechanism mostly available through Parrot_freeze and Parrot_thaw, no need to require HLLs to duplicate that
17:50 plobsing no. it is the serializer's business the order in which it wants to visit objects. to accomplish this, it *must* access the vtables somehow.
17:51 dip left #parrot
17:51 whiteknight then it seems we need a better set of ops for the purpose. Using NCI for that purpose really is not the best solution in any case
17:51 plobsing I agree that custom serializers are a good idea, and we should encourage them. I disagree that we should make this facility available through HLL-map.
17:51 plobsing whiteknight: it was expedient. I could have equally used ops.
17:52 whiteknight okay. I'm not really trying to nitpick your solution. I'm just saying that the VTABLE_freeze, _thaw, and _thawfinish are much lower-level than most people need or should even be exposed to
17:52 whiteknight Making them part of the extending interface as-is is probably not a great idea
17:53 whiteknight and exposing them as brain-dead thin wrappers like in vtable_extend.c is no better
17:53 nwellnhof left #parrot
17:53 plobsing and I'm pointing to a case (which I could have done as an extension in stead of HLL) where vtable-access was crucial to accomplishing my objectives
17:54 whiteknight direct vtable access? no higher level of abstraction would have been possible for you?
17:54 plobsing I was *creating* a custom serializer. serializers need that kind of access to control order of serialization.
17:56 sheant joined #parrot
17:56 whiteknight It would be trivial to write a wrapper function that checks the validity of the arguments before passing on to VTABLE_freeze
17:56 whiteknight that would prevent the kinds of test failures that Notfound fixed
17:58 whiteknight combine that with the fact that VTABLE_freeze and VTABLE_visit should be called together, etc. A good wrapper function can do what you need it to do and save a lot of hassle
18:00 Tene Hackbinary: pong
18:00 plobsing I *tried* using a wrapper function initially. visit_loop_visit and visit_loop_thawfinish. it increased the size of the required interface. also it turns out that different visitors have differing needs for the iteration pattern.
18:01 plobsing to be as general as possible, we should expose the building blocks.
18:03 plobsing extenders have access to many powerful capabilities. safeguarding all of these from missuse is a huge undertaking, and not worthwhile IMHO. my preference is a policy of assuming embedders are capable of making their own informed decisions.
18:04 plobsing s/embedders/extenders/
18:04 whiteknight That's fine. I'll follow your lead on that one then
18:09 sorear Do we still interpret "extender" = "writes own pmcs and oplibs"?
18:09 whiteknight sorear: yeah. An extension is something called by libparrot
18:09 whiteknight so a custom PMC type, custom oplib type, or other library
18:10 whiteknight the big benefit is that an extender gets to assume his code is covered by GC, and that there is an exception-handling system in place
18:10 whiteknight embedders....not so much
18:11 plobsing but they aren't as burdened with knowledge-requirements of intricate details
18:11 whiteknight right, exactly. More power, more responsibility
18:11 whiteknight like spiderman, but not ruined by sequels
18:12 sorear What are you thinking of in terms of "or other library"?
18:12 whiteknight nothing in particular. I'm just trying to be general
18:12 * sorear was thinking of dlfunc briefly
18:12 plobsing I'd argue that it is possible to create dynpmcs and dynops without being an extender. only when you call back in to libparrot from these do you become one (although it is hard to do useful work without doing so)
18:12 whiteknight it is possible to use dlfunc to access an extension
18:13 whiteknight that is, I could write an extension library that acts like it's internal to libparrot
18:13 plobsing sorear: deepclone does exactly that. it has a helper C library which is an extender.
18:14 sorear plobsing: a dynpmc that doesn't call back to Parrot still needs extreme knowledge of the VTABLE interface
18:14 whiteknight you can't have a dynpmc that isn't created and managed by libparrot
18:14 whiteknight and you can't access it without libparrot, unless you blatantly violate our encapsulation rules
18:16 plobsing faire nough
18:19 contingencyplan joined #parrot
18:22 bluescreen left #parrot
18:22 vmspb joined #parrot
18:24 bluescreen joined #parrot
18:26 whiteknight ping cotto_work
18:27 Eclesia joined #parrot
18:27 Eclesia hi
18:28 cotto_work pong whiteknight
18:28 whiteknight cotto_work: is there any reason why the trace core is treated like a wierd special clone of the slow core?
18:28 cotto_work hysterical raisins?
18:29 cotto_work I don't know without digging in a bit.
18:29 whiteknight okay
18:29 whiteknight well if you find out that there is no good reason, I'm going to fix it
18:29 cotto_work I looked at it for example code for the profiling runcore, but that's about out it.
18:29 cotto_work s/ out//
18:30 cotto_work whiteknight: how would you fix it?
18:30 whiteknight cotto_work: move it into it's own separate core. Remove the Interp_trace flag, etc
18:32 whiteknight btw, I just tested and the trace core doesn't work in trunk. Probably hasn't since the embed_api merge
18:33 cotto_work if it's not tested...
18:35 dukeleto whiteknight: the trace core doesn't have tests?
18:35 NotFound The trace core is supposed to be used only via -t , isn't it?
18:35 whiteknight dukeleto: trace core in master can't currently be activated. If it had tests, I'm sure they would be failing
18:35 whiteknight Notfound: -t, --trace, and -Rtrace
18:35 whiteknight which, by the way, are far too many options
18:36 davidfetter joined #parrot
18:36 NotFound Last time I checked -t1 worked
18:36 NotFound And it was this week
18:38 whiteknight you can try it. I did a few tests and the trace core did not work
18:38 whiteknight so I might be missing something
18:38 dalek parrot: fc88de3 | NotFound++ | src/pmc/ (4 files):
18:38 dalek parrot: rearrange a bit string and pmc arrays initialization and thaw to ensure threshold is always set in the resizable variants
18:38 dalek parrot: review: https://github.com/parrot/parrot/commit/fc88de3cc6
18:40 NotFound Sort of. Works is some cases, coredumps in others.
18:41 dukeleto Less Than Awesome.
18:41 dukeleto We should either write a bunch of tests for the trace core to make sure it works, or remove it.
18:41 whiteknight Oh, I didn't see any coredumps. All the tests I did defaulted to using the slow core
18:42 whiteknight I think we want the trace core, but it leaves a lot to be desired
18:42 NotFound Remove it without having anything better? Big -1
18:43 whiteknight plobsing: ping
18:43 * dukeleto has never actually used the trace core
18:43 * dukeleto just wants stuff to be tested and work (most of the time)
18:44 dukeleto is the trace core subject to the deprecation policy ?
18:44 dukeleto is it a "user-facing" feature?
18:44 whiteknight dukeleto: it's on the commandline
18:44 whiteknight so yes
18:44 NotFound If you provide another way to enable trace, having it as a runcore is not mandatory.
18:45 plobsing whiteknight: pong
18:45 whiteknight I would really like to get those instrumentation PMCs working again, and start using them for more things
18:45 whiteknight plobsing: have you tested out that imcc_compreg_pmc branch after my changes yesterday?
18:45 plobsing whiteknight: haven't had the chance to do so just yet. will do.
18:46 whiteknight plobsing: because I'm still getting the same segfaulty failure in the build, so I'm trying to see if your situation is as bad
18:46 whiteknight my problem is definitely a GC bug. If I run Parrot -G, I don't see segfaults
18:47 cotto_work whiteknight: I agree about the instrumentation code.  Now if only I could find some tuits...
18:47 whiteknight cotto_work: did you check behind the couch? Tons of crap back there
18:47 dukeleto whiteknight: i am willing to setup some kind of smoking of the instrumentation pmc's if that is possible
18:47 dukeleto whiteknight: where do they live? are they under the parrot github org?
18:47 whiteknight dukeleto: They don't build right now, if I remember correctly
18:47 * dukeleto looks under his couch cushion for some tuits, but only finds a nickel
18:48 cotto_work dukeleto: they're not working now and may require a bit of effort to get working.
18:48 whiteknight but once we get them building, I think we really do need to be smoking them regularly
18:48 dukeleto where do they live currently?
18:48 tadzik ~~
18:48 whiteknight ideally, I would like to see lots of stuff like our trace core, debugger, and various other things being handled with those PMCs
18:48 dukeleto tadzik: howdy
18:48 cotto_work whiteknight: that's quite possible.
18:48 cotto_work dukeleto: just a sec
18:49 whiteknight https://github.com/khairulsyamil/parrot-instrument
18:49 whiteknight also, I had a fork of it, but I don't know if I had any changes made to it
18:49 atrodo dukeleto> I might have some old tuits out in the shed.  Not sure how good they are, probably 10 or more years old
18:49 whiteknight yes, I had several fixes on my fork
18:50 cotto_work It's really too bad that khairul didn't stick around.
18:50 cotto_work seen khairul
18:50 aloha khairul was last seen in #parrot 25 days 13 hours ago joining the channel.
18:50 plobsing whiteknight: I am still *not* seeing failures in the build
18:51 whiteknight fiddlesticks
18:51 whiteknight it bugs me that I am seeing them
18:51 plobsing you are now the second victim of my magical machine where everything works, even when it shouldn't (the first being myself)
18:55 bluescreen left #parrot
18:58 bluescreen joined #parrot
18:58 nwellnhof joined #parrot
18:58 vmspb left #parrot
19:02 whiteknight curses
19:02 dalek parrot: fe658a7 | jkeenan++ | MANIFEST.SKIP:
19:02 dalek parrot: Update .SKIP.
19:02 dalek parrot: review: https://github.com/parrot/parrot/commit/fe658a7cfb
19:13 cotto_work whiteknight: do you recall what your fixes to gsoc_instrument were?
19:15 whiteknight There are only about 5 commits on my fork. Easy to peruse
19:16 cotto_work yeah.  I like seeing that you made some oplib fixes.
19:22 cotto_work looks like a good start for fixes
19:25 whiteknight what I did at the time was incomplete because I didn't understand the oplib changes very well
19:25 whiteknight I understand them better now, but maybe not enough still to completely fix it
19:30 cotto_work I'd really like to get it working.  I'm on the fence about bringing it into core.
19:30 bluescreen left #parrot
19:31 cotto_work It's potentially valuable and pretty sensitive to internals changes, but we also eventually have to start supporting important stuff libraries core.
19:32 whiteknight yeah, I'm a little bit more luke-warm about bringing it into core now
19:33 whiteknight by having it external, and using it to build some important tools, we put out the idea that our system is more modular and more open to external development
19:33 whiteknight that is, there isn't one official debugger from which all other debugging tools must derive, there are a set of tools and build what you may
19:34 cotto_work at the same time, I really don't want it to bitrot once we finally pull together the tuits to get it working.
19:34 whiteknight that's why continuous integration is so crucial
19:34 cotto_work exactly
19:34 whiteknight we should be building and smoking tools like that on a very regular basis
19:35 cotto_work If our CI is solid, I'm comfortable with it staying external.
19:35 cotto_work s/If/Once/
19:35 whiteknight and we should build up its test suite as much as possible, including move some related tests from our core repo out to it
19:36 cotto_work Its tests aren't too bad.
19:36 whiteknight okay
19:37 whiteknight somewhere in my imcc_compreg_pmc branch I'm corrupting memory, and I don't know where
19:37 cotto_work If they pass, I'll feel pretty confident that the project is working.
19:37 whiteknight it happens in ops2c, even when I specially engineer it so that it never calls into IMCC
19:37 cotto_work memcheck?
19:37 whiteknight yeah, I think I have to look at that
19:38 plobsing whiteknight: perhaps you are changing the memory-allocation patterns and exposing an existing bug. wouldn't be the first time.
19:38 whiteknight it's possible. Considering the scope and magnitude of my changes, however, It's more likely that I screwed the pooch
19:45 whiteknight and now I need to re-learn how to read the output from memcheck
19:46 Eclesia I have an error in a grammar file, for some reason it doesnt reconize the last line of my test : http://pastebin.com/fwv5frPC
19:46 Eclesia could someone tell me what I did wrong ?
19:48 whiteknight try changing the expression rule to parse <addition> first
19:49 Eclesia whiteknight: it loops
19:49 whiteknight weird
19:49 whiteknight try adding in a trailing newline?
19:50 Eclesia there is already one
19:50 Tene Eclesia: you really need to move that over to using the expression parser
19:50 whiteknight ah, right. moving addition forward would cause left recursion
19:50 whiteknight fun
19:50 Eclesia hi Tene
19:51 dalek winxed: r783 | NotFound++ | trunk/ (2 files):
19:51 dalek winxed: coerce to destination type in -=
19:51 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=783
19:51 Tene Eclesia: the expression parser is designed to deal with this problem.
19:52 Tene Look at the example in the language shell
19:52 whiteknight yeah, but it still should be parsable without that
19:52 Tene whiteknight: sure, with backtracking, etc.
19:52 whiteknight doesn't NQP implement backtracking?
19:52 Tene Yes, but 'rule' implies :ratchet
19:52 Tene or whatever it's called
19:52 whiteknight ah
19:52 whiteknight so what would it be instead, token?
19:52 Tene You have to turn that off, or use 'regex' and add <ws> all over, etc.
19:53 Tene or add :sigspace
19:53 Tene And, really, using the expression parser ends up being a lot nicer in the end
19:53 Eclesia taht's it, I'm lost :x
19:53 whiteknight blah. I know plenty of parser-theory but lose it with all the perl6 terminolody
19:53 whiteknight terminology
19:54 whiteknight but yes, the expression parser is the right tool for the job
19:54 mtk left #parrot
19:55 Tene Eclesia: the problem is that it successfully parses an id, and then gets to trying to parse the ; and finds a + instead, so it just gives up.
19:55 Eclesia okay, *will learn something new today*. what it that ? it replaces the grammar file ? and where can I found an example
19:55 Tene Because backtracking is disabled
19:55 Tene Eclesia: You could just run the language shell generator again in a different dir
19:56 Eclesia that will generate a grammar file, at least it did the last time. I haven't seen something that might look like an expression parser
19:56 whiteknight it should be something "is optable" or something like that
19:57 whiteknight it's been a while since I worked on it
19:57 arnsholt whiteknight: I agree that the terminology can be a bit distracting, but it's pretty simple at the base. Anything that isn't called regex doesn't backtrack, essentially
19:58 mtk joined #parrot
19:58 whiteknight okay, so regex backtracks, but doesn't automatically disregard whitespace?
19:58 Tene whiteknight: that's right.  You can add :sigspace to turn that on
19:58 whiteknight okay, so regex :sigspace is what we're looking for?
19:59 Tene whiteknight: That would probably work, yes.
19:59 arnsholt regex :sigspace would backtrack, and additionally add <.ws> calls where you have whitespace in the regex
20:01 * Eclesia runned the mk_language_shell.pl again but don't see anything special
20:01 Tene Eclesia: check out Grammar.pm, specifically: token term:* and token infix:*
20:02 Eclesia I see some infix at the end. token infix:sym</>  { <sym> <O('%multiplicative, :pirop<div>')> }
20:02 Eclesia what are those ? infix term ?
20:02 Eclesia circumfix
20:04 benabik In NQP, it's not "is optable".  The EXPR rule is simply special.
20:04 Tene Eclesia: Let me show you a working version:
20:05 Tene https://gist.github.com/811670
20:05 Tene This parses your addition test.
20:07 Tene updated to add --target=parse output
20:07 * Eclesia found in the doc the part about protofunction
20:07 Tene The O grammar rule is used to deal with precedence levels
20:08 Tene So at INIT time I call it to create a precedence level called %additive
20:08 Tene This precedence level is left-associative, and has precedence of 'u'.  Precedence levels are simply alphabetically sorted.
20:08 Tene It can really be any text at all.
20:11 * Eclesia needs a few minutes to read the doc and understand...
20:11 Tene Then, in the infix:sym<+> token, I call back into the O rule to say what precedence level i'm associated with.
20:11 benabik Eclesia: Not sure if more documentation is the solution, but I recently wrote an overly detailed overview of PCT for my compiler class: http://www.cs.rit.edu/~bcg278​4/Courses/20102/Compiler/PCT/
20:13 benabik (And if anyone else wants to tell me how wrong I was, let me know.  I wrote it in a very hurried week, learning as I went.)
20:13 Tene Eclesia: I updated the example output.
20:15 Tene Eclesia: So, the EXPR rule is built in, and it uses grammar rules in the term, infix, prefix, postfix, and circumfix protos.
20:15 Eclesia wait wait wait, I'm sill completly lost :D
20:15 benabik Also postcircumfix
20:15 Tene ah, right.
20:15 Eclesia still*
20:16 Tene Eclesia: are you familiar with a "precedence level" in terms of an expression parser like this?
20:16 Eclesia no ...
20:16 Tene Ahh, okay.  I was assuming more parsing knowledge.  I'll go a step back.  :)
20:17 Tene When we want to parse an expression tree like this, there are two major attributes of the categories of operators, precedence and associativity.
20:17 * Eclesia can parse tiff file or a jpeg2000 but not text stuffs :x
20:18 Tene precedence is the difference in parsing "1+2*3" as ((1+2)*3) and (1+(2*3))
20:18 Tene In normal math, addition has lower precedence, which means that multiplication binds tighter.
20:19 Eclesia I see
20:19 benabik binds tighter = gets done first = is deeper in the parse tree.
20:19 Tene So we'd end up parsing "1+2*3" as (1+(2*3))
20:20 moritz rakudo: say 1 + 2 * 3
20:20 p6eval rakudo 2666b6: OUTPUT«7␤»
20:20 Tene Now, *within* a single precedence level, like "1+2+3+4", there's a question of associativity, which is the differnce between (1+(2+(3+4))) and (((1+2)+3)+4)
20:21 Tene with addition, it turns out to not matter, but with some other operators it does
20:21 Tene Is "1/2/3" ((1/2)/3) or (1/(2/3)) ?
20:22 Tene The first would be left-associative, and the second would be right-associative.
20:22 * Eclesia understand so far
20:23 Tene The reason we have this separate expression parser is that when parsing languages, some things are nicer with top-down parsing, and some things are nicer with bottom-up parsing.
20:23 Tene When trying to parse expressions like this in a top-down way, it's easy to get weird bugs, like the infinite recursion you were seeing, and other difficulties.
20:24 Tene It's easier to break it down into terms and operators, and then build up a parse tree out of those, which is what the EXPR rule does.
20:24 Tene Do you understand "infix", "prefix", "psotfix", "circumfix", etc?
20:24 Eclesia no ...
20:24 Tene That's fine.  It's jargon.  :)
20:25 Tene Infix operators go between two terms, like +, -, *, etc.
20:25 Tene Infix operators take two arguments (generally).
20:26 Tene Prefix operators go in front, and take one argument, like the ++foo preincrement operator, or ±3
20:26 moritz a term is something like a number, or a string, or a (1+2)
20:26 Tene Postfix operators go after something and take one argument, like the foo++ postincrement operator, or... lemme find another example :)
20:27 moritz 5! in math would be factorial of 5
20:27 * benabik checks his periodic table of operators
20:27 Tene Yeah, or 5i for imaginary
20:27 Tene or maybe the ° in 5°
20:27 fperrad left #parrot
20:28 Eclesia I suppose circumfix goes around.
20:28 Tene circumfix operators go around a term, like (), [], <>, etc.
20:28 Tene Yeah.
20:29 Tene For example, I've defined ⦃ ... ⦄ as a Set constructor before.
20:29 Tene or maybe [ ... ] is for making lists or something
20:30 Tene or ⟅ ... ⟆ as a Bag constructor
20:30 * Eclesia wonders whereto find those characters on the keyboard lol
20:30 Tene as moritz said, terms are individual items, which are anything from strings, numbers, etc. or the results of other expressions
20:30 dalek winxed: r784 | NotFound++ | trunk/winxedst (2 files):
20:30 dalek winxed: fix old mistake in operator precedence in both stages
20:30 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=784
20:31 Tene so, like + takes two terms, so 1+2+3 has two operator nodes in its parse tree
20:31 whiteknight perl6 people have keyboards that none of the rest of us has
20:31 Tene one has the children 1 and 2, and the second has the other node as the first child, and 3 as the second.
20:31 NotFound Looks like precedence is the hot topic of the day ;)
20:31 Tene so liek ((1+2)+3)
20:32 plobsing Eclesia: vim -c ':help digraph'
20:32 Tene You can define whatever you like as a term, for example I've defined term:sym<∅> as a literal for the empty set before
20:33 whiteknight crafty
20:33 Tene other examples could include π as a literal for pi
20:33 Tene or maybe ∞
20:33 Tene you certainly could just include π in your number rule, though.
20:34 Tene It's entirely up to you how you want to break things out.
20:34 Tene For each term: proto, you'll have a corresponding method in your action class to generate an AST for it
20:34 Tene as well for each operator proto
20:35 Tene Does that start making more sense now?
20:36 Eclesia for some parts yes.
20:36 Tene What parts would you like more explanation of?
20:36 Eclesia <sym> <O('%additive')>
20:37 Eclesia the order is strange (at least for me)
20:38 Eclesia hm let me say it another way
20:39 Eclesia the infix seems to wwork againt 'term' objects
20:39 Eclesia I see this 'sym' keyword a bit everywhere. I don't understand what it is
20:39 benabik It's part of proto...
20:39 Tene <sym> just matches whatever was in the :sym<...> part of the proto
20:40 Tene so for infix:sym<+>, <sym> matches '+'
20:40 benabik Yes, that's a simpler way to say what I was trying to get to.
20:40 Eclesia the full word for sym is ?
20:40 benabik symbol, I believe.
20:40 Tene You don't need to use it; it's just a convenient shorthand.
20:41 Tene You could say: token infix:sym<fqhhhhhqlrlmlmrl> { '+' <O('additive') }
20:41 Tene And it would work the same, except it might be confusing for the next person to read the code. :)
20:41 Tene Except I left out a >
20:42 Tene You may notice that my typing leaves something to be dsired (like the letters in the right places) :)
20:42 benabik That token's pretty aptly named...  That's approximately what I'd say if I had to read a grammar like that. ;D
20:42 Tene Hahaha
20:43 Tene Eclesia: So, the reason that the O rule is after the <sym> is because it has to know which rule matched before it can attach the right information to the match node.
20:43 Tene consider infix:sym<+> { <sym> ...} infix:sym<*> { <sym> ... }
20:44 Tene The way the protoregex matcher works is it looks at those rules and figures out what they start with, and then looks at the text it has to see which rule to go to, approximately.
20:45 Tene So if it's a '+', it goes to the infix:sym<+> rule, which successfully matches '+', and then it runs the O rule, which attaches additional metadata to the parse node.
20:46 Tene Does that make the ordering make more sense?
20:47 * Eclesia won't say yes. but won't say no either
20:47 Tene :)
20:47 Tene I think I've run out of questions to try to answer.  Is there anything you'd like me to explain further right now?
20:48 benabik I should probably try it, but I doubt the other way round would fail...  It just puts the parsing details before what actually gets parsed, which is hard to read.
20:48 benabik s/doubt the/doubt that the/
20:50 Tene benabik: to do it in a top-down way, you have to write a lot of the parsing details into your rules.  Backtracking, anchors, etc.  It gets all mixed up and ugly.
20:50 Eclesia I have no more questions so far. I don't really understand how it works, I guess a long night will help
20:50 Tene Eclesia: Glad I could help. :)
20:51 Tene Eclesia: If you want to think about it in a purely functional way, you can get pretty far.  Just define term: and infix: and whatever rules, and some precedence levels, and it just works.
20:51 benabik Tene: I just meant using <O()> <sym> instead of sym O
20:51 * Eclesia is starting to wonder if it's possible to implement a language on parrot without learning perlish syntax, strange regex and pir.
20:51 whiteknight :)
20:51 NotFound Eclesia: it is
20:52 Tene Eclesia: It certainly is, several people have done it.
20:52 Tene Well, I don't know about not learning PIR at all...
20:52 NotFound Well, except maybe the pir part
20:52 whiteknight I'm going to print that quote out, frame it, and point to it the next time somebody questions my "not everybody wants to use NQP" hypothesis
20:52 Tene but that should be possible soon, with the POST->pbc stuff
20:52 NotFound Tene: then you'll need to learn POST, wich is probably harder than pir.
20:53 Eclesia so what other solution are there, maybe the TCL is not suited for me.
20:53 Tene whiteknight: they'll have to learn *SOME* language, surely...
20:53 whiteknight POST is just a set of objects
20:53 NotFound Eclesia: take a look at winxed sources
20:54 whiteknight yeah, because C++ is such a big improvement
20:54 whiteknight </dripping sarcasm>
20:54 plobsing see also Ωη which implements grammars on top of winxed
20:54 Tene Eclesia: Is there a parsing technology you're more-comfortable with?
20:55 plobsing whiteknight: winxed implements a parrot-hosted grammar without using NQP or PCT
20:55 whiteknight I'm telling you, we need LALR eventually
20:55 whiteknight plobsing: yeah, I know.
20:55 NotFound plobsing: Is now possible to implement a full language with ohm-eta?
20:55 Eclesia Tene: if it could be in a SINGLE language. with more usual syntax like (C/Java) I guess it would help
20:56 plobsing NotFound: as far as I know, it should be possible. there are grammars for various languages in OMeta, so I intend to try it sometime.
20:56 whiteknight I would be very interested to see any positive result
20:56 plobsing for every language which there is an ometa implementation, there is an ometa grammar for that language.
20:57 whiteknight including Winxed?
20:57 plobsing C#, JavaScript, SmallTalk
20:57 Tene Eclesia: There's a slow conversation going on right now about the needs for the language to present to parrot developers, should we replace NQP, should we have a PIR equivalent, etc.
20:57 Tene Eclesia: As a new Parrot user, your input on that would likely be appreciated.
20:58 plobsing whiteknight: I cheated a bit. OK, a lot. But I do parse most of the toplevel syntax of Winxed and post-process it into an executable form (which happens to also be Winxed).
20:58 whiteknight oh, nice
20:58 NotFound Winxed syntax is not very regular, and subject to change, to try to define a formal grammar right now, IMO.
20:58 plobsing which is why I had to cheat
20:58 Tene Eclesia: On the other hand, I don't actually know what a language grammar written in C or Java only would look like.  Parsing seems like an appropriate place to have a different language from the rest of your implementation.
20:58 Eclesia Tene: my view might not be neutral, I have a long experience is java so ...
20:59 Tene Eclesia: Sure, but nobody's going to be neutral. :)
20:59 arnsholt In C or Java I suppose some kind of LALR (yacc) grammar would be likely
21:00 arnsholt (But ANTLR is actually LL, now that I think about it)
21:01 Eclesia actually even the regex expression took me an adaptation time. like for example java [0-9] becomes [0..9]
21:02 NotFound There are lots of good grammar tools, but I wrote the first winxed implementation in record time with C++ and without any of such tools ;)
21:02 arnsholt Yeah, that's a bit odd even if you're coming from Perl 5, if it's any consolation =)
21:02 mikehh nwellnhof: ping
21:03 arnsholt Yeah, you can definitely write your own parser as well
21:04 nwellnhof mikehh: pong
21:06 Tene Eclesia: The other concern Parrot has is that it wants to own the languages it provides to users, to limit dependencies, limit complexity, etc.
21:06 Tene I'd be very surprised to see Parrot actually adopting Java, for example.
21:08 Tene java-like or c-like syntax, sure, it's possible.
21:08 Eclesia parrot in made of which languages today ? c++ and pir ?
21:09 Tene Parrot itself is written in C.
21:09 plobsing I'm not sure at this point we can come to any reasonable agreement on the matter, although I'd very much like for that to happen. It would be tragic if such disagreements made us stick to the lowest common denominator (PIR).
21:09 Tene Some tools that run on Parrot are written in pir and nqp, mostly.
21:10 NotFound In C, restricted to the subset compatible with C++
21:11 Eclesia so I could be possible to offer a toolkit to compile HLL using C and XML. I think it would be work for a wider range of user then perlish things ^^
21:11 Tene additionally restricted mostly to C89
21:11 Tene Eclesia: That would certainly be a welcome addition.
21:12 NotFound Eclesia: all is possible
21:12 mikehh nwellnhof: still getting an intermittent failure with t/pmc/socket_ipv6.t - bind failed: Address already in use - current instr.: 'test_bind' pc 221 (t/pmc/socket_ipv6.t:77)
21:12 Tene I don't think I quite understand what that would actually be, what XML would be doing there, but we'd love to see some variety in toolkits to offer to our users.
21:13 mikehh nwellnhof: (am running with TEST_JOBS=4) but when I re-run is ok (or prove)
21:13 NotFound mikehh: maybe there are some other test also binding a port
21:14 Eclesia Tene: it's just that I would be 100times more confortable an xsd describing what I can do to replace the grammar/action files.
21:14 Eclesia with an xsd*
21:14 nwellnhof mikehh: yes, the test server is a bit fragile because it currently always binds to port 1234. we should try several ports if the first one is in use.
21:14 Eclesia Tene: no special syntax tricks, just tags
21:15 NotFound Maybe it will even be possible to write a xml to pir compiler using schematron or soemthing like that.
21:15 Tene Eclesia: I can't actually figure out what that would look like, but it sounds interesting.  I'd love to see a little sketch or example of what that could look like.
21:15 mikehh nwellnhof: probably one of the other socket tests, it has failed 3 times now out of a few hundred recent tests
21:16 Tene Eclesia: I'm rather skeptical of replacing the actions class with XML... XML doesn't seem like a good general-purpose programming language, and every language I've worked on so far, the actions class does a lot more than just simple transformations.
21:16 nwellnhof mikehh: are you seeing this with the ipv4 test, too? (t/pmc/socket.t)
21:17 Tene https://github.com/tene/steme/b​lob/master/steme/pct/actions.pm is the actions file for my simple scheme implementation.
21:17 whiteknight Tene: are you maintaing that?
21:17 Tene I can imagine an xml-based grammar description, though.
21:17 Tene whiteknight: I haven't done anything to it in over a year, why?
21:18 whiteknight Tene: just wondering. Trying to take stock of projects which are active
21:18 mikehh nwellnhof: no - i've only had t/pmc/socket_ipv6.t fail on the bind to socket and only 3 times in several hundred tests
21:18 NotFound mikehh: Maybe a few retries with a short delay will solve the problem.
21:19 plobsing Eclesia: parrot tries to provide useful defaults. it is accepted that those defaults may not be the best choice for everyone. we're also short on parsing frameworks ATM. maybe you'd like to implement whatever framework you think works best for you.
21:19 plobsing and provide it as a library
21:19 Tene whiteknight: it seems to still work fine, fwiw
21:19 whiteknight A good XML reader library would be a nice first step. Then we could use that as a basis for doing domain-specific things with XML
21:19 whiteknight Tene: oh, awesome
21:20 mikehh NotFound: probably, was just reporting it, don't know if anyone else has seen it
21:20 whiteknight I think fperrad has been maintaining it somewhat
21:20 Tene oh, maybe
21:21 Tene yeah, the last two commits were from him
21:21 Tene december 2009, though
21:21 Tene unless he forked it?
21:21 whiteknight Does it have a good test suite? We could add it to dukeleto's smoker
21:21 Tene looks like the macros test doesn't pass right now
21:22 Eclesia plobsing: what is the expected language of the 'library'. pir ?
21:22 nwellnhof mikehh: the socket test servers definitely should try several ports. it's on my todo list.
21:22 whiteknight say("omgwtf eval a macro");
21:23 mikehh nwellnhof: great, thanks
21:23 plobsing Eclesia: whatever language you'd like, so long as it runs on parrot (if you want your library to run on parrot)
21:23 plobsing Eclesia: check out plumage for how parrot intends to manage library distribution/installation/management
21:24 Tene Eclesia: If you do put together some examples of what this might look like, please do let me know.
21:25 plobsing For example, little if any of Winxed is implemented in PIR.
21:26 NotFound plobsing: just a few pirops in stage 1
21:27 NotFound Stage 0 is C++ and make, stage 1 is winxed and json.
21:27 nwellnhof how do i rethrow an exception in pir?
21:27 whiteknight nwellnhof: there is a rethrow op, or you can use throw again
21:28 whiteknight rethrow, as we've found recently, has some weird sideeffects
21:28 plobsing but throw clobbers the original error site
21:28 whiteknight but it does keep an extended backtrace now
21:29 whiteknight so you lose the original error context, but you keep a string-based backtrace
21:29 whiteknight anyway, /me has to pack up and go home
21:29 whiteknight left #parrot
21:30 plobsing and of course, the whole thing is unsuitable for implementing a large set of exception systems (eg: javascript, perl, etc) because of the assumptions it makes
21:34 * Eclesia will try to think about something.
21:34 Eclesia I have to go +++
21:35 Eclesia left #parrot
21:37 vmspb joined #parrot
21:41 dalek parrot: 2c89624 | nwellnhof++ | t/pmc/ (2 files):
21:41 dalek parrot: [t] Make IPv6 test server try several ports
21:41 dalek parrot: review: https://github.com/parrot/parrot/commit/2c89624a9a
21:43 nwellnhof mikehh: that commit should make sure we always find a free port.
21:53 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#7439) fulltest) at 3_0_0-457-gfe658a7 - Ubuntu 10.10 i386 (g++-4.5)
21:53 mikehh nwellnhof: great - nwellnhof++
21:55 wknight-phone joined #parrot
21:57 plobsing is there any documentation of how I might go about using TAP::Harness in a push-parser style?
22:00 dalek parrot: eb13b10 | nwellnhof++ | t/pmc/ (2 files):
22:00 dalek parrot: [t] Do the same for IPv4 test
22:00 dalek parrot: review: https://github.com/parrot/parrot/commit/eb13b10302
22:00 rurban_ joined #parrot
22:02 rurban left #parrot
22:02 rurban_ is now known as rurban
22:04 mtk left #parrot
22:13 wknight-phone left #parrot
22:14 cotto_work msg whiteknight gsoc_instrument could use some help from you.  It looks like it depended on some functions that got cleaned up in your refactoring.
22:14 aloha OK. I'll deliver the message.
22:19 contingencyplan left #parrot
22:42 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#7448) fulltest) at 3_0_0-459-geb13b10 - Ubuntu 10.10 i386 (g++-4.5 with --optimize)
23:10 dalek ohm-eta-wink-kzd: ebd851a | plobsing++ | t/harness:
23:10 dalek ohm-eta-wink-kzd: add test harness to ignore winxed warnings and produce/consume proper tap
23:10 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/ebd851a134
23:10 dalek ohm-eta-wink-kzd: 4273c40 | plobsing++ | t/character-classifier.Ωη:
23:10 dalek ohm-eta-wink-kzd: update number of tests
23:10 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/4273c40462
23:10 dalek ohm-eta-wink-kzd: ba60895 | plobsing++ | Makefile:
23:10 dalek ohm-eta-wink-kzd: add test target
23:10 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/ba608959cf
23:10 dalek ohm-eta-wink-kzd: 3499fe3 | plobsing++ | Makefile:
23:10 dalek ohm-eta-wink-kzd: add uninstall rule and correct install rule
23:10 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/3499fe3502
23:14 Andy left #parrot
23:19 kid51 joined #parrot
23:26 mikehh rakudo (9242428) - builds on parrot (3_0_0-459-geb13b10) - make test, make spectest_smolder[(#7458), roast (0484877)] PASS - Ubuntu 10.10 i386 (gcc-4.5 with --optimize)
23:26 mikehh 27,634 ok, 0 failed, 610 todo, 1,847 skipped and 0 unexpectedly succeeded
23:32 sheant left #parrot
23:36 dalek plumage: 980c771 | plobsing++ | plumage/metadata/ohm-eta.json:
23:36 dalek plumage: add Ωη
23:36 dalek plumage: review: https://github.com/parrot/​plumage/commit/980c771739
23:38 NotFound plobsing++
23:40 dalek winxed: r785 | NotFound++ | trunk/winxedst (2 files):
23:40 dalek winxed: operator '^'
23:40 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=785
23:44 vmspb left #parrot
23:49 whiteknight joined #parrot
23:54 cotto_work whiteknight: ohai
23:55 whiteknight lolwut?
23:55 cotto_work I fixed some of the easy stuff in gsoc_instrument.  It's still broken though.
23:57 whiteknight okay, what functions was it using that I removed?
23:58 cotto_work interp->output_file and imcc_run_api are tripping it up
23:58 whiteknight oh, awesome
23:59 cotto_work that's against master (maybe a few days old)

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

Parrot | source cross referenced