Parrot 4.7.0 "Hispaniolan" | parrot.org | Log: irclog/perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 27 August 2012.
00:08 lucian joined 00:14 MikeFair joined 00:18 aloha joined 00:23 MikeFair joined 00:26 benabik joined 01:08 woosley joined 07:01 brrt joined 08:05 lucian joined 08:14 fperrad joined 08:19 Psyche^ joined 09:38 schm00ster joined
dalek rrot: e7cced7 | rurban++ | t/dynpmc/os.t:
win32 skip t/dynpmc/os.t os.readdir

This test not only fails on MSVC, also with mingw gcc and all others.		 10:31
rrot: a960052 | rurban++ | config/ (2 files):
Makefile pmc dependency cleanup

Remove the unneeded suffix rule.
Remove duplicate lib/Parrot/Pmc2c/PCCMETHOD.pm dep.
Fix vtable.dump deps.
default.dump is still created on every make invocation, only make -t fixes that.		 11:04
11:24 travis-ci joined
travis-ci [travis-ci] parrot/parrot#531 (master - a960052 : Reini Urban): The build was broken. 11:24
[travis-ci] Change view : github.com/parrot/parrot/compare/e...600528c7b8
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/2317499
11:24 travis-ci left
dalek rrot: 6a36728 | rurban++ | t/codingstd/pccmethod_deps.t:
t/codingstd/pccmethod_deps.t: bogus dependency detection

There is a special test to check if every .dump contains PCCMETHOD.pm as dependency, but every .dump contains $(PMC2C_FILES) which includes PCCMETHOD.pm.		 11:29
nemesys @jimmy thanks for the threads hint 11:50
dalek rrot: 13f3cf5 | rurban++ | config/auto/warnings.pm:
warnings cleanup

Remove already by -Wall and -Wextra implied gcc/clang warnings, for a shorter cc cmdline.		 11:53
12:12 travis-ci joined
travis-ci [travis-ci] parrot/parrot#532 (master - 6a36728 : Reini Urban): The build was fixed. 12:12
[travis-ci] Change view : github.com/parrot/parrot/compare/a...36728d660e
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/2317715
12:12 travis-ci left 12:32 zby_home joined 12:50 JimmyZ joined 12:52 rurban_mobile joined 12:55 PacoAir joined
dalek rrot: f1d2865 | tadzik++ | lib/Parrot/Configure/Options.pm:
Cry when Configure.pl is given a relative path. Probably works for Unixes only
 12:57
rrot: 1a0a31c | jkeenan++ | / (2 files):
Let's try using a File::Spec function for testing for absoluteness. Add a regression test for invalid value to '--prefix'.
13:03 schm00ster joined 13:30 Maddingue joined
nemesys Just came to the conclusion that building concurrency on-top of the current parrot implementation will always result in a never ending green/hybrid-thread story 13:33
Would have to define a shared memory model from groud up
for int, str, flot, and pmcs
brrt . 13:34
nemesys: i think the hybrid threads thing is not inelegant
and tbh
i'm not superbig on 'shared memory' myself 13:35
as an aside
having a 'interpreter-per-thread' is not bad, either
because, just as silicon cpus cannot execute two tasks at once 13:36
virtual cpus cannot either
dalek rrot/bdw/move-os: 97aa16a | rurban++ | / (24 files):
move os.pmc from dynpmc back to static pmc

