Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today” | Accepted GSoC Students announced! | GSoC student information emails coming out soon
Set by moderator on 26 April 2011.
dalek rrot/pdds_restart: d8c425c | Whiteknight++ | docs/pdds/draft/pdd00_pdd.pod:
first draft/rewrite of PDD 0, cut out some older stuff, be more explicit about certain things. Be clear that PDDs are the intended ideal designs
 00:13
00:18 Coke left 00:19 Coke joined
cotto_work whiteknight: I note that your changes to PDD 0 conflict with the way I'm using PDD 32 in the m0-spec branch. 00:21
Do you think it'd be worthwhile to have Parrot Implementation Documents for that kind of information?
whiteknight we can hardly get our first set of P*D documents working correctly
cotto_work That's a valid concern. 00:22
whiteknight That might be worthwhile, eventually. I really want to focus on PDDs first
cotto_work I'll keep doing what I'm doing with the M0 pdd and put it in the right place later.
00:24 perlite left
whiteknight the PDD00 thing is still draft. I did more deleting of old details than adding of new details 00:24
if the M0 doc still doesn't conform, we'll have to delete more details 00:25
cotto_work My goal in that doc is to say "here's everything you need to implement a conformant M0 vm". 00:26
whiteknight well, that doc may have a slightly different purpose than other PDDs 00:27
cotto_work That's probably true. 00:28
whiteknight most PDDs are only going to talk about the internals of Parrot specifically
the PIR PDD might be in the same boat
but we can re-evaluate PDD00 at any time, of course. I suspect the PDD review project will last quite a long time
cotto_work It's a good project for pretty much anyone. It's good for newbies because they're better at exposing implicit assumptions and it's good for people who know the code because they know the code. 00:29
whiteknight yes 00:30
cotto_work www.gitalytics.com/user/detail/leto 00:31
00:31 Coke left, Coke joined 00:36 darbelo_ left 00:38 perlite joined
whiteknight I think we are going to want to put in a heck of a lot of effort into PDD01 00:41
that has the potential to really become our mission statement of sorts 00:42
anyway, I'm out for the night 00:46
00:47 whiteknight left 00:48 theory left 00:58 davidfetter left
atrodo whiteknight++ 01:01
cotto_work> gitalytics is really neat 01:02
01:03 lucian joined
cotto_work atrodo: I just saw it fly by on hacker news. It has a few raw spots, but there's a lot of potential and realized awesomeness. 01:09
01:11 theory joined 01:13 mtk0 left 01:20 mtk0 joined, sjn left, krunen left, sjn joined 01:24 krunen joined 01:27 lucian left 01:47 rurban_ joined 01:49 rurban left, rurban_ is now known as rurban 01:51 woosley joined
cotto ~~ 02:56
atrodo =~ 02:57
cotto new lappy is here
atrodo Hurray! New toys are fun 02:58
03:04 hudnix left
cotto Awesome. Apparently the ssd I bought is too thick. 03:08
stupid first world problems 03:09
I have angries. 03:13
dukeleto sadface 03:17
msg plobsing i finally have the gcc40 machined configured to send smoke reports 03:27
aloha OK. I'll deliver the message.
dukeleto whoa, gitalytics is cool 03:31
03:32 jrt4__ joined
dalek rrot: ed43c68 | petdance++ | src/dynext.c:
consting local vars
 03:45
rrot: 7580e82 | petdance++ | src/dynext.c:
lib_name cannot be NULL
rrot/m0-prototype: 3dc9be0 | cotto++ | src/m0/m0_interp.pl:
zero all context registers during context initialization
 04:11
