Camelia, the Perl 6 bug

IRC log for #parrot, 2011-01-30

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 allison lucian: oh, we're both right http://hugunin.net/story_of_jython.html
00:00 allison lucian: I guess it doesn't surprise me that people would give more credit to Guido, it kind of boosts the "validity" of Jython as a "true" Python
00:02 bacek_ joined #parrot
00:20 bacek_ left #parrot
00:26 bacek joined #parrot
00:27 chromatic pmichaud, I'm comfortable implementing some/much/all of 6model in Parrot. Replacing the existing object model makes sense.
00:27 pmichaud I think that's all that we're looking for at the moment.
00:28 pmichaud I'm also pleased that Parrot has been able to use nqp in the past for some of its internals, and I think it makes sense going forward, but I'm completely understanding if that's not the case.
00:28 sorear chromatic: What is the status of the sixperl minutes backlog?
00:29 chromatic You know my reservations there, especially given Pugs.
00:29 pmichaud absolutely.
00:29 pmichaud they are still noted, and if/when I see multi-backendness causing us issues I plan to put a stop to it.
00:29 chromatic sorear, I have minimally formatted notes. I could forward them to you for publishing if you volunteer.
00:29 pmichaud at least as far as "core goals" goes.
00:29 sorear allison: I've spoken to people deeply involved in the IronLanguages project
00:29 chromatic It's not just the cost of supporting them (and the question of whether anyone's going to take advantage of that feature).
00:30 sorear allison: what I've heard from them is that the main reason people are interested is interop with other libraries, and the main reason people don't follow through is because Iron* starts up way too slow, due to compulsory JIT and bad handling of dynamism
00:30 chromatic The further NQP diverges from Parrot's semantics (and, as I realized five minutes ago, the less it makes demands of Parrot so we can improve Parrot's semantics), the less competitive Parrot *can* be with regard to NQP.
00:31 chromatic That's always Parrot's advantage for Rakudo, that we *can* change what Parrot does to improve Rakudo.
00:31 pmichaud I think that's a useful insight.  It'll take me a bit to digest it.
00:31 chromatic That's the source of a lot of my frustration, that it hasn't happened enough.
00:32 pmichaud That was the source of my frustration for much of Parrot development :-)
00:32 chromatic I should have said something earlier, but it didn't coalesce in my mind until a few minutes ago.
00:33 chromatic There are a lot of places in Rakudo where I want to optimize things, but run into spots where it's doing things Parrot should be doing.
00:33 chromatic There have been a lot of crashes, bottlenecks, and memory leaks in those places too.
00:33 pmichaud I totally understand.  I remarked privately to jnthn that I thought you were just having difficulty formulating/discovering what needed to be said.
00:33 chromatic Hence the "big wad of code" mentions.
00:34 chromatic I understand the desire for immediate action, especially considering deprecation policies and other design review.
00:34 pmichaud I'm also the first to admit that I've not been as open or good about publishing plans and descriptions as I need to be... I keep trying to improve
00:34 bacek left #parrot
00:34 pmichaud so, I'll keep working on it until someone finds a better way (or person) to do it :)
00:35 chromatic But for every place a HLL needs to work around a core API or semantic, we should at least weigh design alternatives.
00:35 pmichaud Yes.  Rakudo guts (and NQP guts) are full of places where we've had to work around Parrot semantics. (more)
00:35 pmichaud P6object was the first layer to work around Parrot core semantics, but it ultimately didn't go far enough.
00:36 chromatic That's probably the point we should have started to revise the design of the core semantics.
00:36 pmichaud Ultimately the nqp says largely "here are the core PMCs we think we need to begin to get Rakudo to run reasonably well"
00:36 pmichaud *the new nqp
00:37 pmichaud in some sense that's entirely keeping with the way HLLs were originally envisioned to work with Parrot -- that each would provide its own core PMCs to use and be dynamically loaded
00:37 pmichaud if that's the way that nqp ends up being -- it's just another Parrot HLL used as the foundation for Rakudo -- that's pretty much okay with Rakudo devs for now
00:37 chromatic For something as fundamental as an object model though, that's a lot to reimplement.
00:38 pmichaud right
00:38 chromatic I really do see the value of NQP and PCT as part of Parrot though.
00:38 chromatic With two caveats.
00:38 chromatic 1) The deprecation policy may constrain them too much, which is a shame.
00:39 pmichaud I agree totally.  As jnthn++ can tell you, I gave up the notion of "no extra runtime for NQP" _very_ reluctantly and took a bit of time to come around to that conclusion.
00:39 chromatic 2) Backend portability is not of value to Parrot to support there.
00:39 pmichaud I agree with #1 and #2 both.
00:39 chromatic (Given complexity, the usage question, et cetera... and believe me, I understand sunk costs.)
00:40 pmichaud Indeed, this is why Rakudo is expecting to start targeting NQP_REVISION (where most changes will be taking place) instead of PARROT_REVISION over the near future.)
00:40 chromatic Is it possible for Parrot core to provide a PCT/NQP which other languages can customize as they need more features?  Would that be useful to Rakudo and other HLLs?
00:40 pmichaud I think it's possible and possibly useful, yes.
00:40 pmichaud Right now we haven't focused much on that.
00:41 chromatic That way if Rakudo wants more abstractions to make other backends possible, it can have them, but Parrot doesn't have to pay for that complexity?
00:41 pmichaud NQP is still intended to be extremely lightweight, yes.
00:41 pmichaud we just had to move our notion of "lightweight" a bit.
00:42 chromatic NQP and Parrot both benefit from a tight but well-defined coupling.
00:42 pmichaud there's also a part of me that wonders if/when someday NQP will disappear entirely, and we just have Perl 6.
00:42 chromatic Within Rakudo?
00:42 jnthn Not until we write a *really* good optimizer.
00:42 jnthn :)
00:43 pmichaud right
00:43 chromatic I have to switch hats to think about that.
00:43 pmichaud right
00:43 pmichaud at some point NQP might be not lightweight enough to deserve its own implementation separate from Perl 6.  But I see that as being far in the future, if ever (more)
00:43 allison sorear: I've talked to the Iron* folks too, agreed
00:43 chromatic From Parrot's perspective (I haven't managed to remove that hat yet), we still need PCT with some minimal language.
00:44 pmichaud I do see the value of NQP as being a fairly minimal language for writing low-level stuff-ish
00:44 allison sorear: but, as much as people *say* they want interop, I know very few real-world projects that really go for multi-language implementation
00:44 chromatic How about this plan then.
00:45 chromatic * Port as much of 6model as makes sense to Parrot as dynpmcs
00:45 jnthn I'm dismayed that having spent a bunch of time carefully working out how to factor things in 6model, there's some automatic assumption that I've done stuff in it that inherently makes it worse than on Parrot than if I was only ever going to implement it on Parrot.
00:45 allison sorear: projects even go so far as using really inappropriate languages to solve some piece of their problem, just so they can stick to one language
00:45 chromatic * Port NQP to those dynpmcs
00:45 allison sorear: for example, java as a command-line language, major suck!
00:45 chromatic * Figure out separation points in NQP/PCT where some things make sense as parts of the Parrot core and other parts are extensions
00:46 mikehh chromatic: that sounds like an excellent plan
00:46 chromatic * Migrate features of extensions to Parrot where they make the most sense
00:46 chromatic jnthn, I don't make that assumption and I apologize for giving you that impression.
00:46 bacek joined #parrot
00:46 allison chromatic: aye, "migrate features" is key, as opposed to "swallow huge wodges of code that might not be a good fit"
00:47 chromatic allison, but also avoiding the "never try new dishes, because they might have a strange taste/texture at first"
00:47 pmichaud chromatic: that plan seems entirely reasonable to me
00:47 pmichaud it's pretty much what I've been hoping for.  I'm fine with there being readjustments of the nqp/parrot demarcation -- that's really what all of this has been about anyway
00:48 jnthn Especially as the first two steps kinda pretty much already happened. ;)
00:48 allison chromatic: I'm not even sure what that means
00:48 allison chromatic: fear of new features?
00:48 chromatic allison, or just never thinking about merging them for whatever reason.
00:48 allison chromatic: new features == good, implementations of new features might be good or bad, no prejudice
00:48 chromatic jnthn, how's that plan sound to you?
00:50 jnthn chromatic: It's mostly the path I've been following. The 6model core is pretty small. Parrot actually has the *best* implementation of it already today. It's exposed as 3 (though may drop to 2 later) dynpmcs and some dynops. Migrating that into Parrot where it makes sense works fine for me.
00:50 pmichaud chromatic: just keep in mind that for the next couple of months jnthn and I will have most of our energies digesting nqp and rakudo migration
00:51 pmichaud as opposed to "how do we get this into core Parrot".  I'm sure we'll advise and help where we can.
00:51 dukeleto jnthn: i think there was some miscommunication and I assure you that I am glad you are trying multiple backends to get the spec nice
00:51 bacek left #parrot
00:51 pmichaud Also, to ease migration I asked jnthn to prefix all of our custom dynops and other items with nqp_, so that there's no big naming issue with migrating to Parrot
00:52 pmichaud i.e., so Parrot can claim the non-nqp_ prefixed names when they are adopted
00:52 jnthn Yes, will do that.
00:54 jnthn I think trying to get it into core Parrot until it runs Rakudo would be too early, fwiw.
00:54 jnthn Things *will* end up changing here and there.
00:54 chromatic Right, but the fewer flag days the better.
00:55 jnthn *nod*
00:55 bacek_ joined #parrot
00:57 pmichaud I have to head off to dinner; I'm comfortable with where the discussion has led and is heading.
00:57 * jnthn should sleep too - need to travel to Stockholm tomorrow.
00:57 pmichaud chromatic: thanks for your comments, as always.
00:57 pmichaud (and suggestions)
00:58 chromatic Thanks for letting me fumble through vague thoughts.
00:58 pmichaud No problem -- I know I have to do it a lot.  Not used to seeing you have to go through the process though.  :-)
00:58 chromatic My office is usually quieter.
00:59 * allison heads to the airport
00:59 allison left #parrot
00:59 chromatic Also I have bleadperl code on another desktop, so I wasn't in a great mood to start.
01:01 nwellnhof left #parrot
01:07 Hackbinary hello
01:09 Tene hi
01:10 whiteknight joined #parrot
01:17 sjn joined #parrot
01:24 whiteknight sorry I'm so late to the meeting. Other parts of my schedule overflowed
01:24 cotto whiteknight, it happens.  Knowing what you think about Parrot, I'm sure you couldn't help it.
01:25 whiteknight I do think it's the bee's knees
01:25 kid51 is now known as kid51_at_dinner
01:28 chromatic left #parrot
01:31 cotto bacek_, I like Lua's minimalist philosophy.
01:39 whiteknight chromatic: ping
01:42 whiteknight some of this conversation looks like it got pretty heated.
01:43 cotto I'm still backscrolling too, but I think it ended well.
01:44 snarkyboojum left #parrot
01:47 mikehh whiteknight: I think it got resolved amicably at the end here
01:47 whiteknight yeah, I'm slowly getting there
01:48 mikehh once chromatic worked out what he wanted to say it was much clearer
01:48 mikehh chromatic++
01:55 whiteknight basically finished backlogging now. Seems I have a hell of a lot to write about
01:55 whiteknight does anybody here have any questions about the IMCC work?
01:56 cotto brain numb.  no think good
01:56 whiteknight okay. I'm always around if questions materialize
02:11 bacek_ left #parrot
02:34 lucian left #parrot
02:37 bacek joined #parrot
02:39 dalek TT #462 closed by pmichaud++: [TODO]  Refactor handling of 'stages' in PCT::HLLCompiler
02:39 dalek TT #462: http://trac.parrot.org/parrot/ticket/462
02:39 dalek parrot: 0e83c3b | bacek++ | DEPRECATED.yaml:
02:39 dalek parrot: Remove deprecated item which will not be implemented.
02:39 dalek parrot: review: https://github.com/parrot/parrot/commit/0e83c3bf84
02:46 snarkyboojum joined #parrot
02:48 bacek cotto, ping
02:49 kid51_at_dinner /nick kid51
02:49 kid51_at_dinner is now known as kid51
02:49 bacek ETOOMANYSPACES
02:49 bacek msg cotto Should M0 be CPS based? Or we are going to implement CPS on top of it?
02:49 aloha OK. I'll deliver the message.
03:05 cotto bacek, pong
03:06 cotto on top
03:06 cotto why do you ask
03:06 bacek cotto, ok than
03:06 bacek cotto, thinking about M0 in background
03:07 cotto that's a good sign
03:07 bacek cotto, not really nowdays...
03:10 sorear CPS is a framework of thinking
03:10 cotto bacek, what makes you suggest lua's vm?
03:10 kid51 msg mikehh Your comments on TT #1954 would be welcome
03:10 aloha OK. I'll deliver the message.
03:10 sorear there's no decision procedure for "does this language use CPS?"
03:10 bacek cotto, because it's really small VM
03:11 cotto interesting that it has three ops out of 35 related to for loops
03:11 bacek sorear, hmmm. Not all HLLs will target M0 directly.
03:11 bacek cotto, it's just for optimization of most commonly used Lua loops
03:11 sorear if you want to avoid being laughed at, you need to make function calls possible
03:11 cotto I like the size of the op set.
03:12 sorear so you need to offer some way for code to record "where was I before I entered this sub?"
03:12 dalek TT #1454 closed by jkeenan++: make failing for parrot when rakudo git repo path in $PATH environment ...
03:12 dalek TT #1454: http://trac.parrot.org/parrot/ticket/1454
03:12 dalek TT #1739 closed by jkeenan++: Latest CPAN Module Test::Builder caused test failure
03:12 dalek TT #1739: http://trac.parrot.org/parrot/ticket/1739
03:12 dalek TT #1775 closed by jkeenan++: Inline hash key_hash and compare functions
03:12 dalek TT #1775: http://trac.parrot.org/parrot/ticket/1775
03:13 cotto bacek, are you suggesting using luavm directly or adoping heavily from its ideas?
03:13 sorear that information is called a "continuation"
03:13 bacek cotto, for now - just take a closer look at it.
03:13 sorear many languages only allow a single continuation per thread, and have a very specialized variable called a "stack" to hold it
03:13 * cotto continues doing that
03:14 bacek sorear, yes. E.g. "atrodo's lorito" and "LuaVM"
03:14 bacek sorear, and it was my question to cotto: Stack vs CPS
03:14 cotto It's times like this that I wish I knew Lua a little btter.
03:15 bacek cotto, you don't have to. LuaVM is quite generic. Lua's Table ~~ PMC.
03:15 cotto Whatever else you say, you can't call Lua's object model heavy.
03:16 bacek cotto, it's very lightweight, indeed.
03:17 plobsing Lua has some key differences from Parrot in how it interacts with C. Lua embraces C for all its worth (this is why people claim it is "easy to embed"). Parrot, seeing some of the shortcommings of C, tries to avoid it wherever possible (see for example complaints about inferior runloops).
03:18 plobsing IMHO, a wholesale shift directly to Lua would take a similar shift in the mindset of many parrot developers regarding the purpose of a VM.
03:18 plobsing that's not to say we can't plunder all the good ideas
03:19 cotto plobsing, I don't think anyone's suggesting we switch to Lua.
03:19 plobsing the wording was sufficiently ambiguous to me
03:19 cotto just explore their VM and plunder the awesome bits
03:24 cotto bacek, nice job finding that paper
03:26 Coke What's the name of the book in "docs/book/draft" ?
03:29 kid51 I think it was the PIR book that allison and whiteknight wrote
03:32 Coke you mean allison and dan?
03:32 Coke (and leo)
03:35 kid51 http://tinyurl.com/45d3mv2
03:37 mikehh kid51: just saw your message, was going to work on that a couple of days ago, but somehow missed doing it, will have to look later, need sleep now
03:37 kid51 night, night!
03:38 * mikehh sleep - cu
03:38 Coke kid51: I think that's the one in book/pir
03:40 whiteknight left #parrot
03:40 kid51 git blame suggests it was something allison and chromatic were working on in 2009
03:42 bacek cotto, https://github.com/bacek/YAML--Tiny. Can we use JSON for DEPRECATED?...
03:45 Coke bacek: Ha! I already registered my preference to json >> yaml and was shot down. gluck.
03:45 Coke er, "good luck"
03:45 dukeleto ~~
03:47 dukeleto bacek: my plan is to make Lorito CPS-based
03:48 dukeleto bacek: also, i don't know that any language will target M0. Only parrot internals will target M0
03:48 dukeleto bacek: HLLs might want to target M1, though, which will have a MOP
03:49 bacek dukeleto, question was "Should be M0 be CPS based" :)
03:50 dukeleto bacek: ah. the answer is "yes"
03:50 dukeleto bacek: at least that is what i am going for
03:50 bacek dukeleto, ok
03:52 cotto bacek, afk for a while.  will look when I get back
03:52 dukeleto bacek: i am reading the Smalltalk-80 blue book as we speak :)
03:52 bacek dukeleto, is SmalltalkVM CPS based???
03:52 sorear What's the smallest Mx with memory safety?
04:02 kid51 left #parrot
04:02 dalek TT #910 closed by coke++: macport/ installing on OS X
04:02 dalek TT #910: http://trac.parrot.org/parrot/ticket/910
04:02 dalek TT #932 closed by coke++: Warnings in compiling bignum.pmc
04:02 dalek TT #932: http://trac.parrot.org/parrot/ticket/932
04:02 dalek TT #930 closed by coke++: build fails when sandbox path contains whitespace
04:02 dalek TT #930: http://trac.parrot.org/parrot/ticket/930
04:04 dukeleto sorear: probably M1
04:04 dukeleto bacek: as far as I can see, the idea of a "Context" and calling it that comes from Smalltalk
04:05 dukeleto sorear: M0 is bare metal for parrot internals
04:05 bacek dukeleto, hmm. I'll try to squeeze some time to read it.
04:05 dukeleto bacek: i have been enjoying it. you can find them very cheap online, used.
04:07 dukeleto bacek: much of the language of parrot internals seems to come from smalltalk
04:07 bacek dukeleto, I know that chromatic was pushing parrot into smalltalk direction. But I didn't realize how similar are two VMs.
04:08 dukeleto bacek: from what I see, pretty similar
04:13 JimmyZ joined #parrot
04:18 dalek TT #682 closed by coke++: Dynpmcs Don't Depend on Parrot::Pmc2c::*
04:18 dalek TT #682: http://trac.parrot.org/parrot/ticket/682
04:18 dalek TT #414 closed by coke++: [BUG] t/codingstd/c_cppcomments.t reports spurious error at hyperlinks
04:18 dalek TT #414: http://trac.parrot.org/parrot/ticket/414
04:50 Coke msg pmichaud can you respond to TT#1198? Danke.
04:50 aloha OK. I'll deliver the message.
04:50 Coke msg cotto didn't you reject TT#1175?
04:50 aloha OK. I'll deliver the message.
05:12 dukeleto bacek: turns out smalltalk-80 is stack based, but also continuation-based. But it doesn't do CPS
05:12 dukeleto bacek: it stores interp contexts in a stack
05:13 dukeleto
05:14 JimmyZ seems that cotto want CPS is on top of M0 and dukeleto wants M0 is CPS based.
05:17 bacek dukeleto, yeah...
05:19 bacek dukeleto, speaking of yaml. Can we change current format slightly?
05:20 nopaste "bacek" at 192.168.1.3 pasted "Proposed change to DEPRECATED.yaml" (11 lines) at http://nopaste.snit.ch/29487
05:20 bacek dukeleto, see nopaste
05:23 dukeleto bacek: can you make that change in my branch?
05:23 dukeleto bacek: you will see that i cleaned up the YAML considerably
05:23 dukeleto bacek: leto/deprecations_as_data
05:24 bacek dukeleto, ok.
05:29 dalek parrot/leto/deprecations_as_data: 56c3abc | bacek++ | docs/changes/api.yaml:
05:29 dalek parrot/leto/deprecations_as_data: Change format of api.yaml to be list of hashes
05:29 dalek parrot/leto/deprecations_as_data: review: https://github.com/parrot/parrot/commit/56c3abcb6a
05:29 bacek dukeleto, done
05:30 nopaste "bacek" at 192.168.1.3 pasted "Eat own dog food with nqp-based port of YAML::Tiny :)" (23 lines) at http://nopaste.snit.ch/29488
05:31 bacek dukeleto, see http://nopaste.snit.ch/29488 "good enough" for me :)
05:32 bacek dukeleto, we can switch off from Perl5 for "api.yaml-handling-tools"
05:34 dukeleto good lord
05:34 * dukeleto looks
05:35 * bacek hate YAML even more now.
05:37 bacek dukeleto, https://github.com/bacek/YAML--Tiny
05:38 dukeleto bacek: you are hilarious :)
05:39 bacek dukeleto, it was kind of funny, actually.
05:39 bacek To port YAML::Tiny to nqp.
05:39 dukeleto bacek: why so?
05:39 bacek But my point about YAML still stand. YAML suck big time.
05:40 bacek dukeleto, I didn't write any "high level code" in about last 6 month :)
05:44 * cotto gets back and looks
05:46 dukeleto bacek: looks like you still can :)
05:47 cotto bacek, what format wouldn't you hate?
05:47 dukeleto bacek: not ok 1 - Parse failed 'Could not find sub split'
05:48 dukeleto bacek: most of the test suite fails for me. Does this require a very new NQP?
05:48 bacek dukeleto, on your branch?
05:48 dukeleto bacek: no, in the YAML--Tiny repo
05:48 bacek dukeleto, yes, I fixed nqp-setting slightly. Better to use master parrot :)
05:48 bacek or update your branch to master.
05:53 dukeleto bacek: hokey dokey
05:53 sorear Why -- ?
05:54 plobsing github converts punct to - by default
05:54 rurban_ joined #parrot
05:55 cotto bacek, thanks for working on that
05:55 plobsing also non-ascii. Ωη;)XD had this issue in spades. came out as ----XD
05:55 bacek dukeleto, ?
05:55 dukeleto bacek: yes?
05:55 cotto How long does it take to parse DEP.yaml?
05:56 bacek cotto, it's already parsable in leto/deprecations_as_data :)
05:56 bacek dukeleto, "<dukeleto> bacek: hokey dokey"
05:56 bacek dukeleto, success?
05:56 dukeleto bacek: that means "ok i will do that"
05:57 rurban left #parrot
05:57 rurban_ is now known as rurban
06:00 cotto I somehow haven't installed Parrot since 2.11.something
06:00 cotto time to fix that
06:02 cotto wheee
06:02 cotto /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.20.51-system.20100908 internal error, aborting at ../../bfd/merge.c line 872 in _bfd_merged_section_offset
06:02 cotto /usr/bin/ld: Please report this bug.
06:03 cotto I love parallel builds
06:11 dukeleto bacek: you need a 'clean' target in YAML::Tiny's makefile
06:12 bacek dukeleto, can you create repo in /parrot? I'll just push it in and everyone can cleanup/finish it
06:12 dukeleto bacek: yep, one sec
06:14 cotto and insall too
06:15 dukeleto bacek: https://github.com/parrot/yaml-tiny
06:15 theory left #parrot
06:16 cotto why not just put it in parrot.git?
06:16 dukeleto cotto: we can do that too, and will need to at some point
06:16 bacek dukeleto, pushed
06:16 bacek cotto, I want to polish it little bit more before including into parrot.
06:17 cotto sure
06:17 bacek afk #
06:19 dukeleto cotto: also, we can try using it as a git submodule
06:19 cotto dukeleto, why not
06:25 dukeleto cotto: quite a PDS, today
06:25 cotto dukeleto, yeah really
06:25 dukeleto cotto: what is your take?
06:26 cotto I need some time to digest it, but it seemed to be more positive than negative
06:27 cotto I was unprepared for how active it'd be.
06:28 sorear YAML::Tiny seems almost ... simple
06:28 sorear I'd love to see something like it replace yaml.org as the de facto spec
06:50 allison joined #parrot
07:05 allison left #parrot
07:07 allison joined #parrot
07:38 dalek yaml-tiny: e5358e7 | dukeleto++ | Makefile:
07:38 dalek yaml-tiny: Add a clean Makefile target
07:38 dalek yaml-tiny: review: https://github.com/parrot/y​aml-tiny/commit/e5358e7733
07:39 dalek yaml-tiny: ab874e1 | dukeleto++ | .gitignore:
07:39 dalek yaml-tiny: Add a .gitignore
07:39 dalek yaml-tiny: review: https://github.com/parrot/y​aml-tiny/commit/ab874e180f
08:12 dalek yaml-tiny: 911eeaa | cotto++ | Makefile:
08:12 dalek yaml-tiny: make clean less picky, add an install target
08:12 dalek yaml-tiny: review: https://github.com/parrot/y​aml-tiny/commit/911eeaafb4
08:23 cotto 5.4 seconds to parse api.yaml
08:24 cotto usable, but I'm looking forward to when it's .54 seconds
08:28 JimmyZ cotto, I'd like see your comment on http://trac.parrot.org/parrot/ticket/1992
08:32 dalek TT #1992 created by jimmy++: [NCI] callback sub parameter definition isn't unified with  callback ...
08:32 dalek TT #1992: http://trac.parrot.org/parrot/ticket/1992
08:32 Psyche^ joined #parrot
08:35 Patterner left #parrot
08:35 Psyche^ is now known as Patterner
08:35 JimmyZ msg plobsing I'd like see your comment on http://trac.parrot.org/parrot/ticket/1992
08:35 aloha OK. I'll deliver the message.
08:54 cotto JimmyZ, ok.  I need to plow through the backlog of tickets.  I'll make sure to address that one.
08:54 * cotto sleeps
08:54 JimmyZ thanks , night
09:04 allison_ joined #parrot
09:04 allison left #parrot
09:05 dalek yaml-tiny: 3ce229f | bacek++ | / (2 files):
09:05 dalek yaml-tiny: Fix handling of 'inline nested hashes'
09:05 dalek yaml-tiny: review: https://github.com/parrot/y​aml-tiny/commit/3ce229f48e
09:05 JimmyZ left #parrot
09:48 contingencyplan left #parrot
10:28 fperrad joined #parrot
10:37 dalek yaml-tiny: 487589a | bacek++ | t/11_meta_yaml.t:
10:37 dalek yaml-tiny: Copy test from Perl5 YAML::Tiny
10:37 dalek yaml-tiny: review: https://github.com/parrot/y​aml-tiny/commit/487589a7c6
10:37 dalek yaml-tiny: ef664df | bacek++ | t/02_basic.t:
10:37 dalek yaml-tiny: Untodo test
10:37 dalek yaml-tiny: review: https://github.com/parrot/y​aml-tiny/commit/ef664dfbc7
10:39 dalek nqp-cl-parser: 0e62a62 | moritz++ | do.pl:
10:39 dalek nqp-cl-parser: fix attribute name, masak++
10:39 dalek nqp-cl-parser: review: https://github.com/moritz/nqp​-cl-parser/commit/0e62a6257d
10:39 moritz oops, that should have gone to #perl6
10:45 sheant joined #parrot
11:13 dalek yaml-tiny: 5a55e2b | bacek++ | / (4 files):
11:13 dalek yaml-tiny: Generate Undef instead of Nulls. Reclaim few more tests
11:13 dalek yaml-tiny: review: https://github.com/parrot/y​aml-tiny/commit/5a55e2b16b
11:21 dalek yaml-tiny: 4d712bc | bacek++ | / (2 files):
11:21 dalek yaml-tiny: Fix parsing YAML header
11:21 dalek yaml-tiny: review: https://github.com/parrot/y​aml-tiny/commit/4d712bc94b
11:47 whiteknight joined #parrot
11:59 dalek nqp-rx/nom: 29337fb | moritz++ | src/metamodel/reprs/P6opaque.c:
11:59 dalek nqp-rx/nom: distinguish "P6opaque attributes" error messages (no additional value for the user)
11:59 dalek nqp-rx/nom: review: https://github.com/perl6/nqp-rx/commit/29337fb49b
12:08 nopaste "mikehh" at 192.168.1.3 pasted "problems with tt1954_eliminate_make_docs branch" (40 lines) at http://nopaste.snit.ch/29545
12:27 Eclesia joined #parrot
12:27 Eclesia hi
12:38 Eclesia left #parrot
12:43 sheant left #parrot
12:46 whiteknight good morning, #parrot
13:35 kid51 joined #parrot
13:52 sheant joined #parrot
13:54 rurban_ joined #parrot
13:56 whiteknight left #parrot
13:57 rurban left #parrot
13:57 rurban_ is now known as rurban
14:01 kid51 left #parrot
14:04 ambs joined #parrot
14:05 szabgab anyone coming to FOSDEM ? http://fosdem.org/2011/interview/david-fetter-2011
14:31 * sjn wishes he could :-(
14:31 sjn I _really_ wanted, but alas, I can't afford it
14:40 Kristaba joined #parrot
15:53 Coke someone on the board should point OSUOSL at TT #1838
16:05 Coke (git submodule--)
16:06 Coke msg cotto someone on the board should point OSUOSL at TT #1838 - not much we can do about it.
16:06 aloha OK. I'll deliver the message.
16:43 cotto ~~
17:00 ambs left #parrot
17:25 kid51 joined #parrot
17:34 NotFound left #parrot
17:42 tadzik left #parrot
17:43 tadzik joined #parrot
17:54 theory joined #parrot
18:17 Hackbinary hello
18:18 Hackbinary is there a library that I have to include in an actions.pm file to able to use say() to print messages to the console, or is there another print funciton that I should .. just for debugging.
18:19 cotto It's nice to see tickets going away.
18:19 cotto Hackbinary, nqp-setting.pm or something similar
18:20 arnsholt There's also pir::say()
18:20 cotto pir::load_bytecode("nqp-setting.pbc");
18:20 arnsholt Which does pretty much the same thing IIRC
18:21 cotto but you have to type "pir::", which is less lazy than necessary
18:21 cotto ;)
18:21 arnsholt True. But pir::load_bytecode is kinda long as well ;)
18:21 arnsholt Depends on how much say()ing is required I guess =)
18:22 cotto your call
18:22 cotto there's some other functions that it also provides that make life a little nicer
18:22 Hackbinary cool :)
18:45 contingencyplan joined #parrot
19:03 dukeleto ~~
19:04 cotto hi dukeleto
19:04 dukeleto cotto: how do you feel about the leto/deprecations_as_data_branch?
19:04 dukeleto cotto: also, hello :)
19:06 dukeleto bacek: you changed the format of the api.yaml in my branch, which I like, but you didn't change the scripts that use it => -1
19:07 * dukeleto goes outside for a change
19:08 cotto dukeleto, reviewing now
19:09 cotto thanks for cleaning up the file
19:19 fperrad left #parrot
19:20 kid51 left #parrot
19:21 jan left #parrot
19:31 cotto I'm still not a fan of the name "api.yaml" and the location in docs.
19:32 cotto I don't like having something we expect to change frequently in docs/
19:37 * dukeleto had to take out the recycling
19:37 dukeleto cotto: where do you want it to live?
19:37 dukeleto cotto: what do you want it called?
19:38 dukeleto cotto: API.yaml in the root directory ?
19:38 dukeleto cotto: i really don't care
19:38 cotto dukeleto, I'm trying to figure that out.
19:39 cotto bacek's change looks like a good idea.  Indexing an array by deprecation name struck me as an unusual choice.
19:41 dukeleto cotto: i have updated the scripts to use that format
19:41 cotto beat me to it
19:43 dukeleto incoming
19:43 dalek parrot/leto/deprecations_as_data: 52cf771 | dukeleto++ | / (5 files):
19:43 dalek parrot/leto/deprecations_as_data: Make api.yaml scripts use the new format that makes bacek++ and cotto++ happy
19:43 dalek parrot/leto/deprecations_as_data: review: https://github.com/parrot/parrot/commit/52cf771a69
19:44 dukeleto cotto: the name isn't that important. I hear that you want it in /, is that correct ?
19:44 dukeleto cotto: i think API.yaml works for now, we can always change it
19:44 dukeleto cotto: our scripts provide the layer of abstraction between the name and end-users
19:44 dukeleto cotto: so our end-users just go ahead and use the scripts, which know where to look. Only parrot devs manually edit that file
19:44 Hackbinary hello
19:44 dukeleto Hackbinary: howdy
19:45 cotto dukeleto, I'd prefer / and I agree about the details
19:45 dukeleto cotto: what about API.yaml in / ? Shall I do that?
19:45 Hackbinary where is the best place to lookup information on PAST structure information
19:45 Hackbinary ?
19:45 cotto "API.yaml" isn't a perfect fit, but I don't care to bikehsed it any further.
19:45 Hackbinary :D
19:45 cotto dukeleto, +1
19:45 dukeleto cotto: do you want it to be a SHOUTING file? or api.yaml ?
19:45 cotto EBIKESHED
19:45 dukeleto cotto: ok, i will make it happen
19:46 cotto dukeleto++
19:46 dukeleto Hackbinary: parrot/tree-optimization is probably a good place
19:46 dukeleto Hackbinary: look at it's test suite
19:46 dukeleto Hackbinary: http://github.com/parrot/tree-optimization
19:46 dukeleto Hackbinary: that library will also help you optimize your PAST
19:47 dukeleto cotto: one other issue
19:47 cotto ok
19:47 dukeleto cotto: i want something like api.yaml and old_api.yaml, where, instead of deleting stuff from api.yaml, we put it into a historical file
19:48 dukeleto cotto: instead of that, we could give stuff in api.yaml the tag of "historical" or something
19:48 cotto dukeleto, why not just mark it as "old" and stick it at the bottom of the file?
19:48 dukeleto cotto: what thinks you?
19:48 dukeleto cotto: sure, we will have a tag called "old", that is reasonable
19:48 cotto a single file appeals to my laziness
19:48 dukeleto cotto: i like that too
19:48 dukeleto cotto: where should i put docs relating to api.yaml ?
19:49 cotto dukeleto, if they're short they could go inline as comments at the beginning of the file
19:49 dukeleto cotto: was thinking that as well. is there something like a YAML comment ?
19:49 cotto if not, maybe README.api.yaml or something suitaly obvious
19:50 cotto *suitably
19:50 cotto wfm
19:54 dalek parrot/leto/deprecations_as_data: b7c3ab4 | dukeleto++ | / (10 files):
19:54 dalek parrot/leto/deprecations_as_data: docs/changes/api.yaml is now api.yaml
19:54 dalek parrot/leto/deprecations_as_data: review: https://github.com/parrot/parrot/commit/b7c3ab459f
19:54 dalek parrot/leto/deprecations_as_data: b67a954 | dukeleto++ | t (4 files):
19:54 dalek parrot/leto/deprecations_as_data: Tell scripts that api.yaml has moved
19:54 dalek parrot/leto/deprecations_as_data: review: https://github.com/parrot/parrot/commit/b67a954af5
19:54 dukeleto cotto: ok, i gonna merge this
19:55 dukeleto cotto: we are not using yaml-tiny yet, still using my perl 5 tools
19:55 dukeleto cotto: others can bikeshed that
19:55 dukeleto cotto: i just want this data in a usuable format
19:55 dukeleto cotto: i am sure we will have many tools to interface with it, in various languages
19:55 cotto dukeleto, go for it!
19:57 cotto I'd like to revert a3f6638ef39 and mark the changes it removes as "completed", but there's no rush.
19:58 dukeleto cotto: i think i will deal with that in my merge
19:59 cotto great
19:59 dukeleto lots of dumb conflicts
20:00 cotto yeah
20:00 cotto looks like a couple others got removed too
20:02 dukeleto cotto: can you look at docs/stability.pod ?
20:02 dukeleto cotto: it is severely out of touch with reality
20:02 dukeleto cotto: it has terms we never use
20:04 cotto dukeleto, sure
20:04 cotto I remember when particle introduced that idea.
20:04 cotto There's nothing wrong with it but it never really caught on.
20:05 dalek parrot: 56c3abc | bacek++ | docs/changes/api.yaml:
20:05 dalek parrot: Change format of api.yaml to be list of hashes
20:05 dalek parrot: review: https://github.com/parrot/parrot/commit/56c3abcb6a
20:05 dalek parrot: 52cf771 | dukeleto++ | / (5 files):
20:05 dalek parrot: Make api.yaml scripts use the new format that makes bacek++ and cotto++ happy
20:05 dalek parrot: review: https://github.com/parrot/parrot/commit/52cf771a69
20:05 dalek parrot: b7c3ab4 | dukeleto++ | / (10 files):
20:05 dalek parrot: docs/changes/api.yaml is now api.yaml
20:05 dalek parrot: review: https://github.com/parrot/parrot/commit/b7c3ab459f
20:05 dalek parrot: b67a954 | dukeleto++ | t (4 files):
20:05 dalek parrot: Tell scripts that api.yaml has moved
20:05 dalek parrot: review: https://github.com/parrot/parrot/commit/b67a954af5
20:05 dalek parrot: f4fcd0e | dukeleto++ | / (11 files):
20:05 dalek parrot: Merge branch 'leto/deprecations_as_data'
20:05 dalek parrot:
20:05 dalek parrot: Conflicts:
20:05 dalek parrot: MANIFEST
20:05 dalek parrot: docs/project/cage_cleaners_guide.pod
20:05 dalek parrot: docs/project/release_manager_guide.pod
20:05 dalek parrot: docs/project/support_policy.pod
20:05 dalek parrot: docs/stability.pod
20:05 dalek parrot: src/pmc/object.pmc
20:05 dalek parrot: review: https://github.com/parrot/parrot/commit/f4fcd0e7e9
20:05 dukeleto cotto: it has terms like "Private" and "Evolving" that we never use
20:07 cotto The TODO item is telling.
20:09 cotto dukeleto, did you add a tag to the completed items?
20:10 cotto looks like not
20:11 cotto the nice thing about having this be data is that can (semi) automatically check to see if the relevant tickets have been closed.
20:13 cotto It's times like this that I wish trac had an api.
20:16 cotto I guess we can resort to screen scraping.
20:17 dalek parrot: 3f45e06 | dukeleto++ | api.yaml:
20:17 dalek parrot: Mark recently removed deprecations as 'done' in api.yaml
20:17 dalek parrot: review: https://github.com/parrot/parrot/commit/3f45e0689e
20:17 dalek parrot: 947fb07 | dukeleto++ | DEPRECATED.yaml:
20:17 dalek parrot: Remove DEPRECATED.yaml, which is now called api.yaml
20:17 dalek parrot: review: https://github.com/parrot/parrot/commit/947fb07fca
20:17 dalek parrot: e23d5c7 | dukeleto++ | tools/dev/show_ (2 files):
20:17 dalek parrot: Make show_(deprecated|experimental).pl skip things tagged as 'old'
20:17 dalek parrot: review: https://github.com/parrot/parrot/commit/e23d5c7e28
20:17 dukeleto cotto: there ya go
20:18 dukeleto cotto: we are now in the era of deprecations as data
20:20 cotto looking good
20:24 zby_home left #parrot
20:25 dalek TT #1888 closed by dukeleto++: Deprecations as data
20:25 dalek TT #1888: http://trac.parrot.org/parrot/ticket/1888
20:26 * dukeleto goes afk
20:26 dukeleto cotto: we have completed 1/3 goals for 3.3
20:26 dukeleto cotto: time to focus on Lorito, for me
20:31 cotto dukeleto, did you see bacek's link to the Lua VM intro?
20:31 cotto I've got a printed copy sitting by me and am planning on going through it as soon as I can concentrate.
20:32 dukeleto cotto: i bookmarked it, but haven't read it yet
20:32 moritz through the -w switch i learned that rakudo relies on Undef stringification, which is deprecated. Now... what I can about that?
20:32 dukeleto cotto: it looks good
20:32 dukeleto moritz: we should have a TT and wiki entry for it
20:32 dukeleto moritz: and if we don't, we will make them
20:33 cotto what dukeleto said
20:33 dukeleto moritz: also, take a look at tools/dev/show_deprecated.pl and api.yaml in the parrot repo
20:34 dukeleto moritz: if you have any suggestions for making it easer for Rakudo devs to learn about experimental/deprecated features, i would love to hear them
20:34 dukeleto moritz: there is also a tools/dev/show_experimental.pl
20:34 moritz $ perl tools/dev/show_deprecated.pl|grep Undef
20:34 moritz Use of uninitialized value $eligible in concatenation (.) or string at tools/dev/show_deprecated.pl line 39.
20:34 dukeleto moritz: yep, that is a bug in our data which needs to be fixed
20:35 dukeleto moritz: some items are missing tickets and/or eligible versions
20:35 moritz neither of them mentions Undef
20:35 moritz so... does this mean the Undef stringification deprecation is gone?
20:35 moritz or do I just misremember?
20:35 dukeleto moritz: perhaps that deprecation is not in our data, or it was removed before we switched to our new system
20:35 cotto moritz, if it's not implemented and it's not mentioned, you're clear
20:35 dukeleto moritz: not sure, the code that -w uses and api.yaml could very well be out of sync
20:35 jnthn moritz: What does Undef stringify to, ooc?
20:36 dukeleto moritz: can you gist the errors warnings that you get?
20:36 moritz rakudo: say ~pir::new('Undef')
20:36 p6eval rakudo 549d2a: OUTPUT«␤»
20:36 moritz jnthn: empty string
20:36 cotto https://github.com/parrot/parrot/commit/3be8a9cee is all I can find
20:36 jnthn moritz: If pmichaud++ agrees, we could s/Undef/NQPMu/
20:36 moritz $ ./parrot_install/bin/parrot -w perl6.pbc -e ''
20:36 moritz Stringifying an Undef PMC
20:36 moritz current instr.: 'perl6;PAST;Compiler;as_post' pc 4510 (compilers/pct/src/PAST/Compiler.pir:1084)
20:37 moritz that's with RELEASE_3_0_0-289-gbb69595
20:37 jnthn moritz: Undef really doesn't exist in Perl 6, so I'm not sure NQP using the notion of Undef is so wise.
20:38 moritz jnthn: seems to be from the PAST/POST compilers
20:38 jnthn Oh.
20:38 jnthn OK, guess that's harder to deal with in a hurry.
20:49 zby_home joined #parrot
20:51 tadzik left #parrot
20:51 tadzik joined #parrot
20:52 zby_home left #parrot
20:56 moritz jnthn: no hurry, since it's not in api.yaml as a deprecation :-)
20:56 jnthn :)
21:02 nopaste "bacek" at 192.168.1.3 pasted "show_expetimental.nqp for cotto and dukeleto :)" (46 lines) at http://nopaste.snit.ch/29613
21:03 bacek cotto, it works :)
21:05 tadzik nqp is quite nice
21:05 nwellnhof joined #parrot
21:05 tadzik (to read, to look at)
21:06 bacek tadzik, it's subset of Perl6 :)
21:06 nwellnhof bacek: how did you get the impression that atrodo's lorito is stack-based or has single byte opcodes?
21:06 bacek nwellnhof, rtfs and docs
21:07 nwellnhof yes, i did. it definitely hasn't single byte opcodes and the stack is only used for argument passing.
21:08 bacek "stack used for argument passing" is description of "stack-based VM"
21:08 nwellnhof well, it isn't really a stack. the opcodes are called push and pop, that's all.
21:09 nwellnhof lua vm is much more stack based.
21:10 Eclesia joined #parrot
21:11 Eclesia hi
21:11 bacek nwellnhof, yes, Lua's calling convention even more awful :)
21:11 nwellnhof but very efficient
21:13 bacek nwellnhof, yes, single memcpy to pass args. Little bit more work for RETURN.
21:14 bacek and with smart register allocator allows interesting optimizations
21:15 cotto bacek, nice nqp script
21:15 bacek cotto, direct port of dukeleto++ show_experimental.pl :)
21:16 cotto bacek, do you know if Lua is used for any large project or if it's just for embedding?
21:17 bacek cotto, it's quite popular in gamedev as scripting language. I embedded it into some webframework few years ago.
21:17 bacek cotto, not sure about "standalone big lua app"
21:17 nwellnhof http://en.wikipedia.org/wiki/Lua_%28​programming_language%29#Applications
21:17 cotto Yeah.  The tool-assisted speedrun people do cool things embedding it into emulators.
21:19 bacek cotto, if someone (including you) can finish multiline scalars parsing in yaml-tiny it's ready.
21:20 bacek either as ext/yaml-tiny or runtime/parrot/library/YAML/TIny
21:20 bacek I'm not going to implement serialization in it anyway
21:20 bacek afk # $dayjob
21:21 cotto looks like Prosody is ~20kloc of Lua
21:21 Hackbinary cotto, bacek I've seen lua used on linksys, dlink and netgear routers
21:22 cotto Yeah.  I'm looking for applications where it's not used as an embedding language.
21:22 cotto I'm wondering if its high suitability for embedding means it's lta for larger apps.
21:23 cotto though the counterargument to any mention of language suitability is PHP
21:23 bacek cotto, Lua language - probably no. Lua VM - is kind of good enough :)
21:26 cognominal left #parrot
21:29 cognominal joined #parrot
21:34 * atrodo has a lot of backscrolling to do
21:35 cotto atrodo, indeed.
21:55 rurban_ joined #parrot
21:59 rurban left #parrot
21:59 rurban_ is now known as rurban
21:59 atrodo I hope someone has a chance to write a tl;dr version
22:10 PacoLinux left #parrot
22:13 Eclesia left #parrot
22:46 whiteknight joined #parrot
22:47 pmichaud draft of nqp plan for comment/improvement before I publish it to parrot-dev
22:47 pmichaud http://pmichaud.com/sandbox/nqp.txt
22:50 Kristaba left #parrot
22:52 dalek parrot: e731419 | bacek++ | src/nci/libffi.c:
22:52 dalek parrot: Pacify compiler about absense on default case in switch.
22:52 dalek parrot: review: https://github.com/parrot/parrot/commit/e731419a83
22:52 dalek parrot: a00d590 | bacek++ | src/nci/libffi.c:
22:52 dalek parrot: Avoid (useless) cast INTVAL to size_t
22:52 dalek parrot: review: https://github.com/parrot/parrot/commit/a00d5906b9
22:52 dalek parrot: 01fabfb | bacek++ | config/auto/warnings.pm:
22:52 dalek parrot: Remove -Wbad-function-cast.
22:52 dalek parrot:
22:52 dalek parrot: According to gcc info it's kust helps to catch undeclared functions
22:52 dalek parrot: error. We do have special -Wimplicit to catch it.
22:52 dalek parrot: review: https://github.com/parrot/parrot/commit/01fabfbe1b
22:52 dalek parrot: e19f32b | bacek++ | src/runcore/main.c:
22:52 dalek parrot: Use explicit const_cast to pacify compiler.
22:52 dalek parrot: review: https://github.com/parrot/parrot/commit/e19f32baca
22:52 dalek parrot: 2709a45 | bacek++ | MANIFEST:
22:52 dalek parrot: mk_manifest_and_skip
22:52 dalek parrot: review: https://github.com/parrot/parrot/commit/2709a45aad
23:03 cotto pmichaud, reading now
23:03 cotto and for the next several minutes, apparently
23:05 cotto glad to see that "nqp" is being defined as separate from the current nqp-rx
23:08 sheant left #parrot
23:09 cotto pmichaud, thank you for spelling that out.
23:11 mikehh cotto: what are your thouhts on this?
23:12 cotto It's a natural move for the Rakudo hackers to make.  Parrot's use of nqp-rx in core does seem less than optimal now, though.
23:14 mikehh I think we should use whatever tools are available (maybe modified) but I don't see a major problem with "nqp"
23:15 cotto It's been useful as a higher-level abstraction over Parrot guts, and nqp explicitly will be less guts-oriented.
23:15 hudnix left #parrot
23:15 cotto (from a Parrot core dev pov)
23:16 AzureSto_ joined #parrot
23:16 mikehh as I see it we can use it to develop other interfaces as necessary
23:17 hudnix joined #parrot
23:18 AzureStone left #parrot
23:21 mikehh bacek: g++ don't like the cast in src/runcore/main.c
23:22 cotto I wondered about that.
23:24 mikehh src/runcore/main.c: In function ‘void parrot_hash_oplib(parrot_interp_t*, op_lib_t*)’:
23:24 mikehh src/runcore/main.c:347:50: error: invalid const_cast from type ‘const char*’ to type ‘void*’
23:24 mikehh src/runcore/main.c:350:58: error: invalid const_cast from type ‘const char*’ to type ‘void*’
23:24 mikehh src/runcore/main.c:351:54: error: invalid const_cast from type ‘const char*’ to type ‘void*’
23:30 hudnix left #parrot
23:48 kid51 joined #parrot
23:58 kid51 "And yes, the new NQP is explicitly designed to enable and other languages ..."   -- the 'and' is superfluous.
23:59 kid51 "... we may increase of efforts in this area."  s/of/our/

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

Parrot | source cross referenced