Manually cleaned up pull request 778 by bdw.
Rationale whiteknight: It's my belief that making OS PMC a dynpmc in the first place was a mistake. It is the only real way to access some pretty fundamental filesystem and other functionality from the user level. Further, all the real logic is implemented inside libparrot already, but without OS PMC it isn't exposed to the user at all.
dynpmcs should be used for cases when we want to add new logic to the VM, not when we already have that logic but want to be stingy about when we expose it.
All our major users rely on OS pmc also. Winxed, Rakudo, NQP and Rosella all make some use of it. It's important and necessary, and it should be in core.		 13:48
nemesys brrt: its all about what is really wanted - if you want a real concurrency, there is no way around fiddling with the basics 13:54
rurban_mobile nemesys: I found some races with pmc_new in threads, which worry me 13:55
13:56 schmooster joined
rurban_mobile bumped PBC_COMPAT to 12.1 for pmc/os 13:56
nemesys There are several ways to go: a) Basic types cannot be shared (ie. no lock or proxy-locks lookups needed or lock information to carry with these types)
with basic types I mean int, str, float - pmc could be shared because they are either way heavy enough 13:57
b) foresee an implementation which enables lock information for basic types to 13:58
that would some thingy like a address-hash lock-lookup table
the more cpu's you have, the broader and larger the lookup space in order to decrease hash collisions
but this means reinventing types and memory management 13:59
I cant see a decent way to get performance and real concurreny implemented with the current situation :) 14:01
brrt nemesys: that depends, again, on how you define concurrency :-) 14:03
nemesys indeed
rurban_mobile who wants to share int,num,str?
brrt basically, if you want concurrent merge sort, or something like that, then yes you are probably right
14:03 Maddingue joined
nemesys rurban_mobile: The java jvm implementations does it the same, they avoid carrying lock information for basic types 14:04
but this has a major tradeoff, memory
JimmyZ nemesys: here are some posts about threads on parrot, FYI: whiteknight.github.com/allposts.html, if you didn't see my message to you
;)
nemesys JimmyZ: Read them :)
brrt if you want concurrency as in server-style concurrency, where multiple threads solve different problems each
then hybrid threads are probably pretty cool 14:05
14:06 whiteknight joined
nemesys the current hybrid thread impl. is just a delyed problem solving which hasnt been in the design spec first - and will never reach good performance 14:06
whiteknight good morning, #parrot 14:07
nemesys the progress feels good tho, but it doesnt solve the performance problem
because the real problem is embedded in its design 14:08
dalek rrot/bdw/move-os: 9e45571 | rurban++ | / (5 files):
PBC_COMPAT 12.1
rrot: 97aa16a | rurban++ | / (24 files):
move os.pmc from dynpmc back to static pmc

