Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere
Set by moderator on 18 May 2010.
sorear Util: NQP-rx does not have an Agenda per se; we take feature requests from the public and implement what people want (as long as it doesn't involve "become perl6" or "become PIR") 00:00
darbelo sorear: Become python!
;)
sorear chromatic: I was involved (barely) with GHC in 2007; I might know something
tcurtis: Yuck, "see comments" IS A PERMISSION?! 00:03
sorear spits
chromatic I wonder if C-- might make a good model for Lorito ops. 00:04
darbelo sorear: You can't spit on Drupal without extra permissions.
Coke chromatic: I presume you really mean C++?
sorear I can now see 1 comment 00:05
But I can't see any comments on past-pattern-matching
tcurtis darbelo deleted the test comments I made. 00:06
sorear The comment I see is on hybrid threads
Coke: C-- makes more sense than C++ for Lorito...
Coke sorear: I know C-- as "an insulting way to say C++". Is it also an actual thing? 00:07
sorear Coke: yes
chromatic C minus minus.
Coke www.parrot.org/comment/reply/163 has no comments, yes.
chromatic It's a simpler version of C.
tcurtis C-- is used by Haskell as an intermediate representation.
sorear www.cminusminus.org/
darbelo It's intended to be a thing to target compilers to.
sorear (GHC Haskell) 00:08
C-- has one little problem for us.
It's an expression form.
Coke Thank you. You might want to spell that out or link to it in docs. =-)
sorear Lorito should probably be a bytecode-instruction form to make compiling to it less insane
GHC philosophy is to destructure late; the expressions aren't flattened into an op sequence until the actual code generation 00:09
the ability to re-run static type checks after the optimizer is pretty awesome though
chromatic My idea is to see if we can extract the ops necessary to support the C-- expressions. 00:10
bacek_at_work We don't have to. 00:12
All what we need is way to express current ops in subset of another ops.
chromatic We need a subset of current ops which is both sufficient to represent all other ops and reasonably easy to JIT or otherwise translate to another executable representation. 00:13
sorear Coke: Isn't partcl abandoned and dead? Why do you want to fix it? 00:15
Whiteknight partcl isn't abandoned or dead 00:17
just temporarily not working
darbelo It's jus' restin'
sorear partcl-nqp is the FUTURE
sorear needs to braindump that idea he had earlier for extremely space-efficient sweep-free, generational, and incremental GC 00:18
chromatic Please do.
darbelo sorear: Coke is the author of both partcls, I think he knows which future he wants to pursue. 00:19
Coke sorear: partcl is not dead. 00:20
it's like the old master vs ng for rakudo.
we aren't at the point where we can cutover.
and right now, partcl is one of the few big PGE/TGE implementations.
I just want to get partcl to the point where it passes tests again. it's only broken because parrot isn't standing still. 00:21
more hands on partcl-nqp will help that day come sooner, though. =-) 00:24
00:38 plobsing joined 01:02 ruoso joined 01:04 abqar joined
dalek TT #1587 closed by plobsing++: delete Parrot_PMC_* from src/extend.c 01:10
TT #1587: trac.parrot.org/parrot/ticket/1587
Whiteknight Does GHC interpret Haskell programs, or only compile it to machine code? 01:17
plobsing both IIRC
tcurtis Although there are some syntax differences in ghci(because it's in IO IIRC). 01:19
Whiteknight ok
dalek rrot: r46774 | plobsing++ | trunk (5 files):
remove duplicate embed/extend vtable wrappers
rrot: r46775 | plobsing++ | trunk (3 files):
eliminate vtable hackery from embed/extend interface
plobsing has deleted much code recently. is there any tool to find out my SLOC add/remove ratio? 01:20
cotto_work diffstat
purl i think diffstat is make histogram from diff-output
01:26 TiMBuS joined
dalek TT #1588 closed by plobsing++: Parrot_VTABLE, Parrot_get_vtable, Parrot_PMC_set_vtable 01:26
TT #1588: trac.parrot.org/parrot/ticket/1588
plobsing ooh. TT #449 lets me move the evil ops I recently discovered to dynops. 01:29
bacek_at_work plobsing\t210 (3.26%)\t26280\t18310 01:31
commits, +lines, -lines
2010-05\tplobsing\t59 (14.97% of 394)\tbacek, fperrad, NotFound, mikehh
Author of the month :) 01:32
59 commits
plobsing bacek++ # can I see the commandline-fu for that?
bacek_at_work "gitstats . stats" :)
It generates some html pages
plobsing shakes fist at svn
sorear msg Whiteknight GHC is a compiler. It converts Haskell code through a sequence of IRs then passes it to either a byte-compiler, a custom codegen, gcc, or LLVM. None of the IRs is ever directly interpreted 01:34
bacek_at_work just clone dukeleto's parrot from github
purl Message for whiteknight stored.
sorear msg Whiteknight there are some thoughts to deprecate the bytecode backend. it might already be done by now. the only advantage it ever had was portability, and LLVM takes care of a lot of that 01:35
purl Message for whiteknight stored.
plobsing bacek: regarding deprecating PASM->PBC altogether, I'm in favour of deprecating hand-generated PASM, but I think having an executable textual format of our bytecode is nifty
sorear msg Whiteknight GHC != Haskell; there are several pure-interpreting implementations
purl Message for whiteknight stored.
sorear plobsing: having a *stable* format of our bytecode is a prerequisite for killing IMCC, if we ever want to go that way 01:36
plobsing sorear: please justify that statement. I think if the instability is hiden behind packfile PMCs, we can get along just fine. 01:37
tcurtis sorear, ghci doesn't interpret Haskell? 01:38
plobsing I thought the bytecode (as opposed to native codegen) was interpretation of a sort
sorear plobsing: suppose we break PBC compatibility. You still have the packfile PMCs, but they're useless - to use them you need to run code on Parrot, and you have no code compiled for the new Parrot 01:48
to bootstrap, we need some C code which generates PBC from a stable(r) format
IMCC fills that role now
tcurtis: when the "compiler" and "interpreter" share 95% of the code, I feel it only confuses issues to speak of them separately 01:49
there is one compiler which can target four runtimes
plobsing sorear: if we can compile a minimal subset of parrot bytecode instructions to C, we can cut IMCC out of the loop and still be fine 01:50
I am not against bytecode stability, I'm just against doing what that requires (eg: not changing what PMCs are in core, not changing the internal representations of said PMCs, not changing what ops are in core, etc) 01:51
wait, are we talking about PBC stability or PASM stability or what? 01:52
plobsing needs to eat something to think 01:53
chromatic We could also get around that if we had a PBC migration utility.
01:57 JimmyZ joined
bacek_at_work Speaking of which... Can we deprecate and remove "opsrenumber"? 01:57
Just to preserve stability of ops numbers. 01:58
Coke opsrenumber is an internal, dev only tool.
bacek_at_work: not until you have a plan for dealing with removed ops.
bacek_at_work just left holes in numbering
01:59 snarkyboojum joined
Coke it's /a/ plan, fer shure. 01:59
bacek_at_work what's wrong with this plan??? 02:01
Plus adding something like "pmc.num" to preserve PMCs number
chromatic It keeps opnumbers around. 02:02
bacek_at_work chromatic, ?
purl it has been said that chromatic, is that typical of CG-ed (dynamic) languages?
chromatic Maybe we don't need op numbers.
Coke hopes that someone wasn't waiting until 2.4 release to rip out those deps...
chromatic Or, at least, we don't need a fixed numbering for ops independent of any single PBC file. 02:03
sorear plobsing: I'm not advocating bytecode stability. I'm advocating not removing IMCC until we have the PIR->C compiler working 02:06
cotto_work That'd be fine by me. opsrenumber is kinda hacky and silently depends on the order of ops in src/ops/*.ops *and* the order in which those files are processed.
chromatic Maybe we could solve the dynops numbering problem at the same time. 02:07
Add another header to packfiles: a mapping of op signatures to numbers. Use those numbers pervasively throughout the PBC.
s/header/directory/ 02:08
cotto_work That sounds far-off enough (i.e. not in the next week) that I'll still have to make opsrenumber work in ops_opt.
*ops_pct.
cotto_work decommutes 02:09
chromatic It might be a bad idea, but it's an idea.
dalek kudo: 248ae36 | (Solomon Foster)++ | build/PARROT_REVISION:
Bump parrot to 2.4.0. snarkyboojum++
sorear chromatic: Funny, that's the way I always thought it worked 02:11
How does dynop numbering work currently?
chromatic I'm not sure how it works in the packfiles. 02:12
plobsing back.
dynops get loaded by the compiling interpreter whose state gets frozen into the packfile and merged with the executing interpreter on load 02:13
and hopefully they load the dynop libraries in the same order
02:13 Mokurai joined
sorear so, if A.pir loads liba.so, and B.pir loads libb.so (both dynoplibs), and they're compiled to pbc separately, and loaded into the same interpreter later, things go boom? 02:15
plobsing possibly 02:16
personally, I hate the ParrotInterpreter freeze hack. I'd love to see a dictionary-based solution. 02:17
perhaps with the bytecode version giving a sort of baseline dictionary
AFAIK the same is also true of dynpmc libs 02:20
02:25 parthm joined 02:48 janus joined
dalek rrot: r46776 | plobsing++ | trunk/src (4 files):
move freeze/thaw calls adjacent to visit calls.
 02:58
