Parrot 2.10.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot Developer Summit 2300 UTC today | Please test rakudo with bleeding edge parrot!
Set by moderator on 5 December 2010.
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
fbrito bluescreen: I live in en.wikipedia.org/wiki/Jo%C3%A3o_Pessoa, the easternmost city in the Americas :)
bluescreen even better 00:02
it must be hell right now 00:03
fbrito it is always like hell :( 00:04
average of 28~30C
bluescreen well same here but i don't have the nice beaches
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
sorry I missed #ps but got tied up
fbrito bluescreen: have you ever been in Brazil? The only time I left it was in my exchange student program (to Europe) 00:08
bluescreen many times... i love brazil 00:09
fbrito wow, very interesting :) 00:14
dukeleto fbrito: looks like an awesome city. I will have to come visit :)
bluescreen dukeleto: you can call it a biz trip 00:16
fbrito ahahha, good idea 00:17
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?
lucian fbrito: i'm in Newcastle, UK right now, and I'll be going somewhere close to Recife 00:24
fbrito Recife is only 120km away from here! Do you have family/friends here? 00:26
lucian fbrito: sort of, my i'm staying with my dad. he takes his vacations in brazil 00:27
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 :)
fbrito s/I host/I can host/
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:34
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:35
lucian fbrito: i'm european (romanian), that's not terribly surprising to me 00:36
00:39 smash left 00:41 Matt221 left 00:42 kid51 is now known as kid51_at_dinner 00:55 theory left 00:56 bluescreen left 00:57 whiteknight joined 00:59 bluescreen joined 01:00 chromatic left
whiteknight good evening, #parrot 01:03
bluescreen good evening 01:05
01:05 dip left 01:06 dip joined 01:13 nwellnhof joined
whiteknight blah. My experiments in javascript are not going well. 01:33
I can install narwhal, but there's a problem in it's metadata repo so I can't use it to install jison
Ubuntu installs node.js as "nodejs" instead of "node", which is what all the software expects. 01:34
so I create a symlink, but then the makefile for npm fails with an unhandled exception
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
whiteknight ...and finally I am able to build cafe 01:51
cotto ~~ 01:52
kid51_at_dinner, pign
or ping if you prefer
01:55 kid51_at_dinner is now known as kid51
kid51 pong 01:55
though in a few minutes it has to be kid51_doing_laundry
cotto privmsg'd 01:56
02:01 kid51 is now known as kid51_doing_laundry 02:04 mikehh left, tcurtis left 02:07 kid51_doing_laundry left
lucian whiteknight: i found this interesting pycon.blip.tv/file/3263942/ 02:10
it's very long, though
whiteknight no time for that tonight
will watch it tomorrow
lucian it's VERY long
3h+ ...
cotto 3h+? Is there a "the important parts" version? 02:14
lucian cotto: not afaict 02:16
it's not a presentation, just a recording from some coding thing
the important part is "implementing increasingly large subsets of python in assembly is both fun and hard" 02:17
02:20 whiteknight left
lucian i wonder if his results are fast at all 02:22
lucian hates java 02:25
Coke use groovy or cold fusion! 02:27
lucian Coke: it's not a choice. and i don't love groovy much either :)
uni coursework ... 02:28
cotto at least you won't be stuck with it for long 02:30
02:31 s1n joined
lucian cotto: i'm not very hopeful. a ton of projects still use java 02:31
cotto Sure, but you won't be dealing with any 1.5 mloc code bases with factory factory builders. 02:33
It's not a bad learning language. Its excessive verbosity is annoying though. 02:35
Do you have the option of taking a principles of programming languages class? Those are great. 02:36
02:36 s1n left
lucian cotto: for some reason there's not one in my uni right now 02:37
i do however think java is quite a bad learning language 02:38
there are too many arbitrary restrictions
lucian is thankful he didn't learn to program in java
cotto It doesn't have the sharp edges of C++ or the bookkeeping of C.
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.
lucian i'm implementing A* in java and it's truly horrible
cotto A*? 02:40
lucian there are so many useless contortions, half of which because the basic types and literals suck
cotto: A* search in a grid
lucian is off to sleep. good night! 02:50
cotto 'night
02:50 lucian left 02:54 nwellnhof left 03:09 ingy left 03:15 theory joined
fbrito There is a comment on this task www.google-melange.com/gci/task/sho...9148666886 saying that this task is invalid. It that true? 03:22
cotto looking 03:24
not sure what he's talking about 03:25
seen matt-gci
aloha matt-gci was last seen in #parrot 3 days 7 hours ago joining the channel.
cotto fbrito, I see you jumped up a bit in the gci rankings 03:27
dukeleto, ping 03:28
03:31 kthakore left
fbrito cotto: yes... I (me?) and rfw are going pretty well right now :) 03:36
dukeleto cotto: pong 03:48
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 blog.chromium.org/2010/12/new-crank...or-v8.html
I would love to see how well parrot-js does on those benchmarks when it's running. 03:50
fbrito dukeleto: I see... thank you :) 03:51
cotto dukeleto, is there an easier way to fill in gci tasks than using melange directly? 03:52
rfw did i just get higlighted
oh, right there
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:56
cotto: github.com/leto/gci 03:57
cotto: feel free to fork that repo, it has task templates and examples
cotto dukeleto, is that easier than filling in the form in melange? 03:58
dukeleto cotto: for me it is 03:59
cotto: YMMV
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
cotto: but you can just copy and paste that if you want
cotto That add-on looks nice.
dukeleto cotto: it saves my life every day 04:01
cotto: especially with Melange
theoatmeal.com/comics/unanswered_email 04:04
it is mildly parrot related...
dalek rrot/tt532_headerizer_refactor: 880b3e2 | jkeenan++ | t/tools/dev/headerizer/02_methods.t:
Test more execution paths in attrs_from_args().
 04:06