cotto dukeleto, it seemed like it'd be right up your alley
dukeleto cotto: yeah, quie spiffy 04:16
quite, even
cotto I got the ssd installed, but I don't think it's ever coming out. 04:30
seems to work fine 04:32
atrodo okay, i give up. Anyone know how to cast in nqp? 04:51
tadzik cast from what to what? 04:52
atrodo Regex::Match to number 04:53
dalek rrot: 766efa7 | jkeenan++ | Configure.pl:
Minor code reformatting.
atrodo basically call the get_number that i see in the pir defination of regex::match 04:54
cotto atrodo, prepend + 04:59
note that nqp uses N, not I 05:03
05:12 fperrad joined
atrodo cotto++ Looks like that was it. Thanks 05:14
I'm curious why +0 doesn't work 05:15
I'm also curious why it was auto-casting sometimes, and not others. but that's no here nor there at this point 05:17
cotto nqp has its own set of quirks 05:19
dukeleto msg plobsing "make test" passed on your tt1931 branch on debian/powerpc64 05:40
aloha OK. I'll deliver the message.
dukeleto msg plobsing now that I think about this, your branch needs darwin/ppc testing, not debian/ppc testing. Blarg.
aloha OK. I'll deliver the message.
cotto I need a name for my new laptop. 05:49
tcurtis ~~ 06:01
moritz cotto: regarding calling to srand(), I think the original reason it was done automatically was to prevent complexity attacks on hashes 06:07
cotto moritz, the hash seed is still initialized from the system clock. 06:08
moritz ah
cotto and that was indeed the motivation
tcurtis ooc, does anyone here happen to both live in the Chicago area, and own one of those Captain Crunch whistles that were once used for phone phreaking? And also be willing to lend it to some college students Sunday for a scavenger hunt?
cotto Half of me wishes it grew up in those days. 06:09
The other half is pretty happy with how things have worked out so far.
The third half belongs to someone else entirely. 06:10
dalek rrot/m0-prototype: 2cdd5cd | dukeleto++ | / (5 files):
Add another test for invalid M0 and the beginning of version parsing
 06:22
cotto woot 06:24
dukeleto++
dalek rrot/m0-prototype: 34e3c86 | dukeleto++ | / (2 files):
Actually parse version and add a test
 06:26
06:32 mj41 joined
dalek rrot/m0-prototype: c4f3c2d | dukeleto++ | src/m0/m0_assembler.pl:
Add a stub for generate_bytecode()
 06:40
cotto dukeleto, are you around? 08:07
08:07 jrt4__ left
cotto Bah. I need to sleep. 08:08
'night
dalek rrot/m0-prototype: f6c45b2 | cotto++ | t/m0/m0_interp.t:
add some interp tests to be unstubbed when the assembler is ready
 08:09
