Parrot 2.11.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: write GettingStartedWithPlumage, review html documentation, test HLLs, review deprecations | only critical fixes and documentation updates until after 3.0.0
Set by moderator on 16 January 2011.
00:05 KatrinaTheLamia left 00:12 allison joined 00:13 allison left 00:16 allison joined
bacek_at_work seen jimmy 00:18
aloha Sorry, I haven't seen jimmy.
bacek_at_work seen jimmyz
aloha jimmyz was last seen in #parrot 1 days 7 hours ago joining the channel.
00:21 KatrinaTheLamia joined 00:25 aloha left 00:27 aloha joined
dalek rrot/nqp_pct: e9cd556 | bacek++ | compilers/pct/src/POST/Node.pm:
Revert "added missing =cut". This is Perl6 pod syntax, not Perl5.

This reverts commit 1f020173a3241fd10672c46d74b0faca948beeda.		 01:00
plobsing bacek_at_work: is there a perl6doc somewhere so that I might view that pod? 01:10
dukeleto plobsing: cpanm App::grok , iirc 01:22
01:23 whiteknight joined 01:32 vmspb left
bacek_at_work aloha, S26? 01:35
aloha bacek_at_work: I have no idea.
bacek_at_work aloha, S26 is Perl6 POD or github.com/perl6/specs/raw/master/...tation.pod
aloha bacek_at_work: Okay.
bacek_at_work aloha, S26
aloha, S26? 01:36
aloha bacek_at_work: S26 is Perl6 POD or github.com/perl6/specs/raw/master/...tation.pod
01:36 kid51 joined
bacek_at_work aloha, Perl6 pod is see S26 01:36
aloha bacek_at_work: Okay.
dukeleto bacek_at_work: what are you hacking on? 01:37
bacek_at_work dukeleto, migrating PCT to nqp :)
dukeleto, part of PIRATE/POST-to-PBC effort
atrodo cotto> ping
dukeleto bacek_at_work: can you explain that to me a bit more? I have been watching what you are doing, but I don't quite understand why 01:38
bacek_at_work dukeleto, why what?
dukeleto bacek_at_work: why is PCT being converted to nqp-rx ? what does that buy us? 01:39
bacek_at_work: so that it doesn't use PGE anymore?
bacek_at_work dukeleto, emitting PBC from POST (large part of PIRATE) is implemented in nqp-rx.
Basically PIRATE is "PIR Grammar" + "POST2PBC"
POST2PBC is part of PCT.
Instead of having mixed PIR/nqp implementation of PCT I decided to migrate PCT to nqp-rx. 01:40
POST::* parts for now.
Makes sense?
dukeleto bacek_at_work: i have seen the light! 01:41
bacek_at_work dukeleto, :)
dukeleto, instead of having "Language->PAST->POST->PIR->imcc->PBC" we will have "Language->PAST->POST->PBC" 01:42
Get imcc out of loop :)
dukeleto bacek_at_work: ah, that is a big win 01:43
bacek_at_work And PIRATE is just "PIR Language" with shortcutting PAST step.
dukeleto bacek_at_work++ and imcc--
bacek_at_work dukeleto, actually POST->PBC step is already implemented (mostly). You can checkout PIRATE and run quite few tests. Pirate still not self-hosted and extremely slow, but it's "a good start" 01:46
dukeleto bacek_at_work: if you can document low hanging fruit somewhere, others can help you 01:47
bacek_at_work And we can plug tree-optimizations between PAST->POST and POST->PBC steps for having less crazy bytecode generated.
dukeleto bacek_at_work: right now, you seem to be the only person that can actually hack on PIRATE, I want to grow that number
bacek_at_work: that sounds awesome
bacek_at_work dukeleto, cotto also hacked it a bit. 01:48
dukeleto cotto: darn you for proving me wrong!
bacek_at_work but yes, I would like to see more people working on it
dukeleto bacek_at_work: anyway, we still need to up that bus number!
bacek_at_work dukeleto, I've got some kind of todo list on rememeberthemilk 01:49
dukeleto bacek_at_work: !!!
bacek_at_work: do you have a religious stance against Github issues?
bacek_at_work: ;)
nopaste "bacek" at 192.168.1.3 pasted "Pirate todo list" (26 lines) at nopaste.snit.ch/27963 01:50
bacek_at_work dukeleto, none at all. I just was too lazy :)
dukeleto bacek_at_work: also, jnthn has a file called LHF.txt in nqp-rx, which seems like a good compromise
bacek_at_work: then you can use git to edit LHF.txt and tickle that reptilian complex :)
bacek_at_work yeah. I have TODO file in pirate. But rtm list is more comprehensive 01:51
dukeleto bacek_at_work: github.com/jnthn/6model/blob/maste...et/LHF.txt
bacek_at_work dukeleto, way too complex :) 01:52
dukeleto bacek_at_work: heh. how hard is the "implementing CLI" arguments thingie?
bacek_at_work dukeleto, GCI :)
dukeleto, if you can create github issues for nopasted list it will be handy. 01:53
And I hve to run for next meeting
c u
dukeleto bacek_at_work: i can try later. Must go to a dinner party or be torched alive.
01:59 Themeruta is now known as NotFound 02:49 kid51 left 02:50 whiteknight left
dalek rrot/nqp_pct: d90f467 | bacek++ | compilers/pct/src/POST/Node.pm:
Remove lefover =cut directives
 03:17