rrot/tt532_headerizer_refactor: b1f035b | jkeenan++ | t/tools/dev/headerizer/02_methods.t:
Return from tempdir gracefully.
 04:12
fbrito I am going to bed. Good night guys :) 04:49
cotto g'night 04:51
04:52 fbrito left 05:13 theory left
dalek tracwiki: v22 | cotto++ | LoritoDesignQuestions 05:30
tracwiki: trac.parrot.org/parrot/wiki/LoritoD...ction=diff
05:38 mikehh joined 05:45 s1n joined 05:46 s1n left
cotto jnthn, ping 05:50
cotto sleeps 06:23
07:21 he_ joined 07:43 bacek left 08:31 fperrad joined 08:51 bacek joined 09:36 fperrad_ joined 09:38 rfw left 09:39 fperrad left, fperrad_ is now known as fperrad 09:41 dngor left 09:47 dngor joined
dalek rrot/opmap_aware_pmcs: b62fff4 | bacek++ | examples/pir/make_hello_pbc.pir:
Update make_hello_pbc.pir to use new PackfileConstTable.
 09:50
rrot/opmap_aware_pmcs: 35f43c1 | bacek++ | src/pmc/packfileopmap.pmc:
Drop inheritance of PackfileOpMap from PackfileSegment. OpMap isn't segment anyway.
rrot/opmap_aware_pmcs: 4645e2e | bacek++ | src/pmc/packfileopmap.pmc:
Set custom_mark on PackfileOpMap and drop useless VTABLE_destroy. Our GC is not so bad.
10:36 cognominal left, cognominal joined 10:57 slavorgn joined 11:03 bacek left 11:16 bacek joined 11:39 ligne joined 11:42 lucian joined 11:47 muixirt joined
muixirt hi 11:47
mikehh muixirt: hi there 11:54
muixirt so all languages targetting parrot are waiting for mop? 11:55
11:56 ligne left
muixirt all languages with the exception of rakudo seem to be abandoned. 11:57
tadzik lua works
lucian pynie almost does too
there's still a bug i have to fix 11:58
muixirt: it's partly because of the MOP, yes
tadzik and LOLCODE works quite well. Even bf works, I fixed some of this few days ago
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 11:59
muixirt lucian: please explain 12:01
lucian muixirt: the parrot documentation recommends implementing languages using PCT/NQP
that's very useful for newly created languages 12:02
muixirt where was that advice given?
lucian but existing, mature languages already have a working runtime (ruby, tcl, python, lua)
so it would be both easier and more maintainable to use the language itself for the parrot compiler 12:03
12:04 jsut joined 12:09 jsut_ left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#1554) fulltest) at 8c3a723 - Ubuntu 10.10 amd64 (g++-4.5) 12:09
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
muixirt tadzik: is lua expected to work? the tests fail horribly 12:19
12:22 mtk joined
tadzik muixirt: really? It usually works 12:25
lemee check
ah, I won't check, ETOORESTRICTIVEFIREWALL 12:26
muixirt tadzik: it may fail due to my setup here, didn't read manuals :-) 12:27
but installable_lua works
12:28 lucian left
muixirt but parrot lua is awful slow 12:29
tadzik is it? It's slower than an "official lua", but not awful slow. Rakudo is awful slow :) 12:31
muixirt 23 secs for mandelbrot (debian benchmarks) on parrot lua 12:33
0.099secs for standard lua
tadzik mhm. Maybe it is slow and I didn't notice. I was just running a binary clock with it
muixirt two magnitudes slower *is* awful, well but it works 12:37
12:46 mikehh left
muixirt got rid of ecmascript fork 12:47
12:54 muixirt left 12:58 lucian joined 12:59 lucian left 13:06 whiteknight joined
whiteknight good morning, #parrot 13:14
parrot.org is the fail 13:22
NotFound Lost connection to MySQL server at 'reading initial communication packet', system error: 113. 13:23
dalek nxed: r702 | NotFound++ | trunk/winxedst1.winxed:
encapsulate information about variables in a class instead of using a plain hash
whiteknight yeah, I just sent an email to osu 13:25
trac.parrot.org still appears to be working 13:27
13:33 dmalcolm joined
dalek nxed: r703 | NotFound++ | trunk/winxedst1.winxed:
generate lexnames unique in the outermost scope, Issue #6, plobsing++
 14:18
