Parrot 1.2.0 released | parrot.org/ | 306 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets
Set by moderator on 20 May 2009.
darbelo Should I open a ticket or is this something I'm doing wrong? 00:02
dalek cnum-dynpmcs: r47 | darbelo++ | trunk/ (4 files):
Replace����/trunk/src/pmc/decnum.pmc

   :45)
   ����Delete����/trunk/src/pmc/decnum2.pmc
   Enough prototyping, global-context is the way of the future.
Ditch the per-PMC prototype. Rename DecNum2 to DecNum. Modify examples accordingly.		 00:21
00:29 ruoso joined 00:34 bacek joined
dalek kudo: b516413 | pmichaud++ | src/ops/perl6.ops:
Add root_new dynop.
 00:47
kudo: 20ec24c | pmichaud++ | src/builtins/ (11 files):
Convert new of parrot-based things to root_new (src/builtins)
kudo: 6079a97 | pmichaud++ | src/classes/ (20 files):
Convert new of parrot-based things to root_new (src/classes)
kudo: 064be63 | pmichaud++ | src/ (4 files):
More new -> root_new conversions.
kudo: f08f5ad | pmichaud++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
darbelo Nevermind, I just saw TT#692. 00:53
00:55 ruoso joined 00:57 hiroyuki_y joined
cotto Isn't Parrot fun! You never know if it's insane or if you are. 01:07
01:14 ruoso joined 01:18 Whiteknight joined 01:19 bacek joined
Coke_afk Tene: APL? Danke. 01:27
Tene why?
Coke_afk darbelo: (catching up) - I just opened a ticket about that.
Coke Tene: if you're working on APL on Parrot, because I actually care about that language. 01:28
Tene Out of curiosity, why do you care about APL? Just general interest, or do you have a use for it?
Coke I care about only because Patrick and I worked to implement it. 01:29
Tene ah
Coke why did I do that? Basically, because Chip dared me.
Tene last I looked, i tried to move it to a .HLL, but then it couldn't load dynops oslt. 01:30
I feel more confident that I can get it working properly now.
Coke does it even build at this point?
Tene I've heard a lot about chip, but he left before I arrived, I gather.
Dunno... I'll find out once the girlfriend is done showing me silly videos. ☺ 01:31
cotto ooh. advanced smilies 01:32
dalek rrot: r39001 | whiteknight++ | branches/gc_internals:
Creating a branch to continue cleaning up the internals of the GC
 01:37
rrot: r39002 | whiteknight++ | branches/gc_internals/src/gc/alloc_memory.c:
[gc_internals] move memory.c -> alloc_memory.c
 01:40
rrot: r39003 | whiteknight++ | branches/gc_internals (1 files):
[gc_internals] move register.c -> alloc_register.c
01:42 ruoso joined
dalek tracwiki: v20 | whiteknight++ | GCTasklist 01:43
tracwiki: trac.parrot.org/parrot/wiki/GCTask...ction=diff
rrot: r39004 | whiteknight++ | branches/gc_internals (1 files):
[gc_internals] move resources.c -> alloc_resources.c
02:01 cotto joined
Coke nick afk_coke 02:06
dalek rrot: r39005 | whiteknight++ | branches/gc_internals/src/gc (3 files):
[gc_internals] start collapsing pools.c (nee smallobject.c) into api.c and system.c as appropriate
02:07 tetragon joined
dalek rrot: r39006 | whiteknight++ | branches/gc_internals (1 files):
[gc_internals] initial move of src/malloc.c and src/malloc-trace.c to src/gc/malloc.c and src/gc/malloc_trace.c. Needs cleaning
 02:09
tracwiki: v21 | whiteknight++ | GCTasklist 02:13
tracwiki: trac.parrot.org/parrot/wiki/GCTask...ction=diff
02:27 mikehh_ joined 02:33 particle1 joined 02:41 janus joined 02:42 eternaleye joined 03:20 donaldh joined 03:53 Theory joined
dalek rrot: r39007 | pmichaud++ | trunk (3 files):
[pmc]: Add C<root_new> opcode to allow creating PMCs from foreign HLL classes
 04:07
04:11 eternaleye joined 04:33 cotto joined 04:53 Theory joined 05:02 japhb joined 05:37 particle2 joined
dalek rdinal: aecc5ad | tene++ | cardinal.pir:
Also set the namespace to be returned to a calling language.
 05:47
rdinal: 144fac4 | duff++ | build/Makefile.in:
Use the parrot build dir for parrot and pbc_to_exe

blithely use the bin_dir from parrot_config which will be a lie if parrot is not actually installed anywhere. Changed the makefile to always use parrot's build dir for the parrot and pbc_to_exe executables
  (emulating rakudo here)
rdinal: 3d6959d | tene++ | :
Merge commit 'perlpilot/master'
mikehh codetest failures (+ TODO pass) - otherwise make -k fulltest PASS 05:51
06:00 cognominal joined 06:15 eternaleye joined
dalek kudo: e6b4630 | pmichaud++ | docs/ROADMAP:
Update ROADMAP.
 06:15
Tene Nice... APL can't even generate a makefile... 06:23
:)
Coke: I have a local patch that gets paraplegic to build. Can't run tests, though. 06:37
06:40 iblechbot joined 06:42 bsdz joined 06:50 flh joined
Tene work with rakudo, too, through eval 07:15
pmichaud: utf8 isn't passed through properly with eval... any ideas? 07:18
07:20 donaldh joined
mikehh nopaste? 07:23
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl i heard nopaste was at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
nopaste "mikehh" at 90.209.117.226 pasted "patch for some codetest failures at r38999" (63 lines) at nopaste.snit.ch/16628 07:27
mikehh this is a patch for some codetest failures at r38999 from make -k fulltest -> nopaste.snit.ch/16628 07:29
dalek rrot: r39008 | cotto++ | trunk (2 files):
[codingstd] a couple of codingstd fixes, patch courtesy of mikehh++
 07:55
cotto mikehh, thanks 07:58
dalek rrot: r39009 | cotto++ | trunk/t/codingstd/copyright.t:
[t] untodo the duplicate copyright test, which seems to be passing
 07:59
cotto I split it in two, since it was doing two different (if small) things.
cotto mikehh++ for that one too ;)
08:08 donaldh left 08:44 bacek joined 10:33 cognominal joined 10:39 particle1 joined
dalek rrot: r39010 | jkeenan++ | trunk/src/pmc/packfileannotations.pmc:
Eliminate trailing whitespace per mailing list report by Michael Hind.
 11:07
rrot: r39011 | jkeenan++ | trunk/docs/pdds/pdd24_events.pod:
Correct error in item numbers per mailing list report by Michael Hind.
 11:14
11:20 donaldh joined
dalek a: 37cb45f | fperrad++ | src/ (2 files):
handle $?FILES for traceback
 11:26
a: 475bbcc | fperrad++ | src/lib/luaaux.pir:
improve traceback output
11:37 particle joined 11:38 particle1 joined 12:12 flh joined 12:16 Theory joined
dalek rrot: r39012 | jkeenan++ | trunk/t/codingstd/copyright.t:
Revert r39009. Due to differences between the 'prove' associated with Perl 5.8 and that associated with Perl 5.10, we get different results on the duplicate copyright tests.
 12:23
12:24 ruoso joined 12:39 Whiteknight joined 12:41 rg1 joined 12:55 PacoLinux joined 12:56 riffraff joined
Coke tene - you have commit bits to APL, knock yourself out. 12:57
msg tene - you have commit bits to APL, knock yourself out. 12:59
purl Message for tene stored.
13:00 NotFound joined 13:22 riffraff joined
Coke msg cotto please stop untodo'ing that test. Please. =-) 13:24
purl Message for cotto stored.
13:27 gryphon joined
dalek a: 61374db | fperrad++ | src/lib/luaaux.pir:
fix previous commit
 13:32