08:20 cotto left 08:22 cotto joined, ShaneC joined 08:23 theory left 09:01 mtk0 left 09:08 mtk0 joined, ShaneC1 joined 09:11 utsl left, ShaneC left 09:21 ShaneC joined 09:22 utsl joined 09:24 ShaneC1 left
moritz what's the state of non-blocking sockets? 09:28
I thought tcurtis or somebody was working on it...
tadzik there''s a ticket for Select PMC 09:30
I remember poking cotto about reviewing it again :)
09:39 woosley left 09:49 rurban_ joined 09:51 rurban left 09:52 rurban_ is now known as rurban 09:59 contingencyplan left 10:06 TiMBuS left, tcurtis left, KaeseEs left 10:10 birdwindupbird joined 10:48 woosley joined
bacek moritz, ping 11:32
aloha, humans (btw)
moritz bacek: pong 11:33
bacek moritz, aloha
moritz, can you rerun your benchmark on parrot master with patch from lists.parrot.org/pipermail/parrot-d...05837.html ?
(benchmark from "Rakudo compilation times from 3.0.0 to now") 11:34
moritz bacek: will do
bacek moritz, thanks!
11:41 KaeseEs joined, tcurtis joined 11:43 darbelo joined 11:51 mtk0 left 11:56 mtk joined 11:59 mtk left 12:04 mtk joined 12:07 birdwindupbird left 12:13 lucian joined 12:32 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner 12:36 birdwindupbird joined 12:42 whiteknight joined
whiteknight good morning, #parrot 12:44
tadzik good morning whiteknight 12:45
moritz bacek: 26% speedup with the patch from the mailinglist
whiteknight 26%? Not bad at all
that definitely puts the numbers into the range we thought they should have been in
moritz aye 12:46
12:50 hudnix joined
whiteknight good thing the Rakudo guys caught that regression, that's kind of embarrasing 12:51
pmichaud here are my results
github.com/pmichaud/rakbench/blob/...051910.txt 12:52
moritz: 26% speedup was for ... ?
moritz pmichaud: the patch that bacek posted to the mailing list
pmichaud I mean, what was being timed? 12:53
core.pm? spectests?
moritz core.pm -> perl6 executable
pmichaud yeah, I only have a 12% speedup.
which is definitely better than the 47% slowdown that 3.3 had 12:54
whiteknight that sin.t test has me befuddled
I suspect strongly that it is not a GC-intensive test
pmichaud well, bacek's 3.3 patch did improve the timing on that substantially
so gc is a part, but there's another part that is slowing things down somewhere 12:55
whiteknight and if GC got faster overall, that means we must have regressed somewhere else if the timing of that test stayed at 100%
right
pmichaud there's definitely been some regressions in other parts of parrot, I think
actually, I can prove it -- I can run the tests with gc=ms2 :-P
that will show a huge regression 12:56
whiteknight yeah, we are going to have to track those down
we should be significantly faster now, methinks 12:57
pmichaud I'm getting a new (supposedly very fast) computer later today, so I should be able to run more benchmarks on it
anyway, the commontest stats at the bottom are also revealing -- we've still only improved by 1.1% since january 12:58
(I've modified the script to run two trials there instead of just one... but that does add two hours to the time needed to run everything :-| ) 12:59
whiteknight We're really feeling the absence of chromatic. He's always been very good keeping up with optimizations and hunting down hotspots
it's not that nobody else does that kind of work, but nobody does it as regularly
pmichaud I'll build a ms2 version of 3.3 with bacek's patch, just so we can see the slowdown 13:01
13:02 bubaflub joined
whiteknight There should be a way to specify the intended gc core in pbc_to_exe, to save you the effort 13:02
I don't know if there is, but there should be
13:02 bluescreen joined
pmichaud that feels like it wants a trac ticket :) 13:03
whiteknight let me double check things before I declare there to be a problem
13:06 darbelo left 13:08 bluescreen left, bluescreen joined 13:13 UltraDM joined
whiteknight no, pbc_to_exe does not have that option 13:17
it really should
I think it also really should be rewritten in NQP or Winxed :)
tadzik is that pir? 13:18
whiteknight yessir
atrodo winxed++ 13:19
karma winxed
aloha winxed has karma of 2.
atrodo karma Winxed
aloha Winxed has karma of 2.
atrodo wow, that's it?
13:23 ambs joined, plobsing left, plobsing joined
coke_ karma parrot 13:24
aloha parrot has karma of 7.
coke_ I suspect that the "import old karma" step never happened. ;)
karma Coke
aloha Coke has karma of 195.
coke_ that cool refreshing drink
whiteknight I'm testing a quick patch that should allow pbc_to_exe to take a --gc= option 13:29
then we can test Rakudo on different GCs without rebuilding Parrot, only changing the Makefile
13:35 kid51 joined
kid51 Trac unavailable with 503 error; have filed bug ticket with OSUOSL 13:35
13:37 lateau joined
kid51 Looks like Smolder needs a restart as well. 13:39
13:39 darbelo joined
whiteknight blarg 13:46
I haven't contacted OSU yet
ah nevermind. it appears kid51++ already has 13:50
kid51 I'm hoping we haven't been hacked. The non-functioning of my account yesterday was very surprising.
But it's very early here on the Left Coast, so nothing will happen with the ticket for several hours 13:51
whiteknight yeah, that's probably true 13:52
kid51 afk
13:53 darbelo_ joined, darbelo left 14:02 ambs left 14:03 ambs joined
kid51 master w/bacek patch: linux/i386: make fulltest PASS 14:11
dalek rrot: 49f46ec | Whiteknight++ | tools/dev/pbc_to_exe.pir:
Add a provisional --gc= option to pbc_to_exe.
whiteknight pmichaud: I just committed a new --gc= option to pbc_to_exe. After you update and build with that, you should be able to change the gc used by rakudo with a simple change to the Makefile 14:12
no more rebuilding parrot for comparisons 14:13
pmichaud whiteknight: excellent, thanks
although that doesn't really help with the older releases :)
and, at least from my experiments over the past few days, the overall timing is *very* sensitive to the parrot build itself
whiteknight we could create branches from the old tags and cherry-pick that commit, if we were feeling productive
pmichaud I prefer to benchmark the actual releases, though, instead of branches 14:14
whiteknight well, this should allow us to narrow down sources of fluctuations
pmichaud yes, I agree there.
allison Linus on GC: gcc.gnu.org/ml/gcc/2002-08/msg00552.html 14:15
moritz that's... not new at all.
allison moritz: yup 14:17
moritz: it does make sense though, the kernel is a very different use case than a high-level language implementation
moritz allison: agreed 14:18
pmichaud "Yes, I generalize. Don't we all?" Linus++
moritz oh, another autopun :-)
where's masak? :-)
whiteknight I love his work on the kernel, but his opinions about most other computing topics are....off 14:20
his rants against C++ for instance are humorous, but ignorant 14:21
moritz his rants against users of centralized version control systems are just stupid and offensive
whiteknight one good point he did make in that mail about GC was the fact that GC is typically very unfriendly to cache locality
14:22 woosley left
whiteknight moritz: yes, those too. We all understand that he made git and he likes git, but that doesn't mean it is the way, the truth, and the life 14:22
refcounting, he correctly points out, is probably much better on the cache
moritz ... and comes with other problems we all know about 14:23
kid51 master w/bacek patch: darwin/ppc: make test PASS
14:23 ambs_ joined 14:24 ambs left, ambs_ is now known as ambs
whiteknight moritz: are refcount updates any more intrusive than GMS write barriers? It's not a clear-cut victory for either side 14:27
plus, I suspect we could come up with gc algorithms which are more friendly on the cache
moritz whiteknight: I'm not talking about the updates, but about circular data structures 14:28
14:38 lateau1 joined
sorear one other problem with refcounting is that it requires locking (or atomic operations) in a multi-CPU case 14:40
probably not much of a problem with Linux because it doesn't need to juggle links very often 14:41
14:43 lateau left
plobsing refcount updates can be done without locking on multi-cpu. atomic increment/decrement are usually (always?) implementable with the hardware's concurrency primatives 14:44
that would be a lot faster than locking 14:45
kid51 whiteknight: OSU OSL has restarted Trac, which enable me to do a password reset. No further action needed on your part at this time. Thanks.
NotFound The problem I see with a refcounting engine is that in general purpose language or machine, forbiding structrures with circular references is not a realistic option. 14:46
plobsing msg dukeleto I had hoped the problem might be an architecture-only problem. thanks for testing. 14:47
aloha OK. I'll deliver the message.
kid51 Hmm, maybe I spoke too soon.
plobsing NotFound: IIUC, python runs a cycle collector periodically to deal with that problem 14:48
NotFound How does that? Stoping the world? 14:49
lucian plobsing: it does
NotFound: possibly, i'm not sure
it has very little work to do, though
14:50 lateau1 left
plobsing lucian: docs.python.org/extending/extending...nce-counts 14:52
14:53 UltraDM left 14:54 kid51 left
whiteknight I'm certainly not suggesting we move to refcounting. I'm only saying that Linus has a point about cache locality 14:54
And I suspect a GC algorithm could be developed which is much more friendly to the cache
for instance, using pointer prefixes to sort items into bins according to how close together they live, then marking bins at once 14:55
if the item is in the current bin, mark it directly. Otherwise, put it in the bin to mark it later 14:56
pmichaud gist.github.com/959083 # results of rakbench on 2011.04 with gms and ms2 14:57
lucian whiteknight: i'm not convinced cache locality is the lowest hanging fruit
plobsing I'm sure the guys at Azul have some solution to the problem.
pmichaud click the "raw" link for an easier-to-read version
whiteknight lucian: I didn't say it was. I'm just saying that if it's a problem, I'm sure there are solutions for it
lucian: I'm positive that our GC can be tuned and optimized pretty aggressively as it is, without worrying about changing the algorithm 14:58
lucian whiteknight: yeah. also, i'm not convinced refcounting is actually better with cache locality. i've yet to see conclusive evidence (perhaps i've missed it)
that too
whiteknight lucian: it makes good logical sense. When you're using the object and have it in memory, you twiddle the refcount which is in the same place 14:59
lucian: as opposed to GC, where you mark items that you are not currently using and do not have in cache
lucian whiteknight: sure, but you do it all the time, for all sorts of objects, in all sorts of places 15:00
GC happens at one point, and the GC's own code gets cached just fine
whiteknight lucian: that doesn't make it right. Plus, GC doesn't need to be adding to a problem just because everybody else does it
plobsing refcounting has advantages and disadvantages. another refcount advantage is on non-memory resource handles, which don't map well to GC
lucian nods at plobsing++
whiteknight GC is one of those things that should be low-level, tucked away, and fast
plobsing whiteknight: the problem with refcount collocated with the object is with COW forking 15:01
because twiddling the refcount marks the page dirty
15:02 mj41 left
whiteknight We don't currently use COW for pmcs, and likely won't in the future 15:02
COW is a bear to deal with in a threaded context
plobsing parrot doesn't, but your kernel does
dukeleto thinks our trac and website got borked because smolder ate all the memory
smolder--
plobsing COW (and its effect on their zygote-forking approach) is why google went to such great lengths to separate their GC information from their objects 15:03
pmichaud what machine/os information would be good to capture in these benchmark reports? 15:04
moritz architecture, register width, OS, gcc version (IMHO)
pmichaud architecture == uname -i ? 15:05
15:05 TiMBuS joined 15:07 benabik left
whiteknight brb. firefox fail 15:11
15:11 whiteknight left
pmichaud flussence++ on #perl6 says "lscpu", so I'll use that. :) 15:12
15:24 davidfetter joined
dukeleto msg cotto i added the PDS to the parrot calendar 15:26
aloha OK. I'll deliver the message.
15:26 hercynium joined 15:33 simcop2387_ joined 15:35 simcop2387 left, simcop2387_ is now known as simcop2387 15:46 theory joined 16:04 whiteknight joined 16:11 benabik joined 16:17 contingencyplan joined 16:20 lucian left 16:23 theory left
dalek rrot/m0-prototype: 237f12a | dukeleto++ | / (8 files):
Merge remote branch 'origin/m0-prototype' into m0-prototype

Conflicts:
  \tsrc/m0/m0_assembler.pl		 16:28
16:32 apt415 left
whiteknight interesting presntation about GC ane exceptions in Java: www.slideshare.net/eplawless/except...ther-stuff 16:34
NotFound I'd like to see parrot running on this: www.raspberrypi.org/ 16:36
whiteknight yes, that would be fun 16:38
"If PHP gets something right before your language does, you should reassess your life goals" 16:42
that's a quote I might keep in my heart forever 16:43
cotto Who said that?
whiteknight that's on that link I posted above
NotFound I don't think beating php at anything must be a language design principle.
whiteknight bottom of slide 16
cotto perfect 16:44
16:48 mtk left 16:50 mtk joined 16:57 birdwindupbird left
cotto_work ~~ 17:11
17:21 dodathome joined 17:25 whiteknight left 17:41 whiteknight joined 17:49 rurban_ joined 17:51 rurban left 17:52 rurban_ is now known as rurban
cotto_work It's quiet. 18:46
benabik Too quiet.
18:47 ZOMBIES joined
plobsing 3 quiet 18:48
ZOMBIES BRAAAIIIIINNNSSSSS
18:48 ZOMBIES left
whiteknight it's depressing that a zombie looking for brains wouldn't hang out in #parrot for longer :( 18:48
cotto_work It could be anyone. Mibbit's nice like that. 18:49
plobsing I like to think they got what they wanted and left 18:50
mission accomplished #parrot!
19:15 theory joined
dukeleto cotto_work: new jitterbug URL is jitterbug.leto.net 19:20
19:20 jevin joined
dukeleto jevin: welcome to #parrot 19:20
19:24 davidfetter left 19:27 ambs left 19:33 ambs joined
cotto_work dukeleto: what's wrong with the Rakudo build? 20:06
Your jitterbug install doesn't show any successful builds. 20:07
tcurtis ~~ 20:17
whiteknight hello tcurtis 20:22
20:24 davidfetter joined 20:25 ShaneC left 20:32 bluescreen left 20:33 dodathome left 20:39 ShaneC joined
plobsing an interesting data point for the 3.0-3.1 regression: valgrind shows the reverse. 3.0 ran 6,548,083,721 instructions vs 3.1's 6,068,114,582 on the Ωη benchmark which exhibits similar behaviour to rakudo. by valgrind, 3.1 is 7.3% faster than 3.0. 20:41
benabik plobsing: Did it spend more time in I/O? Swap? Just more expensive instructions? 20:43
plobsing benabik: that program doesn't really do any IO (besides slurping in a file) and I have swap dissabled
benabik plobsing: So the CPU just does less work in more time. Boo. 20:44
plobsing I could understand cache playing a part in a disparity between valgrind results and wallclock timings, but this is just too big for that
whiteknight that's half a billion fewer instructions 20:46
plobsing yeah, like I said, it's huge
I'm firing up cachegrind to see if my cache hunch is accurate 20:48
benabik whiteknight: Modern processors execute something like 20 billion instructions per second. 20:49
plobsing benabik: only if they're running full-out. that rarely happens. 20:50
benabik plobsing: Yes, but a half billion still goes by pretty quick. 20:51
20:52 bacek left 20:55 jsut joined 20:58 benabik left 20:59 sjn left, dolmen joined 21:00 jsut_ left
whiteknight benabik: in modern computers, the CPU is rarely the bottleneck. If each of those half-billion instructions case a hit to memory or disk (even worse) that can take a hell of a long time 21:00
I'm sure most of those aren't so naughty, but it can be worse than the CPU throughput numbers indicate
21:02 whiteknight left, bacek joined 21:05 ShaneC left
dukeleto cotto_work: jitterbug is messed up with respect to the rakudo test suite, nothing is wrong with rakudo 21:07
Tene "You can take my deterministic resource management when my cold dead hand goes out of scope." -- GC exceptions presentation 21:08
dukeleto lulz 21:09
cotto_work I don't know who eplawless is, but I want to hear him or her speak. 21:11
www.ericlawless.com/
cotto_work makes a note for future conferences 21:17
plobsing the only large cache difference I can see is a 1% increase in the branch mispredict rate, but that is partly due to a decreased amount of branching done 21:22
21:24 ambs left 21:25 hercynium left
cotto_work dukeleto: is jitterbug good enough that we could replace smolder with it? 21:29
Tene cotto_work: that's the eventual plan, at least. 21:31
cotto_work Is someone with a trac admin bit logged in? 21:34
my password suddenly doesn't work 21:35
dukeleto cotto_work: i think all our admin accounts were lost or our trac instance got hacked. not quite sure 21:37
cotto_work That's not good.
dukeleto cotto_work: one difference between smolder and jitterbug is that jitterbug is a dedicated client where smolder allows anybody to submit reports. It is a slightly different model
cotto_work: yeah, it's not good. 21:38
cotto_work: kid51++ noticed first, he sent a ticket to OSUOSL already
cotto_work ok
kid51++
21:40 darbelo joined, darbelo_ left
cotto_work It's times like this that I'm glad I use a generated password and a password manager. 21:42
At least the drupal site is fine. 21:43
dukeleto cotto_work: yep, me too 21:44
cotto_work dukeleto: did you try resetting your password? 21:45
21:46 darbelo left
dukeleto cotto_work: i haven't touched trac yet, just saw some emails fly by 21:48
21:51 darbelo joined 21:52 darbelo_ joined, darbelo left
dukeleto cotto_work: the OSL peeps seem to think it was a full disk a 22:01
cotto_work: does your old password work now?
cotto_work dukeleto: no joy 22:02
dalek rrot/m0-prototype: 71edc13 | dukeleto++ | / (2 files):
Add a test for detecting an invalid M0 version
 22:09
rrot/m0-prototype: 0137f68 | dukeleto++ | / (4 files):
Add test for invalid bytecode and add invalid version m0
rrot/m0-prototype: 02b432b | dukeleto++ | / (2 files):
Parse op table and add a test
rrot/m0-prototype: c544f51 | cotto++ | t/m0/m0 (2 files):
rename a test for better clarity and tab completion
 22:27
darbelo_ ~~ 22:32
22:58 fperrad left 22:59 darbelo_ left 23:07 bubaflub left 23:15 mtk left
wagle trac.parrot.org/parrot/wiki/LoritoRoadmap doesnt say what lorito is? 23:16
dukeleto wagle: trac.parrot.org/parrot/wiki/Lorito 23:17
PerlJam maybe occurences of "Lorito" in that first one should link to the second one :) 23:18
wagle yeah, something like that.. at least one occurance.. 8) 23:19
dalek nxed: r975 | NotFound++ | trunk/winxedst0.cpp:
fix an addparent misindentation in stage 0
 23:21
wagle tries to do it himself.. waits.. waits 23:23
23:31 kid51 joined
wagle apparently trac.parrot.org doesnt want to let me in.. i just sit and wait to login 23:33
kid51 wagle: You are not alone ... either in the universe or your inability to login.
wagle 8) 23:34
kid51 Just updated OSUOSL on the situation 23:36
The wiki is viewable but not log-in-able hence not editable. 23:37
At least git has not been touched by these troubles. 23:40
cotto_work nope. git++ and github++ 23:41
kid51 Oh, that's right, our repository is NOT at parrot.org 23:42
wagle oh look! trac woke up! 23:44
kid51 Huh? Can you login? I cannot.
wagle it sent me two new passwords.. neither work 23:45
kid51 This morning, after it (briefly) came back to life, it sent me a new password .... which no longer works. 23:46
So I doubt we're cured.
wagle wheee 23:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!