#parrot Parrot 2.2.0 "Like Clockwork" Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: documentation sprint and pre-release testing for 2.3, fix line number annotations | Review and vote GSoC applications
Set by moderator on 13 April 2010.
cotto_work looks for a guy named "Tod" to mock. 00:00
with gzip, perl6.pbc goes from 22M to 1.1M. 00:06
plobsing yeah, 464k with lzma
660k with bzip2 00:07
I haven't played with the options
PBC - optimized for compression :p 00:08
nopaste "cotto_work" at 192.168.1.3 pasted "comparison of runcores in compiling tools/dev/pprof2cg.nqp" (8 lines) at nopaste.snit.ch/20265 00:11
chromatic Switch? 00:12
purl Switch is evil.
cotto_work plobsing: we could throw some more long string of 0 in there.
chromatic: running now
chromatic Fast is 4.553% faster than slow. 00:13
plobsing isn't cgp supposed to be an optimized variant of cgoto?
chromatic If I could make fast pass all of its tests properly....
00:13 snarkyboojum joined
cotto_work The validity of that task as a representation of performance is an open question. 00:14
Whiteknight chromatic: fast core doesn't pass tests?
I thought rakudo was using it for default
chromatic Some of the annotations tests are TODO for that core. 00:15
Whiteknight instruction counts don't take into consideration pipeline pairings, or relative instruction costs
nopaste "cotto_work" at 192.168.1.3 pasted "same as previous but with switch" (10 lines) at nopaste.snit.ch/20266 00:16
chromatic Wow, I would have expected switch to perform better.
cotto_work That's without --optimize\\
sorear switch is cgoto + range checking in nearly every C compiler 00:17
opcode range checking, I mean
cgoto will just segfault if it gets an out of range opcode
chromatic I'm not convinced C compilers will reliably optimize a switch statement with that many cases. 00:18
Whiteknight yeah, i doubt it
sorear what do you mean by "optimize a switch statement"
plobsing there should be a pragma that tells the compiler "Hey, I'm making an op dispatcher"
chromatic Then again, I'm not convinced VS can reliably optimize a switch statement with more than four cases.
Whiteknight sorear is right too: best it could be optimized is into a linear dispatch table, like a cgoto
particle preliminary gsoc slot count for tpf: 10
chromatic Perl 5 is borrowing optimizations from parrot: www.mail-archive.com/perl5-changes@...23468.html 00:19
Whiteknight cotto, how many Parrot instructions in that program
chromatic, we have optimizations?
:) 00:20
cotto_work Whiteknight: not sure. I'm just testing the time to compile and spit\\ out pir.
chromatic I could revert several dozen commits and show you, yes.
plobsing pbc_disassemble perl6.pbc => SEGFAULT
cotto_work plobsing, that's not entirely surprising. pbc_disassemble has bugs non-tiny pbc files. 00:21
plobsing is it even worth opening a ticket?
chromatic Not if you can fix it right now.
plobsing not bloody likely
cotto_work nm. I'm thinking of pbc_dump. 00:22
chromatic Ticket away!
nopaste "cotto_work" at 192.168.1.3 pasted "now with --optimize" (15 lines) at nopaste.snit.ch/20267 00:25
00:26 snarkyboojum joined
chromatic Much better. 00:27
purl i heard much better was to design each table in isolation with the table name providing context
chromatic Fast is 1.927% faster than slow. 00:28
cotto_work Assuming this is representative of performance (which is a potentially big assumption), things look bad for cgp. 00:29
Whiteknight kill it with fire
cotto_work and switch and slow
deprecations first, then fire
It'll be really nice to rip some of that code out. 00:30
chromatic cg, cgp, and switch can go away as far as I'm concerned.
Whiteknight +1
purl 1
cotto_work but more testing should be done first, especially with Rakudo and Partcl-nqp
chromatic Switching to fast will be a little more difficult, but we can get that done too.
cotto_work What's tricky about fast? It's the simplest possible runcore. 00:31
Whiteknight purl +1 is <reply>-2
purl ...but +1 is <reply>-1...
chromatic Sometimes it doesn't update pc appropriately.
sorear why are you counting instructions?
00:31 Mokurai1 joined
sorear and not something physically meaningful like milliseconds? 00:31
chromatic Because counting milliseconds is silly and not meaningful. 00:32
cotto_work there's a comment in runops_fast_core that can safely go away
sorear milliseconds are the only thing I care about
I don't lose patience by the billion instructions
I lose patience by the million milliseconds
chromatic You can't compare milliseconds accurately.
sorear are you secretly a computer program? 00:33
cotto_work milliseconds are harder to test
chromatic If your profiles rely on a clock, your profiles are not accurate, and they don't count.
cotto_work time-based testing is fine. It just requires more statistical forethought than instruction counts. 00:34
chromatic Time-based testing isn't fine, because it's unscientific. It's not repeatable.
Whiteknight well, on a single core, non-threaded embedded system with IO interrupts turned off and a fixed crystal freqency, a clock benchmark is fine
sorear Instruction count benchmarking is fine on MIPS
chromatic .... depending on the accuracy of your clock, perhaps Whiteknight is right. 00:35
sorear a single-scalar architecture where all instructions run in one clock cycle
with no cache
cotto_work valgrind can simulate cache but I agree that it's a more abstract measurement than milliseconds 00:36
sorear also, science has involved margins of error for centuries
cotto_work . o O (Look at me, still talking when there's science to do.)
chromatic Okay, hands up everyone profiling Parrot on a single core embedded system with no interrupts and no multitasking. 00:37
No hands?
None?
purl i guess None is :/
chromatic Thought not.
Now complain all you like about how the real world blah blah clock cycles blah blah accurate blah blah, but look me in the eye and tell me that reducing the number of instructions executed by a repeatably measurable and verifiable amount hasn't made Parrot and Rakudo run faster. 00:38
Because I can tell you that a parallel run of coretest takes between 22 and 39 seconds on my development box. 00:39
... and any science which can deal with almost a factor of two margin of error had better be a social science or climatology, because nothing else will take it seriously.
sorear chromatic: Why are you talking about seconds? You just said they don't matter.
plobsing runs off to build a custom test box to fit specifications 00:40
sorear When you measure instruction counts, you have a factor of 400 factor of error. That's the difference between SYSENTER and INC in the i386 system programmer's manual
I would rather have a factor of 2 error than a factor of 400.
Also, the central limit theorem will reduce the factor of 2 as low as I want, but won't affect the 400 (since the error isn't independant between runs). 00:41
cotto_work sorear: where does 400 come from?
plobsing sorear: I seriously doubt the difference in instruction counts comes from any "heavy" instructions such as sysenter
sorear cotto_work: the Intel Pentium 4 System Programmer's Manual
I'm misremembering the values, I'm sure
plobsing: CALL is also a heavy instruction, although less so, and fast uses it in spades 00:42
plobsing fair enough
cotto_work Ah. You're saying that instructions take different amounts of time.
sorear I don't know exactly how heavy CALL is. 00:43
Neither does Intel - it depends on too many factors.
time(1), however, does know
chromatic Too bad time(1) isn't repeatable.
cotto_work a margin of error doesn't preclude repeatability 00:44
chromatic A margin of error affected by local Ethernet traffic does. 00:45
I can run Callgrind on a Parrot program a thousand times and get *the same number*.
cotto_work +/- a little
chromatic If I run time(1) on that same Parrot program, I can ameliorate my margin of error and get a stochastic likelihood that the eventual number I can come up with is probably within my margin of error. 00:46
Which am I going to pick?
sorear If I'm measuring the gravitational forces on oil drops, I don't get exactly repeatable results because every time a truck drives by, my numbers change infinitesemally
You've basically just asserted physics isn't science
chromatic: You're going to pick callgrind. We, however, will stick with time and averaging over hundreds of runs. Neither number is useless. 00:47
chromatic That's probably why physicists don't use Newtonian physics for things that are too big or too small for Newtonian physics to apply.
cotto_work valgrind is very precise, simple to run and gives a rough indicator of performance. milliseconds vary significantly and require many runs with statistical analysis but give an accurate indicator of performance. 00:49
Whiteknight children, stop fighting or you get the hose 00:53
cotto_work sings kumbayaa 00:54
dalek TT #1557 created by plobsing++: pbc_disassemble fails on large PBCs 00:56
TT #1557: trac.parrot.org/parrot/ticket/1557
01:04 abqar joined
nopaste "plobsing" at 192.168.1.3 pasted "compact strings in packfiles slightly" (99 lines) at nopaste.snit.ch/20268 01:32
plobsing probably a little close to the release for that eh? 01:33
cotto normal release, no. supported release, probably yes 01:40
sorear what makes a release "supported?" 01:41
01:41 AndyA_ joined
cotto sorear, docs/project/support_policy.pod 01:45
01:47 kid51 joined
sorear thanks 01:51
plobsing I guess it waits till patch tuesday 01:54
kid51 Yes, I think this is Gerd's first time at bat as release manager, so we don't want to overburden him. 01:55
which reminds me, I should start doing make fulltest
Coke msg allison I will probably not get to the trac report tonight, apologies. 01:58
purl Message for allison stored.
cotto More patches won't put any extra burden on gerd. We just want to focus on documentation and testing. 02:00
actually, it'd depend on how confident you are in the patch. 02:01
plobsing I'm 95% on it. Its pretty simple, but this is software. 02:02
cotto If you want to apply it, better sooner than later.
Coke parrot docbugs is xrl.us/bhg2p8 [trac.parrot.org] 02:06
dalek rrot: r45647 | plobsing++ | trunk/src/packfile/pf_items.c:
use the same opcode for both charset number and pobj flags for strings in packfiles
 02:22
