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.
plobsing luben: which system's malloc? which version? 00:07
luben I have tried to replace hash struct allocation 00:08
current versuion uses Parrot_gc_allocate_memory_chunk... that is a wrapper arround system malloc (linux-2.6.35, glibc02.11) 00:09
I have replaced it with Parrot_gc_allocate_fixed_size_storage 00:11
with the hope to get more speed
but in fact it's slower 00:12
plobsing on what benchmark? 00:15
nwellnhof luben: Parrot_gc_allocate_fixed_size_storage should be only used for small allocations 00:16
bacek_at_work luben, strange. Allocating from fixed_size_storage is (mostly) adjusting of 2 pointers only.
nwellnhof ah, you mean the hash struct itself
luben nwellnhof, I used it just for the header (the struct) 00:17
dalek rrot: r48969 | chromatic++ | trunk (2 files):
[pf] Coalesced empty STRINGs during thawing.
luben I'll work further on this idea... 00:22
whiteknight I wonder what we need to do to get a smolder server up and running again 00:27
because not having that is a huge drag 00:28
dalek rrot: r48970 | whiteknight++ | trunk/docs/project/release_manager_guide.pod:
Pencil in myself for the Dec release, and kid51 for the Jul release.
 00:34
00:40 nwellnhof left 00:42 kid51 joined
dalek TT #1786 closed by jkeenan++: Trac: 'Milestone' drop-down needs to display 2.10 and 2.11 00:53
TT #1786: trac.parrot.org/parrot/ticket/1786
nxed: r644 | NotFound++ | trunk/examples/fly.winxed:
change the way to stop the timer in example fly to avoid race conditions while
 00:59
purl dalek: that doesn't look right
whiteknight purl ignore dalek 01:07
purl whiteknight: huh?
whiteknight you heard me
01:07 whiteknight left
Paul_the_Greek Parrot debugger now loads the ENTIRE source file. 01:08
kid51 Paul_the_Greek is that a feature or a bug? 01:09
Paul_the_Greek The current debugger drops the last line of the file. 01:11
Maybe only if it doesn't have a newline at the end. 01:12
Now I'm ready to get breakpoints to work.
mikehh kid51: ping
kid51 make fulltest PASS r 48970 linux/i386 01:13
mikehh: pong
mikehh I am getting a failure in t/postconfigure/05-trace.t - Failed tests: 7, 9 01:14
01:16 Paul_the_Greek left
mikehh I have just installed Ubuntu 10.10 beta amd64, so maybe I am missing something 01:16
kid51 make realclean 01:17
mikehh it was from a new checkout, but let me try again 01:20
kid51 The .configure_trace.sto created by using --configure_trace needs to get wiped out in order to store meaningful results; only make realclean does that
dalek rrot: r48971 | jkeenan++ | trunk/config/auto/pcre.pm:
Apply 1 of several patches submitted by ronaldws++ in �trac.parrot.org/parrot/ticket/1401. Express 'result' more clearly -- 'no' -- when PCRE not found.
 01:24
mikehh kid51: seems to ok now - no idea what went wrong 01:31
kid51 mikehh: I've had that from time to time. You configure with --configure_trace. You see some test failure or something you want to fix. You hack. You re-configure with --configure_trace -- but without 'make realclean'. You basically end up with the whole structure inside that .sto repeated -- which causes the count of steps to double and the test to fail. 01:34
But don't sweat it. You and I are the only ones who care about that :-)
Since no one's doing any heavy overhauling of the config system right now, no one needs --configure_trace very much. 01:35
But its day may come again!
mikegrb kid51: about that malloc bug, so sorry, been slammed at work with an office move and other things, I've not had a chance to update rakudo and parrot but it was easy to reproduce so if it's fixed now, feel free to close it <3 01:39
kid51 mikegrb: Do you remember which Trac ticket that was? 01:40
mikegrb I can look
kid51 1707, correct?
mikegrb yes 01:41
01:41 TiMBuS left
kid51 got it 01:41
01:41 TiMBuS joined
mikegrb oh, coke already configmed it works 01:41
dalek TT #1707 closed by jkeenan++: attempt to mmap 2325622477335777280 bytes when printing utf8 in perl6 01:44
TT #1707: trac.parrot.org/parrot/ticket/1707
02:09 kid51 left 02:35 janus left 02:36 janus joined 02:46 bacek left, aloha left 02:53 petdance joined 03:05 patspam joined 03:29 bluescreen left 03:50 patspam left
cotto anyone know how many tickets have been closed since last #ps? 04:05
sorear trac.parrot.org/timeline would 04:06
cotto That's what I was looking for. sorear++
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (-1 to go); merge branches; review Git conversion plan 04:09
cotto and there's a good variety of people closing them too 04:10
sorear -1. heheh. 04:25
tcurtis sorear: irclog.perlgeek.de/parrot/2010-08-31#i_2768121 04:29
05:29 ash_ left 05:50 petdance left 05:59 plobsing left, s1n left 06:04 fperrad joined
dukeleto 'ello 06:05
06:09 uniejo joined
dukeleto uniejo: hello 06:11
06:13 baest joined 06:34 luben_work joined 06:35 davidfetter left 06:48 s1n joined 07:09 jsut_ joined 07:10 tadzik joined 07:14 jsut left 07:27 bacek joined 07:32 aloha joined
dalek tracwiki: v26 | dukeleto++ | GitMigration 07:33
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
dukeleto ponders keeping the term revision in parrots guts. it would require a lot less code churn 07:41
parrot_config revision, Parrot::Revision, etc... 07:42
07:43 tadzik left
dalek rrot: r48972 | mikehh++ | trunk/config/auto/pcre.pm:
fix codetest failure - perlcritic - hard tabs used
 07:51
08:08 tcurtis left
dalek ast: 2f690f9 | leto++ | S32-num/rat.t:
[S32-num] Add fudged test for NaN.Rat
 08:25
ast: 326ee0a | leto++ | S32-num/rat.t:
[S32-num] Add some tests for Rat representation of Inf
 08:42