03:37 LoganLK joined 03:58 snarkyboojum joined 04:16 theory joined
dalek rrot: r46777 | plobsing++ | trunk (5 files):
PBC_COMPAT bump and native_pbc s for r46776
 04:32
cotto svn00
svn--
I'm afraid of conflict. 04:48
dalek rrot: r46778 | cotto++ | branches/ops_pct (87 files):
sync branch with trunk
 04:50
rrot: r46779 | cotto++ | branches/ops_pct (2 files):
manifix
05:06 ruoso joined
dalek rrot: r46780 | cotto++ | branches/ops_pct (3 files):
[opsc] bootstrap ops
 05:07
05:27 theory_ joined
sorear tcurtis: ping 05:31
tcurtis sorear: pong 05:32
sorear I've been charged with redesigning the stage mechanism in PCT 05:33
What do you want to see in it?
cotto hllcompiler.addstage('rainbows', 'after' => 'unicorns') 05:38
Tene isn't that already there? 05:39
chromatic I thought it was too. 05:42
05:46 uniejo joined
tcurtis Question before I can answer that: how are stages associated with names? Is there some PCT::HLLCompiler.registerStage($name, $stage) sub? 05:46
Tene tcurtis: a stage is just a method on the compiler object. 05:47
So you add a method of that name to your HLLCompiler subclass. 05:48
tcurtis Ah. Okay. Hmm... A way of specifying additional stages to run on the command line would be helpful, although it might need a way to specify a file that defines the stage. The use case I'm thinking of there is when a HLL user wants to add run an optimization stage on his HLL code that isn't run by the HLL compiler without having to modify the compiler. 05:51
sorear Now: A HLLCompiler instance is associated with a list of method names to call in order on the source code. 05:52
Future: The stages form a tree, not a list 05:53
and I'm looking for input on how to design the tree modification API
the pipeline needs to be able to branch to handle multiple targets - direct-to-PBC, PIR, interpretation, many more things after PCT is untied from Parrot 05:54
cotto You could have an 'optimizer' stage that processes and runs whatever was passed in on the cli.
If it takes and spits out a PAST or POST, you don't have to care what comes after. 05:55
Tene what language would the stage program be written in?
sorear Are you talking to tcurtis?
Tene For now, just add an extra stage before the PAST compiler and before the POST compiler that look somewhere standard for additional PAST-transforming and POST-transforming stages. 05:56
chromatic Yeah, that's my assumption too.
sorear Who is the addressee here?
tcurtis Tene: that's a better idea. Do stages have access to command-line options? 05:57
sorear tcurtis: there is no "do"
Tene tcurtis: As I said before, stages are just methods on the compiler object.
They have access to whatever methods on the compiler object have access to.
sorear there is potentially a clean slate here
Tene: Who are you telling to just add a stage? 06:01
chromatic: What is your assumption?
sorear is confused
tcurtis sorear: in that case, I want to be able to see the command line from a stage. Then there can be an "optimizer" stage as cotto and Tene suggested that looks at the command line options for something like "--optimizations=tailcallelim" and looks some standard place for tailcallelim.pbc, loads it, and runs the stage.
Tene tcurtis: you need to be careful to distinguish what the stage expects as input and as output. 06:02
a PAST-optimizing stage would be different froma POST-optimizing stage.
chromatic Right. 06:03
PAST optimizations probably get us further.
sorear tcurtis: what part of the universe do you want to be able to modify to add this stage?
Tene tcurtis: Unless you're going to start requiring that HLLs adopt standard options, having HLLCompiler inspect the CLI args sounds like a bad idea. 06:04
tcurtis: I recommend instead just parsing them in the HLL and passing them as named arguments to the compiler 06:05
just like the rest of the adverbs.
sorear Tene: that's the way it used to work and I'm planning to keep it that way
Tene all of the stage methods have a slurpy named parameter.
sorear HLLCompiler has a command line parser which can be used to populate the named parameters 06:06
ie try parrot-nqp --parsetrace -e '2+2'
--parsetrace is an NQP-level addition
However, my original question remains unanswered 06:08
tcurtis: add_stage et al cannot live as currently designed
tcurtis: what would you like to see in their place?
Tene sorear: why can't they live?
sorear because they assume stages are totally ordered 06:09
and pmichaud has asked me to remove that
tcurtis Tene: -e, -h/--help, --target, -t/--trace, --encoding, -o/--output, --combine, -v/--version, and --stagestats aren't standard options for PCT-based compilers? 06:11
sorear: I don't know. Will the desired final output determine the branch of the tree taken? 06:15
dalek kudo: c4de1a7 | (Patrick Abi Salloum)++ | src/core/Hash.pm:
Hash in list context behaves like a list of pairs
 06:20
