Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | trac accounts are wonky; talk to cotto, coke or whiteknight if you have trouble
Set by moderator on 10 May 2011.
whiteknight (and it's a mess because we might tailcall into IMCC, and IMCC treats the interp as it's own personal dumping ground) 00:00
plobsing whiteknight: I thought it didn't do that anymore. 00:01
whiteknight plobsing: it might not, but I'm not prepared to remove any of that safety code
plobsing: I think it still does, especially for :immediate and that kind of stuff 00:02
plobsing IMCC calls into libparrot to manage :immediate and :postcomp. if those screw things up, that's parrot's fault. 00:03
whiteknight I have to look at it all again
actually, IMCC isn't an NCI PMC anymore
so the issue might be moot 00:04
NotFound If :immediate messes with the current context, it should stopping doing it and create its own.
whiteknight although IMCCompiler uses that tailcall code
NotFound :immediate invocation in imcc, I mean.
whiteknight we can try removing that. It hasn't been high on my priorities list
NotFound I'm sure :immediate invocation should not be speed-critical in any reasonable parrot usage. Optimizing by complicating other parts is not right. 00:07
whiteknight Sub.invoke perplexes me
why is the lexical/autoclose logic in there?
and the lexpad stuff?
I feel like setting up lexicals and outers should be done by the invoke opcodes, and be in place before we ever get to Sub.invoke 00:08
like chromatic points out, eventually we will want to have multiple types of invokable PMC, and we will want that logic factored out 00:09
00:11 theory left, theory_ joined 00:13 kid51_at_dinner is now known as kid51, theory_ left, theory joined
kid51 does cage cleaning on recent trac tickets 00:13
whiteknight brb, have to restart the computer 00:14
00:14 whiteknight left 00:18 whiteknight joined, spinclad joined 00:19 lucian_ left
plobsing We also want to slim down our Sub PMCs. They're a convenient place to hang all sorts of innappropriate info, so they're overly bloated 00:20
whiteknight plobsing++ I couldn't have said that any better myself 00:21
sorear what's worse is that the clone/capture_lex combo copies the entire structure
kid51 seen moritz? 00:22
aloha moritz was last seen in #perl6 3 hours 14 mins ago saying "of course web frameworks can help you with it".
plobsing sorear: our subs are 23 machine words in size and track information like "the vtable slot that this sub should go in" 00:27
oh misparsed
00:28 theory left 00:32 jsut joined
whiteknight is extremely impressed by Unity and Ubuntu 11.04 on first blush 00:32
kid51 Hmm, I'm wondering whether our current Trac problems mean that people who no longer have current passwords will not receive email notifications of additions to tickets (e.g. "cc"; e.g. new posts to tickets they originally created). 00:33
00:37 jsut_ left
NotFound Looks like :call_sig is not handled well in the caller side. 00:40
whiteknight NotFound: I did the initial implementation of :call_sig, and I know it's not good 00:41
it was a quick prototype and we never went back to improve i
NotFound I mean, not handled at all.
00:41 Coke left 00:42 Coke joined
NotFound Uh... /* EXPERIMENTAL! This block adds provisional :call_sig param support on the callee side only. 00:42
We have ben warned ;)
whiteknight heh, I know it's ugly 00:44
I spent a whole 10 minutes on it
NotFound param_count - 1 isn't always 0 in that branch, or I'm misreading something? 00:47
whiteknight NotFound: if we have :call_sig, it should be 0. You can only have :call_sig, no other parameters 00:48
I think we check that in IMCC, which is bad
NotFound whiteknight: it is in the esle part of: if (param_count > 2 || param_count == 0) 00:49
else
Oh, never mind. 00:50
whiteknight I don't know
NotFound It may be an invocant in case of method calls.
00:50 jsut_ joined
NotFound I've misread > as >= 00:51
Eh, no... I just need to sleep %-) 00:52
whiteknight :)
that code is terrible, don't read it too hard
NotFound The point is, without support in the caller side we can't do proof of concept.
whiteknight we can do half. We can do it on the callee side 00:53
NotFound Well, we can, by adding an indirection, giving less meaning to the tests.
Testing only the callee is almost trivial. 00:54
function test(args[call_sig])
{
say('test');
say(args[0]); 00:55
}
whiteknight this proof of concept would only prove that the mechanism works. It doesn't show us speed because we still use a signature and still hit fillparams
fill_params
00:55 jsut left
NotFound whiteknight: but it will show if filling the params with pir ops is fast enough. 00:55
whiteknight true. It shouldn't be any slower 00:56
I want to add a 2-argument invokecc opcode to take a CallContext, and then we can start doing real tests 00:57
NotFound And the support in the caller can bypass fill_params almost completely, like it does for the callee side.
whiteknight and I can add in a get_call_context op for the callee
if we hand-roll the callee, we don't need to use get_params
NotFound An experimental op will be fine, yes.
And I can add experimental support to winxed. 00:58
No need to touch imcc. 00:59
For basic tests, I mean, not for testing nqp or rakudo. 01:00
Stupid idea of the day: add a winxed backed to pct ;) 01:01
Definitely need sleep. Bye. 01:02
whiteknight goodnight 01:03
kid51 Can anyone speculate as to why certain tests fail with a "Dubious" exit status when run under 'make test' -- but not under 'prove', 'perl t/harness' or even a smaller test target such as 'make dynoplibs_tests'? 01:05
whiteknight kid51: Dubious usually means a non-zero exit code 01:08
and exit codes are not printed by default, so you wouldn't know if you ran it directly
kid51 Why should the test file exit with a non-zero code when run under, say, 'make smolder_test' but not under 'prove' or 'make library_tests'? 01:09
whiteknight oh. good question 01:10
kid51 I should note that I encounter this problem (a) on Darwin/PPC;
(b) on files I suspect touch GC heavily;
whiteknight does anything else change? Any tests fail in that file?
kid51 (c) but on different files at different commit points.
For example, tonight, at head, under 'make smolder_test', t/compilers/opsc/02-parse-all-ops.t reported: Non-zero wait status: 11; Parse errors: Bad plan. You planned 19 tests but ran 9. 01:11
But I get all PASS when run individually under 'prove' or as part of 'make library_tests'
Last night, it was a different file (lemme think which) 01:12
t/compilers/pge/p5regex/p5rx.t
01:13 woosley joined
kid51 In the case of t/compilers/pge/p5regex/p5rx.t, it was the first bad result I'd ever seen from this file. 01:13
t/compilers/opsc/02-parse-all-ops.t, in contrast, is the mother of all GC test files. Takes forever on this box, but has consistently PASSed for a long time. 01:14
01:14 cotto joined
cotto ~~ 01:15
whiteknight gen::makefiles - Generate makefiles and other build files...value for '@cc_build_call_frames@' in config/gen/makefiles/root.in is undef at lib/Parrot/Configure/Compiler.pm line 572, <$in> line 95. 01:18
wtf?
kid51 whiteknight: There were changes in last 24 hours that might have generated that.
whiteknight blah 01:19
I just updated ubuntu too. I've already had a version problem with my ICU install
kid51 Perhaps 3f4486932fa, whose log message reads: eliminate unused buildframes code (this is now handled by libffi) 01:20
whiteknight and I'm seeing that problem with errno.h again 01:21
kid51 whiteknight: Problem confirmed. I just looked at my last Configure output
whiteknight blah. I really wanted to start looking at some PCC stuff tonight, but now I have to twiddle files around to make parrot build 01:22
kid51 It's probably the commit I cited. The commit immediately before that has Configure.pl running clean 01:23
(However, this problem did not prevent me from building tonight on either linux or darwin.)
YMMV
dalek TT #2105 closed by jkeenan++: New build failure on darwin/PPC at runtime/parrot/library/YAML/Tiny.pir 01:24
TT #2105: trac.parrot.org/parrot/ticket/2105
kid51 Trying a correction 01:25
whiteknight: pull 01:35
dalek rrot: 650471b | jkeenan++ | config/gen/makefiles/root.in:
Remove reference to cc_build_call_frames, which probably should have been done along with other recent work on frames. Configure.pl once again runs cleanly.
rrot: 5893e91 | Whiteknight++ | frontend/parrot/main.c:
We don't have a -p option
 01:38
whiteknight configing now
yes, work
works
kid51++
dalek TT #2109 created by whiteknight++: Can't find asm/errno.h 01:40
TT #2109: trac.parrot.org/parrot/ticket/2109
whiteknight is going to bed now. Goodnight 01:44
01:44 whiteknight left 01:58 frodwith left 02:01 frodwith joined
Coke_ msg mj41 started. 02:02
aloha OK. I'll deliver the message.
02:03 mtk left
dalek rrot/m0-prototype: 43a14dc | dukeleto++ | src/m0/m0_assembler.pl:
Refactor writing of bytecode to a documented function
 02:06
rrot/m0-prototype: dfd717c | dukeleto++ | src/m0/m0_assembler.pl:
Add a stub to_bytecode function which takes a line of M0 and returns the bytecode representation
cotto dukeleto++
02:09 Andy joined
dukeleto Andy: slightly OT, but can you release a new version of Test::WWW::Mechanize? The latest release on CPAN fails tests, but them seem to be fixed in svn 02:11
s/them seem/they seem/
02:11 mtk joined
Andy I did. 02:11
Today
dukeleto Andy!
Andy yes?
dukeleto Andy++ # /me goes back in his cave
Andy and it's not in svn any more. IT's on github. 02:13
cotto Mmmmm. Future. 02:16
bacek_at_work ~~ 02:20
kid51 And with my most recent git pull, yet another different file borks early under 'make smolder_test' on Darwin/PPC. This time it's t/library/yaml_tiny.t. 02:27
ingy o/ 02:31
02:32 theory joined
dalek rrot: f29f90c | petdance++ | src/call/args.c:
Removed unused variables
 02:33
rrot: 9b2ad7c | petdance++ | / (2 files):
Merge branch 'master' of github.com:parrot/parrot
Andy bah
bacek_at_work Andy, git config branch.master.rebase true ? 02:42
Andy I always do --rebase 02:43
bacek_at_work hmm 02:44
why then do you have merge commits?
Andy I don't know.
ttbot Parrot 9b2ad7cb MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/2372
Andy Hmm, shouldn't that update my ~/.gitconfig 02:45
plobsing I have an alias that does 'pull --rebase'. That seems to work for me. 02:53
how did that change break the build? it boggles the mind. 02:59
bacek_at_work plobsing, same GC failure is reported by kid51++ for Darwin/PPC. Someone does't WB properly... I'll try to look at it tonight. 03:03
03:12 benabik joined 03:13 kid51 left 03:16 hudnix left 03:31 ShaneC1 joined
dalek rrot: 8628ca5 | petdance++ | / (2 files):
fix an arg annotation
 03:44
03:45 ShaneC1 left
ttbot Parrot 8628ca58 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/2532 03:55
Andy Anyone got guesses why this diff github.com/parrot/parrot/commit/f2...d1a0861985 which only removes unused vars would cause this failure tt.taptinder.org/cmdinfo/2401 04:06
plobsing Andy: bacek guesses it has to do with write barriers.
I'm tempted to believe that.
Andy What is a write barrier 04:07
plobsing it is a necessary part of generational GC
it is somewhat analogous to incref/decref operations in a reference counting scheme 04:08
if a reference from an object in an older generation to an object in a younger generation, the old-gen object has to be marked as "dirty" (which makes it a part of the rootset when only GCing the young generation) 04:09
04:11 soh_cah_toa left
Andy my guess is that const INTVAL named_arg_count = h->entries; causes linkage tohappen. 04:11
plobsing linkage? 04:12
Andy tt.taptinder.org/cmdinfo/2401 04:13
that removing that causes the link failure
vs. the unused stack vars.
plobsing that isn't a link failure 04:14
that's a segfault int parrot-nqp.exe
there are some link *warnings*
dalek rrot/get-entropy: f71bf5d | cotto++ | / (3 files):
add Parrot_platform_get_entropy implementations for generic and win32

The generic code relies on /dev/urandom, which seems to be common enough. The win32 code relies on MS' Cryptograph API and needs testing.		 04:15
rrot/get-entropy: 77191d6 | cotto++ | src/interp/inter_create.c:
initialize Parrot's prng from system entropy
04:16 benabik left
Andy plobsing: What in there tells you its a segfault? 04:16
ooh ooh, it's not trying to make parrot-nqp 04:17
make is using parrot-nqp,which segfaults.
plobsing bingo
Andy and only on Windows which I can't do anything with
plobsing Andy: we've been seeing failures are Darwin/PPC as well 04:18
Andy I have no darwin
plobsing go fish
Andy I mean, no PPC
ooh wait, I might
I think Quinn's mini is ppc
cotto anyone on windows mind testing that branch? 04:19
Andy Maybe I"ll try running that build step for nci_test under splint 04:21
I'm gonna splint on nci_test.c 04:23
plobsing I'm fairly sure none of the steps to build libnci_test use parrot-nqp. I think make has moved on or is working in parallel.
Andy waaah 04:25
plobsing and the darwin/ppc errors don't necessarily present in the same locations. 04:26
they tend to move based on apparently unrelated changes
Andy Are the functions in nci_test.c supposed to be unused anywhere else in the codebase? 04:27
Is that the nature of the testing?
plobsing yes. To my knowledge, they are only used by t/pmc/nci.t
Andy splint is unhappy about nci_ttt() but I find it not used anywhere
indeed, no ttt anyway 04:29
anywhere
plobsing what does it find objectionable?
Andy sprintfing into a potentially-NULL buffer 04:30
What I find objectionable is sprintfing into a string and pritnfing it
but I'm not seeing it used anywhere 04:31
plobsing Andy: it doesn't *only* printf it, it also returns it
Andy so it does
i'm just seeing if I can yank it entirely. 04:32
as a leftover
plobsing I'm betting it is
Andy it is what? A leftover?
plobsing yep.
In fact, I have good evidence that it is. It isn't cited as an export by libnci_test.def, meaning it isn't an exported symbol on win32 04:33
Andy Yanking it. 04:37
(testing first)
dalek rrot/get-entropy: ccf2d6a | cotto++ | src/string/api.c:
use system entropy for hash seed randomization
 04:44
rrot: 570ced6 | petdance++ | src/nci_test.c:
Dropped used nci_ttt function. Consted some local vars, and updated argument annotations in function delcarations
 04:45
04:50 bubaflub left
cotto plobsing, I'd like to know your thoughts on the get-entropy branch. It seems like the kind of thing you'd know more about than I do. 04:52
04:53 eternaleye_ joined, eternaleye left
plobsing cotto: it looks like a good start. I'd like to see some error checking. 04:54
Also, I am not aware of any OS standard (well, the linux FHS probably) that defines where in the file system a random device should be found 04:56
so that is a point of concern
ttbot Parrot 570ced68 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/2680 04:57
sorear there's naturally no inter-OS standard 04:58
cotto plobsing, I looked around and /dev/urandom seemed to be very common
sorear on Linux it's *always* /dev/u?random
devfs is dead
cotto Error handling is tricky. The code is used during interp init. 05:00
05:01 pjcj joined
plobsing cotto: an impolite bail is better than a silent fail-and-continue 05:01
if the operation consistently fails, we will likely get a constant random seed (most likely 0) 05:02
dalek rrot: b4be648 | petdance++ | config/gen/makefiles/root.in:
splinting nci_test.c is OK
cotto plobsing, I guess so 05:03
05:03 elmex_ joined
plobsing sorear: even on GoboLinux? 05:03
05:05 TiMBuS|Away joined 05:06 Hunger left, elmex left, TiMBuS left, TiMBuS|Away is now known as TiMBuS, elmex_ is now known as elmex, Hunger- joined 05:07 eternaleye_ is now known as eternaleye 05:08 Andy left
tadzik plobsing: yes 05:12
"Through a mapping of traditional paths into their GoboLinux counterparts, we transparently retain compatibility with the Unix legacy"
ttbot Parrot b4be648b MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/2740 05:14
05:25 birdwindupbird joined 05:49 alh left 06:05 dngor_ joined, GeJ_ joined, cxreg2 joined, autark_ joined, jtpalmer joined, jsut joined 06:06 dngor left, cxreg left, jsut_ left, sjn left, rblackwe_ left, jtpalmer_ left, KaeseEs left, autark left, GeJ left, KaeseEs joined 06:10 sjn joined 06:24 TiMBuS left 06:25 athomason left 06:29 TiMBuS joined 06:31 cxreg2 is now known as cxreg
dalek rrot: 715d913 | NotFound++ | / (2 files):
Make parrot_iterate_hash more consistent by always expecting a semicolon after it
 06:33
06:34 athomason joined 06:38 TiMBuS left, TiMBuS joined 06:48 ShaneC joined
NotFound Given that ttbot has been silent for some time, I'll assume 715d913 fixed the problem. 07:00
bacek_at_work But how??? 07:06
NotFound bacek_at_work: either do a web search for 'do while(0)' or accept it as white magic ;) 07:15
07:15 mj41 joined
bacek_at_work Magical Coding Robots do not believe in magic! Oh, wait... 07:15
NotFound In short: macros intended to be used as statemente are tricky. 07:17
bacek_at_work Ookey. 07:18
NotFound For the details you'll need to expand its usages by hand or with cpp help... which I didn't. 07:19
And to understand why it failed only on some platforms... I give up.
07:40 theory left 07:43 SHODAN joined 07:46 rurban_ joined 07:47 alh joined 07:48 rurban left, rurban_ is now known as rurban 08:57 dod joined
bacek ~~ 09:40
09:52 mtk left 09:58 mtk joined 10:19 contingencyplan left
dalek rrot: 81c9e6b | bacek++ | include/parrot/context.h:
Provide optimized definitions for Parrot_pcc_foo functions.

It was obvious leftovers from GMS implementation branch. valgrind++ for pointing out.		 10:36
ttbot Parrot 81c9e6b8 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3121 10:46
10:50 woosley left
mikehh bacek: you done broke it again :-} 10:52
bacek mikehh, meh... It's flacking failure. Same as all other GC fails
mikehh bacek: 759d13 was probably just luck 10:56
bacek mikehh, indeed
11:02 Psyche^ joined
dalek rrot: e744d10 | bacek++ | src/gc/gc_gms.c:
Fix off-by-one error in selecting generation to collect.
 11:03
11:07 Patterner left, Psyche^ is now known as Patterner
ttbot Parrot e744d10b MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3181 11:13
mikehh What is fatal error U1077
bacek "segfault" I think 11:15
SHODAN is there a way for a mere mortal to comment on a ticket? trac.parrot.org/parrot/ticket/2107 for example.
bacek SHODAN, did you register in trac? 11:17
SHODAN just did
(and couldn't find a way to comment) :)
mikehh bacek: looks like a nmake error - can't find something in include path
bacek SHODAN, yes. We have to disable trac activity for "fresh users" few weeks ago due abnormal spam activity. Just msg whiteknight/coke with your trac id. They can whitelist you. 11:19
mikehh, return code 0xc0000005 is segfault. nmake is just not smart enough to report absence of YAML/Tiny.pir properly. 11:20
SHODAN i see
bacek SHODAN, sorry for inconvenience. 11:22
mikehh bacek: so it is segfaulting building YAML/Tiny.pir - that is/was yours no? 11:33
bacek mikehh, I'm not sure who is responsible for this fault. But most likely it's me. 11:34
moritz finds "who fixes it?" much more interesting than "who broke it?" 11:35
mikehh bacek: I take it you don't have a Windoze machine to test this on (me either)
bacek mikehh, nope 11:36
mikehh moritz: yeah - not trying to cast any blame, just trying to track down the fault 11:37
with neither bacek nor me having windoze platforms, it becomes that much more difficult 11:39
moritz I understand, yes 11:40
mikehh anyway have just installed Ubuntu 11.04 i386 (again), built perl 5.14.0 and am now going to test parrot on it :-} 11:43
11:48 KaeseEs left 11:54 KaeseEs joined 12:07 dngor_ is now known as dngor 12:12 ambs joined 12:13 lucian joined 12:18 bluescreen joined 12:19 bubaflub joined 12:24 PacoLinux_ joined
bacek msg pmichaud I've got bad feelings that recent changes in rakudo slowed down "gcd" again. 12:28
aloha OK. I'll deliver the message.
12:29 hudnix joined
bacek aloha, (191-184)/192*100 12:29
aloha bacek: 3.64583333333333
pmichaud bacek: did gcd change since my last set of patches yesterday? 12:36
pmichaud looks at commit log
bacek pmichaud, I comparing your initial commit for improve gcd with master (which adds few gcd related multisubs) 12:37
But I can be totally wrong. 12:38
pmichaud the gcd operators are definitely faster than what we had in master as of 48 hours ago
~16% faster on my box
however, sin.t could still be slower than what we had in the 2011.01 release 12:39
I didn't have callgrind numbers for 2011.04 to work from to be able to decide if the problem was just since 2011.04 or perhaps from farther back
gist.github.com/966698 # results of gcd changes -- rakudo-work is the version with the changes 12:41
afk, taking kids to school. bbiab
12:42 redicaps joined
bacek pmichaud, gist was done on your original commit to fix gcd. It was few commits after related to it. 12:43
12:53 PacoLinux_ left
pmichaud I suppose it could've slowed down because of the multi 12:53
I'll check that
12:56 PacoLinux_ joined
pmichaud (re gc and speedup) I suspect you're correct about gc on my box. What we've been able to show is that in situations where gc dominates (boxes with smaller memory footprints, or programs that generate lots of gcables), the gms gc is now a big improvement over what existed in 2011.01. That's good work. (more) 12:58
In other words, gc is no longer the bottleneck it was in 2011.01. To get more speedups, we can start looking at other pieces of the puzzle and not just say "oh, it's the gc slowing us down". 12:59
so, bacek++ bacek++
moritz points to PCC
pmichaud yes, I suspect PCC is a big culprit.
13:00 whiteknight joined
dukeleto ~~ 13:01
whiteknight good morning, #parrot
pmichaud good morning, whiteknight
whiteknight hello pmichaud, dukeleto
pmichaud sorry for flooding your ticket (re errno.h) with replies last night :) 13:02
whiteknight pmichaud, no worries. That's what I get for filing a ticket right before I sign off and go to bed 13:03
atrodo whiteknight++ The PCC blog had some good info
dukeleto whiteknight: mornin'
whiteknight atrodo: my goal for today is to put together a mini benchmark to prove it
dukeleto whiteknight: i also read your PCC blog post and enjoyed the thoroughness of explanation :)
moritz url? 13:04
dukeleto cotto++ # entropy branch
whiteknight atrodo: unfortunately, I have to use PASM to avoid the PIR-mandated infrastructure
atrodo whiteknight> Some of the choices you went over left me curious why it had been done that way 13:05
whiteknight> For instance, the CallContext as a part of the interp, is that left over from previous refactors or was that a designed feature? 13:06
moritz ah, whiteknight.github.com/2011/05/11/p...ments.html
pmichaud bacek: you're correct, the additional multis slow rakudo down slightly: gist.github.com/968447
whiteknight atrodo: most of it is a hold-over
the last round of PCC refactors was a herculean task, and we didn't clean up everything that needed cleaning
plus, we didn't want to break too much backwards compatibility
atrodo whiteknight> Makes sense. So how was it done before the refactor? Did the refactor create CallContext? 13:07
whiteknight atrodo: before the refactor, there were at least 3 different code paths for different types of invocation. There was no CallContext 13:08
All the functions labeled "Parrot_pcc_" didn't exist
atrodo whiteknight> So how were the arguments passed? 13:09
moritz "In short, we have plenty of information available at compile time, but we discard it" 13:14
that's what hurt(s) rakudo too
pmichaud I envision a potential problem with the proposed refactor 13:16
although I guess it must be handled already somehow/somewhere 13:17
dalek rrot: a7862a2 | mikehh++ | src/nci_test.c:
fix =item after consting
rrot: 42b1d80 | mikehh++ | src/gc/gc_gms.c:
fix codetest failure - trailing spaces
rrot: 6456502 | mikehh++ | include/parrot/context.h:
fix codetest failure - c_parens

there should be at least one space between a C keyword and any subsequent open parenthesis
pmichaud is CallContext able to store native types in the positional and named slots?
whiteknight pmichaud: yes, it handles native types without boxing 13:19
otherwise the situation would be even worse
pmichaud so, even in the new scheme, CallContext still has a "signature" that keeps track of the types of the things in each slot
but there'd be only one, set up when the CallContext gets values stored into it 13:20
i.e., if my call context is $P9, then $P9[2] = 4 sets a flag in the CallContext so that we know that the 3rd positional slot contains an int 13:21
whiteknight CallContext still has internal bookkeeping stuff, yes. PCC uses an entirely separate set of signature PMCs
pmichaud got it
whiteknight so we have a signature PMC and a separate CallContext PMC, then a handful more temporary PMCs to deal with both of them
dukeleto whiteknight: i particularly don't like that there are multiple types of signature PMCs
whiteknight and temporary strings to lookup signatures *by name* in CallContext 13:22
er, it looks up attributes by name
dukeleto just crafted an email begging for somebody to look into getting our trac usernames+passwords back
moritz in a hash?
pmichaud anyway, fwiw, Rakudo already does the new model on the callee-side of things
whiteknight moritz: No. A chain of if(STREQ(...)) checks to get the attribute by name 13:23
moritz hm
whiteknight pmichaud: exactly. That's how I know that it works AND it's what users really want
pmichaud i.e., our subs have a single :call_sig parameter, and then we have a specialized opcode to unpack it the way we need based on whatever's in the CallContext
whiteknight: correct :)
whiteknight If we have the decision between Parrot implementing the semantics in a way that nobody wants, or Parrot exposing the primitives to the user to implement those semantics themselves.... 13:24
pmichaud +1. That's kinda what we (Rakudo) argued a long time ago.
whiteknight even without performance savings, which bacek doubts, we still give much win to the users
moritz our code is license compatiable with your code (hint, hint) :-) 13:25
*compatible
whiteknight moritz: :) It's more a matter of Parrot ripping bad code out than borrowing your good code
There are inefficiencies inherent in your implementation that we can reduce
moritz well, rakudo needs some weird stuff that parrot doesn't need 13:26
like, filling positional parameters by name
ttbot Parrot 42b1d800 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3257
whiteknight yes, so we'll expose the CallContext to you directly, and you do whatever with it that you want
or even provide a subclass of CallContext, or something different entirely 13:27
what you pass to a subroutine is no business of mine
pmichaud whiteknight++ # excellent blog post 13:28
whiteknight pmichaud, thanks! I sincerely hope some of these ideas pan out
pmichaud now let's see if I can grok valgrind and get the call numbers bacek++ was producing 13:29
atrodo I'm not a fan of magic that assumes it knows what the end-user wants 13:33
whiteknight> And actually, your proposed change is in line with what I had been working towards for Lorito
whiteknight atrodo: I've been thinking about these suggestions specifically with Lorito in mind
atrodo whiteknight> I think the current m0-spec has argument passing done with registers 13:37
dukeleto atrodo: argument passing to what? 13:39
atrodo dukeleto> Between methods 13:40
dukeleto atrodo: well, i would say that a continuation is passed along, but yes, the continuation boils down to registers
pmichaud ooc, is there a reason we want/need a separate CallContext PMC? 13:41
would it make sense to make all of the argument passing stuff a part of the Context PMC?
hmmm, probably not, because of CPS and coroutines 13:42
nm
(and continuations)
atrodo pmichaud> Perhaps I'm missing the difference between CallContext and Context 13:43
pmichaud Context holds the registers and information for a currently executing Sub
iiuc, CallContext just holds the information for an invocation of a sub
I'm sure I have my names wrong anyway... too early in the morning, too many other things going on 13:44
afk, traveling across town 13:45
bbl
dukeleto in M0, we are going to take things that shouldn't be in the interp object and put them in the current context, where they belong 13:46
interps will still hold a small collection of truly global state info, tho 13:47
whiteknight do we have a Context PMC? 13:49
I don't think we have a separate Context
Lorito might separate that out
atrodo whiteknight> What do you mean? 13:50
whiteknight We only have a CallContext PMC. There is no separate Context type
atrodo whiteknight> I see what you're saying. That's a good question 13:51
mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_3_0-214-g6456502
Ubuntu 11.04 i386 (g++)
13:52 JimmyZ joined
mikehh that is with perl 5.14.0 13:52
13:52 JimmyZ left 13:53 JimmyZ joined
ttbot Parrot 64565020 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3357 13:53
mikehh I get a deprecation warning in pre-/post-config tests:
Use of qw(...) as parentheses is deprecated at config/init/defaults.pm line 305.
6 times and once in config 13:54
dukeleto mikehh: interesting. which version of perl ? 13:55
mikehh otherwise perl 5.14.0 looks good with parrot - have not tested some of the /tools/dev progs 13:56
dukeleto mikehh: sounds like a new deprecation
mikehh I just did a fresh install of Ubuntu 11.04 and built perl 5.14.0 on top of it and have just now built and tested parrot using it 13:57
it seems to be in perldelta.pod
it is still on RC3 13:58
of course Ubuntu is still on perl 5.10.1 :-{ 13:59
14:00 rj_ac joined
mikehh I am still on perl 5.12.3 on my Kubuntu/Ubuntu 11.04 amd64 14:04
14:06 JimmyZ left 14:13 JimmyZ joined 14:17 JimmyZ left
NotFound whiteknight: thinking about hand decoding call_sig, a posiible slowdown is the distinction between a named optional unfilled and filled with a new value need several ops. 14:21
s/new/null
14:29 redicaps left 14:31 lucian left 14:33 woosley joined, woosley left 14:38 simcop2387 left 14:39 PacoLinux_ left 14:47 SHODAN left 15:00 SHODAN joined 15:04 SHODAN left 15:05 theory joined 15:10 darbelo joined 15:15 lucian joined 15:18 SHODAN joined, davidfetter joined 15:27 PacoLinux_ joined 15:29 PacoLinux_ left 15:30 PacoLinux_ joined
cotto ~~ 15:30
dalek rrot/whiteknight/pcc_prototyping: b2cae51 | Whiteknight++ | / (5 files):
Add in a few new opcodes required for my PCC refactors idea. invokecc_p_p, new_call_context_p, and get_call_context_p. I'm working on a writeup now to discuss why these would be necessary to replace set_args, get_params, set_returns and get_results
 15:38
15:39 SHODAN left 15:46 rurban_ joined 15:48 rurban left, rurban_ is now known as rurban
dalek p: d846b25 | moritz++ | src/Regex/P6Regex/Grammar.pm:
more awesome error message for unrecognized meta character in regexes

not quite awesome yet, it does not report the actual offending character		 15:50
atrodo whiteknight++ 15:51
cotto I suspect that watching MacGuyver may not be the best thing for my code. 15:53
atrodo cotto> What's the worse that could happen. Remember, MacGuyver's hacks always worked and never had side effects 15:54
15:56 benabik joined
benabik ~~ 15:59
cotto Did someone get NotFound access to his trac account? 16:00
dalek rrot: 4f65ae6 | mikehh++ | config/init/defaults.pm:
add parentheses around qw(...) to avoid deprecation warning in perl 5.14.0
rrot/m0-prototype: ec14582 | dukeleto++ | src/m0/m0_assembler.pl:
Generate less wronger M0 bytecode
 16:03
benabik I managed to get into my Trac account by asking for a new password... 16:05
16:07 alester joined
alester dukeleto: Are you using the new TWMech OK? 16:08
whiteknight atrodo: You like some of those timings? It's good validation
atrodo whiteknight> what timings?
whiteknight> Ah, new blog. I was giving you karma for the branch 16:09
whiteknight atrodo: Oh, I thought you were ++ing my latests blog
:)
cotto benabik, some users don't remember which email they set for password recovery (if any)
atrodo whiteknight++ that too
benabik cotto: Well, that would be a problem yes.
16:10 dodathome joined
ttbot Parrot 4f65ae6b MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3425 16:10
NotFound I think I set it, but I'm not completely sure. 16:11
cotto dukeleto, I don't think the M0 assembler needs to do as much work as you think it does. 16:12
16:17 mj41 left
atrodo whiteknight> So thinking outloud, how would this change hll interop? 16:17
dukeleto alester: haven't tried the newest version, yet. Will let you know. 16:18
16:20 simcop2387 joined
dukeleto cotto: please explain 16:20
Coke_ shodan, userid? 16:26
16:26 PacoLinux_ left
cotto dukeleto, cotto_work will. 16:26
16:26 cotto left
Coke_ I'm happy to play tracadmin, but need trac IDs in order to assign privs. Ping me if it's still an issue. 16:28
whiteknight atrodo: Good question. Right now it's the wild west. Parrot tries to provide a system, and if you don't like it (how Rakudo doesn't) you provide your own 16:32
atrodo, in my system, the only interface is that you put parameters into the CallContext, and the recipient unpacks it however they want
16:33 bluescreen left
whiteknight and if you do it that way, there's no reason why CallContext even needs to contain the actual values. It could just contain references to the registers where those values are held 16:36
or CallContext could be lazy, and not load values until they are unpacked
dukeleto BREAKING NEWS FROM OSL 16:38
whiteknight something like Javascript's arguments[] array becomes trivial to implement. "arguments" is just an alias over the CallContext
dukeleto they have restored our trac htpasswd file from a backup 16:39
NotFound whiteknight: note that javascript has no named parameters.
dukeleto and the version we have been modifying is now called parrot.htpasswd.bak is the same directory.
benabik dukeleto: woo!
whiteknight NotFound: right
dukeleto which means people can go back to their passwords before the madness 16:40
NotFound dukeleto: verfied, I'm logged now.
People actually do backups? I'm amazed ;) 16:42
I thought they were an urban legend.
Or even pre-urban.
benabik whiteknight: re blog: is a two argument invoke basically call/cc and three arg tail recursion (i.e. never comes back to here)? 16:43
atrodo whiteknight> So if js doesn't have named params, how would they get named params?
whiteknight benabik, right now we have invokecc (1 arg) and invoke (2 args). invoke takes a sub and a return continuation
atrodo Although, that probably doesn't change with the new callcontext
whiteknight benabik, I think we could condence down to a single invoke op with 2 or 3 args. The optional third arg would be the return continuation
atrodo, if javascript doesn't have named params, they wouldn't be generating code to access them 16:44
benabik whiteknight: If you have "invoke sub, contination" then "say 'Hi'", the code never prints anything because it never comes back, right? (Just trying to be certain I have the structure right.)
whiteknight: It invokes the continuation at return instead of coming back to after the invoke.
whiteknight atrodo: If they wanted to be able to receive named args from code written in a different language, they could add a custom function or override named attribute access on "arguments" 16:45
benabik, exactly right. The return continuation is where the subroutine jumps to when it is over
benabik, and there's no reason it has to jump back to the point of the call
it can jump directly to another chained sub, or a continuation somewhere 16:46
benabik whiteknight: Right, right. I was just making sure I wasn't assuming the wrong thing.
whiteknight no, you've got it
benabik :-D
benabik has been stuck in Java-land for 3 days.
benabik puts away Eclipse and doesn't want to touch it again any time soon.
whiteknight brb 16:47
16:47 whiteknight left, whiteknight joined, alh left
dukeleto benabik: good idea 16:47
NotFound Note that on the callee side you can already do all that, just by using a :call_sig arg 16:48
benabik dukeleto: I like Eclipse when I have to work in Java, but I don't like working in Java. I've been working in Ruby, Scala and Parrot for too long.
16:48 bluescreen joined
benabik Hm. Does parrot have any way to bypass repeated type lookups? i.e. can I do something like `mypmc = get_type "MyPMC"; a = new mypmc; b = new mypmc` instead of `a = new "MyPMC"; b = new "MyPMC"`? 16:53
cotto_work ~~
plobsing benabik: yes. I believe it is called 'get_class' 16:57
16:57 birdwindupbird left
benabik plobsing: Interesting. I was wondering about that because of whiteknight's blog and comment about the slowness of `new "CallContext"`. Although a dedicated op new_callcontext is probably best because we need that to be as fast as possible all the time. 16:59
cotto_work dukeleto: the M0 assembler doesn't need to care about what op arguments mean. Looking things up is the responsibility of the M0 interp. 17:00
whiteknight benabik: I didn't try get_class at all. I might want to include that in a benchmark instead of a dedicated new opcode
17:00 rj_ac left
dalek rrot: dbfe940 | plobsing++ | config/gen/opengl.pm:
convert opengl NCI signatures to new format
 17:00
rrot: 5e2b6af | plobsing++ | runtime/parrot/library/OpenGL.pir:
handle new signature change at runtime
rrot: 5e2f161 | plobsing++ | runtime/parrot/library/NCI/Utils.pir:
update call_toolkit_init for new call by reference calling convention
whiteknight Notfound: :call_sig on the callee does not do quite the same thing I do. It still calls get_params, which calls fill_params. fill_params does a check for :call_sig flag and returns early
benabik whiteknight: get_class only helps people who make multiple calls while an opcode helps everyone. And without the opcode, we'll just end up with every single bit of PIR code with a dedicated CallContext class register.
whiteknight it's less work than doing the whole fill_params show, but it's more than we need
plobsing benabik: be careful not to fall into the "add an op for it" trap. adding ops just pushes the complexity elsewhere
benabik plobsing: True enough.
NotFound whiteknight: I mean "you" the compiler writer.
plobsing NotFound: opengl appears to be fixed now 17:02
whiteknight plobsing: Yeah, that's my least favorite part of this approach. I find comfort in the idea that we should be able to delete more ops than we add
benabik plobsing: But performing calls is such a vital part of the VM that it doesn't seem uncalled for.
NotFound whiteknight: "you" can wtite the code to get the arguments.
benabik (Uncalled for, heh.)
NotFound plobsing: nice, going to test...
whiteknight Notfound: yes, true. Getting the call context is still more expensive now than it needs to be
plobsing whiteknight: WRT callcontext referencing the caller context, we already have something that does that - Keys. Perhaps we could merge the two concepts. 17:03
whiteknight blah. I have an irrational and unfounded hatred of keys 17:04
benabik plobsing: Keys?
whiteknight benabik: basically, something like a magical linked list
plobsing whiteknight: the implementation is a bit lacking, but the concept is necessary
whiteknight src/key.c and src/pmc/key.pmc
benabik whiteknight: I have a distrust of "magical".
plobsing whiteknight: there is nothing that *requires* keys to be a linked list
they could just as easily be implemented using an array of integeres 17:05
benabik I also distrust comments like "Sometimes it's the next key, sometimes it's not. The Key code is like that."
plobsing the caller convention would then be (1) fetch key constant describing call (functions as signature PMC) (2) clone key and bind clone to current context (3) pass cloned key during call 17:06
NotFound That comments can be remanants from a previous epoch, the key usage is more clean right now. 17:07
plobsing fetching a constant is cheap, cloning a key (if implemented using an integer array) could be cheap, binding a key to a context is a single pointer assign 17:08
17:08 contingencyplan joined
plobsing the caller side of PCC becomes increadibly inexpensive 17:08
whiteknight can we implement all that inexpensiveness inside CallContext? 17:09
NotFound plobsing: examples/fly flies again :)
benabik Key is a constant heterogeneous list?
plobsing benabik: yes, it is used to implement keyed access to aggregates
ttbot Parrot dbfe9404 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/3497
plobsing keys can also reference registers
whiteknight: we can. and then we can kill keys replace them with callcontext, and rename callcontext to key 17:10
they are the same concept
benabik plobsing: They sound more like "closely related concepts" than the same one. 17:11
whiteknight CallContext does a lot more than just passing arguments. It also holds the registers and all context information for the sub
plobsing see, that strikes me as just wrong
whiteknight We could CallContext isa Key, if you think that's worthwhile. The whole thing gives me the heeby-jeebies, so I don't want to think about it much 17:12
plobsing the register frame should be independant of the callcontext
whiteknight plobsing: We combined the two during the PCC refactors because it was seen as needlessly wasteful to create a CallSignature AND a Context for every call
and since the two almost always have a 1:1 relationship, they were merged. Great savings. There was much rejoicing 17:13
plobsing but some of that information is much more long-lived than other information
the call info is only alive during the call
whiteknight I'm not saying it's the best decision on all levels
plobsing and should be reclaimed afterwards
whiteknight but it was an optimization with significant performance benefits
a better design that doesn't regress miserably on performance would be eagerly considered 17:14
plobsing GenGC means we should aggressively seek to split information with different lifetimes
whiteknight to the point of turning one PMC allocation per call into two PMC allocations per call, across the board? 17:15
plobsing young generation garbage is cheap 17:16
call info is young generation except in special cases
dukeleto msg bacek you gonna unbreak master anytime soon? jitterbug.leto.net:3000/project/parrot 17:19
aloha OK. I'll deliver the message.
dukeleto msg bacek i would prefer you break a branch
aloha OK. I'll deliver the message.
17:19 fedov joined
dukeleto cotto_work: i am going afk for a while. Can you send an email to me or parrot-dev explaining exactly what an M0 assembler should and should not do ? 17:22
cotto_work dukeleto: srue
*sure 17:23
17:25 davidfetter left 17:27 fedov left 17:47 jevin joined
lucian has just submitted his dissertation. yay for mediocrity! :) 17:55
benabik lucian++
lucian whiteknight: with a good gc, constant-size allocation is free 17:56
whiteknight: so overall, i agree with plobsing, although PMC construction might be more complex that i immagine
benabik: thanks
benabik lucian: Is this the final dissertation? Ready for defense and everything? 17:57
benabik just started talking to a prof about a thesis.
lucian benabik: yeah, pretty much
done with uni after this
benabik lucian: Awesome!
lucian not really, it's kinda crap
whiteknight lucian: okay, I'll take your work and plobsing's word for it. I don't think we need to be changing around the way CallContext works for the first upcoming round of refactors
I mean, we can do it, or we can start cleaning crap up and make a new plan when the dust settles 17:58
lucian and i have plenty of coursework and exams left ...
whiteknight: if you think about it, you can arrange your gc so that allocation is just incrementing a pointer
benabik Do we currently have allocation pools for constant sized objects?
lucian PyPy's and jdk's do that
whiteknight lucian: yes, that's how we do allocations in Parrot now, for the most part 17:59
lucian whiteknight: but you certainly know more than me about parrot, it might not be feasible/good idea short-term
whiteknight for a fresh pool, we increment a pointer. Once the pool has been exhausted the first time, we GC and then pull off a linked free list
lucian right. so if the pools are too small/not aligned to pmc size, two allocations might be an issue 18:00
whiteknight pools should be plenty large and are aligned
lucian btw, dl.dropbox.com/u/317039/paper.pdf if anyone cares about my paper. don't distribute it please, 'cause i'm not sure i'm allowed
whiteknight because each pool only services objects of one size
lucian and is PMC initialisation expensive?
whiteknight I would say so, yes 18:01
benabik lucian: IRC channels are logged, so that link is now "public", so you might want to move it after a short time. :-/
whiteknight for each PMC we have to allocate an attributes structure for it, assign a vtable, and call VTABLE_init
lucian benabik: for some definition of "public"
benabik lucian: In this case, by public I mean "indexed by Google" 18:02
cotto_work There's a pretty good chance it'll be indexed by various search engines at some point.
lucian shrugs. it "slipped" out of my dropbox
whiteknight: right. could this be reduced?
if nothing else, a zygote PMC might help 18:03
after 3 years, i truly regret doing uni 18:04
benabik lucian: That sucks. :-( Despite the panic at the end of this quarter, I've been really enjoying it. 18:05
lucian benabik: at least mine's been mostly useless
only 3rd year have i learned new things
and even then, the exams and coursework is usually stupid 18:06
benabik lucian: Well, that's no good. I've had three classes a quarter so far and it's broken down into: 1 bleh, 1 kinda interesting, 1 awesome. 18:07
lucian right. my first year was all bleh, second year mostly bleh with a little interesting, 3rd mostly interesting with a little awesome
darbelo ~~ 18:08
benabik lucian: Oh well. :-(
lucian: Hopefully the little bit of paper they'll give you will be useful at least. :-D
cotto_work Anyone know windows and want to take a look at the get-entropy branch?
lucian benabik: doubtful, but hopefully 18:09
whiteknight cotto_work: yes, and no 18:14
:)
cotto_work sad face 18:15
whiteknight I'm looking now
benabik lunch!
18:15 benabik left
cotto_work happy face 18:15
whiteknight++
whiteknight cotto_work, where is the entropy stuff defined?
cotto_work src/platform/win32/entropy.c
new file 18:16
whiteknight okay, what am I looking at? 18:18
just make sure it works, or you want me to fill in the blanks? 18:19
cotto_work Why it won't build with the msvc toolchain
whiteknight ah, okay
cotto_work the blanks are the easy part
I just left them blank in case the surrounding code needed to be changed.
whiteknight cotto_work, it doesn't look like we are linking against advapi32.dll 18:24
that's where those functions are defined 18:25
cotto_work whiteknight: ok.
do you have the tuits to fix it? 18:26
whiteknight lemme look 18:27
I'm trying a build now. 18:30
cotto_work much appreciated
figured out how to fix the Makefile 18:33
whiteknight yeah, me too 18:34
cotto_work and where to add the .lib 18:35
whiteknight okay, parrot builds but the build now fails building ops2c
.\\parrot-nqp.exe --target=pir --output=compilers/opsc/gen/Ops/Compiler/Grammar.pir compilers/opsc/src/Ops/Compiler/Grammar.pm
NMAKE : fatal error U1077: '.\\parrot-nqp.exe' : return code '0xc0000005'
Stop.
everything up to that point passes
cotto_work I saw that on mingw 18:36
atrodo Looks like we're legit: www.yapc2011.us/yn2011/event/877
cotto_work atrodo: wootsauce
atrodo www.yapc2011.us/yn2011/event/876
cotto_work whiteknight: trying after adding advapi.lib to the mswin32 hints 18:37
whiteknight cotto_work: that's what I did the first time. It's in the commandline for building parrot-nqp 18:38
cotto_work build looks good for me 18:39
dalek rrot/get-entropy: 42dda94 | cotto++ | config/init/hints/mswin32.pm:
add advapi32 to the list of libs libparrot gets linked to
 18:40
cotto_work That wasn't quite as painful as I'd expected. 18:41
It seems to work and generate superficially random-looking numbers. 18:43
dalek rrot/get-entropy: c59893a | cotto++ | src/platform/win32/entropy.c:
pass PARROT_INTERP to entropy function instead of void
 18:44
cotto_work nice to have that working 18:45
whiteknight: thanks 18:47
and whiteknight++
The mingw build still explodes on opsc. 18:50
I saw that on master too, though.
whiteknight that's worrisome 18:51
I wasn't building with mingw 18:52
cotto_work yes
The entropy code also doesn't dtrt on mingw. 19:06
19:08 SHODAN joined
cotto_work having msvc working is definite progress 19:14
mikehh plobsing: perlcritic does not like the prototype on line 48 of config/gen/opengl.pm 19:24
whiteknight: bacek claims that error code is a segfault 19:26
whiteknight mikehh: which error code? 19:27
mikehh whiteknight: NMAKE : fatal error U1077: '.\\parrot-nqp.exe' : return code '0xc0000005' <- this one
whiteknight oh, nice 19:28
mikehh U1077 indicates nmake can't find it - the return code is supposed to be a segfault 19:29
whiteknight ok 19:30
cotto_work awesome 19:31
mikehh IOW it fails to build and '0xc0000005' indicates a segfault has occurred (at least according to bacek) me I don't know from nothing
cotto_work It's been too long since I've seen a segfault.
whiteknight I can make a bunch more for you, if you want 19:43
entropy generator + pointer dereference seems like a good system for making them 19:46
cotto_work whiteknight: sounds good 19:47
dukeleto ~~ 19:51
cotto_work hio dukeleto 19:54
dukeleto cotto_work: howdy 19:56
dalek rrot/get-entropy: 782b0e5 | cotto++ | src/platform/win32/entropy.c:
add enough magic to fix entropy for the mingw build
 20:00
dukeleto cotto_work: which platforms has get-entropy not been tested on yet?
20:01 darbelo left, darbelo joined
dalek nxed: r997 | NotFound++ | trunk/winxedst1.winxed:
extract creation of predef caller into a function
 20:01
cotto_work dukeleto: I've tested on windows (msvc and mingw) and Ubuntu 10.10 (x86) and 11.04 (x64). 20:02
dukeleto: any other *nix would be great. /dev/urandom seems to be very common, but there's no fallback for if it doesn't exist. 20:03
20:04 benabik joined 20:06 ShaneC left 20:15 benabik left 20:19 benabik joined
Coke_ benabik: (java land) hey, I'm in cold fusion land. 20:25
20:26 ShaneC joined
benabik Coke_: Cold fusion in physics is neat. In programming, not so much. 20:26
20:27 ambs left
whiteknight FYI: github.com/blog/854-scheduled-main...-22-00-pst 20:27
20:28 ambs joined, whiteknight left 20:30 particle left 20:32 ShaneC left 20:34 particle joined 20:37 dodathome left 20:42 bubaflub left
dalek nxed: r998 | NotFound++ | trunk/winxedst1.winxed:
check validity of instanceof left operand
 20:49
20:51 ambs_ joined, ambs left, ambs_ is now known as ambs
NotFound Winxed millenium edition is approaching ;) 20:55
tadzik yay :) 20:56
cotto_work worst marketing evar 20:57
20:57 Coke left 20:58 Coke joined
plobsing NotFound: oh noes. I'll have to rush to ensure all my code is w1k compliant 20:58
20:59 perlite_ joined
NotFound if (r % 100 > 99) ... 20:59
21:02 perlite left, perlite_ is now known as perlite 21:05 Coke left, Coke joined 21:07 SHODAN left
dalek TT #2110 created by cotto++: mingw build fails while building opsc 21:15
TT #2110: trac.parrot.org/parrot/ticket/2110
21:18 bubaflub joined
dalek nxed: r999 | NotFound++ | trunk/winxedst1.winxed:
check invalid initialization from void
 21:20
bacek Good morning, humans 21:30
dukeleto, I didn't brake build. GC maybe. But not build. 21:31
21:32 ambs left
cotto_work aloha, bacek 21:32
bacek msg whiteknight Nice post. Just 2 "small" problems: "C boundaries" and "MMD".
aloha OK. I'll deliver the message.
bacek cotto_work, aloha
cotto_work msg whiteknight The formatting on your latest blog post looks wacky. There's a big gap between the first paragraph and the code snippet. 21:39
aloha OK. I'll deliver the message.
bacek msg whiteknight And another "small" problem - ":flat/:slurpy". E.g. ($P1, $P2 :slurpy) = foo($P3 :flat) where "foo" is declared with ".param int a; .param pmc b :slurpy". 21:40
aloha OK. I'll deliver the message.
benabik 'lo bacek! I'm one major project closer to working on GSoC. :-D 21:41
bacek msg whiteknight and .return ("foo", "bar", "baz", $P3 :flat). Good luck!
aloha OK. I'll deliver the message.
bacek benabik, good to know! How many left?
benabik bacek: 1 large paper, 1 homework, 3 finals.
bacek benabik, which is equal to (in days)?
benabik bacek: Monday the projects are done, and I can actually spend some (but not too much) time in Parrot-land. Friday morning is my last final and I can really dig in after that. 21:42
bacek benabik, hooray! 21:43
benabik bacek: I'm not overly worried about the finals this quarter. Need to do some studying, but nothing too bad. It's been the projects due today and Monday that have taken ALL OF MY TIME. 21:44
bacek benabik, fair enough :) 21:48
benabik ETOOMANYFINALS ETOOMANYPROJECTS ENOTENOUGHTIME ETOOMANYERRORS
cotto_work ENOTENOUGHROBOTS
bacek msg whiteknight gist.github.com/969536 - this is why we have all "fill_params hell". Without splitting PCC into 2 parts a-la "fastcall" vs "smartcall" we can't do it much faster. 21:51
aloha OK. I'll deliver the message.
21:56 bluescreen left, darbelo left
bacek cotto_work, #2110 (mingw fail) Is it optimized build? 22:08
cotto_work bacek: no 22:09
22:09 bluescreen joined
bacek cotto_work, hmm. Can you obtain backtrace for it? 22:10
22:15 bluescreen_ joined
cotto_work bacek: I need to install gdb first 22:21
apparently strawberry doesn't include it 22:22
should have something in a minute or two 22:24
22:27 alester left
cotto_work doesn't seem to fail under gdb 22:28
benabik cotto_work: I love that kind of bug.
22:29 alester joined
benabik I have a bug in git where a change in the configuration code causes git-fsck to fail a test, but only when I run the test on a ramdisk. If I run fsck manually or run the test on my hard drive, it works fine. I call it a quantum bug. Its behavior is different depending on how I observe it. 22:30
lucian benabik: sounds like a timing bug 22:32
cotto_work What's $? in CMD.COM?
er, what's its equivalent.
benabik lucian: I think it's timing and memory allocation. When a variable changed from a static buffer to an allocated one, it started exploding. Fun to track down at any rate. (Which I'll spend some cycles on after finals.) 22:33
lucian: It'll give me good practice for GC bugs in Parrot. ;-)
lucian i try to stay away from anything that can deadlock
benabik: good luck with that :) 22:34
seeing as how i hate C so much, the only gc work i plan to maybe to would be either porting jikes rvm gcs or writing gcs in winxed 22:36
cotto_work looks like %errorlevel% is what I wanted
lucian s/maybe to/maybe do/
cotto_work: i can never remember all the odd windows constants
cotto_work bacek: any suggestions?
22:47 lucian left 22:50 lucian joined
bacek_at_work cotto_work, is there something like "ulimit -c unlimited" on win32? 22:50
cotto_work beats me. lemme dig 22:51
lucian i've been thinking that perhaps parrot could adopt one of the OS abstraction libs 22:55
cotto_work lucian: you mean something like apr? 22:56
lucian that, or nspr or glib
benabik Wasn't someone talking about glib interop?
cotto_work Historically, we've tried to be very minimal in our dependencies. 22:57
benabik: that's GObject interop at the PMC level
lucian cotto_work: but doesn't that involve a lot of new wheels?
like with threads. either one of those gives you threads, presto
at least locks
22:58 bubaflub left
dalek rrot/get-entropy: 8f424c1 | cotto++ | / (5 files):
shorten entropy function name, implement error checking/reporting
 23:03
23:03 benabik left
cotto_work lucian: I'll have to dig around to form a proper response to that. I think a big reason we're not using something like apr is that it'd limit the potential for embedded applications, but honestly it's an assumption that I've inherited and not thought about a lot. 23:08
lucian i see. it's just one more of the things i run background tasks in my brain for 23:09
cotto_work: myself, i rather like glib, and vala to some extent
it might even be interesting to couple PMCs and gobject more closely, or even base PMC on gobject 23:12
but that's a lot of work with little clear benefit 23:13
cotto_work yeah
23:17 Caelum left
lucian well, there are clear benefits 23:19
23:20 whiteknight joined
lucian but as you said, there may be features that can't be done easily this way 23:20
bacek_at_work cotto_work, can you try to revert 19962bf49db7a9fb7f60f54d17786a52f64758c4 locally? It's only one "big" change in GC which can cause this failure.
23:21 Khisanth left 23:22 Khisanth joined
cotto_work bacek_at_work: trying now 23:24
whiteknight what failure are we looking at? 23:27
whiteknight needs to backlog
bacek_at_work: I suspect we are going to need two new ops, one to pass :flat args and one to gather :slurpy args. Both of those things could also be done using loops/iterators or even the old slice vtable 23:29
cotto_work whiteknight: mingw build 'splosion
23:30 lucian left, bubaflub joined
dalek rrot/get-entropy: 0596d98 | cotto++ | src/platform/win32/entropy.c:
add missing semicolon
 23:31
cotto_work bacek_at_work: same failure after reverting that commit 23:34
bacek_at_work cotto_work, oookey. 23:35
cotto_work, what about reverting 6f0cfa824ff117c6731ab47320e0375402f14e80?
cotto_work, or even better - just bisect RELEASE_3_3_0..HEAD 23:36
cotto_work or that
might be a while 23:38
whiteknight I can debug it tomorrow in VisualStudio if needed 23:40
I didn't have time for that earlier today
cotto_work whiteknight: good to know
we'll see how far I can get
whiteknight ok
23:46 rurban_ joined
KaeseEs has anyone started on the m0 disassembler? i have some tuits tonight and tomorrow 23:48
23:48 rurban left, rurban_ is now known as rurban 23:49 hudnix left
cotto_work KaeseEs: it's all yours 23:53
KaeseEs: please do any m0-related work in the m0-prototype branch

Powered by Cro and the Raku® Programming Language.

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

Thank you!