GeJ exit
cotto exits
plobsing #parrot: you have suspended jobs.
GeJ Ah, dammit. bad focus when closing a window. 02:23
Sorry about that.
sorear at least you didn't do 'su'
(I've seen this happen)
02:28 tetragon joined
GeJ sorear: hum, I believe I may have typed my password here at least a couple of time before. 02:29
cotto hunter2 02:30
dalek rrot: r45648 | coke++ | trunk/src/packfile/pf_items.c:
eliminate trailing whitespace
 02:39
rrot: r45649 | gerd++ | trunk/NEWS:
some news added
cotto plobsing, did you run make test before that commit? 02:41
I'm seeing some packfile-related test failures.
plobsing I did. The test pbcs need to be regenerated.
I just commited that. 02:42
kid51 exit
make fulltest PASS linux/i386 r 45649 02:43
plobsing wha? are you sure? the native pbcs were broken in that rev. 02:44
kid51 Uh-oh: getting lots of failures on Darwin/PPC 02:45
All in the t/pmc/packfile*.t tests
cotto there you go
plobsing thats more like it 02:46
update to r45650. that should fix it.
02:48 janus joined
kid51 Let's see: that was my first build of Parrot using Perl 5.12.0 02:48
Correction: those failures were on Linux/i386 02:49
02:50 hercynium joined
kid51 Yes that looks better 02:50
dalek rrot: r45650 | plobsing++ | trunk/t/native_pbc (4 files):
mk_native_pbc
 02:56
rrot: r45651 | plobsing++ | trunk/config/gen/config_pm/config_pir.in:
describe new structure of config hash
TT #1474 closed by plobsing++: runtime/parrot/library/config.pir refers to long dead "None" PMC. 02:58
TT #1474: trac.parrot.org/parrot/ticket/1474
TT #1536 closed by coke++: Remove History and Maintainer sections from PDD's (mostly drafts) 02:59
TT #1536: trac.parrot.org/parrot/ticket/1536
Coke msg gerd - pretty sure that the 3 month deprecation cycle was already announced in our last stable release, and stringnull ain't new.
purl Message for gerd stored.
03:00 snarkyboojum joined
Coke Invalid charset number '1825' specified 03:05
(getting that trying to run anything in rakudo...
plobsing really? coretest is working fine for me 03:07
dalek rrot: r45652 | coke++ | trunk/docs/pdds (30 files):
PDD cleanup (TT #1536); Remove maintainer, changes sections.

podular cleanups. Update copyrights on edited files.		 03:13
cotto Coke, I saw something like that. It disappeared after I ran make without -j 03:18
03:23 jsut_ joined
tcurtis What are PAST::Control nodes for? 03:54
sorear I would imagine they're like COPs, but that's a completely wild guess 03:55
03:57 khairul joined
sorear no 03:59
PAST::Control nodes do not appear to be used for anything at all 04:00
ah, Rakudo uses them 04:02
see src/Perl6/Actions.pm
in particular when implementing given/when
it's not a loop, but it needs to catch break
tcurtis Thanks. 04:09
sorear++ 04:10
04:11 Andy joined
Andy hey plobsing 04:12
purl plobsing is part of our sanity injection framework or probably canadian or mailto:plobsing@gmail.com
plobsing j0 04:15
s/j/y/
dalek rrot: r45653 | petdance++ | trunk (2 files):
correct an incorrect annotation
 04:23
Andy hey plobsing 04:28
purl plobsing is part of our sanity injection framework or probably canadian or mailto:plobsing@gmail.com
Andy we want to change any checks of NULLness of STRINGs to STRING_IS_NULL, right? 04:29
plobsing Andy: in general yes. There are places, especially in the string system proper where this doesn't make sense. 04:30
but most systems have no excuse for breaking this encapsulation 04:36
sorear if strings are supposed to act like a primitive type, why do we have a null string at all?
there's no null int or null num, we just use the additive identity (0, 0.0) 04:37
maybe S variables should always point to valid strings, and be initialized to ""
plobsing what encoding is that in/ 04:38
?
sorear all of them
the empty string has the same representation in every real-world character encoding I know of 04:39
plobsing true, but, based on my understanding of how strings work in Parrot, the encoding flag on that string (and there can be only one encoding for a string) can cause other strings to get promoted when they interact 04:40
dalek rrot: r45654 | petdance++ | trunk/src/spf_render.c:
updated annotation
plobsing I am not totally against the concept of "no null strings". But I don't totally buy the "strings are a value type" paradigm either. 04:41
I'm just trying to make what we have now work. Whether what we have is a good idea, I'll leave to someone with more vision than myself. 04:43
sorear my argument is that void strings aren't sufficiently interesting to justify the current trichotomy (STRINGNULL, NULL, "")
plobsing sorear: dichotomy. the official line is that STRINGNULL and NULL are equivalent strings in parrot's eyes 04:44
# define STRING_IS_NULL(s) ((s) == STRINGNULL || (s) == NULL) 04:45
sorear "" probably should be handled as special for promotions; if someone says $a = ""; for (@input) { $a .= $_; } they probably didn't mean to coerce the entire file into UTF-8 or whatever the default encoding of literals in $HLL is
"" is the denotational identity of .; for it to not be so operationally violates the PoLS 04:46
plobsing: ah
04:47 snarkyboojum joined
plobsing sorear: my PoLS would involve never seeing denotational identities :p 04:50
ttbot Parrot trunk/ r45656 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/263791.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 05:21
dalek rrot: r45655 | petdance++ | trunk/src/packfile.c:
use the new STRING_IS_NULL macro
 05:31
rrot: r45656 | petdance++ | trunk/src (2 files):
use the new STRING_IS_NULL macro. Consting and function annotations.
05:52 eternaleye joined
cotto Bah. All our fancy function annotations make Coccinelle sad. 06:02
06:07 uniejo joined 06:58 iblechbot joined
dalek kudo: aae95f4 | moritz++ | t/spectest.data:
we pass sort.t, quester++
 07:25
cotto There's a lot of code that matches /if \\(s\\)/ 07:37
If someone's up for wrestling with Coccinelle, this would be a great application for it.
otoh, it's yet another thing that acts kinda like a C compiler 07:41
dalek rrot: r45657 | dukeleto++ | trunk/docs/pdds/draft/pdd10_embedding.pod:
[cage] Fix signature docs for Parrot_compile_string in PDD10
 07:42
ttbot Parrot trunk/ r45657 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/263982.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 07:43
cotto all better 07:45
cotto kicks dalek gently 07:50
dalek rrot: r45658 | cotto++ | trunk/src/call/args.c:
[call] run headerizer, fix build, more cowbell, etc
 07:59
cotto I've lost much faith in the speed of nqp-rx's regex matching capabilities. 08:04
moritz speed? are you kidding? 08:08
since nqp-rx doen't yet implement :: it's not so easy to fail early in some rules
08:14 chromatic joined
moritz Coke: why did you change TT #389 from "bug" to "deprecated"? And what exactly does that mean? 08:17
dalek rrot: r45659 | gerd++ | trunk/RESPONSIBLE_PARTIES:
add myself for Fedora
 08:18
08:22 mikehh joined
chromatic PBCs are ~4.5% smaller now. 08:33
moritz chromatic: I've just received complaints about the rendering of the Perl 6 book 08:35
chromatic: it seems that B<...> outlining doesn't work in =begin programlisting blocks 08:36
ie the B<...> are left verbatim in the code
chromatic We had that working at one point. I'll ask allison about it. 08:37
sorear I'd prefer you didn't think about them as complaints 08:56
LTA, sure, but perfectly readable 08:57
moritz sorear: I don't mean "complaints" negatively in any way 09:03
to me it's more like "bug report" :-) 09:04
and since I mostly look at the POD, and nearly never at the tex or pdf, those are valuable 09:05
cotto 1-4/128 09:34
purl 0.96875
cotto yay for being faster 09:39
chromatic What's faster? 09:40
purl *whutcchhh* *whutcchhh* or Citius, Altius, Fortius! or the wrong goal
cotto it'll be even nicer when switching to a hand-rolled parser actually slows nqp-rx code down
parsing profiles
it's down to "reasonable" now
about 4s for t/pmc/fixedpmcarray.t 09:41
chromatic Is the recursive descent of NQP painful? The lack of cut? Missing LTM?
dalek rrot: r45660 | cotto++ | trunk/runtime/parrot/library/ProfTest (3 files):
[proftest] switch from grammar to manual string mangling
 09:42
cotto It don't know. It looked like more of a "use a different tool" problem than a "tune the existing code" issue.
cotto time for sleep 09:43
chromatic Indeed.
bacek aloha 09:48
dalek rrot: r45661 | cotto++ | trunk/runtime/parrot/library/ProfTest/PIRProfile.nqp:
[proftest] fix some escaped debugging code
 09:58
chromatic The PF_fetch_* functions in src/packfile/pf_items.c might not need to use function pointers; the underlying fetch functions are static and easy to inline a few bytes of asm. 10:07
You hate to see branch prediction hurt there. 10:08
10:24 aukjan joined 10:42 clinton joined
dalek rrot: r45662 | bacek++ | branches/immutable_strings_part1/src/string/charset/ascii.c:
Remove unused static function
 10:48
allison Score! all tests passing with TT #389 fixed 10:50
bacek ship it! 10:57
12:01 whiteknight joined 12:06 bluescreen joined
whiteknight good morning, #parrot 12:09
dalek rrot: r45663 | allison++ | trunk/runtime/parrot/library/TAP/Parser.pir:
[cage] Preparing for deprecation change, methods are only stored in the
rrot: r45664 | allison++ | trunk/compilers/pge/PGE (2 files):
[pge] Preparing for deprecation change, methods are only stored in the
 12:26
purl i already had it that way, dalek.
rrot: r45665 | allison++ | trunk/t (8 files):
[tests] Preparing for deprecation change, methods are only stored in the
purl i already had it that way, dalek.
13:00 ruoso joined 13:04 smash joined
smash hello everyone 13:04
13:05 aukjan joined
whiteknight hello smash 13:11
allison moritz: you have to set the $new->codes_in_verbatim(1); option on the parser object 13:16
13:16 Andy joined
allison moritz/chromatic: the version of Pod::PseudoPod::HTML I have for the Parrot Dev Guide sets it automatically in the core module 13:17
moritz/chromatic: digging further, it's in the released version of Pod::PseudoPod too 13:19
moritz allison++
allison moritz: but note that standard Pod does *not* parse format tags like B<...> in verbatim code blocks
moritz allison: I know 13:20
allison ok
moritz I picked it up from an editoral patch by chromatic++
allison I don't know what version of the parser the Perl 6 book was generated on, though
moritz: okay, cool 13:21
moritz ii libpod-pseudop 0.15-1 A framework for parsing PseudoPod
is what I use
allison moritz: hmmm.. what distro?
purl somebody said distro was HTML::Tree
moritz allison: debian... but probably a self-made module
allison 0.16 is the latest, but it's just a couple weeks old 13:22
moritz if I read the changelog correctly, it's not worth upgrading for removed tests :-)
allison moritz: and, looks like the option was enabled there too 13:23
moritz: aye, no point
moritz: it was just a release to silence the CPAN failures
moritz: (by "there" 3 lines ago, I meant "in 0.15 too") 13:24
13:24 atrodo joined
moritz good 13:24
13:26 payload joined
moritz seems to work... at least the generated .tex doesn't contain B< anymore 13:27
there are still some layout issues, but I assume you have much better tex templates anyway 13:29
(for example the tables have borders, except the title rows, which only have borders on the bottom/right, but not on the top/left) 13:30
13:32 rhr joined
Coke moritz: it's called "deprecation" now. basically, a change in behavior that needs to occur that will break backward compatibility. 13:34
particle tar zxf foo.tgz # tar: You must specify one ef the '-Acdtrux' options
huh?
is x no longer x?
moritz particle: try tar -xzf foo.tgz
Coke particle: tar -zxf foo.tgz
(I thought you needed the -_ 13:35
moritz Coke: depends on the tar
I think GNU tar doesn't need it
but others are a bit more picky
particle this is centos, doesn't like - 13:36
ah... interesting....
13:36 payload1 joined
particle the full line is: su - minicpan -c tar zxf foo.tgz 13:36
13:37 patspam joined
particle even if i do 'su - minicpan -c -- tar -xzf foo.tgz' i get su: invalid option -- x 13:37
su is seeing the -xzf
i've got to put quotes around the -c arg, i guess 13:38
moritz allison: another complaint about Pod::PseudoPod: it translates double quotes differently in verbatim blocks and C<...> constructs 13:39
13:40 payload joined
moritz which is rather annoying when you talk about interpolation semantics 13:40
example: moritz.faui2k3.org/tmp/book.pdf page 8 (a bit above the Excercises)
13:41 tetragon joined
allison moritz: that's not Pod::PseudoPod, that's LaTeX doing that 13:41
moritz oh, and B<...> now gets translated into \\textbf{...} inside programlisting blocks, but \\begin{verbatim}...\\end{verbatim} doesn't process that... do I need fancyvrb or so? 13:42
allison: ugh
allison moritz: latex again
moritz: if you do the HTML output it comes out right 13:43
moritz so Pod::PseudoPod::LaTeX isn't supposed to emit "working" latex output? :/
or does it require a special latex prelude? 13:44
smash excelent the build system for the perl6 book 13:45
13:54 bubaflub joined 13:57 payload1 joined 14:04 ruoso joined
allison moritz: it should be valid LaTeX, but so far I haven't found a way to get LaTeX to handle formatting codes inside verbatim blocks 14:05
14:06 ash_ joined
allison moritz: if you run across the magic incantation, pass it along and I'll make sure it gets into the module 14:06
moritz allison: I'll look into it - I dimly recall that fancyvrb can do such things
ash_ whiteknight: have you seen macruby much? I only mention it because its the exact kind of thing i would like to do with parrot, concerning the llvm that is for my GSoC project. 14:08
14:10 particle1 joined 14:11 Andy joined
whiteknight ash_: no, not familiar with macruby at al 14:11
all
links or info?
ash_ www.macruby.org/blog/index.html talks about it a good bit, what i would like to do 14:12
its ruby, the same core as the mainline of ruby, but they replaced the vm with the llvm, added a few things, and made a bridge to objective-c, (that doesn't use libffi, it compiles down to a real C call instead of libffi so its faster) 14:13
it comes with a AOT compiler, macrubyc, that will take a ruby file and convert it to a native binary using the llvm, it can also make dynamic libraries too 14:14
whiteknight ash_: An AOT compiler is a feature that I would love to have in Parrot eventually
ash_ that was one of the things i'd like to do with parrot, instead of dumping bytecode, actually using the llvm to build a native executable, granted its only for parrot installs with the llvm, but still 14:15
dalek rrot: r45666 | allison++ | trunk (2 files):
[cage] Associate named macros with sub compilation flags that are already used,
 14:16
whiteknight ash_: Yeah, but you could package up the executable and libparrot into an installer, and distribute that to people who don't have parrot already
14:16 payload joined
ash_ yeah, theres a lot of stuff you can do 14:17
in nq-nqp i am finally getting to code generation, i have some basic ability to call functions and make new objects 14:20
whiteknight: if your on linux, you can still build macruby if you want to see it work, it just won't have all the cocoa stuff 14:22
it works on linux, and windows (via cygwin)
whiteknight I can check it out later today when I get home
Coke wonders if there's anyone else he can sucker into working on partcl. =-) 14:24
ash_ how is partcl coming along? 14:26
allison ooookey, I'm not committting the TT #389 fix before 2.3, because even NQP-rx depends on the old broken behavior 14:27
I can fix PGE, but NQP-rx is generating broken code 14:28
Coke slowly. had gotten to a point with partcl that it was running the tcl test suite and passing a large fraction. but it was harder and harder to add new features. switched to a version written in NQP-rx, which makes writing things a lot easier, but involves a lot of recoding.
allison (I can even fix the broken generated code in the Parrot repository, but the problem is external)
Coke (fixing nqp-rx) - if we can get a few moments of pmichaud's time, we might be able to make that happen. 14:29
(and there are multiple commiters on nqp-rx)
moritz if somebody needs commit access to nqp-rx, that can also be organized
allison it'll be a small fix
just adding :nsentry to a template for generated code 14:30
he can go back and remove it later if he wants to make the more sweeping changes to avoid pulling methods out of the namespace 14:31
dalek rrot: r45667 | allison++ | trunk/runtime/parrot/library/TAP/Parser.pir:
[cage] No need to repeat the sub name in :nsentry.
 14:32
rrot: r45668 | allison++ | trunk/runtime/parrot/library/pcore.pir:
[cage] Some tests were relying on the get_lexenv method being available from
purl the namespace is the internal namespace for things like $c->forward and template paths, anyway or hll:X::Y, but yes.
rrot: r45669 | allison++ | trunk/runtime/parrot/library/P6object.pir:
[cage] Preparing for deprecation change, methods are only stored in the
14:32 theory joined
purl i already had it that way, dalek.
rrot: r45670 | allison++ | trunk/runtime/parrot/library/Stream/Base.pir:
[cage] Preparing for deprecation change, methods are only stored in the
purl i already had it that way, dalek.
smash where can i send patches for the perl6 book ? 14:34
moritz smash: good question... maybe perl6-compiler@perl.org for now 14:35
smash: if you have just small changes, you can commit them directly if you want... just tell me your github ID
smash moritz: just some typo fixes 14:37
moritz smash: the commit them directly
14:38 fperrad joined
Coke moritz: just have him fork and pull request? 14:39
(oh, typos, envermind. )
moritz Coke: just have him commit directly... I don't see why not :-) 14:40
whiteknight what is a pull request?
purl i guess a pull request is just a message
whiteknight thanks purl
Coke "i have committed things to a fork of your project. you should look at them."
whiteknight ah, that makes more sense
Coke except that github (kind of) makes it easy to do.
moritz it also add those commits to a fork queue, where you can apply patches with a single click 14:41
Coke whiteknight: github.com/guides/pull-requests
smash moritz: sure i can commit them directly, my githud id is 'smashz'
moritz smash: and you have commit access now. Welcome! 14:43
smash moritz: ok, thank you
Coke whiteknight: github.com/blog/270-the-fork-queue 14:45
14:48 fperrad_ joined 14:54 ash_ joined 14:55 davidfetter joined 14:57 snarkyboojum joined
cotto Are the repeat VTABLE functions and ops valuable? They strike me as something that could easily go on the deprecation pile. 14:58
whiteknight cotto: which ones?
purl which ones are b0rked
whiteknight purl forget which ones
purl whiteknight: I forgot which ones
cotto repeat 15:00
cotto heads to wrok 15:03
davidfetter mmm...wrokz 15:08
15:11 ash_ joined
Coke repeat just lets you turn "X" into "XXX", yes? 15:12
I need that for [string], but do I think it needs to be a vtable? probably not. 15:13
S26?
purl rumour has it S26 is perlcabal.org/syn/S26.html
dalek rrot: r45671 | fperrad++ | trunk/runtime/parrot/library/TAP (2 files):
[TAP] minor refactor
 15:22
15:28 cotto_work joined
Coke smash: "its most simple form' was corect 15:41
"correct". =-)
moritz smash++ # for the other fixes :-)
smash ups, sorry 15:43
my bad, fixing it
15:44 plobsing joined
smash reverted, sorry again, my bad # smash-- 15:45
moritz no problem, the other fixes are good 15:46
Coke NBD.
what moritz said. =-)(
er, =-)
15:52 clinton joined 15:59 theory_ joined
Coke ~/I've got a theory, it's a demon. A dancing demon! Something isn't right there. /~ 16:00
theory dances
moritz tries to dance, tumbles. Not a good dancer 16:01
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33187), fulltest) at r45671 - Ubuntu 10.04 beta i386 (g++ with --optimize) 16:04
16:20 joeri joined 16:25 allison joined 16:29 bubaflub joined 16:32 brrant joined
dalek tracwiki: v6 | Jack++ | FreezeThawTasklist 16:33
tracwiki: trac.parrot.org/parrot/wiki/FreezeT...ction=diff
tracwiki: v3 | Jack++ | ExceptionRefactor
tracwiki: trac.parrot.org/parrot/wiki/Excepti...ction=diff
bubaflub Jack--, Jack-- 16:34
i've undone the spam that Jack put on the wiki. can someone with permissions delete his account and update trac.parrot.org/parrot/wiki/TracSpammers? 16:36
16:38 iblechbot joined
particle removed jack's account 16:39
crap, don't have jack's email, sigh
17:17 GodFather joined
GodFather newbe trying to get squaak to work 9 step episode seems out of date 17:22
17:26 ruoso joined 17:35 whiteknight joined 17:50 hercynium joined
Coke We should restrict wiki editing access to developers. 17:58
doing so now.
I am also tempted to remove "ticket_append" for authenticated. 18:00
purl okay, Coke.
18:01 plobsing joined
darbelo purl: Coke? 18:01
purl i think Coke is Will Coleda <mailto:will@coleda.com> or perpetually annoyed. or magical ticket robot or (if Diet), something that turns into formaldehyde in my blood. or getting those data_json issues in Coke's build. or tempted to remove "ticket_append" for authenticated.
Coke done. 18:02
email sent to list.
I wonder if having a captcha for account creation would help.
darbelo didn't know purl knew how to parse 'I am also...'
Coke: It won't hurt... 18:03
18:04 GodFather joined
allison With the makefile changes of a few months ago, how does one rebuild the IMCC pregenerated files? 18:07
particle is it no longer perl Configure.pl --maintainer? 18:10
particle forgets the option himself
Coke yes it is. 18:13
that is unchanged.
allison particle: --maintainer enables lex and yacc in the makefile
particle: that's working
Ah! that's better. I modified the files again, in case make got confused when I rebuilt without --maintainer 18:19
Coke I am tempted to fix that process so we can leave the files checked in but can avoid all the dummy targets. 18:20
allison Coke: marvelous idea 18:21
18:26 chromatic joined
particle trac.parrot.org/parrot/ticket/1542 is a blocker for blizkost *, can we mark that on the ticket, or add it to some list of priority tickets? 18:26
should i simply update priority? i don't know how the tickets are triaged these days
Coke particle: ticket triage is not really done. 18:28
add the language to the ticket, set it to blocker. that's all you can do.
Why are they using NQP, and not NQP-rx?
And if they want to use NQP, I think they need to preload something else. Austin just fixed this bug for me in partcl-nqp. 18:29
18:34 GodFather joined
Coke allison: I don't see where to edit the list of languages for the dropdown in the tickets. 18:36
allison Coke: it's on the server
Coke: in the trac configuration file
(some things can be edited through the admin interface, but for some reason those can't) 18:37
Coke: /var/lib/trac/sites/parrot/conf/trac.ini 18:39
Coke: lang.options 18:40
Coke on the server was enough. =-) updated. particle, you can set it for that ticket now.
particle danke shoen mein fruend 18:43
Coke particle: why is 1542 not a rakudo bug? 18:46
18:56 Tene_ joined, mikehh joined 18:59 GodFather joined
Coke particle: I have no clue what's going on in 1542. 18:59
if RT #65994 worked, it would be much easier to diagnose. 19:00
19:09 davidfetter joined
cotto_work allison: could SUB_COMP_FLAG_MASK be made less magical? 19:27
dalek rrot: r45672 | allison++ | trunk/compilers/pge/PGE/Exp.pir:
[pge] Slightly cleaner handling of :nsentry, the sub named doesn't need to be
 19:30
rrot: r45673 | allison++ | trunk/include/parrot/sub.h:
[cage] Modify the mask for sub compilation flags so it allows nsentry and
allison cotto: sure
cotto: I could use an | on the relevant flags instead 19:31
cotto_work It's pretty opaque as-is.
allison cotto: agreed 19:32
cotto: I ended up resorting to perl to calculate what the new value should be
19:32 Austin joined
chromatic Can you | together several SUB_FLAG(n)s? 19:35
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33196), fulltest) at r45671 - Ubuntu 10.04 beta i386 (gcc with --optimize) 19:36
allison chromatic: better to use the named flags, since it's clearer
sorear Coke: I filed it on the Parrot tracker because I thought it was unlikely that a purely Rakudo bug would cause load_language to inject code into the wrong namespace
Coke: I don't understand the issue well enough to be at all sure of this, though
chromatic Named flags are better if the compiler supports them there, yes. 19:37
allison chromatic: i.e. SUB_COMP_FLAG_METHOD | SUB_COMP_FLAG_VTABLE | SUB_COMP_FLAG_NSENTRY
cotto_work wonders about a "no magic numbers" codingstd test
allison chromatic: if the compiler supports SUB_FLAG, it should support SUB_COMP_FLAG_* 19:38
chromatic At that point in the struct declaration? 19:39
allison cotto: I just got rid of a bunch of them. It wasn't documented anywhere that P_METHOD in imcc and SUB_COMP_FLAG_METHOD in subs were the same magical constant
19:39 GodFather joined
allison cotto: so reordering one set of apparently unrelated constants would have thrown off the whole system 19:40
19:40 ruoso joined
allison chromatic: we're already defining entries in the enum by previous entries in the enum 19:41
chromatic: so the only uncertain part is whether it'll handle | in the enum definition
chromatic: (which would be true whether we used SUB_FLAG or SUB_COMP_FLAG_*
cotto_work I'm tempted to look at the C standard or K&R to see what should happen, but we know how standards work. 19:42
wfm on gcc 19:43
Austin cotto_work: That's defined behavior. 19:45
Things that have to do with parsing are generally much more specified than things having to do with platform behavior. 19:46
Coke sorear: I'm sorry, where's load language in that ticket? 19:54
(I see load_bytecode)
19:56 mikehh joined 19:59 bluescreen joined
TimToady phone 20:00
20:00 theory joined
Coke crap! be there shortly. 20:01
allison, you about? 20:12
(this is the second week that every sounded like they were talking underwater. I dropped out.)
chromatic Ditto.
Except for dropping out. 20:13
cotto_work charming language rant: www.xent.com/pipermail/fork/Week-of...54578.html 20:15
allison Coke: I'm here
sorear Coke: At the time I filed that ticket I was not aware load_language existed. I have since tested using it and it results in exactly the same error. I suppose I should add this fact to the ticket. 20:16
20:16 payload joined
Coke sorear: I tried to debug it, but I have no idea what perl6 is doing in the VM before we get to the load_bytecode. 20:16
also, why are you using NQP and not nqp-rx?
allison Coke: oreilly "upgraded" their phone system a couple weeks ago
Coke chromatic: pm'd you some notes. 20:17
chromatic Thanks.
cotto_work 0x00000c06 == SUB_COMP_FLAG_VTABLE | SUB_COMP_FLAG_METHOD | SUB_COMP_FLAG_PF_INIT | SUB_COMP_FLAG_NSENTRY if someone wants to remove a magic number in include/parrot/sub.h 20:27
sorear Coke: my copy of 'nqp' actually is nqp-rx
Coke: right, there are probably at least two bugs here - Perl6 is doing something wrong with the VM, and Parrot is handling it wrongly 20:29
but I'm not sufficiently up to speed on the namespace mechanism to debug it
parrot-nqp is nqp-rx nowadays 20:30
c.f. Rakudo-NG uses parrot-nqp in the makefile
allison cotto: got the fix ready to commit (got distracted by the phone) 20:31
cotto_work Yay for less magic! 20:33
20:34 ash_ joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33197), fulltest) at r45673 - Ubuntu 10.04 beta amd64 (gcc with --optimize) 20:36
20:38 jan joined
dalek rrot: r45674 | allison++ | trunk/include/parrot/sub.h:
[cage] Build the flag mask from the values we want to pass through, rather than
 20:40