Manually cleaned up pull request 778 by bdw.
Rationale whiteknight: It's my belief that making OS PMC a dynpmc in the first place was a mistake. It is the only real way to access some pretty fundamental filesystem and other functionality from the user level. Further, all the real logic is implemented inside libparrot already, but without OS PMC it isn't exposed to the user at all.
dynpmcs should be used for cases when we want to add new logic to the VM, not when we already have that logic but want to be stingy about when we expose it.
All our major users rely on OS pmc also. Winxed, Rakudo, NQP and Rosella all make some use of it. It's important and necessary, and it should be in core.
brrt hi whiteknight 14:09
whiteknight nemsys: what do you mean the performance problem? What is the right solution if threads isn't right?
hello brrt
brrt primitive shared memory if i understood it right
with an address lock hash 14:10
nemesys lock-lookup table based on hashed addresses 14:11
brrt sounds fun, but i'm not sure about reaally sharing that much details
nemesys it's used in the kernel too
then use different locking schemes like spinlock upon these locks
instead of carrying around the locking information in your types and objects, have it stored there
brrt fair enough, but, what is wrong with hybrid threads? 14:12
they serve the purpose of running multiple paths of code, simultaneously 14:13
nemesys everyone else has them because no-one was able to solve the concurrency sustainable - so what about a solution which is?
brrt java has pretty primitve concurrency afaik 14:14
and it is / can be a pain
nemesys indeed, with a memory tradeoff because they carry the lock information around
brrt i think keeping the lock in a lookup table will in the general case cost at least as much memory
nemesys just a few k 14:15
brrt you need a lock for every locked object, right?
nemesys be your lock space around 4096 possible locks, increase it by the factor for each cpu you add
brrt those locks won't be that much smaller than locks that are carried arround
hence 14:16
in the general case, you use exactly as much memory
nemesys you overbook the locks
brrt overbook, I'm sorry?
nemesys get ones object address, hash it correctly, lookup it up in the lock table 14:17
the more conccurent access you have, the higher your chance to get hash collisions
that's why sizing the lookup table is essential when there are more cpu#s
ie. there might be different objects which have the same lock-lookup due to their hash 14:18
but that chance is quite minimal
whiteknight nemesys: So isn't this something that could be implemented in the new threading system? It sounds like you're just talking about an algorithm for assigning and organizing locks 14:19
brrt whiteknight: in the new threading system, as it stands, and as i understand it, objects aren't shared, they are proxied 14:20
whiteknight right
brrt hence, you don't need to put locks on objects
whiteknight also, right 14:21
brrt which is why
you don't have locks on objects :-)
nemesys iirc you have a queue which holds write-tasks for threads
brrt but it also means (and I think this is what nemesys means) you can't realistically write concurrent merge sort in parrot
nemesys the current threads impl. is rather a fake because we would love to get near concurrency, but we lied to ourselves 14:22
brrt which is harsh and informationless
nemesys maybe, you're right - not up to me to decide about it
as I said, it's all about what we want - real concurrency or a simple "select" 14:23
brrt but am i correct in that you want to implement things that need concurrent writes?
nemesys I cant implment, I'm way to dumb for that :) 14:24
I just good at throwing rocks
No seriously, had a longer discussion with a kernel developer which just started crying when I explained the current concurrency plans for parrot 14:25
rurban_mobile hi whiteknight: I'm still doing major cleanup. bdw/move-os will be merged soon. native_pbc should be merged also, but I need votes for that.
brrt well, concurrent merge sort (a rather tired example by now) is not that hard :-) for example
nemesys whiteknight: I dont know if it's dooable in the current impl. but I can imagine that incl. concurreny by design touches quite a few places in parrot - I dont know 14:33
whiteknight nemesys: We always want to hear more ideas for improvements 14:34
nemesys
nemesys I can imagine that operations like these in such a model would be quite deadlocky: c = a + b in concurrent to c = b + a
rurban_mobile nemesys: perl6 implements its own native types which enables concurrent merge sort 14:35
nemesys but there is a solution for that too, like sorting the addresses of a b c ascending and claiming them in order and only proceed if all locks could be claimed 14:36
14:37 smash joined
dalek rrot/bdw/move-os: c52f7c4 | rurban++ | t (2 files):
fix mk_native_pbc

In order to update the native pbcs for 12.1, the creation script needed to be fixed.		 14:40
nemesys rurban_mobile: and perl6 is currently implemented on?
JimmyZ parrot? 14:43
dalek rrot/bdw/move-os: eaca4f2 | rurban++ | t/native_pbc/ (4 files):
native_pbc for i386 updated
 14:44
rrot/bdw/move-os: 9eaa77a | rurban++ | t/native_pbc/ (2 files):
native_pbc i386 type 2 (long double) updated
 14:48
arnsholt nemesys: Rakudo runs on Parrot, Niecza is .Net/Mono 14:50
whiteknight I'm not sure that I'm taking from this conversation anything concrete to work on 14:52
brrt no, not really 14:55
not that i personally don't appreciate a different view
there is just 'not much we can do'
whiteknight if we get concrete suggestions for new algorithms or architectures, we definitely will consider them 14:56
But I think the best thing we can do now is to merge threads and start collecting feedback to see what works and what doesn't
brrt basically, if any
dalek rrot: 9e45571 | rurban++ | / (5 files):
PBC_COMPAT 12.1
 14:57
rrot: c52f7c4 | rurban++ | t (2 files):
fix mk_native_pbc

