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.
whiteknight I think we can abstract the underlying threading model from HLLs pretty well 00:00
that's precisely why I like the idea of a thread pool and dispatchable messages/tasklets
you make tasks for the things in your program, and don't have to worry how many threads there are, or how they are implemented internally
I absolutely do not want to expose posix threads directly 00:01
we can build an interface that looks like posix threads on top of our system, but we need an abstraction
plobsing I absolutely do not want to care about that discussion.
whiteknight okay. shelved 00:02
00:02 _dolmen_ left
plobsing the thing about a concurrent GC (as awesome as that sounds), is that we don't have one right now. 00:02
whiteknight we also don't have threads right now to be safe with 00:03
your zeromq bindings withstanding
plobsing and mod_parrot as well?
whiteknight do we have mod_parrot
?
we *did* have it
I can't say we do anymore
plobsing it exists in a state of disrepair, true.
but if we were to attempt to recycle or rewrite, it would be mostly pointless without thread-safety. 00:04
whiteknight as Parrot-Instrument demonstrates, if we don't have it in working order, we don't have it
Okay. So step one is a first-pass, best effort implementation of thread safety? 00:05
followed by threads, fixes to thread safety, and the great blue yonder?
plobsing yes, that sounds about right.
whiteknight I can find no fault there. We need to decide what our thread-safety mechanism is 00:06
a big portion of my threading idea was the need to avoid sharing data at the user level. If we go with that, we only need to worry about securing data internally
and if each thread gets its own read-only proxies and it's own interp/thread, we can avoid sharing data between them without messages 00:07
so what we need is to secure the GC, and have thread-safe message mailboxes
mailboxes can come from a library, there are plenty to choose from 00:08
which leads us to the GC
and maybe the solution is for us to start writing a concurrent GC core right now so we have it
plobsing we could punt and just throw in a global-allocator-lock for the moment. 00:09
whiteknight we could, but I really hate that idea
it's just one step short of a global interpreter lock
00:09 cosimo joined
plobsing but it isn't nearly as bad because it is relinquished much more frequently 00:09
and not all of parrot's operations allocate. a fair number of them (the majority?) do, but not all. 00:12
whiteknight do we implement our own locks, which is going to require at least a CAS on every platform we support, or do we use a locking library?
plobsing we already have a lock abstraction 00:13
whiteknight barely.
plobsing and I'm generally against going lower than the platform-provided threading abstraction. requiring CAS rules out SPARC for example
at least according to liblfds
whiteknight I know what you're trying to say about how we have stuff and we don't need to start from scratch. I'm of the opinion that what we have is worse than nothing
I'm not trying to be dismissive or pessimistic about it, I sincerely believe we can do better with a clean slate 00:16
plobsing I think there are some useful primitives out of which something that isn't quite functional has been built. 00:20
for example, the platform (pthread/win32) thread stuff is fairly vanilla.
whiteknight is it worth the effort to pick through the rubble looking for the occasional thing of value, then fixing it and applying it consistently?
plobsing there is no point rewritting something that will come out nearly identical no matter how many times you delete and rewrite 00:21
00:22 davidfetter left
plobsing you mentioned earlier that there were several good thread-safe mailbox libraries available. do you have favorites? 00:23
00:23 kid51_at_dinner is now known as kid51
whiteknight not at the moment. I haven't dug into it deeply enough into any of them to pick favorites 00:23
My thinking has all been very preliminary so far. I wasn't expecting to do any serious work on threading until fall at the earliest 00:28
plobsing that would be an important decision, and one that can be made early-on 00:30
whiteknight I take it you are more keen to get working on this sooner rather than later?
plobsing I'm keen on getting *something* working. It doesn't have to be full, user-visisble threads.
whiteknight ok 00:31
plobsing I'd like to see Parrot useable for web applications for at least one multi-platform webserver. Apache needs threads, mongrel needs zeromq, fastcgi needs concurrency related things like sockets which we've currently implemented piecemeal. 00:33
whiteknight What I really want to do is avoid complete interp clones for each thread. I really would like to avoid that 00:34
but I feel like breaking the interp up in the way it really needs to be is going to be a hassle
nd it's going to require a deprecation poin
point
plobsing once we have a coherent base, I think a lot of things will fall out as one-off projects, implementable by individuals when the motivation strikes them because the design is already there
whiteknight I like the concept. I'm having trouble getting around my own extreme demotivation to work on our current rotten threads system 00:36
I can definitely start researching libraries 00:38
00:38 bubaflub joined
whiteknight I do have 6model pretty high up on my priorities list, but I can interleave this with that 00:38
plobsing it is important to me (which is why I've brought it up), so I'm willing to do some work on it. But I'm no architect. 00:42
whiteknight you keep saying that. You either underestimate, or misrepresent yourself, methinks 00:43
okay. if you dust off the lock abstraction, we can find a way to fill it with working code 00:44
apply a handful of locks to critical portions of code, then move forward from there 00:45
sound good?
plobsing sounds good
whiteknight then we have an accord
:)
if we can find a portable library which implements some concurrency primitives and message passing routines, that would be a great start
kid51 plobsing: Good news: tt1931-nci-parameters-deprecation has built successfully on Darwin/PPC at commit dc68cb00c10315c30fd5a7a0456a7673839e7e3d 00:46
make test now running
msg cotto Your LFNW slides look much better than first draft
aloha OK. I'll deliver the message.
plobsing kid51: that's great news. if I can get the PPC pass, I can get that thing merged
cotto_work kid51: thanks 00:47
I think they're still to wordy. I also want to try to make it easier to remember what all the various abbreviations are.
kid51 plobsing: But in view of today's discussion about performance impacts, have you benchmarked this branch+Rakudo vs master+Rakudo? 00:48
plobsing kid51: I have not. I will do so. 00:49
whiteknight is heading to bed 00:57
goodnight
00:58 whiteknight left
cotto_work That seems to have gone well. 00:59
atrodo cotto_work> I actually had the pleasure of sitting with Randall Schwartz at the YAPC::NA dinner last year 01:02
cotto_work I got to hang out with him on Saturday evening too. He's quite approachable. 01:05
That's one of the things I like most about conferences. 01:09
kid51 could have gone out drinking with Randall Schwartz tonight! 01:10
But, since we were out with a leading French perlmonger last night, I took a pass.
plobsing: Getting one test failure.
Hmm: In 'make test', I got this: 01:12
t/compilers/pct/complete_workflow.t Failed tests: 43-44 Non-zero exit status: 2
Parse errors: Bad plan. You planned 54 tests but ran 44
But, running the file with 'prove', everything passed.
smolder.parrot.org/app/projects/rep...ails/16122 01:13
plobsing this looks like more of that flaky behaviour we saw earlier when you run things under 'make' 01:19
I'm not sure what your make program is doing, but I suspect it is modifying the environment somehow 01:20
kid51 I have never seen that failure before, on either box
And I have never had to peek into that particular test file before, either. 01:21
plobsing src/gc/gc_gms.c:1231: failed assertion '!PObj_on_free_list_TEST(pmc) || !"Resurrecting of dead objects is not supported"'
that's the same failed assertion 01:22
kid51 I'm not sure what earlier flaky behavior you are referring to. Usually, 'make' gives me less problems than 'prove'
Hmm, I didn't look at the smolder directly
plobsing the next test fails because of file not found and the whole test bails because of it. I suspect that test 43 is supposed to create a file. 01:23
dalek rrot/m0-spec: b079ec9 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add an exception-related TODO to the M0 spec
kid51 The file consists of several blocks, and yes, files are to be created.
plobsing kid51: the flaky behaviour I was alluding to was your problems building parrot. 01:24
kid51 Ah, yes. And we've gotten that error in the past as well.
01:25 Andy joined
plobsing kid51: what type of make is it? GNU? custom apple? 01:27
cotto_work decommutes 01:37
01:37 woosley joined
kid51 GNU Make 3.80 01:42
Bad news: When I configure and build with all g++, 'make' fails
plobsing with?
nopaste "kid51" at 192.168.1.3 pasted "tt1931-nci-parameters-deprecation branch on Darwin/PPC: all g++ build: 'make' fails" (770 lines) at nopaste.snit.ch/43359 01:45
01:45 rurban_ joined
plobsing again with that failing assertion! can you run the program that failed outside of make to see if it is the make problem again? 01:47
01:47 rurban left 01:48 rurban_ is now known as rurban
kid51 ./parrot-nqp --target=pir --output=compilers/opsc/gen/Ops/Compiler/Grammar.pir compilers/opsc/src/Ops/Compiler/Grammar.pm completed 01:48
IIRC, when I then called 'make' to resume the build, I got one more similar failure, treated in the same way. 01:49
Yes this next failed:
./parrot-nqp --target=pir --output=compilers/opsc/gen/Ops/Trans/C.pir compilers/opsc/src/Ops/Trans/C.pm
And that command also succeeded when run just on its own. 01:50
This is the same version of 'make' I have used for 5 years.
Configuring here with g++ foreach of cc, link and ld (my normal thing is gcc for cc, g++ for the others) 01:51
And now make is continuing onward
... but I spoke too soon 01:52
Failed with same error here:
./ops2c --dynamic src/dynoplibs/obscure.ops --quiet
01:52 dmalcolm left
bubaflub kid51: could it be related to the new GC failing intermittently / or when certain memory conditions are hit? 01:53
kid51 On this machine, 'master' has been building with what is now default GC 01:54
plobsing bubaflub: that wouldn't explain why it consistently fails when run under make and consistently runs when run individually 01:55
kid51 g++ is finding something it doesn't like that gcc apparently tolerates
bubaflub plobsing: true.
kid51 So, 'make' completed -- after 3 restarts :-(
bubaflub kid51: isn't that usually pointer casts and such? i'm not sure what would cause that assertion failure. does it always happen in the same file / same place?
wish i could help test but i don't have access to a PPC machine 01:56
kid51 bubaflub: Over the past week, depending on which patch plobsing has been asking me to test, we've gotten the same assertion failure in different places -- but apparently consistent re location for any one patch
bubaflub kid51: ok. 01:57
kid51 Am now trying to smolder -- but going to bed soon
KaeseEs sort of a philosophical question, what's the rationale behind having (rather) high level stuff like print directly as an opcode for m0? 01:58
kid51 KaeseEs: When cotto gets back from cotto_work, he'll probably be able to answer that question 01:59
KaeseEs okey dokey :)
plobsing kid51: probably not a terribly good long-term plan, but you could try commenting out the assertion and crossing your fingers 02:04
dukeleto ~~ 02:10
bubaflub hola dukeleto 02:13
dukeleto bubaflub: wazzup 02:18
bubaflub dukeleto: writing a final paper, listening to the Black Keys. you?
kid51 and on this all=g++ attempt, we once again get one file failing in 'make test': 02:29
smolder.parrot.org/app/projects/tap.../16127/309
different file -- t/compilers/opsc/06-opsfile.t -- but same reason: failed assertion '!PObj_on_free_list_TEST(pmc) || !"Resurrecting of dead objects is not supported"' 02:30
with that, sleep
02:30 kid51 left
dukeleto bubaflub: oooh, Black Keys is good. Trying to backlog from #ps today 02:30
blarg 02:31
02:31 ShaneC joined
atrodo KaeseEs> the print op in m0 is suppose to be temporary, meant for bootstrapping 02:36
plobsing core.pm > core.pir timings (3-run avg) master: 367.73s tt1931: 358.69s
conclusion: no significant impact
bubaflub plobsing: you're referring to your NCI deprecations branch? 02:38
plobsing yes
bubaflub ok.
plobsing kid51 asked for benchmarking
02:39 rohit_nsit08 left
dukeleto => self.nom() 02:39
02:43 ShaneC left
plobsing do we have any other PPC developpers in the Parrot community? 02:47
02:48 hudnix left 02:49 mtk0 left
bubaflub plobsing: trac.parrot.org/parrot/wiki/ListOfPlatforms lists only dukeleto and kid51 02:51
best bet might be to hit the mailing list
02:56 mtk0 joined 03:00 jrt4__ joined
plobsing ping dukeleto 03:03
03:05 Andy left
dalek rrot/tt1931-nci-parameters-deprecation: 1149c70 | moritz++ | / (2 files):
Revert "now that PMCNULL is not NULL, we can update function annotations"