bacek aloha, humans 09:38
seen chromatic
purl chromatic was last seen on #parrot 1 days, 6 hours, 47 minutes and 31 seconds ago, saying: Cleanliness is good. [Sep 12 02:51:14 2010]
aloha chromatic was last seen in #parrot 4 days 10 hours ago joining the channel.
bacek seen whiteknight 09:39
purl whiteknight was last seen on #parrot 8 hours, 31 minutes and 58 seconds ago, saying: you heard me
aloha whiteknight was last seen in #parrot 8 hours 31 mins ago saying "you heard me".
bacek oookey
09:40 tadzik joined 09:48 jsut joined
luben_work good morning bacek 09:52
do you have a minute to give me an advice?
09:53 jsut_ left
bacek luben_work, sure 09:53
luben_work I am working now on parrot_hash
you were right - fixed size allocator is really fast 09:54
it was my fault
when I thought it's slow
09:54 ruoso left
luben_work I have converted all memory allocations in hash handling code to use fixed_size pools 09:55
bacek :)
luben_work 3.5-4% performance gain :)
bacek hooray
ship it :)
luben_work but I am not sure if it is the appropriate type for all of the memory allocations 09:56
bacek Hmm...
fixed_size allocator is for small objects only 09:57
luben_work for the header it's fixed_size - it's OK
bacek Look at src/pmc/callcontext.pmc for example for switching from fixed_size to sys_mem
But hashes includes buckets allocations 09:58
luben_work but what type to use for buckets and index areas
bacek exactly
you can use fixed_size allocator for "small hashes"
But it's better to switch to sysmem for "big one"
luben_work I have separated hash struct from index/buckets 09:59
bacek ah
it was single chunk of memory before, afair
luben_work yes. it is still this way, in trunc 10:01
another idea I could try is to make separate allocation for each bucket... 10:05
Is there any way to make GC run on this without custom mark function like now? 10:06
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' 10:16
all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48972 - Ubuntu 10.10 beta {gcc-4.5)
also get - FATAL ERROR: Duplicated VTABLE function: get_integer at /home/mhc/t.parrot/tools/build/../../lib/Parrot/Pmc2c/PMC.pm line 74
does not seem to effect the test results
bacek luben_work, can you rephrase your question? I didn't quite get it 10:18
mikehh build error with g++: src/string/api.c:999:16: error: invalid conversion from ‘const STRING*’ to ‘STRING*’ and also 10:24
src/hash.c:1468:71: error: invalid conversion from ‘const STRING*’ to ‘STRING*’
src/hash.c:1468:71: error: initializing argument 2 of ‘size_t key_hash_STRING(parrot_interp_t*, STRING*, size_t)’
dalek rrot: r48973 | mikehh++ | trunk/src (2 files):
add casts to get g++ to build
 10:57
11:27 mikehh left
luben_work bacek, I was away for an hour. 11:28
My idea - not sure that it will bring performance gains 11:29
is to allocate each hash bucket with fixed size allocator
in this way, I could nuke the memory allocation from parrot_hash (it doubles the work of the GC) 11:30
another advantage is that hash expanging will become only realloc and rehash of the index, without recalculating pointers - they remain the same 11:32
this scheme has disadvantages - you could not iterate over a hash in a linear manner like now, indexed iteration is slower
so if this will bring some performance gains depends on the following: 11:34
could we make the GC walk the hash-buckets pool in a linear fasion (it will be much faster) 11:36
11:44 mikehh joined 11:56 kid51 joined 12:02 GodFather joined 12:04 plobsing joined
dalek rrot: r48974 | mikehh++ | trunk/src/packfile:
add svn:ignore (*.str)
 12:04
rrot: r48975 | Paul C. Anagnostopoulos++ | trunk/src/pmc/boolean.pmc:
Add empty headerizer lines
rrot: r48976 | mikehh++ | trunk/MANIFEST.SKIP:
re-generate MANIFEST.SKIP
12:23 kid51 left 12:26 whiteknight joined 12:32 contingencyplan left
whiteknight good morning, #parrot 12:32
12:33 smash joined
smash hello everyone 12:33
12:34 plobsing left
whiteknight good morning smash 12:34
dalek rrot: r48977 | mikehh++ | trunk/src/hash.c:
remove a compiler warning related to const
 12:38