a: 0bbfd9e | fperrad++ | src/POSTGrammar.tg:
fix luap.pir
a: 84a6ced | fperrad++ | src/POSTGrammar.tg:
pathname must be be escaped
a: ddd9113 | fperrad++ | t/ (26 files):
fix tests for absolute path on Windows (C:\\somewhere\\...)
13:38 Theory joined
Coke if I have a bunch of perl files that depend on including one of the parrot installed .pm's, I'm guessing I should make a local generated file that updates @INC to the right place, and just have everything refer to the generated file. 13:39
sound reasonable?
Coke wonders what "Object must be created by a class" means. 13:40
13:40 Casan joined
PerlJam Coke: objects can't be created by other objects? 13:41
Coke it's some behavior that changed since last partcl walked the earth. 13:43
so, sure; what does that mean, though? (will track down the actual pir once other thigns are working.)
Whiteknight Coke, is that an error message that you saw? 13:58
Coke Whiteknight: yes, in partcl-latest.
trying to resurrect the test suite as time permits.
Whiteknight i think that error message comes from src/pmc/object.pmc:init 13:59
so somewhere somebody is probably doing a "$P0 = new 'Object'"
dalek rtcl: r350 | coke++ | trunk/ (4 files):
Add Parrot::Installed.pm

the installed lib dir to our path; figure out the path at config time		 14:00
14:03 Theory joined 14:22 Andy joined 14:33 whoppix joined
dalek kudo: d163016 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 392 files, 11342 passing, 0 failing
 14:34
14:35 dalek joined
Infinoid Coke: Ok, we should now have notifications for trac.parrot.org/parrot/timeline?ticket=on 14:36
dalek rtcl: r351 | coke++ | trunk/t/cmd_ (50 files):
Tests only need to run from top level build dir.

Fix a few perl-based scripts that need the Installed parrot config.		 14:45
14:47 Plisk joined
Coke here's what's generating the failure: 14:59
25792 new P0, "Undef" P0=PMCNULL
25795 assign P0, P1 P0=Undef=PMC(0x82acde8) P1=Object(TclArray)=PMC(0x82addc0)
Whiteknight ah, that's quite interesting 15:00
I wonder if that sequence was always causing a failure, or whether that's new
15:01 dalek joined
Whiteknight Can you do me a favor, create a ticket for that and assign it to me? 15:01
Coke it worked at some point.
Sure.
Whiteknight I think I know how to fix it quick, but I can't till I get home tonight
Coke Whiteknight: ugh. I'll have to wait for 1.3, won't I. :| 15:07
dalek TT #696 created by coke++: Can't assign an object to Undef.
Whiteknight I don't think so, no
is partcl targetting Parrot HEAD? 15:08
Coke Whiteknight: no.
it's targetting "installed parrot" which basically means "releases".
Whiteknight urg
you could probably do a pure PIR workaround if you need to work around it now 15:09
Coke esp. if the current behavior of that snippet is intentional. 15:10
dalek rtcl: r352 | coke++ | wiki/ParrotIssues.wiki:
added another parrot bug.
Whiteknight no, I don't think it's intentional
Infinoid cool. dalek's trac ticket notifications are faster than my email client 15:12
Coke Infinoid: does it track every ticket status?
Infinoid It tracks the major state changes only. See trac.parrot.org/parrot/timeline?ticket=on
so it should emit messages for created, closed and reopened 15:13
Coke Infinoid++
Infinoid and it shouldn't annoy us every time someone adds themselves to cc: or adds a milestone/keyword or trivial things like that 15:14
15:20 donaldh joined
Coke ah. "anyone test "language_output_is" in an installed parrot?" he asked, expecting the answer no. =-) 15:23
Infinoid *crickets chirping* 15:24
Coke all my perl based tests are failing.
Infinoid lemme guess, path issues? 15:25
Whiteknight maybe Perl is the problem?
Whiteknight is only joking! Perl is good 15:26
Coke # '/usr/local/lib/parrot/1.2.0/tools/parrot ........../tcl.pbc t/cmd_cd_1.tcl' failed with exit code -1 15:27
that command line seems wrong.
(path to parrot is wrong, the ..... is wrong...) 15:28
15:29 Plisk joined
dalek kudo: 7c5be8b | pmichaud++ | docs/ROADMAP:
Minor ROADMAP improvement.
 15:29
kudo: 97c7cec | pmichaud++ | docs/ChangeLog:
ChangeLog updates for release
kudo: dafdc06 | pmichaud++ | docs/announce/2009-05:
Final 2009-05 announcement updates.
15:30 Theory joined
NotFound Someone has some objection of reusing the file_size attribute of the filehandle pmc to store the pid of the child process? 15:34
When the handle is a pipe, that is.
dalek kudo: c4fa3ba | pmichaud++ | docs/release_guide.pod:
Update docs/release_guide.pod .
 15:35