In order to update the native pbcs for 12.1, the creation script needed to be fixed.
rrot: eaca4f2 | rurban++ | t/native_pbc/ (4 files):
native_pbc for i386 updated
rrot: 9eaa77a | rurban++ | t/native_pbc/ (2 files):
native_pbc i386 type 2 (long double) updated
brrt the question is, do we want to share memory
if so, we can probably solve for 'how'
nemesys calls shared memory 'real concurrency', i am not really convinced i agree 14:58
whiteknight For right now, I'm 100% behind this new design: Direct reads and proxied writes
rurban_mobile shared memory is a windows hack 14:59
brrt windows and java, then
whiteknight the simple heuristic of "if this thread doesn't own it, you can't change it" seems to solve a lot of conceptual problems, and is very inline with existing solutions like Erlang, etc
pmichaud note: I'm sure it'll be relatively easy to fix, but 97aa16 breaks the rakudo build. 15:00
rurban_mobile I'll be gone for some hours driving back. bdw/move-os has landed. native_pbc would be nice also. threads I'm not so sure.
pmichaud error:imcc:loadlib directive could not find library `os' in file '(file unknown)' line 1
rurban_mobile pmichaud: loadlib 'os' is now not needed anymore. It's a pmc
tadzik whiteknight: oh, I have feedback alright 15:01
(threads)
rurban_mobile See github.com/parrot/parrot/pull/778/
tadzik let me find this
whiteknight I wonder if we can add a hack/workaround that ignores loadlib os for a while
rurban_mobile hmm, good idea until the next supported release. 15:02
whiteknight pmichaud: One way or another, we'll fix that today
pmichaud rurban_mobile: sure, I understand that part. It just means that rakudo can run on either post-97aa16 or pre-97aa16 but not both.
tadzik okay, I have no gist. But lexical scoping was quite broken there, even in parrot-nqp
rurban_mobile somewhen we have to do the move. We wanted it before the next release.
whiteknight tadzik: ah, that's very good to know. I wonder why
tadzik for stuff like my $x := 42; sub foo { say($x) }; <run thread with foo>
I'm at work and can't test it now, but it was something of this sort 15:03
whiteknight tadzik: Okay, I'll look into that before merging anything
rurban_mobile pmichaud: the next release is next week.
tadzik whiteknight: I'll try to remember to file a bug when I get back home
whiteknight tadzik++
tadzik which is soon, since it's 17 already :)
rurban_mobile gist.github.com/3580241 15:04
JimmyZ the next release is next week? not next next week?
tadzik that's another thing
pmichaud release should be sep 18
tadzik that's nqp with custom lexpads, and rakudo with custom everything
but it wasn't even working in parrot-nqp
rurban_mobile oops, mixed the dates. enough time
anyway. I'll be back in ~2 hrs. maybe hack loadlib 'os' 15:05
pmichaud just create a dummy empty os_ops for now.
so that the loadlib doesn't fail.
whiteknight pmichaud: yes, that's my plan 15:11
pmichaud as long as we're moving things back from dynamic to static... what's the rational for having 'pow' in trans_ops ?
whiteknight we'll make sure this is a backwards-compatible change
pmichaud while 'sqrt' is a core op
whiteknight pmichaud: make a recommendation, it will be done
(I agree that situation is less than optimal) 15:12
pmichaud I don't have a strong recommendation here; at least nothing that affects rakudo/nqp directly, since we have to load trans_ops either way. (more) 15:13
I just know that it seemed very odd to me that sqrt was "core" while pow required loading. Far more languages have exponentiation as a core operator than have sqrt as a core operator 15:14
it also seemed weird that 'pow' was listed as a "transcendental opcode"; I don't normally think of exponentiation as being a transcendental. So I was surprised that libload 'math_ops' didn't resolve the problem either. :) 15:15
*loadlib 15:16
I'm afk again for a while 15:28
MikeFair Hey all! 15:42
I'd like to do something like: say("$/") in a rule to find out what got passed into it. What can I do inside the regex to make that happen? I read somewhere that $/ isn't valid in the middle of the match and my attempts have so far yielded nothing but an empty string (despite that there is a match string it is operatng on). I'm just having a really hard time getting this expression right (and it seems like it should be so
easy!)
I'm working on creating the Grammar for my language 15:43
whiteknight MikeFair: you want to dump the contents of that variable in mid-match? 15:44
MikeFair whiteknight: Well mostly I just want to dump it at match start 15:45
whiteknight:{ say("rule_part") } has been working mid-match
whiteknight hmm, I'm not great with the nqp parsing engine, that's probably a question for one of the p6 guys 15:46
MikeFair whiteknight: Or better yet, perhaps there are some trace keywords I can use
whiteknight The #perl6 channel on freenode probably has people who know nqp better than I
MikeFair whiteknight: "It works in rakudo" :) and "Parrot's NQP is pretty old by now" :)
whiteknight: They say say("$/") should work 15:47
whiteknight I suggest you use the new nqp, not the parrot-nqp that ships with Parrot
MikeFair LOL!
sounds great!!!!
whiteknight our version is very old and in the process of being upgraded
MikeFair How do I do that!? I've just had access to the tutorials so far and this channel has been fairly quite when I'm working on this 15:48
whiteknight Build and install Parrot on your machine. Then grab a copy of nqp and build that: github.com/perl6/nqp.git, I think 15:49
MikeFair I can pull and compile stuff and have ~/local tree that has the appropriate overrides so I can install stuff in it
whiteknight: Did that (head from like two weeks ago) 15:50
whiteknight: will get nqp now
I'm excited to be seeing this begin to take shape but I'm certain I've been encountering bugs in NQP 15:55
But it's too difficult for me to distrguish what's a bug from what's my not knowing how this new syntax works yet 15:56
15:56 zby_home joined
whiteknight yeah, the old parrot-nqp is missing a lot of features that the new one has. 15:59
tadzik whiteknight: gist.github.com/3610283 16:00
whiteknight thanks tadzik++ 16:01
MikeFair whiteknight: I'm geting: PARROT VM: Could not initialize new interpreter 16:17
PackFile_Header_validate: This Parrot cannot read bytecode files with version 12.0.
when I try to run nqp
parrot-nqp seems to work but I can't tell where that came from
whiteknight hmmm, that's a version mismatch error message. Uninstall/reinstall Parrot and try again 16:20
make sure you only have it installed in one place
MikeFair whiteknight: I originally used --gen-parrot, rebuilding NQP with the --with-parrot=parrot_exe_path instead 16:21
whiteknight I wonder if that created two versions? Just make sure they're both removed so nqp doesn't get confused 16:22
MikeFair whiteknight: --gen_parrot supposedly downloads and builds the right version of parrot for NQP
whiteknight right
16:22 travis-ci joined
travis-ci [travis-ci] parrot/parrot#536 (master - 9eaa77a : Reini Urban): The build was broken. 16:22
[travis-ci] Change view : github.com/parrot/parrot/compare/9...aa77a4bf25
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/2319615
16:22 travis-ci left
MikeFair whiteknight: ok so how do I know tell parrot to use the new "nqp" as opposed to the "parrot-nqp" 16:27
or did that happen for me automagically
I can tell from the --version outputs that nqp and parrot-nqp aren't the same, nqp giving both its own version and its built-with-parrt version, which is good 16:28
whiteknight they're different programs at the commandline. One is "nqp", the old one is "parrot-nqp" 16:37
MikeFair right
so when I'm using the PCT, and type parrot setup.pir, I'm asuming I have to change something somewhere
MikeFair could just alias it and move the old one out of the way
whiteknight no, the new nqp doesn't use PCT. It has all that parsing stuff built in
MikeFair so then does invalidate the tutorial instructions? 16:38
whiteknight yes
MikeFair nods.
whiteknight I think somebody is working on a new tutorial for the new language
MikeFair sorear is I believe
iS the directory structure and files the same at least? src/lang_name/Grammat|Actions|Runtime.pm 16:39
Or do you not know
I just need to know how "modify .pms, type something, execute new compiler" 16:40
works
i'll read around the docs, I'm sure it's in there somewhere
whiteknight yeah, read the docs. I'm kind of useless on this topic for now 16:41
17:40 rurban_home joined 17:59 zabirauf joined
zabirauf Hello , Ive just started looking into parrot. Im following the example in the slides pmichaud.com/2009/pres/oscon-pct/slides 18:00
when i run the grammar which is in pmichaud.com/2009/pres/oscon-pct/sl...de22a.html i get an error
when i do parrot languagename.pbc --target=parse
then when i put something in the console i gett error "Method 'parse' not found for invocant of class 'Undef'" 18:01
does any body know what the problem is and how to resolve it
18:20 rurban_mobile joined 18:35 zabirauf_ joined
sorear MikeFair: I am *not* working on any tutorials 18:37
18:58 rurban_mobile joined 19:10 lucian joined
rurban_mobile Wrote the dummy os dynpmc and tests. How long do we keep this dummy? 19:29
I can add the version number to the test.
dalek rrot/bdw/move-os: e8eaa7d | rurban++ | / (3 files):
Provide dummy loadlib "os" for backwards compat

  pmichaud does not want to change his sources all around.		 19:31
rrot: e8eaa7d | rurban++ | / (3 files):
Provide dummy loadlib "os" for backwards compat

  pmichaud does not want to change his sources all around.		 19:36
pmichaud ...really, that's the commit message? *sigh* 19:41
rurban_mobile why, it's a valid concern. 19:42
when you fixed it we can get rid of this dummy. so we know whom to ask. 19:43
sorear what. 19:47
pmichaud I never said anything about wanting or not wanting to change the sources.
dalek rrot: d76bef8 | rurban++ | / (3 files):
Provide dummy loadlib "os" for backwards compat
 19:48
rurban_mobile removed that line, sigh. sorry
dalek rrot/bdw/move-os: 5a03032 | rurban++ | / (3 files):
Provide dummy loadlib "os" for backwards compat
 19:50
19:56 sivoais joined
sorear what's going on here and why is it causing strife? 20:01
rurban_home patrick didn't like my commit msg, so I removed it.
it was a stupid msg 20:31
20:38 travis-ci joined
travis-ci [travis-ci] parrot/parrot#537 (master - e8eaa7d : Reini Urban): The build was broken. 20:38
[travis-ci] Change view : github.com/parrot/parrot/compare/9...eaa7de06a6
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/2322713
20:38 travis-ci left 21:41 travis-ci joined
travis-ci [travis-ci] parrot/parrot#538 (master - d76bef8 : Reini Urban): The build was fixed. 21:41
[travis-ci] Change view : github.com/parrot/parrot/compare/e...6bef83f04f
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/2322891
21:41 travis-ci left 22:22 lucian joined 22:47 whiteknight joined 22:52 schmooster joined
whiteknight good evening, #parrot 23:20
dalek rrot: 352010e | jkeenan++ | MANIFEST (2 files):
Update MANIFEST and SKIP to reflect one new, one renamed file.
 23:36
23:41 Timbus joined 23:42 dalek joined, particle1 joined 23:43 p6eval joined, perlite joined 23:44 autark joined, lucian_ joined, PacoAir joined, NotFound joined, wagle joined, GeJ joined, MikeFair joined, elmex joined, arnsholt_ joined, benabik joined, schmooster joined, whiteknight joined, lucian joined, rurban_home joined, Maddingue joined, schm00ster joined, Patterner joined, woosley joined, mtk joined, jlaire joined, simcop2387 joined, cosimo joined, he joined, ttbot joined, mj41 joined, Coke joined, pmichaud joined, Util joined, sri joined, moritz joined, Infinoid joined, japhb joined, jevin_ joined, nine joined, cxreg joined, tokuhirom joined, allison joined, lizmat joined, TonyC joined, eternaleye joined, nopaste joined, woolfy_ joined, Hunger joined, pjcj joined, nemesys joined, kid51 joined, rurban joined 23:45 alvis joined, sivoais joined, atrodo joined, tadzik joined, PerlJam joined, dukeleto joined, knewt joined, drift joined, dngor joined 23:49 slavorg joined
whiteknight netsplit-- 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!