sorear tcurtis: yes
06:27 fperrad joined
tcurtis I'm not really sure why you're asking me specifically, but here's an idea.... If you're dispatching based on the final output, why not, instead of a tree, have a hash of output formats to stage lists? Then your addstage calls have a :finaltarget argument, with either absence of a value of a special value("all"?) specifying to add it to all branches. A addtarget method to create a new final output format, with an argument to allow you to automatically popula 06:35
with another target's list before a certain stage. Maybe have it work so that if you add a stage before the point where a target branched from its sibling/parent target, then it gets added to both targets' lists. Or just that same API with an actual tree, but that would be probably be less efficient.
chromatic I don't understand the value of a tree. 06:36
It's lovelier than a poem for certain, but....
sorear tcurtis: I'm asking you because you have the best reason to want to affect the stagelist
chromatic: source -> parse -> past -> post -> pir; source -> parse -> past -> post -> eval -> pbc 06:39
the union of these is a tree
06:39 fperrad_ joined
chromatic How many paths through that tree are you going to take during a single invocation of the compiler? 06:40
sorear One.
Suggestions for a better data structure are always welcome. 06:41
plobsing a lazy tree traveled once and a chain bear a remarkable resemblance 06:42
sorear plobsing: the chain can differ for every call to compile
which is why I can't just store it
I was going to store a tree instead, and traverse it to get the chain for each compile 06:43
plobsing I don't see why you need to store it. Does HLLCompiler require that all steps be added before comencing compilation?
sorear yes
currently
chromatic And each compiler has a default invocation method and potentially CLI options to change the output type and to add or delete steps. 06:44
tcurtis sorear: I think perhaps a better option than either hash of arrays of stages or a simple tree of stages is a linked list where the items can be either stages or a hash from output targets to similar linked list. 06:47
sorear That's called a simple tree of stages. 06:49
tcurtis Not really. A simple tree of stages would be [source, parse, past, post, [ pir, [eval, pbc] ] ]. 06:53
My suggestion would be [source, parse, past, post, { pir: pir, pbc: [eval, pbc] } ] 06:54
But, if that's already what you had in mind, I don't know of a more suitable data structure for this context. 06:56
sorear Ah
sorear has a random crazy thought 06:57
use a pathfinder
past2post, etc stages
then we'd have a natural notion of add_postprocessor('past', &my_past_processor) - it runs after the stage which produces past 06:58
similarly for preprocessor 06:59
dalek kudo: d4bb7b2 | moritz++ | docs/ChangeLog:
[docs] add some entries to ChangeLog
sorear I like this ide
a
objections?
purl objections are noted, though.
sorear purl, forget objections
purl sorear: I forgot objections
chromatic When registering any transformation, you have to register it by stage and give it some ordering, sort of like defining an operator type in Perl 6. 07:01
07:01 aukjan joined
cotto (Why) do certain ops need to have fixed numbers? 07:05
tcurtis One point, sorear: it would be a good idea to have the ability to ensure that given two particular stages that could be run in either order(for example, two mappings from 'past'->'past') are run in a specific order. For example, LLVM has some passes that just simplify the IR so that other passes can do what they want more easily. So, you wouldn't want to run the loop-invariant code motion pass until you've ran the loopsimply pass.
chromatic Other stages you can safely run more than once. 07:06
tcurtis s/loopsimply/loopsimplify
plobsing cotto: noop should be op 0 for sure. the other ops that require specific numbers were all JIT-specific
cotto and therefore no longer needed? 07:07
plobsing thinks so
chromatic I thought we used op numbers in the PBC. Do we use op names?
cotto should be. The next jit will be on Lorito, not pir directly.
no, number 07:08
s
07:08 viklund joined
cotto I'm looking at ###DYNAMIC### in ops.num and wondering if it's worth keeping. 07:08
plobsing chromatic: there are comments in the ops files such as "(Must be op #4"
07:09 iblechbot joined
chromatic Oh, that question. Yes, I think that was JIT. 07:09
That's odd though, as we had #defined constants for those ops. Who knows.
cotto and a nice enum 07:10
sorear tcurtis: that is easy enough to arrange; just use a postprocessor instead of a stage 07:11
tcurtis I'm not 100% sure if I understand exactly what your idea is, sorear, but it sounds like it would be something similar to the compiler essentially just supplying a list of stages in any order, where each stage specifies its input format and output format, and you find a path from source to the desired output format. Am I correct? I like that idea, if so, although it might be a little complicated to implement. 07:12
chromatic More to the point, I have difficulty believing we need an optimal graph traversal algorithm to build a transformation pipeline right now. 07:13
cotto +1 to writing only as much code as is needed to implement a simple optimization like constant folding. You'll know the problem much better after that. 07:16
messing with the op order causes some failure but not as many as I was expecting
chromatic I taught myself that over again this week on some client code.
sorear cotto: this isn't about optimizations at all
chromatic Throwing out technical features I thought I might need is liberating.
bacek_at_work tcurtis, Use "XPath" for tree traversal :)
sorear tcurtis: that is the idea, yes 07:17
bacek_at_work XPath semantic is very clean and easy to implement in simple recursive fashion.
plobsing cotto: should I stay away from moving ops to dynops (TT #449) and wait untill opsc lands? 07:18
cotto plobsing, not at all. 07:19
chromatic I used XPath in Perl 5. It worked pretty well.
cotto charge ahead
plobsing roger. time for round 1!
cotto plobsing++
plobsing I'd like to get rid of some of them completely, but this deprecation means I can at least get them out of core. 07:20
chromatic I mean, I used XPath for traversing the Perl 5 optree. 07:21
dalek kudo: 643442b | moritz++ | t/spectest.data:
run a few of the new advent calendar integration tests
 07:24
07:25 plobsing joined
dalek tracwiki: v131 | fperrad++ | Languages 07:29
tracwiki: update Parrot version 2.4.0
tracwiki: trac.parrot.org/parrot/wiki/Languag...ction=diff
tcurtis bacek: I will look into that, but for now I must go to sleep. 07:35
07:42 cosimo joined 07:47 gaz joined
dalek rrot: r46781 | plobsing++ | trunk (7 files):
move lcm, gcd, and fact opcodes to dynopslibs/obscure
 08:00
moritz
.oO( mathoms )
 08:01
cotto waves goodbye to fact 08:14
though I'd expect them to go in the math dynoplib 08:15
either way, they're in a better place
plobsing cotto: feel free to move them there. I thought math_ops should be reserved for more common non-core-ish ops (eg: ceil) 08:17
moritz we have a gcd op?
wow, rakudo could use that :-)
08:47 slavorg joined
ttbot Parrot trunk/ r46782 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/318292.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 09:02
09:02 gaz joined
moritz does r46781 mean that rakudo has to import something before it can use gcd in pir? 09:08
plobsing moritz: yes. check out t/dynoplibs/obscure.t 09:09
the .loadlib line does the import
moritz plobsing: thanks. Now I just have to manage to remember that after the rakudo release :-) 09:11
plobsing finds it funny that an unused op is finding a use once it is removed
dalek rrot: r46782 | plobsing++ | trunk (12 files):
move clear[insp], set[insp]_ind and exchange to deprecated dynops lib
rrot: r46783 | plobsing++ | trunk/src/exceptions.c:
export do_panic to be able to use PANIC() in dynlibs
ttbot Parrot trunk/ r46783 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/318364.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 09:17
dalek kudo: 5ec28d3 | moritz++ | src/core/Rat.pm:
replace hand-rolled gcd function by PIR gcd opcode