Infinoid NotFound: Not per se. But I'd prefer to extract the necessary bits of Filehandle into a more generic base class, to make sockets and pipes saner
(that's one one of the things on my "when I get around to it" list) 15:36
Whiteknight Infinoid: I agree with that 100%
NotFound Infinoid: me also, but some people are demanding to have working pipes NOW
Whiteknight Have a "Stream" base class, and derive from that Socket, FileHandle, and Pipe types
Infinoid I was thinking of calling it Handle, but that works too 15:37
Whiteknight NotFound: We're all volunteers, things get implemented when we ger around to it
Infinoid perl 5's IO:: class heirarchy is fairly sane, I wouldn't have a problem with following that model
Whiteknight NotFound, best idea is still to create a Pipe PMC type, and then we can start abstracting and refactoring things later
probably anyway, I don't know if people would perfer FileHandle to do piping too 15:38
Infinoid +1 Pipe PMC
NotFound Whiteknight: that will need a lot of changes
Infinoid it's a branch-worthy task
Whiteknight NotFound: you think so? I don't think it would require too much
the only changes would be at PIR-level, doing 15:39
"new 'Pipe'" instead of "new 'FileHandle'"
NotFound Whiteknight: the current way is: first create a Filehandle, then open.
Whiteknight: you forget the open opcode
Whiteknight $P0 = new 'Pipe' \\n open $P0 15:40
the open opcode calls the "open" method, which the Pipe PMC will provide
doesn't require any changes internally
Infinoid $P1 = $P0.'reader'()
$P2 = $P0.'writer'()
NotFound open 'fileaname_or_command', 'mode'
Whiteknight NotFound: Okay, I forgot about the two-operand version. Add a "p" to the mode that uses a Pipe instead of a FileHandle 15:41
I think that's in the PDDs anyway
Infinoid Do you intend to follow perl5-like "| command" semantics for open()'s filename parameter?
oh, ok 15:42
Tene Coke: what email address did you grant privileges for? i can't seem to authenticate...
NotFound Whiteknight: that way is done now, but the way it works is by creating a filehandle and then calling the open function
Whiteknight yeah, PDD22 says to use the p mode for Pipes
NotFound: Well it's a small change to use a Pipe type instead
NotFound And I didn't write that, it was already present, I just fixed it.
Infinoid when we have a Pipe PMC, the FileHandle can pmc_morph to it 15:43
Whiteknight maybe a Pipe type doesn't make sense. I'm no architect
Coke tene: for APL 15:44
?
NotFound I'm not opposing to the creation of the pipe pmc, I'm just asking about a simple solution for the current failures.
Tene Coke: yes
Coke code.google.com/u/@WRRfRF1YARJBXQd6/ 15:45
Infinoid the Pipe PMC doesn't necessarily have to be a direct part of the "get output from shell commands" feature, anyway
The one I was thinking about writing is more low level than that... it's just something that knows how to call pipe() on the C level and implement 'reader' and 'writer' methods which return separate handles for each
Tene huh
Coke tene: did you check it out from http: ? 15:46
or https ?
purl hmmm... https is almost same or web.. or blocked
Whiteknight Infinoid: So you would have a Pipe type, a PipeReader, and a PipeWriter?
Coke you might have to svn reloc.
Infinoid or a Pipe type which returns generic Handle objects, doesn't matter much
Tene ah, googlecode password != google account password
Infinoid Basically the same as perl5's IO::Pipe
NotFound Did we have a generic handle object? Filehandle doesn't inherit from anything 15:47
Infinoid Not yet, I want to write one.
Since we don't have one yet, Socket is a bit ... weird at the moment 15:48
NotFound Well, I'm going to commit my workaround. The open_p_s_s opcode can be modified later to create and return some other type. 15:49
When we have it.
Infinoid NotFound: using FileHandle is fine for now, I was just talking about what I wanted to do in the future :)
NotFound Yeah, but I'm attending the demands from pmichaud of having some working pipe mechanism as soon as possible. 15:50
Infinoid No, absolutely. working trumps perfect, every time
NotFound I agree that is an important featute for any realistic usage
Infinoid (having some working pipe mechanism)++
Tene Coke: committed. 15:53
dalek TT #697 created by coke++: Parrot::Test "language_output_is" fails in installed parrot. 15:54
rtcl: r353 | coke++ | wiki/ParrotIssues.wiki:
another parrot bug.
Coke GAH. I should not have to keep approving posts from googlecode to googlegroups. :| 15:55
pima.
15:55 jan joined
Tene ouch 15:56
dalek raplegic: r5 | t...@allalone.org++ | trunk/ (3 files):
(from /trunk/config/makefiles/root.in

   ����Delete����/trunk/config/makefiles/root.in
   Steal a Configure.pl from Rakudo... possible to build now.
Tests still won't run...		 15:58
raplegic: r6 | t...@allalone.org++ | trunk/ (2 files):
(from /trunk/APL.pir

   ����Modify����/trunk/build/Makefile.in
   Move from APL to apl to work with other languages.
Infinoid uck, I need to fix that parser. 15:59
16:00 flh joined
dalek rrot: r39014 | NotFound++ | trunk/src (2 files):
[core] fix unix pipe handling, now write pipes must works reliably
 16:03
Tene pmichaud: what needs to be done to support utf8 in a PCT repl? 16:04
APL is kinda crippled without it...
pmichaud add 'encoding'=>'utf8' to the call to 'command_line' 16:05
NotFound Someone can unskip the 4 test and give a try in t/op/io.t ?
Tene pmichaud: it's there already 16:06
pmichaud okay, then set the encoding on stdin prior to calling 'command_line'
(yes, we can fix this in pct as well -- these are quick fixes that get us through the issue for now)
Tene what kind of object does getstdin return? io.pod claims parrotio, but there's no parrotio.pmc. 16:07
NotFound Tene: a filehandle
purl it has been said that a filehandle is the structure for manipulating files. It's the FILE in open FILE, "/tmp/bobo" or die $!.
pmichaud it's a filehandle
Tene ah 16:08
pmichaud just do $P0 = getstdin, then $P0.'set_encoding'('utf8')
(I might be misremembering the method name)
Tene it's 'encoding'
hmm... doesn't work... 16:13
purl Look buddy, doesn't work is a strong statement. Does it sit on the couch all day? Is it making faces at you? Does it want more money? Is it sleeping with your girlfriend? Please be specific!
Tene PGE can't parse it. 16:14
but works fine when it's in a file.
nopaste "tene" at 166.70.38.237 pasted "encoding fail in apl... :(" (10 lines) at nopaste.snit.ch/16631 16:15
16:16 dalek joined, iblechbot joined 16:17 bacek joined
Tene late to work... later. 16:19
pmichaud it may be an issue with reading utf8 from terminal/stdin
we have had similar issues with rakudo
Infinoid "t...@allalone.org" is Tene, right? 16:21
Tene Yes.
Infinoid will add a karma alias 16:22
16:24 ilia_ joined
dalek rrot: r39015 | Infinoid++ | trunk/CREDITS:
Add a karma alias for tene's googlecode account.
 16:26
Infinoid NotFound: test passes here on linux/amd64 (and no leftover processes) 16:31
16:35 Themeruta joined
NotFound Infinoid: good. I'm going to unskip the test, then. 16:38
Infinoid ok 16:41
NotFound++
16:43 particle joined
dalek rrot: r39016 | NotFound++ | trunk/t/op/io.t:
[test] unskip pipe write test, TT #661
 16:46
16:54 Theory joined
dalek kudo: 79d0b9a | pmichaud++ | docs/release_guide.pod:
Fix "git push --tags" in docs/release_guide.pod .
 16:56
allison Whiteknight: what's broken now about pipes is the low-level C code, it doesn't much matter if a Pipe is a separate PMC 16:57
NotFound allison: the C code isn't broken now, at least in the unix incarnation. 17:04
The win32 one is not broken, it just does not exist X-) 17:06
allison NotFound: I saw the commit message, just looking over the change log, well done!
NotFound Thanks
allison NotFound: you can go ahead an add a second ATTR to FileHandle, rather than reusing file_size. The old ParrotIO had two "process" attributes (what's now called 'os_handle'), for pipes. 17:09
NotFound allison: did we plan to allow bidirectional pipes? 17:10
allison NotFound: win32 pipes have never worked, so no loss. It would be nice to get them to work someday
NotFound: you mean read and write? if possible, yes
NotFound That will need to add another atribute for a second os handler. 17:11
cotto Coke, sorry
allison NotFound: okay, then add two new ATTRs, one for the second OS handler, and one for the pid 17:12
NotFound Ok 17:14
Coke allison: partcl's 'make test' now actually passes some tests. 17:16
allison Coke: how many for you?
(I'm trying to figure out what's different in my checkout) 17:17
Coke at a guess, you had your build directory lying about. =-)
17:17 contingencyplan joined
allison hmmmm I thought so too, but I ran Configure.pl with no arguments, so it used the parrot_config in my path 17:18
that's the installed one, and I deleted the build directory for that one 17:19
Coke: btw, the tests I modified were just removing some hard-coded 'languages/tcl/runtime' paths from load_bytecode 17:20
Coke k.
I haven't dug through all remaining failing tests, as the two sources I found are causing a LOT of them.
(tickets opened for both of them.) 17:21
allison Coke: I also have an include/ directory at the top-level
Coke Files=74, Tests=1255, 179 wallclock secs ( 0.38 usr 0.20 sys + 159.07 cusr 5.54 csys = 165.19 CPU)
... that doesn't help. moment. 17:22
allison (it's an include directory containing macros.pir, mathops.pir, and returncodes.pasm 17:23
Coke I do not see a test summary.
379 failures. 17:24
allison: just relocated from src ?
allison okay, that's about twice as many as I see
Coke which version of parrot are you running against?
(1.2.0 here)
allison Coke: aye, relocated, because Parrot will pick them up in include/ at the top level, with no path 17:25
I'm running against my installed 1.0
Coke: (re: relocated) so, they can be included as .include 'macros.pir', which will also work after they're installed, instead of .include 'src/macros.pir', which won't work installed 17:27
Coke: I get a lot of these kinds of failures, where it tries to run: /usr/lib/parrot/1.0.0/tools/parrot ......../tcl.pbc t/cmd_source_2.tcl 17:28
Coke allison: that's TT # 697
I'm seeing TT #696, you're probably not. 17:29
17:29 Theory joined
allison Coke: yup, it's 697 17:31
Coke: and you're right, I'm not seeing 696, I'm assuming that's new with 1.2?
or 1.1?
purl well, 1.1 is best :)
allison oh, 696 looks like a morph bug 17:32
Coke (also have you updated? had several commits today.) 17:39
allison Coke: nope, updating now 17:42
I had 198 test failures before, will see after
Coke feel free to commit the move of the include files. 17:43
allison okay 17:44
17:46 bacek joined
Coke 'make spectest' now is able to trip over TT#696. 17:46
(before it wouldn't run.)
allison progress :) 17:47
updating to the latest, I'm still at only 198 failures in my working copy 17:48
Coke I am now hopeful that at least for linux, 'make test' will work on parrot 1.3
allison trying a fresh checkout to see the difference
Coke (osx is still fubar.)
dalek rtcl: r354 | coke++ | trunk/tools/tcl_test.pl:
We don't live in the parrot repository any more.
nopaste "coke" at 193.200.132.135 pasted "make test from partcl, parrot 1.2, linux" (1893 lines) at nopaste.snit.ch/16632 17:50
Coke I might have mis-added, also. 17:51
Looks like it's not just language_output_is that's borked. 17:55
parrot_output_is doesn't fare much better.
er, s/parrot/pir/ 17:56
dalek rtcl: r355 | coke++ | trunk/t/internals/ (3 files):
not in the parrot repository anymore.
 17:58
18:08 davidfetter joined
Whiteknight do we have anybody around who is working on the Win32 pipes? 18:10
I could break out my copy of Petzold and tackle them soon if they're in demand
allison Coke: the fresh checkout is also 198 test failures
purl okay, allison.
allison purl: forget the fresh checkout
purl allison: I forgot fresh checkout
NotFound Whiteknight: Infinoid said yesterday that will take a look this week 18:12
Coke allison: again, parrot 1.2?
Infinoid Whiteknight: Yeah, I'll take a look this weekend if noone beats me to it
Whiteknight Okay, if you're looking at it I won't spend time on it 18:13
I
've got plenty of other thigns to keep me busy
allison Coke: nope, still 1.0. I'm just narrowing down the possible cause of failures. (and making sure my changes in my working copy aren't relevant) 18:14
Coke ok.
allison Coke: any objections to a simple test framework lib local to Partcl instead of Parrot::Test?
Coke: it may ultimately end up as the replacement for Parrot::Test, but in the mean time frees us up to work on it quickly 18:15
Coke no. but if we're going to do that, I recommend not installing the testing infrastructure in teh first place.
no objection, that is.
allison Coke: not installing Parrot::Test? yes, if we can't fix it up to work installed, we'll just stop installing it 18:16
dalek rrot: r39017 | NotFound++ | trunk/src (2 files):
[pio] new attribute process_id in filehandle pmc
allison (or install the Tcl version, if it works)
18:27 bacek joined 18:37 particle joined, flh joined
dalek rrot: r39018 | pmichaud++ | trunk/compilers/pge/PGE/Exp.pir:
[pge]: Switch PGE's code generation to use root_new instead of new.
 19:10
