www.parrot.org/ | Parrot 1.4.0 "Mundo Cani" Released!
Set by moderator on 21 July 2009.
jonathan (e.g. attributes) 00:00
Alternatively, lexical scopes and context vars may render it a non-issue also. 00:01
MikHel jonathan: I was thinking of an approach whereby you would recursively go down the past tree when constructing the top level object (for example a method). 00:03
jonathan: But then I have not understood yet the subtelties of the lexical scopes and context. Have to delve into that :) 00:04
bacek_at_work hi again 00:07
purl oh, you're back!
jonathan MikHel: Some of it is, I believe, fixed up during the PAST -> POST trnasformation. 00:09
dalek cnum-dynpmcs: r134 | darbelo++ | trunk/aux/decTest/cfg/Makefile.in:
This line is generating errors from Configure.pl, and it doesn't serve any
 00:10
cnum-dynpmcs: r135 | darbelo++ | trunk/t/ (4 files):
Add our first batch of decTest generated tests. We fail 184 out of 3840, but it
 00:20
rrot: r40327 | whiteknight++ | branches/io_cleanups/src/pmc/handle.pmc:
[io_cleanups] fix a weird pod bug that was breaking the build
 00:26
Coke Whiteknight: poing 00:27
Whiteknight Coke: the TPF grants thing closes on friday, right? 00:29
cotto darbelo, ping 00:31
darbelo cotto: pong 00:33
cotto darbelo, have you verified that the failing tests are caused by the library rather than by the PMC or Parrot?
s/\\?/ code?/ 00:34
It's odd that the code would fail its own tests.
darbelo I'm working on it. It's really tedious, as I have to check case by case. 00:35
cotto Yeah.
For the commit message it sounded like you were just blowing off the failures.
I can help parallelize if you like. 00:36
nopaste "darbelo" at 200.49.154.172 pasted "Here's an example of what I'm using to check the failures." (27 lines) at nopaste.snit.ch/17432 00:38
cotto That's what I'd do.
dalek rrot: r40328 | whiteknight++ | branches/io_cleanups/t/pmc/handle.t:
[io_cleanups] the Handle PMC type is instantiable right now (whether that's a good thing or not) so we shouldn't be testing to prove that it isn't instantiable
 00:39
kid51 svn ups in io_cleanups branch for first time in weeks 00:40
darbelo I'm not doing anything with multiply.t right now, so feel free to look at those as beredom strikes you. I'll get to them eventually otherwise. 00:41
cotto ok. That's only 7 failures. 00:43
nm. It throws an exception.
darbelo exception? where? 00:44
purl exception is from Email.pm not that code
cotto It'd be nice if the test failures printed the name of the failing test.
Invalid number of digits provided!
multiply.t
darbelo the new ones do, actually. But you have to prove -v t/testfile.t to see it.
00:46 mikehh_ joined
cotto good thing you told me that before I tried to add it myself 00:46
darbelo Besides, now that I look at it I see that it's not a test that's failing. 00:47
The test file has test for numbers with more difits than we support right now. 00:48
cotto how are you marking tests TODO?
japhb++ for the library suggestions
japhb cotto: thanks! 00:49
darbelo cotto: I'm not. I haven't checked if test_more.pir has a way to. 00:50
s/to./to do that./ 00:51
Also, there is a comment in t/data/multiply.decTest right before the failing tests that says: 00:57
"following testcases [through mulx800] not yet run against code" 00:58
So I'm ripping those tests out of the file for now. Wait for the commit
cotto Nice. 00:59
01:02 bacek joined
darbelo There. 11 failures in the file, but now it runs to completion. 01:04
svn up to r137 and you're good to go. 01:06
dalek cnum-dynpmcs: r136 | darbelo++ | trunk/t/multiply.t:
Remove some multiplication test that can only fail.
01:09 hiroyuk__ joined
dalek cnum-dynpmcs: r137 | darbelo++ | trunk/t/multiply.t:
Oops forgot to adjust the plan().
 01:11
Whiteknight japhb? 01:12
purl somebody said japhb was Geoffrey Broadwell, mailto:geoff@broadwell.org
japhb I be here
Whiteknight oh, I just wanted to make sure that you == Geoff Broadwell
japhb ah 01:13
kid51 Whiteknight: Am getting one test failure in io_cleanups 01:16
smolder.plusthree.com/app/public_pr...ails/25685
Whiteknight kid51: yeah, we're working on that one right now 01:17
once that gets fixed I think we can merge to trunk
kid51 cool 01:18
01:18 samlh joined 01:23 mokurai1 joined
nopaste "samlh" at 99.144.113.17 pasted "tiny patch for html docs css" (11 lines) at nopaste.snit.ch/17433 01:24
samlh Hello, long-time lurker here. I was reading the html documentation, and made a small patch for the css. Thoughts?
kid51 samlh: Can you show us what this looks like 'before' and 'after'? Links? 01:28
(patch seems reasonable, but it's been years since I looked at CSS) 01:30
My last Smolder report didn't display the branch ( which was io_cleanups ). 01:32
Am testing a patch to Parrot::Harness::Smoke which should alleviate that.
samlh 1 min 01:33
samlh.nfshost.com/foo/html/docs/pdd...c.pod.html versus docs.parrot.org/parrot/latest/html/...c.pod.html 01:37
see especially the list of vtable entries
nopaste "darbelo" at 200.49.154.172 pasted "cotto: does this look sane to you?" (15 lines) at nopaste.snit.ch/17434
Infinoid samlh++ 01:38
kid51 hmm, both versions taking long time to load.
Ahh, it's Verizon, of course. 01:39
darbelo msg cotto That nopaste is the sanest way I can think of TODOing tests so that we'll know if they ever start spontaneously PASSing. Let me know what you think about it.
purl Message for cotto stored.
Infinoid the difference is evident in the list of modifiers under Defining PMCs, too. Looks nice
darbelo With that done, I'm going to find some food. 01:40
samlh Infinoid: thanks!
cotto Hmmm. I don't like the idea of modifying generated code. 01:42
dalek rrot: r40329 | jkeenan++ | trunk/docs/resources/parrot.css:
[docs] Applying patch refining CSS contributed by samlh++.
 01:44
kid51 samlh: See CREDITS in top-level of distro. You are now eligible to add your data there; post patch.
And speaking of CREDITS ... does anyone know the status of (allison's) efforts to determine who is a member of the Parrot Foundation and eligible for voting? 01:45
dalek rrot: r40330 | jkeenan++ | branches/io_cleanups/lib/Parrot/Harness/Smoke.pm:
[testing] Improve regex used to identify repository branches in preparing smoke reports.
 01:50
rrot: r40331 | jkeenan++ | trunk/lib/Parrot/Harness/Smoke.pm:
[testing] Improve regex used to identify repository branches in preparing smoke reports.
samlh kid51: ok, thanks! This is awesome... 01:51
nopaste "samlh" at 99.144.113.17 pasted "Credits patch" (15 lines) at nopaste.snit.ch/17435
dalek rrot: r40332 | jkeenan++ | trunk/CREDITS:
First squawk of the Parrot for Samuel Harrington.
 01:57
samlh :) 01:59
02:00 Andy joined
bacek_at_work TapTinder? 02:01
purl i think TapTinder is software development tool - taptinder.org . For Parrot project running on tt.perl6.cz/ and reporting build failures to #parrot channel as ttbot.
kid51 must sleep 02:07
purl $kid51->sleep(8 * 3600);
02:17 jdv79 left 02:19 nopaste joined 02:28 wayland76 joined
nopaste "samlh" at 99.144.113.17 pasted "similar patch, fixes spacing in html documentation" (13 lines) at nopaste.snit.ch/17436 02:32
samlh Sorry, just tweaked it a little more to improve the spacing. old: samlh.nfshost.com/foo/html/docs/pdd...c.pod.html / new: samlh.nfshost.com/foo2/html/docs/pd...c.pod.html . Again, the functions listing shows improvement. Thanks!
02:42 janus joined 02:45 magnachef joined 02:55 tetragon joined 03:38 wayland76 joined 03:50 samlh joined
dalek TT #890 created by satrac++: build failed on intel mac osx 10.5 03:54
treed Oh? 03:57
04:06 dukeleto joined 04:07 TiMBuS joined
wayland76 Does anyone know how close protoregexes and LTM are? 04:33
cotto pmichaud does. 04:34
if anyone does
wayland76 Right. But he's afk, according to #perl6. Thanks though. 04:36
cotto My impression is that it hasn't gotten a definite spot on his schedule. 04:38
I'm really looking forward to profiling.
It's nice to be excited about something and actually able to act on it. 04:39
04:39 sbluen joined 04:40 sbluen left
wayland76 Well, pmichaud predicted that it'd be ready by the end of summer. He predicted Northern summer (ie. at least September), but being an Australian, I predict Southern summer (ie. February) :) 04:41
cotto before Christmas 04:42
purl but after lunch.
wayland76 Well, when we discussed it, I figured we were about half done, and had missed our deadline by maybe 8 months (this was in maybe June), so I just added another 8 months :) 04:43
purl: seen allison? 04:44
purl allison was last seen on #parrot 1 days, 9 hours, 56 minutes and 44 seconds ago, saying: (and expanding from there) [Jul 28 18:42:29 2009]
Coke cotto++ # profiling is desperately needed. 04:47
pmichaud protoregexes will be very soon
we need them in order to be able to support the other PGE improvements 04:48
dukeleto has anyone ever successfully deleted a breakpoint in parrot_debugger? it doesn't seem to work
Coke dukeleto, you're the first person to touch the debugger in years. Don't expect anythign to work.
pmichaud and the other PGE improvements are needed so that jonathan++ and I can make some key changes to lexical handling in Parrot
Coke dukeleto++
pmichaud in summary: The PGE tasks are becoming even-more-critical
Coke (there was some cleanup a while back, but I don' think anyone uses it on a regular basis. i'mm very happy to see those tests.
pmichaud on the good side, this last weekend jnthn++ and I were able to spec out how I can make the PGE changes without breaking everything that already exists 04:49
dukeleto Coke: yeah, I can tell. I am writing tests as fast as I can so that I can start actually hacking on it and have some peace of mind that I am not breaking things
pmichaud (end of pge/protoregex/ltm status report)
wayland76 pmichaud: Many thanks. When I ask questions like this, it usually means I've been reading the ROADMAP again :) 04:50
I'm also wondering whether task B (Parrot Calling Conventions) got into the July release
Coke nope 04:51
wayland76 ok
cotto pcc_rewiring is allison's next priority, afaict
Coke (at least ,not if that's the parrot portion of that. there's a branch that is still under development.)
wayland76 Coke: Yes, it specifically mentions Parrot 04:52
pmichaud allison said during today's perl 6 meeting that parrot calling conventions is her next task. 04:53
(to which I respond heartily: "Yay!")
wayland76 For anyone who'd like to see the ROADMAP (2 months out of date, but probably still mostly right): github.com/rakudo/rakudo/blob/ce21f...cs/ROADMAP 04:54
pmichaud better url is github.com/rakudo/rakudo/trunk/docs/ROADMAP 04:55
oh, wait.
hmmm.
better url is github.com/rakudo/rakudo/trunk/tree...cs/ROADMAP
grrr
better url is github.com/rakudo/rakudo/tree/maste...cs/ROADMAP 04:56
there.
(that way it's not tied to a specific commit)
cotto yay +1
I'm really happy to know that that's her next task. 04:57
05:01 Andy joined
dalek rrot: r40333 | dukeleto++ | trunk (2 files):
Add two TODO tests for deleting parrot_debugger breakpoints and add code that throws an friendly error message instead of a Bus Error
 05:07
05:16 desertm4x joined
dukeleto it seems that the PDB_t interp->pdb never gets a non-NULL interp->pdb->file associated with it in the parrot_debugger, which causes listing the source and deleting breakpoints to not work. the breakpoints that *do* get set right now are probably not working correctly either, due to this. 05:26
05:26 eternaleye joined
dalek rrot: r40334 | dukeleto++ | trunk/t/tools/parrot_debugger.t:
Add tests to parrot_debugger for tracing multiple statements and printing all integer registers
 05:56
cotto seen chromatic 06:05
purl chromatic was last seen on #parrot 1 days, 6 hours, 39 minutes and 48 seconds ago, saying: I thought that already worked. [Jul 28 23:20:27 2009]
Andy did passwords get reset in svn.parrot.org? 06:09
aha! trac.parrot.org and svn.parrot.org are the same DB 06:11
06:12 theory joined
dalek rrot: r40335 | petdance++ | trunk/lib/Parrot/Pmc2c/PCCMETHOD.pm:
set qr delimiters to // so vim color coding does not freak out.
 06:13
06:15 uniejo joined
Andy I can't get into trac at all. I'm having looping redirects. 06:17
cotto cookie issue? 06:18
I can log out and in ok. 06:19
Andy it's gotta be cookies 06:21
but 06:22
I've totally cleared all my cookies
wayland76 Maybe you need more squashed flies (sultanas/raisins) in your cookies 06:29
dukeleto Andy: do you have a browser-add-on that is being too smart ? 06:39
wayland76 ...or not smart enough :) 06:40
cotto I'm glad I don't have to write xs. 06:42
dalek rrot: r40336 | dukeleto++ | trunk/t/tools/parrot_debugger.t:
Add tests for printing each register type in parrot_debugger
 06:57
07:29 flh joined 07:30 chromatic joined
dalek rrot: r40337 | dukeleto++ | trunk/src/parrot_debugger.c:
Add some much-need docs to parrot_debugger, mostly about breakpoints and printing registers
 07:31
08:11 rhr joined 08:59 HostileParadox_ joined 09:09 einstein joined 09:11 clinton joined 09:13 donaldh joined 09:40 bacek joined 09:55 bacek_ joined
bacek_ o hai 09:58
moritz hi bacek_ 09:59
bacek_ moritz: hi
bacek_ hate moritz sometimes when he try to autocomplete "good mor..."
moritz won't apologize for his nick :-) 10:00
bacek_: hate yourself for mangling the autocompletion of "back" :-) 10:01
bacek moritz: No way! :)
bacek just finished reading latest #ps log 10:06
msg chromatic How Keys refactor related to "VTABLE swap"? 10:07
purl Message for chromatic stored.
10:08 kj joined
bacek kj: O HAI! 10:08
kj bacek: Hi there 10:09
purl hola, kj.
kj just replied your email
10:09 mikehh joined
bacek kj: just read it. 10:09
I've got about 20 commits waiting in git :) 10:10
kj oh very good
hope it's of any use as a basis to start from
10:10 Casan joined
bacek kj: It's just small cleanups for now. 10:10
And it _is_ very good basis. 10:11
kj where's the repository?
purl the repository is chastity locked.
kj it's not listed on parrot.org/languages
bacek kj: btw, good half of reasons why I joined parrot was your PCT tutorial :) 10:13
svn.parrot.org/languages
10:14 flh joined
kj ORLY? 10:14
purl YA RLY.
kj cool :-)
btw, i remember now what a big issue was with the PCT based implementaiton of PIR: macros and heredocs 10:15
both are a PITA to implement 10:16
bacek they are. 10:17
But my main goal is implement some optimisations strategies for PIR. So heredocs and macros aren't high on my task lists. 10:18
kj ah i see
feel free to replace my name in the maintainer file ;-) 10:19
bacek OTOH having "mostly" finished PIR compiler will help to archive other goals. Like "Emit PBC from PCT" :)
kj: I probably will. But you are still in AUTHORS section :) 10:20
moritz why do you need another PIR compiler when you want to emit PBC from PCT?
or did I make a connection here that doesn't exist?
(I mean you could make the POST compiler emit PBC, no need to touch PIR here) 10:21
bacek moritz: good half of PCT-based compilers have "embedded PIR fragments"
like Q:PIR
moritz maybe it would be easier to offer a good alternative to that 10:23
bacek yeah. PCT based PIR compiler is good alternative :)
moritz ok, I don't want to prevent you from having fun :-) 10:25
bacek moritz: look. For implementing various optimisations "from 80's" we need PIR/PASM parser.
We have "fully functional" compiler IMCC. Which implies that we have to write all this optimisations in "some bloody macroassembly language from 80's" 10:26
(and I don't want to do it) 10:27
moritz I don't see why you can't write a POST compiler that handles the cases without embedded PIR 10:28
see how it works out
and if it does bring some significant speed gain, you can still worry about a PCT/NQP/Whatever based PIR compiler to use inside that POST compiler
that's the "simplest thing that could possibly work" approach 10:29
bacek 1. it's not "inside".
moritz what is not inside whate? 10:30
s/e\\b//
bacek 2. In POST too much information about semantic already lost.
moritz then you can write a PAST compiler instead of a POST compiler 10:31
bacek yeah.
But "generic" PAST is "too generic" for me.
If I have "PIR PAST" that I can rely on I can do much more things. 10:32
And, and the end of the day, POST will converted to something very similar from "PCT PIR" 10:33
Because those 2 things are quite close
moritz I don't know what you mean by "PIR PAST", but that's probably OK 10:34
bacek moritz: "PIR PAST" is AST with well predefined, expected by optimiser, properties. 10:36
moritz will it be plugged into the existing toolchain? Or do the PCT based compilers have to be changed to use that? 10:37
mikehh All tests PASS at r40377 (pre/post-config, smolder, nqp_test, fulltest) - Ubuntu 9.04 amd64 10:38
bacek moritz: PCT architecture allows to plug additional steps. pmichaud++. So, answer is "yes"
But I can't say right now that it will not require some small tweaks. Like "compiler.add_step('enable_megacool_optimisations')" 10:40
moritz ok. I was more thinking about changed code/PAST generation 10:41
bacek no-no-no.
One of PCT steps is "to_pir". 10:42
So, after this I (and anyone else) can embed "optimisation step". And that's why I need "PIR compiler"
moritz ah 10:43
you want to optimize the generated PIR
bacek any PIR
moritz I thought you wanted to omit the PIR generation
bacek I would like to. But again - PAST is way too generic. 10:44
10:45 MoC joined
bacek But I will consider to use POST for "basis" 10:45
dalek ose: r86 | Austin++ | trunk/ (16 files):
Checkpoint: grammar refactoring proceeds. AST now has types.
 10:52
ose: r87 | Austin++ | trunk/src/parser/ (4 files):
Checkpoint: grammar refactoring proceeds. AST now has types.
 10:57
mikehh rakudo (13ba2f3) builds on parrot r40377 - make test PASS/ make spectest (up to 27815) two tests FAIL - reported before - Ubuntu 9.04 amd64 10:58
t/spec/S12-enums/basic.rakudo - Parse errors: Bad plan. You planned 30 tests but ran 28 - fails with Method 'Num' not found for invocant of class '' 11:03
t/spec/S12-introspection/walk.t - Parse errors: Bad plan. You planned 10 tests but ran 4. - fails with Parameter type check failed; expected Any, but got Object for $class in call to block_86 + backtrace 11:05
I think I better post to #perl6 as well 11:09
need to connect
11:20 donaldh joined 11:50 mikehh_ joined 12:11 ruoso joined 12:15 Jimmy joined
dalek rrot: r40338 | jkeenan++ | trunk/docs/resources/parrot.css:
[docs] Additional CSS refinement contributed by samlh++.
 12:19
12:39 HG` joined 12:48 jimmy joined 13:15 desertm4x joined 13:20 iblechbot joined 13:44 makk384 joined 14:03 NotFound joined
NotFound hi 14:03
purl niihau, NotFound.
14:05 fdorothy joined 14:10 hercynium joined 14:15 Andy joined
dalek rrot: r40339 | NotFound++ | trunk/src/debug.c:
[debugger] repair source loader
 14:16
NotFound Please stop adding bad tests to parrot_debugger. 14:17
dalek kudo: 5797a68 | jnthn++ | src/pmc/p6opaque.pmc:
Fix bug relating to submethod dispatch on a proto-object.
 14:22
kudo: a100a60 | jnthn++ | src/builtins/guts.pir:
Ensure that proto-objects use the correct dispatcher, just like any other object.
kudo: 21cbaef | jnthn++ | t/spectest.data:
Add S14-traits/routines.t to spectest.data.
Coke if you defined "bad", that might be more helpful. 14:27
NotFound Checking the look of the output instead of the functionality. 14:28
Coke looks like the output checks are at least regexes, not full output matches. 14:30
NotFound Is failling on one of my systems, anyway. 14:31
dalek rrot: r40340 | NotFound++ | trunk/compilers/imcc (5 files):
[cage] rename imcc struct _IMC_Unit to struct IMC_Unit and avoid several forward declarations of it
Coke do we run those tests in 'make test' ?
NotFound Coke: yes
Coke k.
I have some small updates to avoid backwhacking. 14:32
NotFound IMO parrot_debugger is not mature enough to be fully testable
Coke some sane tests are better than no tests. 14:34
NotFound Looks like some of that tests assume that in the trace output the integer registers are zero, and they aren't 14:35
Coke: yeah, but no one knows how a sane parrot_debugger output looks like. 14:37
dalek rrot: r40341 | coke++ | trunk/t/tools/parrot_debugger.t:
Make the regex on this test a little looser so it passes.
 14:38
mikehh oops - in my earlier posts I used r40377 instead of r40337 for parrot 14:39
Andy can anyone help me with trac.parrot.org redirects? 14:41
"delete your cookies" does not solve my problem. 14:42
14:42 dukeleto joined
NotFound Coke: thanks 14:43
Andy It's very sad. Not able to commit code (easily). 14:49
jimmyZ Andy: can you log in ? 14:51
Andy no
I get a redirect loop.
mikehh t/tools/debugger.t FAILS - Failed test: 19 (at r40341) 14:52
Ubuntu 9.04 amd64
Coke Andy: what's the issue?
purl The Chinaman is not the issue here Dude!
Andy I keep redirecting to /parrot/prefs/account 14:53
NotFound mikehh: I'm looking at it
Coke Andy: you're going to trac.parrot.org (redirects to /parrot), clicking on login? 14:54
Andy I've tried a billion different things.
Coke ok. I can't duplicate the problem with my account, so i'm trying to figure out what you're doing that's different.
(also, OS/browser?)
Andy GENERAL AWESOMENESS, THAT'S WHAT
Mac, both Safari and Firefox 14:55
Coke ... how's that working out for ya.
ok. my mac is at home, so i can't verify that...
I'll switch to firefox on win instead of chrome, though. =-)
jimmyZ works fine for me FF on win
Andy now, I changed passwords yesterday 14:56
Coke as did i. =-)
Andy right
Coke ... assuming you really are andy and not some nefarious hacker.
Andy I might be. 14:57
You just can't tell.
EXCEPT FOR THE AURA OF AWESOME.
Coke more of an aroma.
14:57 Psyche^ joined
Coke Andy: did you ever confirm your email address with trac? 14:58
(just out of curiousity. I know that bit some people i the past.)
Andy I don't know.
it does williningly email me password resets 14:59
now, I can get to trac.parrot.org/parrot
but I'm not logged in.
Coke ok. when you click login, that should take you to: trac.parrot.org/parrot/login 15:00
Andy yes, it does
Coke and when you click the button, you should land on /parrot
Andy no, it tries to send me to /parrot/prefs/account
and redirects over and over
dalek rrot: r40342 | NotFound++ | trunk/t/tools/parrot_debugger.t:
[t] don't assume value 0 on unitialized I registers
 15:01
Coke Andy: JS disabled, perhaps? 15:02
;( web equivalent of "did you reboot yet" questions.)
Andy nope
I don't allow creating windows, though
NotFound mikehh: Can you check with r40343?
Andy can you see if my email addr is confirmed?
Coke it's listed. 15:03
I don't know if that means confirmed.
Andy: I can try to reset your password.
Andy ok
it will mail me a new PW just fine 15:04
but logging in again still goes into looping
15:04 jimmyZ_ joined
dalek rrot: r40343 | NotFound++ | trunk/t/tools/parrot_debugger.t:
[t] fix errata from r40342
 15:04
15:10 ruoso joined
mikehh NotFound: building now 15:11
Interestingly enough make fulltest PASSes at r40441 - it does not check t/tools, nor nqp_test for that matter 15:12
15:12 ruoso joined
mikehh r40341 15:13
15:13 ruoso joined 15:15 ruoso joined
mikehh NotFound - yes it passes - running smolder now 15:16
15:17 ruoso joined 15:18 jan joined, quek joined
mikehh so you can remove a breakpoint once it's set? 15:18
15:19 ruoso joined
NotFound mikehh: amusing, several tests still failed for me in amd64 15:19
mikehh: I don't looke at that tests yet, they are todo'ed
dalek rrot: r40344 | NotFound++ | trunk/t/tools/parrot_debugger.t:
[t] use the --script option instead of stdin to pass commands in parrot_debugger tests
15:21 donaldh joined, slavorg joined
NotFound Witht that last change, the remaining failures are gone. Don't know what's the cause. Different versions of Test::More, maybe? 15:22
I think I know what was the culprit: readline_interactive ! 15:25
It behaves differently if parrot is built with realine support or not.
mikehh smolder PASSed at r40343 on Ubuntu 9.04 amd64 15:27
I definately have readline = yes in Configure 15:29
15:29 theory joined
mikehh All tests PASS at r40343 (pre/post-config, smolder, nqp_test, fulltest) - Ubuntu 9.04 amd64 15:33
t/tools/parrot_debugger.t PASSes if I svn up and prove -v t/tools/parrot_debugger.t 15:37
at r40344 - I haven't rebuilt yet 15:38
NotFound No need to rebuild, the only change is in the test file 15:39
mikehh NotFound - sure, but my test script does a make realclean etc 15:40
15:41 einstein joined
NotFound Not sure what is exactly the problem with readline_interactive in that case, but using --script instead of stdin we don't have to worry. 15:43
mikehh NotFound: you use g++ don't you - what advantages do you find using that over gcc 15:51
NotFound mikehh: mainly, that if I don't do that no one cares about not breaking the c++ compatibility of the code base ;) 15:52
Building with c++ ensures that we fix some problems that with C can look as unimportant warnings. 15:56
Also, the C++ name mangling helps check that we declare as PARROT_EXPORT all things that need it.
15:59 dukeleto joined
dukeleto hola 15:59
Coke dukeleto: hio 16:00
16:02 darbelo joined, mokurai joined
dukeleto coke: did that debugger test that you changed fail for you? it would seem that the next test would need to be changed as well. in any case, thanks! 16:04
16:05 clinton joined
Coke dukeleto: yes, it failed, or I'd not have changed it. it was the only one that did. 16:06
(that on feather, a linux box.)
NotFound dukeleto: I fixed several other as well. They were dependant of several assumptions that aren't always true.
If failed since I fixed a problem in the source loading function of the debugger. 16:07
dukeleto NotFound: I saw that, does listing the source work now? very exciting! 16:09
NotFound dukeleto: it was already working last time I checked, don't know when it get broken. 16:10
Coke how does it work? (if I do load foo.pir\\nlist, I get nada.) 16:12
dukeleto is there a way to test my code on muiltple architectures *before* committing? or perhaps getting branches tested? 16:13
NotFound: I am compiling the latest parrot from scratch now, I will add some tests for listing the source
Coke dukeleto: for anything bigger than a breadbasket, use a branch and ask for smoke reports.
for incremental fixups on parrot_debugger, I think trunk is fine if they work for you, and you're not too close to a release. 16:14
do you have access to linux?
NotFound Coke: parrot_debugger file.pir -> Both compiles and loads the source.
Coke whee, source (also segfault. =-) 16:16
but still, that's probably the most I've seen out of the debugger ever. =-)
NotFound Coke: the load command just loads the source, you need to have the pbc already loaded.
Coke: last time I worked on it put to work several things, even if badly. 16:17
Coke woot.
16:17 payload joined
NotFound Is not stable, and is not up to date with parrot features, but is able to do some things. 16:18
16:32 whiteknight joined
dalek TT #891 created by particle++: [TODO] allow spaces in nci function signatures 16:37
16:40 Themeruta joined
Coke Ugh. do we really want to be making our string based parameter listings MORE flexable, requiring more effort to parse? 16:40
16:42 davidfetter joined
Coke and here goes the "unify the signature" discussion again. I cannot remember the outcome the last time it occurred. 16:42
whiteknight last time it occured, we got off onto a tangent about how condensed signatures weren't the most expressive form for expressing signatures
particle ok, so i'm stoking the fire a bit 16:43
Coke i don't think we want expressive signatures to parse at runtime.
whiteknight and no matter what the outcome last time, we DO need to fix our signature string handling in one way or another
particle runtime? it's c.
NotFound If you want to make it clear in C, just write: "I" /* <- */ "I" 16:45
particle or 'I' 'I'
NotFound Or just "I" "I"
particle: syntax error 16:46
purl syntax error is what he's already getting
Coke yes, and whenever someone calls Parrot_call_sub_ret_int(interp, sub, "II", 5);, we're doing a runtime lookup to figure out what actually means. I'm just concerned about slow downs. (yes, benchmarks needed)
particle why syntax error? they're both one char.
Coke particle: 'I' is a char, not a string.
this ain't perl.
ascii i?
purl, you need an ascii function.
purl Coke: i'm not following you...
particle chr i 16:47
NotFound Thw way I proposed, is the C compiler who works.
particle: but you don't need chars, but strings
particle right, of course. duh.
16:47 he joined
particle notfound: the developer works, too 16:47
space is a lot cheaper to type than '" /* <- */ "' 16:48
NotFound particle: if the developer wants clarity, he must write something.
You can even write a beautiful C macro: SIGNATURE(ret_type,args) ... 16:49
particle and it's actually the compiler working with my solution, yours uses the preprocessor 16:50
NotFound Anyway, there is no need to add bloat to the machine to allow a C coder to write in a clean way.
Coke (macro++)
16:51 bacek joined 17:00 quek left
cotto seen chromatic 17:01
purl chromatic was last seen on #parrot 1 days, 17 hours, 34 minutes and 51 seconds ago, saying: I thought that already worked. [Jul 28 23:20:27 2009]
Coke abesapien! 17:28
particle joy! the blue angels have returned to seattle :) 17:36
17:57 einstein joined 17:58 Themeruta joined 18:10 chromatic joined 18:11 bacek joined 18:12 Themeruta joined 18:22 Themeruta joined
cotto chromatic, ping 18:24
chromatic pong 18:25
nopaste "cotto" at 74.61.2.46 pasted "initial idea of profiling runcore output" (31 lines) at nopaste.snit.ch/17439 18:26
chromatic Sensible. 18:27
purl hmmm... sensible is usually inappropriate, yes :)
chromatic My only question is if functions need association lines as well.
cotto Sure. 18:28
chromatic Looks doable then.
cotto What do you think about using a hash to map between function and file names and their shortened versions? 18:29
the alternatives being a O(n) lookup or something I hadn't thought of 18:30
chromatic A hash in the output file? 18:31
Or a hash in memory.
cotto in memory
"/home/user/foo.pir" => "F0" 18:32
dalek rrot: r40345 | NotFound++ | trunk/compilers/imcc (6 files):
[cage] get rid of one imcc global, RT #39714
PerlJam er, don't you normally want it the other way around?
chromatic Or we could only write the file/function output when it changes.
cotto PerlJam, only when you're reading the file.
That's also a possibility. If we're using some sort of compression, it'll take care of the redundancy. 18:33
18:33 NotFound joined
chromatic An in-memory hash perturbs memory, which I'd like to avoid. 18:34
... as much as possible, anyway.
cotto btw, all the information we want to store is available. I hacked up the slow run core as a proof of concept.
chromatic Perfect. 18:35
purl perfect is the enemy of good enough.
chromatic I'll get everything set up to add that runcore on the branch by the end of the day. 18:37
cotto except hll annotations, but those are obviously available
nice
chromatic Are you working on converting our simple format to Callgrind format? 18:38
cotto I haven't started on that. 18:39
It was on the list after figuring out the immediate format.
18:40 Zak joined
particle cotto: i'd put a marker after the time spent, to mark the units 18:41
cotto particle, the units don't matter as long as they're consistent.
particle or maybe somethng in the marker
er, header
if the units change, then you'll know how to handle it
cotto when would they change in the middle of profiling? 18:42
particle eg an embedded device that measures slower than ns
not the middle of profiling
this is output to a file, that's read later
perhaps on another platform
don't assume nanoseconds, make it a declaration
cotto That's a good idea, but also something that can be added once there's some extant code. 18:43
NotFound 10^-30 Galactic rotation periods
chromatic First we need to get our control flow tracking reasonably accurate.
cotto chromatic, that's what the call chain depth is for 18:44
chromatic I found that figuring out which ops go where was tricky.
particle call chain depth won't work with tailcalls
cotto although the control flow information would be somewhat implicit.
particle if you give contexts uids, then you can refer to calling context 18:45
that will allow circles and reused contexts
cotto particle, actually when using a tailcall the depth changes at the .sub line and then goes back down, but I don't know if it's wise to depend on that. 18:46
particle maybe a hash of the context?
cotto particle, so each line would also refer to the calling context somehow? 18:48
particle yes, each line refers to calling context, rather than chain depth
let the program interpreting the data build the call graph 18:49
cotto I like that. 18:50
Is there any problem with adding an UINTVAL field to Parrot_Context that gets incremented each time a context is created? 18:54
particle try to remember, there is no stack. everything is relative.
cotto I had to stop myself from typing "stack" several times. 18:55
chromatic Let's see what we can get without doing any of this yet. We may not need it.
cotto Sounds good. I'll get started converting the immediate format (+filenames/subs only when they change) into something Callgrind can use. 19:00
dalek rrot: r40346 | NotFound++ | trunk/compilers/imcc (2 files):
[cage] getting rid of a imcc global, RT #39714
 19:01
chromatic Even that much may be useful to Rakudo.
cotto How are pluggable runcores going? 19:04
chromatic Mostly a SMOP at the moment. 19:05
I've decided to abstract them first, then make them pluggable later.
Adding the profiling core and getting it to where Rakudo can start to use it and give us feedback on what it gets wrong is more important. 19:06
19:20 donaldh joined 19:38 MoC joined
dalek rrot: r40347 | NotFound++ | trunk/compilers/imcc/symreg.h:
[cage] headerizing update forgotten in r40346
 20:08
rrot: r40348 | NotFound++ | trunk/src/embed.c:
[cage] isolate and simplify startup debug info
 20:33
rrot: r40349 | particle++ | trunk/docs/pdds/draft/pdd16_native_call.pod:
[PDD16] these are symbols, not letters
 20:47
20:49 mokurai joined 20:52 jevin joined
mikehh All tests PASS at r40343 (pre/post-config, smolder, nqp_test, fulltest) - Ubuntu 9.04 amd64 21:02
BAH that's r40348
21:03 flh joined 21:06 pmurias joined
pmurias hi 21:06
there used to be a gsoc project to plug harmonys gc into parrot right? 21:07
chromatic Yes. 21:11
21:14 payload joined
pmurias chromatic: how far did it get? 21:15
GeJ Good morning everyone 21:16
mikehh rakudo (279abf9) builds on parrot r40348 - make test PASS/ make spectest (up to 27821) same two tests FAIL - Ubuntu 9.04 amd64 21:18
t/spec/S12-enums/basic.rakudo - Parse errors: Bad plan. You planned 30 tests but ran 28 - fails with Method 'Num' not found for invocant of class ''
t/spec/S12-introspection/walk.t - Parse errors: Bad plan. You planned 10 tests but ran 4. - fails with Parameter type check failed; expected Any, but got Object for $class in call to block_86 + backtrace
Coke mikehh: are those known failures? If so, probably no point in reporting them. 21:28
ISTR that when updating the spectest progress, known failures are at least listed in the commit message. not sure if they are also in the spectest progress file.
mikehh just the numbers 21:30
pmichaud jonathan was going to see about fixing those regressions... not sure what happened to that. 21:31
if they aren't fixed by tomorrow, we'll fudge them out for now.
mikehh I 've still got to get partcl working on my (non-installed) parrot 21:32
was palying around with the Configure.pl to make it more like rakudo so I can use --parrot-config=../parrrot/parrot_config 21:33
pmichaud I hope to have a significant update to rakudo's Configure.pl soon 21:34
21:35 kj joined
pmichaud (the one from our ins2 branch) 21:36
chromatic pmurias, I didn't hear much after the initial plan. 21:40
cotto Now might be a good time to revisit that goal if anyone's interested. 21:41
jonathan pmichaud: One of them I think the test file needs to change.
pmichaud: The other is a bug that I was hoping I'd suddenly realize how to fix, but that sudden moment has been rather unsudden in coming. :-)
moritz if you don't see a fix on the horizon, please regress on the tests and open a ticket for it 21:42
a clean 'make spectest' is immensely helpful when testing local changes
pmichaud agreed. I'm fine with fudging the tests. 21:43
Coke (making partcl work on non-installed parrot) the path of least resistance there is to just install it into a subdir.
or some other non-standard location.
pmichaud that's what Rakudo is doing.
jonathan Aye, I've kept expecting to fix them "today".
Coke fixing that for real requires a lot of work.
jonathan Sorry for the noise.
Coke AIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII! 21:44
moritz jonathan: no problem, I just don't want it to be a permanent condition ;-)
21:46 Whiteknight joined
cotto Hi, kj 21:47
kj hi cotto
cotto long time no c
jonathan kj! :-)
kj yeah:-) 21:48
good evening all
cotto kj, do you have any plans on getting back into pirc? 21:49
kj cotto: short term, prob not :-( 21:50
cotto rl is life that sometimes 21:51
kj i have little time to really focus on it
21:53 japhb joined
Whiteknight hello kj 21:55
kj hi Whiteknight
21:56 bacek joined 21:59 sekimura_ joined 22:05 dukeleto_ joined
kj cotto: perhaps I should increase the documentation so the bus number can be increased 22:06
that would be a start at least
haven't written a line of code in 6 monhts
cotto That would be a good thing.
kj documentation is easy, code is not 22:07
cotto and since you haven't written anything in the past 6 months, you'll have a better idea of what's not clear from the code
kj yes, well i was looking at it earlier this week, and i realized how complex pir really is
why is it that complex?! </rhetoric> 22:08
chromatic Because no one's pushed to simplify it.
Sufficiently, I mean. 22:09
kj most of the complexity comes from all the sugar
22:17 bacek_ joined
bacek_ Good morning 22:17
purl And good moroning to you, bacek_.
cotto maroons purl 22:18
chromatic, do you know smalltalk? 22:19
(or anyone) 22:20
kj cotto: that's a coincidence, was just checking out squeak :-)
but don't know it... 22:21
purl hmmm... don't know it is worth doing disguise for putting is at top of the function
22:21 donaldh_ joined
cotto It might be a good start for L1 if someone were to take the Smalltalk operations listed at wiki.squeak.org/squeak/2267 and explain what they do on the wiki. 22:22
chromatic I know a bit.
bacek chromatic: you wanted to talk to me (according to #ps logs) 22:24
q: Who can grant commit access to /languages? 22:25
cotto bacek, have you tried and failed to commit there?
chromatic bacek, is the Key PMC still a mess in terms of that it can store a STRING, an INTVAL, or a PMC? 22:26
bacek cotto: yes 22:27
chromatic: yes 22:28
chromatic Okay. Vtable swap is the idea that we can write one variant of each vtable entry for each type of value we expect a Key to hold and swap between those vtables when the type of the Key changes.
bacek chromatic: yak... What for? 22:29
chromatic Remove complexity and run time switching from each single vtable entry. 22:30
bacek you still have to check type of Key on each call, ain't you? 22:31
chromatic Nope, that's all hidden behind the proper vtable interfaces. 22:32
bacek I don't quite understand. 22:33
E.g. $P0 = new 'Interger; $P1 = new 'Float'; $P3 = $P0 + $P1
"+" is $P0.add($P1, $P3) 22:34
chromatic We have a set of vtable entries for "Key containing a STRING key", one for "Key containing an INTVAL key", and one for "Key containing a series of Keys".
bacek which is VTABLE_add(INTERP, SELF, $P1, $P3)
chromatic When we assign to a Key PMC (or convert the key it contains), we swap its vtable pointer to the appropriate vtable for the type of key it contains. 22:35
bacek ah. I misread original idea
22:36 wayland76 joined
bacek chromatic: and "VTable swap" only for Key PMC? 22:37
22:38 rg1 joined
chromatic Or any other PMC that really needs it; that might be a nice way to upgrade Integer into BigInt in place. 22:39
bacek In this case easier to convert Key to base class without data and inherit StringKey, IntegerKey, etc.
chromatic Key really benefits from something like this; it moves a lot of complexity behind the vtable interface.
Except that makes us morph.
bacek "makes us morph"? 22:40
chromatic How do you know what you're going to store in a Key PMC until you store it?
bacek (Integer PMC upgrades to BigInt in place)
chromatic: (Key) Factory? E.g. Key."create_key"(INTVAL), etc 22:41
chromatic I don't believe you know what you're going to store until you store it. 22:42
bacek We can reimplement Key as RPA of KeyItem (which is "pure virtual"), inherit StringKeyItem from KeyItem. 22:44
Key.push_something will create appropriate SomethingKeyItem 22:45
chromatic Okay, but what does that give us?
bacek clean design of Keys.
chromatic You're creating an abstract interface to abstract away the vtable interface which all PMCs already implement.
bacek VTABLEs for each *KeyItem will dtrt 22:46
I treat Keys as Path. (And they are Path now. Used only for getting data from nested containers) 22:47
Whiteknight pmichaud: ping
chromatic We could create a new PMC type for each type of thing a Key stores, but that multiplies entities and tempts people to instantiate those key PMCs directly, which I'd like to encourage. In addition, we either require all Key PMC creation to go through a single C function with a switch statement to create the right type of PMC or we have to create a Key PMC and in its initializer use a big switch statement to morph it in place 22:49
like some in place factory pattern.
Although we *could* treat a Key as a delegate and send all of the operations to the contained item. That's not so bad. 22:50
bacek chromatic: no one should create "*KeyItem" directly. But there is no way do declare something as "private" in PMC.
chromatic You can throw an exception from init and init_pmc. 22:51
bacek And "single C function with switch" isn't required. We have various "push_*" vtables to create appropriate *Item. 22:52
pmichaud Whiteknight: pong
22:52 Limbic_Region joined
Whiteknight pmichad: at #ps, you mentioned you were interested in using pushmark/popmark/pushaction eventually 22:52
chromatic But then to create a Key PMC, unlike any other PMC I can think of, you can't just say "new ['Key']", you have to do that and explicitly push a new type of PMC onto it? 22:53
Whiteknight i'd like to hear more about what you are planning, because at the moment those ops are pretty useles
chromatic I don't like that much.
pmichaud Whiteknight: I need a mechanism to rollback the caller chain from exceptions. afaict, pushmark/popmark are the only mechanisms available to do that
bacek chromatic: finally it will be something like: $P0 = new 'Key'; push $P0, 42, push $P0, "string"; push $P0, 84; to create [42;"string";84] Key
Whiteknight pmichaud: not at the moment. The docs say more then the ops actually do
pmichaud I also need a mechanism to say "when this context is being rolled back, execute this other code first" 22:54
Whiteknight which is why I want to talk to you, because no matter what you want we are going to have to basically implement it from scratch
22:54 wayland76 joined
pmichaud iiuc, rgrjr has been using these opcodes successfully. 22:54
chromatic I don't mind using push to link Keys together, but I don't like using it to initialize a Key's first (and possibly only) value.
Whiteknight let me rephrase: they can be used, but they are not nearly as useful or capable as they should be
22:54 allison joined
pmichaud Whiteknight: I don't disagree with that at all. 22:55
Whiteknight pushaction doesn't fire actions when an exception fires, or when a sub returns, for example
pmichaud afaict, I don't need something to fire an action when an exception fires
I do want something that can fire when a sub exits, yes.
bacek chromatic: why? Key is Path. By default it doesn't contain any Steps. push_* is factory methods to create proper Step and append it to Path. 22:56
pmichaud pushaction can do that, if it's set up properly.
chromatic Because we don't create any other value PMCs that way.
Whiteknight okay. in that case we either need to extend the behavior of pushaction, if that's the right way. I might suggest we create a new at_return op to fire actions on context exit
pmichaud I'm not attached to the current pushmark/popmark/pushaction in any way; I just didn't want them to disappear without having some mechanism for doing what they currently provide (even if it's in a very limited form)
Whiteknight okay, that's what I'm trying to do: give you the mechanism you need (because I don't think pushaction/pushmark/popmark is the right way) 22:57
pmichaud I agree with that.
Whiteknight okay, awesome
chromatic Also you're overloading what push does on a Key PMC.
If the Key doesn't already have a value, it sets the value.
pmichaud while you're considering this, not that I also need a way to force a context to exit (and roll up any nested contexts)
chromatic If the Key has a value, it creates a new Key, sets that Key's value, and links that new Key to the current Key.
bacek chromatic: no-no-no. Key never have value. KeyItem have. 22:58
chromatic Fine then, s/(value)/KeyItem with a $1/ then.
bacek Key has RPA of KeyItem.
pmichaud in general allison and I have been looking as "invoking the return continuation" as being the generic mechanism for this. But of course we also need to roll-up any intervening contexts.
chromatic We create a KeyItem PMC which is purely abstract because... well I certainly don't know.
bacek Key.push create new KeyItem with value and push it to RPA 22:59
chromatic Then we create a StringKeyItem PMC, an IntegerKeyItem PMC, a FloatKeyItem PMC, a KeyItemKeyItem PMC, et cetera, which all extend the abstract KeyItem interface which provides the vtable interface every PMC provides.
This to me is not a win in terms of complexity.
bacek KeyItem is interface class. We can actually avoid it and just create bunch of concrete FooKeyItem.
Whiteknight pmichaud: okay, that's something to consider too (but that probably is blocking on pcc_rewiring, like everything else)
pmichaud Whiteknight: yes, I agree it probably blocks on pcc_rewiring. 23:00
but ultimately I want a way to force a context to leave without having to throw exceptions up the call chain to do it.
chromatic Why do we need a StringKeyItem PMC to represent a String PMC used as a Key?
pmichaud (because trapping and rethrowing exceptions is somewhat heavyweight, and exiting a context is common)
chromatic We don't have a StringArrayItem PMC or a StringAssociativeArrayItem PMC.
bacek chromatic: to avoid storing messy attributes in single Key
pmichaud (keys) Sometimes it's better to have the messiness all in once place, rather than spreading it out. 23:01
*one place
bacek PMCKeyItem can store new Key.
chromatic How many types of PMCs are we going to create to store Key information? 23:02
bacek 4
chromatic How many PMCs do we have to instantiate every time we access something by a Key?
bacek String/Integer/Float/PMC
ah sorry.
chromatic What kind of contortions will PCT have to go through to generate code that uses Keys?
bacek 1+n
1 for key. N steps 23:03
pmichaud wrong, bad
keys (especially constants) should be specifiable as an operand. If we have to execute N+1 opcodes to build a constant key, we're going in the wrong direction. 23:04
especially if those N+1 opcodes are producing gcables at every step.
chromatic Exactly.
bacek pmichaud: no. constant Keys are stored in PackfileConstantTable and not created in runtime
jonathan Constant keys should be constants stored in the packfile constants table.
bacek my proposal do not change it. 23:05
pmichaud then your answer to chromatic's question was incorrect. :-)
bacek I treat "generate code that uses Keys" as runtime question :)
imcc/pirc/* will just switch to slightly different key creating in compile-time 23:07
And with my proposal we'll make Key equal to all other PMCs without any special treatment. 23:09
(especially for storing in PBC...) 23:10
chromatic Can you write it up on the wiki?
bacek I'll try. But I have to go to $dayjob really soon. 23:12
pmichaud Who currently builds the .rpm modules that are available for fedora?
23:12 patspam joined
nopaste "NotFound" at 213.96.228.50 pasted "Patch; Use vtable slot nums instead of names in default and null" (132 lines) at nopaste.snit.ch/17440 23:14
NotFound Can someone take a look at this patch? 23:15
dalek tracwiki: v89 | bacek++ | WikiStart 23:17
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
chromatic NotFound, looks decent; what are you trying to do there? 23:18
Smaller executable size by reusing C string constants where possible? 23:19
23:20 donaldh joined
NotFound chromatic: yes 23:20
chromatic I'm all for that. 23:21
NotFound In some cases the strings are optimized by the C compiler, but not all.
chromatic default.o is 303112 bytes on my machine. 23:22
48372 stripped.
NotFound 377064 here, but is 64 bits
29400 stripped 23:23
chromatic How big is it after the patch?
NotFound Hu, wait, this was with --optimize --debugging=0
dalek tracwiki: v1 | bacek++ | KeysRefactor 23:24
tracwiki: trac.parrot.org/parrot/wiki/KeysRe...ction=diff
23:24 dukeleto joined
NotFound I'll look at my laptop before and after 23:25
23:25 bkuhn joined
NotFound Before: 216952 - 33992 stripped 23:31
After: 205980 - 29096 stripped
bacek chromatic: trac.parrot.org/parrot/wiki/KeysRefactor 23:33
chromatic thanks.
bacek $dayjob time
dalek tracwiki: v2 | bacek++ | KeysRefactor 23:34
tracwiki: trac.parrot.org/parrot/wiki/KeysRe...ction=diff
23:35 dukeleto joined
NotFound Null PMC 23:37
purl i think Null PMC is or ought to be like a C NULL ptr, so no
NotFound Before: 167604 - 30588 stripped
After: 143364 - 14892 stripped
Not bad 23:38
chromatic Definitely an improvement. 23:39
Now for libparrot. 23:40
NotFound libparrot.so.1.4.0 23:47
Before: 10382421 - 3442576 stripped
After: 10363829 - 3426192 stripped
chromatic Not huge. 23:48
Whiteknight space savings is good, if it isn't adding a performance penalty 23:49
dalek kudo: a53a1cd | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 423 files, 12114 passing, 8 failing

   S12-enums/basic.rakudo aborted 2 test(s)
   S12-introspection/walk.t aborted 6 test(s)
NotFound Whiteknight: the possible penalty is for throwing exception for null access or vtable not implemented, not a big problem. 23:50
Whiteknight ok 23:51
NotFound libparrot.a
Before: 18652260 - 3351288 stripped
After: 18618096 - 3331744 stripped
More or less the same than the .so
The only disadvantage is a lot more of symbols in vtable.h, but there is no measurable impact in the compilation. 23:54
Whiteknight ok 23:56
NotFound I'll commit it now, if nobody objects.
particle i forgive you. 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!