12:54 patspam joined
Coke nwellhoff? 13:01
Ok. now aloha is annoying me as much as purl used to. I'll ask YA: why can we not make the cutover to aloha?
moritz +1 to cutover 13:02
Coke msg kid51 re: 1450 - I have no further comment on that ticket. FWIW, I am subscribed to parrot-tickets, so I don't need reminders here as well. 13:04
purl Message for kid51 stored.
aloha OK. I'll deliver the message.
Coke msg kid51 (I mean, reminders here are fine, but the belt & suspenders approach annoys me.) 13:05
purl Message for kid51 stored.
aloha OK. I'll deliver the message.
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' 13:13
all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48977 - Ubuntu 10.10 beta {g++-4.5 with --optimize)
purl might be annoying at times, but she still keeps track of messages and karma (mostly) 13:14
purl mikehh: excuse me?
mikehh YA see
moritz I have a script that extracts karma from the IRC logs 13:15
moritz.faui2k3.org/tmp/parrot_karma are the results of my last run (a few weeks ago)
I can re-run the script and provided for bacek++ to include it in aloha
mikehh moritz: we need to put it place so you can query it
13:16 uniejo left
moritz mikehh: my idea was to seed aloha's karma database with it, and let aloha track it from there on 13:16
aloha: karma mikehh
purl mikehh has karma of 1017
aloha moritz: mikehh has karma of 10.
moritz you see, it does track, it just doesn't have the old records
13:18 Patterner left
mikehh moritz: at the moment aloha is hosted in Oz, we need it to be hosted on parrot.org or something like that 13:18
where's purl, feather.nl? 13:19
13:19 sjn left
moritz nope (but I don't know where it is) 13:19
mikehh purl, where are you? 13:20
purl i am just misguided.
szbalint ask hachi
mikehh right
13:22 NotFound left 13:23 NotFound joined
mikehh purl@irc,perl.org 13:25
13:27 Psyche^ joined, Psyche^ is now known as Patterner 13:32 mib_xa5gz6 joined
whiteknight ha, it's funny that in the karma list that moritz computed, my karma ranking comes in at number 12 and number 16 13:37
I would suggest that the karma scraping script should either be completely case-insensitive, or case-insensitive of the first character 13:39
13:43 patspam left 13:46 PacoLinux joined
moritz case insensitive is easy to do 13:50
I've also installed some few aliases (like allisonrandal => allison), but certainly not enough yet
13:54 plobsing joined
jnthn -25 MSVC? MSVC++ :-) 13:54
moritz: aye, jonathan => jnthn maybe is also a good one :-) 13:55
moritz maybe :-) 14:00
14:06 patspam joined 14:52 davidfetter joined 14:53 ash_ joined 15:00 ruoso joined
whiteknight -24 MSVC? MSVC-- :( 15:25
No, I can't really complain too much about visual studio. It is one of the better IDEs I've ever used 15:38
jnthn I use its C debugger when I get an urge to track down Rakudo or Parrot segfaults. 15:40
tadzik ww :) 15:41
ash_ i am such a terminal junky, prefer using the gdb and what have you, but thats all just personal preference /shrug 15:42
jnthn Personal preference is fine. :-)
15:42 mib_xa5gz6 left
whiteknight I very much like VisualStudio with C#, but I've always found mountains of frustrations using it with C or C++ 15:43
atrodo gdb-- # Being Obtuse is not a feature
ash_ atrodo: how does lorito work? the one on github? can it run any files yet? 15:44
davidfetter who's got tuits?
atrodo ash_> it runs. Just not a lot of stuff. And nothing close to anything parrot related 15:45
whiteknight davidfetter: depends on the project. 15:46
davidfetter whiteknight, postgresql. we're having a "commitfest" a.k.a. month of patch reviews starting wednesday
ash_ atrodo: make test didn't give me any hints on how to run things, and ./lorito just says to give it a bytecode file, but i don't know which kind of bytecode it wants 15:47
15:47 mj41 left
davidfetter whiteknight, if there's something the pg people can do, we might be able to work some kind of favor swap 15:47
particle purl, karma
purl hmmm... karma is totally a measure of blame.
atrodo ash_> perl lasm.pl < $t > ${t%%.t}.ito where $t is a .t file 15:48
And yea, it's not pretty at this point
and the .ito that comes out is the file lorito expects
davidfetter lorito? 15:49
purl rumour has it lorito is "little parrot" in spanish or xkcd.org/707/ or github.com/atrodo/lorito or trac.parrot.org/parrot/wiki/Lorito or github.com/ekiru/yalp-asm
ash_ ah, neat
that worked
want me to expand the make test to run both of your examples?
15:50 mj41 joined
dalek TT #1787 created by ash++: OS X --m=32 doesn't work in snow leopard 15:52
TT #1787: trac.parrot.org/parrot/ticket/1787
15:52 theory joined
davidfetter mornin' theory 15:53
theory sup fetter? 15:55
davidfetter trolling for CF vic^H^Holunteers
theory good luck
purl You'll need it.
szbalint is trolling for more hours / day 15:56
theory trolls for szbalint's trolls 15:57
davidfetter pwnz some of szbalint's current hours for the postgres commifest
15:57 ash_ left 15:58 fperrad left
atrodo msg ash_ sure, I've got no problem with volunteer help 15:58
purl Message for ash_ stored.
aloha OK. I'll deliver the message.
szbalint :) 16:01
16:05 GodFather left 16:16 tadzik left 16:21 fperrad joined
dalek nxed: r645 | NotFound++ | trunk/winxedst1.winxed:
anonymous functions in stage 1 - initial implementation, no lexicals
 16:25
16:30 nwellnhof joined 16:31 particle left, plobsing left 16:32 particle joined 16:36 nwellnhof left 16:39 tcurtis joined, luben_work left
dalek nxed: r646 | NotFound++ | trunk/winxed (2 files):
use keyed syntax for Getopt/Obj
 16:40
nxed: r647 | NotFound++ | trunk/pir/winxed_compiler.pir:
update installable compiler generated pir
 16:50