19:20 donaldh joined
dalek rrot: r39019 | pmichaud++ | trunk/runtime/parrot/library/PGE/Perl6Grammar.pir:
[pge]: Switch Perl6Grammar to use root_new instead of new in codegen.
 19:24
NotFound Soemone said that rakudo was not ready to be built with an installed parrot? 19:26
pmichaud that's my current understanding, yes. 19:27
although I would phrase it as "an installed parrot is not sufficient for building/testing rakudo" 19:28
NotFound My last test shows that is semi-true. It builds... as long as the devel tree is still in place X-)
pmichaud yes, rakudo always builds against the build tree, not the installed version. 19:29
NotFound Maybe is just a thing of choosing the appropiate keys from the config
pmichaud No, the problem is getting an installed parrot to recognize dynops/dynpmcs 19:30
purl okay, pmichaud.
Coke tcl is getting really close to building against only an installed parrot.
(and we have dynpmcs and dynops). But only on linux, as far as I know.
NotFound The first problem it barfs on is to locate PGE/Perl6Grammar.pbc
pmichaud well, "installed parrot" might mean "install-dev" 19:31
Coke yes.
pmichaud iiuc, "make install" (isntead of "make install-dev") is certainly not sufficient for building Rakudo in any case.
Coke sorry, figured that was obvious.
pmichaud I don't know if "make install" also installs PGE/Perl6Grammar.pbc 19:32
NotFound pmichaud: no, the error message contains the full path on the build tree
And before that it says that the Makefile is out of date 19:33
pmichaud oh, you probably need to re-run Configure.pl then
NotFound pmichaud: it keeps saying it again and again
cotto NotFound, I've been building Rakudo with an installed Parrot for a while, but it requires frequent Parrot updates.
(and install-dev) 19:34
NotFound cotto: without the build tree in place?
mv parrot noparrot
cotto The build tree is still there. I hadn't thought to see if it'd work without that.
pmichaud cotto: it probably won't.
cotto let's find out
Coke until rakudo stops relying on particular svn releases, there's not much point in building against an installed parrot, is there? 19:35
(I mean, it'll easy the transition later, but it's not practical for anyone who isn't hardcore.)
pmichaud Coke: one could always choose to install a svn release that isn't an official Parrot release
NotFound Coke: being able to do it may help to clarify dependencies 19:36
pmichaud also, one could choose to install a released version of Rakudo, which does only build against released parrots
but no, someone who is following Rakudo development closely generally can't rely on the latest Parrot release
purl okay, pmichaud.
NotFound BTW, the fakecutable compiling is much faster now. What has changed? 19:37
pmichaud I don't know. I don't think I changed anything.
cotto Util++ did some work on pbc_to_exe 19:38
Coke (install a svn release that isn't a releas) yes, but that's not normal behavior. =-)
NotFound Last time I tried it froze my laptop. Now has do it in a few minutes.
pmichaud I didn't see if pbc_to_exe changes made it into trunk -- I'll have to look.
cotto istr that he added the fast code for gcc, but kept the old (slow) code for msvc 19:39
NotFound In fact less than a minute, I think
pmichaud My pbc_to_exe is still generating the old-style code
not the fact gcc version 19:40
cotto pmichaud, you're right. it won't work without the build dir in place
NotFound I don't see the conversion to string literal that was talked about, certainly.
pmichaud (and yes, I'm running gcc)
s/fact/fast/
cotto is 0 for 2 so far. It's not looking good. 19:43
at least my Progress Quest guy is leveling up
19:44 donaldh joined
cotto pbc_to_exe does seem faster now, though not as fast as util's original patch made it 19:45
NotFound cotto: for me is a big difference, now I can build and test rakudo 19:51
Coke msg allison I have a POC for tcl_output_is, will convert over the test suite as time permits.
purl Message for allison stored.
Whiteknight I think Util mentioned using an attached binary resource on msvc to speed it up on that platform too
NotFound I was unable to do that on my home machines since some weeks ago 19:52
Whiteknight a PGE optimizer is becoming a necessity, I think
NotFound I'm using gcc on linux
Coke can someone on windows give the latest version of partcl a shot and see how far you et?
pmichaud Whiteknight: we really need a profiler more than an optimizer at this point
although PGE optimizations will be coming reasonably soon 19:53
Coke (requires installed parrot; 1.0 or higher)
Whiteknight pmichaud: at the risk of making people repeat themselves, what would be needed in a PIR optimizer?
er, PIR profiler?
pmichaud something that tells us how much time is being spent in each sub would be a start
Whiteknight okay, so you're more interested in a Sub-level profiler then in a opcode-levle profiler? 19:54
cotto There definitely haven't been any substantial changes to pbc_to_exe recently (except an accidental one my me that I undid).
Coke Whiteknight: there's a ticket regarding the generation of callgrind output, which would be peachy.
Whiteknight: chromatic suggested a new callgrind runcore.
19:55 Austin_Hastings joined
cotto trac.parrot.org/parrot/log/trunk/t...to_exe.pir 19:55
pmichaud Whiteknight: for me at this point a sub-level profiler is far more useful. I don't think opcode-based profiling would tell me a lot, unless we happen to be calling a few very expensive opcodes and I'm unaware of it.
Whiteknight I'm hesitant to do anything PCC-related while allison is working on her branch. I could take a look at the callgrind thingy
Austin_Hastings Hey, can I ask a not-1.2-related question? 19:56
Whiteknight I don't know much about callgrind or it's output format though
Austin_Hastings: yes
Coke Whiteknight: we already HAVE an opcode level profiler.
"parrot -p"
Whiteknight Coke: Do we? I was unaware that we had one that worked
Whiteknight needs to do more experimenting with that kind of stuff
Coke It's from Dan-time.
Austin_Hastings What's the situation in pir with respect to $P-registers after a sub or method call? Are they all gone and need a reload, or do they hold their value?
Whiteknight Austin_Hastings: when a sub returns, it's dynamic context (registers, etc) are destroyed and garbage-collected 19:57
Austin_Hastings (I ask because I notice that PCT is generating VAR:scope('parameter') as a lex, rather than register, variable.
@WhiteKnight: I'm not asking about the sub called, but the caller's $P-registers. 19:58
Whiteknight PCT generates them as lexicals so they are visible to internal scopes, such as nested blocks
Oh, the caller will maintain pointers to those registers after the called sub returns
Austin_Hastings Aha! It's for dynamic scoping rather than lexical, eh?
Whiteknight yes, dynamic scoping
purl well, dynamic scoping is perfectly acceptable when used for something it's suitable for
Whiteknight purl forget dynamic scoping 19:59
purl Whiteknight: I forgot dynamic scoping
Austin_Hastings Okay, cool. Thanks.
@purl - I forgot it, too. Funny how that works. :)
pmichaud PCT thinks that most languages will want to have parameters available a lexically-scoped variables. 20:00
20:00 Theory joined
pmichaud So it implements them that way. 20:00
*available as
Whiteknight and on that note, I am leaving. Later 20:01
pmichaud it might not be implemented yet, but I'm planning that non-lexical parameters might be possible by not providing a :name
i.e., a parameter without a :name() attribute would provide a register but not a lexical alias.
Austin_Hastings I saw where the params are named anonymously, then loaded into .lex vars. So it seems like you're halfway there.
But frankly, I want my (register) params to have a name. 20:02
I think this is where you start pushing things into the pirflags() attribute.
pmichaud and you don't plan to access them from nested lexical blocks?
Austin_Hastings I think that depends on what you mean by "nested lexical block" - and I'm not parrot-dev --savvy enough to be able to answer you. 20:04
pmichaud okay, how about a Perl 6 example...?
sub foo($x) { if rand { say $x } }
Austin_Hastings How about a C example?
pmichaud okay, a C example
Austin_Hastings Because that's the model.
Declare a param in a sub, it's visible in all the curly-blocks within that sub, but not to any call-ees. 20:05
pmichaud int foo(int x) { if (rand() < 0.5) { int myvar; printf("%d\\n", x); } }
Austin_Hastings As I understand it, based on the information I just got, putting it in a $P-register would do the trick, no need for a .lex entry.
Right.
x is visible to all of the stuff you just wrote, but not visible inside rand() or printf(). 20:06
pmichaud in the C code I just gave, the then portion of the 'if' statement is a nested lexical block
Austin_Hastings Okay.
pmichaud in Parrot, that ends up being a separate Parrot sub
NotFound Austin_Hastings: curly blocks are usually translated to separate pir subs, that's the reason to use lexicals
Austin_Hastings But in PAST it's a Stmts, not a Block, right?
pmichaud the problem is handling that "int myvar;" line
"myvar" should only be visible within the if block
Austin_Hastings ... 20:08
The trick I've been using is the locally-maintained stack of Blocks for scoping
pmichaud right. Each Block corresponds to a separate Parrot sub
Austin_Hastings So I'm not passing the blocks out as part of the final PAST, just replacing them with Stmts if I can get away with it. 20:09
pmichaud okay, here's a somewhat trickier example, then
20:10 eiro__ joined
nopaste "pmichaud" at 72.181.176.220 pasted "C code with nested lexical blocks" (10 lines) at nopaste.snit.ch/16635 20:10
eiro__ hello
20:11 allison joined
Austin_Hastings Got it. 20:11
pmichaud Note that the 'i' that is in the true part of the if statement is not the same as the 'i' that the else sees
Austin_Hastings Yep.
Is there enough internal linkage with the "hidden Block" approach for that to fall out right? 20:12
I haven't got that far yet.
pmichaud you'll have to manage your own register mappings to make it work.
Austin_Hastings Eek.
pmichaud i.e., if you're wanting to avoid PCT's PAST::Block structure 20:13
Austin_Hastings Or make the true block a Block.
pmichaud right. PAST::Block is intended to handle lexical scoping.
But it does mean that things are stored as Parrot lexicals.
Eventually I want PCT to be smart enough to avoid creating a separate lexical sub when one isn't needed (as would be the case for the 'else' block in the nopaste) 20:14
Austin_Hastings But not right now, eh?
pmichaud it's non-trivial.
NotFound my @parrot_config_exe = qw( parrot/parrot_config ../../parrot_config parrot_config );
That s the order in they are checked?
pmichaud yes.
Austin_Hastings So the "right" thing to do is to adopt an "old C" style model, with all the lexicals at the top... 20:15
pmichaud Austin_Hastings: and even if PCT can optimize the 'else' block, it would have to do something to handle the 'if' block.
NotFound Maybe just puttinng plain parrot_config in the first place will solve some problems.
pmichaud NotFound: I want Configure.pl to prefer a locally generated parrot_config to any other.
NotFound: changing the order doesn't improve at all the "build Rakudo against installed Parrot" situation. 20:16
NotFound Yes, I was thinking about the wrong problem
Austin_Hastings Hey, here's a couple of other questions. 20:17
Is there any way to suppress the .return() at the end of a generated sub?
and (2) What's the right way to code PAST for returning a list of values? 20:18
a la (x, y, z) = foo()
pmichaud We don't have a solution yet for #2.
(haven't needed it yet)
Austin_Hastings Okay.
What's parrot doing internally when that happens?
pmichaud I'm not sure about suppressing the .return() at the end of a generated sub -- I'd have to think about it a bit.
Austin_Hastings Don't waste any time thinking about the .return thing - I'm generating my own, so it's just a bit of extra code. If there's not already a "don't issue a return()" flag, then stop. 20:19
pmichaud stops :-)
Austin_Hastings :)
But the return-a-list thing - parrot is doing this CPS thing, right, so they are like args in the mirror? 20:20
pmichaud yes.
Austin_Hastings But I don't really know how args get handled.
pmichaud .return (1,2,3) returns three values
Austin_Hastings Do they go into registers, or what? 20:21
pmichaud and ($I0, $I1, $I2) = foo() would place the first returned value into $I0, the second into $I1, the third into $I2
Austin_Hastings Right. I've seen that in some PIR.
So I wondered how to code PAST for it.
pmichaud there's not a PAST coding for it yet.
again, we haven't needed it yet.
PAST isn't intended to represent every possible PIR construct -- just the things common to dynamic languages (more) 20:22
Austin_Hastings You see there? You get rid of the whole "list context" thing, and everybody stops thinking about returning multiple values...
pmichaud yes, list assignment is common to dynamic languages, but thus far it hasn't been expressing itself at the PAST level 20:23
Austin_Hastings Ahh. Are the rakudo folks doing an Array then?
pmichaud Also, Parrot and PIR are about to undergo substantial changes to the calling conventions, so there's not a lot of point in putting effort here until we get to that point 20:24
i.e., until those are in place.
Austin_Hastings Oh frabjous day.
Coke if I want to have a #! parrot shebang, must I specify the full path for it to really work?
pmichaud right now rakudo isn't supporting multi-argument returns. 20:25
Austin_Hastings Slackers.
purl slackers is a film which features the female drummer from the Butthole Surfers discussing Madonna's pubic hair
pmichaud because what really needs to happen is that the multi-arguments get placed into a Capture object, and that Capture object is what gets returned to the caller
Austin_Hastings Maybe in P6.
pmichaud but note that in that case, PAST really only needs to support returning a single (Capture) object
Austin_Hastings brb 20:26
pmichaud and that object then contains the return values that are to be bound in the caller
PerlJam Coke: you mean as opposed to a relative path or what?
Coke: you should be able to use #!./parrot or #!../../parrot/parrot or what not. You can even use #!/usr/bin/env parrot if you've got things setup right 20:27
Coke PerlJam: as opposed to no path.
literally, I want "#! parrot" to work. 20:28
PerlJam oh
pmichaud afk # tree planting
PerlJam that only works if parrot is in the same dir I think. 20:29
Coke PerlJam: that only works if . is in your PATH, I think. =-)
PerlJam er, yes.
Coke bah. ``.include "test_more.pir" '' dies on parrot 1.2 installed.
allison aw... sweet! I'm down to 8 test failures in Partcl (on 1.0)
Coke allison: uhoh. 20:30
Austin_Hastings Okay. New category: namespaces.
PerlJam so, just make sure you've got your environment setup correctly and parrot in the right place and "#! parrot" will work :)
Coke you didn't roll your own tcl_output_is, did you?
PerlJam: ah. my failure is probably related to ".include test_more.pir" dying.
Austin_Hastings Is it the case that the "true" namespace for something is $HLL/$NAMESPACE/name?
allison Coke: no, I just changed how Parrot::Test::Tcl was calculating the path to parrot and tcl
NotFound PerlJam: then you try in a diffrerent unix incarnation, and it stops working X-)
Coke allison; ok. I re-rolled both tcl and pir _output_is. 20:31
PerlJam NotFound: hey, AFAIK, he was only talking about *for him* :)
allison Coke: do you want me to send you mine as a patch?
NotFound PerlJam: then subst "you" X-)
Austin_Hastings That is, according to PDD whatever-it-was, that a Perl6 object Foo::Bar::dog winds up as ::perl6::Foo::Bar::dog? 20:32
(modulo smileys on your end)
PerlJam Austin_Hastings: what are all of those :: about? Parrot doesn't grok those :) 20:33
Austin_Hastings Maybe not, but I'm faster at :: than I am at ';' 20:34
Coke allison: I'd rather not rely on Parrot::Test at all.
at least for now.
allison Coke: agreed
NotFound PerlJam: tell the same to allison and Coke ;-)
Coke I'll get that pushed later.
(er, later tonight) 20:35
Austin_Hastings But if you prefer, is the "one true namespace" of perl6's Foo::Bar::dog going to be [ 'perl6' ; 'Foo' ; 'Bar' ] with 'dog' as a local symbol?
allison Coke: how are you getting the path to the parrot executable in your changes? Mine pulls them from the Perl Parrot::Config, but would be better to pull them from parrot_config
Coke I'm assuming it's in my path. =-) 20:36
I can fix that.
Austin_Hastings @NotFound - that was the first thing I changed. :)
allison Coke: I'm just using 'bindir'
NotFound Coke: I think that if parrot_config is in the path there are lots of chances that parrot is also 20:37
allison Coke: aye, pulling parrot from the path will work if it's installed in standard location, but it is handy to be able to test it on various temporary install directories 20:38
NotFound: except, you may want a different parrot_config than the one in the path, and then you want to test against the different parrot too
Austin_Hastings @pmichaud - while I'm thinking about it, I added a little bit to PAST. I've created a 'goto' and a PAST::Label with the obvious connection. (And no knowledge whatsoever about the higher level requirements vis-a-vis control contexts, exception handling, etc.)
@allison - Java has a trick for this 20:39
allison NotFound: I've currently got 3 parrot installs, and I test against all three
Austin_Hastings The whole "select alternative" thing
Coke allison: done, gets it from wherever you config'd partcl wth
allison Coke: you rock! 20:40
purl Dis is the drum
Coke are you able to run t/internals/select*.t ?
allison Coke: nope, those completely fail for me 20:41
Coke TT #692 is killing those for me.
it finds the .include, which tries to load a .pbc, which doesn't exist, and the fallback goes boom.
allison Coke: okay, let me do a local 1.2 install
NotFound Austin_Hastings: yeah, and maybe that is the main reason that forces to use a different classpath for each application in too much cases
Coke allison: we can avoid that issue by just inlining the code from test_more.pir that we want.
NotFound Coke: An include that loads a pbc? Why? 20:42
20:42 donaldh joined
allison Coke: a reasonable stop-gap. I'd rather keep test_more in one place if we can, but if we can't, we can't 20:42
Coke NotFound: look at parrot's test_more.pir
It's just to avoid having the same boilerplate everywhere. 20:43
allison Austin_Hastings: parrot has a way to do it too, just pull the path to the parrot executable from parrot_config. Everything else happens automatically.
Coke in fact, I probably will just inline that in partcl also; parrot may use that dozens of times, but I only use it 2x. 20:44
Austin_Hastings Well, as long as that problem's solved... :;-)
allison Coke: oh, you just mean the little test_more.pir include, not the whole PIR Test;More library? yeah, I'd totally go for inlining that
NotFound Coke: what I read in that file is: "Feel free to use Test::More directly" ;)
Coke NotFound: yah. do a blame on that line. :P 20:45
doesn't change the fact that TT #692 is broken. =-)
allison: ah, can't inline it. 20:46
because test/more.pir tries to load_bytecode a .pbc , BOOM.
so we're scr0d.
allison Coke: same error as TT #692? 20:47
Coke Yes.
Test::More tries to load Test::Builder... boom
20:47 Tene joined
allison okay, will take a look. It's an odd error. 20:47
clearly Tcl code is able to load some libraries 20:48
Coke allison: load_bytecode "foo.pir" works.
allison but not foo.pbc?
Coke allison: load_bytecode "foo.pbc" barfs, if only foo.pir exists.
if foo.pbc exists, it's fine.
SFAIK.
allison ah, okay, I understand
yes, that should be fixable
NotFound I think that this may be due by imcc setting flags to tell himself what is doing 20:50
20:54 Austin_Hastings left
allison Coke: yes, it is using the "extension as passed in" instead of the "extension as found" to determine how to load the file 20:55
Coke ah, so that doesn't even work in build dir? 20:58
NotFound The problem is that those pbc are not in the installed runtime, and they must 20:59
Well, one of the problems
purl one of the problems is probably that most of the people who work at the World Wide Web Consortium are not practical people. This reminded me of a post made by Russell Beattie, PHP Web Projects Continue to Impress Me, where he states in the end:
Coke no, one of the problems is <reply>
purl okay, Coke.
allison Coke: yup, it's not an install problem, just a general problem 21:01
Coke: testing a fix now
NotFound Is also a install problem, IMO
afk_Coke NotFound: how? 21:02
NotFound The pbc must be here
Coke that's a separate issue.
allison NotFound: as long as the .pbcs are in a path that parrot searches, we're fine
Coke if the fallback is working, we don't NEED the .pbc
NotFound allison: but they aren't
Coke right. we're only installing the PIR, not the PBCs.
but if the fallback is working, the install will still work.
allison NotFound: yes, what coke's saying 21:03
NotFound Yeah, but we must not forget the other problem
Coke what's the /other/ problem?
NotFound Thos pbc not being installed, if they must
21:03 Whiteknight joined
NotFound And I think they must, because others are 21:03
allison NotFound: it's okay not to install the .pbcs, the problem is just that right now when it falls back to the .pir files, it's still trying to load them as if they were PBC 21:05
Coke we should either intsall all off them or none of them.
allison is this still Tcl/Glob?
Coke no.
NotFound Coke: That's my idea, yes
Coke it's anything in runtime/library
NotFound: yay, concensus. 21:06
and now, ->
allison huh, and it's only installing .pir versions, not .pbc versions?
that's strange
so, yes, we should install .pbc
it won't break anything not to, but loading pbc is faster 21:07
NotFound I'd like to have an installer that copy the .pir files, and then compile them to pbc using the parrot being installed 21:08
I think the issue is just that the .pbc must be in MANIFEST.generated but they aren't 21:11
21:11 bsdz joined
allison NotFound: pbc doesn't hardcode paths, so it's fine to compile them to .pbc using the build dir parrot 21:12
NotFound: yes, they won't be installed if they're not in MANIFEST.generated 21:13
NotFound Fixing and testing...
Yes, that is. Checking for more files with the same problem... 21:16
Commited a bunch that I'm more or less sure that must be installed 21:30
dalek rrot: r39020 | NotFound++ | trunk/MANIFEST.generated:
[cage] add several missing .pbc files to MANIFEST.generated
 21:31