After the release (and bumping the parrot revision) this will require
  .loadlib 'obscure_ops'		 09:18
bacek plobsing, you can't move recently deprecated ops into dynops. You are "braking contract".
plobsing bacek: they were deprecated a while back
TT #449 09:20
I missed that the first time round
bacek ah
than that's fine
dalek rrot: r46784 | plobsing++ | trunk/include/parrot/exceptions.h:
headerizer
 09:27
purl headerizer is making me happy
moritz purl: forget headerizer 09:28
purl moritz: I forgot headerizer
plobsing aw, I like making purl happy 09:29
09:30 parthm joined
moritz botsnack 09:30
purl thanks moritz :)
09:45 clinton joined
bacek seen pmichaud 09:50
purl pmichaud was last seen on #parrot 1 days, 21 hours, 48 seconds ago, saying: that's saner/safer [May 17 12:49:30 2010]
bacek sigh... 09:59
dalek rrot: r46785 | bacek++ | trunk (5 files):
Merge branch 'pct_multi_support' into trunk
 10:00
10:03 parthm left
bacek msg pmichaud Multi support in nqp-rx waiting for your review :) 10:05
purl Message for pmichaud stored.
10:12 bakkdoor joined 10:15 simcop2387 joined
dalek rrot: r46786 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] old NQP is gone
 10:16