cotto atrodo, pong 03:51
03:52 fbrito joined
cotto atrodo, I saw you had some struct parsing code but it looked like nothing was fully implemented. 03:52
atrodo cotto> In fact, I have thought what a struct would look like. Since my PMCs are blocks of memory, it's pretty easy
cotto> Yes, that's actually apart of the work I'm on now 03:53
cotto how timely
jnthn was kind enough to give me a basic list of things that'd be needed for a 6model implementation. It's essentially structs, arrays, hashes and invokable thingies that can accept arguments. 03:54
nothing earth-shattering, which is the point 03:55
atrodo I saw that. And I'm working on arrays and hashs now
cotto you're an asset 03:58
plobsing cotto: for structs, could you get by with just pointers and pointer-sized ints? it would make the implementation pretty easy. 04:25
cotto plobsing, whose pointers? 04:32
plobsing platform-native 04:33
it would completely eliminate the problem of alignment because all elts are the same size, so it reduces to an array. 04:35
with some fancier bookkeeping for GC
cotto The simplicity is tempting, but that'd also mean different behavior on different architectures. 04:42
plobsing can you give an example of a situation where that might come up? we have INTVAL now which is pointer-sized, and we don't seem to be suffering from such issues to my knowledge. 04:43
alternatively to uniform elt sized structs, may I suggest that M0 struct access have offsets calculated (and checked for alignedness) at compile time? such checks performed at runtime could get costly quick. 04:45
04:46 theory left
cotto that could wor 04:52
k
plobsing of course, I would also advise against building such logic directly into the M0 compiler. smarts like that are part of where imcc went wrong. 05:19
some kind of separate macro pre-processor maybe
05:20 jan left 05:40 Andy joined
Andy What is the magic to regenerate src/ops/*.c 05:40
plobsing ./opsc --core 05:42
er ops2c rather
cotto or make bootstrap-ops 05:43
05:47 rurban_ joined 05:50 rurban left, rurban_ is now known as rurban
Andy so basically we're saying "ops change so rarely no need to rebuild on every build" 05:50
sorear Andy: more than that, we've dogfooded the op rebuilder 05:51
you need a working Parrot to rebuild ops 05:52
Andy as in, installed? 05:55
cotto sorear, that's not quite true. Since the generated C files are checked in, they can be used to build a parrot to build the ops.
bacek_at_work cotto, sorear was right. We do need working parrot to rebuild ops :) 05:56
cotto Right, but that can be the parrot in the build dir. 05:57
sorry. I was conflating "working" and "installed".
Andy well, my "make boostrap-ops" is failing on me, alas. 06:01
do I need to do something to specify which parrot?
wait, dont' tell me
i'm going to bed.
cotto Andy, how's it failing?
Andy I'm gonna deal with this tomorrow
g'night y'all 06:02
cotto ok
06:02 Andy left
cotto 'night 06:02
Hmm. looks broken here too 06:06
might just need realclean to clear out invalidated pbc 06:08
It seems to generate a different ordering of ops
06:08 jan joined
cotto Ah. Looks like it's due to finalize being deexperimentalized. It gets put much earlier in the list. 06:09
looks fine after that
msg Andy make bootstrap-ops works fine. It just needs realclean afterward to clear out invalidated pbc due to an op numbering change. 06:10
aloha OK. I'll deliver the message.
Coke we're getting even more failures than embed.t: smolder.parrot.org/app/projects/rep...tails/3216 06:41
lots of smoke now that smolder is back up.
(that particular report has a lot of --without-* flags, but we should still track down the failures.) 06:46
cotto dukeleto, ping 07:19
07:21 mberends joined 07:42 kurahaupo joined
dukeleto cotto: pong 07:49
07:51 kurahaupo left
cotto dukeleto, see privmsg 07:52
dukeleto it looks like t/pmc/nci.t needs some tests TODOed when parrot is compiled with --without-libffi --without-extra-nci-thunks
cotto yeah. Your combinatorial smoking is revealing some surprising failures. 07:53
dukeleto cotto: and the failures in t/src/embet.t are not the tests that I recently added 07:55
embed.t
cotto: those are some really old tests that are failing in embed.t 07:56
Coke my darwin smoke looks greenish. 07:58
dukeleto Coke: our tests seem to be fine on a normal config, but some combination of compile flags still cause test failures 07:59
Coke: mostly due to some tests not being TODOed when they should
where does ometazd (sp?) live? 08:01
Should that be in NEWS?
cotto dukeleto, github
dukeleto found it 08:04
dalek rrot: 845f1c2 | dukeleto++ | NEWS:
Add NEWS item about Ī©Ī·;)XD
 08:05
dukeleto plobsing++ # using the substring ;) in a language name 08:07
cotto: should we deprecate the todo() function ? 08:09
cotto dukeleto, I don't think it's worthwhile, but I don't feel too strongly either way. 08:10
I should write some tests with the named todo and see how it feels.
dukeleto cotto: it makes testing much nicer 08:13
cotto: i am adding some basic docs for it right now
dalek rrot: a4a3627 | dukeleto++ | runtime/parrot/library/Test/More.pir:
[doc] Add some examples using the new way to TODO tests
 08:14
dukeleto cotto: the old way to todo tests requires you to write a test differently, depending on if it is a TODO or not 08:15
cotto: which really sucks
cotto: because you write a test, then realize it needs to be TODOed, then you need to change it around 08:16
cotto: this way, you just add a named argument to your test function and you are set
cotto: let me know if you need any other help in releasing 3.0 08:17
cotto: i think our NEWS file is in pretty decent shape
08:19 fperrad joined
cotto dukeleto, thanks 08:21
dukeleto one thing to note with the smokers is that the sparc32 machine is much slower than the other, so it doesn't update it's repo as often, so you may see failures there a for a few hours after a commit happens
PROTIP: ^^^
cotto I definitely prefer using a named todo, but I don't think deprecating the old version is worth the churn.
dukeleto cotto: yep, i agree. just wondering 08:22
cotto: can you add extend_vtable.h to deprecations? i haven't had the time
cotto dukeleto, what about it? The whole thing?
dukeleto cotto: yep. if we change any vtables, some part of it will change 08:23
cotto: and the new embed api will replace part of it
cotto: it won't be removed, but we want the freedom to change some function signatures/vtable signatures
cotto: it is part of the old embedding API 08:24
cotto: but the new embedding API doesn't do everything that extend_vtable does
cotto dukeleto, So what's being deprecated? We're trying to get away from deprecating anything without having a replacement ready to use at the point of removal. 08:25
which parts of extend_vtable, that is
dukeleto cotto: hmm, perhaps now is not the time 08:26
cotto: let's wait on it
cotto ok
08:26 fbrito left
cotto Some cool stuff will be going in after 3.0.0 is out. I'm excited. 08:28
cotto sleeps 08:29
dukeleto cotto: don't let the bed bugs bite! 08:30
dukeleto does the same
08:46 TiMBuS left, TiMBuS joined 08:52 Psyche^ joined, Patterner left, Psyche^ is now known as Patterner
dalek rrot: 22eccfd | fperrad++ | NEWS:
[NEWS] about Plumage
 08:53
08:54 allison left 08:58 allison joined
tadzik ~ 09:10
09:44 contingencyplan left
bacek ~~ 10:16
10:21 JimmyZ joined 10:31 wesjdj joined 10:45 ambs joined 10:57 Kulag left 11:01 JimmyZ_ joined 11:04 JimmyZ left, JimmyZ_ is now known as JimmyZ 11:09 fbrito joined
dalek rrot/imcc_cleanups: da323e3 | Whiteknight++ | compilers/imcc/ (3 files):
move call-in interface functions for IMCC into compilers/imcc/main.c from compilers/imcc/parser_util.c. This will allow for better side-by-side comparison, and eventually unify these into a second callpath
 11:35
11:48 Drossel joined 11:54 Drossel left 11:55 Kulag joined
dalek rrot: 71fe141 | (Gerd Pokorra)++ | lib/Parrot/Revision.pm:
counting commits to get a number similar a svn revision
 12:00
12:17 Kulag left 12:20 Kulag joined, JimmyZ left 12:26 Drossel joined 12:28 Kulag left 12:33 Drossel left 12:40 Kulag joined 12:47 Kulag left, Kulag joined 12:49 nopaste left, TonyC_ joined, TonyC left 12:50 nopaste joined 12:58 wesjdj left
dalek rrot: ebb7ec6 | (Gerd Pokorra)++ | lib/Parrot/Revision.pm:
change release default to zero
 13:05
13:15 fbrito1 joined 13:18 fbrito left 13:23 fbrito1 left, whiteknight joined 13:49 rurban_ joined 13:52 rurban left, rurban_ is now known as rurban
whiteknight good morning, #parrot 14:09
14:09 plobsing left 14:10 ambs left 14:15 Khisanth left 14:32 plobsing joined
whiteknight msg Andy I should be in #parrot most days. I would love to talk about PARROT_CATCH_NULL when you have a moment 14:32
aloha OK. I'll deliver the message.
whiteknight much of the evilness of IMCC that I am finding stems from three problems: 1) lots of unnecessarily duplicated code, especially in the external-facing interface functions, 2) extremely poorly-named functions, and 3) not having any particular rhyme or reason for how logical code paths are broken up into separate functions 14:36
when you take a function which was simply split out of a larger function along any arbitrary lines, and give it a confusing name, you end up with confused developers
I happen to know the answer now, after several hours of reading code and tracing it, but I would be surprised if anybody else could tell me what the differences are between imcc_run, imcc_compile, imcc_compile_file, imcc_run_compilation, compile_string, and compile_file 14:38
a quick sed script could fix those ambiguities
14:46 vmspb joined
dalek TT #1975 created by doughera++: pbc_dump and pbc_merge may crash on illegal options 14:52
TT #1975: trac.parrot.org/parrot/ticket/1975
15:05 PacoLinux joined 15:08 bluescreen joined 15:24 plobsing left 15:32 plobsing joined 15:37 kid51 joined
nopaste "kid51" at 192.168.1.3 pasted "t/dynoplibs/trans.t: test failures reproduced on two boxes" (81 lines) at nopaste.snit.ch/27996 15:39
15:39 kid51 left
nopaste "plobsing" at 192.168.1.3 pasted "[PATCH] properly skip GMP on 32-bit" (13 lines) at nopaste.snit.ch/27999 15:45
dalek rrot: 489709a | Whiteknight++ | frontend/pbc_merge/main.c:
attempted fix for TT #1973
plobsing msg kid51 try nopaste.snit.ch/27999 for your t/dynoplibs/trans.t problems. I suspect it is simply a failure to skip tests appropriately. 15:46
aloha OK. I'll deliver the message.
16:04 ambs joined 16:13 vmspb left 16:19 bacek left, bluescreen left
whiteknight plobsing: ping 16:21
plobsing pong 16:27
whiteknight plobsing: I think I want to move much of the PackFile merge logic from pbc_merge into libparrot. Merging a packfile (from IMCC for instance) into another packfile seems like it will become a common operation
And if we expose that functionality through a method on the PackFile PMC, we get the nice benefit that pbc_merge becomes a ~20 line PIR program 16:28
plobsing I'm opposed to the philosophy of tacking every packfile-related operation on as a method on packfile PMCs. 16:29
16:29 bacek joined, fbrito joined
whiteknight plobsing: well, I'm hoping that there will be a relatively small handful of packfile operations that the user cares about 16:30
plobsing What I'd ultimately like to see is a fairly minimal set of packfile, to which such functionality can be added by runtime libraries implemented in HLLs.
merge is not a fundamental operation, IMHO
whiteknight what I'm thinking about is a situation where an HLL compiler returns us a proper packfile, not an Eval or anything stupid like that. Also, the HLL compiler doesn't automatically overwrite interp->initial_pf, or automatically create it's new segments in it 16:31
so what we get back from a compiler is a completely fresh PackFile, completely unrelated to interp->initial_pf
plobsing parrot should be able to handle more than one packfile. otherwise we stand no chance of GCing them. 16:32
whiteknight then, if we want to make that packfile live and executable, we either need to swap out the current packfile, or merge them together
we can always GC a PMC that is stored in a register
or, GC mark it
plobsing stored in a register? if you *merge* the packfiles, their resources become irreversibly entangled. 16:33
whiteknight do you see that as a fundamental reality, or a bug that we can fix? 16:34
plobsing see Parrot_switch_to_cs for an example of how we currently manage multiple simultaneous packfiles
we're already doing just that
don't take it away
whiteknight don't take what away?
plobsing multiple parallel packfiles
whiteknight nobody is talking about taking that away 16:35
plobsing it already works. the "merge" functionality on pbc load is *not* the same as the merge functionality from pbc_merge
one is shallow, the other deep.
16:35 dmalcolm joined
whiteknight There's a difference between a PackFile* and a PackFile_ByteCode*. Parrot_switch_to_cs only switches between bytecode segments in a single packfile 16:41
it doesn't give us anything if we've got two completely separate packfiles 16:42
we still need a way to say "use this packfile instead of interp->initial_pf" 16:43
plobsing if and when packfiles are managed by PBCs and properly mark their dependancies, any PackFile_ByteCode will point to its containing PackFile_Directory (or possibly only the contained resources it cares about).
Subs will point to the PackFile_Bytecode they require 16:44
so invoking a sub (which can be obtained from the packfile) will use the appropriate packfile.
whiteknight So in that case you're basically saying we delete interp->initial_pf and interp->code entirely 16:45
plobsing yes to interp->initial_pf, no to interp->code
interp->code is a cached pointer to the bytecode we are currently executing
whiteknight okay
16:46 JimmyZ joined
whiteknight so example workflow: I pass a string to the IMCC compreg. It returns me a packfile. I use that packfile to find a sub I am interested in and invoke it. Internally, the invoke calls Parrot_switch_to_cs to put us on the right segment, and we just chug along? 16:46
somewhere in there we save the previous segment in the return continuation 16:47
and in that case, so long as we have a reference to it, there's no difference between a PackFile which is loaded or not loaded
Within the space of a month I am going to have IMCC no longer writing any data to interp->initial_pf or interp->code, and it will no longer be creating it's new segments in interp->initial_pf packfile 16:50
Coke /me tries to figure out how to pass args to dukeleto's build scripts.
whiteknight and I'm trying to figure out exactly what support routines I need to write to support that
16:53 plobsing left 16:58 plobsing joined
plobsing whiteknight: yes, the retcontinuation will hold a pointer to the original packfile by virtue of being derived from a sub (the caller) which depends on said packfile 16:59
initial_pf is only required as a point to perform GC marking on packfiles which are not yet proper PBCs (but may point to GCables). we shallow-merge all loaded packfiles into it so that they are tracked as well. 17:00
17:02 plobsing_ joined 17:03 plobsing_ left
whiteknight what's the routine to shallow-merge? Is there anything specific? 17:06
plobsing whiteknight: (re: TT #1973) 489709a60 does appear to fix the problem, but we need to handle cases where the API functions have been circumvented somehow better. exit() without printing anything is unnaceptable.
whiteknight PF_create_default_segs seems like the likely culprit to me 17:07
plobsing: Yes, I'm working on a better solution
probably won't be in before 3.0
plobsing I'd like a backtrace or a coredump, but that might just be me. 17:08
whiteknight plobsing: Ultimate goal is to update pbc_merge in some fashion to use the new API instead of the old one
plobsing yes, but we need better encapsulation-break detection
whiteknight plobsing: That's true. of course, if a user breaks encapsulation in a way we say not to do, they're on their own 17:09
plobsing must leave. shallow-merge functionality is somewhere under load_bytecode_sc.
whiteknight ok
thanks
ah, right. PackFile_append_pbc. I cleaned that very function up in my branch 17:12
17:15 plobsing left 17:35 fperrad left 17:37 JimmyZ left 17:42 theory joined, Kristaba joined
Coke hey, build is broken. 17:43
whiteknight building now 17:47
built fine. Running tests
Coke configure_args => '"--optimize" "--ccflags=-g -mtune=native" "--prefix=/Users/coke/bird" "--cc=ccache gcc"' 17:49
make: *** [runtime/parrot/library/PCT/PAST.pbc] Segmentation fault
whiteknight I dont have ccache 17:51
17:52 mikehh left
whiteknight I'm building with the rest of it 17:52
Coke should have no impact on the build except to speed it up.
nopaste "coke" at 192.168.1.3 pasted "building with g++ dies sooner:" (5 lines) at nopaste.snit.ch/28010 17:53
Coke 489709a 17:54
(that's where am I, which suspiciously says you fixed something in that file"
17:55 contingencyplan joined
whiteknight here's a fix 17:58
dalek rrot: 460a85c | Whiteknight++ | frontend/pbc_merge/main.c:
fix prototypes of config-related functions
whiteknight forgot to add the prototypes
thanks for the catch 18:01
szabgab @seen chromatic 18:09
18:10 davidfetter joined 18:11 fperrad joined 18:13 PacoLinux left
Coke whiteknight: I recommend installing ccache - should speed up your build a bit. 18:15
whiteknight: that fixed it, thanks. 18:16
18:17 PacoLinux joined
Coke there were warnings in the build on gcc for that file. that should help avoid those in the future. 18:18
18:20 dmalcolm left
cotto_work ~~ 18:28
18:39 plobsing joined
cotto_work What's an illegal option that that crashes pbc_dump and pbc_disassemble? 18:45
trac.parrot.org/parrot/ticket/1975 doesn't specify a test case. 18:47
plobsing --illegal should work
18:53 vmspb joined
cotto_work "./pbc_dump --illegal -t pbc_to_exe.pbc" complains and exits with a 0 return value for me. 18:53
18:57 cogno joined
plobsing cotto_work: that's because your platform is sane and puts null-padding after the struct (which, by happy accident is the way termination is signaled) 18:58
perhaps some people are not so lucky
cotto_work plobsing: ok. magical accidental correctness ftw. 19:00
19:02 fbrito left
szabgab anayone know at which time or where I might find chromatic on-line? 19:05
cotto_work szabgab: here's as good as anywhere. You could also email him. 19:06
szabgab I did that already a few days ago
19:10 vmspb left
dukeleto szabgab: you can always try a smoke signal 19:15
cotto_work He can be tricky to contact. 19:16
dukeleto cotto_work: you actually at work today? 19:19
cotto_work dukeleto: yup
dayjobs are like that
dukeleto: why do you ask/ 19:20
?
whiteknight we need a pcache program, like ccache but for Parrot bytecode
19:20 Themeruta joined 19:21 Themeruta is now known as NotFound_b
cotto_work whiteknight: sure. Just figure out how to properly invalidate the cache in all cases. 19:21
dukeleto cotto_work: 19:22
cotto_work: MLK day
cotto_work ah
yup. no holiday for me today
19:23 plobsing left 19:24 fperrad left 19:27 mikehh joined
whiteknight cotto_work: checking a file and doing an MD5 sum on it and it's .includes would suffice, probably also including in the full path name and version of the parrot executable which created it 19:30
if the user is doing something funny, we would have an option to manually invalidate the cache
jnthn .loadlib too maybe - change to an op lib could cause issues. 19:31
19:31 plobsing_ joined
whiteknight jnthn: But that would only effect the semantics of the compiled bytecode, not actually change what the PBC looks like 19:31
op #1234 is always op#1234, whether it does one thing or the other 19:32
szabgab dukeleto: I want to give money to the man, how hard does he make it to do it?
jnthn whiteknight: Not if the op's sig changes. :-) 19:33
Or if they get re-ordered in the ops file or... :)
19:33 cogno left
dukeleto szabgab: i will gladly accept money :) 19:34
szabgab: have you attempted to contact him on the twitterwebs?
cotto_work: i really don't like the look of 71fe1413bd1e739616b457adf5238c01777faae1 19:39
cotto_work: i think we should back out any changes to Parrot::Revision after 3.0 and some decent testing 19:40
cotto_work: the way it is trying to implement that is very inefficient
cotto_work: it also seems to go against "don't change anything other than docs/tests" before 3.0 19:41
cotto_work dukeleto: +1 19:44
whiteknight: what about libraries? 19:45
cotto_work is slow
dukeleto: do you have the tuits to back out those changes?
dukeleto cotto_work: yeah
cotto_work thanks
seen gerd 19:47
aloha gerd was last seen in #parrot 60 days 19 hours ago joining the channel.
dukeleto cotto_work: testing now to make sure i didn't break stuff worser 19:48
cotto_work whiteknight: I suspect that proper cache invalidation will end up being significantly more difficult than it first appears. I like the idea of pcache, but it'll need to be very careful to not mess things up or people won't trust it. 19:49
dukeleto++
dukeleto cotto_work: you might want to send another email saying "don't touch master unless something is on fire"
19:50 Khisanth joined
dalek rrot: 00c7f87 | dukeleto++ | lib/Parrot/Revision.pm:
Revert "counting commits to get a number similar a svn revision"

This reverts commit 71fe1413bd1e739616b457adf5238c01777faae1.
Conflicts:
  \tlib/Parrot/Revision.pm		 19:52
rrot: eddd548 | dukeleto++ | lib/Parrot/Revision.pm:
Revert "change release default to zero"

This reverts commit ebb7ec684db4dd1d96172f5031683ea67b106bf6.
dukeleto seems like new branches don't get announced by dalek
cotto_work dukeleto: yeah. I shouldn't be assuming that everyone will see the topic in #parrot.
dukeleto i pushed gerd's changes as the 'parrot_revision' branch
sorear: do you know if dalek has a bug where it doesn't announce new branches? 19:53
cotto_work: what kind of help do you need between now and the release of 3.0 ? 19:54
cotto_work dukeleto: probably not much. I have all the permissions bits I need.
whiteknight looks like darwin is failing one of the threading tests 20:00
whiteknight says something evil about threads, and something about how we should have deprecated them so we could rip them out once and for all
grumble grumble
cotto_work whiteknight: did they not get deprecated? 20:01
whiteknight windows has been persistently failing one of the dynop/debug.t tests, but I have no idea how to fix it
cotto_work: hardly the will of the community from the discussions we had on list
mikehh dukeleto: btw that commit ebb7ec6.. fails perlcritic (2 arg open [line 82]) was tryin' to fix that when you reverted it
dukeleto: how do you sort out a commit not pushed yet? 20:02
20:03 nwellnhof joined
sorear dukeleto: well, I wouldn't call it a bug... 20:03
dalek rrot: c81f8b4 | cotto++ | frontend/pbc_ (2 files):
fix pbc_dump and pbc_merge option processing, fixing #1975. patch courtesy of doughera++
 20:09
20:12 vmspb joined
mikehh t/configure/018-revision_to_cache.t - Failed test: 6 20:17
that's with Configure.pl --test 20:19
cotto_work right
We should fix that.
whiteknight Now is the time to put in any deprecation notices too, if there are any left that we want and people agree on 20:26
jnthn wonders whether anything on nqp-rx stuff should go in. 20:27
I think that the nqp-rx on 6model is going to have to be handled like the nqp => nqp-rx change. 20:28
That is, for a while we have two NQPs and people migrate as they wish.
But deprecating the current one is probably too early yet.
tadzik I can't wait til 3.0 is out and people start to merge their branches furiously :)
jnthn That is, we should have the new one actually available. 20:29
I think for some the migration will be painless, and for some painful.
20:29 ambs_ joined
jnthn wishes pmichaud++ was about to ask for thoughts 20:29
20:31 ambs left
dukeleto is very excited to see the post 3.0 branch-merge-a-thon, and observe how the smokers play their part 20:34
20:35 Util joined
whiteknight jnthn: I would be inclined to put in a deprecation notice to alert users that changes are on the horizon 20:35
20:36 ambs_ left
plobsing_ put in the dep notice, but mark it [eligible in 3.4] 20:36
whiteknight isn't it 3.5?
jnthn whiteknight: OK. I just worry about how useful it'll be to have something so generic.
whiteknight oh, wait
no I'm stupid
jnthn Oh, I don't think we'll be removing it that soon.
mikehh whiteknight: I thought the consensus was that before ripping it out we needed a replacement, not that it couldn't be deprecated
jnthn For one because Parrot itself has many dependencies on nqp-rx as it stands today
20:37 ambs joined
plobsing_ jnthn: 3.4 eligibility means that it could happen before 3.6. that's a full 6 months away. 20:37
jnthn *nod*
fwiw, my feeling is that I'll want new-nqp-rx to be used by a branch of Rakudo in 2-3 weeks time. 20:38
I expect things that ease the transition will come along beyond that point, mind.
cotto_work whiteknight: part of the reason nqp-rx is external is so that it doesn't need to deal with Parrot's deprecation policy. 20:41
dukeleto jnthn: that is exciting to hear
jnthn: but Parrot can use an older nqp-rx, since we choose which version of nqp-rx is used by Parrot internals 20:42
jnthn: does Rakudo have some kind of dev timeline, of when features are planned to be ready? 20:43
jnthn: it would be useful to compare a parrot and rakudo dev timeline, if they exist 20:44
and if they don't exist, maybe they should
cotto_work What's the proper fix for the failing configure test?
mikehh++ for catching that 20:45
20:45 dmalcolm joined 20:51 nwellnhof_ joined 20:54 simcop2387_ joined 20:55 TiMBuS|Away joined, ambs left, nwellnhof left, theory left, nopaste left, TonyC_ left, TiMBuS left, mberends left, Coke left, simcop2387 left, Util left, PacoLinux left, bacek left, tadzik left, Infinoid left, rblackwe_ left, NotFound left, dalek left, mj41 left, AzureStone left, sECuRE_ left, Kapace left, estrabd left, hatseflats left, frodwith left, confound left, simcop2387_ is now known as simcop2387, TiMBuS|Away is now known as TiMBuS, nwellnhof_ is now known as nwellnhof, plobsing_ left 20:57 TonyC joined, cxreg left, Coke joined, athomason left, Kovensky left
whiteknight mikehh: Right. I don't have a replacement in hand. I only want to get rid of the existing threads garbage 20:58
20:59 theory joined 21:01 nopaste joined 21:02 fbrito joined, Util joined, PacoLinux joined, bacek joined, tadzik joined, Infinoid joined, rblackwe_ joined, NotFound joined, dalek joined, mj41 joined, AzureStone joined, sECuRE_ joined, Kapace joined, estrabd joined, hatseflats joined, frodwith joined
mikehh dukeleto: I think you should also have reverted the previous commit by gerd on lib/Parrot/Revision.pm - 71fe1413bd1e739616b4... 21:04
cotto_work mikehh: that did get reverted 21:05
21:06 Kovensky joined, ambs joined, mberends joined
mikehh I think I need to do a clean clone maybe 21:06
21:08 athomason joined, cxreg joined
cotto_work mikehh: what's wrong with your clone? 21:09
It's unlikely you need to nuke it.
jnthn dukeleto: A Rakudo one doesn't especially exist. 21:10
dukeleto: I can try and come up with something perhaps.
21:11 confound joined
mikehh cotto_work: no it didn't, still got that counting stuff - lines 80 thru 87 21:15
cotto_work mikehh: you're right. It must have been a wacky revert. dukeleto, I don't think you reverted what I think you think you reverted. 21:18
whiteknight that word. I do not think it means what you think it means 21:19
cotto_work whiteknight: it's getting eerie how often you're thinking the same thing I am. 21:20
whiteknight :) 21:21
tadzik how urgent is the Deprecations as Data thing? 21:28
whiteknight has to leave. later.
21:28 whiteknight left
cotto_work tadzik: what do you mean? 21:29
Nothing's on fire because of it, but we do want to get it iterable as soon as we can. 21:30
tadzik cotto_work: I have quite a busy week and probably won't be able to do this before friday evening, so if that's urgent I can shamefully pass it to sb else
cotto_work Deprecations are more painful than they need to be.
tadzik: getting a start this weekend is fine. 21:31
tadzik fine then
. o O ( DEPRECATED.pod is deprecated )
cotto_work that'll be the day
actually, if all the data is in one place, we can automatically update the wiki 21:32
tadzik trac.parrot.org/parrot/ticket/1868 "in stead" => "instead" 21:33
cotto_work tadzik: it's not worth making trivial changes to tickets. Trac sends out a message with the old and new text, but no direct indicator of what's been changed. 21:35
tadzik bah, I see 21:36
well, it's not really painful anyway
cotto_work It's just annoying. 21:37
nopaste "mikehh" at 192.168.1.3 pasted "git diff with current lib/Parrot/Revision.pm and version before recent commits" (23 lines) at nopaste.snit.ch/28034
tadzik sure thing
cotto_work mikehh: thanks. That fixes the misrevert. 21:38
mikehh you want me to commit it? 21:39
cotto_work mikehh: not right now
dukeleto: ping
dukeleto: is there a nicer way to completely revert the Parrot::Revision changes than applying the patch from mikehh++ ? 21:40
mikehh anyway with that change t/configure/018-revision_to_cache.t passes again
cotto_work meant to wait for a pong before posting that
mikehh: yup
dalek rrot: d7fa575 | NotFound++ | t/pmc/string.t:
test String to_int with non alphanumeric char
 21:49
21:49 rurban_ joined, mikehh left 21:52 rurban left, rurban_ is now known as rurban 21:57 plobsing joined
cotto_work msg cotto Don't let nopaste.snit.ch/28034 get dropped on the floor before the release. 21:58
aloha OK. I'll deliver the message.
22:04 Kristaba left
moritz fwiw rakudo passes spectests on current parrot 22:07
22:10 mikehh joined
NotFound_b I fail to make sense of he dynoplib/trans.t integer_overflow_with_pow sub 22:16
It can't test in non 32 bit, and does nothing in 32 bits ? 22:17
If i comment the "if intvalsize == 4 goto end" statement, it fails a conversion to string. 22:18
22:22 ambs left
cotto_work moritz: thanks 22:26
bacek_at_work bacek@illusion:~/src/parrot$ make -C docs 22:43
make: Entering directory `/home/bacek/src/parrot/docs'
/usr/bin/perldoc -ud ops/bit.pod ../src/ops/bit.ops
Can't write-open ops/bit.pod: No such file or directory at /usr/share/perl/5.10/Pod/Perldoc.pm line 1497.
cotto_work, fulltest is broken.
cotto_work bacek_at_work: make -C docs wfm 22:44
bacek_at_work cotto_work, just remove docs/ops directory.
Or run "git clean -fd" 22:45
docs/ops directory isn't in git.
dalek rrot: 2420681 | cotto++ | lib/Parrot/Revision.pm:
Revert "counting commits to get a number similar a svn revision"

This reverts commit 71fe1413bd1e739616b457adf5238c01777faae1.
Conflicts:
  \tlib/Parrot/Revision.pm		 22:46
bacek_at_work cotto, false alarm. "git clean -dfx" solve problem. docs/doc-prep is ignored. 22:47
cotto_work is relieved
dalek rrot: ea2a249 | NotFound++ | t/dynoplibs/trans.t:
skip pow overflow tests in 32 bits instead of ignoring them
 22:50
p-rx/nom: f5e448a | jonathan++ | src/Regex/Cursor.pm:
To really get the benefits of 6model, we need to get Cursor etc into NQP. Plus it's just painful to not do so. :-) This is the start of that work. No doubt we'll end up with some chunks of PIR in the file too, but the ones done so far map very neatly to NQP.
 23:16
p-rx/nom: bf4218f | jonathan++ | CREDITS:
I probably contributed enough to nqp-rx/nom to have a CREDITS entry by now. :-)
23:17 pmichaud joined
bacek_at_work aloha, pmichaud 23:22
23:23 fbrito left
dalek p-rx/nom: 6677616 | jonathan++ | src/pmc/stable.pmc:
Ensure the method cache gets marked if present.
 23:32
p-rx/nom: 179a148 | jonathan++ | src/metamodel/how/NQPClassHOW.pm:
Get NQPClassHOW to publish a method cache.
bacek_at_work seen mikehh 23:34
aloha mikehh was last seen in msg 1 hours 23 mins ago <private message>.
23:34 kid51 joined
bacek_at_work msg mikehh Can you check it? $ prove t/dynoplibs/trans.t t/dynoplibs/trans.t .. Failed 40/111 subtests 23:34
aloha OK. I'll deliver the message.
kid51 Are we still getting delays upon hitting "Submit changes" on Trac pages? 23:35
NotFound_b bacek_at_work: that should have been fixed with my last commit 23:38
cotto_work kid51: what do you mean? trac doesn't support callbacks, so changes have to be polled via rss.
kid51 cotto_work: On Saturday (at least), OSU OSL was having problems reflected in (a) our inability to upload reports to Smolder; (b) sluggish response when filing posts on Trac tickets. 23:41
I filed two bug tickets with OSU OSL; they want to know if the latter has been fixed.
bacek_at_work NotFound_b, ah, thanks. pulling 23:47
NotFound_b, confirmed :)
aloha, taptinder? 23:49
aloha bacek_at_work: taptinder is continues integration tool - taptinder.org . For Parrot project running on tt.taptinder.org/ and reporting build failures to #parrot channel as ttbot.
23:50 contingencyplan left
kid51 msg dukeleto Reading backscroll. Yes, I agree that there should not have been changes in Parrot::Revision this close to 3.0. 23:54
aloha OK. I'll deliver the message.
kid51 msg plobsing Yes, your patch fixes t/dynpmclibs/trans.t (on the one box I have access to at the moment). Thanks. 23:56
aloha OK. I'll deliver the message.
cotto_work kid51: I talked with them on Saturday and they were very helpful in getting trac and drupal fixed. I didn't know about smolder. 23:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!