21:40 particle joined
dalek kudo: 5ed6dac | pmichaud++ | (2 files):
Use root_new opcode from parrot trunk. Bumps PARROT_REVISION.
 21:47
rrot: r39021 | whiteknight++ | branches/gc_internals (9 files):
[gc_internals] PWNd the branch with mighty HEADERIXXORmake. It builts now.
 21:55
21:58 Whiteknight joined
dalek rrot: r39022 | whiteknight++ | branches/gc_internals (4 files):
[gc_internals] gut pools.c (nee smallobject.c) and move most of the remainders into mark_sweep.c
 22:05
rrot: r39023 | whiteknight++ | branches/gc_internals/src/gc/pools.c:
[gc_internals] delete pools.c
cotto looks at commit message for r39021 22:07
It seems that all that GC work is taking its toll.
NotFound Maybe he commited by SMS 22:08
Infinoid wishes he had l33t mighty HEADERIXXORmake sK1lLz too
NotFound Don't know what, but something has changed. Now I can build rakudo on the laptop and on the desk, with C and with C++, even with --optimize 22:10
Whiteknight NotFound: you couldn't before?
NotFound Whiteknight: it eated all the memory when building the fakecutable 22:11
Whiteknight oh, that issue is being resolved by Util
he's fixed it on linux, I think, and is working to fix it on Win32
NotFound But he hasn't commited yet
Whiteknight oh? I thought he had
NotFound The .c generated looks like some days ago 22:12
dalek rrot: r39024 | whiteknight++ | branches/gc_internals/src/gc/mark_sweep.c:
[gc_internals] rename some functions. Functions internal to the gc do not need to be prefixed with Parrot_gc_*
tracwiki: v22 | whiteknight++ | GCTasklist 22:13
tracwiki: trac.parrot.org/parrot/wiki/GCTask...ction=diff
22:16 Ademan joined
dalek cnum-dynpmcs: r48 | darbelo++ | trunk/ (5 files):
Welcome decNumber and goodbye decQuad, go in peace knowing you served your

