Parrot 2.8.0 released | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | smoke GC-related branches and attack GC tickets
Set by moderator on 1 October 2010.
cotto whiteknight, if you know your way around distutils all of the nqp files in parrot-instrument need to be compiled down to pbc and merged into InstrumentLib.pbc with pbc_merge. 00:07
00:29 whiteknight left 00:47 whiteknight joined 01:27 whiteknight left
plobsing cotto: ping 01:29
01:31 theory joined 01:57 theory left 02:25 Andy joined 02:35 janus left 02:42 janus joined
dukelet0 'ello 02:56
GeJ Heya.
cotto plobsing, pong 02:57
dukelet0 GeJ: how goes it? what are you hacking on with your new commit bit?
plobsing cotto: I've been looking at the profiling runcore failure some more. I now suspect my initial assessment is dead wrong. 02:59
notably, reverting the commit I blamed doesn't solve the problem
cotto do tell
plobsing what I do notice though is that the code makes use of a lot of preop_x variables *after* the op has been executed. 03:00
somewhere one of these may be pointing to state that is no longer valid, or at least no longer valid in the context it is being used. 03:01
cotto Are you thinking that I should try to copy the data I'll need into someplace where I know it won't be changed 03:03
plobsing I think we should calculate all the preop_x stuff needed for accounting *before* we actually execute the op. 03:04
cotto That sounds like a good idea in any event. 03:05
plobsing also, I'm having trouble wrapping my head around a function that big with so much branching. I might take my refactor hammer to it later. 03:06
cotto You're welcome to.
03:07 jsut joined
cotto My last attempt was to factor out common code, but there's not a whole lot. 03:07
Breaking it into functions, even if they're only called once, could do a lot for readability. 03:08
How soon is "later" for you? It's starting to sound like a good thing for me to tackle. 03:09
plobsing if you're eager to fix it, be my guest 03:10
cotto starts hammering 03:11
plobsing just be sure to move the preop_line calculation stuff to before DO_OP
cotto I'll try breaking it into functions first, but that's on the todo list. 03:12
03:12 jsut_ left
GeJ dukeleto: Right now, a real estate app in Perl 5 for $work. 03:12
cotto plobsing, thanks for the feedback. It'd a valuable data point that my code is hard to follow. 03:13
s/'d/'s/
GeJ dukeleto: but at home, in my secret lair, I'm working on taking over Data::Dumper.
plobsing cotto: at least you're smart enough to be able to do something about it. all I can do is stay away from bus routes. 03:14
cotto recalls that naming things is one of the two hard problems in programming. 03:16
plobsing the other being implementing said things? 03:17
cotto the other being cache invalidation
dalek rrot: r49433 | plobsing++ | trunk (7 files):
add --ar and --arflags options to Configure.pl
 03:21
03:33 Andy left
cotto --arflags, in the middle of --arstreet 03:38
dalek rrot: r49434 | cotto++ | trunk/src/runcore/profiling.c:
break some profiling code off into separate functions
 03:51
rrot: r49435 | plobsing++ | trunk/src/sub.c:
add some sanity and sanity checking to Parrot_Sub_get_line_from_pc
 04:07
rrot: r49436 | cotto++ | trunk/src/runcore/profiling.c:
break some more code into separate functions
 04:37
