Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches
Set by moderator on 31 January 2011.
nwellnhof sitewat.ch/en/Advisory/View/1 00:09
Send an email to majordomo's mail interface with the body of the message as follows: help ../../../../../../../../../../../../../etc/passwd
cotto_work ow 00:10
Hackbinary huh?
tadzik always funny 00:15
cotto_work I'm a little surprised nobody thought to try that earlier. 00:18
dukeleto Hopefully that motivates people to not use Majordomo 00:22
Hackbinary do ppl still majordomo? 00:35
00:39 vmspb left 00:41 kid51 joined
nwellnhof Hackbinary: it was discovered by Mozilla, they still use it. 00:45
cotto ~~ 00:50
bacek_at_work cotto, ENOTMATCH :) 00:52
00:53 bluescreen left
bacek_at_work whiteknight, which branch? 00:54
whiteknight bacek: whiteknight/imcc_compeg_pmc
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
bacek_at_work whiteknight, ok :) 00:55
whiteknight the hard part is understanding why it's broken 00:56
dalek rrot: 09dc23b | NotFound++ | src/pmc/ (2 files):
rarrange initialization and freeze/thaw of FIA and RIA to avoid redundant code and duplicated storage in RIA
 01:00
bacek_at_work whiteknight, because you broke it? :) 01:05
01:12 NotFound_b left 01:21 wknight-phone joined 01:28 nwellnhof left 01:36 wknight-phone left 01:43 contingencyplan left 01:44 kid51_at_dinner is now known as kid51 01:46 contingencyplan joined
dukeleto ~~ 01:56
nopaste "kid51" at 192.168.1.3 pasted "comp_reg branch: src/dynoplibs/trans_ops.c: seg fault" (842 lines) at nopaste.snit.ch/30382 01:59
02:33 whiteknight left 03:06 shortcircuit left 03:55 benabik joined 04:02 kid51 left 04:19 mtk left 04:26 mtk joined
dalek rrot/generational_gc: 75902a0 | bacek++ | src/gc/ (3 files):
Properly initialize GMS. I have no idea how it used to work before
 05:34
KaeseEs that's a hell of a commit msg :V 05:35
cotto is curious 05:39
All it's missing is some very rude English. 05:40
I completely agree with that commit message.
bacek, how was your code even being run? 05:44
sorear KaeseEs: quite a lot of real world code only works by accident... parrot is sadly no exception 05:46
cotto ccache++ 05:47
05:56 simcop2387_ joined 05:58 simcop2387 left, simcop2387_ is now known as simcop2387 05:59 rurban_ joined 06:02 rurban left, rurban_ is now known as rurban
bacek_at_work cotto, I have no idea... But new GC was definitely used before. 06:09
nopaste "bacek" at 192.168.1.3 pasted "Current list of test failures on gen_gc branch." (26 lines) at nopaste.snit.ch/30433 06:10
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:17
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:18
bacek_at_work cotto, I've spent last few days in gdb... It was definitely hitting GMS. 06:21
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.
nopaste "bacek" at 192.168.1.3 pasted "gen_gc vs master build times" (20 lines) at nopaste.snit.ch/30434 06:23
bacek_at_work yes. Now rakudo's make fails on gen_gc. In generating core.pir. 06:24
cotto I like the speed. bacek++
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
Why do we need separate string gc code? 06:26
bacek_at_work STRINGs are slightly special 06:30
And treated separately in GC.
Not actually bad thing because it gives performance boost "for free" 06:31
cotto Is it documented anywhere how they're special?
bacek_at_work For example STRINGs doesn't have interior pointers.
And we compact them.
And can share underlying buffers. 06:32
Almost encapsulated inside String_GC.
07:06 fperrad joined 07:21 cognominal left 07:28 benabik is now known as benabik_sleep 07:29 cosimo joined 07:31 cosimo left, cosimo joined
dukeleto ~~ 07:51
07:52 benabik_sleep left, contingencyplan left, Infinoid left, extreme left, particle left, elmex left, estrabd left, preflex left, jasonmay left, dngor left, sECuRE_ left, hatseflats left, KaeseEs left 07:53 frodwith left, mj41 left, Util left, rblackwe_ left, confound left 07:58 particle joined, benabik_sleep joined, contingencyplan joined, Infinoid joined, extreme joined, elmex joined, estrabd joined, preflex joined, jasonmay joined, dngor joined, KaeseEs joined, confound joined, Util joined, rblackwe_ joined, mj41 joined, sECuRE_ joined, hatseflats joined, frodwith joined 08:29 theory left 08:53 cosimo left 09:19 davidfetter joined 10:55 contingencyplan left 10:58 KaeseEs left 11:26 davidfetter left 11:58 KaeseEs joined 12:06 mtk left 12:13 mtk joined 12:49 bluescreen joined 13:07 kid51 joined 13:08 plobsing_ left 13:18 kid51 left 13:34 bluescreen left 13:39 bluescreen joined 13:41 bluescreen left, whiteknight joined 13:42 bluescreen joined
whiteknight good morning, #parrot 13:45
13:47 bluescreen left 13:48 bluescreen joined 13:50 bluescreen left, bluescreen joined 13:53 cognominal joined 13:59 rurban_ joined 14:02 rurban left, rurban_ is now known as rurban
dalek TT #1996 created by NotFound++: Function Parrot_ext_try for extenders 14:44
TT #1996: trac.parrot.org/parrot/ticket/1996
14:53 jan joined
dalek rrot: 668635f | NotFound++ | / (3 files):
add function Parrot_ext_try and use it in extend_vtable tests
 14:55