17:01 Paul_the_Greek joined
Paul_the_Greek G'day, fellow Parrotoids. 17:01
cotto_work Good day, greeky Paul 17:02
whiteknight Paul_the_Greek: "Parroteers"
:)
and good day
purl every day above ground is a good day or I love the smell of napalm in the morning. It's the smell of victory.
whiteknight purl no, every day is <reply>every day's a holiday, every meal's a feast
purl okay, whiteknight.
Paul_the_Greek So, do you agree that having the Parrot debugger test actually compare output messages is ... er ... silly?
whiteknight agreed 17:03
purl no, good day is <reply>every day's a holiday, every meal's a feast
purl okay, whiteknight.
whiteknight good day
purl every day's a holiday, every meal's a feast
Paul_the_Greek Good. 17:04
whiteknight verbatim tests on error messages is a very bad thing, especially if we ever want Parrot to implement i18n internationalization 17:10
Coke I think exact matching is silly. I think making sure it outputs something and comes back is probably a good idea.
NotFound Then kill test_throws_like from Test/More 17:11
17:12 plobsing joined
NotFound I mean, throws_like 17:13
whiteknight I'm surprised more people haven't volunteered yet to be release managers 17:14
cotto_work wonders why kid51 volunteered for 3.6 instead of something sooner 17:19
whiteknight cotto_work: that is the first tuesday when he doesn't have a schedule conflict with his perl group 17:20
tcurtis considers signing up for November. 17:21
whiteknight I don't even know what I'm making for dinner tomorrow night, and Jim knows exactly what he's doing on the third tuesday of July, 10 months from now 17:22
Coke NOT JIM!
<ahem>
whiteknight tcurtis: you better! you owe us for all the GSOC cash you earned
cotto_work tcurtis: done. 17:23
no takebacks!
pmichaud I'm getting failures in Rakudo with the latest Parrot 17:25
pmichaud@plum:~/rakudo$ ./perl6 t/spec/S04-statement-parsing/hash.rakudo
1..7
can't get class from an instance of class 'P6role' in 'Test::isa_ok' at line 142:Test.pm in main program body at line 9:t/spec/S04-statement-parsing/hash.rakudo
...I thought we reverted the get_class thingy? 17:26
cotto_work We did.
pmichaud pmichaud@plum:~/rakudo$ ./perl6
> say $*VM<config><revision>
48977
cotto_work A current Parrot shouldn't be able to produce that error message.
but there it is 17:27
pmichaud I wonder if the boolean branch merge brought it back in.
cotto_work That must be it.
dalek rrot: r48978 | tcurtis++ | trunk/docs/project/release_manager_guide.pod:
Volunteer myself as release manager for November.
cotto_work tcurtis++ 17:28
pmichaud tcurtis++
tcurtis Now, let's just hope I don't mess it up. :)
pmichaud you won't.
cotto_work tcurtis: the onus is on everyone who edits the release manager guide, not the release manager himself (or herself)
dukeleto 'ello
cotto_work Could someone review the sleeker_boolean merge to make sure nothing else snuck in? 17:29
Paul_the_Greek: make sure to merge from trunk to branch before merging from branch to trunk in the future. 17:30
tcurtis Looks like the only non-Boolean changes were mergeinfo prop changes. 17:31
Paul_the_Greek Yes, that's what kid51 said. He guided me. I would have had no clue. 17:32
cotto_work you seem to be correct
cotto-- for jumping the gun
Paul_the_Greek What's a "mergeinfo prop change"?
He had me do the merge from a separate checkout that had been updated. 17:33
tcurtis A change to the "svn:mergeinfo" property of a file.
Paul_the_Greek Why did my merge end up with so many? I checked other merges and not so many.
pmichaud ah, it came from the hash_inlined_branch merge 17:34
github.com/parrot/parrot/commit/fc4...ec6ea2f1db
cotto_work svn--
Paul_the_Greek So every file that had been changed since I branched ended up with this property change? 17:35
cotto_work Paul_the_Greek: yes
Paul_the_Greek Odd.
karma svn
purl svn has karma of -69
aloha svn has karma of -2.
Paul_the_Greek karma git 17:36
purl git has karma of 319
aloha git has karma of 0.
cotto_work I'd hate to lose that. We've worked hard to get svn's karma that low.
NotFound botconsensus--
Paul_the_Greek New subject: Does everyone agree that a breakpoint should be triggered before the instruction is executed?
cotto_work Does gdb do it that way? 17:37
Paul_the_Greek No, it does it after, which is much easier.
cotto_work That would probably be less surprising then.
Paul_the_Greek Surprised the hell out of me when it happened after. 17:38
pmichaud surprises me also.
Paul_the_Greek I believe that most people think breakpoints don't work at all, so perhaps it doesn't matter.
sorear gdb has always done it before for me, at least when I've been using it at the instruction level
cotto_work I mean for people who are used to gdb. If before is a more useful behaviour, we can go with that.
Paul_the_Greek Odd.
sorear can't remember the last time I set a source-level breakpoint, haha :(
Paul_the_Greek The check is made after the instruction is executed. 17:39
NotFound Paul_the_Greek: parrot_debugger breakpoints do work. What doesn't work is the way it locates its places.
Paul_the_Greek Another question: Do we all agree that having the debugger tests check output messages is silly?
NotFound At least, they wirked last time I worked on it.
cotto_work Is there a better way? 17:40
Paul_the_Greek NotFound: I've fixed bugs in loading the source, listing the source, and creating breakpoints.
cotto_work: I don't know, but actually checking the text of messages is whacky.
NotFound Paul_the_Greek: the debugger tests are silly. They are here just because our paractice is that is better having bad tests than haning none.
Paul_the_Greek I'll see if I can come up with a cleverer way to test. 17:41
cotto_work We should have some kind of test. If you can think of a better strategy, +1.
Paul_the_Greek I'll ponder it while I hack away at the debugger, rendering each and every test busted.
NotFound Paul_the_Greek: my personal view is that people that writes source code without newline at the end deserve what happen to them, but that's just me ;) 17:42
Paul_the_Greek Well, the problem is that I just don't remember to add one sometimes. The editor shouldn't do it unilaterally.
A blank line at the end was loaded incorrectly, too. It's all good now. 17:43
NotFound A text file is a bunch of lihes. Lines are a bunch of characters newline ended.
Paul_the_Greek Except why would the editor assume it was a text file?
I suppose if there is a coda, then okay.
Of course, I've never put a coda in a single file I've ever created, except for now.
So many new and exciting practices in Parrotville. 17:44
NotFound Paul_the_Greek: a source file is a texte file.
That's the practice since the '60 at least. 17:45
Paul_the_Greek Right, but the editor can't simply assume I'm editing a source=text file.
I may be editing a binary file.
NotFound My editor don't assume that, but I know what I'm doing.
cotto_work If you're doing that with a normal editor, you're asking for it. 17:46
Paul_the_Greek Huh?
My editor can edit binary files. It even has a hex dump mode that can be edited.
cotto_work nm in that case
NotFound I can make mistakes, of course, but tools that silently ignore the problem doesn't help to catch it.
Paul_the_Greek But I agree that a coda or the appropriate extension can signify that it's a text file.
cotto_work I'm accustomed to using hexedit for those 17:47
Paul_the_Greek Wait, you want the debugger to drop the last line of your file if you forget a newline, like slapping your wrist?
Ooh, bad programmer.
Shall I display a warning if there is no newline after the last line?
NotFound Paul_the_Greek: I don't necesary want that, I just don't care for it while I worked on the debugger.
Paul_the_Greek Easy enough to display a warning. 17:48
NotFound A warning will be nice, yes.
Paul_the_Greek Consider it done.
dukeleto Paul_the_Greek: so you are breaking all the parrot_debugger tests? do tell 17:49
dukeleto backlogs
NotFound BTW is what gcc does.
Paul_the_Greek Well, I'm changing the output, so that will break many of them.
cotto_work throws a log a darbelo
Paul_the_Greek For example, every breakpoint command now lists the breakpoint as it stands after the command is done. 17:50
Hitting a breakpoint will display a message about which one you hit.
Things like that.
purl things like that are unusual
dukeleto Paul_the_Greek: are you working on branch? do you have any of your debugger stuff in a publicly-viewable place? 17:53
Paul_the_Greek NotFound: Warning added.
No, I didn't start a new branch. I figure to commit a first round of changes in a few days; ones that don't affect the runcore. 17:54
It's only one file so far.
Actually, I should probably create a patch and let people play before committing. 17:56
cotto_work That's why we have branches. 17:57
NotFound The entire debugger should be marked as experimental until some day when it's somewhat feature complete. 17:58
We were using it that way before the policy for experimental were stablished. 17:59
pmichaud is anyone going to look at reverting the get_class (and possibly other) changes? or shall I file a ticket? 18:00
I'll file a ticket and blame r48944
Paul_the_Greek cotto_work: Sorry, I'm gun-shy of patches now. I'll suck it eventually. 18:01
cotto_work +1. We need to make sure nothing else was accidentally changed.
Paul_the_Greek s/patches/branches/
NotFound Put the blame on Mame, boy.
cotto_work mame?
purl rumour has it mame is www.media.dsi.unimi.it/mame/ or at drake.dit.upm.es/~mame/ or at www.davesclassics.com/ or an arcade game emulator or available on the Kodak DC265 at members.aol.com/JWSurine/ or really at www.mame.net
NotFound cotto_work: www.youtube.com/watch?v=rVI0A4DTVgg 18:03
pmichaud trac.parrot.org/parrot/ticket/1788 18:09
afk, lunch
dalek TT #1788 created by pmichaud++: r48944 breaks rakudo 18:10
TT #1788: trac.parrot.org/parrot/ticket/1788
18:13 contingencyplan joined
dukeleto TT #1788 is a great reason to move to git, even faster. 18:14
cotto_work dukeleto: has any work been done on moving mk_manifest_and_skip to git? 18:15
18:18 hercynium joined
dukeleto cotto_work: i've shed a few tears while thinking about it. Mostly I have been working on everything else 18:19
cotto_work What's the hard part?
purl well, the hard part is the reliability ;-)
18:20 purl joined
dukeleto cotto_work: not sure. i just hacked on other things first, because they were easier. It shouldn't be too hard 18:21
moritz pmichaud++
18:23 Paul_the_Greek left
dalek TT #1560 closed by moritz++: r45619 (merge of stringnull branch) causes Rakudo failure in ... 18:44
TT #1560: trac.parrot.org/parrot/ticket/1560
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (-2 to go); merge branches; review Git conversion plan 18:44
18:50 Andy left
dukeleto cotto_work: i've made progess in other git stuff in your git_aware_tools branch 19:06
cotto_work glad to hear it 19:07
davidfetter waves briefly to dukeleto et aliae 19:08
cotto_work It's a bad idea to assume the presence of a .git dir, right? 19:09
i.e. ignore it if it's there, but don't depend on it 19:10
dalek rrot: r48979 | nwellnhof++ | trunk (10 files):
Switch from charset to encoding opcodes in tests and examples
rrot: r48980 | nwellnhof++ | trunk/docs (5 files):
Update string API documentation
19:10 hercynium left
dalek tracwiki: v27 | cotto++ | GitMigration 19:17
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
dukeleto cotto_work: what exactly do you mean? .git won't exist in release tarballs 19:24
cotto_work: and we have to consider people working in bzr/hg mirrors of the parrot repo, i guess 19:25
cotto_work: i already killed svnclobber.pl
dalek rrot: r48981 | nwellnhof++ | trunk/src (7 files):
Update a handful of comments still mentioning charsets
 19:27
