Camelia, the Perl 6 bug

IRC log for #parrot, 2010-12-07

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 fbrito whiteknight: I will push some code soon in my PLA fork and ask for feedback here :)
00:02 Matt_ whiteknight: I searched through the code and the path doesn't seem to be stored in PackFile, so I assign it after calling PackFile_new in functions that get passed the filename as a parameter
00:04 kid51 whiteknight: patches applied to the embed_api2 branch today do not fix the problem on Darwin, though they do reduce the volume of warnings somewhat
00:05 nwellnhof whiteknight: feel free to commit your Win64/MSVC changes to nwellnhof/compilerflags btw
00:05 nopaste "kid51" at 192.168.1.3 pasted "embed_api2: build failures persist on Darwin" (319 lines) at http://nopaste.snit.ch/26733
00:07 NotFound Matt_: Get a filename from the content of a packfile that can not be read? Awesome!
00:12 NotFound About the Key thing: if we are planning to replace Key with RPA, as some people have suggested sometimes, a first step should be making its vtable more compatible.
00:13 nwellnhof seems that headerizer needs to be run in branch embed_api2
00:14 kid51 I will try that
00:16 plobsing looking for the error text in TT #1833, it appears only in ImageIOThaw on the arbitrary strings codepath. there is *no* file associated with that error.
00:17 NotFound plobsing: even more amazing!
00:17 plobsing I'd close it as invalid.
00:18 fbrito whiteknight: sorry for the silly question, but if I have a 2x2 matrix and try to access a element using "matrix{Key.new(n)}", what should be returned? The n-th element on the 1st row, right?
00:18 plobsing I'd remove the arbitrary strings codepath entirely (it's not particularly useful), but testing ImageIO would get a whole lot more tricky.
00:18 Matt_ Hmm ok! Should I withdraw from the task on the GCI site?
00:19 plobsing Matt_: yes. sorry. we need better ticket triage it seems.
00:19 kid51 It looks like running headerizer.pl may have done the trick in the embed_api2 branch.
00:23 nwellnhof dukeleto: ping
00:24 dukeleto nwellnhof: pong
00:25 nwellnhof in git_workflow.pod, we should document how to create a tracking branch.
00:25 nwellnhof (git checkout --track -b ...)
00:26 dukeleto nwellnhof: tracking is default for the versions of git that the workflow recommends
00:26 dukeleto nwellnhof: and the README mentions --track
00:26 dukeleto nwellnhof: but yes, you are probably correct
00:26 dalek parrot/embed_api2: c7def2f | jkeenan++ | / (2 files):
00:26 dalek parrot/embed_api2: Run 'perl tools/dev/headerizer.pl src/embed/api.o'.
00:26 dukeleto nwellnhof: what version of git are you using?
00:26 dalek parrot/embed_api2: review: https://github.com/parrot/parrot/commit/c7def2f52a
00:26 dukeleto 1.5.x is painfully old
00:27 lucian left #parrot
00:27 nwellnhof git version 1.7.2.3
00:27 plobsing perhaps exceptions originating from c should inlucde __LINE__ and __FILE__, to make tracking them easier so we can avoid thinkos like TT #1833 in the future.
00:27 dukeleto nwellnhof: then you don't need --track
00:27 kid51 On 1.5.x, when you want to track a branch, the syntax is: git checkout --track -b <newbranch> <origin/newbranch>
00:27 nwellnhof dukeleto: simply omit --track?
00:28 dukeleto nwellnhof: yep
00:28 kid51 nwellnhof On 1.6 and 1.7, yes.  Alas, not on 1.5
00:28 dalek parrot: 45523d2 | dukeleto++ | README:
00:28 dalek parrot: [doc] Tweak formatting in README
00:28 dalek parrot: review: https://github.com/parrot/parrot/commit/45523d2310
00:28 dukeleto kid51: you can also use -t
00:31 donaldh left #parrot
00:35 kid51 is now known as kid51_at_dinner
00:35 dalek TT #1833 closed by plobsing++: Incompatible bytecode error lacks important information
00:35 dalek TT #1833: http://trac.parrot.org/parrot/ticket/1833
00:37 whiteknight fbrito: If you use 1 key, it treats the matrix like a normal C array
00:37 fbrito oh, totally forgot about that. thank you :)
00:37 whiteknight fbrito: look at VTABLE get_pmc_keyed_int
00:38 dalek parrot: df599f5 | dukeleto++ | docs/project/git_workflow.pod:
00:38 dalek parrot: [doc] Describe how to track remote branches in elderly Gits
00:38 dalek parrot: review: https://github.com/parrot/parrot/commit/df599f5414
00:39 dukeleto plobsing: that ticket you just rejected is a GCI task
00:39 dukeleto plobsing: and you are wrong that those errors only happen in ImageIO
00:39 dukeleto plobsing: they happen whenever the PBC format changes and the wrong parrot is used to read bytecode
00:39 dukeleto plobsing: which happens a lot
00:40 plobsing dukeleto: grep the source. that's the only place it shows up.
00:41 plobsing there are only 2 places that call PackFile_unpack. only one of them gives that error on failure.
00:41 dalek parrot: 20ae439 | nwellnhof++ | docs/project/git_workflow.pod:
00:41 dalek parrot: [doc] Fix order of git command line options
00:41 dalek parrot: review: https://github.com/parrot/parrot/commit/20ae439fb4
00:42 plobsing that error only happens when someone does the equivalent of '$P0 = thaw $S0'. how do you expect the packfile to know where the string came from?
00:43 dukeleto nwellnhof: danke for fixing that typo
00:43 dukeleto plobsing: i swear that error happens all the time in PL/Parrot when the wrong parrot version reads an incompatible bytecode file
00:44 plobsing that may be so, but there is nothing that can be done at the packfile level.
00:44 plobsing I suspect that some code may be slurping fpmc files (probably config hash) of the wrong format.
00:45 plobsing and not handling exceptions appropriately.
00:45 dukeleto plobsing: now that sounds like it is possible
00:46 dukeleto plobsing: is there *any* more info that we can give in the error? Perhaps a backtrace?
00:46 plobsing dukeleto: did you relink with config.o after the parrot update? failure to do that would cause this problem.
00:46 dukeleto plobsing: that error is really hard to debug for non-core devs
00:46 plobsing dukeleto: I think Parrot_ex_throw_from_c_args should provide a trace somehow.
00:47 dukeleto plobsing: it happens occasionally when i recompile a new parrot, but PL/Parrot finds my old parrot, and then Bad Things Happen
00:47 plobsing dukeleto: it is *trying* to save you from a segfault. although libparrot probably causes you to crash and burn anyhow.
00:48 dukeleto plobsing: that error segfaults my postgres process every time, so it is failing to save me from a segfault
00:49 plobsing yes, but imageio code is not to blame. exceptions code is. hot potato
00:51 dukeleto plobsing: i still thing that error needs to give more debug info. It is an essentially useless error
00:52 dalek TT #1833 reopened by dukeleto++: Incompatible bytecode error lacks important information
00:52 dalek TT #1833: http://trac.parrot.org/parrot/ticket/1833
00:52 dukeleto plobsing: it doesn't tell the person getting the error how to fix it or what threw the error or anything
00:53 dukeleto i remember getting stuck for weeks on that error and it driving me insane
00:53 plobsing so make Parrot_ex_throw_from_c_args a macro that includes __FILE__ and __LINE__
00:54 plobsing fire up gdb and break on Parrot_ex_throw_from_c_args
00:54 cotto ~~
00:57 plobsing dukeleto: what I'm getting at is that there is no more info that can be included at the point of error. Our exceptions system is lacking when it comes to errors originating from C, and our API is lacking in handling those exceptions.
01:04 dmalcolm left #parrot
01:09 dukeleto plobsing: i think i understand now
01:23 silug joined #parrot
01:24 nwellnhof plobsing: but shouldn't it be possible to add some meta information to the Packfile struct? like the filename where the data came from?
01:26 plobsing nwellnhof: not at all. '.sub 'main' :main; $S0 = freeze $P0; say $S0; .end' what "file" does that come from? the program that created it, which has no way of knowing the frozen string will be output or that the string it is outputing is a frozen pmc, or the file I may or may not be piping the output to?
01:27 plobsing or the c file that pmc gets mangled into? or the object file that c file compiles down to?
01:28 nwellnhof only in case the data comes from a file, of course.
01:28 plobsing if the data comes from a PBC file, that codepath is not taken.
01:32 nwellnhof but it seems that people are getting this error when running some files from an old Parrot installation. so it should be somehow traceable to a certain file. at least in theory.
01:34 plobsing it would be best if we got a C backtrace from C exceptions that never hit a runloop (such as is the case here) so we could easily identify the source
01:34 plobsing I suspect a stale config-hash is the culprit
01:36 kid51_at_dinner embed_api2 now PASS on Darwin:  http://smolder.parrot.org/app​/projects/report_details/1535
01:36 whiteknight kid51_at_dinner: awesome
01:36 whiteknight I was about to fix it, but I just saw your commit
01:38 cotto kid51_at_dinner, nice work
01:38 cotto which ocx?
01:39 cotto osx
01:39 kid51_at_dinner is now known as kid51
01:39 kid51 I'm on 10.4
01:39 kid51 old school
01:39 whiteknight bluescreen++ fixed the underlying error earlier, kid51++ put on the finishing touches
01:40 kid51 is bluescreen Mariano Wahlmann?
01:40 cotto yes
01:41 kid51 cotto:  I doubt /usr/include/stdin.h changes much between Darwin versions, so I suspect we would have gotten this problem on 10.5 or 10.6.
01:41 kid51 And, for once, it has *nothing* to do with how much RAM I have.
01:42 cotto I'm curious because I just closed an old ticket that was on 10.5
01:42 Matt_ left #parrot
01:48 gg411 left #parrot
01:50 kid51 Well, I don't think you have to worry too much about that ticket (TT #1247), cotto.
01:50 kid51 allison knows how to file tickets ;-)
01:51 cotto kid51, I suspect that she does
01:54 nwellnhof plobsing: afaics, the codepath *is* taken when reading a PBC with load_bytecode
01:54 nwellnhof see Parrot_pbc_read in src/embed.c
01:55 allison kid51: I really couldn't tell you, I haven't done any Mac development in a long time
01:55 allison kid51: I would assume it's not an issue any more, as no one else has complained about it
01:56 plobsing nwellnhof: look at the *second* line of the error message. now look at the error message in Parrot_pbc_read(). they are not the same.
01:56 plobsing this is not the point of failure you are looking for
01:56 nwellnhof plobsing: yes, scratch that
01:58 kid51 Re http://trac.parrot.org/parrot/ticket/1883; does anyone understand what 'make bootstrap-ops' is really supposed to do?
01:59 plobsing kid51: it is supposed to rebuild the core ops library. it builds enough of parrot to run ./opsc --core
01:59 plobsing then it runs ./opsc --core, and rebuilds. At least that's my understanding.
02:00 cotto pretty much
02:00 kid51 So, why is it now DWIMming?
02:00 kid51 s/now/not
02:00 kid51 s/now/not/
02:01 plobsing looks like a non-default make target exposing a dependancy failure in our makefile.
02:03 fbrito hm, I really have to learn about pointers :P. can someone please take a quick look on this? http://pastie.org/1354231
02:04 fbrito I want to make it work, but without creating a new variable
02:04 plobsing we need to list the dependency of nqp-rx on cclass.pasm
02:07 plobsing fbrito: (1) doesn't compile because you need to predeclare variables. 'INTVAL element1, element2;' above the code should fix the build error.
02:09 plobsing fbrito: not sure why (2) segfaults, but you are aliasing a variable with a variable of a different type which is just asking for trouble.
02:10 fbrito I did what you suggested on (1) and it worked :o but I can't understand why it was working on (3) and not on (1)
02:10 nwellnhof plobsing: i think the problem with #1833 is thawing the config hash in Parrot_gbl_set_config_hash_interpreter in src/global_setup.c
02:12 plobsing nwellnhof: I agree with that diagnosis. And the solution to making that error easier to debug would be (a) to have access to a C level backtrace or (b) for it to be possible to handle exceptions from c (so Parrot_gbl_set_config_hash_interpreter() could spit out something intelligent about the situation).
02:12 bluescreen fbrito (2) you are redefining "key"
02:13 bluescreen not PMC *key and then PMC * const key
02:13 plobsing fbrito: C makes the distinction between variable declarations and code. Declarations start with a type and may include statements as initializers. However, once a line of code (which does not start with a type) has been hit, you cannot put another declaration line.
02:14 cotto whiteknight, ping
02:14 whiteknight pong
02:14 cotto is it a good time to talk about roadmaps?
02:14 fbrito plobsing: ahh, now I understand. thank you very much :)
02:15 cotto fbrito, you should get a copy of k&r if you don't have one already
02:15 cotto http://en.wikipedia.org/wiki/The_​C_Programming_Language_%28book%29
02:15 whiteknight cotto: sure
02:16 whiteknight k&r is a good book, but a ripoff
02:16 whiteknight same price now as it was 40 years ago
02:17 fbrito cotto: I will take a look, thank you. Before CGI I (almost) only worked with high level languages, like Python and Ruby
02:17 cotto I've recently become a fan of a minimalist ticket queue, so I'm trying to think if tickets are the mechanism we should use for tracking roadmap items in the future.
02:18 whiteknight I dont think so
02:18 cotto Integration with the rest of trac is nice, but if we continued to use them as we have been, most of the work would be pushing tickets back.
02:18 whiteknight they end up too vague and open-ended
02:18 cotto I want what we to do be transparent and accurate as much as possible.
02:19 whiteknight right
02:19 whiteknight tickets in a huge queue are obuscated
02:19 whiteknight obfuscated
02:20 cotto I'm not sure if it's possible, but I'd love to see a 100 ticket queue.
02:20 kid51 For all but a handful of us (not including me), such tickets are untakeable and uncloseable
02:20 whiteknight probably not.projects with queues that small are typically smaller and special-purposed
02:20 whiteknight memcached, etc
02:20 cotto kid51, that may be an innate problem
02:21 cotto most people don't know all parts of parrot or have experience with all platforms
02:22 whiteknight again, Parrot is big
02:22 cotto yes
02:22 whiteknight a smaller ticket queue means smaller Parrot
02:22 rfw oh, afternoon fbrito o/
02:23 cotto there's a correlation, though we're not near optimal yet
02:23 whiteknight no
02:24 cotto anyway, if we want the roadmap to be on trac that implies it'll be in either tickets, the wiki or something else I'm missing.\
02:24 fbrito rfw: Hello! Good evening (23:23 here :P). We should talk in private. They are discussing some important parrot related things here
02:24 cotto fbrito, rfw, no worries.  The channel can handle two threads of conversation.
02:24 whiteknight I like wiki
02:24 rfw (secret: i don't really have anything to talk about, i just wanted to say hi)
02:25 cotto whiteknight, me too.  It has the issue that it gets stale, but that's more an indication of how we're using it (or not)
02:26 whiteknight tickets get as stale or worse because they get burried
02:26 whiteknight lost on page 9/12
02:27 cotto that's where I usually hunt for lhf for closing
02:27 cotto Do you have any thoughts on how we should structure the roadmap?
02:27 cotto I guess that has a lot to do with the tuits of the volunteers working on its items.
02:28 whiteknight by supported release
02:28 whiteknight thats a course enough granularity but still useful
02:28 cotto I'm thinking that supported releases are the highest level of granularity we can reasonably say anything about
02:29 cotto apart from talking about the next release or two
02:29 bluescreen it is a pain in an company doing roadmap where you can count on heads... can't imagine in an OS project
02:30 bluescreen but the good thing is that in most companies people is unhappy and do the least is expected from them.... here people is really passionated about what they're a doing
02:31 cotto Yes.  It's good to know that nobody's here because they have to be.
02:31 plobsing people at companies get to work on their projects 40 hours a week...
02:31 cotto or more positively, everyone here wants to be here
02:31 whiteknight right, monthlies are too close together, and too hard to manage
02:33 whiteknight people work on what they want, it takes time to prepare a major goal
02:33 cotto What about having a relatively solid per-quarter plan for the next year, a general plan for the n+1 year and a vague idea of after that
02:33 whiteknight i like it
02:33 cotto and at the post-x.0 PDS, we figure out the next yearly roadmap
02:34 whiteknight good plan
02:34 nwellnhof plobsing: is there a way to get PARROT_PBC_MAJOR and PARROT_PBC_MINOR out of libparrot?
02:36 plobsing nwellnhof: ack says no.
02:36 plobsing and if it were possible, it put money on needing the config hash to get at it ><
02:36 plobsing s/it put/I'd put/
02:37 cotto whiteknight, ok.  I should have enough time to blog on that.  It's not a very complicated plan.
02:37 whiteknight cotto: general meta-plan out of the way, what are the goals for 2011
02:37 whiteknight ?
02:37 cotto The next step is to figure out what'll go on the roadmap
02:37 plobsing nwellnhof: do you want to compare the version you have versus the version expected? we can modify the error msg to include that info.
02:38 whiteknight MOP? Lorito? GC?
02:38 plobsing roads?
02:38 nwellnhof plobsing: forget it, it was a thinko.
02:38 cotto MOP first
02:38 whiteknight GC will happen concurrently methinks
02:38 cotto It's insanity to try and move to Lorito and change the mop, and I don't want to have to reimplement the current mop
02:39 kid51 What is the minimum set of improvements/feature additions you want to see in each of 3.0, 3.3, 3.6, 3.9?
02:39 cotto sure.  it's pretty orthogonal
02:39 cotto s/want/expect/
02:40 whiteknight jnthn and team have MOP. bacek and co have GC
02:40 whiteknight I'm sure plobsing and friends have packfile magic too
02:40 cotto me and my team have lorito
02:40 whiteknight right
02:40 whiteknight and I'm going to be on a beach somewhere drinking mohitos
02:41 cotto and there's no reason why we can't do Lorito and the MOP simultaneously
02:41 whiteknight in a secured location
02:41 whiteknight right
02:41 kid51 What do the architect and the project manager think they can deliver in each of the supported releases?
02:41 cotto whiteknight, wfm as long as you have your laptop with you on the beach
02:42 whiteknight :)
02:43 whiteknight as product manager, it probably makes most sense for me to focus on MOP, packfiles, and GC. in that order
02:43 kid51 As you can tell, I'm recommending confining the roadmap to what the leadership thinks it can reasonably promise to deliver
02:43 cotto kid51, absolutely
02:43 whiteknight by 3.6 I would like HLLs to be able to output bytecode directly, instead of PIR
02:43 kid51 Anything that happens above and beyond that is icing on cake.
02:44 cotto I want to underpromise and overdeliver rather than what we've been doing.
02:44 cotto or at least promise accurately
02:44 whiteknight MOP and packfile improvements can help to push HLLs to the next level
02:44 kid51 Which implies:  Nothing on the roadmap that the two of you aren't personally invested in -- even if others do most of the work.
02:44 whiteknight nice strategy
02:44 whiteknight kid51: fair
02:45 bluescreen whiteknight: +50 to output bytecode... but you have to have a nice debugger
02:45 whiteknight that's ancillary
02:45 cotto kid51, I'd say nothing goes in unless one of us or a known-reliable contributor is solidly invested in it
02:46 cotto but I agree with the sentiment
02:46 cotto not roadmaps without a champion
02:46 kid51 If there are things that the architect and project manager are merely lukewarm about, let others work on them but don't put them on roadmap.
02:46 cotto er, items
02:47 whiteknight I want the three things I mentioned by 4.0, no exceptions
02:47 cotto We can have a separate wishlist for other items
02:47 whiteknight so put my name down for those
02:48 whiteknight a "general" wishlist and a smaller roadmap
02:48 kid51 s/project manager/product manager/
02:49 kid51 By June, I would like you guys to be capable of giving talks at conferences like YAPC or OSCON where you can say, "We promised to deliver these features/improvements in Parrot in these releases -- and we did."
02:49 cotto A nice roadmap track record will give our community manager something nice to work with.
02:49 whiteknight yes
02:49 kid51 I want you to be capable of giving the kind of talk pmichaud gave at YAPC this year on Rakudo Start
02:49 kid51 Star
02:50 cotto kid51, I'm planning on doing that kind of thing.  It gives me a healthy fear atm.
02:51 kid51 Actually, if there are conferences/user groups in your local areas at which you guys could start doing presentations in, say, February, then that's when you should start doing them.
02:52 cotto kid51, good idea
02:52 whiteknight my availability for those kinds of things is low
02:52 kid51 Start with local Perl/Python/Ruby groups
02:52 whiteknight good idea, but hard to do
02:53 kid51 whiteknight:  For you (unlike the rest of us ;-) ), it's mainly a question of editing down what you've already written!
02:53 whiteknight :)
02:53 kid51 phila.pm, abe.pm or PLUG would probably be good first audiences
02:54 whiteknight PLUG?
02:54 kid51 Phila Linux users group
02:55 whiteknight ah
02:55 kid51 Have never attended myself, but mjd and other Phila perlmongers have presented there
02:55 cotto whiteknight, one concern I have is jnthn's uncertainty wrt the new MOP will be "ready".
02:55 cotto fsvo ready, of course
02:55 whiteknight of course
02:56 cotto I'd love to hear mjd talk.  I'd probably be lost after 5 minutes.  It'd be great.
02:57 cotto If I search for "Seattle PHP user's group", the 3rd entry is for a Perl user's group.  duckduckgo++
02:58 cotto I'm mostly curious what such a group would be like.
02:59 cotto there's not much we can do about the MOP design, apart from providing jnthn with extra minions.
03:00 cotto I trust him to get it right though.
03:00 whiteknight yeah, that's one thing we don't need to worry about
03:00 whiteknight What I really would like to do in 2011, is make a bootstrapped JavaScript compiler for Parrot
03:01 whiteknight once we have something that cool in our ecosystem, I think we will be able to start getting devs for other languages interested
03:01 cotto I saw some discussion about that fly by, but had to attend to other things at the time.
03:01 Matt_ joined #parrot
03:01 whiteknight python people, as an oft-cited example, don't want to make a Python compiler in Perl6
03:01 cotto There's a crazy amount of innovation happing with js right now.
03:01 whiteknight yes
03:03 whiteknight There exist JavaScript parsers written in javascript. If we create a Parrot bytecode backend, we have a JavaScript-on-Parrot compiler
03:04 whiteknight and then we can say to people like Python folks, or PHP folks, "hey, write your compiler for your language in your language. It's all cool with us"
03:04 whiteknight NQP-RX/PCT is very powerful, but it's Perl. for some people, that's an immediate turnoff
03:04 cotto That has potential to be a big draw.
03:04 whiteknight not everybody is as open to multiple languages as Parrot folk
03:04 whiteknight exactly
03:04 whiteknight JavaScript devs know JavaScript. They don't necessarily know C or Perl6
03:05 whiteknight so, let them write it in JavaScript, etc
03:05 whiteknight (repeat that statement for all X, where X is any programming language)
03:05 whiteknight I would like to get at least 1 other bootstrapped compiler project off the ground in 2011, and I think that will be a spark for a lot of people
03:06 whiteknight GSOC could provide us with several, if we play our cards right
03:06 whiteknight Anyway, I have to get moving to bed nowish. Continue the conversation later?
03:06 cotto a minimal bootstrappable language would be an interesting project
03:06 whiteknight yes
03:06 cotto sure
03:07 cotto 'night
03:07 whiteknight goodnight
03:07 Matt_ left #parrot
03:07 whiteknight left #parrot
03:19 bluescreen left #parrot
03:21 kid51_ joined #parrot
03:23 dalek parrot: d922b8a | nwellnhof++ | src/global_setup.c:
03:23 dalek parrot: [src] Better error message when linking against incompatible libparrot
03:23 dalek parrot:
03:23 dalek parrot: This should fix TT #1833.
03:23 dalek parrot: review: https://github.com/parrot/parrot/commit/d922b8a235
03:24 Matt_ joined #parrot
03:25 kid51 left #parrot
03:29 dalek parrot: 7717682 | nwellnhof++ | src/global_setup.c:
03:29 dalek parrot: [codingstd] Fix line length
03:29 dalek parrot: review: https://github.com/parrot/parrot/commit/7717682490
03:32 kid51_ nwellnhof: Is there any test we could write to verify the fix to TT #1833?
03:33 nwellnhof that's hard because one would have to link against a libparrot compiled with a different PBC_MAJOR or PBC_MINOR.
03:33 kid51_ I suspected as much, but I figured it wouldn't hurt to ask :-)
03:34 plobsing likely steps to reproduce: (1) build a custom parrot with bumped pbc compat. (2) build rakudo with this custom parrot. (3) swap in normal libparrot into same location.
03:34 kid51_ mucho trabajo
03:34 plobsing s/rakudo/any application that embeds libparrot/
03:35 * kid51_ must sleep
03:35 cotto kid51_, 'night
03:35 nwellnhof plobsing: i did something similar: ran an old rakudo build with a custom parrot.
03:38 kid51_ left #parrot
03:39 plobsing did it work? did you get the message?
03:39 nwellnhof yes, i did.
03:40 plobsing \o/ I'd say this case is closed (aside from broken encapsulation, which I don't know how to avoid in this instance)
03:40 plobsing nwellnhof++
03:40 kthakore joined #parrot
03:41 kthakore seen chromatic
03:41 aloha chromatic was last seen in #parrot 19 hours 34 mins ago saying "Me too, such as it's midnight.".
03:41 cotto fbrito, after you're done with k&r, you can go on to the advanced lesson: http://www.bobhobbs.com/files/kr_lovecraft.html
03:42 nwellnhof plobsing: yes, it's somewhat of a hack. but i think it's the best we can do for now.
03:45 bacek_at_work cotto, hey. What about resurrecting pmc_pct? :)
03:46 Matt_ left #parrot
03:47 cotto bacek_at_work, would it be more valuable to do that or get the packfile PMCs working?
03:47 Matt_ joined #parrot
03:47 bacek_at_work Packfiles are slightly more valuable.
03:47 cotto only slightly?
03:47 bacek_at_work But pmc_pct is more fun.
03:48 bacek_at_work cotto, we do need both at the end of they day.
03:49 Matt_ left #parrot
03:50 cotto bacek_at_work, what about http://irclog.perlgeek.de/p​arrot/2009-06-30#i_1275754
03:50 * cotto gets purl flashbacks
03:51 nwellnhof somehow, the whole idea of thawing the config hash seems flawed. if we have a stable embedding API, why shouldn't an executable be able work with libparrots that support different bytecode versions?
03:51 bacek_at_work cotto, yes. This idea still hold. But we need functional l1ops and Packfiles for it.
03:52 cotto ok
03:53 cotto I'm inclined to work on packfiles, mostly because I want to finish the work.
03:53 cotto but they're also nice and self-hosty
03:54 cotto bacek_at_work, if you were updating the packfiles, would you have one PMC type per struct or would you wrap all the bytecode stuff into a single PMC?
03:54 plobsing nwellnhof: agreed. thawing a config hash is extreme overkill for the ~4 values libparrot uses out of it.
03:55 bacek_at_work cotto, I'll give a look at your packfiles branch tonight. May be we can crack it fast.
03:55 bacek_at_work afk # meetings
04:28 gg411 joined #parrot
04:30 Matt_ joined #parrot
04:48 Matt_ left #parrot
04:49 Matt221 joined #parrot
04:51 Matt221 left #parrot
05:27 fbrito msg whiteknight I have just updated my GCI task. Please take a look when you have some time: http://www.google-melange.com/gci/task/show/goog​le/gci2010/parrot_perl_foundations/t129130043418
05:27 aloha OK. I'll deliver the message.
05:34 nwellnhof left #parrot
06:09 gg411 left #parrot
06:33 Kulag left #parrot
06:34 Kulag joined #parrot
06:42 Drossel joined #parrot
06:43 Kulag left #parrot
07:05 fbrito left #parrot
07:16 dalek left #parrot
07:17 dalek joined #parrot
07:26 cotto http://reparrot.blogspot.com/2010​/12/roadmaps-fact-or-fiction.html
07:52 bacek joined #parrot
08:02 jan left #parrot
08:03 cotto hio bacek
08:04 moritz cotto++ # roadmap thoughts
08:05 moritz personally, I'd even go one step further
08:05 moritz and decouple the development roadmap from the release roadmap completely
08:06 cotto moritz, please elaborate
08:06 moritz a time based release schedule is great
08:06 moritz but volunteer work doesn't tie well to schedules, in general
08:06 cotto It's done wonders for Parrot.
08:06 moritz so
08:07 moritz I'd propose to only promise dates for parrot releases, not features
08:07 moritz and have a separate development roadmap, which basically manages depencies among feature ideas
08:07 moritz like "we need lorito for JIT compilation"
08:07 moritz or "we need $thing for lorito first"
08:08 moritz and that development roadmap can also have time estimates, but it doesn't really need to
08:09 moritz cotto: does this make some kind of sense to you?
08:09 cotto That's worth thinking about.  A separate development roadmap would get daunting, but it'd also show us where to put effort to reach our goals.
08:09 cotto very much
08:09 moritz well
08:10 moritz it would make the release roadmap basically just a list of dates, versions and an [X] for supported releases
08:10 moritz so you'd have two lists to maintain, but one would be rather slim (and mostly autogenerated, if somebody steps up and writes a tool that generates it)
08:11 cotto I like the general idea (though I want to have features tied to releases where we know we can get them done), but I don't know how managing that on the wiki would work.
08:11 cotto that being the dev roadmap
08:12 moritz neither do I :-)
08:12 moritz I just made the experience that the only time you can plan is your own, and even that only in limits
08:13 cotto very true
08:13 cotto btw, I'm loving the Perl 6 Advent Calendar this year.
08:13 moritz good to hear, thanks
08:17 jhelwig left #parrot
08:23 sorear maybe I'll do something for it
08:23 cotto sorear, what do you mean?
08:25 moritz like, a post? or two? :-)
08:31 fperrad joined #parrot
08:33 sorear moritz: that sort of thing, yes
08:34 sorear I'm still trying to understand what it really *wants*
08:35 moritz that's easy: something related to Perl 6 that outsiders might find interesting to read
08:35 moritz where "outsiders" mostly means "programmers who are familiar with other languages, and have heard a bit about Perl 6"
08:44 * cotto sleeps
08:52 sorear most of my familiarity with that kind of person involves them laughing at Perl 6
08:54 moritz sorear: you've read too many reddit comments :-)
08:54 moritz sorear: but fact is that many of those posts attract more than 1k readers, and most comments are very positive
08:55 sorear moritz: no, I just hang out on irc.perl.org a lot.
08:55 moritz and there's a considerable interest in non-empty Perl 6 talk in the Perl 5 community too, though some p5 people brag very loudly how much they don't care
08:56 moritz sorear: don't let a loud minory discourage you
09:00 lucian joined #parrot
09:31 rfw left #parrot
10:06 Drossel left #parrot
10:06 Kulag joined #parrot
10:48 dalek left #parrot
10:49 dalek joined #parrot
11:04 AndChat| joined #parrot
11:12 AndChat| left #parrot
11:16 contingencyplan left #parrot
11:17 lucian2 joined #parrot
11:20 lucian2 left #parrot
11:21 AndChat| joined #parrot
11:25 AndChat| left #parrot
11:26 lucian2 joined #parrot
11:30 lucian2 left #parrot
11:35 dalek parrot/nwellnhof/compiler_flags: b6eca53 | fperrad++ | config/auto/gcc.pm:
11:35 dalek parrot/nwellnhof/compiler_flags: [mingw] no -fPIC on Windows
11:35 dalek parrot/nwellnhof/compiler_flags:
11:35 dalek parrot/nwellnhof/compiler_flags: warning: -fPIC ignored for target (all code is position independent)
11:35 dalek parrot/nwellnhof/compiler_flags: review: https://github.com/parrot/parrot/commit/b6eca533a4
11:45 jan joined #parrot
13:11 bluescreen joined #parrot
13:19 dalek parrot/nwellnhof/compiler_flags: 6d5fc62 | fperrad++ | config/init/hints/mswin32.pm:
13:19 dalek parrot/nwellnhof/compiler_flags: [mingw] lib msvcrt not needed
13:19 dalek parrot/nwellnhof/compiler_flags: review: https://github.com/parrot/parrot/commit/6d5fc6268b
13:29 slavorgn left #parrot
13:35 smash joined #parrot
13:38 smash hello everyone
13:42 whiteknight joined #parrot
13:43 Patterner left #parrot
13:44 whiteknight good morning, #parrot
13:44 smash seen chromatic
13:44 aloha chromatic was last seen in #parrot 1 days 5 hours ago saying "Me too, such as it's midnight.".
13:45 bacek left #parrot
13:46 smash chromatic ?
13:50 Kulag left #parrot
13:50 whiteknight good morning, smash
13:50 whiteknight chromatic is probably still asleep
13:50 whiteknight or, very recently awake
13:50 * smash nods
13:51 smash i'll see if he pops in the next hours
13:52 Kulag joined #parrot
13:53 Psyche^ joined #parrot
13:53 Psyche^ is now known as Patterner
13:58 Kulag left #parrot
13:58 Kulag joined #parrot
14:12 ligne joined #parrot
14:24 Kulag left #parrot
14:24 Kulag joined #parrot
14:27 Coke I'm not sure where he'll respawn.
14:56 whiteknight I think we're going to be able to put together a decent JavaScript on Parrot compiler, and I think we will be able to do it pretty quickly
14:56 atrodo Exciting
14:57 dukeleto whiteknight: that sounds exciting
15:00 whiteknight I've been reading over zaach/cafe source all morning, and it looks like it should be pretty easy to add in a Parrot PIR backend
15:00 whiteknight that gives us a stage 0 pretty quickly
15:01 whiteknight Once we can get the generated compiler to start building itself, we can remove the non-Parrot stuff, or make the Parrot stuff the default and keep everything else
15:02 whiteknight it looks like he also has an Objective-J frontend, and a Harmony front-end, so we get those for cheap too, if we want
15:03 whiteknight er, I guess Harmony is just a newer version of JavaScript
15:05 bluescreen left #parrot
15:05 whiteknight the hardest part of it is, I think, setting up a good prototype-based object model for the generated code to use so we can approximate JS semantics
15:06 whiteknight at the very least we will need a temp implementation until Parrot's new MOP_ is in
15:06 atrodo It's sad that's the hardest part
15:07 whiteknight atrodo: for a basic implementation I don't think it should be too hard. JavaScript objects are very Hash-like. We would need some kind of a ProtoFactory  that we can put in a prototype and get out a new clone
15:07 whiteknight and then we need to create a bunch of Prototype objects for built-in types, and make sure they all have a .prototype field
15:08 atrodo whiteknight> Aye.  But I would have hoped that the problem would have already been solved in some regard for another language
15:08 whiteknight atrodo: yes, there just hasn't been much motivation yet. The older ecmascript compiler used the normal Parrot MOP and hacked together a working implementation
15:11 * atrodo goes to read the cotto and whiteknight blogs
15:17 dmalcolm joined #parrot
15:17 NotFound whiteknight: for some value of working, las time I worked on it was only able to run very simple programs.
15:20 bluescreen joined #parrot
15:21 bluescreen whiteknight, make sure you blog in a tutorial way about it... that will make it easier for others who want to do a similar task with ruby, python or any other HLL
15:23 NotFound bluescreen: anyone wanting to write a compiler targeting pir have already a good example to borrow: the two stages of winxed.
15:24 bluescreen NotFound, is there any tutorial in how to do it...? or just reading source code?
15:25 NotFound bluescreen: reading source, asking, working and thinking.
15:26 NotFound I expect people wantning to write compilers to be able to do that.
15:26 atrodo NotFound> When I'm working, last thing i want to do is think
15:26 bluescreen but they have to learn winxed and pir
15:27 NotFound bluescreen: poor guys.
15:27 bluescreen and know that winxed already does have a compiler written in winxed
15:27 NotFound bluescreen: stage 0 is writen in C++, you don't need to learn winxed.
15:28 plobsing left #parrot
15:29 NotFound Anyway, if I should write a tutorial about writing a javascript compiler in order for someone to write it, I prefer to write the compiler.
15:29 bluescreen lol
15:30 NotFound And about python and ruby, I think there are people in its comunitys able to write compilers.
15:30 bluescreen yeah but we have to give them a few pointers in how to build the gap between the AST and PIR
15:31 * NotFound trying hard to not make the usual jokes about 'pointers'...
15:31 atrodo NotFound> Actually, how easy/good is winxed at generating bytecode?
15:33 NotFound atrodo: any comment about that from me will be highly subjective,
15:33 atrodo NotFound> I can appreciate that, but the question is also highly subjective as well
15:35 NotFound About the "easy" part, I really don't know what to say. For me is good.
15:35 atrodo NotFound> When I was trying to write a bytecode generator I tried nqp, not sure if I liked it.  But the more I hear about winxed, the more interested I am in it
15:36 NotFound atrodo: the bytecode generator is not bad, the bad part is that is has a lot of special cases.
15:36 atrodo NotFound> What kind of special cases?
15:36 Patterner left #parrot
15:37 NotFound atrodo: maybe is easier to ask what cases are not special X-)
15:37 atrodo NotFound> hehe
15:38 NotFound atrodo: a few examples: selecting what king of get/set_...._keyed_... should be intended depending on arguments and return or assign-to types.
15:38 NotFound kind
15:39 NotFound That may be less problem with languages that doesn't use parrot native types.
15:42 mtk joined #parrot
15:42 atrodo NotFound> Good to know.  When I get back around to that project, I'll probably check winxed out more
15:42 NotFound atrodo: feel free to ask, comment, and criticise.
15:43 atrodo NotFound> I will remember that ;)
15:46 mtk left #parrot
15:48 NotFound Now that I think about it, there is a sort of step-by-step tutorial: the stage 1 history in the winxed repository.
15:50 NotFound I mean, the history of the changes of the winxedst1.winxed file.
15:50 whiteknight creating a bootstrapped compiler is not too hard: Create a stage 0 compiler, in your language, and run it on an existing compiler
15:50 whiteknight then, use the output result to compile itself
15:50 whiteknight when you're doing development, always use the previous version to compile the new version
15:51 mtk joined #parrot
15:51 NotFound I wrote this post some months ago: http://notfound.posterous.com/​self-hosted-winxed-why-and-how
15:52 * bluescreen is reading winxedst1.winxed
15:53 mtk left #parrot
15:53 mtk joined #parrot
15:54 whiteknight the key is, write the compiler in language X as if you have a compiler for language X around already
15:55 whiteknight use an existing solution until yours is mature enough to host itself
15:55 whiteknight no magic. C compilers have been doing it for decades
15:55 NotFound And Pascal before it.
15:56 bluescreen what should be the minimal features a compiler has to have to bootstrap itself ? string manipulation and io subsystem?
15:57 moritz "io subsystem" is a bit of a stretch :-)
15:57 moritz print() is usually enough
15:57 NotFound Yeah
15:58 moritz (you can print to STDOUT, and your build system redirects to a file)
15:58 bluescreen but you need at least read stdin
15:58 mtk left #parrot
15:58 moritz yeah, right
15:58 moritz ok, readline() and print()
15:59 mtk joined #parrot
15:59 bluescreen and some variables... :)
15:59 atrodo And sanitation!
16:00 atrodo (Now regrets attempting an obscure Life of Brian reference)
16:00 NotFound If you use an existing language, you can do it step by step. Start with a compiler able to compile a helloworld program.
16:01 NotFound Then, improve it until is able to compile itself. Easy ;)
16:02 bluescreen yeah... piece of cake! :D
16:04 moritz what people don't realize is that compilers are of the simplest kind of programs really
16:04 moritz they read a file as input, and write a file as output
16:04 moritz no concurrency or IPC needed
16:05 moritz no interaction with stupid users
16:05 moritz no passwords to be stored
16:06 NotFound No databases
16:06 bluescreen mortiz, you have to interact with the user and give them some feedback
16:07 moritz bluescreen: you have to give error messages, or say that it compiled OK
16:07 moritz bluescreen: but that's not the same as asking the user "do you want to continue (y/n)?"
16:08 bluescreen not at all... but still have to make user's life easier trying to understand what they are trying to do and help them finding the errors
16:08 NotFound bluescreen: people used to write compiler in a few KB in the heroic times of personal computers, with diagnoses like "error x at line y", and they survived.
16:09 bluescreen or bare "Syntax error"
16:09 moritz most early bootstrapping stage compilers just have the "syntax error" error :-)
16:09 NotFound Having nice messages is nice, of course, but you can live without it.
16:10 moritz especially if you wrote the compiler yourself, and know it by heart
16:10 NotFound In fact, winxed stage 0 still sucks at some points... but you can try the chenges with stage 1 first.
16:11 bluescreen it doesn't make much sense to give nice error messages in stage 0
16:11 plobsing joined #parrot
16:11 bluescreen its a throw away
16:12 NotFound bluescreen: it makes sense if it helps diagnosing.
16:12 bluescreen yourself..?
16:12 NotFound Yeah
16:13 bluescreen how about: "Something wrong... please check"?
16:13 atrodo Add the word "doofus" and you've got a winner
16:13 NotFound bluescreen: sometimes is enough, sometimes is time wasting.
16:14 bluescreen NotFound: how long did it take to you to cook stage 0?
16:14 NotFound In the current winxed way, I improve the stage 0 compiler in order to be able to use a better language in stage 1, so having better diagnoses in stage 0 is helpful.
16:15 NotFound Another way can be writing a stage 2 with the more complete language.
16:15 NotFound bluescreen: about two months
16:15 NotFound bluescreen: a primitive version, of course, not its actual state.
16:17 bluescreen it's a shame you don't have the whole process blogged
16:19 NotFound bluescreen: the svn repo has almost the full process.
16:26 fbrito joined #parrot
16:32 lucian NotFound: while I think winxed is awesome and you did a great job on it, i think you're underestimating the effort needed to map an existing language to parrot
16:32 NotFound lucian: I just try to avoid overestimating it.
16:34 lucian NotFound: sure, it just takes a significant amount of work
16:34 lucian there are a lot of corner cases. I still have no idea how python's sys._getframe() would ever work on parrot
16:35 NotFound Of course, writing a implementation compatible with existing ones and passing its test is harder than designing the language as you go.
16:36 NotFound But you don't need to start with the full spec.
16:36 lucian yeah
16:37 lucian i do think however that parrot suggests new languages to use parrot's compiler tools, and it shouldn't
16:37 NotFound As I said, you can start with something able to compile helloworlds and the like.
16:37 lucian they can only be useful for new languages
16:37 Kulag left #parrot
16:37 lucian NotFound: if you have a new language. but existing languages have existing implementations
16:38 lucian pynie should be written in python, cardinal should be written in ruby, etc
16:38 Kulag joined #parrot
16:38 NotFound lucian: if you use an existing implementation to write the compiler, you can *use* the full language, but support only a minimal subset.
16:38 Patterner joined #parrot
16:38 lucian NotFound: yes, initially
16:39 lucian i don't think it's important to bootstrap using parrot only
16:39 NotFound For me, the important part is having something that works, and that people like to work with.
16:40 NotFound Even if 'people' is one person.
16:41 lucian NotFound: for pynie, that would mean passing the Python test suite
16:41 lucian as I said, i think development of new languages is fundamentally different to existing languages
16:45 NotFound I'll be hapy if proven wrong by having a working compiler developed by any other process.
16:46 lucian NotFound: :)
16:47 lucian i think i mentioned this before, i'd like to see pynie implemented in pure python, perhaps from PyPy's compiler
16:47 lucian and stay that way, always require a full python implementation for building
16:47 whiteknight bootstrapped compilers is probably an area where Parrot is going to shine
16:48 whiteknight PCT/NQP-RX are awesome tools, but there are plenty of people who have a simple aversion to Perl
16:48 whiteknight being able to write your compiler in your language is a big deal
16:48 lucian whiteknight: not only that, but i don't see why you wouldn't self host
16:48 NotFound lucian: yeah, but if you use a preexisting self compiler the process is completely different.
16:48 lucian if you write a compiler for a language, you most likely like it enough to use it for the actual compiler
16:49 lucian whiteknight: and there's the aversion to perl's syntax too, yes
16:50 NotFound Or just lack of confidence and familiarity with that kind of syntax.
16:50 lucian NotFound: no, there's aversion too
16:51 NotFound lucian: there is, but is not always such a strong position.
16:51 lucian NotFound: to just the syntax, there's not quite that much (but still significant)
16:51 lucian but people hate perl5 and php so much, they associate their failings with the syntax, as well
16:51 atrodo The problem with self hosting is you're not necessarily using high quality compiler tools
16:52 lucian atrodo: depends on your language, of course
16:52 PerlJam Making Perl 6 regex/grammars available to other languages would help too.  Even if people dislike Perl, they tend to see the power behind regex.
16:53 lucian atrodo: pretty much all popular languages have good compiler tools
16:53 lucian PerlJam: again, you'll see people disagreeing there
16:53 NotFound That depends... there is also people that hate regexes, or using them too much.
16:53 PerlJam anyone writing a compiler is going to use regex (or something similiar) if they are sane
16:53 lucian PerlJam: and i think regexes are misleading. they imply finite state machines, which suck at parsing
16:54 lucian PerlJam: again, MANY people will disagree :)
16:54 contingencyplan joined #parrot
16:54 NotFound PerlJam: you can look at winxed sources for an exception ;)
16:55 NotFound regexes are used only for including pasm constants, if I remember well.
16:55 * moritz wants to point out that a typical p6 grammar for a programming language doesn't have much in common with regexes
16:55 NotFound (maybe the "if they are sane" excludes me)
16:56 PerlJam moritz: with traditional regex you mean?
16:56 moritz PerlJam: both with traditional regex, and with regex you'd write for an ad-hoc parsing problem in Perl 6
16:58 PerlJam Perhaps I'm just too steeped in my own history with using lex/yacc and their progeny so that that's mostly what I see
16:59 NotFound Remember, TIMTOWTDI
16:59 theory left #parrot
17:00 PerlJam sure, but using grammars is funnest!  :)
17:01 NotFound Fun is in the smile of the beholder
17:04 fbrito whiteknight: ping
17:05 whiteknight fbrito: pong
17:05 cotto_work ~~
17:07 whiteknight hello cotto_work
17:07 fbrito whiteknight: about my tests (https://github.com/fernandobrito/p​arrot-linear-algebra/commit/1f1e)... should I add/remove something? change their names? where should they be placed? in testlib/matrixtest.nqp or should I copy and paste in pmc/*matrix2d.t?
17:08 whiteknight fbrito: let me look
17:09 whiteknight fbrito: t/testlib/matrixtest.nqp is probably right. The tests will get inherited for all types
17:09 whiteknight and saves you from having to copy+paste :)
17:11 dukeleto cotto_work: mornin'
17:12 fbrito whiteknight: and what about their names? I saw that there are some conventions, like test_MISC or test_VTABLE... but I can't figure out how should I name my tests
17:13 whiteknight fbrito: Those names all use stupid old conventions. Don't worry about them. Your names are good
17:13 whiteknight I think they need to start with "test_"
17:13 whiteknight otherwise the harness can't find them, but I might be wrong
17:13 whiteknight brb, lunch. back in a few minutes
17:13 cotto_work seen chromatic
17:13 aloha chromatic was last seen in #parrot 1 days 9 hours ago saying "Me too, such as it's midnight.".
17:14 fbrito whiteknight: ok :D
17:27 NotFound whiteknight: what's the nick of the guy with the YCombinator task?
17:30 NotFound Don't worry, a search in the irclog told me.
17:32 whiteknight fbrito: I think the code all looks good. When you're ready submit it
17:36 dalek winxed: r701 | NotFound++ | trunk/winxedst1.winxed:
17:36 dalek winxed: generate internal names for arguments that are unique within the outermost
17:36 dalek winxed: scope, issue #4, rfw++ whiteknigh++ plobsing++
17:36 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=701
17:37 whiteknight NotFound++
17:41 Coke NotFound: would you could original partcl as "working" ?
17:41 Coke (going back to your send earlier about a working implementation of an existing language)
17:42 NotFound Coke: I don't know enough tcl to judge that,
17:43 fbrito whiteknight: have you seen those 2 tests that are failing in the "master" branch? inside methods/complexmatrix2d/ (conjugate and row_combine)
17:43 whiteknight fbrito: yes, those tests are marked TODO, but my test harness is not smart enough to ignore them
17:43 whiteknight annoying, but OK
17:44 Coke NotFound: we passed a substantial fraction of the official tcl test suite.
17:44 NotFound Coke: then yes
17:44 theory joined #parrot
17:45 Coke ok. that was written in PIR&PMCs.
17:45 NotFound Ah, you mean I'm already proven wrong.
17:45 Coke I think so. I was scrolling pretty fast. ;)
17:46 NotFound That's not fair. I mean doing it now. And fast! ;)
17:46 Coke I would never reimplement partcl using that method, agreed. ;)
17:46 whiteknight what method?
17:47 Coke "ok. that was written in PIR&PMCs."
17:47 whiteknight ok
17:48 NotFound Any method that differs substantially from the things I talked about.
17:50 Coke that said, I'm not sure partcl would be a good candidate for bootstrapping.
17:51 whiteknight The reason I like bootstrapping is because it lets compiler devs write the compiler in whatever language they are most comfortable in
17:51 whiteknight if TCL doesn't lend itself to that, you pick a different implementation language that you like
17:52 Coke like PERL?
17:52 whiteknight if that's what you're comfortable with, yes. We've got a great toolset available if you like Perl
17:53 Coke ... I was snarkily pointing out that it's Tcl.
17:53 NotFound You, and preferably the people you like to join the project.
17:53 Coke and I'm already using NQP. And I wouldn't call it a great toolset.
17:53 whiteknight Coke: well, that's an issue outside of our control. I'm sure pmichaud and co would like any feedback you have
17:54 Coke it is easier to develop in than PIR/TGE/PGE/PMCs, I'll grant you that.
17:56 Coke whiteknight: it's too slow and needs better docs.
17:56 Coke (most of which is a parrot issue, as you're dealing with parrot objects most of the time, nqp is just syntax to get at them.)
18:00 whiteknight fbrito: I need a few minutes. I have to reinstall Parrot for testing
18:00 dukeleto Coke: i agree with you. nqp-rx is more featureful than everything else, but you pay the price in lack of docs and speed
18:00 fbrito whiteknight: ok, no problem
18:01 NotFound whiteknight: Are you sure the man-boy program is correct? According to wikipedia: "value k; integer k;", wich I suppose mean k is passed by value.
18:02 whiteknight Notfound: I tried converting it to an int, and I tried making a copy. Maybe you can find a solution
18:02 * NotFound doesn't know ALGOL 60
18:03 whiteknight From what I gather, k should be pass-by-value, not reference
18:04 whiteknight so if you know how to change that
18:04 NotFound Problem is, int can't be lexical in winxed.
18:05 NotFound I'll try some workaround.
18:07 whiteknight could make a copy
18:12 NotFound A workaround seems to work, but runs out of stack at 10
18:13 whiteknight yeah, that's expected
18:13 whiteknight that thing eats stack space
18:13 NotFound Good, I'll elaborate a bit more and post in the issue.
18:14 whiteknight Awesome! NotFound++
18:16 NotFound So winxed is a man now? I tend to antropormorph it as a woman.
18:17 whiteknight a man?
18:17 NotFound man-boy test?
18:17 whiteknight ha, okay
18:17 whiteknight woman-girl test
18:20 fbrito Woman-girl test? Ahahaha! We just have to test if it throws the BloodException every month. If it does, it is a woman!
18:21 Coke I suspect that send is not cool.
18:21 cotto_work +1
18:23 NotFound Fairy-pixie test if you prefer.
18:23 atrodo Perl-php?
18:24 whiteknight fbrito: submission pushed. Accepted. Thanks.
18:25 dalek parrot-linear-algebra: 25966ce | fernandobrito++ | src/ (3 files):
18:25 dalek parrot-linear-algebra: Update GET_KEY_INDICES_* macros to use new pmckey_to_coords()
18:25 dalek parrot-linear-algebra: review: https://github.com/Whiteknight/parr​ot-linear-algebra/commit/25966ceadc
18:25 dalek parrot-linear-algebra: 1f1e5c9 | fernandobrito++ | t/pmc/pmcmatrix2d.t:
18:25 dalek parrot-linear-algebra: Add tests to new pmckey_to_coords() function
18:25 dalek parrot-linear-algebra: review: https://github.com/Whiteknight/parr​ot-linear-algebra/commit/1f1e5c93a9
18:25 dalek parrot-linear-algebra: 25d9334 | fernandobrito++ | src/ (2 files):
18:25 dalek parrot-linear-algebra: Update pmckey_to_coords() quantity of parameters
18:25 dalek parrot-linear-algebra: review: https://github.com/Whiteknight/parr​ot-linear-algebra/commit/25d9334a90
18:25 dalek parrot-linear-algebra: bd5a52c | fernandobrito++ | src/ (5 files):
18:25 dalek parrot-linear-algebra: Update GET_KEY_INDICES_ROWMAJOR quantity of parameters
18:25 dalek parrot-linear-algebra: review: https://github.com/Whiteknight/parr​ot-linear-algebra/commit/bd5a52cdda
18:25 dalek parrot-linear-algebra: 66943d5 | fernandobrito++ | t/pmc/pmcmatrix2d.t:
18:25 dalek parrot-linear-algebra: Add more tests to new pmckey_to_coords() function
18:25 dalek parrot-linear-algebra: review: https://github.com/Whiteknight/parr​ot-linear-algebra/commit/66943d5fdd
18:25 dalek parrot-linear-algebra: 9a899cd | fernandobrito++ | t/ (2 files):
18:26 dalek parrot-linear-algebra: Move new tests to a place where it will get inherited
18:26 dalek parrot-linear-algebra: review: https://github.com/Whiteknight/parr​ot-linear-algebra/commit/9a899cd345
18:29 fbrito whiteknight: yay! thank you
18:29 * tadzik wishes he was younger so he could get involved in funny stuff too :)
18:31 fbrito tadzik: are you in university? there is always the Google Summer of Code :)
18:32 tadzik fbrito: yeah, I'm planning that :)
18:32 tadzik (actually, it's today I become 2 years too old for GCI :))
18:33 bacek joined #parrot
18:34 fbrito tadzik: today, like... really today? is today your b-day? :o
18:34 fperrad left #parrot
18:36 tadzik fbrito: yep :)
18:36 NotFound No one picks the chunked encoding task? Sigh.
18:37 fbrito tadzik: oh!... happy birthday! :)
18:37 tadzik (I even changed my gravatar from a dog to a pic, as if I were mature or something)
18:37 tadzik fbrito: thank you :)
18:38 smash tadzik: happy birthday!
18:38 tadzik thanks smash :)
18:39 * NotFound light some candles
18:41 * tadzik pffffffffffffffffff!
18:41 fbrito NotFound: the chunked encoding task seems really scary to me :(
18:42 NotFound fbrito: for me too. That's what I want to pass it to other people ;)
18:44 jhelwig joined #parrot
18:45 whiteknight left #parrot
18:45 ligne left #parrot
18:46 ligne joined #parrot
18:46 fbrito NotFound: Ahahha, ok. I am going to try a task for another project and then, if no one have claimed the chunked task, I will do it :)
18:47 NotFound fbrito: thanks!
18:50 whiteknight joined #parrot
18:52 ligne left #parrot
18:54 wesjdj joined #parrot
19:09 theory left #parrot
19:13 wesjdj left #parrot
19:42 tcurtis joined #parrot
19:43 rfw joined #parrot
19:45 plobsing left #parrot
20:23 allison left #parrot
20:23 allison joined #parrot
20:26 kid51 joined #parrot
20:31 allison parrotsketch meeting now?
20:31 kid51 Yes
20:38 kid51 aloha, seen NotFound?
20:38 aloha kid51: NotFound was last seen in #parrot 1 hours 51 mins ago saying "fbrito: thanks!".
20:39 kid51 NotFound: available for parrotsketch?
20:39 NotFound Ups, got distracted, sorry.
21:04 PerlJam whiteknight++ just read yesterday's blog entry
21:08 theory joined #parrot
21:12 bacek_at_work ~~
21:19 chromatic joined #parrot
21:20 chromatic Oh, 20:30 UTC not 21:30 UTC.
21:56 mtk left #parrot
21:57 whiteknight left #parrot
22:10 cotto_work Interesting.  Google's new V8 thingy uses a linear-scan register allocator: http://blog.chromium.org/2010/​12/new-crankshaft-for-v8.html
22:11 Matt221 joined #parrot
22:19 * dukeleto just got off the PaFo conf call and things look like they are changing for the better
22:20 cotto_work dukeleto: good to hear.  What's the upshot?
22:20 bluescreen left #parrot
22:21 atrodo dukeleto> that was a long phone call
22:21 dukeleto Parrot Foundation is getting back on track and the Software Freedom Law Center is helping us get there
22:22 * dukeleto learned a lot about how open source projects + nonprofits/taxes work
22:24 plobsing joined #parrot
22:28 nopaste "chromatic" at 192.168.1.3 pasted "Draft of Branch Merge Review Policy" (162 lines) at http://nopaste.snit.ch/26794
22:31 * dukeleto gets popcorn
22:33 cotto_work I like where this is going.
22:35 chromatic It gets speculative later.
22:35 kid51 What is a "shim"?
22:36 chromatic Ever had a heavy piece of furniture which wobbled, so you took a small piece of wood or cardboard to make it fit better?
22:36 chromatic This is the code version.
22:36 dalek left #parrot
22:37 kid51 A kludge?
22:38 cotto_work That's way easier to read as pod.
22:39 p6eval left #parrot
22:41 dalek joined #parrot
22:42 dukeleto chromatic: If you've need any exclusions to the deprecation policy, have you asked for and
22:42 dukeleto chromatic: some wording need fixin' there
22:42 chromatic Will do.
22:44 dukeleto chromatic: you may want to mention that coding standard tests are run with "make codingstd" or whatever it is
22:44 dukeleto chromatic: or just say that all branches should pass "make fulltest"
22:45 chromatic Done.
22:46 cotto_work chromatic: is this intended to be a more complete version of docs/project/core_inclusion.pod?
22:46 dukeleto chromatic: i really like what you wrote. a big +1 from me to put that in docs/project as a stand-alone doc
22:46 p6eval joined #parrot
22:46 cotto_work or a complement?
22:46 dukeleto chromatic: i think it is important enough to have it's own file
22:46 kid51 dukeleto: Yes I like the idea of running 'make fulltest' at least once on each branch
22:47 dukeleto chromatic: but if you feel it fits better into another already existing file, go for it. But please commit that sooner rather than later
22:47 cotto_work kid51: I think it's silly we're not doing that already.
22:47 dukeleto cotto_work: it is, except that "make fulltest" takes an extraordinary amount of time for many people
22:47 dukeleto cotto_work: not everyone has multiple cores and SSDs
22:47 chromatic I have no preference for where this document goes.
22:48 dukeleto cotto_work: "make fulltest" could take 30 minutes or hours depending on how old the machine is
22:48 cotto_work dukeleto: true.  People on slow machines can ask for volunteers to run fulltest though.
22:48 dukeleto cotto_work: of course
22:48 dukeleto cotto_work: i wasn't defending not running it, but just documenting *why* people don't run it
22:48 kid51 Note that I said: at least once per branch.  i.e., I'm not expecting them to do more than once.
22:49 kid51 In point of fact, t/codingstd/perlcritic.t is the biggest time-sink there.
22:50 kid51 I used to dread 'make fulltest', but since we eliminated one core its something I just chuck into a screen session (on Linux -- it's still a multi-hour thing on my iBook)
22:50 cotto_work I <3 screen.
22:52 atrodo screen++
22:53 dukeleto fulltest got a lot faster when me moved to Git, since I got to delete a lot of annoying svnprop tests
22:53 cotto_work Did those take long?
22:53 chromatic Longer than you might think.
22:56 chromatic IO is a bottleneck there.
22:58 dukeleto they took a really long time on non-SSD drives
22:58 rfw left #parrot
22:59 dukeleto every file in the repo had to have it's svnprops read, which is time-consuming
22:59 rfw joined #parrot
23:20 kid51 What's an SSD drive?
23:21 cotto_work solid state drive drive
23:22 cotto_work no moving parts, *really* good seek time, quite expensive atm
23:22 dukeleto kid51: it makes git repos insanely faster
23:23 * dukeleto used to wait 60seconds for a catalyst app to start, now it does it in 3s
23:23 dukeleto the seek time of SSDs is way less than drives with moving parts
23:24 dukeleto so if you are touching lots of files on the filesystem, they scream.
23:24 Matt221 left #parrot
23:24 dukeleto we could also setup a service for "fulltest" to be run on the GCC Compile Farm
23:25 dukeleto we haven't used the farm at all, mostly because I am the only one that can do stuff on it, and I have been busy with git migration and lots of other stuff
23:25 dukeleto but we need to use it
23:25 dukeleto also, we don't have coverage reports anymore
23:25 dukeleto aloha, coverage?
23:25 aloha dukeleto: coverage is http://cv.perl6.cz or http://tapir2.ro.vutbr.cz/cover/cover-results/
23:25 dukeleto wait, we do!
23:25 dukeleto looks like the coverage reports are talking to git
23:26 dukeleto http://tapir2.ro.vutbr.cz/cover/cover-res​ults/2010-12/2010-12-07-7717682/c_cover/
23:26 dukeleto that is good to know
23:26 dukeleto getting coverage reports for certain branches would be pretty killer as well
23:27 dukeleto the String PMC has 83% coverage. That seems a bit too low for such an important PMC
23:28 dukeleto that would make a good GCI task, to increase the coverage by 5% or so
23:28 NotFound Oh, is alive again? Hurrah!
23:28 dukeleto String PMC doesn't have any coverage for "set_bool"
23:29 dukeleto and a bunch of others
23:29 dukeleto I am going to add that as a GCI task, no one fix it yet!
23:29 NotFound dukeleto: set_bool is hard to cover, can't be done from pir
23:29 dukeleto NotFound: o rly?
23:29 dukeleto NotFound: we can add a test from the embed interface
23:29 dukeleto NotFound: correct?
23:30 dukeleto String.substr has no coverage either
23:30 dukeleto and cmp_num. These seem important.
23:31 NotFound dukeleto: there is a ticket about the substr vtable
23:32 NotFound Surely we can find a way to add a test for set_bool, but I wonder if we should just delete it instead.
23:33 dukeleto NotFound: do you think anybody outside of parrot uses it somehow?
23:33 dukeleto NotFound: the only way to use it is from embedding, no?
23:33 dukeleto NotFound: i doubt if PL/Parrot uses it. If it does it is on accident.
23:34 NotFound dukeleto: I fail to imagine why someone may be using it, but one never knows...
23:34 dukeleto NotFound: indeed. But now we can at least ack through github repos
23:35 dukeleto NotFound: it would be nice to have a script that ack's through the repos of all known parrot projects and says "hey project X is using this thing that is on the chopping block"
23:35 dukeleto that would be amazingly useful
23:35 NotFound dukeleto: aye
23:35 dukeleto perhaps that could live on the gcc compile farm. It wouldn't be very hard to do.
23:37 NotFound This is the ticket for substr: http://trac.parrot.org/parrot/ticket/1682
23:39 * dukeleto just approved 5 parrot gci tasks and kicked off 1 more task claim request
23:39 dukeleto someone finally took the "compare Neko VM to Parrot VM" task. I am interested to see what they come up with.
23:41 NotFound GCI is being very helpful, much more than I expected.
23:42 cotto_work dukeleto: that'd be amazingly useful.
23:42 cotto_work It's a bandaid until we finally get deprecations right, but it's a really nice bandaid.
23:42 bacek_at_work dukeleto, Neko is stack based. Parrot is register.
23:42 bacek_at_work One of Neko dev sitting just next to me ):)
23:42 cotto_work That's a difference.
23:43 cotto_work bacek_at_work: steal his brane
23:43 NotFound bacek_at_work: you've failed the task, your report is too short ;)
23:43 bacek_at_work cotto_work, he refuses to join parrot. And continue LLVM based backend for Neko...
23:43 bluescreen joined #parrot
23:43 cotto_work Neko isn't entirely unlike what we want from lorito.
23:43 cotto_work bacek_at_work: his loss ;]
23:44 bacek_at_work I think Lorito should be stripped down of current parrot. Register based, CPS.
23:44 bacek_at_work May be without multi-dispatch.
23:44 lucian bacek_at_work: noooooooo :)
23:44 bacek_at_work Rakudo build own anyway.
23:44 * lucian thinks single dispatch is a subset of multi dispatch, but not the other way around
23:45 cotto_work bacek_at_work: the current plan is for CPS and MMD to live on top of lorito.  Are you thinking of something else?
23:46 bacek_at_work cotto_work, why?
23:46 bacek_at_work I think CPS is core of VM.
23:46 bacek_at_work MMD is not.
23:47 cotto_work Well, anything that's not directly in Lorito will have to be on top of it.
23:47 cotto_work not necessarily at the same level
23:48 dukeleto bacek_at_work: yes, but we are going to get a GCI student to write about it :)
23:48 bacek_at_work I thinks CPS is in. It's just our way of invoking subs.
23:49 * dukeleto just added a parrot gci task for increasing String PMC code coverage
23:50 fbrito wow, lots of new tasks :)
23:50 Matt221 joined #parrot
23:51 dukeleto fbrito: indeed. To keep you busy!
23:51 dukeleto fbrito: just ping me if you are waiting on a claim request
23:52 dukeleto fbrito: twitter is probably the fastest
23:52 dalek parrot: 8c3a723 | NotFound++ | t/pmc/mappedbytearray.t:
23:52 dalek parrot: a bit more initial tests for MappedByteArray
23:52 dalek parrot: review: https://github.com/parrot/parrot/commit/8c3a723c13
23:52 dukeleto new string task: http://socghop.appspot.com/gci/task/show/google​/gci2010/parrot_perl_foundations/t129176557195
23:52 chromatic multidispatch at the core makes vtables much nicer
23:55 fbrito dukeleto: ok, but right now I am working on a task for Sahana Foundation :o
23:56 dukeleto fbrito: sounds good. I am going to create a huge backlog of tickets before I go on vacation :)
23:57 fbrito dukeleto: when are you going to vacations? if you are coming to Brazil, please let me know :P
23:58 dukeleto fbrito: i will definitely let you know if I am passing by :)
23:59 dukeleto fbrito: visiting family in the US, this time. But I am sure I will visit Brazil someday.
23:59 bluescreen where are you fbrito? Buzios?

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

Parrot | source cross referenced