| Time |
S |
Nick |
Message |
| 00:01 |
|
plobsing |
that's the result of me trying to reduce the core ops last year. People writing PIR protested that it was too inconvenient. |
| 00:01 |
|
plobsing |
so the getstd ops stayed |
| 00:02 |
|
bacek |
ParrotInterp.stdfoo_handle methods aren't tested. And doesn't work apparently. |
| 00:02 |
|
cotto_work |
charming |
| 00:03 |
|
whiteknight |
bacek: those methods do work. I use them in Rosella every day |
| 00:04 |
|
whiteknight |
they might not be tested, but they do work |
| 00:05 |
|
nopaste |
"Whiteknight" at 192.168.1.3 pasted "fib benchmark with new Rosella Memoize library" (44 lines) at http://nopaste.snit.ch/39231 |
| 00:06 |
|
whiteknight |
(abrupt change of topic) |
| 00:12 |
|
soh_cah_toa |
so i've been editing a lot of the docs in /docs/dev. is there a max line length i should abide by? it looks like there is |
| 00:14 |
|
whiteknight |
I think it's 78 |
| 00:14 |
|
whiteknight |
78 or 80 |
| 00:14 |
|
aloha |
94 |
| 00:14 |
|
whiteknight |
damnit |
| 00:14 |
|
soh_cah_toa |
why thank you aloha |
| 00:17 |
|
soh_cah_toa |
it also looks like they all should have a blank line at the end as well |
| 00:17 |
|
cotto_work |
soh_cah_toa: run make codingstd_tests and it'll yell at you as needed |
| 00:18 |
|
cotto_work |
If it doesn't complain about something we don't like and could reasonably detect, that's a bug. |
| 00:18 |
|
kid51 |
soh_cah_toa: In response to your question: http://tinyurl.com/3foqrn6 |
| 00:19 |
|
cotto_work |
I'd like to see a gsoc project to update all of our documentation. I don't think it'd take a whole summer, but it'd be nice to get that Augean stable cleaned out. |
| 00:19 |
|
soh_cah_toa |
that's what i've been doing actually |
| 00:20 |
|
cotto_work |
soh_cah_toa++ |
| 00:20 |
|
cotto_work |
soh_cah_toa++ |
| 00:20 |
|
cotto_work |
soh_cah_toa++ |
| 00:20 |
|
cotto_work |
we have too many lies and half-truths |
| 00:21 |
|
soh_cah_toa |
i've been fixing some grammar issues, format code errors, abbreviations used before explaining what it stands for, etc. |
| 00:21 |
|
soh_cah_toa |
also, you don't need =cut at the end if there's no code right? just a pod file |
| 00:21 |
|
cotto_work |
soh_cah_toa: I encourage you to try to match the docs to the code and ask (or update it yourself) if you see any discrepancies. |
| 00:22 |
|
cotto_work |
soh_cah_toa: podchecker can tell you that. |
| 00:22 |
|
soh_cah_toa |
ok |
| 00:22 |
|
soh_cah_toa |
match the docs to what code? |
| 00:22 |
|
cotto_work |
whatever code the docs cover |
| 00:23 |
|
cotto_work |
e.g. if you're reading about pbc, check out the packfile code and try to figure out if it does what the docs say |
| 00:23 |
|
soh_cah_toa |
i see, okay |
| 00:24 |
|
soh_cah_toa |
do they all need they vim comments at the end? e.g. expandtab, shiftwidth, etc. b/c some do and some don't |
| 00:24 |
|
soh_cah_toa |
*the |
| 00:24 |
|
nopaste |
"kid51" at 192.168.1.3 pasted "t/src/extend_vtable.t: FAIL on Darwin/PPC with gcc for cc, g++ for link and ld" (101 lines) at http://nopaste.snit.ch/39238 |
| 00:25 |
|
cotto_work |
soh_cah_toa: which ones? We have a test that's supposed to make sure the codas are present. |
| 00:26 |
|
soh_cah_toa |
docs/dev/c_functions.pod |
| 00:26 |
|
soh_cah_toa |
docs/dev/headerizer.pod |
| 00:26 |
|
soh_cah_toa |
docs/dev/infant.pod |
| 00:26 |
|
soh_cah_toa |
a few others i think too |
| 00:27 |
|
soh_cah_toa |
some aren't all the same. for instance, some have tw=78 others don't |
| 00:28 |
|
soh_cah_toa |
there's also a lot of broken links in infant.pod. what should i do about those? |
| 00:28 |
|
cotto_work |
docs/pdds/pdd07_codingstd.pod specifies which files should have which codas |
| 00:28 |
|
nopaste |
"kid51" at 192.168.1.3 pasted "t/src/extend_vtable.t: FAIL on Darwin/PPC with gcc for cc, g++ for link and ld" (113 lines) at http://nopaste.snit.ch/39239 |
| 00:28 |
|
soh_cah_toa |
oh good |
| 00:29 |
|
cotto_work |
I'm not sure that file is still useful. bacek, should we nuke docs/dev/infant.pod? |
| 00:31 |
|
bacek |
cotto_work, I think it can stay. We are using "Variant 1 - C stack walking" |
| 00:32 |
|
cotto_work |
bacek: ok |
| 00:32 |
|
soh_cah_toa |
docs/pdds/pdd07_codingstd.pod doesn't specify the correct coda for pod files. only for source code |
| 00:33 |
|
cotto_work |
soh_cah_toa: do any pod files have codas? They're most useful for code. |
| 00:33 |
|
soh_cah_toa |
yeah |
| 00:34 |
|
* cotto_work |
heads home. I'll backscroll. |
| 00:34 |
|
soh_cah_toa |
sure, i gotta eat dinner anyway |
| 00:35 |
|
kid51 |
I doubt we need codas for .pod files. If the formatting is bad, it's usually self-evident. 'pochecker %' gets most (but not all) other problems. |
| 00:35 |
|
kid51 |
we need codas for .pl .pir .pasm .c |
| 00:42 |
|
|
bubaflub joined #parrot |
| 00:45 |
|
|
khisanth_ joined #parrot |
| 00:47 |
|
|
Khisanth left #parrot |
| 00:51 |
|
soh_cah_toa |
kid51: so should i remove the codas from pod files, then? |
| 00:54 |
|
kid51 |
Well, if they're there, please leave them. |
| 00:54 |
|
soh_cah_toa |
okay |
| 00:54 |
|
kid51 |
Maybe they serve some purpose of which I am not fully aware. |
| 00:55 |
|
kid51 |
After all, we know that the major problem with the docs is content, not form ;-) |
| 00:55 |
|
soh_cah_toa |
if that's the case then it must be a MAJOR problem |
| 00:57 |
|
cotto |
~~ |
| 00:58 |
|
|
mikehh joined #parrot |
| 00:59 |
|
dalek |
parrot/jit_prototype: cf79a9f | bacek++ | t/compilers/opsc/21-jit-files.t: |
| 00:59 |
|
dalek |
parrot/jit_prototype: Add proper unittest for "end-to-end" jitter testing. |
| 00:59 |
|
dalek |
parrot/jit_prototype: review: https://github.com/parrot/parr[…]commit/cf79a9fa73 |
| 00:59 |
|
dalek |
parrot/jit_prototype: 8496f10 | bacek++ | t/compilers/opsc/data/03.pir: |
| 00:59 |
|
dalek |
parrot/jit_prototype: Embed expected results into test. |
| 00:59 |
|
dalek |
parrot/jit_prototype: review: https://github.com/parrot/parr[…]commit/8496f10ae7 |
| 00:59 |
|
dalek |
parrot/jit_prototype: 9de7241 | bacek++ | t/compilers/opsc/ (5 files): |
| 00:59 |
|
dalek |
parrot/jit_prototype: Add expected results and enable more tests |
| 00:59 |
|
dalek |
parrot/jit_prototype: review: https://github.com/parrot/parr[…]commit/9de72414e9 |
| 00:59 |
|
dalek |
parrot: 756672c | petdance++ | src/gc/gc_gms.c: |
| 00:59 |
|
dalek |
parrot: Fixed PARROT_CAN_RETURN_NULL annotations |
| 00:59 |
|
dalek |
parrot: review: https://github.com/parrot/parr[…]commit/756672c152 |
| 01:02 |
|
dalek |
parrot/jit_prototype: 320a8e7 | bacek++ | t/compilers/opsc/21-jit-files.t: |
| 01:02 |
|
dalek |
parrot/jit_prototype: Don't recreate Ops::File for each test. |
| 01:02 |
|
dalek |
parrot/jit_prototype: review: https://github.com/parrot/parr[…]commit/320a8e7770 |
| 01:07 |
|
kid51 |
bacek: Does functionality in the jit_prototype branch depend on having a sufficiently modern LLVM? |
| 01:08 |
|
bacek |
kid51, 2.7 at least |
| 01:12 |
|
mikehh |
bacek: I am setting up Kubuntu 11.04 amd64 beta, I have installed LLVM 2.8, will that work? |
| 01:13 |
|
mikehh |
bacek: IOW what do I need to do to test the branches |
| 01:14 |
|
kid51 |
mikehh: that should work |
| 01:14 |
|
kid51 |
you just check them out and run them like any other branches |
| 01:15 |
|
kid51 |
(assuming bacek got rid of hard-coding 2.7 in certain locations) |
| 01:15 |
|
mikehh |
do I need to specify any Configure options? |
| 01:15 |
|
kid51 |
No. |
| 01:15 |
|
kid51 |
Unless you specifically want to build without llvm |
| 01:15 |
|
kid51 |
perl Configure.pl --help |
| 01:16 |
|
bacek |
mikehh, try Configure.pl --llvm-config=llvm-config-2.8 |
| 01:17 |
|
mikehh |
'k will give it a try when I have everything set up - I doubt it will be soon, need some sleep first :-} |
| 01:21 |
|
|
lucian left #parrot |
| 01:27 |
|
|
woosley joined #parrot |
| 02:00 |
|
|
whiteknight left #parrot |
| 02:14 |
|
soh_cah_toa |
can anyone recommend an article or document i can read to get started w/ nqp? |
| 02:15 |
|
kid51 |
soh_cah_toa: If you find one, let me know too! :-) |
| 02:16 |
|
cotto |
soh_cah_toa, I go for its test suite. It covers most of the basics in a fairly minimalist way. |
| 02:16 |
|
soh_cah_toa |
where's that? |
| 02:16 |
|
plobsing |
soh_cah_toa: nqp is mostly (strictly?) a subset of Perl 6. IIUC, most of the basic perl 6 stuff should work. |
| 02:17 |
|
soh_cah_toa |
yeah, i never thought about that. i do have my perl 6 and parrot essentials book |
| 02:17 |
|
cotto |
I don't know how up-to-date that'll be. |
| 02:18 |
|
cotto |
It'll probably help you get the basic idea of how Perl 6 works. |
| 02:18 |
|
bubaflub |
soh_cah_toa: http://perlgeek.de/blog-en/ has some perl5 to perl6 posts |
| 02:19 |
|
bubaflub |
i believe that's moritz++ 's blog |
| 02:19 |
|
cotto |
yes. That's helpful. |
| 02:21 |
|
soh_cah_toa |
yeah, this is pretty good |
| 02:27 |
|
bubaflub |
you can also pop over to #perl6 on freenode and ask there - they're pretty friendly and helpful |
| 02:29 |
|
soh_cah_toa |
good |
| 02:31 |
|
bubaflub |
sorear over on #perl6 recommended looking at squaak |
| 02:34 |
|
soh_cah_toa |
it looks like squaak is for compiling hll's into pir |
| 02:40 |
|
cotto |
squaak is an example hll |
| 02:41 |
|
soh_cah_toa |
oh okay |
| 02:44 |
|
|
khisanth_ is now known as Khisanth |
| 02:44 |
|
|
kid51 left #parrot |
| 02:50 |
|
|
dcolish left #parrot |
| 02:51 |
|
sorear |
cotto: isn't squaak implemented in nqp? |
| 02:52 |
|
cotto |
sorear, yes |
| 02:53 |
|
sorear |
that's why I'm suggesting it |
| 02:53 |
|
sorear |
the squaak tutorial examines a NQP program |
| 02:54 |
|
soh_cah_toa |
oh good |
| 03:00 |
|
bubaflub |
sorear++ |
| 03:23 |
|
|
bubaflub left #parrot |
| 03:35 |
|
|
soh_cah_toa left #parrot |
| 03:49 |
|
|
mikehh left #parrot |
| 03:52 |
|
|
mtk left #parrot |
| 03:58 |
|
|
mtk joined #parrot |
| 04:12 |
|
|
bubaflub joined #parrot |
| 04:22 |
|
|
bubaflub left #parrot |
| 04:52 |
|
|
theory left #parrot |
| 05:33 |
|
|
mtk left #parrot |
| 06:16 |
|
|
fperrad joined #parrot |
| 06:34 |
|
|
particle left #parrot |
| 06:35 |
|
|
particle joined #parrot |
| 06:42 |
|
|
Kulag left #parrot |
| 06:43 |
|
|
Kulag joined #parrot |
| 06:44 |
|
|
fperrad_ joined #parrot |
| 06:47 |
|
|
fperrad left #parrot |
| 06:47 |
|
|
fperrad_ is now known as fperrad |
| 07:16 |
|
|
dcolish joined #parrot |
| 07:50 |
|
|
dodathome joined #parrot |
| 07:52 |
|
|
woosley left #parrot |
| 09:26 |
|
|
cgaertner joined #parrot |
| 09:26 |
|
cgaertner |
hello #parrot |
| 09:41 |
|
|
bacek left #parrot |
| 10:08 |
|
|
benabik_ joined #parrot |
| 10:09 |
|
|
benabik left #parrot |
| 10:09 |
|
|
benabik_ is now known as benabik |
| 10:12 |
|
|
lucian joined #parrot |
| 10:13 |
|
|
jsut_ joined #parrot |
| 10:15 |
|
|
rohit_nsit08 joined #parrot |
| 10:18 |
|
|
jsut left #parrot |
| 10:30 |
|
|
bacek joined #parrot |
| 10:52 |
|
|
rohit_nsit08 left #parrot |
| 10:54 |
|
lucian |
'morning |
| 10:54 |
|
lucian |
well, it's 12 here so not really |
| 10:56 |
|
|
benabik_ joined #parrot |
| 10:56 |
|
|
benabik left #parrot |
| 10:56 |
|
|
benabik_ is now known as benabik |
| 11:00 |
|
|
benabik_ joined #parrot |
| 11:02 |
|
|
benabik left #parrot |
| 11:02 |
|
|
benabik_ is now known as benabik |
| 11:08 |
|
|
rohit_nsit08 joined #parrot |
| 11:16 |
|
moritz |
lucian: regarding your mail to parrot-dev... |
| 11:16 |
|
lucian |
moritz: yes? |
| 11:16 |
|
moritz |
lucian: 6model is generic enough to do what you want |
| 11:16 |
|
moritz |
lucian: you just won't get the same benefits from at as a Perl 6 compiler does |
| 11:17 |
|
lucian |
moritz: ok, cool. that's the gist of what everyone's beey saing |
| 11:17 |
|
lucian |
what benefits? |
| 11:17 |
|
moritz |
well |
| 11:17 |
|
moritz |
in Perl 6, attributes are declared |
| 11:17 |
|
moritz |
so an attribute $!foo can be compiled to a slot number |
| 11:18 |
|
moritz |
and if the attribute has a native type, it can be stored inline the object |
| 11:18 |
|
lucian |
and 6model has optimisations for that |
| 11:18 |
|
moritz |
correct |
| 11:18 |
|
lucian |
hmm. well, there are a lot of techniques to achieve similar effects in python/js |
| 11:18 |
|
lucian |
substitute "a lot" for "a couple" |
| 11:19 |
|
lucian |
v8 calls them hidden classes, PyPy has something more general |
| 11:19 |
|
moritz |
even if you don't use them, 6model gives you a convenient way to write metaclasses |
| 11:19 |
|
lucian |
does 6model want to be more general? or will non-perl6 be a second-class citizen forever |
| 11:19 |
|
lucian |
metaclasses are trivial in python's object system, can't get more convenient than that really |
| 11:21 |
|
cgaertner |
lucian: as I understand it, python's object model on 6model wouldn't be second class - it just would not make use of all of its features... |
| 11:21 |
|
|
whiteknight joined #parrot |
| 11:21 |
|
lucian |
ch |
| 11:21 |
|
lucian |
cgaertner: i get that. but there are plenty of other features that python's object model could make use of |
| 11:22 |
|
cgaertner |
andwhich of these are currently not in 6model? |
| 11:23 |
|
lucian |
mainly shared structure classes |
| 11:24 |
|
lucian |
or "hidden classes" as v8 calls them |
| 11:24 |
|
lucian |
it's a non-issue for perl6 because it's objects appear to be very static |
| 11:26 |
|
lucian |
moritz: cgaertner: this sort of thing http://morepypy.blogspot.com/2[…]thon-objects.html |
| 11:26 |
|
lucian |
it's a bit like declared slots, but better |
| 11:28 |
|
moritz |
lucian: 6model is generic already |
| 11:28 |
|
moritz |
lucian: jnthn has also implement Perl 6 specific things, but those aren't required |
| 11:28 |
|
lucian |
moritz: right. so conceivably i could implement python3-specific things? |
| 11:29 |
|
moritz |
lucian: sure |
| 11:29 |
|
lucian |
moritz: and how hard is that? |
| 11:29 |
|
moritz |
lucian: I don't know |
| 11:29 |
|
whiteknight |
that's the crux |
| 11:30 |
|
whiteknight |
we need to figure out what the effort required there would be |
| 11:30 |
|
moritz |
there's just one way to find out: dig into the sources |
| 11:30 |
|
lucian |
ok. actually, "hidden classes" or maps or w/e you want to call them would benefit other languages as well |
| 11:31 |
|
lucian |
whiteknight: btw, i shan't have time today for that digging |
| 11:31 |
|
whiteknight |
no worries |
| 11:43 |
|
rohit_nsit08 |
whiteknight: hi |
| 11:43 |
|
whiteknight |
good morning rohit_nsit08 |
| 11:43 |
|
rohit_nsit08 |
lucian: hi |
| 11:43 |
|
lucian |
hi |
| 11:43 |
|
rohit_nsit08 |
lucian: read your proposal, fantastic :-) |
| 11:43 |
|
lucian |
glad you like it. i have a 'meh' attitude towards it |
| 11:44 |
|
plobsing |
lucian: the article you linked to describes parrot's current class scheme pretty well |
| 11:44 |
|
lucian |
plobsing: really? i had the impression classes weren't even objects |
| 11:45 |
|
plobsing |
lucian: they have a slots lookup mechanism and instances have an array of attributes |
| 11:46 |
|
lucian |
plobsing: hmm |
| 11:54 |
|
|
cgaertner left #parrot |
| 11:54 |
|
|
Patterner left #parrot |
| 11:55 |
|
|
Psyche^ joined #parrot |
| 11:55 |
|
|
Psyche^ is now known as Patterner |
| 11:55 |
|
|
lateau joined #parrot |
| 11:56 |
|
|
lateau left #parrot |
| 11:56 |
|
|
lateau joined #parrot |
| 12:02 |
|
|
cgaertner joined #parrot |
| 12:04 |
|
|
benabik_ joined #parrot |
| 12:04 |
|
dalek |
parrot/jit_prototype: 84e3931 | bacek++ | src/pmc/parrotinterpreter.pmc: |
| 12:04 |
|
dalek |
parrot/jit_prototype: Implement ParrotInterpeter.mark. It's required to be child interpreter independent from parent in terms of memory management. |
| 12:04 |
|
dalek |
parrot/jit_prototype: review: https://github.com/parrot/parr[…]commit/84e393179b |
| 12:04 |
|
dalek |
parrot/jit_prototype: 226e5bb | bacek++ | src/dynpmc/llvm_engine.pmc: |
| 12:04 |
|
dalek |
parrot/jit_prototype: Don't waste space for attributes. Store LLVMExecutionEngine directly in PMC_data. |
| 12:04 |
|
dalek |
parrot/jit_prototype: review: https://github.com/parrot/parr[…]commit/226e5bbeb4 |
| 12:05 |
|
dalek |
parrot/jit_prototype: 5d7a091 | bacek++ | t/compilers/opsc/21-jit-files.t: |
| 12:05 |
|
dalek |
parrot/jit_prototype: Reorganize logical blocks in test as preparation for more-than-one-sub JITting. |
| 12:05 |
|
dalek |
parrot/jit_prototype: review: https://github.com/parrot/parr[…]commit/5d7a0910ab |
| 12:05 |
|
dalek |
parrot/jit_prototype: 6ba48b4 | bacek++ | compilers/opsc/src/Ops/JIT.pm: |
| 12:05 |
|
dalek |
parrot/jit_prototype: Resurrect keep_going flag with handling "branch" and "jump" ops. |
| 12:05 |
|
dalek |
parrot/jit_prototype: review: https://github.com/parrot/parr[…]commit/6ba48b4d26 |
| 12:06 |
|
|
benabik left #parrot |
| 12:06 |
|
|
benabik_ is now known as benabik |
| 12:24 |
|
dalek |
Rosella/gh-pages: 4aec279 | Whiteknight++ | / (16 files): |
| 12:24 |
|
dalek |
Rosella/gh-pages: conflict |
| 12:24 |
|
dalek |
Rosella/gh-pages: review: https://github.com/Whiteknight[…]commit/4aec279f30 |
| 12:24 |
|
dalek |
Rosella: ca4183b | Whiteknight++ | / (4 files): |
| 12:24 |
|
dalek |
Rosella: fixes for Path class move |
| 12:24 |
|
dalek |
Rosella: review: https://github.com/Whiteknight[…]commit/ca4183b4b1 |
| 12:24 |
|
dalek |
Rosella: 92ae143 | Whiteknight++ | / (4 files): |
| 12:24 |
|
dalek |
Rosella: Add memoize to the build. Fix it so it builds, and at least part of it runs. Add in a benchmark which shows the performance difference between a naive recursive fibonacci, and a version using a memoized Y combinator |
| 12:24 |
|
dalek |
Rosella: review: https://github.com/Whiteknight[…]commit/92ae14312d |
| 12:24 |
|
dalek |
Rosella: debb3fc | Whiteknight++ | / (10 files): |
| 12:24 |
|
dalek |
Rosella: Redo the memoizer cache system. Add in a proxy-based memoization solution in addition to the 'simple' versions |
| 12:24 |
|
dalek |
Rosella: review: https://github.com/Whiteknight[…]commit/debb3fcafa |
| 12:24 |
|
dalek |
Rosella: 601bc6a | Whiteknight++ | benchmarks/memoize/proxy.winxed: |
| 12:24 |
|
dalek |
Rosella: Add in a benchmark showing the performance of simple memoizer vs proxy-based. proxy-based is approx 60% slower, but does add more features |
| 12:24 |
|
dalek |
Rosella: review: https://github.com/Whiteknight[…]commit/601bc6a851 |
| 12:33 |
|
cgaertner |
is it correct that the flag PObj_is_object_FLAG (which decides whether pmc attribute access goes throuh the vtable get_attr/set_attr functions or through the attributes structure) is dynamic, ie modifyable at runtime? |
| 12:35 |
|
cgaertner |
atupid question, I guess: if it's not, there would be no need for pmc2c to generate attribute accessor macros |
| 12:35 |
|
cgaertner |
^stupid |
| 13:00 |
|
|
kid51 joined #parrot |
| 13:04 |
|
|
ambs joined #parrot |
| 13:10 |
|
cgaertner |
the question wasn't as pointless as I thought |
| 13:10 |
|
cgaertner |
what I really need to know is whether PObj_is_object_FLAG can change during a PMC's lifetime |
| 13:11 |
|
whiteknight |
cgaertner: yes, it should be modifiable at runtime |
| 13:11 |
|
whiteknight |
cgaertner: I don't think there's a PIR opcode to do it, so you would need to do it internally |
| 13:12 |
|
whiteknight |
cgaertner: what are you trying to do with it? |
| 13:13 |
|
cgaertner |
whiteknight: I want to be able to poke into parrot's guts from gobject so that I could for example write the Vala-bindings for Rakudo in Vala |
| 13:14 |
|
whiteknight |
ok |
| 13:14 |
|
cgaertner |
therefore I need a gobject extension api |
| 13:14 |
|
cgaertner |
it would have been nice if a pmc could not suddenly becom an object |
| 13:14 |
|
whiteknight |
cgaertner: there are macros to set those flags. PObj_is_object_SET and PObj_is_object_CLEAR |
| 13:14 |
|
whiteknight |
oh, you don't want that flag to change? In current Parrot, it doesn't |
| 13:15 |
|
whiteknight |
well, unless the PMC is garbage-collected and recycled to something that isn't an object |
| 13:15 |
|
cgaertner |
right, if it does not change, I can have a GParrotObject subclass of GParrotPMC, and non-object pmcs can't sudeenly become objects |
| 13:16 |
|
cgaertner |
that way, I would only need to check for object-ness once when the PMC passes the boundary into gobject, at not on each access |
| 13:16 |
|
whiteknight |
checking flags is an inexpensive operation |
| 13:16 |
|
lucian |
perhaps it's just me, but i'd find being able to consume gobject more interesting |
| 13:17 |
|
cgaertner |
lucian: yes, but that gonna be my gsoc proposal - if I do all the work now, I can't get paid for that ;) |
| 13:18 |
|
lucian |
heh. sure you can :) fiddle with the dates in git commits |
| 13:18 |
|
cgaertner |
whiteknight: the operation may be inexpensive, but the interface won't be as nice |
| 13:18 |
|
whiteknight |
cgaertner: okay. Good interfaces are fine. I'm just making sure you're not optimizing prematurely |
| 13:18 |
|
lucian |
cgaertner: also, i'm not sure a complete parrot-gobject-introspection can be written in 3 months anyway :) |
| 13:19 |
|
cgaertner |
lucian: that might well be the case, but didn't the python bindings also start as a gsoc project? |
| 13:20 |
|
lucian |
cgaertner: i don't know, perhaps :) |
| 13:23 |
|
cgaertner |
whiteknight: I also plan to register pmc attributes as gobject properties, and it makes sense to put that logis into GParrotObject instead of GParrotPMC |
| 13:23 |
|
cgaertner |
the latter gives low-level access, the former is roughly what is exposed to HLLs |
| 13:24 |
|
cgaertner |
and that means I only need to register attributes which correspond to nativa parrot types |
| 13:24 |
|
cgaertner |
which is actually the only way this can sanely work as gobject properties must have their types registered with gtype |
| 13:25 |
|
cgaertner |
whiteknight: if it won't break existing code, I'm going to assume that object-ness is constant over a pmc's lifetime |
| 13:28 |
|
dalek |
Rosella/gh-pages: 7126d75 | Whiteknight++ | libraries/future.md: |
| 13:28 |
|
dalek |
Rosella/gh-pages: add memoize library to listing |
| 13:28 |
|
dalek |
Rosella/gh-pages: review: https://github.com/Whiteknight[…]commit/7126d750d3 |
| 13:28 |
|
|
jsut joined #parrot |
| 13:29 |
|
dalek |
Rosella/gh-pages: 5dc8a0f | Whiteknight++ | index.html: |
| 13:29 |
|
dalek |
Rosella/gh-pages: remove index.html file |
| 13:29 |
|
dalek |
Rosella/gh-pages: review: https://github.com/Whiteknight[…]commit/5dc8a0f0ee |
| 13:30 |
|
whiteknight |
cgaertner: that's a good idea. We probably don't want gobject messing with the attributes of built-in PMC types |
| 13:30 |
|
whiteknight |
unless exposed through get_attr_str or set_attr_str, those are considered opaque |
| 13:33 |
|
|
jsut_ left #parrot |
| 13:43 |
|
cgaertner |
btw, this means that I could write the introspection code in Vala, which would however carry a performance penalty because of wrapper-object generation and dynamic type-checking |
| 13:45 |
|
whiteknight |
is there a benefit to doing it in Vala? |
| 13:47 |
|
cgaertner |
whiteknight: using libgirepository from Vala is probably easier that doing it from C or through NCI from any Parrot language |
| 13:47 |
|
whiteknight |
ok |
| 13:50 |
|
cgaertner |
girepository is actually gobject-based, so using Vala would be natural |
| 13:51 |
|
cgaertner |
if speed is a concern, one could also create a low-level wrapper over parrot's APi which treats all types as opaque and still use Vala, I guess |
| 13:55 |
|
whiteknight |
ok |
| 13:57 |
|
cgaertner |
it's just that the GObject API I'm working on can be made far nicer that parrot's C API [more] |
| 13:58 |
|
cgaertner |
for example, the pmc arwpper structure already is larger that apointer because it inherits form GObject (which carries at least an int for type information and a refcount), so it's not really in issue to stick a pointer to the interpreter into that as well |
| 13:58 |
|
cgaertner |
thus, you don't need to always carry the interpreter around yourself: a PMC knows where ir's from |
| 14:00 |
|
cgaertner |
or is there a valid use-case for invoking a PMC's vtable funciton on an interpreter which wasn't used for it's creation? |
| 14:02 |
|
|
kid51 left #parrot |
| 14:02 |
|
whiteknight |
no, the PMC should only be used with the interpreter that owns it |
| 14:02 |
|
lucian |
cgaertner: so you're trying to make parrot objects available for gobject-introspection? |
| 14:02 |
|
whiteknight |
there are very few exceptions to that rule. |
| 14:04 |
|
cgaertner |
lucian: to a certain degree, yes |
| 14:04 |
|
cgaertner |
of course that's only possible for core (ie non-dynamic) pmcs |
| 14:05 |
|
cgaertner |
C code for pmcs is generated, it should be possible to leverage the existing infrastructure |
| 14:06 |
|
lucian |
cgaertner: hmm. it'd be nice if HLLs were gobject-introspectable |
| 14:06 |
|
lucian |
but that's certainly outside the scope of your gsoc |
| 14:09 |
|
cgaertner |
lucian: as far as I know, gi is purely static, so in the general case, that's impossible |
| 14:09 |
|
lucian |
possibly |
| 14:09 |
|
cgaertner |
however, you can get access to HLLs through parrot's api |
| 14:13 |
|
|
lateau left #parrot |
| 14:15 |
|
|
jrtayloriv joined #parrot |
| 14:19 |
|
cgaertner |
btw, who would be willing to mentor the project? the proposal template ask for that information, I I don't remeber anyone actually mentioning that... |
| 14:30 |
|
|
hudnix left #parrot |
| 14:41 |
|
|
hudnix joined #parrot |
| 14:51 |
|
dalek |
winxed: r918 | NotFound++ | trunk/winxedst1.winxed: |
| 14:51 |
|
dalek |
winxed: use a specific class for argument modifiers |
| 14:51 |
|
dalek |
winxed: review: http://code.google.com/p/winxe[…]urce/detail?r=918 |
| 14:55 |
|
|
JimmyZ joined #parrot |
| 15:07 |
|
JimmyZ |
good evening, #parrot |
| 15:12 |
|
dalek |
winxed: r919 | NotFound++ | trunk/winxedst1.winxed: |
| 15:12 |
|
dalek |
winxed: use a specific class for parameter modifiers |
| 15:12 |
|
dalek |
winxed: review: http://code.google.com/p/winxe[…]urce/detail?r=919 |
| 15:15 |
|
|
theory joined #parrot |
| 15:22 |
|
dalek |
winxed: r920 | NotFound++ | trunk/pir/winxed_compiler.pir: |
| 15:22 |
|
dalek |
winxed: update installable compiler |
| 15:22 |
|
dalek |
winxed: review: http://code.google.com/p/winxe[…]urce/detail?r=920 |
| 15:42 |
|
|
kid51 joined #parrot |
| 16:00 |
|
|
bubaflub joined #parrot |
| 16:15 |
|
|
JimmyZ left #parrot |
| 16:18 |
|
cotto |
~~ |
| 16:20 |
|
|
theory left #parrot |
| 16:29 |
|
|
kid51 left #parrot |
| 16:32 |
|
|
ambs_ joined #parrot |
| 16:32 |
|
|
ambs left #parrot |
| 16:32 |
|
|
ambs_ is now known as ambs |
| 16:38 |
|
* cgaertner |
just sent a mail asking for likely mentors and a revised project outline to parrot-dev |
| 16:47 |
|
|
lucian left #parrot |
| 16:55 |
|
* cgaertner |
is gone for today, be back tomorrow |
| 16:55 |
|
|
cgaertner left #parrot |
| 17:01 |
|
|
Eduardow left #parrot |
| 17:12 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: 8500125 | Whiteknight++ | config/gen/makefiles/root.in: |
| 17:12 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: fix some deps in the makefile so that checkdepend.t can shut up |
| 17:12 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parr[…]commit/85001259b9 |
| 17:18 |
|
|
Eduardow joined #parrot |
| 17:37 |
|
|
Eduardow left #parrot |
| 17:42 |
|
rohit_nsit08 |
whiteknight:hi, sorry for absence from the irc, now i have finished some work on nodejs and today compiled some scripts using 'cafe' and winxed , so i can now start my work on cafe now :-) |
| 17:43 |
|
whiteknight |
rohit_nsit08: awesome! I'm glad to hear you are making progress |
| 17:43 |
|
NotFound |
rohit_nsit08: welcome to the Winxed fanbase ;) |
| 17:43 |
|
rohit_nsit08 |
whiteknight: thanks, had to dig a lot for it, :-) loved it |
| 17:43 |
|
rohit_nsit08 |
whiteknight: u play cricket? |
| 17:44 |
|
rohit_nsit08 |
whiteknight: sorry, i'm very happy today, india has just won cricket world cup after 28 years |
| 17:44 |
|
whiteknight |
rohit_nsit08: no cricket. I did hear that india beat pakistan in a nice match last week |
| 17:44 |
|
whiteknight |
oh, I didn't know they won the cup |
| 17:44 |
|
rohit_nsit08 |
whiteknight: yup, just 5 minutes ago :-) |
| 17:45 |
|
whiteknight |
very nice |
| 17:45 |
|
whiteknight |
now we have your undivided attention :) |
| 17:46 |
|
rohit_nsit08 |
whiteknight: ya, but i saw just last half an hour, before that i was on nodejs irc :-) knowing their api , |
| 17:48 |
|
rohit_nsit08 |
whiteknight: so let's get back to work, now that i'm done with some more work, i'm working on to finish my proposal and will upload it on google today |
| 17:48 |
|
bubaflub |
NotFound: i'm thinking about using Winxed for my NCI bindings for GMP - i might be joining the fanbase as well |
| 17:48 |
|
rohit_nsit08 |
bubaflub: hi |
| 17:49 |
|
bubaflub |
rohit_nsit08: hello |
| 17:49 |
|
NotFound |
Soon we'll be doing the first World Winxed Users convention ;) |
| 17:50 |
|
rohit_nsit08 |
NotFound: :-) |
| 17:52 |
|
whiteknight |
bubaflub: Winxed is to C, like PIR is to ASM |
| 17:52 |
|
whiteknight |
bubaflub: once you start using it, I think you never go back to PIR |
| 17:54 |
|
rohit_nsit08 |
whiteknight: how should i start with making changes in codegen.js of cafe, right now it's generating an AST and converting it back to javascript. pls guide |
| 17:55 |
|
NotFound |
whiteknight: BTW, I've almost finished the the syntax for function call getting multiple return values. |
| 17:57 |
|
|
Eduardow joined #parrot |
| 17:58 |
|
bubaflub |
whiteknight: i'm sold. i'll modify my proposal from PIR/Test::More to Winxed/Rosella |
| 17:59 |
|
tadzik |
whiteknight: how good is the generated code from winxed? |
| 17:59 |
|
rohit_nsit08 |
bubaflub: faced any problem with PIR? |
| 17:59 |
|
bubaflub |
rohit_nsit08: not problems, just very low-level and i have to deal with a lot of stuff that i don't normally |
| 17:59 |
|
rohit_nsit08 |
bubaflub: i am planning to generate PIR code from my javascript compiler |
| 17:59 |
|
bubaflub |
rohit_nsit08: especially when creating and initializing an obejct |
| 18:00 |
|
bubaflub |
rohit_nsit08: that's fine... writing it from scratch / by hand can be tedious |
| 18:01 |
|
rohit_nsit08 |
bubaflub: i have spent some time with PIR, ya it's low level. seemed similar to C . |
| 18:01 |
|
bubaflub |
rohit_nsit08: i'd say a bit lower than that... most of my hacking on Parrot has been in PIR |
| 18:01 |
|
rohit_nsit08 |
bubaflub: any benefits if i switch to winxed? |
| 18:01 |
|
rohit_nsit08 |
winxed is similar to javascript |
| 18:01 |
|
bubaflub |
rohit_nsit08: syntax wise, yes it is. but i'm not sure if there is any benefit |
| 18:02 |
|
bubaflub |
rohit_nsit08: the idea is that eventually the code would get into some form that can be compiled on parrot |
| 18:03 |
|
rohit_nsit08 |
ya that's the main thing, either PIR or winxed all ends to bytecode |
| 18:03 |
|
cotto |
It'd be interesting to build a compiler that generated pbc using our packfile PMCs. |
| 18:04 |
|
|
pranq joined #parrot |
| 18:04 |
|
rohit_nsit08 |
cotto: what are packfile PMCs? |
| 18:04 |
|
cotto |
src/pmc/packfile*.pmc |
| 18:05 |
|
cotto |
a pmc-based interface for dealing with the binary format parrot uses for bytecode |
| 18:05 |
|
benabik |
cotto: I am in the middle of writing a POST->Packfile library GSoC proposal. |
| 18:06 |
|
cotto |
benabik, have you talked with bacek? He has a POST variant that's better suited to packfile generation than the one currently used. |
| 18:06 |
|
benabik |
cotto: Not yet, although I'm guessing that's what the nqp_pct branch is? |
| 18:07 |
|
cotto |
benabik, iirc yes |
| 18:07 |
|
rohit_nsit08 |
cotto: packfile object is a parser? what does it parses to ? |
| 18:08 |
|
cotto |
rohit_nsit08, it's not a parser. |
| 18:08 |
|
tadzik |
wow, the code winxed generates is awesome |
| 18:09 |
|
tadzik |
at least for the examples I tried |
| 18:10 |
|
rohit_nsit08 |
cotto:sorry, i'm reading packfile.pmc .i read the class implements a packfile object which is a parser and serializer . |
| 18:10 |
|
cotto |
ah. I see where the confusion came from. |
| 18:10 |
|
benabik |
rohit_nsit08: It's a parser in that it can read in a .pbc file and give an interface to its internals. |
| 18:12 |
|
rohit_nsit08 |
benabik: hmm okay, actually i'm new to pbc. Sorry didn't knew that |
| 18:12 |
|
benabik |
rohit_nsit08: Asking questions is how you learn. :-) |
| 18:12 |
|
cotto |
The PMCs are just the interface. Note that set_string_native isn't very long. |
| 18:12 |
|
benabik |
rohit_nsit08: I mostly know that because I've been looking over the docs for a couple hours now. |
| 18:12 |
|
cotto |
Packfile_unpack, which does the work, doesn't live in the PMC code. |
| 18:13 |
|
dalek |
winxed: r921 | NotFound++ | trunk/winxedst1.winxed: |
| 18:13 |
|
dalek |
winxed: experimental syntax in stage 1 to call functions with multiple results: ':(a, b) |
| 18:13 |
|
dalek |
winxed: = something();' |
| 18:13 |
|
dalek |
winxed: review: http://code.google.com/p/winxe[…]urce/detail?r=921 |
| 18:13 |
|
rohit_nsit08 |
benabik: how is pbc different from PIR. |
| 18:14 |
|
rohit_nsit08 |
benabik: i know PIR |
| 18:14 |
|
cotto |
rohit_nsit08, pbc is the binary format that pir compiles to. |
| 18:14 |
|
benabik |
rohit_nsit08: PIR : pbc :: assembler : object code |
| 18:14 |
|
cotto |
(after some desugaring and magic) |
| 18:14 |
|
rohit_nsit08 |
got it . |
| 18:16 |
|
rohit_nsit08 |
i thought PIR is the lowest level and it gets converted into object code, the Pbc part was missing |
| 18:16 |
|
rohit_nsit08 |
thanks |
| 18:16 |
|
benabik |
rohit_nsit08: PBC is basically the object code for Parrot. It stands for Parrot ByteCode (I think) |
| 18:17 |
|
rohit_nsit08 |
yes, that's correct |
| 18:18 |
|
dalek |
TT #2085 created by jkeenan++: Eliminate reliance on any 'tempdir' based on Perl 5's setting |
| 18:18 |
|
dalek |
TT #2085 : http://trac.parrot.org/parrot/ticket/2085 |
| 18:18 |
|
dalek |
TT #1544 closed by jkeenan++: t/profiling/profiling.t fails on darwin |
| 18:18 |
|
dalek |
TT #1544 : http://trac.parrot.org/parrot/ticket/1544 |
| 18:18 |
|
bubaflub |
rohit_nsit08: if you know java there is as good analogy - .java files (which are text files written in the Java language) are compiled to bytecode .class files |
| 18:19 |
|
bubaflub |
rohit_nsit08: just like .class, .pbc is platform independent compiled files |
| 18:19 |
|
bubaflub |
rohit_nsit08: we have multiple languages just like the JVM does, and anything that runs on Parrot written in any languages can be compiled down to a PBC |
| 18:20 |
|
rohit_nsit08 |
bubaflub: thanks, now i have got the whole point. |
| 18:20 |
|
bubaflub |
rohit_nsit08: glad to help. feel free to ask any questions about anything you are confused about. someone here will point ya in the right direction. |
| 18:20 |
|
bubaflub |
rohit_nsit08: ah, so the original question if you should use PIR or Winxed - it doesn't totally matter as long as it compiles correctly... PIR is pretty simple but can be tedious to write since it is so low-level. |
| 18:21 |
|
bubaflub |
rohit_nsit08: for my project i think i'll be using Winxed because it is more convenient. |
| 18:21 |
|
NotFound |
And even more tedious to debug. |
| 18:21 |
|
bubaflub |
rohit_nsit08: but if the code is generated, you might not care about how low-level something is |
| 18:21 |
|
rohit_nsit08 |
yup |
| 18:22 |
|
rohit_nsit08 |
i have decided to stick to PIR , since i know it and keep winxed for an option for future |
| 18:23 |
|
dalek |
winxed: r922 | NotFound++ | trunk/pir/winxed_compiler.pir: |
| 18:23 |
|
dalek |
winxed: update installable compiler |
| 18:24 |
|
dalek |
winxed: review: http://code.google.com/p/winxe[…]urce/detail?r=922 |
| 18:26 |
|
|
bubaflub left #parrot |
| 18:39 |
|
dalek |
winxed: r923 | NotFound++ | trunk/ (3 files): |
| 18:39 |
|
dalek |
winxed: add test for multiple return |
| 18:39 |
|
dalek |
winxed: review: http://code.google.com/p/winxe[…]urce/detail?r=923 |
| 18:44 |
|
|
jrt4 joined #parrot |
| 18:46 |
|
|
jrtayloriv left #parrot |
| 18:52 |
|
|
rohit_nsit08 left #parrot |
| 18:55 |
|
|
bubaflub joined #parrot |
| 18:56 |
|
whiteknight |
tadzik: (sorry about the delay) the PIR generated from Winxed is very good and very efficient |
| 18:56 |
|
whiteknight |
tadzik: winxed does not hide too many details, so the translation is pretty straight-forward |
| 18:57 |
|
tadzik |
yeah, I checked that out. Very nice |
| 19:08 |
|
|
rohit_nsit08 joined #parrot |
| 19:09 |
|
benabik |
Is the OpLib PMC the way to access the opcode tables from inside the VM? I noticed that IMCC uses interp->op_hash from C and was looking for a way to do something similar without C code. |
| 19:10 |
|
sorear |
rule of thumb: whatever way IMCC uses, is the wrong way |
| 19:14 |
|
plobsing |
benabik: having a global hash of ops is wrong |
| 19:15 |
|
plobsing |
you should keep track of the oplibs that are relevant to the compile in progress and perform lookups on those. |
| 19:17 |
|
|
theory joined #parrot |
| 19:19 |
|
benabik |
sorear: I can understand where that rule's coming from, but as far as I can tell IMCC is the only thing that actually generates bytecode right now. |
| 19:20 |
|
sorear |
benabik: there's also PIRATE, but it's rather limited |
| 19:20 |
|
benabik |
plobsing: Fair enough... But is ObLib the right way to do that? And how do dynops get converted to opcode numbers? |
| 19:20 |
|
benabik |
sorear: Oddly enough, searching for "parrot PIRATE" doesn't give very useful links. ;) |
| 19:21 |
|
|
jevin left #parrot |
| 19:21 |
|
plobsing |
IMCC is the only thing that generates PBC right now because IMCC was integrated in a highlander fashion (there can be only one) |
| 19:21 |
|
sorear |
benabik: bacek/pir IIRC |
| 19:22 |
|
benabik |
sorear: 404 from github. parrot/pir ? |
| 19:22 |
|
plobsing |
benabik: OpLib is how you'll want to go about doing that, yes. Ops (dyn- or otherwise) need to be mapped into a segment before they can be used. The PackFilePMC representing the bytecode segment should facilitate this operation. |
| 19:22 |
|
sorear |
benabik: parrot/pir looks correct |
| 19:33 |
|
|
theory left #parrot |
| 19:33 |
|
|
theory joined #parrot |
| 19:35 |
|
rohit_nsit08 |
whiteknight: i'm uploading my final proposal on gsoc site. will be glad if u can have a last look before submitting https://gist.github.com/899803 |
| 19:38 |
|
|
nwellnhof joined #parrot |
| 20:20 |
|
|
jevin joined #parrot |
| 20:26 |
|
whiteknight |
rohit_nsit08: okay, looking now |
| 20:26 |
|
whiteknight |
I'm going to be offline for most of the rest of the afternoon |
| 20:27 |
|
|
dodathome left #parrot |
| 20:27 |
|
whiteknight |
rohit_nsit08: the proposal looks good |
| 20:29 |
|
rohit_nsit08 |
whiteknight: thanks for the reviewing , I'm putting it on mailing list and will finally submit it tomorrow morning. |
| 20:29 |
|
rohit_nsit08 |
whiteknight: can i make any further changes after submitting? |
| 20:44 |
|
benabik |
GSoC 2011 Proposal for Parrot: Bytecode Emitters for POST https://gist.github.com/899867 |
| 20:50 |
|
|
bubaflub left #parrot |
| 20:50 |
|
|
theory left #parrot |
| 20:52 |
|
benabik |
If anyone has any comments on my proposal above, I'll be online for about another half-hour. I'll leave my client open to try to catch any messages after that. I also sent a copy to the parrot-dev list for comments, so e-mail and comments on the gist itself are good. |
| 20:57 |
|
|
pranq left #parrot |
| 21:02 |
|
|
bubaflub joined #parrot |
| 21:08 |
|
|
rohit_nsit08 left #parrot |
| 21:16 |
|
|
clunker9_ joined #parrot |
| 21:17 |
|
rblackwe |
I am in pmichaud talk at Texas Linux Fest |
| 21:18 |
|
rblackwe |
There are ~40 people in here. |
| 21:20 |
|
|
jevin left #parrot |
| 21:21 |
|
sorear |
is that a lot? |
| 21:21 |
|
|
jevin joined #parrot |
| 21:24 |
|
rblackwe |
sorear: I think so |
| 21:24 |
|
rblackwe |
I am very happy with attendence |
| 21:25 |
|
rblackwe |
Even better ... people seem interested |
| 21:27 |
|
benabik |
rblackwe: Sounds awesome. |
| 21:28 |
|
benabik |
Heading off to "be social", whatever that is. |
| 21:32 |
|
|
Eduardow left #parrot |
| 21:37 |
|
|
ambs left #parrot |
| 21:43 |
|
rblackwe |
benabik: Interactive audience too |
| 21:44 |
|
rblackwe |
People are interested enough to ask questions |
| 21:45 |
|
|
bacek left #parrot |
| 21:47 |
|
|
nwellnhof left #parrot |
| 22:07 |
|
|
soh_cah_toa joined #parrot |
| 22:28 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: 52f4632 | plobsing++ | src/packfile/api.c: |
| 22:28 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: [codingstd] c_arg_assert |
| 22:28 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parr[…]commit/52f4632394 |
| 22:28 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: f0010a7 | plobsing++ | src/packfile/api.c: |
| 22:28 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: [codingstd] c_function_docs |
| 22:28 |
|
dalek |
parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parr[…]commit/f0010a7a06 |
| 22:37 |
|
soh_cah_toa |
whiteknight: i'm reworking my gsoc proposal and i have a question. would you recommend doing documentation before or after the coding phase? |
| 22:38 |
|
bubaflub |
soh_cah_toa: if i may be so bold as to suggest you do inline documentation before and during the coding, examples after |
| 22:40 |
|
soh_cah_toa |
bubaflub: yeah, alright. how much time should i reserve for user docs/examples? |
| 22:40 |
|
bubaflub |
soh_cah_toa: that's a tough call. it's been my experience that the docs and tests and other "periphery" type stuff usually takes more time |
| 22:41 |
|
bubaflub |
soh_cah_toa: but it is in some ways more important - if you have that last week open maybe allocate some of that time to a good tutorial or README |
| 22:41 |
|
soh_cah_toa |
bubaflub: well, i think i'm gonna go w/ a test driven development approach w/ failing tests before and passing afterwords |
| 22:42 |
|
bubaflub |
soh_cah_toa: great. that's a good way to ensure you've got the coverage you want and need. i'd say to combine that with documentation driven development - tests and docs before the code is written |
| 22:42 |
|
bubaflub |
soh_cah_toa: that might just be my style, though. your mileage may vary |
| 22:44 |
|
soh_cah_toa |
bubaflub: well, i've never developed as part of a team before so this would be the first time i actually practiced a development process w/ design, docs, test, all the works. any advice will help |
| 22:46 |
|
bubaflub |
soh_cah_toa: sure. i think test driven development is the bee's knees. |
| 22:46 |
|
bubaflub |
soh_cah_toa: but getting use to TDD can sometimes take a bit |
| 22:46 |
|
bubaflub |
soh_cah_toa: for me the impulse is always to just jump into the code |
| 22:46 |
|
soh_cah_toa |
bubaflub: yeah, i know |
| 22:46 |
|
bubaflub |
soh_cah_toa: and the tests (or docs or whatever) is never very glamorous |
| 22:46 |
|
bubaflub |
soh_cah_toa: and it's ok if there is some give and take |
| 22:47 |
|
bubaflub |
soh_cah_toa: i.e. you sometimes start with the tests, sometimes start with the code |
| 22:47 |
|
bubaflub |
soh_cah_toa: as long as in the end there are both good, passing tests and code |
| 22:47 |
|
bubaflub |
soh_cah_toa: at work i've had one line changes that take five minutes to fix |
| 22:47 |
|
bubaflub |
soh_cah_toa: and 45 minutes to test |
| 22:47 |
|
soh_cah_toa |
bubaflub: wow |
| 22:47 |
|
bubaflub |
soh_cah_toa: it may or may not be "worth it" in that kind of environment, but i think it's always good to have more tests |
| 22:47 |
|
bubaflub |
soh_cah_toa: you'll know if you broke something |
| 22:48 |
|
bubaflub |
soh_cah_toa: esp. if you get bug reports - every regression should have a test so you don't keep making the same mistakes |
| 22:48 |
|
soh_cah_toa |
bubaflub: right |
| 22:48 |
|
soh_cah_toa |
bubaflub: i've never had to right documentation outside of inline comments before. are there any articles or books you could recommend for writing technical documentation? |
| 22:49 |
|
bubaflub |
soh_cah_toa: ah, that's tough. yeah, i mean most developers end up dumping stuff into a wiki... and then the information never gets updated and it gets useless. i'd say avoid the wiki route. |
| 22:49 |
|
bubaflub |
soh_cah_toa: also, POD is pretty standard with Perl projects, but it has the nasty tendency of following the API a bit too closely. |
| 22:50 |
|
bubaflub |
soh_cah_toa: a good tutorial will show people step by step exactly what they need to get a project up and running |
| 22:50 |
|
bubaflub |
soh_cah_toa: the Catalyst tutorial or the DBIx::Class intro are both good examples of that kind of doc |
| 22:50 |
|
bubaflub |
soh_cah_toa: i think you can also expect feedback from the community and your mentor to help improve the docs |
| 22:50 |
|
bubaflub |
soh_cah_toa: and you can always bug me if you'd like my opinion |
| 22:51 |
|
soh_cah_toa |
bubaflub: o'reilly has been my best friend in the past. i'm sure they have some good books on technical writing as well |
| 22:51 |
|
bubaflub |
soh_cah_toa: no doubt. it's not particularly my field so i don't have any suggestions off hand. |
| 22:54 |
|
bubaflub |
soh_cah_toa: this is a great parrot tutorial: http://coolnamehere.com/geekery/parrot/learn/ |
| 22:54 |
|
bubaflub |
soh_cah_toa: i'm not suggesting you do something this in-depth (as it could well be outside the scope of a single summer) but the style is engaging |
| 22:54 |
|
bubaflub |
soh_cah_toa: also, he does some TDD in there |
| 22:54 |
|
soh_cah_toa |
bubaflub: i know, i've been reading it religiously. it's a really great tutorial |
| 22:55 |
|
bubaflub |
soh_cah_toa: great. |
| 22:56 |
|
|
Eduardow joined #parrot |
| 23:04 |
|
|
zby_home left #parrot |
| 23:05 |
|
|
benabik_ joined #parrot |
| 23:06 |
|
|
benabik_ left #parrot |
| 23:06 |
|
|
benabik_ joined #parrot |
| 23:40 |
|
|
benabik_ left #parrot |
| 23:40 |
|
|
benabik__ joined #parrot |
| 23:53 |
|
|
benabik_ joined #parrot |
| 23:54 |
|
|
jasonmay left #parrot |
| 23:58 |
|
|
benabik__ left #parrot |