are no more.		 22:21
darbelo "$P0 = loadlib 'whatever'" fails silently for me if whatever isn't found. Is that intended? 22:28
NotFound darbelo: I think is, but I don't think is clearly documented 22:35
dalek rrot: r39025 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
[pct]: Give a more useful diagnostic for variables not in scope.
darbelo It seems an odd failure mode to me, figured I'd check if it was intended. 22:38
allison darbelo: not really the desired behavior, no
darbelo: I think there's a ticket for it already
NotFound allison: then what to do when the intention is to try several variants? Catch the excpetions? 22:39
dalek rrot: r39026 | allison++ | trunk/src/packfile.c:
[cage] Update library loading so it loads the file as bytecode or source

the requested extension, so defaulting to .pir from .pbc will work.
darbelo Found it. TT #437. 22:40
allison NotFound: when loading PIR/PBC files it goes ahead and tries all the variants, and only throws an exception if the file can't be found at all 22:41
NotFound: should do the same for dynexts
NotFound allison: we have some control over the pir/pbc/watever, we don't control external libraries 22:43
22:44 bacek joined
allison NotFound: we search for them along several paths, just like PIR/PBC, so we have some control 22:45
NotFound Look for example SDL.pir, it tries a lot of variants
allison NotFound: in src/dynext.c we return Undef from Parrot_load_lib when no library can be loaded 22:48
NotFound: oh, you mean trying lots of variants from PIR, not at the C level?
NotFound: then, yes, it should catch an exception 22:49
NotFound: and really, SDL is probably doing something wrong if it has to try a bunch of variants from PIR
pmichaud I think that SDL tries the variants because libsdl is installed differently on various platforms. 22:50
allison NotFound: or, just still targeting legacy code
pmichaud i.e., many platforms don't provide the libsdl.so symlink
NotFound pmichaud: I think that if someone needs to try a .so.0 his system has a problem 22:51
pmichaud NotFound: agreed, but I know that various linux distros have this problem.
allison grep doesn't find a loadlib in runtime/parrot/library/SDL 22:52
NotFound allison: ack does
pmichaud allison: it's in runtime/parrot/library/SDL.pir
(not in SDL/ subdir)
NotFound Ah, yes, sorry
allison NotFound: yeah, just found it moving the grep up a directory 22:53
NotFound: SDL does correctly check for an Undef return value from loadlib 22:54
darbelo: you can just check the return value to see if it's "true"
darbelo: so, it's not entirely silent. But I do also prefer throwing an exception. (There's even a comment in the code where it would be logical to throw an exception, asking if it should throw an exception instead of returning Undef) 22:55
darbelo allison: I'm from the 'Burst into flame' school of error reporting. It seems odd to me to just 'not fail' on failure :) 22:56
22:56 tetragon joined
darbelo I'm looking at the code now too. 22:57
NotFound allison: there is a related problem: some libraries are linked to libparrot, the failure of loadlib is ignored, and dlfunc gets the symbol from the current process image.
So if you throw an exception, you'll get a lot of bug reports 22:58
22:59 wayland76 joined 23:00 bacek_ joined
bacek_ good morninh 23:02
morning
afk_Coke allison: another partcl commit.
Infinoid morning bacek_ 23:04
bacek Infinoid: thanks for comment in TT#452
dalek rtcl: r356 | coke++ | trunk/ (15 files):
Roll out own _output_is test functions, so we don't have to rely on parrot.
 23:05