This reverts commit c1f77f7eb90041468c3b13f5b48ae2ca1d1c37a5. It broke several rakudo spectests, see TT #2104		 03:09
rrot/tt1931-nci-parameters-deprecation: dc5f4cf | mikehh++ | src/call/pcc.c:
add missing ASSERT_ARGS
rrot/tt1931-nci-parameters-deprecation: cccbf37 | mikehh++ | src/debug.c:
add missing ASSERT_ARGS
rrot/tt1931-nci-parameters-deprecation: 8b0397b | mikehh++ | src/debug.c:
add missing documentation
rrot/tt1931-nci-parameters-deprecation: e3ecaf8 | mikehh++ | src/gc/gc_ms.c:
add missing documentation
rrot/tt1931-nci-parameters-deprecation: 56d903b | plobsing++ | / (57 files):
Merge branch 'master' into tt1931-nci-parameters-deprecation
03:33 rohit_nsit08 joined 03:34 rohit_nsit08 left
bacek_at_work seen jnthn__ 03:49
aloha jnthn__ was last seen in #parrot 8 hours 39 mins ago saying "pmichaud: #phasers is on at the moment, btw :)".
bacek_at_work msg jnthn__ on which platform are you? (Related to gist.github.com/953615 results) 03:50
aloha OK. I'll deliver the message.
cotto ~~ 04:16
KaeseEs, atrodo is correct. The ops in the "temporary" category only exist to make life easier for implementors. Once M0 interps start to mature, we'll take them out. 04:19
dukeleto ~~
KaeseEs is it intended they get moved up to m1/m2/mX or to HLLs entirely (with some sort of 'a syscall goes here!' instr presumably left in lower levels) 04:20
cotto KaeseEs, it'll be done via the ffi ops and calls to Parrot_sprintf or something similar 04:21
KaeseEs ah-ha. 04:22
cotto That'll be the primary mechanism for interacting with any C code, wither internal to Parrot or external. 04:23
04:30 bubaflub left
cotto seen allison 04:47
aloha allison was last seen in #parrot 4 days 9 hours ago saying "Andy: sure, Ubuntu brain available for query at any time :)".
dukeleto cotto: what are you hacking on? 04:54
cotto dukeleto, sending out the pds notice
followed by looking at the rakudo slowdown, followed by thinking about the structure of the M0 interp
y tu? 04:55
dalek rrot-instrument: fa403a9 | dukeleto++ | LICENSE:
Add a LICENSE
dukeleto cotto: trying to get back on my M0 wagon
cotto: and dealing with odd git error due to my harddrive wonking out: gist.github.com/954763#comments 04:56
benabik: you got any clue how to fix gist.github.com/954763 ? 04:57
cotto ouch
dukeleto, ssd?
dukeleto cotto: nope
cotto: wonky normal harddrive
cotto: but encrypted filesystems could be to blame
cotto: encrypted filesystems do not fail gracefully when hardware goes to wonkytown 04:58
cotto you can always bundle any unpushed commits, nuke and reclone
dukeleto cotto: yep. but i am crazy enough to want to understand what is going on :) 04:59
cotto your call
not sure why you'd want to try to understand what looks like a hardware failure though
dukeleto cotto: well, i feel that there should be a git util to repair this, I guess 05:00
cotto: i want lose too much sleep over it
cotto git fsck?
dukeleto s/want/won't/
cotto: good idea 05:01
cotto: that seems to be doing something. genius!
cotto: almost every other git command was erroring out
cotto: ooh, it spit out even more mysterious junk
cotto sounds like a win 05:02
benabik dukeleto: It looks like you're missing objects. 05:11
dukeleto: Did you have to kill a fetch recently?
dukeleto: I'd suggest moving the pack object git was complaining about and trying fsck again. .git/objects/pack/pack-43a2872bd320ca70652c13c47aa933d2cab5cac7.pack might be the corrupt one. 05:12
benabik is going AFK again.
cotto aloha, clock? 05:14
aloha cotto: LAX: Tue, 22:14 PDT / CHI: Wed, 00:14 CDT / NYC: Wed, 01:14 EDT / UTC: Wed, 05:14 UTC / LON: Wed, 06:14 BST / BER: Wed, 07:14 CEST / TOK: Wed, 14:14 JST / SYD: Wed, 15:14 EST
dukeleto benabik: yep, tried that. no avail. 05:17
cotto what's the right rakudo-related list to send the PDS date to, if any? 05:18
dukeleto cotto: perl6-compiler 05:21
cotto: possibly perl6-users as well
05:22 woosley1 joined 05:23 woosley left 05:31 woosley1 left 05:35 jsut joined 05:40 jsut_ left
benabik dukeleto: You could try `git prune` 05:40
05:41 birdwindupbird joined 05:50 jsut left 05:54 woosley joined
cotto dukeleto, is it a good idea to build a backup strategy around bup? 05:56
dukeleto cotto: that is what i plan to do, but haven't yet 05:57
benabik: git prune gives the same errors :(
cotto Apparently SSDs are mostly ticking time bombs that will almost certainly self-destruct within two years or so. 05:58
dukeleto cotto: why do you say that ? 06:01
cotto: and by self-destruct you mean lose writability and performance?
cotto: because their failure mode is being write-only, not data loss
cotto news.ycombinator.com/item?id=2505700 06:02
ymmv
dukeleto it always doess
does, even
cotto: lots of noise in that 06:03
cotto: not quite scientific ;)
cotto dukeleto, sure. It's a good motivation to start regular backups, even if it's a very noisy and limited data set. 06:04
dukeleto cotto: backups are always a good idea
cotto dukeleto, exactly 06:05
KaeseEs i am more skeptical than normal of anything where jeff atwood is the source
cotto KaeseEs, yeah. codinghorror stopped being on my list of rss feeds a while ago 06:06
06:12 Andy joined 06:22 Andy left
benabik dukeleto: Try `git repack -Ad && git prune`. It should put all "good" objects into a single pack and remove the excess. 06:24
06:33 UltraDM joined 06:35 fperrad joined
dalek rrot/tt1589_library_path: 98a30cc | dukeleto++ | / (3 files):
[t][TT #1589] Apply patch from soh_cah_toa++ with small tweaks and an extra test
 06:47
dukeleto benabik: alas, the same errors 07:03
07:05 theory left
cotto dukeleto, what do you think about adding a count of the number of elements in each chunk to the M0 spec? 07:15
07:23 particle1 joined 07:26 particle left 07:35 mj41 joined 07:44 spinclad left, spinclad joined
dalek rrot/m0-spec: 4b9eb13 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add element count to all M0 chunk segments
 07:56
rrot/m0-prototype: 29165dc | cotto++ | src/m0/m0_interp.pl:
stub out bytecode loading in the M0 interp
rrot/m0-prototype: 5aad56f | cotto++ | t/m0/m0bgen.t:
implement element count in chunks, clean up code a bit
rrot/m0-spec: b971810 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
specify a proper magic number, taken from PackFile_Header_validate
 08:05
rrot/m0-prototype: 72889c0 | cotto++ | t/m0/m0bgen.t:
switch to new magic number for generated m0b tests
cotto definitely time for sleep. dukeleto, comments appreciated 08:06
'night 08:07
dalek p: 625f17d | moritz++ | t/p6regex/rx_backtrack:
[t] fix a simple backtrack test
 08:13
p: 4b653ba | moritz++ | src/core/testing.pm:
implement todo()
p: 8fc008a | moritz++ | t/p6regex/01-regex.t:
remove outdated comment from 01-regex.t
08:16 cosimo left
bacek ~~ 08:21
dalek p: de3220e | moritz++ | t/p6regex/01-regex.t (2 files):
[t/p6regex] disable broken PIR script for now
 08:27
p: 48d0448 | moritz++ | t/p6regex/01-regex.t:
[t/p6eregex] add first shot of regex test runner
p: b1d4c13 | moritz++ | t/p6regex/01-regex.t:
[t/p6regex] start to expand backslash escapes
 08:37
p: 3d43ac9 | moritz++ | t/p6regex/01-regex.t:
[t/p6regex] also expand \\xBEEF escapes
 08:49
08:51 jrt4__ left 09:14 birdwindupbird left, birdwindupbird joined
dalek p: 9a5e02f | moritz++ | t/p6regex/ (3 files):
[t/p6regex] update error message wording
 09:28
p: 221501e | moritz++ | t/p6regex/01-regex.t:
[t/p6regex] skip looping tests for now; emit late plan
 09:35
09:37 birdwindupbird left 09:38 birdwindupbird joined, birdwindupbird left 09:47 rurban_ joined 09:49 rurban left, rurban_ is now known as rurban
dalek p: f480bab | moritz++ | build/Makefile.in:
[build] run p6regex tests with nqp
 09:56
jnthn__ ^ 10:01
msg bacek Test results came from amd64 box with 8 GB RAM, running Linux. 10:02
aloha OK. I'll deliver the message.
bacek jnthn__, aloha!
jnthn__ o/ bacek :)
Machine CPU info: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz, 8 cores
bacek jnthn__, :)
looks like my investigations were correct: 10:03
32-bits: 4G is faster than 2G
64-bits: 8G is faster than 4G
jnthn__ Ah. :)
bacek 4G: 32-bits is faster than 64-bits
jnthn__ is happy that somebody other than pmichaud managed to get the results he was seeing 10:04
dalek p: 1226591 | moritz++ | build/Makefile.in:
[build] use the current nqp for testing, not the installed one
 10:05
