Parrot 1.0 Released | parrot.org | 380 RTs left!
Set by moderator on 28 March 2009.
dalek rrot: r37880 | coke++ | trunk (3 files):
[t/docs] Fix a bug in headerizer (and its duplicated method) that extracted the non-function declaration '}'
 00:01
00:09 AndyA joined
Coke_afk hopes he didn't just turn into the headerizer expert. :P 00:09
00:17 Chile joined
bacek_ good morning. 00:17
Coke ~~ 00:19
bacek_ I have stupid question: why PBC stored in system-dependent format?.. 00:25
rg i've asked that before. it's so that it can be executed directly without any conversions 00:27
when running on the native platform that is
00:28 shucho_ joined
bacek_ rg: and no one will use it... 00:29
btw, "directly executed" was about opcodes? 00:30
rg maybe i should have said interpreted 00:31
bacek_ then it's easy achievable replacing *cursor++; with something like *(cursor += pbc->header->opsize / sizeof(opcode_t))
more over, pbc->header-opsize will always be constant 00:32
rg well the design is that a pointer has the same size as an integer register aswell as an opcode 00:34
bacek_ ouch... It's.. weird...
why opcode_t-in-the-PBC can't always be uint64_t? 00:36
rg well if you make opcodes smaller than arguments you're quickly running into alignment problems 00:37
bacek_ starring at TT#364
Current design doesn't solve this problem 00:38
rg actually that's currently not reproducibla 00:39
s/bla/ble/
(as i noted in comment 17) 00:40
bacek_ rg: good to know... 00:43
rg unfortunately rurban seems to be otherwise occupied, so there's really nobody working on cross platform testing
bacek_ I found biggest PBC on my box. perl6.pbc. Less than 3 megabytes. Reading it into memory, converting into native format will take, hmm, 10ms? 00:44
214128 ops. 00:46
Coke it's been ages since I looked at the PBC stuff, but I would have expected that if you built the pbc on your own machine, that it would already be in the native format for your platform. 00:47
bacek_ Coke: it is. And I don't understand why. 00:48
I expect to have platform-independent PBC
rg coke: it is, of course. the question is, why jump through hoops with cross platform compatibility when you could just standardize on a single format.
Coke rg: that's a good question. 00:49
bacek_ It's my question! :)
Coke bacek_: that isn't a problem that was going to be fixed 100% before 1.0
rg one argument that was given is speed on the native platform
also, being able to run the code without actually reading it into memory
pmichaud iiuc, all .pbcs are platform independent. It's just that some are more optimized for some platforms than others.
rg pmichaud: that's the theory. in practice, some conversions are not implemented. 00:50
bacek_ pmichaud: technically they are platform dependent...
pmichaud the implementation may be lacking, yes. But that could probably be said about many things in Parrot.
*cough*...UNICODE!...*cough*
Coke bacek_: it's not that it's never going to be fixed.
bacek_ counted at least 8 different supported storage formats of PBC. 00:51
pmichaud *cough*...make install...*cough*
*cough*...mmd...*cough*
rg bacek: more if you also count floats
more like 12
bacek_ rg: ooo.. floats... 5 different floats...
rg parrot only knows about 3 00:52
bacek_ rg: FLOATTYPE_8, _12, 16MIPS, _16AIX, _4 00:54
5
And _16! (Yest, 3 of them are not implemented) 00:55
rg uh where do you see the arch specific types?
bacek_ packfile.h + 31 00:56
rg ah but FLOATTYPE_MAX is 2, so those are not really supported
bacek_ rg: parrot knows about 6, but support only 3... Instead of knowing only 1 "portable" and 1 "system-specific". 00:57
rg well every system i know of knows at least 2: float and double. plus there's usually long double, which may be implemented in software (i.e. slow). 00:58
bacek_ rg: there is one "number" type in PBC. 00:59
system storage after loading can vary
rg i haven't checked what happens if you're trying to load a pbc file with a number (or for that matter integer) type that is too large for the native one. 01:01
can't be good 01:03
01:04 eternaleye joined 01:05 GeJ_ joined
bacek_ rg: only one case supported in PF_fetch_number - messy hack for 12 to 8. casting. 01:06
no, I was wrong. 01:07
dalek rrot: r37881 | jkeenan++ | branches/install_tools (2 files):
Applying patch submitted by wayland, with revision to exclude Perl 5.10-only features.
 01:13