dukeleto cotto_work: i also have github.com/parrot/parrot/tree/leto/..._svn_tests going, which basically just removes a bunch of svn tests
cotto_work My only problem is that you didn't use the word "massacre". 19:30
;)
atrodo massacre++
whiteknight tcurtis++ 19:31
cotto_work what's he up to now?
whiteknight nov release manager
GeJ Bonjour everyone. 19:32
whiteknight hello GeJ
dalek tracwiki: v28 | dukeleto++ | GitMigration 19:34
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
dukeleto cotto_work: yeah, should have named it svn_massacre ;) 19:37
whiteknight And next time we clean out old branches, we can call that work "massacre_massacre" 19:38
cotto_work dukeleto: is there an equivalent functionality to svnclobber?
dukeleto cotto_work: git clean
dukeleto saw talk about release managers being in short supply. I am willing to be the first release manager after the git conversion, but I don't know exactly when that will be
cotto_work: git clenan -fdx <==> svnclobber.pl 19:39
cotto_work: git clean -fdx, that is
\\o/ for deleting code
cotto_work it'll FedEd any uncommitted changes to /dev/null 19:40
s/changes/anything/
whiteknight and /dev/null will FedEx it back to itself
19:44 kid51 joined
dukeleto kid51: hola 19:49
dalek lectus: 7214e75 | bschmalhofer++ | docs/eclectus.pod:
Fixed path to test scripts.
 19:51
nxed: r648 | NotFound++ | trunk/winxedst1.winxed:
use keyed syntax for Getopt Obj in stage 1 compiler
 19:55
19:59 whiteknight left
dalek nxed: r649 | NotFound++ | trunk/winxedst1.winxed:
rename ClassBase to ClassSpecifier also in stage 1 compiler
 20:15
20:27 tcurtis left
luben pmichaud, ping 20:34
pmichaud luben: pong
luben I am ready with the patch for src/oo.o
but I have a problem 20:35
There seems to be unrelated bug (here I has shown after boolean branch merge)
so I could not test that this fixes the case 20:36
pmichaud I agree, this is a problem.
the revision that the branch was based on had several problems in it that broke rakudo
the src/oo.c problem is just one of them.
so, when the branch was merged back in, it's possible that other needed fixes were lost as well 20:37
it's not so easy for me to pinpoint the exact parrot commits that might have fixed those other issues.
luben I have reviewed the diffs I am sure thet oo.c is only reverted change
everithing other is the code that I have changed 20:38
pmichaud try applying your src/oo.c patch to r48944 and see if that fixes things.
if so, then it's probably safe to say that other things since then are now causing Rakudo to fail. 20:39
luben yes... I will make it
pmichaud or, it's probably save to just commit the src/oo.c patch and then we can try Rakudo from there and perhaps pinpoint what else is left to be fixed. 20:40
s/save/safe/
sorear pmichaud: do we have any clue why load_bytecode "perl6.pbc" makes everything Parrot does 10 times slowe? 20:42
luben I am building 48945 with the patch...
pmichaud sorear: gc
sorear I thought our GC ignored compiled code 20:43
pmichaud the gc goes quadratic with large (largish) strings at that point
well, loading rakudo ends up with more than just compiled code
all of the :load routines get executed
and we end up attaching properties to various subs and the like. Parrot Subs aren't immutable, so they have to be marked along with the rest of the gc. 20:44
dalek TT #1789 created by pmichaud++: String concatenation is really slow 20:45
TT #1789: trac.parrot.org/parrot/ticket/1789
pmichaud and it's not necessarily the case that "everything Parrot does" is 10x slower; so far it's just string concatenation. :)
20:46 bluescreen joined
pmichaud and string concatenation of large strings, at that. I think that 25,000 short string concatenations doesn't exhibit the same bad behavior (because the gc is able to recycle space easier) 20:46
luben pmichaud, it passes the test... I am commiting to trunc 20:47
dukeleto pmichaud: it is becoming very apparent that our GC needs some kind of hackathon or something
20:47 ruoso left
pmichaud dukeleto: we've only been saying that for nearly three years. :-| 20:47
dukeleto pmichaud: well, perhaps we can fix that 20:48
pmichaud perhaps longer.
dukeleto: I hope you'll forgive me if I'm not entirely optimistic about that.
cotto_work We could call the branch "gc_massacre".
pmichaud hey! great idea!
NotFound String concatenation basically does dest = Parrot_str_new_noinit(interp, total_length); Is funny if the gc can solowdown a lot this. 20:49
dukeleto pmichaud: it is a hard subsystem to hand out work for. Very few people understand it enough to modify it. We need to fix that.
pmichaud (phone) 20:50
NotFound There is also a problem after the string immutable switch. const STRING * vs STRING * everywhere, 20:52
cotto_work #define STRING const parrot_string_t
dalek rrot: r48982 | luben++ | trunk/src (2 files):
fix a unintended change resulted from hash_inlined merge
 20:53