bacek I'm happy that I finally reproduced this slowdown. It's kinda give me ideas where to look for performance 10:07
10:08 woosley left 10:17 fperrad left 10:18 fperrad joined 10:36 mtk0 left 10:43 mtk0 joined
dalek p: 6b448c9 | moritz++ | build/Makefile.in:
[build] fix previous commit. Where did I have my mind?
 11:14
11:15 woosley joined 11:57 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner 12:09 preflex left, Kovensky joined 12:12 preflex joined 12:15 darbelo joined 12:20 davidfetter joined 12:23 cotto_work left 12:31 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner 12:38 bubaflub joined 12:49 jsut joined 13:17 bluescreen joined 13:24 whiteknight joined
whiteknight good morning, #parrot 13:26
pmichaud (SSDs from backlog) FWIW, both my SSDs (Intel X25M and X15M) seem to be going strong 13:27
bubaflub morning dukeleto
dalek p: 026eb76 | moritz++ | src/HLL/Compiler.pm:
start rewriting HLL::Compiler.parse in nqp
 13:29
p: d63b1e1 | moritz++ | src/HLL/Compiler.pm:
finish rewriting HLL::Compiler.parse in nqp
p: 5359d2b | moritz++ | src/stage0/ (6 files):
update bootstrap
13:31 hudnix joined
dalek p: a954a63 | jonathan++ | src/ModuleLoader.pm:
Make global merging slightly less dumb.
 13:36