bacek_ anyway, direct interpretation of ops from PBC isn't supported. Or I can find code which doing it. And even if it exists it big abstraction leak... 01:19
rg well the bytecode isn't set in stone. TT 451 (deprecation item) allows you to change pretty much anything you like. 01:23
if you have the time and the energy, i imagine you could push through a different design 01:25
dalek rrot: r37882 | jkeenan++ | branches/install_tools/t/tools/install/01-install_files.t:
Add a self-contained test for create_directories().
 01:27
bacek_ O! Good ticket! 01:30
01:37 Luyt joined
Infinoid hmm 02:16
last time I talked with rurban about that, he didn't seem to like the "1 portable and 1 system-specific" approach
But converting from everything to everything sounds like it will get messy
I still think it would be easier to just convert to/from the local platform, and standardize the bytecode format 02:17
bacek_ Infinoid: it's already messy...
Infinoid sprintf() works for me
bacek_ Infinoid: and one standard bytecode format is what I voting for :) 02:18
Infinoid Me too
bacek_ Infinoid: excellent! There is two of us already 02:19
Infinoid PARROT_NET_DEVEL has been defined since r4381 in 2005. Do we really need that to be conditional? 02:31
Oh, excuse me. It was added in r4381, but it started being defined in r7974, also in 2005. 02:33
bacek_ Infinoid: small embedded platform without networking? Something like tosters?
o wait. It's 21st century. Even toasters have public IP address :) 02:34
Infinoid Not this week. The "nanoparrot" roadmap item won't hit until 3.0
02:35 janus joined
Infinoid You're right, we will eventually want to make it conditional, but hopefully we'll name it something better than "devel" by then 02:35
bacek_ So, just remove it. Or better rename to something like PARROT_NETWORKING_SUPPORT 02:36
Infinoid That looks nice. But it seems out of place in io_private.h 02:37
I'll make a ticket so we can get some more opinions 02:38
dalek rrot: r37883 | jkeenan++ | branches/install_tools/lib/Parrot/Install.pm:
'die' statements don't need a newline. Use lexical variable instead of $_ in two locations.
 02:42
rrot: r37884 | jkeenan++ | branches/install_tools/t/tools/install/01-install_files.t:
Beginning to extend test coverage of Parrot::Install subroutines.
kid51 must sleep 02:45
purl $kid51->sleep(8 * 3600);
Infinoid Is anyone else seeing a parrot crash from t/pmc/codestring.t? 02:47
nopaste "Infinoid" at 75.5.244.171 pasted "SIGBUS in ICU when running t/pmc/codestring.t" (62 lines) at nopaste.snit.ch/16075 02:51
02:52 darbelo joined 03:13 rdice joined 03:15 Andy joined
Infinoid msg pmichaud r37866 causes a SIGBUS here, in t/pmc/codestring.t on linux/x86-64. Please see nopaste.snit.ch/16075 03:25
purl Message for pmichaud stored.
03:39 klapperl joined 04:27 iblechbot joined 04:42 Theory joined 05:01 TiMBuS joined 05:42 TiMBuS joined 05:47 Tene_ joined 06:12 tetragon joined 06:13 flh joined 06:24 uniejo joined 07:08 TiMBuS joined 07:54 masak joined 08:36 mikehh joined 08:51 iblechbot joined 09:03 HG` joined 09:30 HG` joined 09:33 bacek joined
bacek good evening 09:33
purl: msg Infinoid I'm going to implement "pbc_dump.pir" first to get understanding about packfile*.pmc's. And then start implementing writing support. 10:08
purl Message for infinoid stored.
10:13 pjcj joined 10:15 kid51 joined
dalek rrot: r37885 | jkeenan++ | branches/install_tools (2 files):
Tighten scoping of lexical variables inside create_directories(). Add test
 10:36
10:44 bacek joined
dalek rrot: r37886 | jkeenan++ | branches/install_tools (2 files):
Eliminate unreachable condition in create_directories(). Make some variable names more self-documenting.
 10:52
10:58 wayland76 joined
wayland76 kid51: ping 10:59
11:00 ruoso joined 11:04 riffraff joined
dalek rrot: r37887 | jkeenan++ | branches/install_tools (2 files):
Tighten test of variable in install_files(). Test previously untested
 11:12
