Camelia, the Perl 6 bug

IRC log for #parrot, 2010-09-13

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:07 plobsing luben: which system's malloc? which version?
00:08 luben I have tried to replace hash struct allocation
00:09 luben current versuion uses Parrot_gc_allocate_memory_chunk... that is a wrapper arround system malloc (linux-2.6.35, glibc02.11)
00:11 luben I have replaced it with Parrot_gc_allocate_fixed_size_storage
00:11 luben with the hope to get more speed
00:12 luben but in fact it's slower
00:15 plobsing on what benchmark?
00:16 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.
00:16 nwellnhof ah, you mean the hash struct itself
00:17 luben nwellnhof, I used it just for the header (the struct)
00:17 dalek parrot: r48969 | chromatic++ | trunk (2 files):
00:17 dalek parrot: [pf] Coalesced empty STRINGs during thawing.
00:17 dalek parrot: Make reconfigure required.
00:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48969/
00:22 luben I'll work further on this idea...
00:27 whiteknight I wonder what we need to do to get a smolder server up and running again
00:28 whiteknight because not having that is a huge drag
00:34 dalek parrot: r48970 | whiteknight++ | trunk/docs/project/release_manager_guide.pod:
00:34 dalek parrot: Pencil in myself for the Dec release, and kid51 for the Jul release.
00:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48970/
00:40 nwellnhof left #parrot
00:42 kid51 joined #parrot
00:53 dalek TT #1786 closed by jkeenan++: Trac: 'Milestone' drop-down needs to display 2.10 and 2.11
00:53 dalek TT #1786: http://trac.parrot.org/parrot/ticket/1786
00:59 dalek winxed: r644 | NotFound++ | trunk/examples/fly.winxed:
00:59 dalek 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
00:59 dalek winxed: exiting
00:59 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=644
01:07 whiteknight purl ignore dalek
01:07 purl whiteknight: huh?
01:07 whiteknight you heard me
01:07 whiteknight left #parrot
01:08 Paul_the_Greek Parrot debugger now loads the ENTIRE source file.
01:09 kid51 Paul_the_Greek is that a feature or a bug?
01:11 Paul_the_Greek The current debugger drops the last line of the file.
01:12 Paul_the_Greek Maybe only if it doesn't have a newline at the end.
01:12 Paul_the_Greek Now I'm ready to get breakpoints to work.
01:12 mikehh kid51: ping
01:13 kid51 make fulltest PASS r 48970 linux/i386
01:13 kid51 mikehh: pong
01:14 mikehh I am getting a failure in t/postconfigure/05-trace.t - Failed tests:  7, 9
01:16 Paul_the_Greek left #parrot
01:16 mikehh I have just installed Ubuntu 10.10 beta amd64, so maybe I am missing something
01:17 kid51 make realclean
01:20 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
01:24 dalek parrot: r48971 | jkeenan++ | trunk/config/auto/pcre.pm:
01:24 dalek parrot: Apply 1 of several patches submitted by ronaldws++ in �http://trac.parrot.org/parrot/ticket/1401.  Express 'result' more clearly -- 'no' -- when PCRE not found.
01:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48971/
01:31 mikehh kid51: seems to ok now - no idea what went wrong
01:34 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 kid51 But don't sweat it.  You and I are the only ones who care about that :-)
01:35 kid51 Since no one's doing any heavy overhauling of the config system right now, no one needs --configure_trace very much.
01:35 kid51 But its day may come again!
01:39 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:40 kid51 mikegrb:  Do you remember which Trac ticket that was?
01:40 mikegrb I can look
01:40 kid51 1707, correct?
01:41 mikegrb yes
01:41 TiMBuS left #parrot
01:41 kid51 got it
01:41 TiMBuS joined #parrot
01:41 mikegrb oh, coke already configmed it works
01:44 dalek TT #1707 closed by jkeenan++: attempt to mmap 2325622477335777280 bytes when printing utf8 in perl6
01:44 dalek TT #1707: http://trac.parrot.org/parrot/ticket/1707
02:09 kid51 left #parrot
02:35 janus left #parrot
02:36 janus joined #parrot
02:46 bacek left #parrot
02:46 aloha left #parrot
02:53 petdance joined #parrot
03:05 patspam joined #parrot
03:29 bluescreen left #parrot
03:50 patspam left #parrot
04:05 cotto anyone know how many tickets have been closed since last #ps?
04:06 sorear trac.parrot.org/timeline would
04:06 cotto That's what I was looking for.  sorear++
04:09 Topic for #parrot is now  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:10 cotto and there's a good variety of people closing them too
04:25 sorear -1. heheh.
04:29 tcurtis sorear: http://irclog.perlgeek.de/p​arrot/2010-08-31#i_2768121
05:29 ash_ left #parrot
05:50 petdance left #parrot
05:59 plobsing left #parrot
05:59 s1n left #parrot
06:04 fperrad joined #parrot
06:05 dukeleto 'ello
06:09 uniejo joined #parrot
06:11 dukeleto uniejo: hello
06:13 baest joined #parrot
06:34 luben_work joined #parrot
06:35 davidfetter left #parrot
06:48 s1n joined #parrot
07:09 jsut_ joined #parrot
07:10 tadzik joined #parrot
07:14 jsut left #parrot
07:27 bacek joined #parrot
07:32 aloha joined #parrot
07:33 dalek tracwiki: v26 | dukeleto++ | GitMigration
07:33 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=26&amp;action=diff
07:41 * dukeleto ponders keeping the term revision in parrots guts. it would require a lot less code churn
07:42 dukeleto parrot_config revision, Parrot::Revision, etc...
07:43 tadzik left #parrot
07:51 dalek parrot: r48972 | mikehh++ | trunk/config/auto/pcre.pm:
07:51 dalek parrot: fix codetest failure - perlcritic - hard tabs used
07:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48972/
08:08 tcurtis left #parrot
08:25 dalek roast: 2f690f9 | leto++ | S32-num/rat.t:
08:25 dalek roast: [S32-num] Add fudged test for NaN.Rat
08:25 dalek roast: review: http://github.com/perl6/roast/commit/2f​690f94accf8f591a35bbadd339fe4d82ad012d
08:42 dalek roast: 326ee0a | leto++ | S32-num/rat.t:
08:42 dalek roast: [S32-num] Add some tests for Rat representation of Inf
08:42 dalek roast: review: http://github.com/perl6/roast/commit/32​6ee0a072ef21ccbd5f696667c87e2d125f29bf
09:38 bacek aloha, humans
09:38 bacek seen chromatic
09:38 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]
09:38 aloha chromatic was last seen in #parrot 4 days 10 hours ago joining the channel.
09:39 bacek seen whiteknight
09:39 purl whiteknight was last seen on #parrot 8 hours, 31 minutes and 58 seconds ago, saying: you heard me
09:39 aloha whiteknight was last seen in #parrot 8 hours 31 mins ago saying "you heard me".
09:39 bacek oookey
09:40 tadzik joined #parrot
09:48 jsut joined #parrot
09:52 luben_work good morning bacek
09:52 luben_work do you have a minute to give me an advice?
09:53 jsut_ left #parrot
09:53 bacek luben_work, sure
09:53 luben_work I am working now on parrot_hash
09:54 luben_work you were right - fixed size allocator is really fast
09:54 luben_work it was my fault
09:54 luben_work when I thought it's slow
09:54 ruoso left #parrot
09:55 luben_work I have converted all memory allocations in hash handling code to use fixed_size pools
09:55 bacek :)
09:55 luben_work 3.5-4% performance gain :)
09:55 bacek hooray
09:55 bacek ship it :)
09:56 luben_work but I am not sure if it is the appropriate type for all of the memory allocations
09:56 bacek Hmm...
09:57 bacek fixed_size allocator is for small objects only
09:57 luben_work for the header it's fixed_size - it's OK
09:57 bacek Look at src/pmc/callcontext.pmc for example for switching from fixed_size to sys_mem
09:58 bacek But hashes includes buckets allocations
09:58 luben_work but what type to use for buckets and index areas
09:58 bacek exactly
09:58 bacek you can use fixed_size allocator for "small hashes"
09:58 bacek But it's better to switch to sysmem for "big one"
09:59 luben_work I have separated hash struct from index/buckets
09:59 bacek ah
09:59 bacek it was single chunk of memory before, afair
10:01 luben_work yes. it is still this way, in trunc
10:05 luben_work another idea I could try is to make separate allocation for each bucket...
10:06 luben_work Is there any way to make GC run on this without custom mark function like now?
10:16 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 mikehh all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48972 - Ubuntu 10.10 beta {gcc-4.5)
10:16 mikehh also get - FATAL ERROR: Duplicated VTABLE function: get_integer at /home/mhc/t.parrot/tools/build​/../../lib/Parrot/Pmc2c/PMC.pm line 74
10:16 mikehh does not seem to effect the test results
10:18 bacek luben_work, can you rephrase your question? I didn't quite get it
10:24 mikehh build error with g++: src/string/api.c:999:16: error: invalid conversion from ‘const STRING*’ to ‘STRING*’  and also
10:24 mikehh src/hash.c:1468:71: error: invalid conversion from ‘const STRING*’ to ‘STRING*’
10:24 mikehh src/hash.c:1468:71: error:   initializing argument 2 of ‘size_t key_hash_STRING(parrot_interp_t*, STRING*, size_t)’
10:57 dalek parrot: r48973 | mikehh++ | trunk/src (2 files):
10:57 dalek parrot: add casts to get g++ to build
10:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48973/
11:27 mikehh left #parrot
11:28 luben_work bacek, I was away for an hour.
11:29 luben_work My idea - not sure that it will bring performance gains
11:29 luben_work is to allocate each hash bucket with fixed size allocator
11:30 luben_work in this way, I could nuke the memory allocation from parrot_hash (it doubles the work of the GC)
11:32 luben_work another advantage is that hash expanging will become only realloc and rehash of the index, without recalculating pointers - they remain the same
11:32 luben_work this scheme has disadvantages - you could not iterate over a hash in a linear manner like now, indexed iteration is slower
11:34 luben_work so if this will bring some performance gains depends on the following:
11:36 luben_work could we make the GC walk the hash-buckets pool in a linear fasion (it will be much faster)
11:44 mikehh joined #parrot
11:56 kid51 joined #parrot
12:02 GodFather joined #parrot
12:04 plobsing joined #parrot
12:04 dalek parrot: r48974 | mikehh++ | trunk/src/packfile:
12:04 dalek parrot: add svn:ignore (*.str)
12:04 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48974/
12:04 dalek parrot: r48975 | Paul C. Anagnostopoulos++ | trunk/src/pmc/boolean.pmc:
12:04 dalek parrot: Add empty headerizer lines
12:04 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48975/
12:04 dalek parrot: r48976 | mikehh++ | trunk/MANIFEST.SKIP:
12:04 dalek parrot: re-generate MANIFEST.SKIP
12:04 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48976/
12:23 kid51 left #parrot
12:26 whiteknight joined #parrot
12:32 contingencyplan left #parrot
12:32 whiteknight good morning, #parrot
12:33 smash joined #parrot
12:33 smash hello everyone
12:34 plobsing left #parrot
12:34 whiteknight good morning smash
12:38 dalek parrot: r48977 | mikehh++ | trunk/src/hash.c:
12:38 dalek parrot: remove a compiler warning related to const
12:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48977/
12:54 patspam joined #parrot
13:01 Coke nwellhoff?
13:01 Coke 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?
13:02 moritz +1 to cutover
13:04 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.
13:04 aloha OK. I'll deliver the message.
13:05 Coke msg kid51 (I mean, reminders here are fine, but the belt & suspenders approach annoys me.)
13:05 purl Message for kid51 stored.
13:05 aloha OK. I'll deliver the message.
13:13 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 mikehh all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48977 - Ubuntu 10.10 beta {g++-4.5 with --optimize)
13:14 mikehh purl might be annoying at times, but she still keeps track of messages and karma (mostly)
13:14 purl mikehh: excuse me?
13:14 mikehh YA see
13:15 moritz I have a script that extracts karma from the IRC logs
13:15 moritz http://moritz.faui2k3.org/tmp/parrot_karma are the results of my last run (a few weeks ago)
13:15 moritz I can re-run the script and provided for bacek++ to include it in aloha
13:15 mikehh moritz: we need to put it place so you can query it
13:16 uniejo left #parrot
13:16 moritz mikehh: my idea was to seed aloha's karma database with it, and let aloha track it from there on
13:16 moritz aloha: karma mikehh
13:16 purl mikehh has karma of 1017
13:16 aloha moritz: mikehh has karma of 10.
13:16 moritz you see, it does track, it just doesn't have the old records
13:18 Patterner left #parrot
13:18 mikehh moritz: at the moment aloha is hosted in Oz, we need it to be hosted on parrot.org or something like that
13:19 mikehh where's purl, feather.nl?
13:19 sjn left #parrot
13:19 moritz nope (but I don't know where it is)
13:20 mikehh purl, where are you?
13:20 purl i am just misguided.
13:20 szbalint ask hachi
13:20 mikehh right
13:22 NotFound left #parrot
13:23 NotFound joined #parrot
13:25 mikehh purl@irc,perl.org
13:27 Psyche^ joined #parrot
13:27 Psyche^ is now known as Patterner
13:32 mib_xa5gz6 joined #parrot
13:37 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:39 whiteknight I would suggest that the karma scraping script should either be completely case-insensitive, or case-insensitive of the first character
13:43 patspam left #parrot
13:46 PacoLinux joined #parrot
13:50 moritz case insensitive is easy to do
13:50 moritz I've also installed some few aliases (like allisonrandal => allison), but certainly not enough yet
13:54 plobsing joined #parrot
13:54 jnthn -25 MSVC? MSVC++ :-)
13:55 jnthn moritz: aye, jonathan => jnthn maybe is also a good one :-)
14:00 moritz maybe :-)
14:06 patspam joined #parrot
14:52 davidfetter joined #parrot
14:53 ash_ joined #parrot
15:00 ruoso joined #parrot
15:25 whiteknight -24 MSVC? MSVC-- :(
15:38 whiteknight No, I can't really complain too much about visual studio. It is one of the better IDEs I've ever used
15:40 jnthn I use its C debugger when I get an urge to track down Rakudo or Parrot segfaults.
15:41 tadzik ww :)
15:42 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 #parrot
15:43 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
15:44 ash_ atrodo: how does lorito work? the one on github? can it run any files yet?
15:44 davidfetter who's got tuits?
15:45 atrodo ash_> it runs.  Just not a lot of stuff.  And nothing close to anything parrot related
15:46 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
15:47 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 mj41 left #parrot
15:47 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
15:47 purl hmmm... karma is totally a measure of blame.
15:48 atrodo ash_> perl lasm.pl < $t > ${t%%.t}.ito where $t is a .t file
15:48 atrodo And yea, it's not pretty at this point
15:48 atrodo and the .ito that comes out is the file lorito expects
15:49 davidfetter lorito?
15:49 purl rumour has it lorito is "little parrot" in spanish or http://xkcd.org/707/ or http://github.com/atrodo/lorito or http://trac.parrot.org/parrot/wiki/Lorito or http://github.com/ekiru/yalp-asm
15:49 ash_ ah, neat
15:49 ash_ that worked
15:49 ash_ want me to expand the make test to run both of your examples?
15:50 mj41 joined #parrot
15:52 dalek TT #1787 created by ash++: OS X --m=32 doesn't work in snow leopard
15:52 dalek TT #1787: http://trac.parrot.org/parrot/ticket/1787
15:52 theory joined #parrot
15:53 davidfetter mornin' theory
15:55 theory sup fetter?
15:55 * davidfetter trolling for CF vic^H^Holunteers
15:55 theory good luck
15:55 purl You'll need it.
15:56 * szbalint is trolling for more hours / day
15:57 * theory trolls for szbalint's trolls
15:57 * davidfetter pwnz some of szbalint's current hours for the postgres commifest
15:57 ash_ left #parrot
15:58 fperrad left #parrot
15:58 atrodo msg ash_ sure, I've got no problem with volunteer help
15:58 purl Message for ash_ stored.
15:58 aloha OK. I'll deliver the message.
16:01 szbalint :)
16:05 GodFather left #parrot
16:16 tadzik left #parrot
16:21 fperrad joined #parrot
16:25 dalek winxed: r645 | NotFound++ | trunk/winxedst1.winxed:
16:25 dalek winxed: anonymous functions in stage 1 - initial implementation, no lexicals
16:25 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=645
16:30 nwellnhof joined #parrot
16:31 particle left #parrot
16:31 plobsing left #parrot
16:32 particle joined #parrot
16:36 nwellnhof left #parrot
16:39 tcurtis joined #parrot
16:39 luben_work left #parrot
16:40 dalek winxed: r646 | NotFound++ | trunk/winxed (2 files):
16:40 dalek winxed: use keyed syntax for Getopt/Obj
16:40 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=646
16:50 dalek winxed: r647 | NotFound++ | trunk/pir/winxed_compiler.pir:
16:50 dalek winxed: update installable compiler generated pir
16:50 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=647
17:01 Paul_the_Greek joined #parrot
17:01 Paul_the_Greek G'day, fellow Parrotoids.
17:02 cotto_work Good day, greeky Paul
17:02 whiteknight Paul_the_Greek: "Parroteers"
17:02 whiteknight :)
17:02 whiteknight and good day
17:02 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.
17:02 whiteknight purl no, every day is <reply>every day's a holiday, every meal's a feast
17:02 purl okay, whiteknight.
17:02 Paul_the_Greek So, do you agree that having the Parrot debugger test actually compare output messages is ... er ... silly?
17:03 whiteknight agreed
17:03 whiteknight purl no, good day is <reply>every day's a holiday, every meal's a feast
17:03 purl okay, whiteknight.
17:03 whiteknight good day
17:03 purl every day's a holiday, every meal's a feast
17:04 Paul_the_Greek Good.
17:10 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.
17:11 NotFound Then kill test_throws_like from Test/More
17:12 plobsing joined #parrot
17:13 NotFound I mean, throws_like
17:14 whiteknight I'm surprised more people haven't volunteered yet to be release managers
17:19 * cotto_work wonders why kid51 volunteered for 3.6 instead of something sooner
17:20 whiteknight cotto_work: that is the first tuesday when he doesn't have a schedule conflict with his perl group
17:21 * tcurtis considers signing up for November.
17:22 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!
17:22 Coke <ahem>
17:22 whiteknight tcurtis: you better! you owe us for all the GSOC cash you earned
17:23 cotto_work tcurtis: done.
17:23 cotto_work no takebacks!
17:25 pmichaud I'm getting failures in Rakudo with the latest Parrot
17:25 pmichaud pmichaud@plum:~/rakudo$ ./perl6 t/spec/S04-statement-parsing/hash.rakudo
17:25 pmichaud 1..7
17:25 pmichaud 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
17:26 pmichaud ...I thought we reverted the get_class thingy?
17:26 cotto_work We did.
17:26 pmichaud pmichaud@plum:~/rakudo$ ./perl6
17:26 pmichaud > say $*VM<config><revision>
17:26 pmichaud 48977
17:26 cotto_work A current Parrot shouldn't be able to produce that error message.
17:27 cotto_work but there it is
17:27 pmichaud I wonder if the boolean branch merge brought it back in.
17:27 cotto_work That must be it.
17:27 dalek parrot: r48978 | tcurtis++ | trunk/docs/project/release_manager_guide.pod:
17:27 dalek parrot: Volunteer myself as release manager for November.
17:27 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48978/
17:28 cotto_work tcurtis++
17:28 pmichaud tcurtis++
17:28 tcurtis Now, let's just hope I don't mess it up. :)
17:28 pmichaud you won't.
17:28 cotto_work tcurtis: the onus is on everyone who edits the release manager guide, not the release manager himself (or herself)
17:28 dukeleto 'ello
17:29 cotto_work Could someone review the sleeker_boolean merge to make sure nothing else snuck in?
17:30 cotto_work Paul_the_Greek: make sure to merge from trunk to branch before merging from branch to trunk in the future.
17:31 tcurtis Looks like the only non-Boolean changes were mergeinfo prop changes.
17:32 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
17:32 cotto_work cotto-- for jumping the gun
17:32 Paul_the_Greek What's a "mergeinfo prop change"?
17:33 Paul_the_Greek 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.
17:33 Paul_the_Greek Why did my merge end up with so many? I checked other merges and not so many.
17:34 pmichaud ah, it came from the hash_inlined_branch merge
17:34 pmichaud http://github.com/parrot/parrot/commit/f​c4e59145e3f2490d39c6d08771e4aec6ea2f1db
17:34 cotto_work svn--
17:34 cotto_work svn--
17:34 cotto_work svn--
17:35 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
17:35 Paul_the_Greek Odd.
17:35 Paul_the_Greek karma svn
17:35 purl svn has karma of -69
17:35 aloha svn has karma of -2.
17:36 Paul_the_Greek karma git
17:36 purl git has karma of 319
17:36 aloha git has karma of 0.
17:36 cotto_work I'd hate to lose that.  We've worked hard to get svn's karma that low.
17:36 NotFound botconsensus--
17:36 Paul_the_Greek New subject: Does everyone agree that a breakpoint should be triggered before the instruction is executed?
17:37 cotto_work Does gdb do it that way?
17:37 Paul_the_Greek No, it does it after, which is much easier.
17:37 cotto_work That would probably be less surprising then.
17:38 Paul_the_Greek Surprised the hell out of me when it happened after.
17:38 pmichaud surprises me also.
17:38 Paul_the_Greek I believe that most people think breakpoints don't work at all, so perhaps it doesn't matter.
17:38 sorear gdb has always done it before for me, at least when I've been using it at the instruction level
17:38 cotto_work I mean for people who are used to gdb.  If before is a more useful behaviour, we can go with that.
17:38 Paul_the_Greek Odd.
17:38 sorear can't remember the last time I set a source-level breakpoint, haha :(
17:39 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.
17:39 Paul_the_Greek Another question: Do we all agree that having the debugger tests check output messages is silly?
17:39 NotFound At least, they wirked last time I worked on it.
17:40 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.
17:40 Paul_the_Greek cotto_work: I don't know, but actually checking the text of messages is whacky.
17:40 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.
17:41 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.
17:41 Paul_the_Greek I'll ponder it while I hack away at the debugger, rendering each and every test busted.
17:42 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.
17:43 Paul_the_Greek 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.
17:43 Paul_the_Greek Except why would the editor assume it was a text file?
17:43 Paul_the_Greek I suppose if there is a coda, then okay.
17:43 Paul_the_Greek Of course, I've never put a coda in a single file I've ever created, except for now.
17:44 Paul_the_Greek So many new and exciting practices in Parrotville.
17:44 NotFound Paul_the_Greek: a source file is a texte file.
17:45 NotFound 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.
17:45 Paul_the_Greek I may be editing a binary file.
17:45 NotFound My editor don't assume that, but I know what I'm doing.
17:46 cotto_work If you're doing that with a normal editor, you're asking for it.
17:46 Paul_the_Greek Huh?
17:46 Paul_the_Greek My editor can edit binary files. It even has a hex dump mode that can be edited.
17:46 cotto_work nm in that case
17:46 NotFound I can make mistakes, of course, but tools that silently ignore the problem doesn't help to catch it.
17:46 Paul_the_Greek But I agree that a coda or the appropriate extension can signify that it's a text file.
17:47 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?
17:47 Paul_the_Greek Ooh, bad programmer.
17:47 Paul_the_Greek Shall I display a warning if there is no newline after the last line?
17:47 NotFound Paul_the_Greek: I don't necesary want that, I just don't care for it while I worked on the debugger.
17:48 Paul_the_Greek Easy enough to display a warning.
17:48 NotFound A warning will be nice, yes.
17:48 Paul_the_Greek Consider it done.
17:49 dukeleto Paul_the_Greek: so you are breaking all the parrot_debugger tests? do tell
17:49 * dukeleto backlogs
17:49 NotFound BTW is what gcc does.
17:49 Paul_the_Greek Well, I'm changing the output, so that will break many of them.
17:49 * cotto_work throws a log a darbelo
17:50 Paul_the_Greek For example, every breakpoint command now lists the breakpoint as it stands after the command is done.
17:50 Paul_the_Greek Hitting a breakpoint will display a message about which one you hit.
17:50 Paul_the_Greek Things like that.
17:50 purl things like that are unusual
17:53 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.
17:54 Paul_the_Greek 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 Paul_the_Greek It's only one file so far.
17:56 Paul_the_Greek Actually, I should probably create a patch and let people play before committing.
17:57 cotto_work That's why we have branches.
17:58 NotFound The entire debugger should be marked as experimental until some day when it's somewhat feature complete.
17:59 NotFound We were using it that way before the policy for experimental were stablished.
18:00 pmichaud is anyone going to look at reverting the get_class (and possibly other) changes?  or shall I file a ticket?
18:00 pmichaud I'll file a ticket and blame r48944
18:01 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.
18:01 Paul_the_Greek s/patches/branches/
18:01 NotFound Put the blame on Mame, boy.
18:01 cotto_work mame?
18:01 purl rumour has it mame is http://www.media.dsi.unimi.it/mame/ or at http://drake.dit.upm.es/~mame/ or at http://www.davesclassics.com/ or an arcade game emulator or available on the Kodak DC265 at http://members.aol.com/JWSurine/ or really at http://www.mame.net
18:03 NotFound cotto_work: http://www.youtube.com/watch?v=rVI0A4DTVgg
18:09 pmichaud http://trac.parrot.org/parrot/ticket/1788
18:09 pmichaud afk, lunch
18:10 dalek TT #1788 created by pmichaud++: r48944 breaks rakudo
18:10 dalek TT #1788: http://trac.parrot.org/parrot/ticket/1788
18:13 contingencyplan joined #parrot
18:14 dukeleto TT #1788 is a great reason to move to git, even faster.
18:15 cotto_work dukeleto: has any work been done on moving mk_manifest_and_skip to git?
18:18 hercynium joined #parrot
18:19 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?
18:19 purl well, the hard part is the reliability ;-)
18:20 purl was kicked by pmichaud:  (forgiveness > permission)
18:20 purl joined #parrot
18:21 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 #parrot
18:44 dalek TT #1560 closed by moritz++: r45619 (merge of stringnull branch) causes Rakudo failure in ...
18:44 dalek TT #1560: http://trac.parrot.org/parrot/ticket/1560
18:44 Topic for #parrot is now  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:50 Andy left #parrot
19:06 dukeleto cotto_work: i've made progess in other git stuff in your git_aware_tools branch
19:07 cotto_work glad to hear it
19:08 * davidfetter waves briefly to dukeleto et aliae
19:09 cotto_work It's a bad idea to assume the presence of a .git dir, right?
19:10 cotto_work i.e. ignore it if it's there, but don't depend on it
19:10 dalek parrot: r48979 | nwellnhof++ | trunk (10 files):
19:10 dalek parrot: Switch from charset to encoding opcodes in tests and examples
19:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48979/
19:10 dalek parrot: r48980 | nwellnhof++ | trunk/docs (5 files):
19:10 dalek parrot: Update string API documentation
19:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48980/
19:10 hercynium left #parrot
19:17 dalek tracwiki: v27 | cotto++ | GitMigration
19:17 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=27&amp;action=diff
19:24 dukeleto cotto_work: what exactly do you mean? .git won't exist in release tarballs
19:25 dukeleto cotto_work: and we have to consider people working in bzr/hg mirrors of the parrot repo, i guess
19:25 dukeleto cotto_work: i already killed svnclobber.pl
19:27 dalek parrot: r48981 | nwellnhof++ | trunk/src (7 files):
19:27 dalek parrot: Update a handful of comments still mentioning charsets
19:27 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48981/
19:27 dukeleto cotto_work: i also have http://github.com/parrot/par​rot/tree/leto/kill_svn_tests going, which basically just removes a bunch of svn tests
19:30 cotto_work My only problem is that you didn't use the word "massacre".
19:30 cotto_work ;)
19:30 atrodo massacre++
19:31 whiteknight tcurtis++
19:31 cotto_work what's he up to now?
19:31 whiteknight nov release manager
19:32 GeJ Bonjour everyone.
19:32 whiteknight hello GeJ
19:34 dalek tracwiki: v28 | dukeleto++ | GitMigration
19:34 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=28&amp;action=diff
19:37 dukeleto cotto_work: yeah, should have named it svn_massacre ;)
19:38 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?
19:38 dukeleto cotto_work: git clean
19:38 * 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
19:39 dukeleto cotto_work: git clenan -fdx <==> svnclobber.pl
19:39 dukeleto cotto_work: git clean -fdx, that is
19:39 dukeleto \o/ for deleting code
19:40 cotto_work it'll FedEd any uncommitted changes to /dev/null
19:40 cotto_work s/changes/anything/
19:40 whiteknight and /dev/null will FedEx it back to itself
19:44 kid51 joined #parrot
19:49 dukeleto kid51: hola
19:51 dalek eclectus: 7214e75 | bschmalhofer++ | docs/eclectus.pod:
19:51 dalek eclectus: Fixed path to test scripts.
19:51 dalek eclectus: review: http://github.com/bschmalhofer/eclectus/comm​it/7214e75b0b10b132e77bd45dcc29a47bbf490b59
19:55 dalek winxed: r648 | NotFound++ | trunk/winxedst1.winxed:
19:55 dalek winxed: use keyed syntax for Getopt Obj in stage 1 compiler
19:55 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=648
19:59 whiteknight left #parrot
20:15 dalek winxed: r649 | NotFound++ | trunk/winxedst1.winxed:
20:15 dalek winxed: rename ClassBase to ClassSpecifier also in stage 1 compiler
20:15 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=649
20:27 tcurtis left #parrot
20:34 luben pmichaud, ping
20:34 pmichaud luben: pong
20:34 luben I am ready with the patch for src/oo.o
20:35 luben but I have a problem
20:35 luben There seems to be unrelated bug (here I has shown after boolean branch merge)
20:36 luben so I could not test that this fixes the case
20:36 pmichaud I agree, this is a problem.
20:36 pmichaud the revision that the branch was based on had several problems in it that broke rakudo
20:36 pmichaud the src/oo.c problem is just one of them.
20:37 pmichaud so, when the branch was merged back in, it's possible that other needed fixes were lost as well
20:37 pmichaud it's not so easy for me to pinpoint the exact parrot commits that might have fixed those other issues.
20:37 luben I have reviewed the diffs I am sure thet oo.c is only reverted change
20:38 luben 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.
20:39 pmichaud 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
20:40 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 pmichaud s/save/safe/
20:42 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...
20:42 pmichaud sorear: gc
20:43 sorear I thought our GC ignored compiled code
20:43 pmichaud the gc goes quadratic with large (largish) strings at that point
20:43 pmichaud well, loading rakudo ends up with more than just compiled code
20:43 pmichaud all of the :load routines get executed
20:44 pmichaud 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:45 dalek TT #1789 created by pmichaud++: String concatenation is really slow
20:45 dalek TT #1789: http://trac.parrot.org/parrot/ticket/1789
20:45 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 #parrot
20:46 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:47 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 #parrot
20:47 pmichaud dukeleto: we've only been saying that for nearly three years.  :-|
20:48 dukeleto pmichaud: well, perhaps we can fix that
20:48 pmichaud perhaps longer.
20:48 pmichaud dukeleto: I hope you'll forgive me if I'm not entirely optimistic about that.
20:48 cotto_work We could call the branch "gc_massacre".
20:48 pmichaud hey!  great idea!
20:49 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.
20:50 pmichaud (phone)
20:52 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
20:53 dalek parrot: r48982 | luben++ | trunk/src (2 files):
20:53 luben pmichaud, fix commited in r48982
20:53 dalek parrot: fix a unintended change resulted from hash_inlined merge
20:53 dalek parrot: Merging hash_inlined_func branch reverted some previous commits.
20:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48982/
20:54 pmichaud I did a similar program that simply concatenated 25,000 integers together.  That program resulted in something like 1700 mark runs.
20:55 pmichaud 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
20:55 pmichaud (or, at least, that's part of the problem)
20:55 NotFound This is the main problem.
20:55 tadzik joined #parrot
20:55 pmichaud NotFound: why would that be a problem?
20:56 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
20:56 NotFound It affects any attempt to clean the string mess.
20:58 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.
20:59 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.
20:59 pmichaud cotto_work: depends on how long it takes for rakudo to start working with parrot again.  :)
21:00 pmichaud I can try building rakudo from the branch and see what fails.
21:00 NotFound Is working with trunk right now?
21:00 pmichaud no.
21:00 cotto_work It's been a while since it was synced with trunk, iirc.
21:00 pmichaud I'm testing r48982 now.
21:01 Andy joined #parrot
21:02 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:03 Coke does it do anything?
21:03 cotto_work (having, in this theoretical situation, confirmed that Rakudo works with the branch)
21:03 NotFound cotto_work: it's convenient to check if the boolean merge has done some damage to rakudo, to avoid mixing problems.
21:03 cotto_work adds a new gc that needs tuning but has the potential to be faster than what we havew now.
21:04 NotFound cotto_work: "potential to be faster than what we havew now" -> surely a mumerous family ;)
21:04 perlite left #parrot
21:04 cotto_work NotFound: I agree, but some problems were already exposed and dealt with.
21:04 whiteknight joined #parrot
21:04 perlite joined #parrot
21:05 cotto_work Tuning and testing is the blocker, not coding afaict.
21:05 cotto_work In the wurst case (Mmmm.  Wurst.) we can make the new gc core non-default.
21:06 NotFound We can make the infinite memory the default ;)
21:06 tadzik left #parrot
21:06 cotto_work We keep complaining about gc but nobo0dy's taken the initiative to merge the branch.
21:06 cotto_work s/0//
21:06 atrodo what needs done to merge?
21:07 cotto_work 1 - verify the hash_inline merge, clean up any additional junk that shouldn't have been merged
21:07 cotto_work 2 - make sure Rakudo builds and passes its spectest with trunk
21:07 cotto_work 3 - sync gc_massacre with trunk
21:08 cotto_work 4 - make the new gc non-default (switch this step with 3)
21:08 cotto_work 5 - merge
21:08 luben cotto_work, hash_inlined_func merge problems were just fixed, r48982.
21:09 cotto_work luben: did you verify that no other stuff got mismerged?
21:09 pmichaud luben: we only know that.... what cotto++ just said
21:09 luben NotFound, after boolean merge rakudo stopped working for me
21:09 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.
21:09 cotto_work No, but it's a lower barrier to entry
21:10 Coke is that a pool you really want to swim in?
21:10 dalek parrot: r48983 | mikehh++ | trunk/src/oo.c:
21:10 dalek parrot: fix codetest failure - trailing whitespace
21:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48983/
21:10 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
21:10 cotto_work Probably not me, but I was someone in it.
21:10 Coke ->
21:11 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)
21:11 pmichaud (test is still running, more failures may show up)
21:11 pmichaud the 48982 feels like it could be a boolean failure
21:11 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.)
21:11 cotto_work luben++
21:13 luben let me check again
21:15 bacek aloha, humans
21:15 whiteknight hello bacek
21:15 bacek whiteknight, hello
21:16 cotto_work hail, bacek
21:17 bacek aloha, cotto_work
21:22 pmichaud boolean merge breaks at least one rakudo test.
21:26 dalek winxed: r650 | NotFound++ | trunk/winxedst1.winxed:
21:26 dalek winxed: refactor keyed new using ClassSpecifier in stage 1 compiler
21:26 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=650
21:27 dalek parrot: r48984 | bacek++ | branches/gc_massacre (203 files):
21:27 dalek parrot: Merge branch 'master' into gc_massacre
21:27 dalek parrot: Conflicts:
21:27 dalek parrot: src/gc/system.c
21:27 purl src/gc/system.c is a known mess and I'm working on it as we speak
21:27 dalek parrot: src/string/encoding/fixed_8.c
21:27 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48984/
21:28 kid51 left #parrot
21:28 purl was kicked by pmichaud: purl
21:28 purl joined #parrot
21:29 pmichaud r48982 leaves at least two spectest failures for Rakudo.
21:29 pmichaud One is definitely from the Boolean switch, as  :multi(Integer, Integer)  no longer accepts boolean arguments
21:30 pmichaud I'm still trying to figure out the other one.
21:31 sorear what does "two spectest failures" mean?  I thought we had thousands
21:32 cotto_work bacek++
21:32 pmichaud it means that at least two tests that were passing in r48933 are no longer passing in r48982
21:32 pmichaud (I don't understand "I thought we had thousands.")
21:37 luben what is the other test that doesn't pass
21:37 smash left #parrot
21:38 pmichaud t/spec/S32-str/encode.t fails test #10
21:38 pmichaud t/spec/S03-operators/short-circuit.rakudo fails test #20
21:38 pmichaud the short-circuit.t test is definitely because Boolean is no longer "isa Integer"
21:39 pmichaud I haven't figured out what is causing the encode.t test to fail yet.
21:39 cotto_work Does Perl 6 require that?
21:39 pmichaud Perl 6 doesn't, but some of our internals apparently were making use of it
21:40 pmichaud 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:41 NotFound pmichaud: That test uses ByteBuffer?
21:41 pmichaud NotFound: the encode.t test does, yes.
21:42 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 :)
21:42 pmichaud was ByteBuffer available in 2_6_0 ?
21:43 NotFound pmichaud: I think so
21:43 pmichaud hmmm
21:43 NotFound If you are thinking about the deprecation police, note that is marked as experimental.
21:44 pmichaud it is?
21:44 purl Oh no it isn't!
21:44 purl was kicked by pmichaud: purl
21:44 purl joined #parrot
21:45 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
21:45 pmichaud I'm looking at the 2.6 release notes.
21:46 NotFound It was added in 2.5
21:46 pmichaud from DEPRECATED.pod, in 2.6.0:
21:46 pmichaud "For an item to be considered experimental, it can B<never> have shipped in
21:46 pmichaud a supported release without the C<[experimental]> tag; otherwise, it must be
21:46 pmichaud deprecated normally before removal or incompatible change.
21:46 pmichaud "
21:48 NotFound The offending method can be fixed to accept two arguments, but I'm not sure if it makes sense.
21:49 pmichaud according to the deprecation policy, it does make sense (at least until the next supported release).
21:50 fperrad left #parrot
21:50 pmichaud (and assuming that this is the method that is causing the Rakudo failure)
21:51 NotFound -    METHOD get_string(STRING *charsetname, STRING *encodingname) {
21:51 NotFound +    METHOD get_string(STRING *encodingname) {
21:51 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.
21:51 NotFound This is the candidate
21:52 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 ;)
21:52 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"
21:55 dukeleto pmichaud: i think it is not so much hypocrisy as unintended consequences, but I understand your frustration
21:56 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 pmichaud and potentially not even then.
21:56 cotto_work left #parrot
21:59 pmichaud anyway, I'll write tickets for the new deprecation issues and people can work it out on the list.
22:00 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 NotFound We had a check that verifierd that Boolean isa Integer
22:01 pmichaud ouch.
22:01 pmichaud that definitely implies "deprecation notice needed"
22:01 pmichaud one cannot simply remove a tested behavior because it's inconvenient.
22:03 NotFound Mmmm... no, I was fooling myself.
22:04 NotFound There is just a check that does scalar
22:05 NotFound interface_check, at the bottom of t/pmc/boolean.t
22:06 NotFound And that part don't changed in the boolean merge
22:09 cotto_work joined #parrot
22:11 dalek TT #1788 closed by luben++: r48944 breaks rakudo
22:11 dalek TT #1788: http://trac.parrot.org/parrot/ticket/1788
22:11 dalek TT #1790 created by pmichaud++: r48965 changes :multi dispatch from 2.6.0 behavior
22:11 dalek TT #1790: http://trac.parrot.org/parrot/ticket/1790
22:14 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)
22:15 pmichaud rakudo doesn't use it directly, but only indirectly via nqp
22:15 NotFound I think we must promove it to official status, then.
22:15 pmichaud well, I don't mind if features explicitly marked 'experimental' change.
22:16 pmichaud it's when the non-experimental features change that we run into trouble.
22:17 pmichaud (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
22:18 pmichaud wfm :)
22:29 NotFound I see we still have the duplicated silliness in DEPRECATED.pod
22:40 kid51 joined #parrot
22:40 kid51 ~~
22:42 bacek_at_work ~~
22:43 bluescreen left #parrot
22:46 jimk joined #parrot
22:47 jimk left #parrot
22:48 kid51 left #parrot
22:55 kid51 joined #parrot
23:10 Paul_the_Greek joined #parrot
23:10 Paul_the_Greek Howdy ho.
23:12 nopaste "Paul_the_Greek" at 192.168.1.3 pasted "Is this correct?" (8 lines) at http://nopaste.snit.ch/23316
23:12 davidfetter mr. hanky? is that you?!?
23:12 Paul_the_Greek Can someone take a look at that paste?
23:12 Paul_the_Greek I have no hankies.
23:12 cotto_work what about it?
23:13 Paul_the_Greek Are the PCs correct in the disassembly?
23:13 cotto_work It looks sane,
23:13 Paul_the_Greek I know the line numbers aren't.
23:13 cotto_work period
23:13 Paul_the_Greek So the .sub does not generate any code?
23:13 bacek_at_work .sub generate code
23:13 cotto_work Nope.  .sub is an abstraction.  You'll find it if you look at the constants table
23:14 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
23:15 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 http://github.com/parrot/pir/bl​ob/master/src/POST/Compiler.pm (starting from line 60)
23:16 bacek_at_work nope
23:17 bacek_at_work PC 0 is for "say_sc"
23:17 bacek_at_work 2 is for implicit "end" inserted by IMCC
23:17 Paul_the_Greek Oh, then maybe I'm getting confused because the debugger's line numbers are off by 1.
23:18 Paul_the_Greek Hang on ...
23:18 bacek_at_work line numbering is well known problem...
23:18 nopaste "Paul_the_Greek" at 192.168.1.3 pasted "Debugger output" (18 lines) at http://nopaste.snit.ch/23317
23:19 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.
23:19 Paul_the_Greek The algorithm for scanning the compiled code to match up lines and PCs must be too simplistic.
23:20 Paul_the_Greek Can I paste it for someone to look at?
23:21 cotto_work Anything that uses line numbers relies on information generated by imcc.
23:21 NotFound Paul_the_Greek: scanning the compiled code? =:o
23:22 Paul_the_Greek Yes, it scans beginning at interp->code->base.data, trying to match instruction offsets to source lines.
23:22 Paul_the_Greek I'll paste the code.
23:22 NotFound Paul_the_Greek: don't do that.
23:23 Paul_the_Greek Don't scan, or don't paste? :D
23:23 NotFound Don't write code like that-
23:23 Paul_the_Greek I did rather think it was a bit funky.
23:23 NotFound We have a pir debug segment and an annotations segment.
23:24 Paul_the_Greek With those I can match source lines to PCs reliably?
23:24 cotto_work "reliably" is such a strong word
23:24 NotFound They are not very reliable, but writing and maintaining yet another way to do the work is not a good solution.
23:24 Paul_the_Greek Yes, especially when you're not really parsing the lines, but just glancing at them.
23:24 cotto_work "as well as imcc" would be more accurate
23:25 Paul_the_Greek That code is in the debugger already, but I'm happy to replace it with something better.
23:25 Paul_the_Greek What would I look at to get a reasonable understanding?
23:26 NotFound Paul_the_Greek: code that parses the source to match bytecode?
23:27 Paul_the_Greek Yes. It's five lines of code plus a poor man's parser.
23:27 Paul_the_Greek Basically, it decides if there is an opcode/directive, then looks up the next byte in the op_info_table.
23:28 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.
23:28 Paul_the_Greek Since the op_info_table contains entries for the directives, too, it sort of works.
23:28 Paul_the_Greek It thinks .sub takes 2 bytes.
23:28 NotFound What?
23:29 Paul_the_Greek Let me check ...
23:29 NotFound Anyway, that remainders of past times should be killed.
23:30 Paul_the_Greek No, never mind, it's just being stupid and assuming byte 0 is the opcode for .sub
23:32 Paul_the_Greek 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.
23:32 jnthn There is no .sub opcode
23:32 Paul_the_Greek I'm pretty sure, since I rewrote the load_source function.
23:33 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.
23:33 Paul_the_Greek NotFound: Indeed.
23:33 Paul_the_Greek So does the debug segment have PC <=> source line correspondence?
23:34 NotFound Paul_the_Greek: I'm not sure if the PDD is fully uptodate, but is a good guide.
23:35 NotFound Paul_the_Greek: yes, but not in a immediately obvious way.
23:36 Paul_the_Greek Okay, I'll study it.
23:36 Paul_the_Greek There is a disassemble command in the debugger, but it doesn't list anything.
23:37 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.
23:37 * jnthn -> sleep
23:37 autark left #parrot
23:37 Paul_the_Greek What does disassemble do?
23:38 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?
23:39 NotFound Paul_the_Greek: disassemble, and put the lines generated in the debugger structs to be shown with l
23:39 NotFound Paul_the_Greek: It means that I become cross-eyed with that things :D
23:39 Paul_the_Greek Oh, it replaces the source with the disassembly. Wild!
23:40 Paul_the_Greek But the disassembly has no PCs.
23:40 Paul_the_Greek It has line numbers, but I don't know what they mean.
23:40 NotFound Yeah, the list command is not very smart.
23:41 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 ruoso joined #parrot
23:41 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!
23:42 Paul_the_Greek So I have to add "seriously" after my question tomorrow.
23:45 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:46 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.
23:47 whiteknight it probably could be used for a debugger
23:48 NotFound Someone is going to merge it?
23:49 NotFound 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:50 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.
23:50 Paul_the_Greek New subject: Could someone look at this ticket: http://trac.parrot.org/parrot/ticket/1790
23:51 Paul_the_Greek What's the right thing to do? We agreed this didn't need a deprecation notice, but perhaps that was the wrong decision.
23:52 * cotto_work is evolving.
23:52 cotto_work It turned into cotto
23:52 NotFound Multidispatch is a part of parrot completely out of my skills, sorry.
23:52 cotto_work left #parrot
23:53 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 #parrot
23:58 pmichaud http://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 pmichaud (except for the name, obviously)

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced