Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets; merge branches; review Git conversion plan
Set by moderator on 7 September 2010.
00:00 kid51 is now known as kid51_at_dinner
sorear just skip_all nt/exit 00:09
NotFound I just deleted alll and forked again 00:11
dalek TT #1781 created by plobsing++: examples/benchmarks/freeze.pasm broken in r48918 00:25
TT #1781: trac.parrot.org/parrot/ticket/1781
00:26 eternaleye_ is now known as eternaleye 00:39 tcurtis joined 00:47 davidfetter left 00:54 kid51_at_dinner is now known as kid51
dalek TT #1782 created by NotFound++: C++ build broken in r48923 00:59
TT #1782: trac.parrot.org/parrot/ticket/1782
tcurtis Hello, folks. 01:07
whiteknight hello tcurtis 01:09
tcurtis How's PLA coming, whiteknight? 01:22
whiteknight tcurtis: very well, thanks. I'm putting together some online documentation for it now. I'm planning a release to follow 2.8
kid51 whiteknight: How much linear algebra would someone need to know to appreciate/use PLA? 01:25
whiteknight kid51
: not much, really. Basically it only provides some matrix types now. Bsically 2-D arrays
it does support some of the mathematical operations on matrices too, but those aren't really necessary to use
kid51 once studied linear algebra. Nixon was president.
whiteknight :) 01:26
the ComplexMatrix2D PMC type is an extremely efficient storage solution for Complex values 01:28
...if that's something anybody cares about
NotFound I suppose it can be useful for doing 3-D oprations for graphics.
kid51 I ask because I've been thinking ... 01:29
... (which is always dangerous) ...
... that in the first half of 2011, it would nice to be able to have a "road show" of projects built on Parrot ... 01:30
tcurtis whiteknight: whiteknight.github.com/parrot-linear-algebra/ is excessively wide on my screen (I have to scroll right to read some of the text and to see the sidebar). On the PMC documentation pages, I have the opposite problem.
whiteknight japhb, I think, was talking about using the matrix type as a screen buffer for graphics
kid51 ... both the ones people expect (i.e., Rakudo) and the ones they don't expect (such as PLA)
dalek rrot: r48925 | jkeenan++ | trunk (4 files):
Applying patch submitted by ash++ in �trac.parrot.org/parrot/ticket/1774, plus additional tests for case of new configuration option '--without-readline'.
whiteknight tcurtis: that's weird. I don't specify any screen widths, I don't think
kid51 hmm, you can tell that's a whiteknight page: white type on black background 01:31
not good on kid51's eyes 01:32
NotFound kid51: I'm doing a Gtk wrapper via Gtk2 perl5 module via blizkost that will be good for presentations for people that only appreciate things with GUI.
whiteknight kid51: I'm no artist. I rarely use color, and I stick with what I know
:)
kid51 But I don't have problem tcurtis reports
dalek TT #1774 closed by jkeenan++: Adding without-readline support
TT #1774: trac.parrot.org/parrot/ticket/1774
whiteknight kid51: If you can suggest to me a better color scheme, I'll consider changing it 01:33
NotFound whiteknight: you can add some men at work signs, to give it a full good old geocities fashion ;) 01:34
01:34 hercynium left
whiteknight again, not an artist 01:35
NotFound Talking about art, we still lack a scalable version of the parrot logo. 01:36
01:39 ash_ left
whiteknight well, on that front: is the current parrot logo something we want to keep and use, or do we want a different one? 01:40
if we don't have a scalable version of it, we'll need to recreate it in a scalable format. Getting it right could be a huge pain in the butt 01:41
NotFound If someone provides a better one, I suppose we can switch.
whiteknight That's not really a serious proposal, I'm just musing out loud 01:42
kid51 whiteknight: When you get a chance, can you comment on trac.parrot.org/parrot/ticket/1450 ?
msg Coke Can you comment on trac.parrot.org/parrot/ticket/1450 ? Thanks. 01:43
purl Message for coke stored.
aloha OK. I'll deliver the message.
whiteknight kid51: sure. I'll do it now
I'm fine with closing the ticket 01:45
kid51 msg allison When you get a chance, can you comment on trac.parrot.org/parrot/ticket/905 ? Thanks.
purl Message for allison stored.
aloha OK. I'll deliver the message.
kid51 whiteknight: ok, but presumably coke has something to say before we close it
plobsing C++ build has been broken for a while. why don't we have ttbot++ complaining at us?
whiteknight I'm sure. My vote is cast, anybody else can have their say too
NotFound plobsing: usually I am ttbot++, but these days I've been buliding with C for blizkost compatibility. 01:47
plobsing I'm trying to fix TT #1782, but there have been a number of changes that each broke C++ build independantly. fun. 01:49
NotFound plobsing: I can take care of them.
(not today) 01:50
plobsing I really don't know how to fix "src/packout.c:280:30: error: cast from ‘void*’ to ‘int’ loses precision
it's an explicit cast. why can't C++ shut up and deal?
NotFound Error? No warning? 01:52
plobsing yeah. error. no idea why.
NotFound I'm too sleepy to look at it right now, sorry. 01:53
plobsing It's cool. I'm lukcy, I'll be able to figure it out somehow. 01:54
lucky even
NotFound We have some macros for convoluted casts.
01:55 shockwave joined
shockwave Hi. 01:55
I'm having some trouble compiling a file to PBC. 01:56
kid51 Uh-oh: Starting to get things like this in 'make test' on Darwin/PPC: src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
I was not getting that yesterday at this time. 01:57
shockwave Up until now, I've running my compiler's output by simple doing: ./parrot -I someDir someDir/file.to_run.foo -- Which runs fine.
However, when I try to create a pbc, by adding the -o output_name, only a blank file is created.
I must be overlooking some silly detail.
plobsing kid51: that's likely related to TT #1781 02:00
shockwave: what is the exact command you run that generates a blank PBC file? are there any diagnostic messages printed? 02:01
shockwave @plobsing: I copied the parrot exec/lib to the output directory, so that I don't have to use the -I flag. But still, no luck. Here's the command: 02:02
./parrot -o tmp.rune TestOutput.s_stream_2_xml_2.proof
No diagnostics
if I remove the -o tmp.rune from the command, the file is ran fine. 02:03
plobsing hmmm... parrot still uses file extension to determine filetype in a number of places. try changing the name to tmp.pbc.
cotto is afk for most of the evening 02:04
shockwave @plobsing: thanks. That wrote a non-empty file. 02:05
If I may ask you another question.
Now, when I run that pbc file, I get a Null PMC error. 02:06
dalek TT #1783 created by jkeenan++: t/compilers/pge/p5regex/p5rx.t and t/compilers/pge/perl6regex/01-regex.t: ...
TT #1783: trac.parrot.org/parrot/ticket/1783
shockwave Do all the .include'ed files get baked into the PBC, or not?
plobsing null pmc error... progress :-D
shockwave Yep :)
To tell you the truth, when I saw that blank file get created a few times, my heart skipped a few beats. 02:07
plobsing yes, all included files are baked into the PBC.
shockwave Compared to that, errors are much better :)
plobsing I'd suggest filling a ticket (if one doesn't already exist) about alternate file extensions. 02:08
shockwave That's weird, then.
@plobsing: If you want, I can do it. But, I don't really need it. And, in fact, I did mean to use the .pbc extension. I'm saving that .rune extension for something else. I just had it in mind, and kept writing it. 02:09
That null pointer error, otoh... that's something. 02:10
Some of the file my compiler generates have different file extensions, such as .proof, .init, and .main -- I hope that's not the case 02:14
They get read fine, like I said, when just running them with ./parrot ... 02:15
plobsing really? I thought parrot would assume them to be pbc files by defalt. 02:16
s/defalt/default/
shockwave The only reason I'm doing that is to match them up with their correct .pir counterparts.
I'll test naming them all with the .pir extension. 02:17
02:18 kid51 left 02:20 whiteknight left 02:22 sjn joined
tcurtis shockwave: ooc, is your compiler available anywhere online? 02:22
shockwave tcurtis: Unfortunately no. 02:23
Darn, that issue is not name related :(
I manually edited the files, and renamed them with the .pir extension.
02:24 kid51 joined
plobsing shockwave: if I've understood correctly, you are compiling up a number of files using a bunch of includes. could you try compiling smaller sets of files or even individual files in an attempt to pinpoint the problem? 02:26
02:27 patspam joined, patspam left
ttbot Parrot trunk/ r48925 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/389770.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 02:28
plobsing yay! ttbot lives!
shockwave @plobsing: Sure. But, I'm gonna have to do this tomorrow. I can't keep my eyes open anymore. (I get up at 5am).
I'm sure I'll be back asking for more help.
Thanks for getting me this far. 02:29
bye
02:29 shockwave left 02:35 janus left, ash_ joined 02:41 alin left, ash_ left 02:44 kid51 left 02:48 janus joined 03:25 sjn left 03:36 sjn joined 04:24 luben left 05:32 gaurav joined 05:44 gaurav left
dalek rrot: r48926 | plobsing++ | trunk (7 files):
fix C++ build
 05:57
rrot: r48927 | chromatic++ | trunk/src/gc/system.c:
[GC] Fixed unoptimized builds in stack tracing.

marked don't need. This whole system is a mess of false and foolish premature isomorphism, but we can live with this for now (unless someone beats me to cleaning up this approach before we replace this part of the GC).		 06:31
TT #1782 closed by plobsing++: C++ build broken in r48923 06:35
TT #1782: trac.parrot.org/parrot/ticket/1782
rrot: r48928 | chromatic++ | trunk/src/pmc/nci.pmc:
[PMC] Fixed GC bug in NCI's mark().
 06:47
07:38 tcurtis left 07:59 tadzik joined 08:06 cosimo left
mikehh t/op/integer.t and t/pmc/bigint.t FAIL in make corevm/make coretest - error:imcc:loadlib directive could not find library `sys_ops' 08:32
all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48928 - Ubuntu 10.04 i386 (g++ with --optimize)
08:38 tadzik left 08:45 barney joined 09:00 cosimo joined 09:12 mikehh left
dalek ast: defbf3b | moritz++ | S0 (2 files):
random rakudo unfudges
 09:27
moritz whoever configured dalek, roast should report o #perl6, not #parrot 09:28
*to
dalek ast: 3d90aad | moritz++ | S03- (2 files):
fix two tests that used non-matching series endpoints
 09:34
ast: c3f4ab2 | moritz++ | S32-list/grep.t:
fix another series misuse
 09:40
ast: 2832230 | moritz++ | S03-operators/series- (2 files):
[series] fudge fixes
 09:52
09:58 whiteknight joined 10:03 barney left 10:07 mikehh joined 10:08 contingencyplan joined 10:12 fperrad joined, baest left
whiteknight good morning, #parrot 10:12
dalek ast: d3868b4 | moritz++ | S04-statements/given.t:
[given.t] unfudge test using .so
 10:18
10:22 tadzik joined 10:44 slavorg left 10:51 slavorg joined
dalek rrot: r48929 | whiteknight++ | trunk/docs/project/release_manager_guide.pod:
fix a typo with the 3.0 release date. Add dates of releases through 3.6
 10:58
allison msg kid51 commented on TT #905 11:13
purl Message for kid51 stored.
aloha OK. I'll deliver the message.
11:13 allison left
dalek rrot: r48930 | NotFound++ | trunk/t/pmc/packfile.t:
add some more Packfile PMC tests
 11:31
11:45 atrodo left
dalek TT #1784 created by whiteknight++: distutils fails sdist and bdist if zlib is not installed 11:53
TT #1784: trac.parrot.org/parrot/ticket/1784
tadzik new parrot fails with LDFLAGS=--as-needed, is that known? 11:58
(fails to build)
whiteknight fperrad: ping 12:04
how do I go about making a .deb file for my project using distutils? 12:10
12:31 sjn_ joined 12:33 sjn_ left
dalek nxed: r627 | NotFound++ | trunk/winxedst1.winxed:
minor refactors
 12:41
12:47 aloha left 12:48 bacek left 12:59 kid51 joined
kid51 Just got this build failure on Darwin/PPC at r48930: <src/glut_nci_thunks.nci 13:03
src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
make: *** [src/glut_nci_thunks.c] Error 134
Re-building to confirm.
13:18 Patterner left
kid51 Well, I got 'make' to complete. But am still getting same test failures reported in TT #1783 yesterday. 13:18
13:28 Psyche^ joined, Psyche^ is now known as Patterner
plobsing kid51: can you get a backtrace of the failing assertion? (I tried, but I can't get it to fail on linux/x86_64) 13:46
fperrad pong whiteknight
whiteknight fperrad: how do I make a .deb using distutils?
I can see some stuff in the code, but I can't quite figure out all the steps to make the package 13:47
kid51 plobsing: I don't know how to do that
plobsing kid51: do you have gdb? if you run the failing parrot program (gdb --args ./parrot etc.pbc), it will halt at the failing assertion. then run bt to print a backtrace. 13:48
whiteknight fperrad: if I do "setup.nqp control" it looks like I get all the .deb metadata. Is that what I'm supposed to do or is there a different step I should run? 13:50
fperrad whiteknight, distutils doesn't make .deb, like it makes a RPM or SRPM,
but the command :
$ setup.pir control
creates some useful files in port/debian 13:51
dalek TT #1781 closed by plobsing++: examples/benchmarks/freeze.pasm broken in r48918
TT #1781: trac.parrot.org/parrot/ticket/1781
13:51 tadzik left
whiteknight yeah, okay. so after that I can use some external tools to make the .deb? 13:51
fperrad the next step is read : www.debian.org/doc/maint-guide/
kid51 plobsing: I typed: gdb --args ./parrot t/compilers/pge/p5regex/p5rx.t 13:55
When the gdb prompt appeared, I typed: run t/compilers/pge/p5regex/p5rx.t
All the tests ran and I got this result: Program exited normally.
whiteknight fperrad: yeah, I've been reading that. Thanks.
plobsing well there's your fix... just run parrot through gdb all the time ;-) 13:56
kid51 Got same result with: run t/compilers/pge/perl6regex/01-regex.t 13:57
plobsing do the same files fail when run with just ./parrot ? if not maybe the harness is using some flags. 14:01
kid51 plobsing: Running: ./parrot t/compilers/pge/p5regex/p5rx.t t/compilers/pge/perl6regex/01-regex.t ... 14:04
... the first test fails at the same point (after completing 233), with this:
src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
Abort trap
And, earlier, I got the same result running the 2nd test just by itself in the same way 14:05
plobsing can you try (under gdb and not) the --gc-debug flag? 14:06
kid51 perl t/harness --gc-debug t/compilers/pge/p5regex/p5rx.t .... ends with: 14:07
t/compilers/pge/p5regex/p5rx.t .. 209/960 src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
t/compilers/pge/p5regex/p5rx.t .. Failed 727/960 subtests
(less 8 skipped subtests: 225 okay)
Again invoking 'gdb' as before, only calling: run --gc-debug t/compilers/pge/p5regex/p5rx.t, I get same result, i.e., all tests complete and I conclude with: Program exited normally. 14:09
dalek ast: fd2903a | moritz++ | S03-operators/series-nonnumeric.t:
fix another old-school series test
 14:10
kudo: 62e168d | patrickas++ | src/core/operators.pm:
Starting to implement new series spec
 14:11
kudo: 953705a | patrickas++ | src/core/operators.pm:
There is no more need to check of the wrong side
kudo: 6483439 | patrickas++ | src/core/operators.pm:
Simplify the limit-reached code since geometric series don't require use of abs() anymore
kudo: c6e6807 | patrickas++ | src/core/operators.pm:
Simplify the code, we don't need the type of the series anymore
kudo: 9f204b1 | patrickas++ | src/core/operators.pm:
1..* ... 5 and @fib ... 8 (where @fib is infinite lazy) now work
kudo: 927c28c | patrickas++ | src/core/operators.pm:
Simplify limit check and when in doubt next is .succ
kudo: 09f36de | patrickas++ | src/core/operators.pm:
.succ instead of src/core/operators.pm.succ
kudo: 23cffdb | moritz++ | src/core/operators.pm:
Merge remote branch 'patrickas/series-new-spec'

This implements the new series spec, and at the same time significantly simplifies the code.
To quote github.com/rakudo/rakudo/pull/4 :
  * No more special cases for geometric series switching sign
  * No more special case 'limit is on the wrong side'
  * Literal limit must smart match exactly
  * Code on the rhs returns true to indicate limit has been reached.
  * Code on the rhs cannot have arity > 1		 14:12
plobsing kid51: well, that's pretty much the end of my bag of tricks. I really don't see what gdb could be doing to modify the program execution so that it doesn't fail. 14:15
kid51 ISTR that we've encountered this paradoxical situation before
NotFound Is Darwin, it adapts to survive. 14:16
kid51 I am now bisecting
dalek ast: 9560604 | moritz++ | S03- (10 files):
move series test to new S03-series/ directory
 14:17
ast: e118651 | moritz++ | S03-series/misc.t:
[series] comma before series is caught at compile time, so change test to eval_dies_ok
kudo: fb4feba | moritz++ | t/spectest.data:
track test file rename
kid51 i.e., a situation in which a test file fails via 'prove' or 'perl t/harness' but succeeds when run thru 'gdb'. 14:20
dalek rrot: r48931 | NotFound++ | trunk/src/pmc_freeze.c:
check PMCNULL instead of NULL and improve the Exception thrown in Parrot_visit_loop_visit
 14:35
ast: 4e24c6c | moritz++ | S03-series/ (4 files):
lots of series unfudges for rakudo
 14:36
kudo: a93dcb6 | moritz++ | / (2 files):
[docs] update ChangeLog
 14:41
14:42 cognominal left, cognominal joined
dalek ast: 1beb062 | moritz++ | S03-series/nonnumeric.t:
[series] oops, unfudged too much in previous commit; adding back a fudge marker now
 14:42
kid51 r48918 is the source of the problem in TT #1783: trac.parrot.org/parrot/ticket/1783#comment:4 14:46
14:49 ash_ joined 15:03 patspam joined 15:04 davidfetter joined, kid51 left 15:08 whiteknight left 15:19 tcurtis joined
dalek p-rx: 184e828 | moritz++ | src/Regex/P6Regex/Grammar.pm:
catch p5 gneral quantifiers
 15:21
NotFound The next commit is funny 15:26
cotto sighs 15:33
15:33 ruoso joined
dalek rrot: r48932 | NotFound++ | trunk (3 files):
add a check for duplicated VTABLE functions in PMCs and remove two duplicates found while tesing it
 15:42
rrot: r48933 | nwellnhof++ | trunk/src/ops (2 files):
Fix find_codepoint opcode without ICU
15:43 patspam left 15:48 mikehh left
dalek TT #1758 closed by plobsing++: Segfault caused by new dynop mapping code 15:49
TT #1758: trac.parrot.org/parrot/ticket/1758
15:56 kid51 joined
dalek rrot: r48934 | NotFound++ | trunk/t/pmc/packfile.t:
fix test for Packfile set_integer_keyed_str with invalid key
 15:58
nopaste "plobsing" at 192.168.1.3 pasted "TT #1783 debug patch" (13 lines) at nopaste.snit.ch/23297 16:11
plobsing kid51: nopaste.snit.ch/23297 will turn the failed assertion into an infinite loop. you then can use gdb to attach to the already started program (using the 'attach <PID>' command) and obtain a backtrace. 16:12
16:27 tadzik joined
kid51 plobsing: When I apply that patch, then call 'make', 'make' is hanging at Linked: parrot_nci_thunk_gen ./parrot_nci_thunk_gen --loader-name=Parrot_glut_nci_loader --loader-name=Parrot_glut_nci_loader --loader-storage-class=PARROT_DYNEXT_EXPORT --output=src/glut_nci_thunks.c <src/glut_nci_thunks.nci 16:29
pmichaud there's an argument to be made that r48932 requires a deprecation cycle. 16:31
plobsing then it is working. the assertion failed. get the PID of the hung parrot process and attach.
16:34 sjn left
NotFound pmichaud: What is the reason? 16:37
purl rumour has it the reason is that the company isn't VC funded. VC funded companies tend to spend money like water or that you didn't patch it yet or that you didn't patch it yet or that you didn't patch it yet
pmichaud NotFound: because there could be users that rely on that particular bug, and now their code doesn't work. 16:38
kid51 plobsing: gdb ./parrot_nci_thunk_gen 11663
leads to
purl somebody said leads to was a type of verb.
kid51 0x0207e7c0 in Parrot_gc_mark_PMC_alive_fun (interp=0x600c30, obj=0x1065de0) at src/gc/api.c:169
169 while (!PObj_is_PMC_TEST(obj));
plobsing yes. that's the line of the failing assertion. running 'bt' should get you a backtrace now. 16:39
NotFound pmichaud: I profoundly dislike the idea of supporting stupidity.
Including our won.
pmichaud that's part of what a deprecation policy is for, though.
NotFound If something is obviously wrong, it should be fixed. 16:40
pmichaud I didn't say "don't fix it", I said "don't break our users' code"
nopaste "kid51" at 192.168.1.3 pasted "'bt' after applying plobsing's diagnostic patch to api.c" (31 lines) at nopaste.snit.ch/23298
NotFound pmichaud: What user code? Code affected by that thing disappears.
pmichaud Rakudo doesn't build because of that patch. 16:41
kid51 plobsing: is that what you were looking for?
NotFound pmichaud: It has duplicated VTABLE functions on its PMCs?
pmichaud There's one yes. I agree it's a mistake (and I'm fixing it now) 16:42
But the point of the deprecation policy is so that user code doesn't get surprised by these sorts of changes.
plobsing kid51: yes, that backtrace should help tremendously. I'm not all that familiar with gc (and trying to stay that way), so I'll defer to chromatic for the fix.
pmichaud (which we did.)
NotFound pmichaud: I don't expect anyone to be negatively impacted by better error detection. 16:43
pmichaud NotFound: then you were wrong.
the better approach is to issue a warning until the deprecation point, and fail after that.
anyway, it's not serious enough for me to argue heavily for. I'm simply pointing out that it violates the deprecation policy. 16:44
NotFound pmichaud: I don't buy that. If someone wants to do the deprecation cycle, fine, but I'm not going to do it. 16:45
pmichaud Fair enough.
I'm not saying we absolutely have to make this fix. But as one of the active users of Parrot I think I also have a responsibility to let Parrot devs know when they've done something that breaks our code. 16:46
If you'd prefer that I shut up about it, then I will.
NotFound Sorry if I'm being rude, but I'm tired of seeing lots of breaks without complaints, and complains for absolutely minor points. 16:47
pmichaud breaks without complaints?
NotFound Changes that break lot of things. Like the dynop debacle, for example. 16:48
pmichaud I did complain about that.
NotFound But it passed
pmichaud So, you would prefer I just shut up and not report these things? 16:49
tcurtis And resulted in some changes to our deprecation policy.
NotFound I'm not sure about what I prefer. 16:50
pmichaud sometimes when we discover that something breaks the deprecation policy, we decide to go with the lesser evil of causing some pain for downstream users rather than trying to strictly follow the policy, and to me that's okay. But we should at least acknowledge when it occurs. (more) 16:51
and this includes letting our downstream users know that a fundamental change was made outside of the policy. 16:52
kid51 plobsing++ for diagnostic assistance; let's hope c. can figure this out
pmichaud but simply saying "sorry, we don't support stupidity" doesn't seem to me to be very supportive. 16:53
NotFound In a extreme case, someone can argue that fixing a segfault breaks the deprecation policy, because some code may be expecting that the segfault happens.
pmichaud so, you're saying we should be free to ignore the policy in extreme cases, and we should be able to ignore it in non-extreme cases.
NotFound I just don't think that the purpose of the deprecation policy is to keep errors. 16:54
pmichaud it's there to keep errors that downstream projects may be inadvertently relying upon. 16:55
kid51 Patrick, may I ask a question ...
pmichaud kid51: sure
kid51 Does Rakudo (or any other downstream project) have some idea of which bugs it is *advertently* relying on?
pmichaud it's there to give downstream users the opportunity to adjust to things rather than "surprise! Your project no longer builds!"
NotFound pmichaud: I completely fail to imagine how someone mey be relying on having two chunks of source code and one being ignored.
kid51 (I haven't been involved in any downstream projects, so I don't have the user's perspective.) 16:56
pmichaud NotFound: because pmc2c now dies where previously it succeeded.
NotFound: in other words, when I type "make" for Rakudo, it no longer gets to a running perl 6 executable.
it now stops with an error
NotFound Because there is an error. 16:57
pmichaud an error that previously wasn't one.
it may have been poor coding style, but it wasn't a fatal error.
kid51: sometimes we do know that we're relying on certain bugs, yes. 16:58
when that happens, I try (but often fail) to add a test for the buggy behavior so that someone else knows we're relying on it
tcurtis Speaking of deprecation, was the charset/encoding distinction at all user-facing? 16:59
pmichaud tcurtis: very.
at least at the opcode level it certainly is.
at the PMC level I suspect it could be user-facing as well, especially for users that create their own String PMC types (such as Rakudo does) 17:00
kid51: but many times it's hard to know if a given feature is in fact a bug or "working as designed"
NotFound In fact is hard to know is it was designed. 17:01
s/is/if
pmichaud NotFound: agreed.
in the case of the segfault example, we've already declared that "Parrot should never segfault", so any user that relies on a segfault is in fact relying on an explicitly deprecated feature. 17:03
tcurtis Did the charset_massacre merge affect the user-visible behavior of strings?
NotFound Good point ;)
kid51 IIRC, our next *supported* release is Sept 21.
pmichaud kid51: Oct 21 17:04
kid51 k
pmichaud Jan, Apr, Jul, Oct
NotFound I'm having this failure during the build with --optimize=-O3
builtins_gen.pir compilers/pge/PGE/builtins.pg
NULL current PMC at 0 in visit_loop_todo_list - thaw
current instr.: 'parrot;PGE;Perl6Grammar;Compiler;__onload' pc 24 (runtime/parrot/library/PGE/Perl6Grammar.pir:75)
kid51 CAn we put in a deprecation notice today such that it will take effect after Oct 19 ... and revert the commit, changing die to warn?
pmichaud kid51: that would be the normal procedure, yes. 17:05
in rakudo's case it won't matter in about 10 minutes, as I'm fixing the rakudo bug (at least the one we've found)
NotFound The error message comes from r48931, previously it was a NULL PMC accessed.
pmichaud NotFound: line 75 is load_bytecode 'PGE.pbc' 17:07
kid51 NotFound: I think we could live until Oct 19 with a deprecation notice, and a revert of r48932, and a change from 'die' to 'warn' at line 74 of lib/Parrot/Pmc2c/PMC.pm
pmichaud so it does sound like a thaw issue
NotFound kid51: As I said, I don't oppose to do it, but I'm not going to do it myself.
kid51 Then I'll do it. 17:08
NotFound Fine
jnthn plobsing: I just blogged something roadmap-ish. 6guts.wordpress.com/2010/09/11/a-ro...x-changes/ 17:12
as I mentioned I would last night.
:-)
pmichaud kid51++ 17:19
plobsing jnthn++ # roadmap 17:25
jnthn :-)
jnthn afk for noms
17:28 chromatic joined
dalek TT #1785 created by jkeenan++: src/pmc/oplib.pmc, src/pmc/resizeablestringarr.pmc: Deprecate duplicated ... 17:29
TT #1785: trac.parrot.org/parrot/ticket/1785
chromatic Testing a fix for TT #1783. 17:33
pmichaud kid51++ # because one karma wasn't enough
chromatic The warning is my preference for now as well. 17:34
17:35 sjn joined 17:36 sjn left
dalek kudo: 085920f | pmichaud++ | src/pmc/perl6multisub.pmc:
Remove extra (unused) VTABLE get_pmc_keyed_int from perl6multisub. Discovered by NotFound++ (Parrot r48932) and masak++.
 17:37
17:38 nwellnhof joined, sjn joined, hudnix left 17:39 hudnix joined
plobsing NotFound: I can't reproduce your --optimize=-O3 error. what compiler/system are you on? 17:39
NotFound plobsing: amd64 debian gcc 4.3.2
17:41 patspam1 joined, patspam1 left
nwellnhof chromatic: TT #1783 might be caused by something on the stack that looks like a PMC pointer, but isn't. 17:41
chromatic Yeah, I found what should be an easy fix. 17:42
nopaste "nwellnhof" at 192.168.1.3 pasted "--- a/src/gc/system.c +++ b/sr" (12 lines) at nopaste.snit.ch/23299 17:44
nwellnhof Something like that?
chromatic That was my first thought, but I found something better. 17:45
dalek TT #1786 created by jkeenan++: Trac: 'Milestone' drop-down needs to display 2.10 and 2.11 17:46
TT #1786: trac.parrot.org/parrot/ticket/1786
chromatic kid51, can you test r48936? 17:49
dalek rrot: r48935 | jkeenan++ | trunk (4 files):
TT #1785: partially revert r48932 to conform to deprecation policy.
 17:55
rrot: r48936 | chromatic++ | trunk/src/gc/system.c:
[GC] Made is_pmc_ptr() much more accurate.
kid51 chromatic in progress 17:56
nwellnhof chromatic: i'm not sure your patch is safe. it can access random memory between pmc_min and pmc_max which might be unmapped. 17:59
chromatic Is the check better after contained_in_pool? 18:00
nwellnhof yes, that should be safe.
kid51 chromatic: Got: make: *** [compilers/opsc/gen/Ops/Emitter.pir] Segmentation fault 18:04
18:04 luben joined 18:07 kid51 left 18:08 patspam joined
dalek nxed: r628 | NotFound++ | trunk/winxedst1.winxed:
fix a mistake in keyed base classes
 18:09
nxed: r629 | NotFound++ | trunk/ (3 files):
Error for no program specified in installable driver
 18:14
18:28 jhelwig left
dalek rrot: r48937 | chromatic++ | trunk/src/gc/system.c:
[GC] Inverted the condition of r48936 for safety.

not be a PMC could read unmapped memory. Kablammo.		 18:29
18:52 M_o_C joined
plobsing NotFound: it appears this is another victim of -finline-functions. 18:52
NotFound plobsing: some function in particular? 18:53
plobsing not sure yet, but I can get it to fail with -O2 -finline-functions but not with only -O2 18:54
I'm not certain, but I suspect our stack-scanning code.
nwellnhof plobsing: is this with gcc 4.3? 18:55
NotFound I tend to suspect of wrong const casts or lack of NULLOK somewhere
plobsing nwellnhof: yes. 18:56
NotFound: how could either of those cause only inlined versions to fail? 18:57
NotFound plobsing: inlining combined with others optimizations may delete checks for NULL
nwellnhof i have the suspicion that gcc 4.3 with -finline-functions also inlines functions with __attribute__((noinline)). 18:58
NotFound And const assumptions can make use values on register rather than re-reading memory.
When the const qualifiers ara lies... Boom 18:59
plobsing the thing is, that PMC hasn't been alive long. it gets created at src/pmc/imageio.pmc:769 and the failure occurs in the first loop iteration of Parrot_visit_loop_visit called on the next line. 19:01
it doesn't appear to be put into any const containers 19:02
dalek nxed: r630 | NotFound++ | trunk/winxedst0.cpp:
start reworking of base class specifiers in stage 0
 19:08
NotFound WTF is the private1 flag in imageio? 19:09
plobsing whether or not we have an external packfile constant table to work from. 19:10
we use this knowledge to avoid generating extra PBC headers and also to leverage the existing string constants when available 19:11
I would have given it a better name, but I couldn't get the pre-processor to expand things in the correct order.
NotFound Where is the todo attribute initialized? 19:18
plobsing ImageIO.init 19:20
NotFound Empty
Where is populated?
plobsing ImageIO.shift_pmc 19:21
NotFound unused = STATICSELF.shift_pmc(); ?
plobsing yes. that is used to populate the first entry in the todo list
the first being the actual object that will be evenutally returned (ImageIO.get_pmc) 19:22
NotFound What if the first object is a PMCNULL?
plobsing it cannot be NULL. the null PMC is treated separately. also it is not null in this case (otherwise it would fail elsewhere) 19:24
19:27 M_o_C left 19:30 nwellnhof left
NotFound Unfortunately pbc_dump fails the same way. 19:32
19:35 fperrad left
nopaste "plobsing" at 192.168.1.3 pasted "PGE.pbc dump" (10005 lines) at nopaste.snit.ch/23300 19:35
NotFound I don't see anything wrong in a packfile.winxed dump
plobsing the packfile is fine. I can read it and manipulate it with my previously installed parrot tools. 19:36
NotFound For me it fails at loading Perl6Grammar.pir 19:37
I can compile it to pbc, and looks fine, but executing the pbc gives the failure. 19:38
19:40 Paul_the_Greek joined
Paul_the_Greek Good afternoon [here in Massachusetts], folks. 19:41
NotFound At least the pbc_dump backtrace is shorter 19:43
plobsing NotFound: first discrepancy I found - failing case reads a type of 4(UnManagedStruct) for the first PMC, as opposed to 8 (ParrotInterpreter) for the non-failing case 19:49
19:54 pjcj left
NotFound plobsing: the failure is while thawing the first item inside that, it isn't? 19:57
plobsing yes. and the first PMC constant of any PBC file is a ParrotInterpreter.
dalek kudo: 8669d77 | Util++ | build/PARROT_REVISION:
Bump PARROT_REVISION to include nwellnhof++ fix for non-ICU Parrots. Fixes RT#77778 part 2.
 19:58
plobsing NotFound: it appears the ImageIO is being fed a buffer that is 8 bytes offset from where it should be 20:06
NotFound plobsing: I'm not sure if it's really reading the constant segment 20:10
plobsing It is. If I use image->strstart[8] as the array base in the failing case, it matches up with image->strstart[0] in the non-failing case 20:11
I'm currently focused on PF_fetch_buf, which appears to be where the trouble is. 20:12
NotFound Nice, we just need to look for an 8 that fails when being inlined X-)
plobsing I suspect an opcde_t* isn't being incremented properly. 20:13
NotFound Yes, bytecode and fixups gets unpacked without problem. 20:14
20:17 AzureSto_ joined 20:20 AzureStone left
dalek rrot: r48938 | chromatic++ | trunk/src/string (2 files):
[string] Optimized Parrot_str_substr().

source directly. (Hooray for immutable STRINGs!) This optimizes Rakudo slightly by allocating fewer STRING headers.		 20:25
20:26 tadzik1 joined 20:27 ash_ left 20:28 tadzik left
plobsing NotFound: I'm testing a fix. Turns out gcc was breaking pointer aliasing. 20:28
NotFound plobsing: where? 20:31
plobsing in PF_fetch_opcode
stream wasn't being updated
at least when called from PF_fetch_buf
20:33 Paul_the_Greek left 20:36 tadzik1 left
nopaste "chromatic" at 192.168.1.3 pasted "Now that trunk works, can I get some review on this patch?" (53 lines) at nopaste.snit.ch/23301 20:38
plobsing NotFound: should be fixed at r48934
NotFound plobsing: it buils with --optimize='-O2 -finline-functions' Testing now with -O3 20:42
dalek rrot: r48939 | plobsing++ | trunk/src/packfile/pf_items.c:
tidy up PF_fetch_opcode.
rrot: r48940 | plobsing++ | trunk/src/pmc_freeze.c:
eliminate unused variable
NotFound -O3 build and pass tests. plobsing++ 20:46
plobsing chromatic: patch seems to be missing a mark and sweep run that could free up more memory before compact 20:47
also the "worthwhile" test for compacting is gone, so the comment is a bit misleading 20:48
chromatic We could yank the compact there too. 20:49
NotFound chromatic: patch pass tests in amd64 -O3
plobsing benchmarks or gtfo 20:50
chromatic Suggestions for a STRING-heavy benchmark?
I wrote this patch in response to pmichaud's mail sometime last week about Parrot's GC. 20:51
sorear micro or macro?
NotFound I'm going to install int and build winxed. Not a good benchmark but can give some idea.
20:52 patspam left 20:55 nwellnhof joined
NotFound No noticeable difference 20:56
chromatic It'll have to be something NQP-rx based, I'm sure.
nwellnhof chromatic: what's the purpose of the patch? if we skip a GC run there, we will simply run the GC at the next header allocation. 20:58
chromatic It's to decouple allocating new fixed-sized pools from GC runs. 20:59
It's much more likely to get into a situation where we've exhausted one fixed-size pool without making any GCables GCable than it is to fill up a GCable pool without making any GCables GCable. 21:00
nwellnhof the timing of GC runs now depends on a global condition. it is checked in two places: allocation of a memory block for fixed size headers and allocation of a memory block for variable sized buffers. 21:09
if remove the check in one of these places, the GC will be run as soon as we reach the other place. 21:10
dalek nxed: r631 | NotFound++ | trunk/winxedst1.winxed:
fix mistake with trans_ops commited when refactored lib loading
chromatic Enough other things allocate from pools we don't need to mark/sweep that I'm not sure running a full mark/sweep on exhaustion is useful. 21:12
nwellnhof exhaustion of a pool doesn't really trigger a GC run. it's just a good place to check for the global condition. 21:16
we have to change that condition if we want to make a difference. 21:17
taking freed memory into account, for example.
chromatic It's not even exhaustion of a pool, just not enough space in a pool for an allocation. 21:18
21:24 pjcj joined
nwellnhof but that doesn't trigger a GC unconditionally. it's only the place where we check whether to run a GC. we could put that check in as many places as we want. it wouldn't make a difference. 21:25
plobsing nwellnhof: so if we're running the GC too much, then it is because this condition is too often true? 21:31
nwellnhof plobsing: yes 21:33
but the condition is easily tunable to avoid GC runs at the expense of memory.
plobsing why don't we make the threshold higher then? or make it configurable such that rakudo could 'gcadvise .GONNA_ALLOCATE_A_LOT' 21:34
nwellnhof making it configurable is a good idea, IMO 21:35
chromatic Not everything that allocates a lot of memory from here is visible to Rakudo. 21:39
plobsing such as? 21:40
purl hmmm... such as is done with isgt vs islt now
plobsing purl, forget such as
purl plobsing: I forgot such as
chromatic Resizing storage of hashes and arrays.
plobsing resizing an individual array or hash isn't really visible. but rakudo knows that at startup it is going to be populating a lot of such objects. 21:43
dalek izkost: 489e3c7 | NotFound++ | src/pmc/bkmarshal.c:
Fix mistake caused by my previous commits, not sure why
 21:47
21:51 kid51 joined
plobsing hmmm... reviewing pmichaud's email, that's not really the problem. rakudo simply has a lot of objects and it is expensive to trace through them all. 21:55
pmichaud I looked at it further, a bit later. 21:56
That program resulted in 1700 mark and sweep runs
inside of the call to .'readall'()
plobsing we fixed that part thought, didn't we? 21:57
chromatic This patch gave me a 20% performance improvement ont hat benchmark though.
pmichaud plobsing: 'readall' was fixed, yes. That doesn't fix the generic problem that lots of string concats result in a huge number of GC marks. 21:58
I can come up with a straightforward Perl 6 program that exhibits the same behavior.
sub join($sep, *@list) { my $s = ''; for @list { $s = $s ~ $_ }; $s }; .... 21:59
oops, and I need a $sep in there. Anyway, you get the point.
sub join($sep, *@list) { my $s = shift @list; while @list { $s = $s ~ $sep ~ shift @list }; $s } 22:00
plobsing understood. so the problem is that GC is triggered to frequently by this common but pathological case? 22:01
not that GC costs too much to run?
pmichaud plobsing: I think it's both.
GC costs too much to run, and this case ran it too often.
simply loading static code shouldn't increase our GC load as much as it did. 22:02
let me put it a different way.
when perl6.pbc isn't loaded, we have 1740 mark runs.
when perl6.pbc is loaded, we have a few more mark runs, *and* those runs take a heck of a lot longer.
enough to make the difference between 2 seconds and 22 seconds. 22:03
and perl6.pbc is static.
(it's static from the perspective of "it's not doing anything other than sitting in memory")
plobsing I think we could squeeze some GC performance out of inlining common mark vtables. good candidates: Sub, FixedIntegerArray, Key, etc
pmichaud I think the order-of-magnitude win is to find some way to avoid "mark the world". 22:04
chromatic That's minor optimization though.
Mark/sweep the world is just too expensive.
pmichaud put another way, those optimizations would have likely made zero difference to my example.
chromatic Look at it this way: if we *know* we've thawed all Sub attributes from PBC, why do we ever need to mark them?
Those Sub attributes should never change, if we've designed Sub correctly. 22:05
pmichaud ...sub attributes aren't static?
plobsing they aren't
pmichaud they do change, unfortunately.
(my remark was in answer to chromatic's question... we mark them because they aren't static)
plobsing multidispatch, autoclose, various other "features"
chromatic They should be static.
dalek rrot: r48941 | NotFound++ | trunk/src (4 files):
replace several usages of Parrot_str_new_noinit(interp, 0) with CONST_STRING(interp, "")
pmichaud chromatic: probably they should be, but several pieces of parrot's design depend on them not being static. 22:06
chromatic Sure, and we need to fix that too.
The solution to "GC takes too long!" is "Don't mark/sweep things that never change." and "Mark/sweep only what may have changed."
22:07 ash_ joined
plobsing avoiding marking the world is hard. we could make the world smaller though. I doubt most Perl 6 programs actually make use of all of the facilities rakudo provides. If these could be lazily loaded somehow... 22:07
dalek kudo: 9734b29 | chromatic++ | src/pmc/objectref_pmc.template:
[PMC] Made ObjectRef's mark() more accurate.
pmichaud plobsing: that's actually pretty hard to do (more)
most of Perl 6's features are built in terms of other Perl 6 features 22:08
I suppose some of them could be autoloaded. But I suspect it doesn't decrease the core working set by a significant amount. 22:09
22:09 kid51 left
pmichaud (I could be wrong about that; but that's my guess based on the code I've seen.) 22:09
plobsing every single method, block, hash access, namespace lookup, etc adds more gcables 22:10
I imagine those add up quite quickly
oh, I forgot function and method calls 22:11
pmichaud from a design perspective, the existence of lots of gcables shouldn't be causing huge performance penalties, though.
if it does, that's a design flaw.
We want programs running on Parrot to be able to handle millions of elements, if not more. 22:12
plobsing It sounds as if we really want a generational gc
chromatic We do.
pmichaud changes his 'm' to a 'b'. 22:13
22:13 dafrito joined
jnthn We can avoid making the world every startup by making it once at compile time and serializing it. But that doesn't mean it won't be in memory. 22:13
pmichaud jnthn: did you mean s/making/marking/ ooc? 22:14
jnthn making
pmichaud we're talking about "marking"
(gc)
jnthn My point being that without switching to a generational scheme, even doing less work at startup to construct all of those objects isn't going to mean there's any less to mark.
pmichaud I think plobsing's point was that by loading less of core Perl 6, there would be less to mark. 22:15
i.e., make some parts of the core dynamically loadable
instead of all-in-one-pbc as we do now.
jnthn That's less than trivial.
If we can find a way to mmap PMCs into memory then we could get it for free out of demand paging by the OS though. :-) 22:16
pmichaud :-)
gist.github.com/575618 # a simple experiment 22:22
99,000 PMCs is not, in the overall scheme of things, a lot of PMCs
(IMO) 22:23
22:24 kid51 joined
NotFound Someone know what is it? CONST { IMCC_INFO(interp)->is_def = 1; } INTC var_or_i '=' any_string 22:24
Declaring a .const pmc by number? 22:25
pmichaud maybe declaring a const int? 22:27
e.g., .const int somevalue = 4
22:28 M_o_C joined
NotFound const int type_enum = atoi(type); switch (type_enum) case enum_class_Sub: .... 22:28
pmichaud or is it the case of 22:29
NotFound Looks like a PMC by number. Isn't that deprecated since long time ago?
pmichaud .const 'Sub' xyz = 'somesub'
?
oh yes, it may indeed be the deprecated form
.const Sub xyz = 'somesub' # iirc
NotFound No, that isin the next branch: | CONST { IMCC_INFO(interp)->is_def = 1; } STRINGC var_or_i '=' any_string 22:30
pmichaud aha
NotFound There is a unused static function in imc.y used only by this.
pmichaud old PGE (parrot 0.4.10) has .const .Sub corou = '%0_corou'
so I'm guessing it's the one that handled the .Sub 22:31
NotFound Unused -> uncovered
pmichaud looks like PGE switched to the .const 'Sub' form in 0.8.1 22:33
NotFound Time to kill, then?
chromatic Do it.
pmichaud I'd try killing it and see what happens.
I suspect it's just a fossil.
NotFound The way to see what happens is to commit it. 22:34
pmichaud if pge/pct survive the change, then I can't imagine anything in rakudo or other HLLs will be affected.
0.8.1 was like... a very long time ago. :) 22:35
NotFound pmichaud: if coverage report says is uncovered, sure pge/pct can survive... or our test suite is a lot worse than I can imagine.
pmichaud good point.
anyway, +1 to kill :)
22:38 hudnix left 22:46 nwellnhof left
luben chromatic, is it time to merge hash-inlined branch? 22:52
chromatic I'm all for it. 22:53
luben by the way, make headerizer spits 2 warnings in compilers/imcc/parser_util.c (try_find_op) 22:54
NotFound luben: I'v seen it, going to fix in a while
22:54 kid51 is now known as kid51_at_dinner
luben ok, I'll wait for the fix in headerizer and the I'll merge the branch into trunc 22:55
dalek rrot: r48942 | NotFound++ | trunk/compilers/imcc (3 files):
delete fossil support for the long time ago deprecated form of declaring const PMC in PIR
 22:56
22:58 davidfetter left
NotFound luben: done, r48943 23:04
luben :) thanks. goint to resolve conflicts now, test and merge 23:05
dalek TT #1783 closed by jkeenan++: t/compilers/pge/p5regex/p5rx.t and t/compilers/pge/perl6regex/01-regex.t: ...
TT #1783: trac.parrot.org/parrot/ticket/1783
NotFound The better way to improve coverage is to delete unused code :) 23:07
luben Why does Bison generated parsers are checked in the repository? 23:10
NotFound luben: we don't want to require flex/bison install to build parrot. 23:11
luben aha, yes... but requires a lot of hand-work on generated code in branch merges 23:12
dalek rrot: r48943 | NotFound++ | trunk/compilers/imcc (2 files):
add can return null decorator to the try_find_op imcc function and make it static
plobsing luben: I tend to just regenerate those files when they have a merge conflict. 23:13
NotFound luben: just ignore it, and rebuild after the mergr
chromatic Same with headerizing. 23:14
luben aha, yes... nice to know
23:14 dafrito left 23:26 M_o_C left
NotFound The function Parrot_pcc_do_run_ops is never used in the repo. Its pod says "Used in tailcall for updating RetContinuation". Can we consider it covered by the deprecation and deletion of RetContinuation ad kill it? 23:27
23:37 patspam joined
jnthn Anyone know if the PMC compiler can handle an ATTR that is a function pointer? 23:41
tcurtis jnthn: are you porting your new metamodel back to Parrot? 23:43
jnthn "back"? :-)
But yes, to :-)
tcurtis: I blogged a roadmap earlier. 23:44
tcurtis: Figured I'd make the first little steps. :-)
plobsing jnthn: probably not a straight function pointer declaration, but a typedef'd thingy should probably work. 23:45
luben hash_inline_func merged :)
jnthn plobsing: OK
dalek rrot: r48944 | luben++ | trunk (11 files):
Merge hash_inlined_func branch
 23:46
rrot: r48945 | luben++ | trunk (2 files):
headerizer run
NotFound But you need to typedef it in a place the generated header can see
jnthn ah, hm
Maybe I'm safer just declaring the struct I want and sorting stuff out manually.
plobsing and, last I tried, I couldn't tell pmc2c to put things in the header 23:47
jnthn Probably want it to be a PMC.
(reprs)
plobsing note that nci.pmc skirts the whole issue by using void*
jnthn heh 23:48
23:48 hudnix joined
jnthn oh hmm...GET_ATTR and SET_ATTR also always do "have we been subclassed" checks... 23:48
Er, subclassed at PIR level
Don't really want that. 23:49
plobsing you can avoid that by getting the attributes struct and doing element lookup directly.
jnthn Yeah
ttbot Parrot trunk/ r48944 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/390546.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ )
23:49 particle left
jnthn Well, thing is, almost all the usage of the stuff in the struct will be by stuff outside the PMC anyway 23:49
The PMC isn't much more than a "holder"
jnthn is still working out how to map everything to C / Parrot. 23:50
23:50 particle joined
jnthn I guess if you squint a struct full of function pointers is a tiny bit like an interface. :-) 23:51
NotFound My god! It's full of function pointers! 23:52
jnthn I accidentally the whole struct. 23:54
cotto In C, we call those "objects". ;) 23:55
jnthn C-ing is believing... 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!