kid51 wayland76: Good morning
wayland76 Oops, I just figured you weren't around, and sent you an e-mail :) 11:13
Is there something that will help me interpret the link you sent me?
kid51 I have to start getting ready to go to $job.
wayland76 ok 11:14
I'm going to bed anyway, so just reply via e-mail
kid51 It's coverage analysis as performed by Devel::Cover.
wayland76 Oh, ok. I'll get doco on that then. Thanks
kid51 thenceforward.net/parrot/coverage/i...ll-pm.html shows extent to which each statement is covered by the test suite.
shorten kid51's url is at xrl.us/benphg
kid51 Links within that will show you branch and condition coverage. 11:15
Objective is to have test file cover a very high proportion of code.
This will show unreachable conditions, etc.
wayland76 Nice. I like it. The only thing I don't understand is why it says none of lines_to_files is covered, but that could be because of those tests that I had to comment out :) 11:17
kid51 Yeah, let me uncomment them. 11:18
wayland76 Btw, did I say it's safe to run that first lines_to_files test along with any one of the others?
That first test never gets as far as the ARGV assignment, so doesn't cause any problems 11:19
dalek rrot: r37888 | jkeenan++ | branches/install_tools/t/tools/install/01-install_files.t:
Uncommenting test of function.
kid51 Uncommented that test. Refresh your links at thenceforward. 11:20
I haven't yet gotten to tests for lines_to_files(). What did you mean by "... until it's been fixed"? 11:21
Gotta run now. Your patch was a great start and (as you can tell) fired me up to write more tests :-) 11:22
wayland76 Well, I had problems if lines_to_files quit with a "die" statement, and we called it again, it still remembered some of its previous state
This is a bug, but fixing it can be part of that rewrite that I have pending 11:23
I think we probably need to cover lines 125 and 126, but the rest I'm less worried about
bed & 11:24
(oh, and thanks)
11:24 wayland76 left 11:29 cognominal joined 11:44 particle1 joined 12:24 rdice joined 12:36 rg1 joined 12:47 particle2 joined, gryphon joined
Coke_afk heee: 13:19
Coke -> (23:54) From nomaded [have passport, will travel], to random:
- "In 4 days I went from the Camel Book to the Llama Book to the Owl Book to
- hoping O'Reilly has a bunny puppet who sings a song about `stdin`."
13:21 jhorwitz joined
dalek a: 5600806 | (Francois Perrad)++ | config/makefiles/root.in:
[config] update variable names see r37861
 13:31
shorten dalek's url is at xrl.us/benprf
dalek rkdown: fefb80a | (Francois Perrad)++ | config/makefiles/root.in:
[config] update variable names see r37861
 13:35
shorten dalek's url is at xrl.us/benpro
dalek rrot: r37889 | coke++ | trunk/t/codingstd/pod_description.t:
[cage] reference ticket number
 13:37