cotto plobsing, I may be done for now. Any further refactoring you care to contribute is welcome. 04:56
plobsing cotto++ # I think I understand it better now 05:02
emphasis on the think
cotto It feels good to break that code up. 05:10
plobsing cotto: profiling runcore should be fixed in r49437. 05:30
05:32 bacek joined
cotto plobsing++ 05:33
now let's see if I can run nqp under the profiling runcore
plobsing can you confirm this is working for you? then I'll update the ticket, but not close it pending testing 05:37
cotto I'm just about to test it.
I think you may have nailed it. 05:38
It's taking a long time to run, but it used to fail immediately.
nm
It explodes with a gc assert failure 05:39
dalek rrot: r49437 | plobsing++ | trunk/src/runcore/profiling.c:
lookup op name *before* executing the op
cotto That's definitely a more different failure though.
plobsing damn. I hate it when I slow things down. Parrot used to fail so quickly. 05:41
cotto tries a differenter gc 05:42
I get an assert failure in src/gc/gc_ms2.c whether I use --gc=ms or --gc=ms2 05:46
Ah. --gc ms is the correct spelling
that fails much more quickly
plobsing parrot's longopts parser isn't very flexible. not that this is necessarily a bad thing... 05:48
cotto Attempting to use inf is as bad an idea as I'd expect it to be with nqp. 05:49
plobsing what? you don't have an infinite amount of memory? 05:50
cotto I settled for infinity minus one. 05:51
plobsing wonders what the swap behaviour would be for gc-inf. if the generational heuristic is accurate, it may not be that bad.
sorear plobsing: there's been quite a bit of work on that (see: log-structured file systems) 05:52
cotto get_ns_cstr shows up in the backtrace 06:04
06:19 bluescreen left 06:26 jsut_ joined 06:30 jsut left 06:33 ash_ left 07:02 dukeleto left 07:07 bacek left 07:17 eternaleye left 07:36 fperrad joined
dalek rrot: r49438 | mikehh++ | trunk/src/runcore/profiling.c:
fix codetest failures - remove space before closing parenthesis,
 07:57
rrot: r49439 | mikehh++ | trunk/src (2 files):
fix codetest failures - remove space after opening parenthesis and
08:03 cosimo_ left 08:12 luben_work joined 08:15 cosimo joined 08:22 eternaleye joined 08:25 dukelet0 is now known as dukeleto 08:32 perlite left 08:33 perlite joined 08:41 esskar left
mikehh plobsing: ping 08:43
aloha msg kid51 t/steps/progs-01 thru 04.t failing, I think due to r49433 - I tried adding ar and arflags to the list(s) but that didn't seem to work 09:08
aloha mikehh: OK. I'll deliver the message.
mikehh aloha msg plobsing t/steps/progs-01 thru 04.t failing, after r49433 (post-config tests) 09:33
aloha mikehh: OK. I'll deliver the message.
09:53 cogno joined 09:57 contingencyplan left 10:08 cogno left 10:27 cogno joined 10:42 cogno left 10:47 cogno joined 11:01 cogno left 11:02 kurahaupo joined 11:13 bacek joined 11:21 kurahaupo left 11:24 cogno joined 11:27 sjn left 11:30 sjn joined 11:36 cogno left 11:50 whiteknight joined, tadzik joined
whiteknight good morning, #parrot 12:10
12:18 ascent left 12:19 ascent joined 12:29 cogno joined 12:35 ruoso joined
plobsing mikehh: tests should be fixed as of r49440. 12:54
also, do we care that t/steps/gen/crypto-01.t fails? 12:55
dalek rrot: r49440 | plobsing++ | trunk (5 files):
fix failing config tests
 13:04