14:55 nwellnhof joined
rrot: ddcab21 | NotFound++ | api.yaml:
experimental notice for Parrot_ext_try, TT #1996
15:07 bluescreen left
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.
moritz if it tests for an exception being thrown... :-)
NotFound TODO freeze + thaw are borked 15:12
IMO what's borked is the test
dukeleto: ping 15:14
whiteknight good morning HackBinary
Hackbinary it's afternoon here, 1515 15:15
;)
NotFound whiteknight: please take a look at TT #1996 15:16
whiteknight seen Yuki'N? 15:17
aloha Sorry, I haven't seen Yuki'N.
whiteknight NotFound: Yes, I've been watching
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
NotFound Yes, but tries to be more friendly to extension code. 15:19
whiteknight yes
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:20
otherwise, function looks good 15:21
NotFound Yes, that point should be improved later.
whiteknight: What do you think about the extend_vtable first test? 15:22
15:22 bluescreen joined
whiteknight I have to look at it 15:28
Yes, that does look broken to me 15:29
what does it output?
NotFound Exception is: type 36 severity 2 message 'push_integer() not implemented in class 'Integer'
whiteknight and the test passes? 15:30
NotFound Is TODOed
whiteknight okay
The test is definitely broken
NotFound Using a RIA as freeze destination may work. 15:31
15:35 benabik_sleep is now known as benabik
whiteknight I don't know enough about that code. It's a plobsing question until I can research it more 15:43
NotFound github blames dukeleto 15:44
The following paths are ignored by one of your .gitignore files: 15:47
t/src/extend_vtable.t
WTF?
Oh, nice: /t/src/*_* 15:48
whiteknight ...lol?
I wonder what the point of that is
NotFound The *_n.c files, I guess 15:49
whiteknight ah yes, that's probably it
maybe rename the test file to t/src/vtableextend.t
or change the rule to /t/src/*_*.c 15:50
dalek rrot: 555b42e | NotFound++ | / (2 files):
fix and untodo extend_vtable is_equal_num test and fix a pitfall in gitignore with that file
 15:52
NotFound The bug in is_equal num was funny. 15:53
Boys, don't try to mix printf and Parrot_printf at home. 15:54
whiteknight :) 15:58
Hackbinary tene: ping 16:09
16:10 plobsing joined
dalek rrot: 93a0806 | NotFound++ | t/src/extend_vtable.t:
fix a mistake in Parrot_ext_try usage that breaks tests in C++ build
 16:11
16:16 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner 16:23 Kovensky left, theory joined 16:30 Kovensky joined
dalek rrot: 054e36b | NotFound++ | t/src/extend_vtable.t:
fix, untodo, and improve extend_vtable freeze|taw test
 16:31
cotto_work `` 16:37
whiteknight '' indeed 16:49
dalek rrot: 50e3be1 | NotFound++ | runtime/parrot/library/NCI/Utils.pir:
fix impedance decoupling between NCI/Utils and UnmanagedStruct
 16:59
dukeleto ~~ 17:28
plobsing ping NotFound 17:32
NotFound plobsing: please take a look at 054e36b 17:33
17:35 Andy joined
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.
whiteknight you know what they say about the best intentions....
....they're not usually found in Parrot
NotFound plobsing: at least looks more plausible that freezing to a Integer 17:42
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.
whiteknight VTABLE_freeze, _thaw, and _thawfinish really shouldn't be exposed to extenders
dukeleto NotFound: i knew i was writing those freeze/thaw tests incorrectly, but i didn't quite know how to make them right
whiteknight: i kind of agree
whiteknight We have interface functions Parrot_freeze and Parrot_thaw that do what is needed, those vtables are too low-level and primitive
plobsing whiteknight: not necessarily true. see github.com/plobsing/parrot-deepclone for an example of intended use. 17:44
I agree they are somewhat confusing and think they should have big nasty documentation deriding the intelligence of people considering using them. 17:45
not really sure how to put that into a generated file though
whiteknight plobsing: all well and good, but nothing I am seeing right now couldn't be rewritten by hll mapping a custom serializer PMC
assuming the freeze/thaw mechanisms are smart enough to allow for HLL maps 17:46
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
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
you want hll-specific freeze/thaw? build that into the objects your HLL generates.
you have that power already
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
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
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
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.
whiteknight: it was expedient. I could have equally used ops.
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
Making them part of the extending interface as-is is probably not a great idea
and exposing them as brain-dead thin wrappers like in vtable_extend.c is no better 17:53
17:53 nwellnhof left
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:53
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
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
that would prevent the kinds of test failures that Notfound fixed
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 17:58
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.
to be as general as possible, we should expose the building blocks. 18:01
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:03
s/embedders/extenders/ 18:04
whiteknight That's fine. I'll follow your lead on that one then
sorear Do we still interpret "extender" = "writes own pmcs and oplibs"? 18:09
whiteknight sorear: yeah. An extension is something called by libparrot
so a custom PMC type, custom oplib type, or other library
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
embedders....not so much
plobsing but they aren't as burdened with knowledge-requirements of intricate details 18:11
whiteknight right, exactly. More power, more responsibility
like spiderman, but not ruined by sequels
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
sorear was thinking of dlfunc briefly
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)
whiteknight it is possible to use dlfunc to access an extension
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.
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
and you can't access it without libparrot, unless you blatantly violate our encapsulation rules
plobsing faire nough 18:16
18:19 contingencyplan joined 18:22 bluescreen left, vmspb joined 18:24 bluescreen joined
whiteknight ping cotto_work 18:26
18:27 Eclesia joined
Eclesia hi 18:27
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?
cotto_work hysterical raisins?
I don't know without digging in a bit. 18:29
whiteknight okay
well if you find out that there is no good reason, I'm going to fix it
cotto_work I looked at it for example code for the profiling runcore, but that's about out it.
s/ out//
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
btw, I just tested and the trace core doesn't work in trunk. Probably hasn't since the embed_api merge 18:32
cotto_work if it's not tested... 18:33
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?
whiteknight dukeleto: trace core in master can't currently be activated. If it had tests, I'm sure they would be failing
Notfound: -t, --trace, and -Rtrace
which, by the way, are far too many options
18:36 davidfetter joined
NotFound Last time I checked -t1 worked 18:36
And it was this week
whiteknight you can try it. I did a few tests and the trace core did not work 18:38
so I might be missing something
dalek rrot: fc88de3 | NotFound++ | src/pmc/ (4 files):
rearrange a bit string and pmc arrays initialization and thaw to ensure threshold is always set in the resizable variants
NotFound Sort of. Works is some cases, coredumps in others. 18:40
dukeleto Less Than Awesome. 18:41
We should either write a bunch of tests for the trace core to make sure it works, or remove it.
whiteknight Oh, I didn't see any coredumps. All the tests I did defaulted to using the slow core
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
whiteknight plobsing: ping 18:43
dukeleto has never actually used the trace core
dukeleto just wants stuff to be tested and work (most of the time)
is the trace core subject to the deprecation policy ? 18:44
is it a "user-facing" feature?
whiteknight dukeleto: it's on the commandline
so yes
NotFound If you provide another way to enable trace, having it as a runcore is not mandatory.
plobsing whiteknight: pong 18:45
whiteknight I would really like to get those instrumentation PMCs working again, and start using them for more things
plobsing: have you tested out that imcc_compreg_pmc branch after my changes yesterday?
plobsing whiteknight: haven't had the chance to do so just yet. will do.
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
my problem is definitely a GC bug. If I run Parrot -G, I don't see segfaults
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
dukeleto whiteknight: i am willing to setup some kind of smoking of the instrumentation pmc's if that is possible
whiteknight: where do they live? are they under the parrot github org?
whiteknight dukeleto: They don't build right now, if I remember correctly
dukeleto looks under his couch cushion for some tuits, but only finds a nickel
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
dukeleto where do they live currently?
tadzik ~~
whiteknight ideally, I would like to see lots of stuff like our trace core, debugger, and various other things being handled with those PMCs
dukeleto tadzik: howdy
cotto_work whiteknight: that's quite possible.
dukeleto: just a sec
whiteknight github.com/khairulsyamil/parrot-instrument 18:49
also, I had a fork of it, but I don't know if I had any changes made to it
atrodo dukeleto> I might have some old tuits out in the shed. Not sure how good they are, probably 10 or more years old
whiteknight yes, I had several fixes on my fork
cotto_work It's really too bad that khairul didn't stick around. 18:50
seen khairul
aloha khairul was last seen in #parrot 25 days 13 hours ago joining the channel.
plobsing whiteknight: I am still *not* seeing failures in the build
whiteknight fiddlesticks 18:51
it bugs me that I am seeing them
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 18:58 bluescreen joined, nwellnhof joined, vmspb left
whiteknight curses 19:02
dalek rrot: fe658a7 | jkeenan++ | MANIFEST.SKIP:
Update .SKIP.
cotto_work whiteknight: do you recall what your fixes to gsoc_instrument were? 19:13
whiteknight There are only about 5 commits on my fork. Easy to peruse 19:15
cotto_work yeah. I like seeing that you made some oplib fixes. 19:16
looks like a good start for fixes 19:22
whiteknight what I did at the time was incomplete because I didn't understand the oplib changes very well 19:25
I understand them better now, but maybe not enough still to completely fix it
cotto_work I'd really like to get it working. I'm on the fence about bringing it into core. 19:30
19:30 bluescreen left
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:31
whiteknight yeah, I'm a little bit more luke-warm about bringing it into core now 19:32
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
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
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
cotto_work exactly
whiteknight we should be building and smoking tools like that on a very regular basis
cotto_work If our CI is solid, I'm comfortable with it staying external. 19:35
s/If/Once/
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
cotto_work Its tests aren't too bad. 19:36
whiteknight okay
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.
whiteknight it happens in ops2c, even when I specially engineer it so that it never calls into IMCC
cotto_work memcheck?
whiteknight yeah, I think I have to look at that
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
and now I need to re-learn how to read the output from memcheck 19:45
Eclesia I have an error in a grammar file, for some reason it doesnt reconize the last line of my test : pastebin.com/fwv5frPC 19:46
could someone tell me what I did wrong ?
whiteknight try changing the expression rule to parse <addition> first 19:48
Eclesia whiteknight: it loops 19:49
whiteknight weird
try adding in a trailing newline?
Eclesia there is already one 19:50
Tene Eclesia: you really need to move that over to using the expression parser
whiteknight ah, right. moving addition forward would cause left recursion
fun
Eclesia hi Tene
dalek nxed: r783 | NotFound++ | trunk/ (2 files):
coerce to destination type in -=
 19:51
Tene Eclesia: the expression parser is designed to deal with this problem.
Look at the example in the language shell 19:52
whiteknight yeah, but it still should be parsable without that
Tene whiteknight: sure, with backtracking, etc.
whiteknight doesn't NQP implement backtracking?
Tene Yes, but 'rule' implies :ratchet
or whatever it's called
whiteknight ah
so what would it be instead, token?
Tene You have to turn that off, or use 'regex' and add <ws> all over, etc.
or add :sigspace 19:53
And, really, using the expression parser ends up being a lot nicer in the end
Eclesia taht's it, I'm lost :x
whiteknight blah. I know plenty of parser-theory but lose it with all the perl6 terminolody
terminology
but yes, the expression parser is the right tool for the job 19:54
19:54 mtk left
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
Tene Because backtracking is disabled
Eclesia: You could just run the language shell generator again in a different dir
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
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
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
whiteknight okay, so regex :sigspace is what we're looking for?
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
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:*
Eclesia I see some infix at the end. token infix:sym</> { <sym> <O('%multiplicative, :pirop<div>')> } 20:02
what are those ? infix term ?
circumfix
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:
gist.github.com/811670 20:05
This parses your addition test.
updated to add --target=parse output 20:07
Eclesia found in the doc the part about protofunction
Tene The O grammar rule is used to deal with precedence levels
So at INIT time I call it to create a precedence level called %additive 20:08
This precedence level is left-associative, and has precedence of 'u'. Precedence levels are simply alphabetically sorted.
It can really be any text at all.
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.
benabik Eclesia: Not sure if more documentation is the solution, but I recently wrote an overly detailed overview of PCT for my compiler class: www.cs.rit.edu/~bcg2784/Courses/201...piler/PCT/
(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.
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
benabik Also postcircumfix
Tene ah, right.
Eclesia still*
Tene Eclesia: are you familiar with a "precedence level" in terms of an expression parser like this? 20:16
Eclesia no ...
Tene Ahh, okay. I was assuming more parsing knowledge. I'll go a step back. :)
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
Tene precedence is the difference in parsing "1+2*3" as ((1+2)*3) and (1+(2*3)) 20:18
In normal math, addition has lower precedence, which means that multiplication binds tighter.
Eclesia I see 20:19
benabik binds tighter = gets done first = is deeper in the parse tree.
Tene So we'd end up parsing "1+2*3" as (1+(2*3))
moritz rakudo: say 1 + 2 * 3 20:20
p6eval rakudo 2666b6: OUTPUT«7␤»
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)
with addition, it turns out to not matter, but with some other operators it does 20:21
Is "1/2/3" ((1/2)/3) or (1/(2/3)) ?
The first would be left-associative, and the second would be right-associative. 20:22
Eclesia understand so far
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
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.
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
Do you understand "infix", "prefix", "psotfix", "circumfix", etc?
Eclesia no ...
Tene That's fine. It's jargon. :)
Infix operators go between two terms, like +, -, *, etc. 20:25
Infix operators take two arguments (generally).
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)
Tene Postfix operators go after something and take one argument, like the foo++ postincrement operator, or... lemme find another example :)
moritz 5! in math would be factorial of 5 20:27
benabik checks his periodic table of operators
Tene Yeah, or 5i for imaginary
or maybe the ° in 5°
20:27 fperrad left
Eclesia I suppose circumfix goes around. 20:28
Tene circumfix operators go around a term, like (), [], <>, etc.
Yeah.
For example, I've defined ⦃ ... ⦄ as a Set constructor before. 20:29
or maybe [ ... ] is for making lists or something
or ⟅ ... ⟆ as a Bag constructor 20:30
Eclesia wonders whereto find those characters on the keyboard lol
Tene as moritz said, terms are individual items, which are anything from strings, numbers, etc. or the results of other expressions
dalek nxed: r784 | NotFound++ | trunk/winxedst (2 files):
fix old mistake in operator precedence in both stages
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
Tene one has the children 1 and 2, and the second has the other node as the first child, and 3 as the second.
NotFound Looks like precedence is the hot topic of the day ;)
Tene so liek ((1+2)+3)
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
whiteknight crafty 20:33
Tene other examples could include π as a literal for pi
or maybe ∞
you certainly could just include π in your number rule, though.
It's entirely up to you how you want to break things out. 20:34
For each term: proto, you'll have a corresponding method in your action class to generate an AST for it
as well for each operator proto
Does that start making more sense now? 20:35
Eclesia for some parts yes. 20:36
Tene What parts would you like more explanation of?
Eclesia <sym> <O('%additive')>
the order is strange (at least for me) 20:37
hm let me say it another way 20:38
the infix seems to wwork againt 'term' objects 20:39
I see this 'sym' keyword a bit everywhere. I don't understand what it is
benabik It's part of proto...
Tene <sym> just matches whatever was in the :sym<...> part of the proto
so for infix:sym<+>, <sym> matches '+' 20:40
benabik Yes, that's a simpler way to say what I was trying to get to.
Eclesia the full word for sym is ?
benabik symbol, I believe.
Tene You don't need to use it; it's just a convenient shorthand.
You could say: token infix:sym<fqhhhhhqlrlmlmrl> { '+' <O('additive') } 20:41
And it would work the same, except it might be confusing for the next person to read the code. :)
Except I left out a >
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
Tene Hahaha
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
consider infix:sym<+> { <sym> ...} infix:sym<*> { <sym> ... }
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:44
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:45
Does that make the ordering make more sense? 20:46
Eclesia won't say yes. but won't say no either 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?
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
s/doubt the/doubt that the/
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
Tene Eclesia: Glad I could help. :)
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
Eclesia is starting to wonder if it's possible to implement a language on parrot without learning perlish syntax, strange regex and pir.
whiteknight :)
NotFound Eclesia: it is
Tene Eclesia: It certainly is, several people have done it. 20:52
Well, I don't know about not learning PIR at all...
NotFound Well, except maybe the pir part
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
Tene but that should be possible soon, with the POST->pbc stuff
NotFound Tene: then you'll need to learn POST, wich is probably harder than pir.
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...
whiteknight POST is just a set of objects
NotFound Eclesia: take a look at winxed sources
whiteknight yeah, because C++ is such a big improvement 20:54
</dripping sarcasm>
plobsing see also Ωη which implements grammars on top of winxed
Tene Eclesia: Is there a parsing technology you're more-comfortable with?
plobsing whiteknight: winxed implements a parrot-hosted grammar without using NQP or PCT 20:55
whiteknight I'm telling you, we need LALR eventually
plobsing: yeah, I know.
NotFound plobsing: Is now possible to implement a full language with ohm-eta?
Eclesia Tene: if it could be in a SINGLE language. with more usual syntax like (C/Java) I guess it would help
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
plobsing for every language which there is an ometa implementation, there is an ometa grammar for that language.
whiteknight including Winxed? 20:57
plobsing C#, JavaScript, SmallTalk
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.
Eclesia: As a new Parrot user, your input on that would likely be appreciated.
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
NotFound Winxed syntax is not very regular, and subject to change, to try to define a formal grammar right now, IMO.
plobsing which is why I had to cheat
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.
Eclesia Tene: my view might not be neutral, I have a long experience is java so ...
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
(But ANTLR is actually LL, now that I think about it) 21:00
Eclesia actually even the regex expression took me an adaptation time. like for example java [0-9] becomes [0..9] 21:01
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 =)
mikehh nwellnhof: ping
arnsholt Yeah, you can definitely write your own parser as well 21:03
nwellnhof mikehh: pong 21:04
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
I'd be very surprised to see Parrot actually adopting Java, for example.
java-like or c-like syntax, sure, it's possible. 21:08
Eclesia parrot in made of which languages today ? c++ and pir ?
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).
Tene Some tools that run on Parrot are written in pir and nqp, mostly.
NotFound In C, restricted to the subset compatible with C++ 21:10
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
Eclesia: That would certainly be a welcome addition.
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)
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.
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
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
with an xsd*
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.
Eclesia Tene: no special syntax tricks, just tags
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.
mikehh nwellnhof: probably one of the other socket tests, it has failed 3 times now out of a few hundred recent tests
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)
Tene github.com/tene/steme/blob/master/...actions.pm is the actions file for my simple scheme implementation. 21:17
whiteknight Tene: are you maintaing that?
Tene I can imagine an xml-based grammar description, though.
whiteknight: I haven't done anything to it in over a year, why?
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
NotFound mikehh: Maybe a few retries with a short delay will solve the problem.
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
and provide it as a library
Tene whiteknight: it seems to still work fine, fwiw
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
Tene: oh, awesome
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
Tene oh, maybe
yeah, the last two commits were from him 21:21
december 2009, though
unless he forked it?
whiteknight Does it have a good test suite? We could add it to dukeleto's smoker
Tene looks like the macros test doesn't pass right now
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.
whiteknight say("omgwtf eval a macro");
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)
Eclesia: check out plumage for how parrot intends to manage library distribution/installation/management
Tene Eclesia: If you do put together some examples of what this might look like, please do let me know. 21:24
plobsing For example, little if any of Winxed is implemented in PIR. 21:25
NotFound plobsing: just a few pirops in stage 1 21:26
Stage 0 is C++ and make, stage 1 is winxed and json. 21:27
nwellnhof how do i rethrow an exception in pir?
whiteknight nwellnhof: there is a rethrow op, or you can use throw again
rethrow, as we've found recently, has some weird sideeffects 21:28
plobsing but throw clobbers the original error site
whiteknight but it does keep an extended backtrace now
so you lose the original error context, but you keep a string-based backtrace 21:29
anyway, /me has to pack up and go home
21:29 whiteknight left
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:30
Eclesia will try to think about something. 21:34
I have to go +++
21:35 Eclesia left 21:37 vmspb joined
dalek rrot: 2c89624 | nwellnhof++ | t/pmc/ (2 files):
[t] Make IPv6 test server try several ports
 21:41
nwellnhof mikehh: that commit should make sure we always find a free port. 21:43
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
nwellnhof: great - nwellnhof++
21:55 wknight-phone joined
plobsing is there any documentation of how I might go about using TAP::Harness in a push-parser style? 21:57
dalek rrot: eb13b10 | nwellnhof++ | t/pmc/ (2 files):
[t] Do the same for IPv4 test
 22:00
22:00 rurban_ joined 22:02 rurban left, rurban_ is now known as rurban 22:04 mtk left 22:13 wknight-phone left
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
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) 22:42
dalek m-eta-wink-kzd: ebd851a | plobsing++ | t/harness:
add test harness to ignore winxed warnings and produce/consume proper tap
 23:10
m-eta-wink-kzd: 4273c40 | plobsing++ | t/character-classifier.Ωη:
update number of tests
m-eta-wink-kzd: ba60895 | plobsing++ | Makefile:
add test target
m-eta-wink-kzd: 3499fe3 | plobsing++ | Makefile:
add uninstall rule and correct install rule
23:14 Andy left 23:19 kid51 joined
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
27,634 ok, 0 failed, 610 todo, 1,847 skipped and 0 unexpectedly succeeded
23:32 sheant left
dalek umage: 980c771 | plobsing++ | plumage/metadata/ohm-eta.json:
add Ωη
 23:36
NotFound plobsing++ 23:38
dalek nxed: r785 | NotFound++ | trunk/winxedst (2 files):
operator '^'
 23:40
23:44 vmspb left 23:49 whiteknight joined
cotto_work whiteknight: ohai 23:54
whiteknight lolwut? 23:55
cotto_work I fixed some of the easy stuff in gsoc_instrument. It's still broken though.
whiteknight okay, what functions was it using that I removed? 23:57
cotto_work interp->output_file and imcc_run_api are tripping it up 23:58
whiteknight oh, awesome
cotto_work that's against master (maybe a few days old) 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!