13:41 HG` joined 13:48 bkuhn joined 13:59 Andy joined
dalek rrot: r37890 | coke++ | trunk/compilers/imcc (3 files):
[t/docs] Add some more stub docs

warns of missing pod, though the c function doc test will warn these are merely boilerplate entries.		 14:07
lscript: a0f9d1f | (Francois Perrad)++ | config/makefiles/root.in:
[config] update variable names see r37861
 14:28
shorten dalek's url is at xrl.us/benpw7
Coke pirc? 14:29
purl pirc is kjs's
Coke kjs? 14:30
purl i guess kjs is Klaas-Jan Stol <mailto:parrotcode@gmail.com> from The Netherlands or KHTML (read Safari/Koqueror)'s JavaScript engine... or called kj these days.
dalek rrot: r37891 | fperrad++ | trunk/tools (2 files):
[languages] add porcupine(pascal)
 14:43
14:56 Tene joined 15:03 Psyche^ joined 15:11 cas joined 15:29 Tene joined 15:33 gryphon joined 15:45 Theory joined
Theory seen allison 15:48
purl allison was last seen on #parrot 23 hours, 45 minutes and 15 seconds ago, saying: changing locations
particle what's shakin', theory? 15:50
Theory It's an ORA question I'm after.
OSCON
not parrot
Thanks tho
16:02 particle1 joined
Coke ORAcle? 16:02
purl it has been said that ORAcle is a distributed humor application or better than free for us since we sell it to clients at a profit or bloody fucking expensive or a piece of shit or fucking annoying or www.worsethanfailure.com/images/iho...le_L_R.gif
16:02 darbelo joined
Coke particle: please document your function. 16:03
perl t/codingstd/c_function_docs.t src/datatypes.c
pmichaud Infinoid: ping 16:04
jonathan oh hai pmichaud
pmichaud good morning, jonathan
Infinoid good morning pm 16:05
pmichaud Infinoid: still seeing the icu segfault?
Infinoid let me verify
Yeah, still seeing SIGBUS in r37891 16:08
My ICU is from the gentoo dev-libs/icu-3.8.1-r1 package, if it helps
Coke particle: nevermind. 16:12
pmichaud I'm not quite sure what would be causing the segfault there. The code is _really_ straightforward.
Infinoid Hmm. 16:13
pmichaud What platform are you on?
Infinoid 220 codepoint = u_charFromName(U_EXTENDED_CHAR_NAME, cstr, &err);
(gdb) print cstr
$2 = 0xe12390 "<no such symbol>"
gentoo linux/x86-64
I can see if I can get some debugging symbols into libicu and get back to you, I guess. 16:14
dalek rrot: r37892 | coke++ | trunk (2 files):
[t/docs] Add function docs.
 16:16
Infinoid Your ICU accepts "<no such symbol>" without segfaulting, I'm guessing?
Coke is that a literal or some error message complaining it can't render it?
Infinoid It's a literal C string. 16:17
Coke seems like an odd thing to ask icu to translate. =-)
Infinoid Yeah, but I suppose that's why there's an &err argument 16:18
(I know nothing about ICU)
pmichaud it's a literal C string -- we're verifying that the method returns the correct error value (-1) when passed a string that isn't a valid character name. 16:19
I'd be okay with changing the test to remove the angles or otherwise test this particular case.
(and yes, my ICU accepts it just fine.)
Infinoid Ok, probably a bug in my ICU version then. I'll dig a little deeper to make sure of that, and then try to find a workaround 16:20
Thanks!
pmichaud fwiw, icu on my system appears to be 3.8-6ubuntu0.1 16:21
jonathan Argh! 16:26
jonathan runs into....some fun bootstrapping issues. 16:27
pmichaud: Do you have a moment?
pmichaud I do. 16:28
jonathan OK
Background: I'm working on us being able to do parametric roles in PIR, since we need to keep Array/List etc there. 16:29
I decided before working on Associative and Positional though that I'd work on the slightly easier Callable.
Essentially I'm wanting to do the equivalent of role Callable[::T = Object] { } 16:30
This actually produces a role object which holds a bunch of (in this case) multis that are candidates for the role.
pmichaud (keep in mind that I've only skimmed over the parametric roles sections of the synopses)
jonathan (you don't need to know much about parametric roles for my questions, it's just background :-)) 16:31
And since they are multi candidates they need signatures.
Thing is, Signature depends on Junction. And Junction in turn depends on List.
And I'll be wanting to make List do Positional. 16:32
At which point you can see the circularity...
I *think* perhaps making Junction not depend on List might break it... 16:33
(As in, break the circularity)
Oh, or I may be able to modify Signature to not construct a Junction unless it really needs one... 16:34
In which case we just don't hit the problem.
(And it only really need create on if there are constraints...)
pmichaud I don't think Junction needs to depend on List
a Junction could use a RPA
jonathan Me either. We do it as a convenience so we can do List.uniq
dalek kudo: 881ed3d | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 344 files, 8081 passing, 0 failing
 16:35
shorten dalek's url is at xrl.us/benqgt
pmichaud .uniq doesn't belong on List anyway
(it goes on Any)
jonathan True.
pmichaud that said, we don't have to (re)use .uniq -- we could implement it there
jonathan Right. 16:36
pmichaud since Junction is now becoming a native type (although I don't know if that will stand), we have a lot more liberties with what we do with it.
jonathan OK.
pmichaud anyway, I'm fine with making Junction not depend on List.
jonathan Seems nothing I'm thinking of doing is anything you'll disagree too strongly with. :-)
pmichaud no, these all sound fine.
er
yes, these all sound fine.
er
These are fine. :-) 16:37
jonathan ;-)
It did occur to me that we maybe don't need Array, List etc to be parametric themselves.
Oh, we do akshually...
But we can still get typed arrays, hashes, routines etc by just making sure they do Positional[T], etc. 16:38
(Which has the other nice side-effect that I stand a chance of finishing my (now over a month late!) grant without having to depend on the refactoring of List to has-a RPA etc. 16:39
)
oh joy i haz a Parrot segfault 17:03
17:05 particle joined
Tene YAY SEGFAULTS 17:31
moritz OH NOEZ 17:33
Infinoid I made u a segfault, but I eated it 17:36
17:37 jan joined 17:44 gryphon joined, rdice joined
Tene no those are not good for u 17:45
Infinoid do not want? 17:47
purl hmmm... do not want is at www.mgroves.com/images/do_not_want_star_wars.jpg
17:53 amoc joined 17:59 AndyA joined 18:11 davidfetter joined 18:41 barney joined
dalek rrot: r37893 | coke++ | trunk/src/packfile.c:
[t/docs] add a placeholder for docs for this func.
 18:42
barney What is the difference between die 'message'; and die "message\\n"; ? 18:51
Infinoid die "message\\n" suppresses the "at foo.pl line 54" suffix 18:52
barney Infinoid++ 18:53
dalek kudo: f6886e3 | jnthn++ | src/ (2 files):
Make Signature not be dependent on List and Failure, to break a dependency chain that got in the way of the bootstrap.
 19:01
kudo: b015a2a | jnthn++ | (2 files):
Remove Junction's deendence on Array and List, then move it to an earlier spot in the built-ins list.
shorten dalek's url is at xrl.us/benq2u
19:01 HG` joined
dalek kudo: 4a7fe22 | jnthn++ | src/builtins/guts.pir:
For registering parametric roles in the stage one set of built-ins, !meta_compose must not depend on having a constructed Perl6 Compiler object yet.
 19:01