Infinoid I hope I summed up the problem well
bacek From my point of view problem is "using mmd for vtable is harmful and slow"... 23:06
Infinoid yeah. Another point of view is "all these things should be overridable by pir at runtime", and I'm not sure how those two views interact 23:07
Coke I am dismayed that we already had it not using vtables, then we went through and added it all in, now we're going through and ripping it all out.
Infinoid For instance, I would be perfectly happy with a lean & fast Integer class... which morphs into an IntegerSubclassable class when you try to extend it
bacek .sub 'infix:+'(_,_) ... .sub 'infix:+'(_,'Foo') 23:08
This is rakudo way.
Infinoid Especially if we can somehow convince pmc2c to generate IntegerSubclassable automatically.
Coke + neq "vtable add"
allison Coke: well, what it was using before was another completely different dispatch system
wayland76 Quick question; does anyone know the policy of which files go where inside the "tools" directory? (for more details, see trac.parrot.org/parrot/ticket/677 ) 23:09
Coke allison: ah, so we're not going in loops, just wandering about. That's slightly better, actually. =-)
allison Coke: not vtables or multiple dispatch
Coke wayland76: there is no policy.
stuff just got plopped in various locations.
wayland76 Coke: Ok, do we want a policy?
Or at least a guideline or something?
darbelo cotto: ping
Coke guideline good. 23:10
Infinoid anyway, would be great to get some parrot designer input on TT#452
allison Coke: aye. the old system called itself "multiple dispatch", but it was really more like simple vtables. I should have just converted it straight to vtables the first time.
bacek allison: can we declare that "mmd should'n be used for vtable calls"?
allison bacek: no, mmd should be used when mmd is needed
Coke does it make sense to have MMD for /vtables/ though?
allison bacek: but mmd shouldn't be used when all you want is simple inheritance 23:11
Coke methods, sure.
bacek then we have to convert all vtable methods to just methods
Infinoid I'd like a clear way to determine when mmd is needed. In the case bacek ran into, the PMC functions fine without MMD but some of the stuff *using* it wanted to override things through MMD
allison Coke: ah, see my conversion made it so each PMC only gets MMD dispatch when it specifically wants MMD dispatch
Coke bacek: 'vtable method' isn't a thing, apparently.
cotto darbelo, pong
NotFound allison: note that example in TT #692 was dependant on not having some .pbc installed, and now they are 23:12
allison Coke: that is, a vtable call always calls a vtable function
bacek first test in t/pmc/multidispatch.t
dalek rrot: r39027 | chromatic++ | trunk/docs/book/ch04_compiler_tools.pod:
[book] Revised PCT chapter for readability and flow.
allison NotFound: it was still a bug,
Coke NotFound: you can easily duplicate the error with no installation.
bacek It want to override VTABLE_add
dalek rrot: r39028 | whiteknight++ | trunk (62 files):
[gc_internals] merge the gc_internals branch into trunk. Monkeyed with the makefile and manifest, so you're probably going to need to make realclean && perl Configure.pl after updating
NotFound allison: yeah, but the example is no longer a test
allison NotFound: you can do a manual test 23:13
all it needs is a simple .pir file, and try to load it as .pbc 23:14
darbelo cotto: I converted DecNum from decQuad to decNumber but I ran into a snag: Just how big does a big number have to be?
allison NotFound: my test was a file x.pir in the same directory as the test script 23:15
bacek allison: is first test in t/pmc/multidispatch.t correct?
dalek rrot: r39029 | whiteknight++ | branches/gc_internals:
Removing gc_internals branch because I'm done with it
 23:16