p: 4abbac4 | jonathan++ | src/stage0/ (6 files):
Update bootstrap.
14:07 davidfetter left
tadzik 'afternoon #parrot 14:08
whiteknight hello tadzik 14:15
benabik morning 14:21
14:37 bubaflub left 14:42 theory joined, UltraDM left 14:49 hercynium joined 14:58 bubaflub joined 15:31 dodathome joined
dalek p: bbd4b88 | jonathan++ | / (4 files):
Factor NQP-specific bits out of HLL::SerializationContextBuilder so that we can use it also in Rakudo.
 15:45
p: 120ff08 | jonathan++ | src/stage0/ (6 files):
Update bootstrap.
16:04 woosley left 16:12 Andy joined 16:15 Andy left
dukeleto bubaflub: mornin' 16:16
16:17 rohit_nsit08 joined 16:39 rohit_nsit08 left
dukeleto self.blarg() 16:39
17:00 rohit_nsit08 joined
whiteknight dukeleto: ping (privmsg) 17:01
17:01 mj41 left 17:19 lucian joined 17:31 mj41 joined, benabik left 17:32 cotto_work joined
cotto_work ~~ 17:33
whiteknight hello cotto_work 17:35
cotto_work hio whiteknight 17:36
dukeleto: ping 17:40
17:47 rohit_nsit08 left 17:48 rurban_ joined 17:49 rurban left, rurban_ is now known as rurban
coke_ obra++ 17:50
17:55 Andy joined, Andy left 17:56 Andy joined 17:57 benabik joined 18:00 davidfetter joined 18:10 rohit_nsit08 joined 18:11 lucian left 18:12 rohit_nsit08 left 18:14 bubaflub left 18:15 lucian joined 18:20 ShaneC1 joined 18:50 bubaflub joined 18:51 lucian left 19:02 lucian joined
whiteknight www.modernperlbooks.com/mt/2011/05/...phism.html 19:08
that post could not be more perfectly timed 19:10
cotto_work how so? 19:11
cotto_work reads
whiteknight Because I was planning to write a post about upcoming 6model work where I address several of those same points
cotto_work niec
nice
whiteknight er, I have most of a post written, I need to revise and publish it
cotto_work (or niece, if you prefer)
whiteknight I'm about 99% certain that he isn't talking to a Parrot-centric audience, so much as holding Parrot up as a [bad] example for Perl5 people to learn from 19:12
but, we can learn from ourselves too
cotto_work we'd do well to
whiteknight the 6model stuff is just the tip of the iceberg. I'm planning a much more grandiose long-term task list for objects and PMCs 19:13
making vtables much less expensive and making subclasses much easier to do for built-ins is a key component 19:14
Lorito will move a long way in that direction, but I think we need to put down some foundations first
cotto_work 6model is a foundation. Deciding what we'll actually do with it will require a lot of planning.
whiteknight yes, and there is a lot that we both need and want to do 19:16
Fixing some of the glaring flaws in our current system is high priority
enabling better flexibility and better features is important too
cotto_work whiteknight: one of the things dukeleto++ suggested is that we need a set of glossy brochure-type documents that quickly give people a high-level view of Parrot and its various components and plans.
whiteknight our object system has been nothing if not stagnant and disappointing until now
cotto_work: at one point, I would have suggsted PDDs to fill that role
I'm still not sure what role PDDs are supposed to fill 19:17
cotto_work Something like that for 6model will be necessary if we want PMC design to be an accessible process.
maybe something like docs/glossy
whiteknight sounds good to me 19:19
atrodo I've always thought PDDs should be design documents. Like, if we lost all our code, with the PDDs we could recreate parrot 19:20
But what cotto_work and dukeleto are suggesting is more marketing material 19:21
whiteknight atrodo: We could recreate parrot as it currently stands if about half those PDDs said nothing besides "Do this as poorly as possible"
no, that's harsh
but there are a handful of systems where that is reality
19:21 kid51 joined
atrodo whiteknight> I agree. But that's reality versus theory 19:23
whiteknight atrodo: that's as good an idea for PDDs as any. What PDDs really need is a purpose, any purpose. Once we have that we can rewrite them to actually meet that purpose 19:24
because most PDDs are in severe need of a rewrite
cotto_work PDD0 says it defines the purpose. 19:25
kid51 at least it indicates that chromatic is still *thinking* about Parrot :-)
whiteknight I think we really need to move a handful of PDDs back into draft/ and start serious rewrites on them
tadzik did he leave just after the "Rakudo will target multiple VMs" mess? 19:26
whiteknight PDDs 10, 15, 17, 20, 21, 23, 24 and 25 all come to mind as needing major review/revision in the coming months
cotto_work tadzik: I don't think he left as much as got really busy with other things.
atrodo my understanding was that he got real busy with a job
tadzik I see 19:27
whiteknight it probably didn't hurt to take some time and blow off some steam
I would also like to get together with plobsing one day and go over PDDs 13 and 16 with a fine-toothed comb
kid51 He should link that to planet.parrotcode.org 19:28
whiteknight If we set up the PDDs as the ideal towards which we are constantly striving, that would be a good step. Because then when PDD did not match reality, we would be able to say conclusively that reality is wrong
atrodo chromatic++ 19:31
whiteknight of course, that would require bumping all PDDs back to draft, and only releasing them when they sufficiently describe what we want, not what we have or had or never wanted 19:32
in fact, maybe I'll set up a branch to do just that
cotto_work whiteknight++
atrodo whiteknight++
whiteknight cotto_work: don't ++ me just yet. You're going to be on the hook for a lot of the work too! 19:33
:)
cotto_work then cotto++ too
atrodo cotto++
cotto_work I'm sure he'll be helpful.
atrodo he has no choice at this point
whiteknight we need an architect astronaut to help hand down the lofty designs
atrodo not being around means being volunteered 19:34
cotto_work atrodo: good point
atrodo (which is why there is not atrodo_work)
whiteknight let's volunteer atrodo_work for some stuff too
get his lazy ass in here cleaning things up
:) 19:35
19:35 atrodo_work joined
atrodo_work unvolunteers himself 19:35
19:36 atrodo_work left
cotto_work I guess that's settled. 19:36
kid51 whiteknight: If we set ourselves an objective of having an East Coast Parrot Developers Gathering, then perhaps plobsing could come down from Ontario to attend 19:37
afk
whiteknight is that where he lives? I wasn't aware of that 19:39
19:39 benabik left
whiteknight Where in Ontario? 19:39
cotto_work whitehorse, yukon iirc 19:40
whiteknight yeah, that's nowhere near Ontario or the east coast 19:42
cotto_work or anything, really
whiteknight with the first million dollars the PaFo takes in, I say we hold a conference somewhere sunny and fly him in for the week 19:44
with the second million, we can meet bacek in person and buy him a beer
and with each subsequent million each each get gold-plated laptops 19:45
atrodo whiteknight++ # Fiscal responsibility
whiteknight if watching celebrities and wallstreet executives on the news has taught me nothing, it's that when you have a lot of money you should waste it in frivolous and border-line criminal ways 19:47
and if you can't trust celebrities and wallstreet executives, who can you trust?
atrodo hobos?
19:50 benabik joined
cotto_work at lfnw, dukeleto chatted with Bradley Kuhn about getting Parrot into the Software Freedom Conservancy. It sounded like it'd be a really nice way to let a pro do the mundane work if PaFo can get its 501(c)(3) status back. 19:50
whiteknight We never were 501(c)(3) 19:55
but yes, it's an option we've been looking at
cotto_work I thought we were but lost it.
whiteknight there is a grace period between the time when you incorporate and the time when you become 501(c)(3). If you get the status during the grace period, donations prior to that are exempt retroactively 19:56
we missed the grace period, so we are not and never were
20:00 benabik left 20:02 darbelo left, darbelo joined 20:05 hercynium left, hercynium joined 20:08 perlite_ joined, utsl left, utsl joined 20:11 perlite left 20:12 perlite_ is now known as perlite 20:17 hercynium left
pmichaud (east-coast parrot gathering): fwiw, I'm tentatively expecting to attend fosscon in Philadelphia on July 23. Maybe we could have a meetup then/there. Also, perhaps there should be a talk about Parrot there. (fosscon.org/) 20:23
I can submit one if nobody else thinks they'll be able to do so.
whiteknight I've been on the fence about it 20:24
but if I know other parroteers are heading that way, maybe I'll think harder about it 20:25
pmichaud where's the doodle poll for PDS?
whiteknight cotto took it down. Sent out results in an email 20:26
pmichaud email says: "If you're not
sure what time that is for you, check the following table or look at
the doodle and set your timezone:
"
kid51 (but I think there were some errors in the UTC listed)
pmichaud so I was wanting to look at the doodle
(to try to tease out the actual UTC/time) 20:27
kid51++ for noticing the error :)
kid51 actually compounded the error in response ... so we need a follow-up from cotto
pmichaud: If you attend on Sat July 23, that will be strong incentive for me to attend as well. 20:29
pmichaud kid51: I'll let you know asap if I'm a confirmed attendee
I'm also planning to stay a day either side of the conference to be able to meet with others
(and if nobody's available to meet, it's my first trip to philly so I'll sightsee :)
Andy pmichaud: Do you need MX records for rakudo.org? 20:30
kid51 whiteknight lives north of Phila. former contributors Infinoid and austin_hastings and jhorwitz are in that area; one GSOCer is in northern NJ.
Andy Is anybody going to be getting mail at that address?
pmichaud Andy: ...I don't think anyone will be getting mail there.
Andy I doubt it, too.
pmichaud if we decide to set up incoming mail there I'll email you about the mx record 20:31
of course, it doesn't hurt to go ahead and add the mx record if you wish :)
cotto_work whiteknight: I didn't take it down. I marked the date and closed it to further voting.
kid51: the funny thing is that I spent 10 minute just trying to double-check the dates. 20:32
pmichaud: www.doodle.com/nf5cip2yrt6a448d#table
20:33 jsut_ joined
pmichaud cotto_work++ # thanks 20:33
doodle says that's 2100 UTC on the 14th :-) 20:34
20:34 whiteknight left
cotto_work ignore anything I say and go with the doodle 20:34
including this
I 20:35
I'll send out a clarification in a few minutes
pmichaud adds the event to his calendar, in case he can make it.
20:36 lucian_ joined 20:37 jsut left 20:41 lucian left, dodathome left
cotto_work sent 20:42
20:42 jevin left 20:44 jevin joined 21:05 benabik joined 21:10 benabik left 21:12 davidfetter left 21:21 ShaneC1 left 21:25 fperrad left 21:26 davidfetter joined 21:27 kid51 left 21:37 theory left
cotto_work pmichaud: fosscon will look more interesting with you there. I'll have to look into it more. 21:48
21:49 mj41 left
cotto_work I've avoided it so far because the conf's site because they don't have any list of proposed talks so I don't have much idea of who's been applying. 21:51
21:55 bluescreen left 21:58 whiteknight joined 21:59 benabik joined 22:03 darbelo_ joined 22:08 darbelo left 22:11 arnsholt_ left
pmichaud bacek: ping 22:12
bacek pmichaud, pong.
pmichaud do you want me to patch 3.3 or the current master?
bacek 3.3 22:13
pmichaud okay, will do
bacek It should apply clearly
pmichaud will let you know when I have results
bacek ok, thanks!
22:15 arnsholt joined
bacek afk # $dayjob 22:15
pmichaud, jfyi looks like ms2 behave much better on "fragmented memory". Hopefully is_ptr.patch can improve gms 22:22
bacek is really afk 22:23
22:35 Andy left 22:36 lucian_ left
coke_ Seen Andy? 22:36
aloha Andy was last seen in #parrot 2 hours 6 mins ago saying "I doubt it, too.".
22:37 Andy joined
coke_ seen mj41? 22:38
aloha mj41 was last seen in #perl6 5 hours 6 mins ago joining the channel.
coke_ pmichaud: oooh. perhaps I'll ditch yapc and go to fosscon, then. 22:39
msg mj41 I cannot run my taptinder client anymore. "bad login or password". 22:40
aloha OK. I'll deliver the message.
coke_ msg mj41 probably been dead for ages, I haven't checked.
aloha OK. I'll deliver the message.
Coke Oh, hey, here I am. 22:41
22:41 coke_ left, bubaflub left 22:59 Andy left 23:03 Coke left 23:06 Coke joined 23:09 theory joined 23:11 Coke left 23:14 Coke joined 23:19 Coke left 23:22 Coke joined 23:32 theory_ joined 23:35 theory left, theory_ is now known as theory 23:48 darbelo_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!