Camelia, the Perl 6 bug

IRC log for #parrot, 2010-12-08

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 fbrito bluescreen: not really :P. my city is like 2,500km away from Buzios
00:01 bluescreen which one is it? I'm from Buenos Aires
00:01 fbrito bluescreen: I live in http://en.wikipedia.org/wiki/Jo%C3%A3o_Pessoa, the easternmost city in the Americas :)
00:02 bluescreen even better
00:03 bluescreen it must be hell right now
00:04 fbrito it is always like hell :(
00:04 fbrito average of 28~30C
00:04 bluescreen well same here but i don't have the nice beaches
00:05 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#1549) fulltest) at 7717682 - Ubuntu 10.10 i386 (g++-4.5)
00:05 mikehh sorry I missed #ps but got tied up
00:08 fbrito bluescreen: have you ever been in Brazil? The only time I left it was in my exchange student program (to Europe)
00:09 bluescreen many times... i love brazil
00:14 fbrito wow, very interesting :)
00:14 dukeleto fbrito: looks like an awesome city. I will have to come visit :)
00:16 bluescreen dukeleto: you can call it a biz trip
00:17 fbrito ahahha, good idea
00:23 lucian fbrito: i'm coming to brazil for christmas :)
00:23 fbrito lucian: oh! where are you from and to which city are you coming?
00:24 lucian fbrito: i'm in Newcastle, UK right now, and I'll be going somewhere close to Recife
00:26 fbrito Recife is only 120km away from here!  Do you have family/friends here?
00:27 lucian fbrito: sort of, my i'm staying with my dad. he takes his vacations in brazil
00:33 fbrito lucian: thats awesome! if you ever come to João Pessoa, please, let me know! I host you on my house or show you the city :P
00:33 lucian fbrito: that's very nice of you :)
00:33 fbrito s/I host/I can host/
00:34 lucian i don't know what my dad planned for us, but if we get extra time we might come over :) (me and my gf)
00:35 fbrito as you may already know, we, brazilians (and south americans in general) are really receptive and have no problems with guests on our house :)
00:36 lucian fbrito: i'm european (romanian), that's not terribly surprising to me
00:39 smash left #parrot
00:41 Matt221 left #parrot
00:42 kid51 is now known as kid51_at_dinner
00:55 theory left #parrot
00:56 bluescreen left #parrot
00:57 whiteknight joined #parrot
00:59 bluescreen joined #parrot
01:00 chromatic left #parrot
01:03 whiteknight good evening, #parrot
01:05 bluescreen good evening
01:05 dip left #parrot
01:06 dip joined #parrot
01:13 nwellnhof joined #parrot
01:33 whiteknight blah. My experiments in javascript are not going well.
01:33 whiteknight I can install narwhal, but there's a problem in it's metadata repo so I can't use it to install jison
01:34 whiteknight Ubuntu installs node.js as "nodejs" instead of "node", which is what all the software expects.
01:34 whiteknight so I create a symlink, but then the makefile for npm fails with an unhandled exception
01:47 lucian whiteknight: i built my own node.js on OS X, perhaps ubuntu's node.js or npm package is faulty?
01:47 whiteknight lucian: yeah, I'm building from source now
01:47 dmalcolm left #parrot
01:51 whiteknight ...and finally I am able to build cafe
01:52 cotto ~~
01:52 cotto kid51_at_dinner, pign
01:52 cotto or ping if you prefer
01:55 kid51_at_dinner is now known as kid51
01:55 kid51 pong
01:55 kid51 though in a few minutes it has to be kid51_doing_laundry
01:56 cotto privmsg'd
02:01 kid51 is now known as kid51_doing_laundry
02:04 mikehh left #parrot
02:04 tcurtis left #parrot
02:07 kid51_doing_laundry left #parrot
02:10 lucian whiteknight: i found this interesting http://pycon.blip.tv/file/3263942/
02:10 lucian it's very long, though
02:10 whiteknight no time for that tonight
02:10 whiteknight will watch it tomorrow
02:10 lucian it's VERY long
02:10 lucian 3h+ ...
02:14 cotto 3h+?  Is there a "the important parts" version?
02:16 lucian cotto: not afaict
02:16 lucian it's not a presentation, just a recording from some coding thing
02:17 lucian the important part is "implementing increasingly large subsets of python in assembly is both fun and hard"
02:20 whiteknight left #parrot
02:22 lucian i wonder if his results are fast at all
02:25 * lucian hates java
02:27 Coke use groovy or cold fusion!
02:27 lucian Coke: it's not a choice. and i don't love groovy much either :)
02:28 lucian uni coursework ...
02:30 cotto at least you won't be stuck with it for long
02:31 s1n joined #parrot
02:31 lucian cotto: i'm not very hopeful. a ton of projects still use java
02:33 cotto Sure, but you won't be dealing with any 1.5 mloc code bases with factory factory builders.
02:35 cotto It's not a bad learning language.  Its excessive verbosity is annoying though.
02:36 cotto Do you have the option of taking a principles of programming languages class?  Those are great.
02:36 s1n left #parrot
02:37 lucian cotto: for some reason there's not one in my uni right now
02:38 lucian i do however think java is quite a bad learning language
02:38 lucian there are too many arbitrary restrictions
02:38 * lucian is thankful he didn't learn to program in java
02:38 cotto It doesn't have the sharp edges of C++ or the bookkeeping of C.
02:39 lucian but why not use an even higher level language?
02:39 cotto Something like Python, Ruby or Perl (of the modern variety) might be better suited.
02:39 lucian i'm implementing A* in java and it's truly horrible
02:40 cotto A*?
02:40 lucian there are so many useless contortions, half of which because the basic types and literals suck
02:40 lucian cotto: A* search in a grid
02:50 * lucian is off to sleep. good night!
02:50 cotto 'night
02:50 lucian left #parrot
02:54 nwellnhof left #parrot
03:09 ingy left #parrot
03:15 theory joined #parrot
03:22 fbrito There is a comment on this task http://www.google-melange.com/gci/task/show/goog​le/gci2010/parrot_perl_foundations/t129148666886 saying that this task is invalid. It that true?
03:24 cotto looking
03:25 cotto not sure what he's talking about
03:25 cotto seen matt-gci
03:25 aloha matt-gci was last seen in #parrot 3 days 7 hours ago joining the channel.
03:27 cotto fbrito, I see you jumped up a bit in the gci rankings
03:28 cotto dukeleto, ping
03:31 kthakore left #parrot
03:36 fbrito cotto: yes... I (me?) and rfw are going pretty well right now :)
03:48 dukeleto cotto: pong
03:49 dukeleto fbrito: one of our developers (plobsing) said that the problems are more complicated than they seem, and that the task is not really doable
03:49 Coke http://blog.chromium.org/2010/​12/new-crankshaft-for-v8.html
03:50 Coke I would love to see how well parrot-js does on those benchmarks when it's running.
03:51 fbrito dukeleto: I see... thank you :)
03:52 cotto dukeleto, is there an easier way to fill in gci tasks than using melange directly?
03:52 rfw did i just get higlighted
03:52 rfw oh, right there
03:56 dukeleto cotto: i commit to a git repo, then use the "It's All Text" FF plugin so I can use vim. Then I read in the file in vim and shove it into melange
03:57 dukeleto cotto: http://github.com/leto/gci
03:57 dukeleto cotto: feel free to fork that repo, it has task templates and examples
03:58 cotto dukeleto, is that easier than filling in the form in melange?
03:59 dukeleto cotto: for me it is
03:59 dukeleto cotto: YMMV
04:00 dukeleto cotto: use the task template in that repo. It has all the links to stuff and gives the steps to fork the parrot github repo and junk
04:00 dukeleto cotto: but you can just copy and paste that if you want
04:00 cotto That add-on looks nice.
04:01 dukeleto cotto: it saves my life every day
04:01 dukeleto cotto: especially with Melange
04:04 dukeleto http://theoatmeal.com/comics/unanswered_email
04:04 dukeleto it is mildly parrot related...
04:06 dalek parrot/tt532_headerizer_refactor: 880b3e2 | jkeenan++ | t/tools/dev/headerizer/02_methods.t:
04:06 dalek parrot/tt532_headerizer_refactor: Test more execution paths in attrs_from_args().
04:06 dalek parrot/tt532_headerizer_refactor: review: https://github.com/parrot/parrot/commit/880b3e23de
04:12 dalek parrot/tt532_headerizer_refactor: b1f035b | jkeenan++ | t/tools/dev/headerizer/02_methods.t:
04:12 dalek parrot/tt532_headerizer_refactor: Return from tempdir gracefully.
04:12 dalek parrot/tt532_headerizer_refactor: review: https://github.com/parrot/parrot/commit/b1f035b3bb
04:49 fbrito I am going to bed. Good night guys :)
04:51 cotto g'night
04:52 fbrito left #parrot
05:13 theory left #parrot
05:30 dalek tracwiki: v22 | cotto++ | LoritoDesignQuestions
05:30 dalek tracwiki: http://trac.parrot.org/parrot/wiki/LoritoD​esignQuestions?version=22&action=diff
05:38 mikehh joined #parrot
05:45 s1n joined #parrot
05:46 s1n left #parrot
05:50 cotto jnthn, ping
06:23 * cotto sleeps
07:21 he_ joined #parrot
07:43 bacek left #parrot
08:31 fperrad joined #parrot
08:51 bacek joined #parrot
09:36 fperrad_ joined #parrot
09:38 rfw left #parrot
09:39 fperrad left #parrot
09:39 fperrad_ is now known as fperrad
09:41 dngor left #parrot
09:47 dngor joined #parrot
09:50 dalek parrot/opmap_aware_pmcs: b62fff4 | bacek++ | examples/pir/make_hello_pbc.pir:
09:50 dalek parrot/opmap_aware_pmcs: Update make_hello_pbc.pir to use new PackfileConstTable.
09:50 dalek parrot/opmap_aware_pmcs: review: https://github.com/parrot/parrot/commit/b62fff4e43
09:50 dalek parrot/opmap_aware_pmcs: 35f43c1 | bacek++ | src/pmc/packfileopmap.pmc:
09:50 dalek parrot/opmap_aware_pmcs: Drop inheritance of PackfileOpMap from PackfileSegment. OpMap isn't segment anyway.
09:50 dalek parrot/opmap_aware_pmcs: review: https://github.com/parrot/parrot/commit/35f43c195c
09:50 dalek parrot/opmap_aware_pmcs: 4645e2e | bacek++ | src/pmc/packfileopmap.pmc:
09:50 dalek parrot/opmap_aware_pmcs: Set custom_mark on PackfileOpMap and drop useless VTABLE_destroy. Our GC is not so bad.
09:50 dalek parrot/opmap_aware_pmcs: review: https://github.com/parrot/parrot/commit/4645e2e9c4
10:36 cognominal left #parrot
10:36 cognominal joined #parrot
10:57 slavorgn joined #parrot
11:03 bacek left #parrot
11:16 bacek joined #parrot
11:39 ligne joined #parrot
11:42 lucian joined #parrot
11:47 muixirt joined #parrot
11:47 muixirt hi
11:54 mikehh muixirt: hi there
11:55 muixirt so all languages targetting parrot are waiting for mop?
11:56 ligne left #parrot
11:57 muixirt all languages with the exception of rakudo seem to be abandoned.
11:57 tadzik lua works
11:57 lucian pynie almost does too
11:58 lucian there's still a bug i have to fix
11:58 lucian muixirt: it's partly because of the MOP, yes
11:58 tadzik and LOLCODE works quite well. Even bf works, I fixed some of this few days ago
11:59 lucian muixirt: i believe it's also because of the advice given for language implementors. existing languages may be better served by themselves for bootstrapping, rathern than PCT/NQP
12:01 muixirt lucian: please explain
12:01 lucian muixirt: the parrot documentation recommends implementing languages using PCT/NQP
12:02 lucian that's very useful for newly created languages
12:02 muixirt where was that advice given?
12:02 lucian but existing, mature languages already have a working runtime (ruby, tcl, python, lua)
12:03 lucian so it would be both easier and more maintainable to use the language itself for the parrot compiler
12:04 jsut joined #parrot
12:09 jsut_ left #parrot
12:09 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#1554) fulltest) at 8c3a723 - Ubuntu 10.10 amd64 (g++-4.5)
12:11 muixirt lucian: so the incentive to target parrot for existing languages diminishes even more because of the demise of pir and the far away paths for mop and lorito?
12:11 lucian muixirt: it diminishes considering that existing parrot compilers are written in pir/PCT/NQP
12:19 muixirt tadzik: is lua expected to work? the tests fail horribly
12:22 mtk joined #parrot
12:25 tadzik muixirt: really? It usually works
12:25 tadzik lemee check
12:26 tadzik ah, I won't check, ETOORESTRICTIVEFIREWALL
12:27 muixirt tadzik: it may fail due to my setup here, didn't read manuals :-)
12:27 muixirt but installable_lua works
12:28 lucian left #parrot
12:29 muixirt but parrot lua is awful slow
12:31 tadzik is it? It's slower than an "official lua", but not awful slow. Rakudo is awful slow :)
12:33 muixirt 23 secs for mandelbrot (debian benchmarks) on parrot lua
12:33 muixirt 0.099secs for standard lua
12:33 tadzik mhm. Maybe it is slow and I didn't notice. I was just running a binary clock with it
12:37 muixirt two magnitudes slower *is* awful, well but it works
12:46 mikehh left #parrot
12:47 * muixirt got rid of ecmascript fork
12:54 muixirt left #parrot
12:58 lucian joined #parrot
12:59 lucian left #parrot
13:06 whiteknight joined #parrot
13:14 whiteknight good morning, #parrot
13:22 whiteknight parrot.org is the fail
13:23 NotFound Lost connection to MySQL server at 'reading initial communication packet', system error: 113.
13:23 dalek winxed: r702 | NotFound++ | trunk/winxedst1.winxed:
13:23 dalek winxed: encapsulate information about variables in a class instead of using a plain hash
13:23 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=702
13:25 whiteknight yeah, I just sent an email to osu
13:27 whiteknight trac.parrot.org still appears to be working
13:33 dmalcolm joined #parrot
14:18 dalek winxed: r703 | NotFound++ | trunk/winxedst1.winxed:
14:18 dalek winxed: generate lexnames unique in the outermost scope, Issue #6, plobsing++
14:18 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=703
14:20 Coke the part of the build where we compile .pm -> .pir seems like the slowest part of the build now.
14:29 whiteknight hasn't it always been?
14:29 whiteknight Actually, we didn't used to do a lot of that. More things are moving from PIR to NQP
14:39 Coke here is a very small snippet of tcl that exposes some parrot bug/change/deprecation/? :
14:39 Coke time {expr 2+2}
14:40 Coke set_string_native() not implemented in class 'TclString'
14:42 whiteknight what is that snippet supposed to do?
14:44 Coke run the code in the block and return something like:
14:44 Coke 23 microseconds per iteration
14:44 whiteknight okay
14:44 whiteknight Does TclString have a set_string_native VTABLE?
14:44 Coke the code doesn't matter: time {set a 2} dies also.
14:45 Coke whiteknight: it's a subclass of String. You'd think so.
14:45 whiteknight ok
14:45 whiteknight and this is in old partcl, not partcl-nqp?
14:46 Coke -nqp
14:46 whiteknight okay
14:46 Coke (subclass created using p6metaclass)
14:47 Coke (not explicitly. it's just "class TclString is String" in nqp)
14:55 mtk left #parrot
14:58 bluescreen hey, good morning
14:59 bluescreen tough question... Do we know what things are slowing parrot down? This morning muyxirt  showed a comparision of official lua vs. parrot lua for running a test suit it was 0.1 secs vs. 23 secs
15:00 bluescreen its all because imcc? how good is parrot running bytecode vs. other non-jitters interpreters?
15:01 bluescreen is it because the gc is the bottleneck?
15:01 moritz for rakudo programs, the IMCC performance doesn't matter at all
15:01 bluescreen mortiz, did you run any profiling in rakudo/parrot?
15:01 moritz ie running a program compiled to pir vs. compiled to pbc doens't make a difference
15:02 moritz bluescreen: we only have C-level profiling, afaict. Last time it identified GC and hash access to be slowest paths
15:02 moritz both areas have been worked on since then
15:03 moritz rakudo has other reasons for slowness
15:03 moritz *) mismatch of object methods
15:03 bluescreen well, pir generated pbc probably have same vices as pir
15:03 moritz *) assignment vs. binding
15:03 bluescreen its like perl generated c code
15:03 bluescreen it won't be any faster
15:03 moritz *) GC
15:04 moritz *) having to wrap everything
15:04 moritz s/object methods/object models/ above
15:04 bluescreen there got to be an 80:20 somewhere
15:05 moritz *) missing (de)serialization for object graphs with cycles
15:05 bluescreen wrapping you mean creating the P6Object on top of Parrot Objects?
15:06 moritz that, and that we have to wrap each and every PIR opcode, even if it's semantically identical to a Perl 6 builtin
15:06 NotFound Coke: What is current partcl-nqp repo? http://github.com/partcl/partcl-nqp.git ?
15:06 moritz because p6 wants things like introspectable signatures, multi dispatch and autothreading
15:07 mtk joined #parrot
15:07 bluescreen how hard would be to emit pbc instead of pir... since with 6model seems like you won't be using much the Parrot object model
15:07 moritz there have been plenty discussions about why rakudo is slow, many involving pmichaud++
15:08 Coke NotFound: that looks right.
15:08 NotFound bluescreen: if you emit pbc you may need to chenge the generator every week
15:08 bluescreen notfound: till pbc is stable enough?
15:08 NotFound bluescreen: pbc format, opcodes, PMCs....
15:09 moritz bluescreen: I can't tell. Most of the code generation is done via PAST, so we'd just need a POST => PBC backend
15:09 moritz but there's also some embedded PIR, and I have no idea how much work it'll be to get rid of it
15:10 moritz to some extend it's not possible without enhancing PAST, afaict
15:10 NotFound Coke: Parrot revision r48596 required (currently r1)
15:11 bluescreen right. I'm wondering whether in a long term rakudo wants to keep pir or not
15:11 moritz it doesn't want to
15:11 Coke NotFound: hand edit the parrot revision file to set it to 1.
15:11 NotFound Coke: ok
15:11 Coke (and thanks for taking a look, I appreciate it.)
15:11 moritz because we want to target multiple VMs
15:12 Coke moritz: yah, getting rid of the handrolled pir in partcl-nqp would be nice, too.
15:12 * Coke needs to rename partcls, so that "partcl" means new, and partcl-pir means old.
15:12 bluescreen moritz.. is that an overall strategy or because of parrot's current speed?
15:13 moritz bluescreen: overall
15:13 bluescreen i mean, if parrot already were a high perf vm, would you be thinking in moving to other vms?
15:13 moritz we don't want to move, just expand
15:13 moritz and yes, even if parrot was faster
15:14 bluescreen ok
15:14 whiteknight moving PIR out of the compiler hotpath is a big priority for Parrot
15:15 whiteknight There's no reason for a compiler to have to generate PIR, and then have that compiled in a separate stage to PBC. HLLs should output PBC directly
15:15 whiteknight We don't have good tools for this yet, and as NotFound pointed out it's not a very stable system right now
15:15 bluescreen will lorito bring balance to the force?
15:15 whiteknight We need to put a good, stable interface on PBC generation, and guarantee that the interface will produce working code
15:16 moritz well, we don't need stable bytecode format, a stable API for creating it would be enough
15:16 whiteknight right, it's the interface that's important
15:16 whiteknight if libparrot provides the PBC creation tools, and consumes the PBC, only libparrot cares about the format
15:16 whiteknight the format can change so long as both ends still look the same
15:16 Coke NotFound:     $ms_per ~ ' microseconds per iteration';
15:17 NotFound Coke: can't help, the P6metaclass stuff is out of my knowledge.
15:17 Coke that's the line that's causing the problem (src/Partcl/commands/time.pm)
15:17 bluescreen so gettting back to my original question? how good is parrot at running stand alone pbc? ( compared to other non-jitters interp)
15:20 Coke argh. if I change it to ~$ms_per ~ ' microseconds per iteration'; no error.
15:20 NotFound Coke: What's the ~ operator? Concatenate?
15:20 whiteknight bluescreen: Not good, but not terrible either. The actual runloop is standard, nothing fancy. We don't JIT which could be a big improvement
15:20 moritz yes
15:20 moritz and it doesn't coerce, like in real Perl 6
15:21 whiteknight bluescreen: the real performance problems happen in things like GC, multi-method dispatch, hash access, etc
15:21 whiteknight in terms of GC, it's two-pronged: We create too many objects that need to be managed by GC ("GCables") and our GC algorithm is poor
15:22 bluescreen so we already have a measure on those...
15:22 whiteknight For instance, a Rakudo Object is a PMC which contains a Hash PMC of attributes, an Array PMC for other stuff, a Hash PMC for properties, etc
15:23 bluescreen is there any plan to do... I don't know ... task force to address those
15:23 whiteknight so every 1 Rakudo object is several Parrot objects
15:23 whiteknight bluescreen: yes.
15:23 NotFound Exception handling is other weak point in speed, and given that is used for control flow in several languages, is a noticeable problem.
15:23 moritz jnthn works on improving the situation for rakudo objects
15:23 Coke NotFound:  ~FOO is "get the string value of value", while FOO~BAR is concat FOO , BAR. ... I would have expected ~ to have to get the string value of each first anyway...
15:23 whiteknight bacek is working on a new GC algorithm that should be more friendly to large object loads.
15:23 bluescreen yes.. thats why hll should talk pbc directly
15:23 whiteknight jnthn is working on a new object system to decrease the number of GCables
15:24 moritz NotFound: I've never understood why. With CPS, exceptions should be dead cheap.
15:24 Coke ... and I see moritz already said it doesn't coerce. ...
15:24 whiteknight moritz: "dead cheap" in relation to things. An exception is no more expensive really than a sub call. The problem is our subcalls aren't too speedy
15:25 whiteknight and setting up control handlers at runtime for them is a huge drain
15:25 moritz whiteknight: compared to continuation invocations
15:25 NotFound moritz: creating the exception handler object, the exception object, and arrays and iterators to look for the appropiate handler..
15:25 Coke ah. it probably has to ~ the RHS, but not the LHS.
15:26 whiteknight moritz: right, the actual jump to the handler is cheap. Finding the handler, invoking the handler, passing the exception to it, etc. Those are expensive right now
15:26 whiteknight We create a CallContext PMC, parse through the signature, etc
15:27 whiteknight The exceptions system needs a pretty big refactor, and it is going to need some special-case logic in places where we don't need the full strength of PCC
15:28 NotFound whiteknight: maybe what we need is a lot less special cases.
15:28 whiteknight and handlers need to get cheaper to create
15:28 whiteknight Notfound: maybe that too. The PCC refactor unified a lot of stuff through a new dispatcher. That new dispatcher is pretty heavy for exceptions which ALWAYS invoke a handler with the same signature
15:28 whiteknight ->P
15:28 whiteknight er, P->
15:31 Coke getting the same error with t/cmd_for.t, but that one isn't as obvious.
15:31 NotFound And don't forget that non existent code doesn't need to be optimized. Generating less code for the simplest cases will be good.
15:33 whiteknight If people are interested in working on exceptions, we can start putting together a refactor design and a tasklist for it
15:34 whiteknight it hasn't been too high up on the priority heap yet
15:34 Patterner left #parrot
15:39 whiteknight I keep thinking that NQP would do much better in this regard if it used Continuations to handle return control semantics instead of CONTROL_RETURN exceptions
15:40 whiteknight at the very least you would lose the method call to set the return handler type, you lose the iterator over available exception handlers, etc
15:41 whiteknight I don't know if it uses exceptions for things like next/last in loops, but if so I suspect there is performance improvement to be had using continuations there too
15:41 zarchne left #parrot
15:41 zarchne joined #parrot
15:49 NotFound Method call? Where?
15:49 Psyche^ joined #parrot
15:49 Psyche^ is now known as Patterner
15:49 arnsholt whiteknight: It's been a while since I looked at the NQP source, but I'm pretty sure it uses the exceptions for loop control as well
15:50 whiteknight that's what I thought
15:50 particle aye, "control exceptions"
15:50 whiteknight I know there were reasons for it, but I don't remember all of them.
15:51 whiteknight I *strongly* suspect that deprecating control exceptions and using continuations instead would have a marked performance improvement for NQP
15:51 NotFound whiteknight: better the other way.
15:51 mtk left #parrot
15:51 whiteknight NotFound: what do you mean?
15:52 NotFound Fisrt using continuations, then think about deprecations.
15:52 whiteknight oh, right. I wasn't talking about it chronologically
15:52 whiteknight but yes, if we didn't use control exceptions and instead used continuations, we would have performance boost
15:53 jjore left #parrot
15:53 NotFound I feel the need to point that, we've been tendig to deprecate things too early.
15:53 mtk joined #parrot
15:53 whiteknight I also think there would be gains if we had proper exception subclasses instead of checking type numbers everywhere
15:54 whiteknight exception handlers in the same scope with different types are put into a multi. We use normal MMD to dispatch
15:54 whiteknight and when the scope exits, we can pop the multi as a single entity
15:57 whiteknight this all becomes more realistic after 4.0 when we (hopefully) have Lorito and a new MOP
15:57 dukeleto ~~
15:57 whiteknight hello dukeleto
15:57 dukeleto whiteknight: mornin'
15:57 whiteknight welcome to "Whiteknight rants about exceptions" hour in #parrot
15:57 bluescreen is the MOP going to be redesign to fit an object model like P6's one
15:58 whiteknight bluescreen: jnthn is a core Rakudo dev, so he is designing a MOP for Rakudo
15:58 whiteknight we think his work is powerful and flexible enough, and are looking to adapt it for use in Parrot directly
15:58 bluescreen yeah I know... but i meant if we going to adapt that to parrot's core
15:58 bluescreen ok
15:58 whiteknight yes. We do want to merge it into Parrot core
16:02 particle whiteknight: actually jnthn is designing a mop for nqp-rx, a project which someday intends to target multiple backends
16:03 whiteknight my mistake. Yes, you are right
16:03 particle that design work is also intended to meet both perl 6 and parrot's needs
16:04 he_ left #parrot
16:04 whiteknight Parrot's needs are "something that sucks less than our current offering".
16:05 dukeleto +1
16:05 whiteknight I have a brown paper bag I could start filling with banana peels and old coffee grounds which might satisfy that requirement
16:05 * atrodo enjoys whiteknight rants
16:05 atrodo Good reading material to distract me from $dayjob
16:06 whiteknight luckily, jnthn is going to do even better than that
16:08 Coke nqp is, as time permits, going to move to a continuation based control flow mechanism, IIRC. Tcl, however, will not be.
16:09 Coke (unless it's compelling and can support all the Tcl semantics.)
16:12 Coke I know whiteknight is being hyperbolic, but I would hope that if we have to go through YA redesign we end up with something awesome, not something slightly better than the placeholder we have.
16:12 dalek parrot: f8e868c | NotFound++ | src/scheduler.c:
16:12 dalek parrot: simplify a bit Parrot_cx_find_handler_local
16:12 dalek parrot: review: https://github.com/parrot/parrot/commit/f8e868c27f
16:13 whiteknight Coke: right. The first step in the "Whiteknight Method" of subsystem design is the angry, hyperbolic rant
16:14 whiteknight one of the many reasons why I'm not Six Sigma certified
16:15 bluescreen hehe... what a BS six sigma is... nothing but canned common sense
16:18 whiteknight Coke: Like I said earlier, the exceptions system has not been on the priorities list for redesign/reimplement
16:18 cotto Why do we disallow XXX and TODO in comments?
16:18 whiteknight if users identify it as a pain point, we can adjust priorities
16:19 whiteknight cotto: I suspect because a TODO is better served as a ticket instead of being burried
16:19 cotto that's sensible
16:20 moritz I kinda disagree
16:20 whiteknight somehow being buried in our Trac queue is better than being buried in our code
16:20 moritz when you read the source, you're interested in spots where the original author thought that more work was necessary
16:20 moritz you don't look through the whole trac queue
16:20 whiteknight moritz: you can have a comment pointing to a TT #. We have several of thsoe
16:20 cotto maybe you don't
16:21 jnthn particle: (someday intends to target multiple backends) already does... ;)
16:21 whiteknight but the details of the TODO are put in a ticket
16:22 moritz whiteknight: that works too
16:22 nopaste "cotto" at 192.168.1.3 pasted "rough outline of thoughts on ticket policy" (31 lines) at http://nopaste.snit.ch/26818
16:22 atrodo What if someone is working on the code on a plane, sees a TT# where he's having issues debugging?
16:22 particle jnthn: congrats!
16:22 * cotto goes to wrk
16:22 jnthn particle: Only cross-compilation at the moment but still...
16:23 * jnthn is more comfortable with existant portable implementation than a hopefully portable one. :)
16:24 particle atrodo: that person writes a ticket system based on git, the plane lands, and he profits.
16:24 atrodo particle++ # Touche
16:26 moritz atrodo: there's a perl based offline ticket system which can interact with several different bug trackers
16:27 moritz obra was involved with its development, iirc
16:27 dalek parrot: 6d04186 | NotFound++ | / (2 files):
16:27 dalek parrot: add init_int vtable to Exception
16:27 dalek parrot: review: https://github.com/parrot/parrot/commit/6d04186314
16:29 whiteknight msg cotto ticket inclusion policy draft looks ok. We might also want to specifically mention the Trac wiki task lists , which can be used to keep track of pie-in-the-sky design tasks and TODOs which might not be suitable as tickets in this policy
16:29 aloha OK. I'll deliver the message.
16:29 particle osuosl had a db server crash, parrot.org is affected
16:30 moritz atrodo: http://syncwith.us/
16:30 dukeleto sadface.
16:30 atrodo moritz> well that looks cool
16:31 Andy joined #parrot
16:32 * particle gives dukeleto a cookie
16:37 * dukeleto eats a cookie
16:39 whiteknight if PaFo had the money, we would mail out more cookies
16:39 dukeleto we could have a bake sale...
16:45 jjore joined #parrot
16:48 whiteknight if https://github.com/parrot/parrot/network were animated, it would become my new favorite TV show
16:53 cotto_work ohai
16:54 dukeleto cotto_work: hola hola hola
16:55 silug left #parrot
16:56 cotto_work whiteknight: I love that show.
16:57 whiteknight cotto_work; I'm thinking about the various tasklist pages on the wiki. I think they deserve a more prominent role
16:57 lucian joined #parrot
16:57 whiteknight we don't need feature TODO tickets in trac. We layout a design somewhere (PDD, wiki, etc), then distill that down to a tasklist
16:58 whiteknight items from the tasklist can become tickets, instead of the other way around where we've been taking lots of related TODO tickets, combining them into a tasklist, and then calling that our design
16:58 cotto_work that makes sense.  Collaborative editing is a more natural fit for figuring out a design.
16:59 whiteknight it also would create a nice flow: We hash out a general design on one wiki page, then use another wiki page to break it out into tasks
16:59 cotto_work then we make tickets out of the tasks, then we take over the world
16:59 whiteknight when we're ready at each stage, we mine the tasklist for potential tickets, or we don't set up tickets at all unless they generate patches
16:59 mikehh joined #parrot
17:01 dukeleto cotto_work: me likey
17:02 dukeleto What do we need translated (for GCI), other than our website?
17:02 dukeleto Are there some core Parrot docs that we would like translated to other languages? (i.e. German)
17:02 whiteknight README?
17:02 dukeleto whiteknight: i likey
17:02 whiteknight make it so
17:03 dukeleto whiteknight: so we will have multiple README's in our repo, something like README.deutsch, README.klingon, etc...
17:05 theory joined #parrot
17:05 NotFound Are you taking into account that we are actually failing to keep up to date the docs in one language?
17:10 whiteknight dukeleto: I would say yes. Maybe a folder for them or something
17:13 wesjdj joined #parrot
17:25 dukeleto whiteknight: sure, namespaces are nice
17:30 mtk left #parrot
17:31 whiteknight dukeleto: once we have the translated files in hand, finding a way to name/store them is really trivial
17:34 lucian left #parrot
17:35 whiteknight what is README in german?
17:38 cotto_work whiteknight: probably "README"
17:38 whiteknight that's no fun
17:42 cotto_work I'm sure moritz could make up something more interesting.
17:46 mtk joined #parrot
17:50 dukeleto i think keeping the name of the file README.$language is fine. README is a meme that hackers of all languages know
17:50 dukeleto but whatever, we can figure it out
17:50 mtk left #parrot
17:51 mtk joined #parrot
17:54 mtk left #parrot
17:55 mtk joined #parrot
17:58 theory left #parrot
18:00 moritz LIESMICH
18:01 whiteknight ah, we probably want to avoid anything that starts with LIES
18:01 whiteknight even if everything in the document is false
18:01 whiteknight (which is not unlikely)
18:04 dukeleto which languages do we want our README in?
18:04 dukeleto other than ancient Hittite and Klingon...
18:05 cotto_work hieroglyphs
18:05 whiteknight dukeleto: you mean there are MORE options?
18:09 NotFound Mordor runes.
18:17 particle lorito.
18:21 whiteknight on a serious note, Spanish and German are good translation targets
18:21 whiteknight it seems like there are some Portuguese people in GCI too
18:21 whiteknight Russian
18:22 whiteknight I could mentor a task to translate README into bad english
18:23 whiteknight "Check it: We gon' get dis shit from github 'cause svn is mad whack. Fo shizzle"
18:24 bluescreen so gangstaaaa!!!
18:28 fperrad left #parrot
18:51 NotFound I'd like a translation to Reverse Polish Notation
18:54 dukeleto i already created a Russian translation task. Will create a "Bad Russian" one, just for bacek_at_work
18:54 dalek parrot: 2b1c336 | NotFound++ | examples/nci/ls.pir:
18:54 dalek parrot: questionable fix for nci example ls.pir, WFM in amd64 linux, TT #1180
18:54 dalek parrot: review: https://github.com/parrot/parrot/commit/2b1c3369fb
18:59 whiteknight checkout -> git_clone parrot_repo_url
19:00 whiteknight git_clone -> "git clone"
19:00 whiteknight parrot_repo_url -> "git://github.com/parrot/parrot.git"
19:00 silug joined #parrot
19:06 dngor left #parrot
19:07 dalek winxed: r704 | NotFound++ | trunk/pir/winxed_compiler.pir:
19:07 dalek winxed: update installable compiler
19:07 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=704
19:07 hercynium joined #parrot
19:10 Coke I recommend that any translated docs go under docs/fr_FR/ or something equally lame.
19:11 dalek parrot: 9d14f6b | NotFound++ | examples/nci/ls.pir:
19:11 dalek parrot: a bit more portable fix for nci example ls.pir, WFM in amd64 and i386 linux, TT #1180
19:11 dalek parrot: review: https://github.com/parrot/parrot/commit/9d14f6b196
19:11 dngor joined #parrot
19:12 cotto_work Coke: good idea.  The more obscure they are, the less we'll think about how quickly they'll become outdated.
19:17 theory joined #parrot
19:35 rfw joined #parrot
20:16 jan left #parrot
20:21 jan joined #parrot
20:31 Coke cotto_work: I was actually being serious. ;)
20:31 Coke rather than having a proliferation of side-by-side docs.
20:35 NotFound Don't we have a wiki or something?
20:36 whiteknight parrot.org should be back up
20:36 whiteknight OSUOSL++
20:39 Coke NotFound: was that in re: translated docs?
20:40 NotFound Coke: yes, I think the wiki is more convenient for that.
20:40 Coke (I'd also like to have docs.parrot.org be able to switch to alternate versions of docs if we have the translation - we can figure that out when we run 'make html')
20:40 Coke NotFound: should our primary docs go in the wiki?
20:41 NotFound A translation is not a primary source.
20:41 Coke someone looking for docs should be able to just go through docs.parrot.org, even if it's a contributed translation.
20:42 M_o_C joined #parrot
20:42 Coke I'll be happy to work on that bit of infrastructure, given translated docs.
20:43 NotFound Coke: I, for one, switch to english or even french wherever I can better that facing bad, inacurate and outdated translations.
20:46 whiteknight NotFound: must be nice to be multi-lingual
20:51 NotFound whiteknight: yes, is useful, even not being good at almost any.
20:52 whiteknight NotFound: I took 4 years of Latin in school. I've forgotten most of it
20:52 whiteknight I don't suspect we have any Latin-speaking users anyway
20:52 jnthn School turned out to be a bad place to learn languages. Or in my experiene anyway.
20:52 jnthn *experience
20:53 NotFound whiteknight: the problem with Latin is the lack of native teachers.
20:53 NotFound Same as with C.
20:56 Coke whiteknight: aliquam.
20:57 Coke jnthn: it's an ok place to learn, but if you don't do anything with it outside of school, you're SOL.
20:58 jnthn Coke: Yeah, I guess that was the real issue.
20:58 jnthn Coke: Though the pace was pretty slow/unchallenging where I was at too.
20:58 jnthn They skimped on grammar badly too.
20:59 jnthn Because it's "too hard" or something.
21:00 Coke ooh, google translate now has latin
21:00 Coke jnthn: crappy school.
21:00 sorear classical latin or 21st century latin?
21:00 Coke sorear: it just says "latin". Have fun experimenting.
21:01 NotFound jnthn: some people learn C that way. That explains the big amount of bad C code and bad C tutorials.
21:01 jnthn Coke: Trouble was that they churned out people able to pass the exam, so looked great on paper. However, schools in the area who were "worse" on paper (exam wise) seemed to produce people who were more competent in the language.
21:01 atrodo sorear> There's a 21st century latin?
21:01 Coke yah, it's very much like learning a programming language at school.
21:02 Coke jnthn: standardized testing definitely has pros and cons.
21:02 NotFound atrodo: sure, the Vatican uses it.
21:04 atrodo NotFound> I always thought there was no difference.  Least that's what my latin teacher lead me to believe
21:04 theory left #parrot
21:07 NotFound atrodo: for example, Classic Latin has no word for photocopy ;)
21:08 whiteknight I will say that a knowledge of Latin helped a whole lot on the SAT and GRE. I don't really know how to speak any of it anymore, but I can still recognize latin roots in words I come across
21:11 NotFound Can someone try examples/nci/ls.pir in something not i386 nor amd64?
21:13 Coke NotFound: darwin don't count, do it.
21:14 NotFound Coke: test in non-linux is also good.
21:15 fbrito joined #parrot
21:16 nopaste "coke" at 192.168.1.3 pasted "for notfound on parrot-latest on darwin/x86" (9 lines) at http://nopaste.snit.ch/26822
21:16 Coke BOOM.
21:18 NotFound Coke: Using current master?
21:19 NotFound Ah, latest, ok.
21:20 Coke yes, although rakudo thinks I'm out of date.
21:20 Coke (git-describe is telling me I have an older version, but "git pull" says I'm up to date.)
21:22 NotFound According that page http://developer.apple.com/library/mac/#DOCU​MENTATION/Darwin/Reference/ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir
21:22 NotFound the struct is not the same as in linux, so no wonder it fails.
21:27 whiteknight left #parrot
21:29 cotto_work Coke: my mistake.  I misinterpreted you as saying the README should go there.
21:30 cotto_work +1 to your suggestion
21:38 NotFound Added a comment to TT #1180 about the portability problem.
21:41 lucian joined #parrot
21:43 dalek winxed: r705 | NotFound++ | trunk/examples/ajax.winxed:
21:43 dalek winxed: add a workaround for chunked encoding transfer to example ajax
21:43 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=705
21:53 theory joined #parrot
21:58 mtk left #parrot
22:03 wesjdj left #parrot
22:09 donaldh joined #parrot
22:29 bacek_at_work ~~
22:29 Coke bacek_at_work: hio.
22:30 bacek_at_work aloha, Coke
22:31 Coke what time is it there?
22:31 cotto_work ~~
22:31 bacek_at_work aloha, clock?
22:31 aloha bacek_at_work: LAX: Wed, 14:31 PST / CHI: Wed, 16:31 CST / NYC: Wed, 17:31 EST / UTC: Wed, 22:31 UTC / LON: Wed, 22:31 GMT / BER: Wed, 23:31 CET / TOK: Thu, 07:31 JST / SYD: Thu, 09:31 EST
22:32 bacek_at_work Coke, 9:30 AM :)
22:32 bacek_at_work Thursday
22:32 Matt221 joined #parrot
22:54 M_o_C left #parrot
22:56 Matt221 left #parrot
22:56 Matt221 joined #parrot
22:57 Hunger left #parrot
23:08 cotto_work bacek_at_work: what are your thoughts on the opmap_aware_pmcs branch?  I saw that you made a couple fixes.
23:14 bacek_at_work cotto_work, wrapping my head around opmapping. Nothing much yet
23:14 cotto_work my blog post might help.
23:15 cotto_work http://reparrot.blogspot.com/2010/11/wh​at-happened-in-dynopmapping-branch.html
23:16 TypeNameHere_____ joined #parrot
23:27 dmalcolm left #parrot
23:30 donaldh left #parrot
23:33 hudnix joined #parrot
23:38 kid51 joined #parrot
23:44 Matt221 Is anyone else having trouble compiling the embed_api2 branch?
23:46 cotto_work Matt221: building now
23:47 Matt221 I seem to be getting: "make: *** [runtime/parrot/library/PCT/PAST.pbc] Segmentation fault"
23:47 Matt221 this is on a clean checkout of the latest source
23:48 cotto_work Matt221: looks fine
23:51 Matt221 cotto_work: Just did a `make clean` and getting the same problem
23:52 cotto_work did you try reconfig to be sure?  clean doesn't get everything.
23:54 Matt221 yup same issue. I even cloned the repository into a new folder and it fails to compile as well
23:54 cotto_work can you nopaste how the build fails?
23:56 Matt221 Last few messages: http://pastie.org/private/pemwh051tszikvsqhmyc9w
23:57 cotto_work That's odd.  What platform are you on?
23:59 Matt221 OS X
23:59 Matt221 Should I try on Linux in VMware?

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

Parrot | source cross referenced