11:02 mikehh joined
dalek kudo: 77c58c2 | (Solomon Foster)++ | src/core/Complex.pm:
Rework Complex.roots a bit, restoring its original elegance. (It had been
 11:29
kudo: 3a694dd | (Solomon Foster)++ | src/core/ (4 files):
Change Complex.roots to take an Int as spec'd, and make it a normal method

unneeded Int.Complex and Num.Complex. Clean up Real.unpolar now that cheats are unneeded.
purl dalek: that doesn't look right
moritz I have an instance of the Sub PMC, and I want to set its name attribute 11:36
in NQP (or PIR)
how can I do that?
the documentation says I can call set_string_native, but that's a C function 11:37
bacek moritz, set_string_native is "$P0 = $S0" 11:39
(in pir)
moritz bacek: thanks, suspected as much
bacek: is there a nice way to call that from NQP?
excpet Q:PIR { find_lex ... }
bacek hmm 11:40
pir::set__ps($sub, $name)? 11:41
moritz 13:41 <@moritz_> nqp: my $x := sub f() { }; pir::set_ps($x, 'foo'); say($x)
13:41 <+p6eval> nqp: OUTPUT«error:imcc:syntax error, unexpected PREG, expecting
oh, forgot a second _ 11:42
13:42 <@moritz_> nqp: my $x := sub f() { }; pir::set__ps($x, 'foo'); say($x) 11:43
13:42 <+p6eval> nqp: OUTPUT«The opcode 'set_p_s_sc' (set<3>) was not found.
oh well, I'll use inline PIR, even if it's ugly
now I get set_attr_str() not implemented in class 'Sub' 11:46
so it seems to call set_attr_str, not set_string_native
11:49 aukjan joined
bacek moritz, try bare "set $P0, $S0" 11:50
moritz tries 11:51
... and waits for a few minutes until the setting is compiled...
11:53 whiteknight joined
moritz bacek: same result 12:01
bacek moritz, check #perl6. There is working result here
there
moritz I was stupid.. the previous solution worked, but I forgot to remove the failed attempt from before 12:02
which used set_attribute
bacek++
erm, setattribute
pmichaud good morning, #parrot 12:08
moritz good morning, pmichaud 12:09
whiteknight good morning, pmichaud
pmichaud I have three goals for today. 1. Review (and apply) sorear++ 's repl patch. 2. Closures in Rakudo. 3. Review (and hopefully apply) bacek++'s multi patch.
moritz all three very laudable! 12:10
pmichaud and if things work out, sink context in Rakudo also :-)
moritz tomorrow: review bkeeler++'s interpolation patch? 12:11
pmichaud sure
moritz \\o/
sounds like great fun before the release :-)
pmichaud oh, that's a problem. drat. 12:13
closures in rakudo will require parrot updates
darn release freeze
whiteknight purl msg sorear: thanks for the info about GHC 12:14
purl Message for sorear stored.
dalek kudo: 603c64c | moritz++ | (2 files):
fix RT #75180, accessors appear under wrong name in introspection
whiteknight pmichaud: what updates?
purl updates are happening in PAUSE, but not to fi.cpan.org
pmichaud whiteknight: improvements to PAST and NQP
whiteknight purl forget pdates
purl whiteknight, I didn't have anything matching pdates
whiteknight purl forget updates
purl whiteknight: I forgot updates
pmichaud rakudo is tied to the parrot release until we make the rakudo release 12:15
12:15 ruoso joined
pmichaud oh well, I can still do the work in branches and then apply right after release 12:15
afk, kids to school 12:18
12:19 aukjan joined 12:20 ruoso joined
bacek moritz, can I kill "mob2" branch in nqp-rx on github? 12:20
looks like it was merged already 12:21
whiteknight purl msg chromatic the t389_fix branch: does it have any value still or should I delete it? I'm leaning towards deletion but if you have something there you want to save let me know 12:27
purl Message for chromatic stored.
12:27 slavorgn joined
whiteknight bacek: what's the status of the avl_string_cache branch? 12:27
bacek whiteknight, stalled. 12:28
dalek rrot: r46787 | whiteknight++ | branches/block_exit_handlers:
delete old, unused branch
rrot: r46788 | whiteknight++ | branches/compact_strings:
delete old, unused branch
whiteknight bacek: boehm_gc_2 branch? 12:29
bacek whiteknight, let's keep it around. There is some changes that I want to propagate back to trunk.
whiteknight ok
purl msg chromatic also, the fix_hll_mmd branch. What's the status of that, and is it worthwhile to keep that particular branch hanging around? 12:30
purl Message for chromatic stored.
12:32 iblechbot joined
moritz bacek: re mob2, yes 12:35
bacek moritz, removed 12:36
moritz bacek++ 12:37
karma purl 12:38
purl purl has karma of 8967
moritz purl--
purl moritz: i'm not following you...
whiteknight {purl}--
karma purl
purl purl has karma of 8967
szbalint (purl)--
karma purl
purl purl has karma of 8966
whiteknight (purl)-- 12:39
that makes me happy
szbalint why?
moritz purl refuses to decrement her karma in the normal way 12:40
purl moritz: sorry...
moritz purl: forget purl--
purl moritz, I didn't have anything matching purl--
whiteknight karma purl 12:41
purl purl has karma of 8965
bacek karmawars!
moritz so purl-- with context works?
karma purl?
purl purl has karma of 8964
whiteknight yay!
moritz it does, purl-- :-)
purl stays quiet
bacek installing WWW::Facebook::API to create new game on facebook 12:42
whiteknight what new game? 12:46
bacek KarmaWars 12:49
12:56 tetragon joined
dalek rrot: r46789 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] more verbose with archive
 13:02
rrot: r46790 | fperrad++ | trunk/include/parrot/stat.h:
remove space (between minus and digit), so all defines are generated in stat.pasm
13:09 mikehh_ joined
Coke msg plobsing please update TT#449 if you're committing things against it. danke. 13:11
purl Message for plobsing stored.
13:13 bluescreen joined
dalek rrot: r46791 | fperrad++ | trunk/runtime/parrot/library/Archive/Tar.pir:
[Archive/Tar] preserve file mode
 13:17
rrot: r46792 | fperrad++ | trunk/runtime/parrot/library/Archive/Tar.pir:
[Archive/Tar] fix r46791, fperrad--
13:18 atrodo joined 13:32 gbacon_ joined 13:33 davidfetter joined 13:44 ruoso joined 13:51 zostay joined 13:52 Chandon joined 13:53 parthm joined 14:05 parthm left 14:22 theory joined 14:24 plobsing joined 14:27 bubaflub joined 14:34 mikehh joined 14:36 bubaflub joined 14:47 tetragon joined 14:48 slavorg joined 14:52 patspam joined
Coke msg plobsing note that ops can take a :deprecated tag in their definition that causes them to warn when used uner parrot -w. 14:52
purl Message for plobsing stored.
15:09 theory_ joined
dalek rrot: r46793 | coke++ | trunk/parrotbug:
use PAGER if set.
 15:11
15:30 theory_ joined 15:36 mikehh_ joined 15:43 iblechbot joined 15:49 Mokurai joined
dalek kudo: c6ecc98 | (Solomon Foster)++ | src/core/ (4 files):
Try to clean up and make consistent Real.Int, Real.Rat, and Real.Num.
 15:56
16:45 khairul joined
whiteknight Austin: ping 16:50
16:52 theory joined 16:54 theory_ joined 16:57 theory_ joined
whiteknight purl msg Austin What version of Parrot did Kakapo release-10 target? I'm trying to set up Parrot-Linear-Algebra to target parrot 2.3.0, but I can't seem to find a version of Kakapo that works with 2.3.0. I also can't seem to build current kakapo with 2.3.0 parrot. Any suggestions? 16:59
purl Message for austin stored.
darbelo Does kakapo work with nqp-rx? 17:01
I was under the impression it was written in old NQP.
whiteknight I don't know. I thought it was working with new stuff
darbelo I think Austin started on kakapo before nqp-rx was imported into parrot. 17:02
17:03 cotto_work joined
whiteknight right, but I think he updated it 17:03
there really isn't much to update, all things considered
darbelo I plead ignorance. My only use of NQP was the boostrap of the decnum-dynpmcs testsuite, after which I checke in the generated PIR and promtly forgot about it ;) 17:06
whiteknight Coke: ping
dalek kudo: 8816781 | moritz++ | t/spectest.data:
run another advent calendar integration test
 17:14