allison actually, I can go ahead and add the NSENTRY flag in IMCC now... since it doesn't change any deep behavior 20:43
(it's just NameSpace PMC that can't change yet) 20:44
chromatic Suggestion: a cleanup sprint on the NameSpace PMC. 20:45
allison chromatic: very much so
chromatic I can't think of a messier PMC. 20:46
allison it's horrifying to think how many developer hours we could have saved on TT #389 if the code was well maintained
chromatic Maybe we need src/namespace/*.c
allison src/global.c certainly needs to die
chromatic ... but I think the real problem is that the existing VTABLE interface isn't appropriate for the operations we need to perform on NameSpaces.
allison it could be split into several files 20:47
chromatic: well, we shouldn't be packing all that behavior into set_pmc_keyed_str
it should be a separate function
that just happens to be called from the namespace PMC
20:48 jan joined
chromatic <field color="green">If we had a system built on a metaprotocol, we could have add_method, add_function, add_string, add_variable, etc methods on a NameSpace class and have avoided all of this.</field> 20:49
allison Yah, it's mainly IMCC that forces the stupidity on the system now
chromatic Not entirely. 20:50
IMCC provides plenty of design and implementation stupid.
20:50 cotto_work joined
allison it starts with lovely rich information on whether a thing is a method, sub, etc, crams it all down into a struct with flags, then unpacks it to decide if the thing is a method, sub, etc 20:50
chromatic ... but having to fit everything through the tiny little round hole of set_pmc_keyed_str means IMCC has to stuff a lot of information that it already knows into flags on Sub PMCs, and NameSpace has to extract all of that... yeah, exactly. 20:51
But that's because of set_pmc_keyed_str being way, way too generic for these operations.
Coke sorear: languages/nqp is nqp-rx!? I don't think so.
sorear: you're loading languages/nqp/nqp.pbc - that's old school NQP, I think.
chromatic Isn't ext/nqp-rx NQP-rx?
allison chromatic: aye, but the reason for that is so that people can use the hash interface on the namespace PMC
chromatic P is for Parrot and Prematuregeneralization. 20:52
20:52 jan joined
Coke chromatic: yes, ext/nqp-rx is NQP-rx. but that isn't installed in to languages, I don't think. 20:52
allison chromatic: but it's perfectly possible (down the road) to say "If you use a namespace like a hash, it acts like a hash, no fancy tricks with methods, vtable overrides, etc" 20:53
"It'll just stuff the thing you give it into the namespace"
chromatic As long as we have something more specific to do smart things, and we don't use a NameSpace as the way of adding methods to a class before we have that class, I can live with that. 20:54
allison there are smarter ways to cache methods before the class exists 20:55
chromatic We should do them then. 20:56
allison yah
not today, though
Austin Please keep in mind that being able to inject methods by adding them to a namesapce is a pretty useful feature. It's how Kakapo works. 20:57
(Conversely, if there's a good way to take over a class/namespace entirely, I could do that, too.)
dalek rrot: r45675 | allison++ | trunk/compilers/imcc (3 files):
[imcc] A two line change to the parser to set an NSENTRY flag for the :nsentry
chromatic The ultimate problem is that Parrot inherited way too much from Perl 5 symbol tables, where there was no good reason to do so. 20:58
allison Austin: that's what 'add_method' is for
Austin: You'll still have the ability to do the same method addition, we're just talking about eliminating one of the interfaces to the feature
chromatic: agreed 21:00
ash_ is there a git repo that's synced with parrot's trunk? 21:11
cotto_work github.com/leto/parrot 21:12
parrot git?
purl hmmm... parrot git is repo.or.cz/w/parrot.git or github.com/leto/parrot
ash_ is there a difference between the repo.or.cz and the github? or is it just extra duplication?
cotto_work dukeleto takes care of the github repo and syncs it regularly. I don't know about the repo.or.cz one. 21:13
Coke repo.or.cz? 21:14
purl repo.or.cz is quite good, and I know the admin
Coke ... yes, but WHO IS IT. =-)
stupid purl.
ash_ kk, well, i think i am going to fork dukeleto's so i can start looking into details on the stack frame, i was thinking of starting a fork 21:15
bacek Good morning
purl Good Morning Mr Rogers
cotto_work hi bacek
bacek aloha cotto
Coke bacek: did you see I reverted one of your commits? 21:16
bacek always depressed that tab-completion doesn't work for "aloha"
Coke, yes.
Coke bacek: hokay.
aloha all better
bacek aloha, aloha!
Coke aloha: aloha.
bacek Coke, my commit was definitely correct but it's too close to release to clean all side-effects. 21:17
tewk t/pmc/packfileannotations.t .... 1/17 unimplemented key type 21:20
Coke bacek: it changes functionality.
so, correct or not, it needs a deprecation warning, if nothing else. 21:21
cotto_work now's the time for those
bacek Coke, i fixed existing check for NULL.
Coke and broke rakudo.
so it's not just that the error message changed. 21:22
cotto_work btw, there's a lot of code that still assumes a null string is NULL instead of STRINGNULL.
bacek Coke, Nope. OTOH I found TT#1207. So, probably proper fix was to remove incorrect check all together. 21:23
dalek rrot: r45676 | bacek++ | trunk/DEPRECATED.pod:
Remove already implemented items from DEPRECATION.pod
 21:30
rrot: r45677 | bacek++ | trunk/DEPRECATED.pod:
Add TT#1207 into deprecation.
21:39 TiMBuS joined
cotto_work wonders how Parrot will do with gcc 4.5.0 21:42
plobsing wonders how much gcc 4.5.0 -flto will help 21:43
cotto_work What does that do? 21:44
plobsing link time optimization.
dumps GIMPLE as bytecode into the object files and then cross-optimizes when linking
21:47 darbelo joined 21:53 theory joined
ash_ clang does link time optimizations too 21:55
plobsing ash_: true, but why use a different compiler when I have my trusty gcc that I know and love-hate 21:56
ash_ hehe, true
gcc 4.5 has a plugin system now, have you seen dragon egg? 21:57
dragonegg.llvm.org/ it's a plugin for gcc 4.5, that replaces the code gen components with the llvm, so you don't have to have llvm-gcc or llvm-g++ anymore if you want to use the gcc as your frontend and use clang as your back end 21:58
s/clang/llvm/
plobsing ash_: cool - now I can use llvm with mature ada and fortran compilers! 21:59
ash_ lol yup
now if there was some way to make parrot compile directly to GIMPLE or llvm-ir... 22:00
22:02 kurahaupo joined
plobsing ash_: opcode introspection + GCC/LLVM PIR bindings would make that possible 22:06
both of those are herculean tasks though
darbelo Maybe a P[AO]ST->GIMPLE translator 22:07
That's just one herculan task ;)
cotto_work That'd actually be kinda awesome.
ash_ (thats my GSoC :P) 22:08
cotto_work though I thought GIMPLE was kept intentionally unstable to prevent that kind of usage
ash_ well, llvm-ir is what i plan on working with
ash_ doesn't know a whole lot about GIMPLE
plobsing looked at GCC internals once. took a week to recover my vision 22:09
darbelo Ftagn! 22:10
Ph'nglui mglw'nafh Cthulhu GCC wgah'nagl fhtagn! 22:11
ash_ oh great destroyer, make it quick 22:13
22:14 hercynium joined
plobsing ash_: for the libffi component of your GSoC, you might find the hooks I added recently useful: NCI_FB_CB, NCI_FB_UD 22:18
ash_ k, i'll look into those
i found an interesting thing in the macruby blog, they used libffi for their bridge to obj-c in version 0.4, but in version 0.5 they switch to llvm constructing real C style calls at runtime, which were (they said) 3-4 times faster 22:19
but that requires llvm support, but if its faster, i think it would be cool to have (assuming you have support for it) 22:20
plobsing ash_: IIRC, thats because they were static thunks - 1 thunk per function as opposed to 1 thunk per signature.
that might take some re-architecting of our NCI system
but when we move native pmc methods away from using nci.pmc, our loading of thunks can become eager if need be 22:21
ash_ ah, just repeating what i read, i don't know much about how its actually implemented
plobsing *probably
darbelo ash_: You might also want to look at kid51's detect_llvm branch. 22:22
plobsing ash_: also, I'm not terribly concerned about the efficiency of the thunks. If you're calling into and out of native that often, you're doing it wrong.
ash_ yeah, i saw that, that will make adding configuration options a lot easier
darbelo it's ~6 months old, so it might need some updating. 22:23
ash_ yeah, but its a head start, also plobsing did his work with libjit and made parts of the stack frame pluggable if i remember correctly
pluggable might not be right, a configuration option 22:24
darbelo (pluggable everything)++
plobsing ash_: libjit wasn't pluggable at all. it was binary, frame builder or no. which I hated because I realized it wouldn't scale beyond 1 option.
ash_ ah 22:25
plobsing I don't think parrot's configure system is set up to handle multiple mutually exclusive options for the same purpose
I would love to be proved wrong on that
darbelo It probably involves adding a runstep, but sounds doable to me. 22:26
We already do it for compiler ;)
ash_ so, during configuration you'd have to check for two options, if 1's set, do X actions, if other is set do Y, if both, error, if neither, use built in stack frame?
plobsing working with parrot's configure system was the part of libjit framebuidler I enjoyed the least
which is why I'm trying to make things runtime pluggable, side-stepping my issues 22:27
hence the hooks
ash_ which do you think would be best? 22:28
should i try to make the stack frame completely pluggable?
plobsing ash_: what do you mean? 22:31
ash_ would you rather i make the stack frame pluggable? or a configuration option? (if i do the GSoC stuff)
22:32 bacek_ joined
plobsing Do the easier thing first - configuration option. 22:33
If it doesn't move too much stuff around (and hopefully it won't, nci should be fairly isolated), it can easily be addapted later.
darbelo I also have a hard time cooking up a sane use case for mixing and mantching frame-builders at runtime. 22:34
plobsing darbelo: it makes plugging them at configure time easy - just stuff it into global init
it also reduces the work required to make a new one (in my eyes), because you don't have to mess around with parrot configure. 22:35
and you can conceivably develop it out of repo as a separate library
darbelo Okay. The last point sold me. 22:36
Downloading and installing a third-party frame-builder without recompilling parrot is a desirable feature. 22:37
Not that I expect a big boom for *that* market, mind you. 22:38
plobsing darbelo: I'm not entirely sure that is the case. I thought so initially but then I considered the "use strict; use warnings" boilerplate in perl 5.
consider having "use nci-llvm;" at the top of every one of your programs
I'm 50/50 on it. But from a dev perspective, anything that lets us independantly develop something better and then drop it in is a good thing IMHO. 22:39
darbelo I'm not following you. Who would put that there and why? 22:40
plobsing if you need to use NCI for your program, you just expect it to be there.
you don't care how it got there, you don't want to think about it
darbelo Yes, and NCI should try to allways work the same, no matter what's under the covers. 22:41
Oh, wait you mean that just installing a new framebuilder won't disable the old one? 22:42
plobsing also consider the headache to bindings library authors. "which nci module do I load?". Although I suppose you could have nci.pir that decided that for you.
darbelo: no. you have to load it into the interpreter for it to replace.
darbelo That can be made an option to the parrot executable, not something that PIR would have to care about. 22:43
I'm thinking of a model similar to the one bacek's using for his bohem_gc work. 22:44
plobsing darbelo: options to the parrot executable are a bad idea - how do I specify them to ./perl6 or ./parrot-nqp?
22:44 Whiteknight joined
darbelo Damm fakecutables. 22:45
plobsing damn OSs that don't support shebang
cotto_work sounds like a fakecutable issue
darbelo Using an env var feels dirty here. 22:46
ash_ i think its fine doing a configuration option... personally, i'd rather just configure at compile time and forget about it
darbelo ash_: Sure, take away the bikeshed before it's painted. See if we care ;)
ash_ lol, in that case, lets statically link all libraries into rakudo, so then you can't change anything! 22:47
cotto_work It'd be nice to make fakecutables support Parrot cli args. 22:50
Coke cotto_work: IMO, not worth it.
if you want to invoke your parrot with very specific options, you can already do that. 22:51
cotto_work yeah but I'm thinking of making life easier for HLL users.
plobsing Coke: being able to specify hash seed to rakduo would have made at least one bug I've dealt with easier to diagnose 22:52
Coke plobsing: you can do that. parrot <options> perl6.pbc
plobsing that's what I wound up doing.
but it took me 5 minutes to figure out I had to do that 22:53
Coke given how much time I've spent chasing things in parrot, that doesn't seem unreasonable. =-) 22:54
a doc fix somewhere in rakudo might be nice. I'll see about adding one.
s/fix/upgrade/
cotto_work The trick is to properly separate Parrot options from HLL compiler options.
ash_ you could configure parrot from ENV vars? 22:55
maybe?
purl Maybe not.
cotto_work ash_: what do you mean? Parrot can read the environment (and I use that in the profiling runcore).
there's no existing equivalence between CLI options and env vars though 22:56
plobsing If we could somehow use an HLL to process all options (using a default interpreter, spawning a differently configured one), HLLs could parse their own flags and pass things along to parrot
ash_ instead of flags on the fakeecutable use env values
darbelo --parrot-options this-one,that-one,other-one=thisvalue is a mouthful to type out, but is pretty collision free.
cotto_work I'm not much of a fan of them as-is, but that's a potential option
darbelo I dislike env var for the fact that I might want to run different HLLs with different options. 22:58
And having one var for each HLL is just too much.
ash_ darbelo: you could have a hierarchy, PARROT_VAR as the fallback; RAKUDO_VAR for a specific executable 23:02
thats probably to complicated though, no need to do that many complicated things
Coke do we install manpages? 23:03
davidfetter Coke++ 23:04
Coke I don't see any.
ah well.
ash_ manpages are useful i find... 23:05
darbelo I'm guessing that would require pod2man, which I lack.
plobsing docs lie. RTFS.
ash_ lol 23:06
cotto_work But the source is OCaml.
ash_ (i find haskell to be very hard to read...)
darbelo I just print the source, set it on fire, and keep inhaling the fumes until it's all reveled to me in a shamanic vision. 23:07
23:08 Mokurai joined
Whiteknight darbelo++ 23:11
23:15 bacek_ left 23:16 bacek_ joined
bacek msg chromatic I'm going to put immutable string aside. I can't understand Rakudo's signature binding at all... 23:17
purl Message for chromatic stored.
Coke darbelo: rakudo/docs/running.pod updated. 23:18
bacek msg chromatic OTOH, if you can create good (fsvo) benchmark test for compact_pool it will be helpful.
purl Message for chromatic stored.
dalek kudo: 2ec0e4e | Coke++ | docs/running.pod:
Add docs on specifying parrot options.
darbelo Coke: Huh? 23:19
ash_ Whiteknight: apparently, the new versions of macruby are OS X only, the first few releases worked on linux, but not anymore 23:20
Coke er, plobsing.
darbelo Ah.
plobsing Coke++
Whiteknight ash_: ok 23:22
plobsing ash_: any idea why that is?
ash_ autozone, and grand central dispatch mostly, i think 23:23
bacek what the heck it "t/tools/install/testlib"? 23:24
ash_ AutoZone is a generationaly mutli-threaded GC system (its built into the ObjC runtime) macruby uses it, so they could remove the GIL ruby has 23:25
23:25 allison joined
ash_ AutoZone is open source, but i don't think its been ported anywhere else 23:26
grand central dispatch is also open source, but again, i don't think its been ported anywhere other than OS X (might be wrong about this one)
cotto_work baest: "This is Parrot, version 0.9.1" Looks obvious to me. ; 23:27
)
23:27 ruoso joined
dalek rtcl-nqp: 91668b4 | Coke++ | src/Partcl/ (2 files):
Add support for ${name} variables.
 23:27
plobsing cotto_work: I thought that too until I peaked into DEPRECATED.pod and noticed my recent changes there
dalek rtcl-nqp: 20fc1e0 | Coke++ | (2 files):
disable the hard parts of this test and TODO what needs it.
rtcl-nqp: 783d48f | Coke++ | docs/todo.pod:
some of these todos are done. fix a syntax error.
rtcl-nqp: fd74fd9 | Coke++ | (3 files):
Add simplistic TclArray
rtcl-nqp: 4b11aab | Coke++ | src/Partcl/commands/main.pm:
relocated helper sub
Coke win 2 23:28
dalek cnum-dynpmcs: r198 | darbelo++ | trunk/src/pmc/dec (3 files):
Change PObj_active_destroy_SET() to PObj_custom_destroy_SET().
 23:36
purl dalek: that doesn't look right
darbelo It probably shows how many users I have that I never got a bug report about the library being 100% borked ;) 23:41
cotto_work Woohoo. bacek++ 23:43
sorear It's still borked. Active destruction can't be used with dynpmcs. 23:44
darbelo sorear: But not a 100% !
Now it passes tests and all.
Also notice that two of the changes are in commented out, right abobe a statement to that fact. 23:45

Powered by Cro and the Raku® Programming Language.

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

Thank you!