13:10 tadzik left
mikehh plobsing: ok tests PASS - it doesn't seem to run t/steps/gen/crypto-01.t for me 13:14
plobsing yeah, I stumbled over it by running prove t/steps/*
mikehh plobsing: if I prove it fails after first test
13:15 Patterner left
mikehh plobsing: I usually run configure with --test 13:16
ie - date && time perl Configure.pl --test --maintainer --configure_trace --optimize 13:17
or even date && time perl Configure.pl --test --cc=g++-4.5 --cxx=g++-4.5 --link=g++-4.5 --ld=g++-4.5 --maintainer --configure_trace --optimize
I drop the --optimize if I want to test the ASSERTs 13:19
Ubuntu/Kubuntu 10.10 defaults to gcc-4.4 but I built perl 5.12.2 with gcc-4.5 so I try and use that 13:21
plobsing I can't seem to find when gen::crypto was removed 13:29
13:29 PerlJam joined, Psyche^ joined 13:30 Psyche^ is now known as Patterner
mikehh plobsing: looking for it 13:33
13:38 cogno left
Coke crypto stuff was moved out of core, neh? 13:45
plobsing AFAICT, yes. this appears to be a fossil 13:49
Coke perhaps we need a test to check for invalid configure tests. ;) 14:04
dalek rrot: r49441 | plobsing++ | trunk (2 files):
remove useless tests for now-removed gen::crypto
 14:06
14:20 patspam joined 14:22 PacoLinux left 14:28 bluescreen joined 14:52 PacoLinux joined 14:55 Andy joined 15:01 patspam1 joined, ash_ joined 15:04 patspam left 15:18 PerlPilot joined 15:19 PerlPilot left, mikehh left, Tanami left 15:23 PerlPilot joined 15:34 contingencyplan joined 16:14 davidfetter joined 16:15 cogno joined 16:22 cogno left 16:23 patspam1 left
cotto ~~ 16:31
16:38 tadzik joined 17:00 theory joined 17:02 PerlPilot left
dukeleto 'ello 17:04
17:10 mikehh joined
whiteknight hello duke 17:12
davidfetter aaaa...what's up, duke? 17:14
</bugs>
dukeleto davidfetter: drinking my morning coffee thinking about writing this in perl 6 : rosettacode.org/wiki/Thiele%27s_int...on_formula 17:16
davidfetter h0ly cr4p! 17:17
17:17 Andy left
davidfetter i presume that this is some numerically efficient way to compute approximations, or a one that converges quickly, or something 17:17
davidfetter reads 17:18
17:20 bluescreen left, bluescreen joined
davidfetter dukeleto, um, i'm missing some context. what makes thiele worth doing? 17:20
dukeleto davidfetter: to show that perl6 can do it in a few lines. 17:22
davidfetter: which isn't a very good reason, i know :) 17:23
17:24 luben_work left
Coke NotFound++ 17:28
dukeleto: use it as an excuse to profile parrot. 17:29
dukeleto Coke: that is a good point. I have been thinking of using generated PIR as benchmarks, since that is the real use case 17:30
Coke: most of our benchmarks are pathological or not realistic 17:31
davidfetter: what are *you* up to?
Coke Since I will likely not be able to make parrotsketch again (bad time for my $DAYJOB), I'd appreciate it if someone can bring up my recent tcl-related bug.)
whiteknight I wonder if we could move it to a different time, again 17:32
we always have people who can't make certain times, moving the meeting around would help to get more people involved, at least temporarily 17:33
Coke don't move it on my account, though.
17:34 patspam joined, patspam left
Coke as my tuits for actual parrot work are not going to improve any time soon. 17:34
(ugh, my home macbox is low on memory) 17:35
dukeleto Coke: do you have a link for the thing you want brought up?
Coke trac.parrot.org/parrot/ticket/1811 17:37
17:37 mikehh left
davidfetter dukeleto, it's a fine reason. are there things that go to elegant and useful in there, or is that "just" a way to show off the power? 17:37
17:38 PerlJam left, fperrad_ joined, PerlJam joined
dukeleto davidfetter: there are some really interesting rosetta code problems, and reading all the solutions in different languages really makes you see the strengths and weaknesses of different languages 17:39
Coke I have another failure in partcl-new that I should be able to bisect sometime today.
dukeleto no parent SL1.00sc00001.g1.t1 (SL1.00sc00001.g1.t1);
oops, accidental paste.
davidfetter what have you run across in rosetta that shows off parrot's weaknesses so far? 17:40
dukeleto davidfetter: i don't know if there are any PIR solutions yet, but there a quite a few perl 6 solutions 17:41
17:41 fperrad left
davidfetter :) 17:41
17:42 fperrad_ is now known as fperrad
dukeleto Coke: perhaps mentioning it on parrot-dev will get some eyes on it 17:42
Coke: telling chromatic that he broke something usually gets it fixed pretty soon :) 17:43
davidfetter what's the latest re: the Great Git Migration™? 17:44
Coke I cc'd him on the ticket.
cotto davidfetter, the plan is to start it shortly after the next release 17:45
davidfetter sweet
cotto++ :)
i don't know whether i really love git, but i know it's hard to live without once you've had some 17:46
cotto there are still a few pieces that need doing 17:47
dukeleto yeah, like mk_language_shell and create_language
cotto like those 17:48
dukeleto, are you to the point of reconsidering whether those need to be hard dependencies? 17:54
18:01 M_o_C joined
dukeleto cotto: what do you mean? 18:05
cotto Are the scripts enough of a mess that we should figure out the problem of dealing with minimum version requirements before updating the language creation scripts? 18:09
18:10 kurahaupo joined
cotto Maybe the best approach would be to use another hll (Rakudo or Partcl) as a guinea pig. 18:12
dukeleto One big problem: mk_language_shell and create_language have no tests. 18:20
cotto sigh
I guess running them manually isn't too hard.
dukeleto the fact that we have two scrips that do *almost* the same thing, that duplicate each others code, and that have no tests => sucks 18:21
that isn't a huge deal, but it factors in
whiteknight add tests
then pick the tool that you want, and add new features to it 18:22
18:26 fperrad_ joined, fperrad left 18:27 fperrad_ is now known as fperrad
whiteknight better yet, consolidate the two tools, and use a command-line switch to select behaviors 18:28
And then, create a thin front-end for them that emulates the current behavior but calls back into a single, well-tested core
viola
plobsing why not leave it up to the parties whose political differences are responsible for there being two tools in the first place? 18:30
whiteknight because they are obviously doing it wrong
18:31 mikehh joined
plobsing when I said it, I meant fixing their respective tool to work with git 18:31
18:32 preflex left 18:35 preflex joined
whiteknight There are two unrelated problems: First, that we need to move tools to git, and Second that we have two tools that do almost the same thing and are poorly designed and untested 18:36
dukeleto Look at the madness here: trac.parrot.org/parrot/ticket/1491 18:40
davidfetter "don't do the browns. the browns are a bummer" 18:41
18:44 PerlPilot joined
whiteknight dukeleto: we can still provide the behaviors that everybody wants, and the interfaces that everybody wants, but improve the internals dramatically 18:47
18:47 fperrad left
Coke partcl doesn't use either of those tools. 18:49
pmichaud may have used one when he rolled up partcl-nqp, but it's a one shot, and if you fix the script, i get no benefit from it.
of all the things we could work on improving, the internals of those scripts seems like a low-impact one. 18:50
dukeleto whiteknight: that is what I just suggested on the ticket
Coke: those two scripts are currently the blockers for moving to git 18:51
Coke I've said this before: do a braindead translation of them and be done with it. don't let git block on that.
and there's no point in worrying about people that are currently using svn, because they won't get the new scripts by default. 18:52
(that is, in terms of fixing /those scripts/)
whiteknight in terms of speeding along the git translation, a "brain dead translation" is a fine short-term solution
dukeleto Coke: what do you mean a "braindead translation" ?
whiteknight in the longer term, if we want people to use and rely on these things, we need to put more tought into them
Coke dukeleto: what do you mean they're blocking you?
why are they so much more effort to translate over than the other scripts that have already been done? 18:53
dukeleto Coke: the way they are written now is incompatible with git
Coke ok. what does that have to do with the fact that there's 2 of them?
dukeleto Coke: there is no monotonically increasing integer revision number to compare in git
Coke the whole (political) issue of which one is the right one should not be blocking the git migration.
dukeleto Coke: i have to convert two almost identical things to git, and they are untested 18:54
Coke ok. that's not the impression I get of the blocker when this issue is discussed.
(almost identical) that's the part Ig et as the major blocker.
dukeleto Coke: and I have to change their behavior when converting them to git
Coke and it's just a fact at the moment. you're not going to solve that problem pre-git, IMO.
dukeleto Coke: the "almost identical" part just doubles my work, is all
cotto and is an excellent demotivator 18:55
dukeleto Coke: i didn't quite parse what you just said. Can you repeat?
Coke I don't know how to make my position any clearer. nevermind.
Wake me up when git is here. ;) 18:56
dukeleto Coke: "(almost identical) that's the part Ig et as the major blocker" 19:00
Coke: i don't understand what you are tying to say there 19:01
Coke: and if you can exactly describe what you mean by "braindead translation", that would be useful.
Coke: it is not like translating a shell script to perl. Fundamental changes to the algorithm need to happen. 19:02
Coke: and doing those twice, in an untested manner, irks me, the person doing all the work.
"all the work" to translate them, I mean.
whiteknight until we know what we want, maybe the best way forward is to rip out all source control logic 19:03
dukeleto we could go the route of "we will fix those scripts after we migrate", i guess
whiteknight Rip out all the svn code and don't replace it with anything until we know what we want 19:04
dukeleto whiteknight: that is a possibility
whiteknight these scripts probably need a complete rewrite anyway, so we can't turn that into a migration blocker too 19:06
cotto What about making a language like Rakudo or Partcl work with git? Getting the git logic working in one of those would help us figure out how the language creation scripts will need to change.
it'd also let us work on one thing at a time and get it working before moving on to the next 19:07
dukeleto cotto: yeah. i have a branch of rakudo for doing that, but it doesn't have anything useful yet
cotto rather than figuring out a git strategy *and* migrating a bunch of duplicated code
Commit something stupid and ask people if they have any suggestions. ;)
dukeleto cotto: the issue is that those two scripts are a nexus of problems. deciding how many to fix before the git migration is the issue 19:08
atrodo cotto> I love doing that
dukeleto cotto: perhaps I will just make both scripts do a "rm -rf /" and say "patches welcome"
cotto At this point, +1
but only if you add sudo 19:09
dukeleto cotto: it seems at this point, tests for either or both scripts are a big win, and are mostly independent of svn/git
cotto: basic tests like "create language X, then make sure that the directory X was created" 19:10
cotto or "create a language and make sure its tests pass" 19:11
Mmmm. Test tests.
dukeleto cotto: the fact that parrot version numbers are hard to parse and compare is the actual hardest part of the migration, but that is wrapped up inside all the other issues with those scripts 19:12
cotto Right. I'm suggesting that we solve that problem first for an existing language (where the scripts don't come in to play), the use that information to tackle the other issues. 19:13
dukeleto cotto: ok, so what would the actual steps of that look like? 19:14
cotto: create a rakudo branch that depends on parrot.git ? 19:15
cotto yes, and focus on that first 19:16
dukeleto cotto: one issue is that a lang can't depend on a specific git commit without having the parrot.git repo 19:17
cotto dukeleto, we can modify the parrot executable to spit out the information needed so that a language can tell if the installed parrot is recent enough. 19:19
dukeleto cotto: that is what parrot_config is for, but the situation is hairy
cotto right. I just thought of that after typing my response 19:20
dukeleto cotto: git describe can help us 19:22
cotto: but there are still some edge cases that make things fun, like x.2.1 coming out after x.3.0
cotto: to get around that, i think appending a date to the output of "git describe" may work 19:23
"perl tools/dev/create_language.pl --help" creates a language called "--help". LTA. 19:26
cotto We could make sure hlls specify a date and a minimum version, i.e. something later than 2.8 and after 10/20/2010.
...
I don't even know how to respond to that. 19:28
19:29 Andy joined
cotto Our scripts probably shouldn't make fun of people who ask for help. 19:30
19:35 kurahaupo left
atrodo That's just generally a bad design decision 19:41
GeJ Bonjour everyone. 19:42
davidfetter salut, GeJ
dukeleto GeJ: welcome to the madness 19:44
davidfetter iaaa! iaaa! 19:45
GeJ Just to get used to it... #ps is in roughly 24h, correct? 19:46
cotto GeJ, closer to 25 19:47
24:42 19:48
GeJ Thanks cotto. 19:49
cotto np 19:50
GeJ can someone with tuits help decrypt some PIR code? 19:51
dukeleto create_language also massively fails if a directory already exists with the name of the language you want to create
GeJ: sure, what are you up to?
Coke the scripts in question are only run once, generate a bunch of other files, and then /those/ become the language directory, eys?
GeJ runtime/parrot/library/dumper.pir lines 166~176 19:52
dukeleto Coke: yes
Coke ok. so are you asking for tests for those scripts themselves, or for the generated language directory?
dukeleto GeJ: looks like some funky code going on there
Coke: i am writing tests for create_language right now, and the answer to your question is "both" 19:53
Coke ok. you might want to be clear about that when asking for tests.
GeJ dukeleto: if I grok it correctly, get me an instance of Data::Dumper if I already stashed one in Data::Dumper::global, make a test to se if I get something back. and in any case, create a new one. 19:54
Coke I find testing the script itself about as helpful as testing a configure step.
GeJ ... and store it in Data::Dumper::global.
cotto Coke, we don't expect people to run it often, but the times when they do are pretty important. 19:56
Coke are we talking about configure steps? i'd be happy to hear a use case where that makes sense. 19:57
dukeleto Coke: the first thing a new HLL dev uses is usually one of those scripts. It would be nice if we could be sure they work correctly. 19:58
Coke yes. by running them and testing the result. sure.
That seems a perfectly reasonable test for the script itself. 19:59
(I can see a few cases where things like 'does it respect this command line option') are helpful. I just would hate to see us head down the same path we did with configure.
dukeleto Coke: what path is that? 20:01
Coke where we test that each configure step has test coverage, rather than relying on parrot functionality tests. 20:02
in very broad strokes, t/configure is good. t/steps is overkill. 20:03
cotto whiteknight++ for the #1491 reply 20:06
karma git 20:13
aloha, karma git
GeJ clock? 20:14
aloha GeJ: LAX: Mon, 10:07 PDT / CHI: Mon, 12:07 CDT / NYC: Mon, 13:07 EDT / UTC: Mon, 17:07 UTC / LON: Mon, 18:07 BST / BER: Mon, 19:07 CEST / TOK: Tue, 02:07 JST / SYD: Tue, 04:07 EST
dalek rrot: r49442 | dukeleto++ | trunk (2 files):
[t] Add some basic tests for create_language.pl
 20:15
GeJ aloha: you're drifting sweety.
rrot: r49443 | dukeleto++ | trunk (2 files):
[t] Add some basic tests for mk_language_shell.pl
dukeleto why isn't aloha keeping track of karma?
20:16 mikehh left
cotto explain git 20:17
aloha, explain git
aloha, msg bacek aloha isn't displaying karma 20:18
aloha cotto: OK. I'll deliver the message.
cotto seen bacek 20:19
aloha bacek was last seen in #parrot 8 hours 46 mins ago joining the channel.
whiteknight karma dukeleto 20:20
karma dukeleto?
aloha, karma dukeleto?
aloha whiteknight: Search me, bub.
cotto According to the github code, the karma module is loaded. 20:21
github.com/bacek/aloha/blob/master//bot.pl
clock?
aloha cotto: LAX: Mon, 10:15 PDT / CHI: Mon, 12:15 CDT / NYC: Mon, 13:15 EDT / UTC: Mon, 17:15 UTC / LON: Mon, 18:15 BST / BER: Mon, 19:15 CEST / TOK: Tue, 02:15 JST / SYD: Tue, 04:15 EST
whiteknight karma? 20:22
atrodo That clock is a bit slow
cotto must be due to to the clock on bacek's dev box 20:23
20:32 M_o_C left 20:50 perlite left, perlite joined 20:57 whiteknight left 21:04 mikehh joined 21:21 bluescreen left 21:23 tadzik left
cotto dukeleto++ 21:26
dukeleto, do those tests work for you? They look broken on my box: 21:38
dukeleto cotto: they passed for me when I committed them
cotto: you have a smoke report? 21:39
nopaste "cotto" at 192.168.1.3 pasted "new language tools tests broken" (15 lines) at nopaste.snit.ch/23986
dukeleto no good deed goes unpunished
cotto: what version of File::Path do you have?
cotto: you must have an old one
cotto: i can probably just switch to using the older rmtree function 21:40
cotto 2.04 apparently
must have come with ubuntu
yes, it has rmtree
dalek rrot: r49444 | cotto++ | trunk/src/runcore/profiling.c:
add a const and cast to make the C++ build work
 21:47
dukeleto cotto: fixed 21:51
cotto wfm now. Thanks. 21:55
21:56 ruoso left
cotto The tests are a little sparse, but that'll be a good start to build on. 21:56
especially people who aren't you. ;) 21:57
dalek rrot: r49445 | dukeleto++ | trunk/t/tools (2 files):
[t] Use rmtree instead of remove_tree to support elderly File::Path's
 22:03
22:04 PerlPilo1 joined
bacek_at_work ~~ 22:25
22:26 aloha left, aloha joined
cotto Nice. I can run headerizer on a single file by throwing it the object file generated by the file I care about. It's a bit baroque, but it'll save me some time. 22:27
aloha, karma git 22:28
aloha cotto: git has karma of 0.
cotto aloha, karma c
aloha cotto: c has karma of 7.
cotto aloha, karma bacek
aloha cotto: bacek has karma of 38.
cotto bacek_at_work, did that get reset again recently?
bacek_at_work cotto, it was. When I moved it from my home laptop. 22:29
about couple of weeks ago
cotto It's good to have that working again. 22:33
bacek_at_work cotto, next time just try to "!load Karma" in aloha's console :)
cotto Now I know. 22:34
thanks
Both the bot and the users take some training. 22:35
Would it be possible to scrape moritz's irclogs to recover karma?
sorear bacek_at_work: btw 22:37
aloha: clock
clock?
aloha sorear: LAX: Mon, 15:37 PDT / CHI: Mon, 17:37 CDT / NYC: Mon, 18:37 EDT / UTC: Mon, 22:37 UTC / LON: Mon, 23:37 BST / BER: Tue, 00:37 CEST / TOK: Tue, 07:37 JST / SYD: Tue, 09:37 EST
sorear oh, you fixed that
bacek++
bacek_at_work sorear, yeah... ntpd on virtual machine doesn't work properly... 22:38
sorear any chance of getting aloha to respond only to ^aloha, and not spuriously trigger when people in #perl6 start a sentence with "explain" or "clock"? 22:39
bacek_at_work sorear, I probably can. But code is same for #parrot and #perl6. So behaviour will be same. 22:40
clock? 22:42
aloha, clock? 22:43
aloha bacek_at_work: bacek_at_work: LAX: Mon, 15:42 PDT / CHI: Mon, 17:42 CDT / NYC: Mon, 18:42 EDT / UTC: Mon, 22:42 UTC / LON: Mon, 23:42 BST / BER: Tue, 00:42 CEST / TOK: Tue, 07:42 JST / SYD: Tue, 09:42 EST
bacek_at_work: No clue. Sorry.
bacek_at_work sigh...
There is a "bug" in Bot::BasicBot::Pluggable. It doesn't stop processing modules after first hit.
22:52 Andy left
cotto almost has the main loop of the profiling runcore down to one screenful of code 23:01
not that that's a goal, but it won't hurt anything either 23:02
dalek rrot: r49446 | cotto++ | trunk/src/runcore/profiling.c:
break a couple more chunks of code into separate functions plus small cleanups
 23:04
plobsing cotto: any luck with that gc bug? 23:05
cotto I'm going to take a crack at factoring out more code and then tackle that one.
It'd also be nice to make the code a little less branchy. 23:07
23:12 whiteknight joined
plobsing it's already significantly less deep. that update_ctx stuff was messy 23:12
23:14 ruoso joined
whiteknight good evening, #parrot 23:16
davidfetter guten abend, whiteknight 23:17
whiteknight hello davidfetter, how are you?
davidfetter i'm well, thanks. yourself?
whiteknight doing pretty damn good myself, thanks 23:18
23:18 Kulag left
GeJ G'Day bacek. 23:22
23:23 Kulag joined
GeJ bacek_at_work: lost one hour of sleep this week-end? 23:24
bacek_at_work GeJ, almost. 23:26
GeJ gained, then? 23:28
GeJ finds this DST thingy very confusing.
davidfetter springs forward
...only upside down from bacek_at_work
dalek rrot: r49447 | cotto++ | trunk/src/runcore/profiling.c:
[profiling] break line number retrieval into a separate function
 23:35
23:46 hercynium joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!