17:14 allison joined
whiteknight allison: ping 17:15
17:16 solarion joined 17:17 ash_ joined
tewk darbelo: github.com/tewk/parrot/tree/select 17:23
sorear moritz: I thought that if a single support routine was costing us 2.4% we moved it into perl6.ops? 17:27
pmichaud: shall I do the rebasing for you? 17:28
17:29 particle joined
sorear moritz: you probably want set__vps 17:29
set__ps is interpreted as 1 arg 1 return
and PAST::Compiler doesn't handle excess args to pirops prettily
Coke whiteknight: pong
whiteknight Coke: I need to get a commit bit for my GSoC student 17:30
At #ps, it looks like the consensus was for the mentor to make that happen
Coke whiteknight: trac id & student name?
whiteknight Chandon, Nat Tuck
particle we did get a cla for nat 17:31
whiteknight Actually, Chandon is his parrot.org username, I dont know if it's a trac username
yes, just checked. It's the trac username too
17:33 hercynium joined
whiteknight Coke, ah, I just found the "Manage Subversion Access Rights" page on Trac. Is this something I could be doing myself? 17:33
Coke if you're a trac admin, possibly. 17:34
give it a whirl.
whiteknight Okay. Even if I have access, I don't want to be touching things that I shouldn't
Coke read the docs for it.
docs/project/met*
whiteknight Am I a metacommitter? 17:36
particle i don't think so 17:37
you can find out, by trying :)
whiteknight particle: I have the same technical rights on Trac as you or Coke have. I'm more asking about the cultural designation 17:38
just because I have technical access doesn't mean I have community permission to use it
particle not true 17:39
you're a member of a special group if you're a metacommitter
dalek rrot: r46794 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] display only the first line sent by Smolder,
particle it's role-based permissions 17:40
whiteknight a special group on trac? On trac, you and Coke are both listed as "admin", same as me
I'm not sure why I'm an admin in the first place, probably something that was decided quickly when I was trying to do a release at some point
which brings me back to my first point: I have the technical ability to change these things.
particle you can't make yourself a metacommitter 17:42
it's an rt group iirc
not trac
whiteknight we're not on rt
on trac, I have authority to add committers to the svn repo. 17:43
particle ok, i'm way out of date on the metacommitter stuff then, i'll need to review the doc
whiteknight ok
17:48 davidfetter joined
particle whiteknight: ok, the docs are a bit misleading, but you're a trac admin, and i'm comfortable with you having that right 17:51
why don't you add nat
's svn perms
whiteknight okay, if it's not a problem I'll definitely do it 17:52
17:52 GodFather joined
particle we may consider creating a group for metacommitters, to make it more clear 17:52
whiteknight might be worthwhile to get some clarification in the policy, however
ok
particle aye
17:52 theory joined 17:53 theory_ joined
whiteknight ...okay, done. I think 17:53
cotto_work can you do the same for khairul?
whiteknight I guess. What's his trac username? 17:54
17:54 theory_ joined
cotto_work khairul 17:55
17:57 theory_ joined
whiteknight done, I think 17:59
gsoc students should do work in branches named "gsoc_*", correct?
or something else?
particle i think that's appropriate 18:01
cotto_work thanks 18:02
khairul, ping
khairul cotto_work: pong 18:03
cotto_work you should have an svn commit bit now
particle test it by creating a new branch for your project! 18:04
khairul thanks cotto++ and whiteknight++ 18:06
whiteknight khairul: try it out before giving me karma
khairul hold on 18:07
ash_ Whiteknight: i am working on a github fork for now...
whiteknight ash_: okay, that's cool too
ash_ i sent my signed agreement thing to legal@parrot.org but i have no idea if thats all setup 18:08
particle ash, it is.
ash_ oh, its setup? so i could work on an svn branch? 18:09
particle sorry, we should respond to cla submissions, let people know they've been accepted.
ash_: you don't have a commit bit yet, but that's what whiteknight++ has been doing
ash_ ah, okay, cool
particle your cla has been accepted.
ash_ i'll ask plobsing if he wants me to work on github or the svn repo (i kinda like git, but i am fine with svn if thats what everyone else is doing)
particle you can and should have a parrot commit bit
18:09 theory joined 18:10 theory_ joined
Coke particle: (respond to cla) let their mentor do it. 18:10
whiteknight: if you have the permissions, you have the permissions.
cotto_work khairul: I've also been thinking about whether your project's long-term state should be a core PMC, a core dynpmc or an external dynpmc. What's been your assumption?
Coke there's no secret "oh you have the permissions but cannot use them" club.
18:10 theory joined
particle coke: their mentor isn't always someone who can read legal@parrot.org 18:11
whiteknight Coke: yeah, but I'm making sure it wasn't some slip-up.
18:11 theory_ joined
Coke whiteknight: if it was, we'd have taken it away already. 18:11
18:11 theory_ joined
particle congratulations on your promotion, whiteknight :) 18:11
18:11 theory joined
particle we have rewarded your enthusiasm with responsibility. 18:12
Coke particle: but we never give out permissions based just on the cla.
18:12 theory joined, fperrad joined, theory joined
particle coke: correct, i'm saying when pafo accepts a cla, we should respond to the submitter letting them know it's been accepted 18:12
darbelo makes a note to remain as unenthusiastic as possible.
khairul cotto_work: i'm making it a dynpmc. that should allow me to group related pmcs together, as i think i would need a few now. 18:13
18:13 theory_ joined
khairul cotto_work: as to core, or external, no assumptions made there. 18:13
18:13 theory_ joined
Coke particle: define "accepts" 18:14
whiteknight Coke: I think he means to say "received"
particle no, it can (and has) been improperly filled out, and will be rejected 18:15
18:15 theory_ joined
particle receipt does not guarantee acceptance 18:15
Coke particle: ETOOMUCHWORK. I think having your bit flipped is sufficient.
18:15 theory_ joined 18:16 theory__ joined
Coke but don't let me stop you from sending out friendly emails. 18:16
18:16 theory_ joined
particle coke: you're missing something. receiving or accepting a cla does not mean you get a commit bit. it's necessary, but not sufficient. 18:16
18:16 theory__ joined
Coke particle: I am absolutely, clearly, 100%, missing your point, yes. 18:16
18:16 theory_ joined 18:17 theory joined
particle ok, so, a contributor wants to become a pafo member. she submits a cla. 18:17
Coke ... please stop. =-)
18:17 slavorg joined
particle fine, i'll go back to work. 18:17
whiteknight bots trust khairul
opbots trust khairul
slavorgn Ok
whiteknight opbots trust Chandon 18:18
slavorgn Ok
darbelo What happened to slavorg?
whiteknight BALEETED
18:18 theory_ joined
darbelo opbots trust me 18:18
slavorgn Ok
whiteknight opbots trust everybody!
slavorgn Ok
whiteknight :)
opbots untrust everybody! 18:19
opbots help
slavorgn I'm slavorg, an op-bot.Commands: trust, distrust, believe, disbelieve, leave, join. See also jerakeen.org/programming/slavorg
whiteknight opbots distrust everybod!
slavorgn But I already distrust everybod!
whiteknight opbots distrust everybody!
slavorgn Ok
darbelo opbots distrust everybody!
slavorgn But I already distrust everybody!
cotto_work khairul, we'll see how the project looks later in gsoc and decide then. It shouldn't be too much trouble to kick it out of Parrot's repo if that looks like the best idea.
slavorg Ok 18:20
But I already trust me
Ok
I'm slavorg, an op-bot.Commands: trust, distrust, believe, disbelieve, leave, join. See also jerakeen.org/programming/slavorg
But I already distrust everybod!
Ok
But I already distrust everybody!
whiteknight ...good. I'm glad that happened
particle opbots leave a lot to be desired
cotto_work you make opbot cry
dalek rrot: r46795 | khairul++ | gsoc_instrument:
Creating a branch for gsoc making parrot instruments
 18:30