Coke the part of the build where we compile .pm -> .pir seems like the slowest part of the build now. 14:20
whiteknight hasn't it always been? 14:29
Actually, we didn't used to do a lot of that. More things are moving from PIR to NQP
Coke here is a very small snippet of tcl that exposes some parrot bug/change/deprecation/? : 14:39
time {expr 2+2}
set_string_native() not implemented in class 'TclString' 14:40
whiteknight what is that snippet supposed to do? 14:42
Coke run the code in the block and return something like: 14:44
23 microseconds per iteration
whiteknight okay
Does TclString have a set_string_native VTABLE?
Coke the code doesn't matter: time {set a 2} dies also.
whiteknight: it's a subclass of String. You'd think so. 14:45
whiteknight ok
and this is in old partcl, not partcl-nqp?
Coke -nqp 14:46
whiteknight okay
Coke (subclass created using p6metaclass)
(not explicitly. it's just "class TclString is String" in nqp) 14:47
14:55 mtk left
bluescreen hey, good morning 14:58
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 14:59
its all because imcc? how good is parrot running bytecode vs. other non-jitters interpreters? 15:00
is it because the gc is the bottleneck? 15:01
moritz for rakudo programs, the IMCC performance doesn't matter at all
bluescreen mortiz, did you run any profiling in rakudo/parrot?
moritz ie running a program compiled to pir vs. compiled to pbc doens't make a difference
bluescreen: we only have C-level profiling, afaict. Last time it identified GC and hash access to be slowest paths 15:02
both areas have been worked on since then
rakudo has other reasons for slowness 15:03
*) mismatch of object methods
bluescreen well, pir generated pbc probably have same vices as pir
moritz *) assignment vs. binding
bluescreen its like perl generated c code
it won't be any faster
moritz *) GC
*) having to wrap everything 15:04
s/object methods/object models/ above
bluescreen there got to be an 80:20 somewhere
moritz *) missing (de)serialization for object graphs with cycles 15:05
bluescreen wrapping you mean creating the P6Object on top of Parrot Objects?
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? github.com/partcl/partcl-nqp.git ?
moritz because p6 wants things like introspectable signatures, multi dispatch and autothreading
15:07 mtk joined
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++
Coke NotFound: that looks right. 15:08
NotFound bluescreen: if you emit pbc you may need to chenge the generator every week
bluescreen notfound: till pbc is stable enough?
NotFound bluescreen: pbc format, opcodes, PMCs....
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
but there's also some embedded PIR, and I have no idea how much work it'll be to get rid of it
to some extend it's not possible without enhancing PAST, afaict 15:10
NotFound Coke: Parrot revision r48596 required (currently r1)
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
Coke NotFound: hand edit the parrot revision file to set it to 1.
NotFound Coke: ok
Coke (and thanks for taking a look, I appreciate it.)
moritz because we want to target multiple VMs
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.
bluescreen moritz.. is that an overall strategy or because of parrot's current speed?
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?
moritz we don't want to move, just expand
and yes, even if parrot was faster
bluescreen ok 15:14
whiteknight moving PIR out of the compiler hotpath is a big priority for Parrot
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
We don't have good tools for this yet, and as NotFound pointed out it's not a very stable system right now
bluescreen will lorito bring balance to the force?
whiteknight We need to put a good, stable interface on PBC generation, and guarantee that the interface will produce working code
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
if libparrot provides the PBC creation tools, and consumes the PBC, only libparrot cares about the format
the format can change so long as both ends still look the same
Coke NotFound: $ms_per ~ ' microseconds per iteration';
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)
bluescreen so gettting back to my original question? how good is parrot at running stand alone pbc? ( compared to other non-jitters interp)
Coke argh. if I change it to ~$ms_per ~ ' microseconds per iteration'; no error. 15:20
NotFound Coke: What's the ~ operator? Concatenate?
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
moritz yes
and it doesn't coerce, like in real Perl 6
whiteknight bluescreen: the real performance problems happen in things like GC, multi-method dispatch, hash access, etc 15:21
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
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
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
bluescreen: yes.
NotFound Exception handling is other weak point in speed, and given that is used for control flow in several languages, is a noticeable problem.
moritz jnthn works on improving the situation for rakudo objects
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...
whiteknight bacek is working on a new GC algorithm that should be more friendly to large object loads.
bluescreen yes.. thats why hll should talk pbc directly
whiteknight jnthn is working on a new object system to decrease the number of GCables
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. ...
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
and setting up control handlers at runtime for them is a huge drain 15:25
moritz whiteknight: compared to continuation invocations
NotFound moritz: creating the exception handler object, the exception object, and arrays and iterators to look for the appropiate handler..
Coke ah. it probably has to ~ the RHS, but not the LHS.
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
We create a CallContext PMC, parse through the signature, etc
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:27
NotFound whiteknight: maybe what we need is a lot less special cases. 15:28
whiteknight and handlers need to get cheaper to create
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
->P
er, P->
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.
whiteknight If people are interested in working on exceptions, we can start putting together a refactor design and a tasklist for it 15:33
it hasn't been too high up on the priority heap yet 15:34
15:34 Patterner left
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:39
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:40
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
15:41 zarchne left, zarchne joined
NotFound Method call? Where? 15:49
15:49 Psyche^ joined, Psyche^ is now known as Patterner
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:49
whiteknight that's what I thought 15:50
particle aye, "control exceptions"
whiteknight I know there were reasons for it, but I don't remember all of them.
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
whiteknight NotFound: what do you mean? 15:51
NotFound Fisrt using continuations, then think about deprecations. 15:52
whiteknight oh, right. I wasn't talking about it chronologically
but yes, if we didn't use control exceptions and instead used continuations, we would have performance boost
15:53 jjore left
NotFound I feel the need to point that, we've been tendig to deprecate things too early. 15:53
15:53 mtk joined
whiteknight I also think there would be gains if we had proper exception subclasses instead of checking type numbers everywhere 15:53
exception handlers in the same scope with different types are put into a multi. We use normal MMD to dispatch 15:54
and when the scope exits, we can pop the multi as a single entity
this all becomes more realistic after 4.0 when we (hopefully) have Lorito and a new MOP 15:57
dukeleto ~~
whiteknight hello dukeleto
dukeleto whiteknight: mornin'
whiteknight welcome to "Whiteknight rants about exceptions" hour in #parrot
bluescreen is the MOP going to be redesign to fit an object model like P6's one
whiteknight bluescreen: jnthn is a core Rakudo dev, so he is designing a MOP for Rakudo 15:58
we think his work is powerful and flexible enough, and are looking to adapt it for use in Parrot directly
bluescreen yeah I know... but i meant if we going to adapt that to parrot's core
ok
whiteknight yes. We do want to merge it into Parrot core
particle whiteknight: actually jnthn is designing a mop for nqp-rx, a project which someday intends to target multiple backends 16:02
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
whiteknight Parrot's needs are "something that sucks less than our current offering". 16:04
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
atrodo enjoys whiteknight rants
Good reading material to distract me from $dayjob
whiteknight luckily, jnthn is going to do even better than that 16:06
Coke nqp is, as time permits, going to move to a continuation based control flow mechanism, IIRC. Tcl, however, will not be. 16:08
(unless it's compelling and can support all the Tcl semantics.) 16:09
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 rrot: f8e868c | NotFound++ | src/scheduler.c:
simplify a bit Parrot_cx_find_handler_local
whiteknight Coke: right. The first step in the "Whiteknight Method" of subsystem design is the angry, hyperbolic rant 16:13
one of the many reasons why I'm not Six Sigma certified 16:14
bluescreen hehe... what a BS six sigma is... nothing but canned common sense 16:15
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?
whiteknight if users identify it as a pain point, we can adjust priorities
cotto: I suspect because a TODO is better served as a ticket instead of being burried 16:19
cotto that's sensible
moritz I kinda disagree 16:20
whiteknight somehow being buried in our Trac queue is better than being buried in our code
moritz when you read the source, you're interested in spots where the original author thought that more work was necessary
you don't look through the whole trac queue
whiteknight moritz: you can have a comment pointing to a TT #. We have several of thsoe
cotto maybe you don't
jnthn particle: (someday intends to target multiple backends) already does... ;) 16:21
whiteknight but the details of the TODO are put in a ticket
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 nopaste.snit.ch/26818
atrodo What if someone is working on the code on a plane, sees a TT# where he's having issues debugging?
particle jnthn: congrats!
cotto goes to wrk
jnthn particle: Only cross-compilation at the moment but still...
jnthn is more comfortable with existant portable implementation than a hopefully portable one. :) 16:23
particle atrodo: that person writes a ticket system based on git, the plane lands, and he profits. 16:24
atrodo particle++ # Touche
moritz atrodo: there's a perl based offline ticket system which can interact with several different bug trackers 16:26
obra was involved with its development, iirc 16:27
dalek rrot: 6d04186 | NotFound++ | / (2 files):
add init_int vtable to Exception
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.
particle osuosl had a db server crash, parrot.org is affected
moritz atrodo: syncwith.us/ 16:30
dukeleto sadface.
atrodo moritz> well that looks cool
16:31 Andy joined
particle gives dukeleto a cookie 16:32
dukeleto eats a cookie 16:37
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
whiteknight if github.com/parrot/parrot/network were animated, it would become my new favorite TV show 16:48
cotto_work ohai 16:53
dukeleto cotto_work: hola hola hola 16:54
16:55 silug left
cotto_work whiteknight: I love that show. 16:56
whiteknight cotto_work; I'm thinking about the various tasklist pages on the wiki. I think they deserve a more prominent role 16:57
16:57 lucian joined
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:57
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.
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
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
dukeleto cotto_work: me likey 17:01
What do we need translated (for GCI), other than our website? 17:02
Are there some core Parrot docs that we would like translated to other languages? (i.e. German)
whiteknight README?
dukeleto whiteknight: i likey
whiteknight make it so
dukeleto whiteknight: so we will have multiple README's in our repo, something like README.deutsch, README.klingon, etc... 17:03
17:05 theory joined
NotFound Are you taking into account that we are actually failing to keep up to date the docs in one language? 17:05
whiteknight dukeleto: I would say yes. Maybe a folder for them or something 17:10
17:13 wesjdj joined
dukeleto whiteknight: sure, namespaces are nice 17:25
17:30 mtk left
whiteknight dukeleto: once we have the translated files in hand, finding a way to name/store them is really trivial 17:31
17:34 lucian left
whiteknight what is README in german? 17:35
cotto_work whiteknight: probably "README" 17:38
whiteknight that's no fun
cotto_work I'm sure moritz could make up something more interesting. 17:42
17:46 mtk joined
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
but whatever, we can figure it out
17:50 mtk left 17:51 mtk joined 17:54 mtk left 17:55 mtk joined 17:58 theory left
moritz LIESMICH 18:00
whiteknight ah, we probably want to avoid anything that starts with LIES 18:01
even if everything in the document is false
(which is not unlikely)
dukeleto which languages do we want our README in? 18:04
other than ancient Hittite and Klingon...
cotto_work hieroglyphs 18:05
whiteknight dukeleto: you mean there are MORE options?
NotFound Mordor runes. 18:09
particle lorito. 18:17
whiteknight on a serious note, Spanish and German are good translation targets 18:21
it seems like there are some Portuguese people in GCI too
Russian
I could mentor a task to translate README into bad english 18:22
"Check it: We gon' get dis shit from github 'cause svn is mad whack. Fo shizzle" 18:23
bluescreen so gangstaaaa!!! 18:24
18:28 fperrad left
NotFound I'd like a translation to Reverse Polish Notation 18:51
dukeleto i already created a Russian translation task. Will create a "Bad Russian" one, just for bacek_at_work 18:54
dalek rrot: 2b1c336 | NotFound++ | examples/nci/ls.pir:
questionable fix for nci example ls.pir, WFM in amd64 linux, TT #1180
whiteknight checkout -> git_clone parrot_repo_url 18:59
git_clone -> "git clone" 19:00
parrot_repo_url -> "git://github.com/parrot/parrot.git"
19:00 silug joined 19:06 dngor left
dalek nxed: r704 | NotFound++ | trunk/pir/winxed_compiler.pir:
update installable compiler
 19:07