luben pmichaud, fix commited in r48982
pmichaud I did a similar program that simply concatenated 25,000 integers together. That program resulted in something like 1700 mark runs. 20:54
The problem is that those mark runs become a lot more expensive when Rakudo is loaded into the interpreter. 20:55
NotFound Parrot_str_to_hashval - Returns the hash value for the specified Parrot string, caching it
pmichaud (or, at least, that's part of the problem)
NotFound This is the main problem.
20:55 tadzik joined
pmichaud NotFound: why would that be a problem? 20:55
NotFound In order to modify the hashval, the STRING can't be const. 20:56
pmichaud I'm not sure I understand how that affects gc
NotFound It affects any attempt to clean the string mess.
Coke dukeleto: we only need to consider people working in a git checkout if they're using something that depends on them being a developer. 20:58
pmichaud General remark: I'm a bit discouraged that whenever we come up with an issue that seems to implicate problems with the GC (which we know has problems), the discussion turns into ways to avoid it rather than fix it.
cotto_work purely theoretical question: Who'd yell at me if I merged gc_massacre when I got home tonight? 20:59
Coke cotto_work: me, if the bugs from the last merge haven't been sorted yet.
pmichaud cotto_work: depends on how long it takes for rakudo to start working with parrot again. :)
I can try building rakudo from the branch and see what fails. 21:00
NotFound Is working with trunk right now?
pmichaud no.
cotto_work It's been a while since it was synced with trunk, iirc.
pmichaud I'm testing r48982 now.
21:01 Andy joined
cotto_work So pretend that we get the hash_inlined_func mismerge fixed, Rakudo building against trunk and gc_massacre synced fine, why not merge the branch? 21:02
Coke does it do anything? 21:03
cotto_work (having, in this theoretical situation, confirmed that Rakudo works with the branch)
NotFound cotto_work: it's convenient to check if the boolean merge has done some damage to rakudo, to avoid mixing problems.
cotto_work adds a new gc that needs tuning but has the potential to be faster than what we havew now.
NotFound cotto_work: "potential to be faster than what we havew now" -> surely a mumerous family ;) 21:04
21:04 perlite left
cotto_work NotFound: I agree, but some problems were already exposed and dealt with. 21:04
21:04 whiteknight joined, perlite joined
cotto_work Tuning and testing is the blocker, not coding afaict. 21:05
In the wurst case (Mmmm. Wurst.) we can make the new gc core non-default.
NotFound We can make the infinite memory the default ;) 21:06
21:06 tadzik left
cotto_work We keep complaining about gc but nobo0dy's taken the initiative to merge the branch. 21:06
s/0//
atrodo what needs done to merge?
cotto_work 1 - verify the hash_inline merge, clean up any additional junk that shouldn't have been merged 21:07
2 - make sure Rakudo builds and passes its spectest with trunk
3 - sync gc_massacre with trunk
4 - make the new gc non-default (switch this step with 3) 21:08
5 - merge
luben cotto_work, hash_inlined_func merge problems were just fixed, r48982.
cotto_work luben: did you verify that no other stuff got mismerged? 21:09
pmichaud luben: we only know that.... what cotto++ just said
luben NotFound, after boolean merge rakudo stopped working for me
Coke merging the branch doesn't mean that it /does/ anything good, though. doing gymnastics with SVN (or git) doesn't make the code any better/tested/understood.
cotto_work No, but it's a lower barrier to entry
Coke is that a pool you really want to swim in? 21:10
dalek rrot: r48983 | mikehh++ | trunk/src/oo.c:
fix codetest failure - trailing whitespace
pmichaud cotto_work: I think luben tested rakudo against a version of parrot after hash_inlined_func merge (but not current head) and got it to work
cotto_work Probably not me, but I was someone in it.
Coke ->
luben cotto_work, I have reviewed the diffs. This (and defining unused variable) were the only artifacts of the merge, they were fixed 21:11
pmichaud I just got one failure in r48982 (but I'm seeing a lot less than I did in the previous one)
(test is still running, more failures may show up)
the 48982 feels like it could be a boolean failure
cotto_work (I'm not adverse to it; I just suspect others are better-suited. I'm not ruling out taking a stab at it.)
luben++
luben let me check again 21:13
bacek aloha, humans 21:15
whiteknight hello bacek
bacek whiteknight, hello
cotto_work hail, bacek 21:16
bacek aloha, cotto_work 21:17
pmichaud boolean merge breaks at least one rakudo test. 21:22
dalek nxed: r650 | NotFound++ | trunk/winxedst1.winxed:
refactor keyed new using ClassSpecifier in stage 1 compiler
 21:26
rrot: r48984 | bacek++ | branches/gc_massacre (203 files):
Merge branch 'master' into gc_massacre

  \tsrc/gc/system.c
  \tsrc/string/encoding/fixed_8.c		 21:27
purl src/gc/system.c is a known mess and I'm working on it as we speak
21:28 kid51 left, purl joined
pmichaud r48982 leaves at least two spectest failures for Rakudo. 21:29
One is definitely from the Boolean switch, as :multi(Integer, Integer) no longer accepts boolean arguments
I'm still trying to figure out the other one. 21:30
sorear what does "two spectest failures" mean? I thought we had thousands 21:31
cotto_work bacek++ 21:32
pmichaud it means that at least two tests that were passing in r48933 are no longer passing in r48982
(I don't understand "I thought we had thousands.")
luben what is the other test that doesn't pass 21:37
21:37 smash left
pmichaud t/spec/S32-str/encode.t fails test #10 21:38
t/spec/S03-operators/short-circuit.rakudo fails test #20
the short-circuit.t test is definitely because Boolean is no longer "isa Integer"
I haven't figured out what is causing the encode.t test to fail yet. 21:39
cotto_work Does Perl 6 require that?
pmichaud Perl 6 doesn't, but some of our internals apparently were making use of it
i.e., Parrot multisubs that were marked as :multi(Integer, Integer) would accept Boolean arguments. That no longer happens, causing the dispatch to go to a different multisub than what it did previously. 21:40
NotFound pmichaud: That test uses ByteBuffer? 21:41
pmichaud NotFound: the encode.t test does, yes.
NotFound pmichaud: ByteBuffer interface change with the encoding massacre 21:42
pmichaud (boolean) We can obviously fix Rakudo to not rely on Boolean being a subclass of Integer; but that change is definitely outside of the deprecation policy :)
was ByteBuffer available in 2_6_0 ?
NotFound pmichaud: I think so 21:43
pmichaud hmmm
NotFound If you are thinking about the deprecation police, note that is marked as experimental.
pmichaud it is? 21:44
purl Oh no it isn't!
21:44 purl joined
pmichaud I don't see an experimental tag... am I looking in the wrong place? 21:45
NotFound Mmmm, I think is no more, but don't remember if it was after 2.6
pmichaud I'm looking at the 2.6 release notes.
NotFound It was added in 2.5 21:46
pmichaud from DEPRECATED.pod, in 2.6.0:
"For an item to be considered experimental, it can B<never> have shipped in
a supported release without the C<[experimental]> tag; otherwise, it must be
deprecated normally before removal or incompatible change.
"
NotFound The offending method can be fixed to accept two arguments, but I'm not sure if it makes sense. 21:48
pmichaud according to the deprecation policy, it does make sense (at least until the next supported release). 21:49
21:50 fperrad left
pmichaud (and assuming that this is the method that is causing the Rakudo failure) 21:50
NotFound - METHOD get_string(STRING *charsetname, STRING *encodingname) { 21:51
+ METHOD get_string(STRING *encodingname) {
pmichaud I really don't mind if the fix isn't made -- we can obviously patch Rakudo to use the new API. But if we're going to be regularly violating the deprecation policy, what's the point of having one? let's get rid of it.
NotFound This is the candidate
pmichaud Let's not advertise something that people aren't going to adhere to. 21:52
NotFound Don't blame me, I don't doit ;)
pmichaud It's not the changes I mind so much (although as a HLL developer, I do) as the hypocrisy surrounding the notion of "supported releases"
dukeleto pmichaud: i think it is not so much hypocrisy as unintended consequences, but I understand your frustration 21:55
pmichaud Over the past ~12 days, there have been more revisions of Parrot that cause Rakudo to fail than to succeed. Furthermore, if people on the Rakudo team weren't regularly testing Rakudo against Parrot head (which we're not supposed to have to do, and some have even told us we *shouldn't* be doing), then the breakages wouldn't be found until the day of the Parrot release. 21:56
and potentially not even then.
21:56 cotto_work left
pmichaud anyway, I'll write tickets for the new deprecation issues and people can work it out on the list. 21:59
NotFound A problem I see is that we have tests for internal details and minutiae indistingushable from tests that verify important documented behaviors. Thus people just "fix" the test that fail. 22:00
We had a check that verifierd that Boolean isa Integer
pmichaud ouch. 22:01
that definitely implies "deprecation notice needed"
one cannot simply remove a tested behavior because it's inconvenient.
NotFound Mmmm... no, I was fooling myself. 22:03
There is just a check that does scalar 22:04
interface_check, at the bottom of t/pmc/boolean.t 22:05
And that part don't changed in the boolean merge 22:06
22:09 cotto_work joined
dalek TT #1788 closed by luben++: r48944 breaks rakudo 22:11
TT #1788: trac.parrot.org/parrot/ticket/1788
TT #1790 created by pmichaud++: r48965 changes :multi dispatch from 2.6.0 behavior
TT #1790: trac.parrot.org/parrot/ticket/1790
NotFound pmichaud: the find_codepoint op is still marked experimental. Is rakudo depending on it? 22:14
pmichaud nqp-rx depends on it (so rakudo does also)
rakudo doesn't use it directly, but only indirectly via nqp 22:15
NotFound I think we must promove it to official status, then.
pmichaud well, I don't mind if features explicitly marked 'experimental' change.
it's when the non-experimental features change that we run into trouble. 22:16
(yes, I'd be glad to see find_codepoint made more official, though.) 22:17
NotFound CodeString is deprecated and that op provides replacement for its functionality, so I think it should be made official before killing CodeString
pmichaud wfm :) 22:18
NotFound I see we still have the duplicated silliness in DEPRECATED.pod 22:29
22:40 kid51 joined
kid51 ~~ 22:40
bacek_at_work ~~ 22:42
22:43 bluescreen left 22:46 jimk joined 22:47 jimk left 22:48 kid51 left 22:55 kid51 joined 23:10 Paul_the_Greek joined
Paul_the_Greek Howdy ho. 23:10
nopaste "Paul_the_Greek" at 192.168.1.3 pasted "Is this correct?" (8 lines) at nopaste.snit.ch/23316 23:12
davidfetter mr. hanky? is that you?!?
Paul_the_Greek Can someone take a look at that paste?
I have no hankies.
cotto_work what about it?
Paul_the_Greek Are the PCs correct in the disassembly? 23:13
cotto_work It looks sane,
Paul_the_Greek I know the line numbers aren't.
cotto_work period
Paul_the_Greek So the .sub does not generate any code?
bacek_at_work .sub generate code
cotto_work Nope. .sub is an abstraction. You'll find it if you look at the constants table
bacek_at_work You have to look in Fixup segment to find out boundaries 23:14
cotto_work well, ones that don't take any args or return anything don't
Paul_the_Greek Okay, then the debugger is incorrect. It assigns PC 0 to the .sub and PC 2 to the say. 23:15
bacek_at_work github.com/parrot/pir/blob/master/s...ompiler.pm (starting from line 60)
nope 23:16
PC 0 is for "say_sc" 23:17
2 is for implicit "end" inserted by IMCC
Paul_the_Greek Oh, then maybe I'm getting confused because the debugger's line numbers are off by 1.
Hang on ... 23:18
bacek_at_work line numbering is well known problem...
nopaste "Paul_the_Greek" at 192.168.1.3 pasted "Debugger output" (18 lines) at nopaste.snit.ch/23317
NotFound Paul_the_Greek: one of the problems of working with the debugger is that the pir info and annotations are not very reliable. 23:19
Paul_the_Greek Notice the confusion in that second paste.
The algorithm for scanning the compiled code to match up lines and PCs must be too simplistic.
Can I paste it for someone to look at? 23:20
cotto_work Anything that uses line numbers relies on information generated by imcc. 23:21
NotFound Paul_the_Greek: scanning the compiled code? =:o
Paul_the_Greek Yes, it scans beginning at interp->code->base.data, trying to match instruction offsets to source lines. 23:22
I'll paste the code.
NotFound Paul_the_Greek: don't do that.
Paul_the_Greek Don't scan, or don't paste? :D 23:23
NotFound Don't write code like that-
Paul_the_Greek I did rather think it was a bit funky.
NotFound We have a pir debug segment and an annotations segment.
Paul_the_Greek With those I can match source lines to PCs reliably? 23:24
cotto_work "reliably" is such a strong word
NotFound They are not very reliable, but writing and maintaining yet another way to do the work is not a good solution.
Paul_the_Greek Yes, especially when you're not really parsing the lines, but just glancing at them.
cotto_work "as well as imcc" would be more accurate
Paul_the_Greek That code is in the debugger already, but I'm happy to replace it with something better. 23:25
What would I look at to get a reasonable understanding?
NotFound Paul_the_Greek: code that parses the source to match bytecode? 23:26
Paul_the_Greek Yes. It's five lines of code plus a poor man's parser. 23:27
Basically, it decides if there is an opcode/directive, then looks up the next byte in the op_info_table.
NotFound Ah, yes, I remember there was something... I don't know if is still in use. 23:28
Paul_the_Greek Oh, it's definitely in use.
Since the op_info_table contains entries for the directives, too, it sort of works.
It thinks .sub takes 2 bytes.
NotFound What?
Paul_the_Greek Let me check ... 23:29
NotFound Anyway, that remainders of past times should be killed.
Paul_the_Greek No, never mind, it's just being stupid and assuming byte 0 is the opcode for .sub 23:30
So the bytecode PDD is the best way to learn about segments? 23:32
NotFound Are you sure that code is used? I think it uses pir debug info when available, and bytecode positions if not.
jnthn There is no .sub opcode
Paul_the_Greek I'm pretty sure, since I rewrote the load_source function.
NotFound Paul_the_Greek: then I think you have to rewrite again ;) 23:33
Paul_the_Greek jnthn: Right, but the debugger is getting confused when matching source lines to PCs.
NotFound: Indeed.
So does the debug segment have PC <=> source line correspondence?
NotFound Paul_the_Greek: I'm not sure if the PDD is fully uptodate, but is a good guide. 23:34
Paul_the_Greek: yes, but not in a immediately obvious way. 23:35
Paul_the_Greek Okay, I'll study it. 23:36
There is a disassemble command in the debugger, but it doesn't list anything.
NotFound Paul_the_Greek: it doesn't list, just generate the listing. l to list 23:37
Paul_the_Greek The scary thing is that it appears to replicate pbc_disassemble.
jnthn -> sleep
23:37 autark left
Paul_the_Greek What does disassemble do? 23:37
NotFound Paul_the_Greek: yes, I started to clean it up, but later got more interested for other things. Before, it was in a even worse state X-) 23:38
Paul_the_Greek Does that smiley mean you're cross-eyed?
NotFound Paul_the_Greek: disassemble, and put the lines generated in the debugger structs to be shown with l 23:39
Paul_the_Greek: It means that I become cross-eyed with that things :D
Paul_the_Greek Oh, it replaces the source with the disassembly. Wild!
But the disassembly has no PCs. 23:40
It has line numbers, but I don't know what they mean.
NotFound Yeah, the list command is not very smart.
Paul_the_Greek Now, here's a question: When I ask tomorrow whether lots of work on the debugger is a good thing, what will people say? 23:41
23:41 ruoso joined
NotFound Paul_the_Greek: in my experience, people always say yes. Then they don't care about. 23:41
Paul_the_Greek Oh, those are the line numbers list generates. It's just that the source has been replaced. Even wilder!
So I have to add "seriously" after my question tomorrow. 23:42
NotFound Paul_the_Greek: the idea we had at a time was to replace most of the current debugger code with calls to the secondary interpreter, where a loadable debugger will handle it and the interaction with the user. 23:45
Paul_the_Greek Oh my, that's out of my league at this point. 23:46
NotFound And I think the SoC project about instrumenting was also on that route.
whiteknight it probably could be used for a debugger 23:47
NotFound Someone is going to merge it? 23:48
Paul_the_Greek: it was also out of mine at that time, thus I stop working on the debugger when some basic functinality started to work again. 23:49
Paul_the_Greek Well, maybe I'll stop with the changes I've made. I'll ask at the meeting tomorrow. 23:50
NotFound And that funcionality has been enough to catch some ugly problems, fortunately.
Paul_the_Greek New subject: Could someone look at this ticket: trac.parrot.org/parrot/ticket/1790
What's the right thing to do? We agreed this didn't need a deprecation notice, but perhaps that was the wrong decision. 23:51
cotto_work is evolving. 23:52
It turned into cotto
NotFound Multidispatch is a part of parrot completely out of my skills, sorry.
23:52 cotto_work left
Paul_the_Greek It's invoking the default function because Boolean no longer inherits from Integer. 23:53
NotFound Most probably yes.
23:58 autark joined
pmichaud gist.github.com/578279 # I'm very confused by this. The definition of Buf.decode2() is *exactly* the same as the definition of Buf.decode(). 23:58
(except for the name, obviously)

Powered by Cro and the Raku® Programming Language.

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

Thank you!