rrot: r46796 | Chandon++ | trunk/CREDITS:
[CREDITS] Adding myself to CREDITS
rrot: r46797 | khairul++ | gsoc_instrument:
Created in wrong folder. Sorry, khairul--
rrot: r46798 | Chandon++ | branches/gsoc_threads:
[gsoc] Creating a new branch to do GSoC work on my threads project
rrot: r46799 | khairul++ | branches/gsoc_instrument:
Creating a branch for gsoc making parrot instruments
18:30 theory_ joined
cotto_work looks like it worked 18:32
18:36 bluescreen joined
dalek rrot: r46800 | NotFound++ | trunk/src/string/api.c:
fix parsing of \\xHH in Parrot_str_unescape_string
 18:46
rrot: r46801 | NotFound++ | trunk (3 files):
add "flags" parameter to Parrot_str_unescape_string
18:48 Mokurai joined
dalek kudo: f6374ad | (Solomon Foster)++ | src/core/Real.pm:
Real.Int is now just sugar for Real.truncate.
 18:54
kudo: ad8556c | (Solomon Foster)++ | src/core/Num.pm:
modf is now a local function instead of a private function; call it accordingly.
19:11 joeri joined
ash_ where do tests for configure steps go? 19:32
ah, i see it, nevermind
19:36 Mokurai joined
dalek rrot: r46802 | NotFound++ | trunk/src/string/api.c:
fix again parsing of \\xHH in Parrot_str_unescape_string and a hard tab
 19:36