19:07 hercynium joined
Coke I recommend that any translated docs go under docs/fr_FR/ or something equally lame. 19:10
dalek rrot: 9d14f6b | NotFound++ | examples/nci/ls.pir:
a bit more portable fix for nci example ls.pir, WFM in amd64 and i386 linux, TT #1180
 19:11
19:11 dngor joined
cotto_work Coke: good idea. The more obscure they are, the less we'll think about how quickly they'll become outdated. 19:12
19:17 theory joined 19:35 rfw joined 20:16 jan left 20:21 jan joined
Coke cotto_work: I was actually being serious. ;) 20:31
rather than having a proliferation of side-by-side docs.
NotFound Don't we have a wiki or something? 20:35
whiteknight parrot.org should be back up 20:36
OSUOSL++
Coke NotFound: was that in re: translated docs? 20:39
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')
NotFound: should our primary docs go in the wiki?
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
Coke I'll be happy to work on that bit of infrastructure, given translated docs. 20:42
NotFound Coke: I, for one, switch to english or even french wherever I can better that facing bad, inacurate and outdated translations. 20:43
whiteknight NotFound: must be nice to be multi-lingual 20:46
NotFound whiteknight: yes, is useful, even not being good at almost any. 20:51
whiteknight NotFound: I took 4 years of Latin in school. I've forgotten most of it 20:52
I don't suspect we have any Latin-speaking users anyway
jnthn School turned out to be a bad place to learn languages. Or in my experiene anyway.
*experience
NotFound whiteknight: the problem with Latin is the lack of native teachers. 20:53
Same as with C.
Coke whiteknight: aliquam. 20:56
jnthn: it's an ok place to learn, but if you don't do anything with it outside of school, you're SOL. 20:57
jnthn Coke: Yeah, I guess that was the real issue. 20:58
Coke: Though the pace was pretty slow/unchallenging where I was at too.
They skimped on grammar badly too.
Because it's "too hard" or something. 20:59
Coke ooh, google translate now has latin 21:00
jnthn: crappy school.
sorear classical latin or 21st century latin?
Coke sorear: it just says "latin". Have fun experimenting.
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.
atrodo sorear> There's a 21st century latin?
Coke yah, it's very much like learning a programming language at school.
jnthn: standardized testing definitely has pros and cons. 21:02
NotFound atrodo: sure, the Vatican uses it.
atrodo NotFound> I always thought there was no difference. Least that's what my latin teacher lead me to believe 21:04
21:04 theory left
NotFound atrodo: for example, Classic Latin has no word for photocopy ;) 21:07
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:08
NotFound Can someone try examples/nci/ls.pir in something not i386 nor amd64? 21:11
Coke NotFound: darwin don't count, do it. 21:13
NotFound Coke: test in non-linux is also good. 21:14
21:15 fbrito joined
nopaste "coke" at 192.168.1.3 pasted "for notfound on parrot-latest on darwin/x86" (9 lines) at nopaste.snit.ch/26822 21:16
Coke BOOM.
NotFound Coke: Using current master? 21:18
Ah, latest, ok. 21:19
Coke yes, although rakudo thinks I'm out of date. 21:20
(git-describe is telling me I have an older version, but "git pull" says I'm up to date.)
NotFound According that page developer.apple.com/library/mac/#DO.../man/5/dir 21:22
the struct is not the same as in linux, so no wonder it fails.
21:27 whiteknight left
cotto_work Coke: my mistake. I misinterpreted you as saying the README should go there. 21:29
+1 to your suggestion 21:30
NotFound Added a comment to TT #1180 about the portability problem. 21:38
21:41 lucian joined
dalek nxed: r705 | NotFound++ | trunk/examples/ajax.winxed:
add a workaround for chunked encoding transfer to example ajax
 21:43
21:53 theory joined 21:58 mtk left 22:03 wesjdj left 22:09 donaldh joined
bacek_at_work ~~ 22:29
Coke bacek_at_work: hio.
bacek_at_work aloha, Coke 22:30
Coke what time is it there? 22:31
cotto_work ~~
bacek_at_work aloha, clock?
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
bacek_at_work Coke, 9:30 AM :) 22:32
Thursday
22:32 Matt221 joined 22:54 M_o_C left 22:56 Matt221 left, Matt221 joined 22:57 Hunger left
cotto_work bacek_at_work: what are your thoughts on the opmap_aware_pmcs branch? I saw that you made a couple fixes. 23:08
bacek_at_work cotto_work, wrapping my head around opmapping. Nothing much yet 23:14
cotto_work my blog post might help.
reparrot.blogspot.com/2010/11/what-...ranch.html 23:15
23:16 TypeNameHere_____ joined 23:27 dmalcolm left 23:30 donaldh left 23:33 hudnix joined 23:38 kid51 joined
Matt221 Is anyone else having trouble compiling the embed_api2 branch? 23:44
cotto_work Matt221: building now 23:46
Matt221 I seem to be getting: "make: *** [runtime/parrot/library/PCT/PAST.pbc] Segmentation fault" 23:47
this is on a clean checkout of the latest source
cotto_work Matt221: looks fine 23:48
Matt221 cotto_work: Just did a `make clean` and getting the same problem 23:51
cotto_work did you try reconfig to be sure? clean doesn't get everything. 23:52
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?
Matt221 Last few messages: pastie.org/private/pemwh051tszikvsqhmyc9w 23:56
cotto_work That's odd. What platform are you on? 23:57
Matt221 OS X 23:59
Should I try on Linux in VMware?

Powered by Cro and the Raku® Programming Language.

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

Thank you!