shorten dalek's url is at xrl.us/benq2w
shorten dalek's url is at xrl.us/benq22
dalek kudo: 903a782 | jnthn++ | src/classes/Callable.pir:
Callable role becomes parametric (like role Callable[::T = Object] { }).
shorten dalek's url is at xrl.us/benq26
dalek kudo: fff26a1 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/benq28
dalek tracwiki: v5 | barney++ | AbandonedLanguages 19:16
tracwiki: Add PONIE
tracwiki: trac.parrot.org/parrot/wiki/Abando...ction=diff
tracwiki: v6 | barney++ | AbandonedLanguages
tracwiki: trac.parrot.org/parrot/wiki/Abando...ction=diff
shorten dalek's url is at xrl.us/benq46
dalek's url is at xrl.us/benq48
19:38 ruoso joined 19:43 HG` joined 19:45 Theory joined
Infinoid is having trouble accessing parrot svn 19:45
moritz works here 19:52
Infinoid ah, here too
I was getting ECONNTIMEDOUT earlier 19:53
dalek rrot: r37894 | Infinoid++ | trunk/compilers/imcc (2 files):
[cage] Fix some pod_syntax.t failures.
 20:05
20:13 pinkyandthebrain joined
Coke Infinoid: thanks for the pod fix. 20:21
I just added the function docs blindly. =-)
Infinoid No prob, it was easy karma. :) 20:26
20:31 pinkyandthebrain left 20:54 mikehh joined
dalek kudo: 07af82b | pmichaud++ | (3 files):
Update the harness to recognize icu flags on spectest.data,

Add a icu-dependent test to spectest.data (which should be skipped on platforms that don't have icu present).		 21:07
shorten dalek's url is at xrl.us/benrkb
21:11 Limbic_Region joined
cotto Infinoid++ #really easy karma 22:46
mikehh parrot r37894 - smolder 19613 - make codetest PASS - still failing t/op/trans.t in jit core (Failed test: 13 - Failed test 'atan2') this passes in all the other cores 22:59
Kubuntu Intrepid i386 23:01
I thought it might even be the compiler - so I spent a day building gcc 4.3.3 from scratch - didn't make a difference 23:04
let me try without the --optimize and see if that makes a difference 23:06
BTW rakudo (07af82b) builds on parrot r37894 - make test/make spectest PASS 23:10
nope - still fails 23:20
23:25 Limbic_Region joined
mikehh perl t/harness -j t/op/trans.t fails (Failed test: 13 (atan2)) -b, -C, -f, -g, -r, -S PASS with or without --optimize 23:28
smolder (without optimize) 19614 (with optimize) 19613 at r37894 23:32
23:37 tetragon joined
mikehh the smolder test took 11:49 without --optimize compared to 10:13 with --optimize 23:37
sorry that was 10:12 with --optimize :-} 23:41
it also passed 40 more tests as I used --configure_trace as well 23:42

Powered by Cro and the Raku® Programming Language.

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

Thank you!