Coke wonders if we should add a 'make check' alias. 19:41
whiteknight what would a make check make, if a make check check were made? 19:44
cotto_work a check, probably with a large number of zeroes 19:46
bubaflub 10.0000000000
nopaste "NotFound" at 192.168.1.3 pasted "Patch: strore string encoding in pbc and make pir parsing of encoded strings a bit sane" (135 lines) at nopaste.snit.ch/20602 19:47
NotFound Some opinion about this patch?
whiteknight NotFound: I'm not sure I understand it 19:50
sorear Anything with sane in it gets a +1 from me
NotFound whiteknight: no one understand the issue, that's the reason it never gets fixed X-)
It stops making the strange assumption that string literals are in the encoding specified, even if mixing 8 bit chars with 16 or 32 bit chars 19:51
19:52 joeri joined
NotFound Also, escapes are always considered codepoints, instead of using bytes for some cases, 19:52
Coke phone in 0:07 19:53
whiteknight: make check is how non-perl people spell "make test", methinks.
whiteknight Coke: ah, okay 19:54
NotFound Rename as "make verify", to fool all people same way X-) 19:55
TimToady phone 20:00
20:05 joeri joined
GeJ Good morning everyone. 20:08
pmichaud no phone today? 20:18
or am I just too late?
sorear Hello 20:19
purl hola, sorear.
20:19 hercynium joined
sorear pmichaud: timtoady said "phone" 18 minutes ago 20:19
(also, the minutes from the last one still haven't landed)
pmichaud sorear: yes, I saw the 18-minute-ago notice. usually the calls last a bit longer than that, though. 20:20
I can't speak to last week's minutes; I'm not the minute-taker. :)
pmichaud checks email 20:21
looks like I just missed the meeting
PerlJam "welp, no one showed up ... meeting adjourned!"
pmichaud no, I see this week's minutes, looks like chromatic++, Coke++, and TimToady++ 20:22
I must've just missed them. Too much going on around here today :-(
Coke hope everything's OK.
pmichaud sure, nothing radically wrong. 20:23
just unexpectedly had to run an errand, which made me late to picking up kids from school, which made me late to call 20:24
darbelo NotFound: +1 to nopaste.snit.ch/20602 20:39
NotFound pmichaud: can you take a look at that nopaste? 20:46
I don't know if it risk to break something on nqp or rakudo. 20:47
darbelo commit it and find out ;)
PerlJam NotFound: what darbelo said :) Rakudo (and I guess nqp) are pegged at the Parrot release anyway. 20:48
NotFound I'm goint to do that anyway, but is polite to ask before cut the throat X-) 20:49
pmichaud Rakudo is pegged at 2.4.0 until we do the release tomorrow.
(so changes to Parrot are generally okay) 20:50
NotFound The main doubt is: someone oppose the changing of meaning of \\xHH to always be a codepoint, not a byte?
pmichaud \\xHH already means codepoint and not byte 20:51
NotFound pmichaud: in theory.
purl well, in theory is my pants or it's too dark to read or somewhat intrusive to David Wheeler
pmichaud if I have unicode:"\\xab"
I guarantee that's a two-byte string at the moment.
moritz forget in theory 20:52
purl moritz: I forgot in theory
NotFound pmichaud: some tests seems to use \\xHH\\xHH as one char codified in utf8 20:53
pmichaud which ones?
theory is forgotten
NotFound UTF8 literals
16 & 17 in stringu.t 20:54
moritz theory: you're forgiven, not forgotten # /me paraphrases old, bad song titles
NotFound The ones that fail with this patch.
theory that'll work
pmichaud NotFound: I agree that in those tests, the utf8: prefix is making \\x act like a byte, not a codepoint 20:55
NotFound That's what I want to change. 20:56
But I can preserve it, at the cost of complicating a bit Parrot_str_unescape_string 20:57
pmichaud I don't have an issue with changing it, as long as unicode:"\\xab" continues to work the same.
NotFound Also, the patch changes completely the meaning of utf16:unicode: but I think no one uses that, 20:58
utf16 and any other encoding based on wide chars. 20:59
Well, I'll do some clean up and review some tests, and commit it tomorrow. 21:02
And change PBC_COMPAT, of course. 21:03
purl NotFound: that doesn't look right
pmichaud there's an argument to be made that it requires a deprecation cycle.
It's a definite change in API. 21:04
NotFound Show me some program that worked, and I'll agree.
pmichaud that's not the way deprecation works.
In general, we have to assume there's a program relying on the behavior (unless it's clearly a bug); we can't take the fact that we're unaware of one as proof of its non-existence. 21:05
NotFound I consider all this thing a big bug. 21:06
pmichaud there are exceptions, of course.... but exceptions really need to be discussed in a wider forum
it really can't be a bug if it's a documented behavior, though.
darbelo Documented where? 21:07
pmichaud (and if there have been tests for this particular behavior, which there are)
documented in the tests, if nothing else.
but also implied in pdd-19
NotFound Is not. We discussed that point long time ago. The pdd isn't clear on that matter.
pmichaud look, I'm not the architect, you don't have to convince me.
NotFound Ok, I'll wait to next #ps
pmichaud I'm simply offering my opinion on the deprecation policy. 21:08
and I think this is about as clear a case as needing deprecation as one can come up with.
(because we have tests to ensure the current behavior)
NotFound If you mean the escapes, I prefer to complicate the patch than wait for a deprecation cycle. 21:10
If you mean the wide char behavior, I disagree. That shit never worked.
darbelo I'm working on parrot's encodings now and I agree with NotFound, that shit never worked. 21:21
pmichaud I don't disagree with that. :-) 21:22
NotFound You don't need to quote the "shit" part ;) 21:23
This is a semi-proof: skip "Tests seem to fail on big endian machines with icu", 2 if $PConfig{byteorder} eq '4321'; 21:25
darbelo In the long term, I'd like it to bot work and not be shit. Any of those right now still makes me happy ;)
s/bot/both/ 21:26
NotFound pdd19: "so in the example above, you can include a particular Unicode character as either a literal sequence of bytes, or as an escape sequence" 21:33
For me the meaning of that phrase is that the curent behavior is a bug. 21:34
21:50 Mokurai joined
bacek ~~ 21:51
Good morning, humans.
darbelo welcomes our new robot overlords. 21:52
bacek pmichaud, ping 21:53
pmichaud bacek: pong 21:57
bacek pmichaud, any progress on mutlis review?
pmichaud bacek: no, ended up with a ton of housework to take care of :-| 21:58
bacek pmichaud, no worries.
pmichaud but I plan to review it (and sorear's patch, and bkeeler's patch) tonight
I also had to deal with a dying wifi router yesterday :-|
on the plus side, I ended up getting a much better router that I'm much happier with
bacek There is always a plus side :) 21:59
22:11 Mokurai1 joined 22:20 Mokurai1 joined
GeJ G'Day bacek. 22:22
bacek G'Day GeJ 22:23
Coke bacek: slacker!
purl slacker is like lazy bum
Coke I expect another dozen commits today. =-)
(is it tomorrow yet?)
bacek Coke, hey! I merged pct_multis_support branch!
dalek rrot: r46803 | darbelo++ | branches/ucs4_encoding:
Branch to add support to parrot for the UCS-4 unicode encoding form.
 22:24
tracwiki: v132 | bacek++ | Languages 22:25
tracwiki: Added my fork of PIR
tracwiki: trac.parrot.org/parrot/wiki/Languag...ction=diff
cotto ~~ 22:26
22:34 tcurtis joined
tcurtis Coke: ping 22:44
22:50 bacek_at_work joined, PacoLinux joined 22:58 Psyche^ joined 23:16 Mokurai joined
tcurtis msg Coke The ping was to ask you if I have a commit bit. I had to go and couldn't wait for your response. 23:19
purl Message for coke stored.
darbelo Hmm. That did not entirely go as expected. 23:46
dalek rrot: r46804 | darbelo++ | branches/ucs4_encoding (6 files):
Merge branch 'NFG' into ucs4
 23:47
darbelo Oh, wait. It was squashed. 23:48
bacek: ping
bacek_at_work darbelo, pong
darbelo Do you know of any way to make git-svn not squash commits when merging a git branch into a svn one? 23:49
bacek_at_work git 1.6+
or 1.7+
darbelo I have 1.7.0.5 23:50
bacek_at_work it's still "squashed" from svn point of view. 23:51
but you should have correct history in git
(It's just svn nature of handling merges. It loosing commits history all the time)
afk # meetings 23:52
darbelo You are right, git log shows the history.
Meh. Fortunately it was a small batch.

Powered by Cro and the Raku® Programming Language.

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

Thank you!