cotto darbelo, what do you mean?
allison bacek: I'll take a look
Whiteknight darbelo: Do you have a limitation?
cotto It's kinda the point of the library that we can have arbitrarily large numbers.
dalek tracwiki: v23 | whiteknight++ | GCTasklist 23:17
tracwiki: trac.parrot.org/parrot/wiki/GCTask...ction=diff
allison bacek: it's only correct if Integer is doing multiple dispatch
darbelo decNumber isn't really "arbitrary presicion", it has a big array of digits at the end of the structure. The length is #define-able, but fixed. 23:18
bacek so my question: should we use mmd for vtable?
allison bacek: since we're changing Integer *not* to do multiple dispatch, then the test will need to change
bacek: not sure what you're asking?
Infinoid the test implies the possibility of subclasses or other code wanting to override vtables at runtime 23:19
allison bacek: the point of the test isn't to make sure Integer is doing multiple dispatch, the point is to test multiple dispatch, and Integer happened to be a handy candidate to test it
Infinoid so these changes disallow that, and if anyone relies on it, it also implies a deprecation cycle 23:20
darbelo True arbitrary precision would need a linked list of 'buckets', decNumber assumes contiguous storage for all of it digits.
bacek allison: what the difference between VTABLEs Integer.add and Foo.splice?
cotto looks at documentation
23:20 donaldh joined
Infinoid if it just used Integer because Integer was handy, then that's fine 23:21
we just weren't sure
allison Infinoid: the subclassing case is fine, since anyone who wants their subclass to do MMD can make their subclass do MMD
Infinoid ok, cool
darbelo cotto: speleotrove.com/decimal/dnnumb.html#decnumlsu
allison Infinoid: what we're disabling is the ability to add arbitrary alternates to the dispatch table
bacek allison: so we need deprecation cycle. 23:22
Infinoid EBADTESTS was the answer I was hoping for :)
allison bacek: try a little more detail to the question? They're different classes and different methods.
bacek: we've already had a deprecation cycle, they were included in DEPRECATED.pod in 1.0 23:23
bacek allison: checking deprecated.pod
cotto It's nice how they give it an obvious name like "lsu" so you know exactly what it does.
allison bacek: you'll find it as trac.parrot.org/parrot/ticket/452 in DEPRECATED.pod 23:24
darbelo It's the "least significant unit", which makes you wonder: "where are the other units, then?" 23:25
Infinoid awesome. so we can just fix up the tests and life is good
darbelo: purl ate them
bacek allison: ok. so I'll go ahead and replace all MUTLI's into VTABLE's
allison Infinoid: aye
cotto nom
darbelo Infinoid: That's what the documentations says too. 23:26
cotto darbelo, I'd say give it a reasonable default (512 digits?) and make it easy to change.
allison bacek: aye, that's good. a simple if/else construct can handle the variants between types
bacek allison: it can. If not I can just fall back to MMD. 23:27
allison bacek: exactly (what I was just typing)
bacek: the final "else" can just make the mmd call
darbelo "Easy to change" == "Pain in the ass" + "memory allocation trickery"
bacek allison: we always have foo(DEFAULT) in current PMCs. 23:28
cotto bacek++ #this issue is the reason I didn't get very far in converting MULTIs to VTABLEs.
23:28 rakudohudson joined
darbelo It's a compile-time constant. The only way to 'enlarge it' is to over allocate and overrun the array. 23:29
allison bacek: many of them do, yes
cotto darbelo, can't you just make sure DECNUMDIGITS is #defined to something appropriate?
bacek cotto++ # If I'll remove all MUTLI's from PMC's it will simplify life in pmc_pct branch :)
cotto darbelo, I was thinking that if someone needed to change it, they'd have to recompile anyway.
allison bacek: some of them, especially numeric PMCs, just extract a value from the second PMC, as the default 23:30
cotto bacek, there seem to be many such tasks
s/ anyway././
darbelo Oh, that *is* easy to change: just adjust the "-DDECNUMDIGITS=xxx" line in the makefile. 23:31
bacek allison: yes. Is it a problem?
cotto anything else has potential for significant ugliness
allison bacek: is what a problem?
cotto (although I though that decNumber did some dynamic stuff once a number got past a certain point)
allison bacek: extracting the numeric value instead of MMD dispatch?
bacek allison: yes 23:32
allison bacek: nope, it's a good default strategy
bacek allison: ok.
afk # time for $dayjob 23:33
allison bacek: I mentioned it just because in some cases you'll be translating the final else to MMD dispatch, and in some cases just to some simple operation
darbelo cotto: That's only for the internal buffers of the built-in functions.
cotto ok 23:34
darbelo You can create numbers as large as malloc let's you and the library will handle them. But resizable storage would be a pain in the ass to do here. 23:36
cotto in that case, just pick a fixed value and fail gracefully 23:41
ideally only when a failure is appropriate, but that's your decision ;)
darbelo All conversion routines will round at the number of digits specified in the context. And I capped that value at DDECNUMDIGITS. So we don't fail, we just round it to fit. 23:43
Andy Quiz!
What is eating all my cycles on my Mac?!?!? 23:44
darbelo A gremlin!
cotto a forkbomb?
purl i guess a forkbomb is :(){ ::& };:
jonathan purl is sometimes helpful. :-) 23:45
cotto Hmmm. I wonder what that does. ;)
Andy ping infinoid
purl I can't find infinoid in the DNS.
dalek cnum-dynpmcs: r49 | darbelo++ | trunk/build/src/ (2 files):
Make room for up to 512 digits in a DecNum.
Andy purl, infinoid? 23:46
purl infinoid is Mark Glines <mailto:mark@glines.org> or likes shiny things
Andy Oh! Hah! It's my md5 brute force computator! 23:48
Infinoid who, me? 23:51
Andy Yeah, you.
Infinoid o hai
Andy let's talk splint and asserts and stuff
cotto It's odd how nobody makes a decent md5 decompressor, especially since the compression ratio is so high.
Infinoid cotto: I'd pay $50 for one of those
Andy elliottkember.com/kember_identity.html
is what I'm working on.
Infinoid cool 23:52
So, I think we talked briefly about ASSERT_ARGS not playing nicely (enough) with splint 23:53
Andy ok 23:54
do go on.
I'm working on $WORK, but listening.
Infinoid I'm trying to find the discussion... it was something of a flyby comment at the time
Andy yes, there are things you can add to splint 23:55
to the code to make splint happy
doyou have an example of a function that we can look at?
Infinoid pmc_new(PARROT_INTERP, INTVAL base_type)
ASSERT_ARGS(pmc_new) will break at runtime if interp is NULL 23:56
Andy break? or fail.
Infinoid break. SIGABRT
with an assertion failure message
Andy well, but that's what we want. So it's not broken. :-)
that was my confusion. 23:57
ok
If you have code like pmc_new( NULL ), splint should catch that.
Infinoid sure, I just saw r38751 and wasn't sure whether it plays nicely with splint
yes
Andy Does it?
That might be a good test. :-) 23:58
Infinoid I have no idea. I haven't run splint in some time
Andy :q
Infinoid So what was the intention behind trac.parrot.org/parrot/changeset/38751 ?
Andy Oh, I was having problems with splint macros. I added those, and then later that niht had to back 'em out. 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!