Parrot 3.6.0 "P�jaros del Caribe" released | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 13 August 2011.
dalek nxed/multi_syntax: d573a38 | Whiteknight++ | / (2 files):
the new multi syntax overrides, and is ignorant of, a more manual approach
 00:02
nxed/verbose_diagnostics: d00e872 | Whiteknight++ | / (2 files):
Merge branch 'nf_master' into verbose_diagnostics
nxed/multi_syntax: ad9459c | Whiteknight++ | winxedst1.winxed:
Make sure to initialize the is_multi field, so we can avoid null pmc accesses
 00:07
00:13 preflex_ joined
dalek nxed/verbose_diagnostics: 9f746d1 | Whiteknight++ | winxed.winxed:
subs_by_flag -> subs_by_tag. explicitly return null when we can't load the packfile
 00:18
lucian bah, can't fix this damned bug 00:19
i can't for the life of me figure out why this happens 00:20
this test fails github.com/lucian1900/puffin/blob/...ect.t#L126 00:34
very odd
whiteknight let me look 00:54
...loading...slowly... 00:55
00:55 darbelo joined
whiteknight lucian: okay, I see the test now. What part of it fails? The assertion? 01:03
lucian whiteknight: yeah, i.bla is null
whiteknight darn 01:04
lucian apparently tracking nulls on parrot is hard
whiteknight what do you mean?
lucian anyway, type.winxed:t.__getattribute__ gets called for that 01:05
whiteknight: that null has to come from somewhere, i never explicitly return null
whiteknight ah, okay
dalek sella: 69aef39 | Whiteknight++ | src/ (5 files):
start updating the Contract library with new features and updated standards
 01:07
sella: 2e30dc5 | Whiteknight++ | s (8 files):
Rename Contract library to Assert
lucian whiteknight: i probably need to test __getattribute__ failures better 01:08
dalek sella: 0111611 | Whiteknight++ | s (2 files):
Add some experimental higher-order functions to the core library. Inspired, in part, by underscore.js and other sources
 01:15
sella: 7b779df | Whiteknight++ | src/ (2 files):
Add forward-declarations for Function routines to Core.include. Fix compilation in assert
 01:26
lucian hmm failure to find attributes does throw the expected exception
Coke finds the release guide probably more convoluted than strictly necessary. 01:42
anyone planning on committing anything anytime soon? 02:00
02:01 RobertLJ_ left
Coke (I'm testing a 3.7 release candidate right now.) 02:01
dalek p/nfa: ef8359b | pmichaud++ | src/Q (2 files):
Add :rxtype<ws> to differentiate meta whitespace from direct calls to <.ws>.
 02:18
p/nfa: 6d9e44e | pmichaud++ | src/NQPQ/Actions.pm:
QRegex::Actions::buildsub no longer sets :blocktype('method') by default.
p/nfa: 88b34ff | pmichaud++ | / (3 files):
Initial version of nfa generation. Build nqpq by default for now to make testing easier.
p/nfa: d3798ba | pmichaud++ | src/QRegex/NFA.nqp:
Relabel NFA_* constants to EDGE_*. Add a simple __dump() method to make it easier to visualize the NFA.
p/nfa: 8c346b0 | pmichaud++ | src/PAST/NQP.pir:
Add nqp::sprintf opcode.
p/nfa: 94795ee | pmichaud++ | src/QRegex/ (2 files):
Initial protoregex nfa generation and merging.
p/nfa: 742b33a | pmichaud++ | src/QRegex/ (2 files):
Add NFA.run -- code to run the NFA on a given input string.
02:23 rohit_nsit08 joined
Coke so, where can someone on OS X get sha256sum ? 02:25
:P 02:26
gerd: you about? 02:30
msg kid51 did you cut the release on your mac? 02:35
aloha OK. I'll deliver the message.
tcurtis Coke: is there any difference between sha256sum and shasum -a 256? 02:42
Coke tcurtis: I have no idea whatsoever.
(looks like shasum is a perl script) 02:43
Coke is done for the night, I'll just do the release on a linux box tomorrow. 02:44
dalek website: soh_cah_toa++ | SOD: Symbolic Opcode Description 02:59
website: www.parrot.org/content/sod-symbolic...escription
03:48 sri joined, cotto joined 03:49 darbelo joined
dalek p/nfa: 505a3d7 | pmichaud++ | src/QRegex/NFA.nqp:
Add anchor and enumcharlist to QRegex::NFA.
 04:02
p/nfa: ef5cfd3 | pmichaud++ | src/QRegex/NFA.nqp:
Some small fixes to anchors and eos handling.
p/nfa: 4903492 | pmichaud++ | src/QRegex/Cursor.nqp:
Code to invoke protoregexes in (decreasing) order of longest match.
cotto ~~ 04:20
dalek rrot: b9fb194 | cotto++ | docs/dev/profiling.pod:
temporarily delete an unfinished section in the profiling doc
 04:25
04:37 tewk_ joined 04:46 tewk joined
ttbot Parrot b9fb194a MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/44596 04:47
cotto lolwut 04:48
Can someone try to repeat that? 05:20
05:33 SHODAN joined 05:50 fperrad joined 06:15 SHODAN joined 06:41 cotto joined
cotto If the release hasn't been cut, we probably shouldn't send out a tarball that installs a known-horribly-broken parrot_debugger. 07:01
aloha, clock? 07:03
aloha cotto: LAX: Tue, 00:03 PDT / CHI: Tue, 02:03 CDT / NYC: Tue, 03:03 EDT / UTC: Tue, 07:03 UTC / LON: Tue, 08:03 BST / BER: Tue, 09:03 CEST / TOK: Tue, 16:03 JST / SYD: Tue, 17:03 EST
dalek p/nfa: 8ea85a9 | pmichaud++ | src/QRegex/NFA.nqp:
Refactor mergesubrule a bit.
 07:15
07:18 woosley joined 07:28 mj41 joined 08:28 Kulag joined 08:44 cotto joined 09:02 bubaflub joined 09:25 nine joined
nine Hi! Would now be a good time to start implementing threading support in Rakudo or is Parrot now ready for that yet? 09:27
09:30 Tene joined 09:41 lucian joined
cotto nine, it needs a lot of thought and design work, but we've been complaining about Parrot's poor threading support for a very long time. 09:47
nine cotto: I'm not quite sure what to make of that answer :) 09:50
cotto nine, I don't think the Parrot threading code is nearly mature enough, so Rakudo would end up having to roll its own. 09:51
(initially misparsed your question)
nine, if you want to help improve Parrot's threading model (so that Rakudo can start using it), that'd be most welcome.
nine cotto: tempting :) It's just a matter of time having a full time job and a study and having picked concurrency support for Rakudo as topic for my bachelor's paper due in February. 09:55
10:09 cotto joined 10:12 ligne joined 10:24 RobertLJ joined 10:58 NotFound joined
NotFound Hi 10:58
cotto hi NotFound 11:02
aloha, clock? 11:14
aloha cotto: LAX: Tue, 04:14 PDT / CHI: Tue, 06:14 CDT / NYC: Tue, 07:14 EDT / UTC: Tue, 11:14 UTC / LON: Tue, 12:14 BST / BER: Tue, 13:14 CEST / TOK: Tue, 20:14 JST / SYD: Tue, 21:14 EST
dalek nxed: 250bbe7 | Whiteknight++ | winxedst1.winxed:
Add multi funcitionality to class methods.
 11:19
nxed: b239fab | Whiteknight++ | t/advanced/10multi.t:
update multi tests
nxed: c23371e | Whiteknight++ | / (2 files):
Merge branch 'nf_master' into multi_syntax
nxed: d573a38 | Whiteknight++ | / (2 files):
the new multi syntax overrides, and is ignorant of, a more manual approach
nxed: ad9459c | Whiteknight++ | winxedst1.winxed:
Make sure to initialize the is_multi field, so we can avoid null pmc accesses
nxed: 6f516b1 | NotFound++ | / (3 files):
Merge pull request #4 from Whiteknight/multi_syntax

Multi functions and methods
cotto looks like someone's waking up
seen not_gerd 11:27
aloha not_gerd was last seen in #parrot 2 days 21 hours ago saying "looks good to me".
dalek nxed: c6ac75c | NotFound++ | winxedst1.winxed:
work around stage 1 limitations to allow multi tests pass with make test1
 11:33
11:49 JimmyZ joined
dalek nxed: 8f25134 | NotFound++ | winxedst1.winxed:
use separate methods to get and set the is_multi flag, and recognize multi declarations on reopened namespaces
 11:55
12:03 whiteknight joined
whiteknight good morning, #parrot 12:04
dalek nxed: 2cd7e1a | NotFound++ | t/advanced/10multi.t:
tests for multi in reopened namespace
 12:05
cotto hi whiteknight
NotFound whiteknight: I've merged the multi push request and fixed a few things.
lucian bah, so if i want to participate in a boolean context i must implement get_integer ?! 12:10
what's get_bool for, then 12:11
lucian think it's that same problem again
whiteknight NotFound++ 12:12
NotFound lucian: the problem lies in the "boolean context".
whiteknight NotFound: How was your fiesta?
lucian NotFound: yes, i remember 12:13
very annoyin
NotFound whiteknight: good, seeing old friedns, eating, drinking, dancing...
whiteknight NotFound: Sounds like a lot of fun
NotFound And wearing a Mazinger-Z t-shirt X-) 12:14
lucian: in winxed you can use the ? operator to force a boolean context: (a ? 1 : 0) 12:16
lucian NotFound: yeah, i realise. the problem is that many other functions expect ints
like Rosella.Test's assert.is_equal
whiteknight yeah, that's a limitation of Parrot 12:17
lucian very annoying
whiteknight why would anybody ever need to use a boolean outside of a normal integer?
lucian because it's semantically correct 12:18
NotFound We don't have a native boolean type so we can't provide a box/unbox mechanic that do the right thing.
lucian NotFound: exactly. let's have one 12:19
i guess i'll use the ? : workaround in tests for now 12:20
whiteknight We do have a Boolean PMC type, although I always feel like it's pretty heavy-weight to hold a single bit
NotFound lucian: I don't oppose the idea. Can you create an RFC ticket for it?
lucian NotFound: in trac? 12:21
NotFound lucian: yes
lucian ok, i'll put it in the todo list
whiteknight: that shouldn't be a problem, if everything actually used it
NotFound Even if it gets rejected, it may help to clarify when get_bool should be used. 12:22
lucian thinks all types should be boxed, let the JIT unbox things
whiteknight lucian: Yeah, I know
We had talked a long time ago about having a get_bool and set_bool opcodes, as wrappers around the vtables of the same name
If we did that, we could cut out a hell of a lot of stupid jump opcodes. 12:23
NotFound I know, but a ticket is better than isolated talks.
whiteknight yes 12:24
ticket++
cotto +1
lucian campaign name suggestions? 12:25
to put on the ticket 12:26
whiteknight ? 12:32
lucian whiteknight: ticket name 12:33
whiteknight oh, whatever. It's not important 12:36
if it's bad, it can be changed
lucian trac.parrot.org/parrot/ticket/2178 12:37
whiteknight lucian++ 12:38
12:42 bluescreen joined
lucian NotFound: i think i have a feature request for winxed 12:44
NotFound: i have a lot of code like "if(exists foo['bar']){ var bar = foo['bar'] ... }" 12:45
something like if-let would help, a conditional binding 12:46
or maybe something like Groovy's/CoffeeScript's soaking operator ?.
whiteknight lucian: I'm not familiar with if-let. example syntax? 12:48
lucian whiteknight: clojuredocs.org/clojure_core/clojure.core/if-let 12:49
12:49 darbelo joined
lucian in particular clojuredocs.org/clojure_core/clojur...xample_165 12:50
whiteknight bleh. I hate S-expressiony syntax
lucian whiteknight: :P
whiteknight okay, can you give me an example of what you think it should look like in winxeD? 12:51
lucian if(var a = foo['bar'])
but that's a little evil
dalek TT #2178 created by lucian++: Parrot lacks a boolean type 12:52
TT #2178: trac.parrot.org/parrot/ticket/2178
lucian ?. is less general
so intead of foo.bar.baz
you could do foo?.bar?.baz
whiteknight like a defined-or operator?
lucian and if bar didn't exist, or baz didn't exist, the entire expression would return null
whiteknight: yes, sort of
whiteknight var a = foo['bar'] defined-or "def"; 12:53
lucian var a = foo['bar'] ?or "def";
the closest to winxed syntax is the coffeescript feature 12:54
NotFound You mean the equivalent of: (exists foo["bar"] ? foo["bar"] : null)
lucian jashkenas.github.com/coffee-script/ search for "Existential operator" 12:55
NotFound: yes, sort of. but without repeating foo['bar'] ideally 12:56
NotFound Sounds useful, but I don't know how easy can be to chain it.
lucian me neither, at least not on hashes
maybe foo?['bar']
and foo?.bar for attributes
whiteknight parsing that is going to conflict with the current ? syntax 12:58
or, we would have to add a bunch of new operators, '?[', '?.', etc 12:59
NotFound A possible way is to use the ? : operator omiting the second operand, but I'm not sure about its readability,
12:59 cotto joined
whiteknight yeah 13:00
NotFound foo["bar"] ? : null
whiteknight that seems...tricky
NotFound Yes, and its parsing can be ambiguous. 13:01
lucian seems confusing
i like adding ?[ and ?. operators
so "foo?['bar']" would be sugar for "exists foo['bar'] ? foo['bar'] : null" 13:02
NotFound That will conflict with the ? operator. Maybe [? and .?
lucian wouldn't that conflict with [ true ? 1 : 0 ] 13:03
also, it might be advantageous to have similar syntax with other js-like languages (CS and Groovy) 13:04
NotFound Note that for attributes the thing is not so easy, it must catch an exception.
lucian yes, i realise
i've yet to feel a need for it on operators
NotFound No, [? and .? currently are syntax errors, the ? operator needs an operand. 13:05
lucian right
do hashes have a method for silently failing 13:06
?
NotFound exists
lucian i mean a getter that silently fails 13:07
NotFound lucian: that depends on what the PMC does and what you need to know. exists can be true if the value is null. 13:08
lucian hmm
NotFound And hashes can return a null pmc for both cases.
Non existent, or set to null. 13:09
13:10 Tene joined
lucian NotFound: it might be useful to show you the ugly code github.com/lucian1900/puffin/blob/...winxed#L92 13:13
13:19 darbelo joined
NotFound lucian: that cases seems to be a bit more complicated than exists-or-null 13:22
lucian it is, indeed 13:23
but bind-if-exists would help 13:24
13:26 ambs joined, baest joined
Coke Anyone want to take a stab at fixing the release process on os x before I get off work today and do the release? ;) 13:27
cotto Coke, I have a concern. parrot_debugger --help segfaults pretty reliably and I don't feel good about letting that escape. 13:31
that said, it did the same thing in 3.6.0
Coke cotto: ok. I don't have time to fix it, but you have several hours before I get to a point where I can cut a release today.
(one of the reasons I wanted to do this @midnight. ah well) 13:32
cotto Coke, ok
NotFound Coke: It's fine to update the winxed snapshot? 13:34
Coke NotFound: I have no idea what sort of support implications that has, if any. so, go for it?
NotFound I'll go. 13:35
lucian loves the winxed snapshot
it makes boostrapping puffin from scatch last a good 5mins less
or maybe more
cotto awesome. It's trying to treat --help as a file 13:36
why are we shipping this? 13:37
Coke cotto - just remove it from the install target. 13:38
cotto I'll do that.
Coke (also, please add a note to NEWS) 13:39
cotto that too
dalek TT #2179 created by "mzoppet@…>++: Bug in setup-parrot-3.6.0.exe broke PATH
TT #2179: trac.parrot.org/parrot/ticket/2179
Coke NotFound: ditto, please update news mentioning the new winxed version #.
who generated a windows installer for parrot? 13:40
fperrad?
cotto trac--
though at least the information is there 13:41
dukeleto, ping 13:44
I should run parrot_debugger's removal by him first.
atrodo =~
cotto hio atrodo 13:45
atrodo Good, well, i assume it's evening for you cotto?
cotto atrodo, you assume correctly 13:46
it feels wrong being in a timezone so different from most Parrot hackers
atrodo YAPC::EU going well?
cotto quite. lots of facetime with rakudo hackers
finally getting to meet jnthn and masak 13:47
riga is charming 13:48
atrodo Sounds like a good time. Get much hacking in?
cotto more thinking than hacking, but lots of that. good feedback on m0 too 13:49
dalek nxed: 747b557 | NotFound++ | / (2 files):
update NEWS and set version to 1.1.0
whiteknight NotFound++ 13:50
oh, I'm very happy that the multi patch is going to be in this release. Rosella will be able to make immediate use of it 13:51
cotto seen dukeleto
aloha dukeleto was last seen in #parrot 1 days 20 hours ago saying "endeavormac: they seem "unlimited", but of course, you will eventually not be able to store any more due to memory constraints".
cotto whiteknight, care to offer a second opinion on parrot_debugger? 13:52
it segfaults when you pass --help, and has done so since at least 3.6.0
I'm tempted to remove it on that basis, though it looks like it does that because it does excessively simple option parsing 13:53
*remove it from the install
whiteknight of course remove it. Does it do anything useful? Is it workable? Does it provide anything that users are relying on? 13:55
if the answer to all those questions is "no", kill it
cotto I hope not. 13:56
whiteknight and do a little victory dance.
cotto either way, it's easily reversible
whiteknight yeah
my forcast: deleting, with a chance of awesome
atrodo what about just deleting it for release, save the final decision for a less crunched time? 13:57
cotto too late
dalek rrot: 73135c5 | cotto++ | / (2 files):
don't install parrot_debugger

it may work, but segfaulting on --help is a non-starter
cotto goes afk to learn about Go
lucian cotto: on Go, i found this useful www.syntax-k.de/projekte/go-review 13:59
dalek nxed/version_1_1: fd223f9 | NotFound++ | pir/winxed_compiler.pir:
update installable compiler
 14:00
rrot: e4ff789 | NotFound++ | / (2 files):
update winxed snapshot to 1.1.0 and add its news
 14:08
cotto lucian, very 14:11
lucian yay for DRY 14:18
ttbot Parrot 73135c53 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/44650 14:20
whiteknight FFFFUUUUUU 14:21
win32--
let me fire up the build now 14:22
cotto it did the same thing after I made a pod change in a non-code file earlier today
whiteknight++
whiteknight "syntax error at config/auto/arch.pmc line 115, near ')'" 14:23
so that's not good
"syntax error at config/auto/arch.pmc line 115, near '}'"
sorry
config/auto/arch.pm has too many errors
so there's the problem
software.intel.com/en-us/blogs/2011...-has-come/ 14:24
cotto whiteknight, so Configure.pl fails but the build proceeds anyway? 14:26
whiteknight it's not building here
configure fails, that's it
hold on, let me try something else 14:27
oh wait, I think I had a messed up local setting. It's building now
cotto looks like removing parrot_debugger from the install didn't cause any surprises
sounds like progress 14:28
whiteknight progress++
cotto (boring releases)++
whiteknight NotFound: ping 14:31
cotto allison, ping
whiteknight everybody: ping 14:32
allison cotto: pong
cotto allison, Parrot's gradually moved from thinking of itself as being close to hardware to being more abstract.
I'm thinking about moving back toward hardware with M0 and would like to make sure that I'm not going down the same road we've already been down.
allison cotto: the thing to watch out for is portability 14:33
cotto I'm looking to reduce the impedance mismatch between M0 and hardware so that the generated code will be easier to make efficient.
allison cotto: M0 shouldn't be too closely tied to any one architecture
cotto a minimalist instruction set guarantees that we'll be generate poor code without an optimizer, which isn't optimal
allison but, on the other hand, since M0 is tiny, it makes it much, much easier to port 14:34
cotto allison, absolutely
allison so, it's totally possible to have some parts that are closely tied to one architecture
the Linux Kernel is a good model here
cotto yes
that's definitely part of the charm of a small VM
allison they make a clear distinction between the "general" parts and the "architecture dependent" parts
(even to the point of segmenting off architecture-dependent directories 14:35
What you don't want is a confused mish-mash of what is or isn't architecture-dependent
lucian allison: the point here is that if M0 is too small, certain constructs will have to be composed, when they might be already existent on most platforms natively
cotto I'd been thinking of separate interpreters, but that's a good way to do it.
lucian, yes 14:36
allison so, if a component is architecture dependent, it is segmented off and customized for all architectures
lucian so all modern archs have vector units
allison lucian: right, it should be totally allowed to have an M0 op be "straight to native" on some platforms
lucian but M0 has nothing to support that
14:37 darbelo joined
whiteknight If M0 is the common lowest-level language, what we need are platform-dependent optimizers and platform-specific JIT 14:37
in addition to maybe a suite a higher-level optimizations which can operate irregardless of platform
allison but, we also want to steer clear of the pain of the old JIT, that involved hand-crafting a huge number of statements for each architecture
lucian whiteknight: it seems to me that interesting platforms already have a similar set of features. so platform-specific (non-peephole) optimisers shouldn't be necessary 14:38
allison (again, the beauty of the small op set in M0)
cotto allison, can you shed some light on Parrot's move away from thinking as itself as close to hardware to more abstract 14:39
whiteknight lucian: Right, that's what I'm talking about. Platform-specific peephole optimizers, mostly
allison cotto: I'm not sure it ever did think of itself as truly close to the hardware
cotto: its background is in interpreters like Perl
cotto allison, ok.
dukeleto we already deleted a platform-specific JIT. Some parts of a JIT can be platform specific, but maintaining platform-specific JIT opcodes again is not a goal we should have
allison cotto: it has certainly been inspired by hardware models all along (register-based, etc) 14:40
cotto allison, definitely yes wrt a small op set. Still, even 100 is reasonable.
lucian whiteknight: and any existing jit framework has peepholes already written
whiteknight every JIT has to be tied to the platform in some way. You can generate "general" machine code
can't
lucian whiteknight: except when it can, i.e. llvm ir, nanojit ir 14:41
whiteknight if we want to avoid writing platform-specific JIT code, we need to use an existing JIT that somebody else went through the pain of writing
ttbot Parrot e4ff7891 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/44667
lucian the way i see it, a goal for M0 should be straightforward, efficient mapping to at least LLVM IR
allison whiteknight: indeed, but you can compose JIT code for macro-level ops from JIT code for M0 ops
14:41 JimmyZ joined
whiteknight there will be pain, the question is how little of it we take upon ourselves 14:41
allison whiteknight: which radically reduces the effort of JITting on a new platform
whiteknight: what our previous JIT proved to us is that we can't rely on anyone else to do the porting either 14:42
whiteknight: so, it's either ourselves, or no one
lucian allison: but that's a pasting jit, and it sort of sucks :)
allison lucian: it's better than no JIT :) 14:43
cotto I'd like to see different backends that use e.g. llvm, gnu lightning, etc. cpu-specific code is definitely out
allison lucian: and more can be built on top of it
whiteknight What sucked most about our previous JIT was maintainability. Every time we added a new op, or changed an existing op, we needed to recreate the exact same changes in several files for several platforms
lucian cotto: i don't think that's a realistic goal
dukeleto firefox uses both nanojit and nitro, for tracing and method-based JITting. It chooses between them via heuristics about hot code
whiteknight and when you have 1300+ ops and variants, that's a nightmare
cotto whiteknight, yes. If we can keep m0 mostly static, much pain goes away.
allison whiteknight: yup, 1300+ is unworkable for manual JITting 14:44
lucian dukeleto: yes, it defaults to tracing (with nanojit) and uses method-jit (nitro) for generally hot methods
allison whiteknight: also, our previous JIT wasn't actually "just-in-time"
lucian dukeleto: with a slightly different approach it's possible to use only tracing (what PyPy do)
whiteknight What we need in a JIT is all the bells and whistles: We need optimizations, tracing, type specialization, and other details. We would never have gotten there with the old architecture
allison whiteknight: it was pre-compiled
whiteknight a JIT that doesn't do aggressive type-specialization is worthless in the modern world 14:45
dukeleto and spidermonkey (the main javascript vm for firefox) has something call interpolines (interpreter trampolines) which are tiny bits of platform-specific code (possibly assembly). I am still trying to fully understand it, but it seems to be the only platform-specific part of spidermonkey
cotto whiteknight, eventually, yes. We can still get meaningful performance just by using a dumb jit. 14:46
dukeleto whiteknight: the mozilla people call it "type inference" and have been breaking new ground in that area. They are doing *static* type inference for Javascript, which is kind of amazing.
whiteknight cotto: all a dumb JIT is going to do is reduce op dispatch costs
lucian whiteknight: the effort of writing a good JIT may dwarf the effort of supporting x86, x86-64 and ARM (the only relevant platforms)
v8 and PyPy have certainly gone that route
cotto whiteknight, which will be meaningful for small ops
whiteknight lucian: right. That's why I think that our best bet is still to use an existing JIT
cotto allison, thanks 14:47
whiteknight Compare how many coders we could devote 100% to a complete in-house JIT infrastructure, against how many coders Mozilla can throw at the problem, or LLVM
lucian whiteknight: sure, if possible. but i've yet to see a successful project use an off-the-shelf jit
allison cotto: anytime, and thanks for thinking of it
whiteknight lucian: if we devote two coders, some of the time, to brewing our own, it will not be successful either
dukeleto from what I can see in Firefox, they have easily spent dozens to hundreds of dev-years already on their JITs, and they didn't develop it from scratch. They built on existing tech (nanojit and nitro)
lucian whiteknight: of course, which is why we should choose two platforms and try 14:48
whiteknight and that's two coders without any distractions, without a deprecation policy in the way, and without real life botching the schedule
dukeleto whiteknight: indeed. Writing our own JIT from scratch is just a non-starter
allison someone recently asked me if v8 JIT could be split out as a reusable library for Parrot
whiteknight lucian: I don't care if it's two or whatever. We do have to start from somewhere
allison I don't know
lucian allison: no
dukeleto allison: the v8 JIT is very specialized to Javascript
atrodo allison> I was hoping for a better answer
whiteknight allison: I've looked at v8 before. I think it's too JS dependent
lucian allison: others have asked before, it's not realistic
allison on the whole, I think we'll be doing well to support a few existing JIT libraries 14:49
and see what works best
lucian allison: to me, that seems about as hard as supporting a few archs
whiteknight We have to pick one to start with, and I think we've already made a good decision with LLVM
atrodo allison> However, if, in a magical world, m0 existed on as a JS backend, that could be
cotto rolling our own is a non-starter. I hope no one thinks I'm suggesting that.
lucian all we'll get from a JIT library is cross-platform IR and a peephole optimiser
dukeleto whiteknight: have we? do we really do much with LLVM yet?
lucian whiteknight: uh, everyone who's tried llvm has failed so far 14:50
allison atrodo: Parrot already has several JS implementations, so yes, one possible use case would be v8 as a JIT backend for Parrot *only* with JS
whiteknight dukeleto: We don't do anything with LLVM yet, but it's as good an option as any. It's maintained, and it's not hopelessly tied to a particular language or semantic
lucian whiteknight: it's just very, very bad
cotto lucian, great. We can learn from them.
allison whiteknight: well, LLVM as a static compiler is well maintained
lucian whiteknight: and it is hopelessly tied to C semantics
allison: indeed. and jus tthat
whiteknight Parrot is written in C
allison whiteknight: LLVM as a JIT is not, which the unladen-swallow guys definitely proved
atrodo allison> I think you misunderstood. Imagine a m0 interp written in js 14:51
lucian both PyPy and unladen swallow have shown that LLVM sucks for JITs, and is very buggy on top
cotto atrodo, I have been.
allison whiteknight: (they also improved it, but it has a lot of work needed)
whiteknight so then what are the alternatives? We need at least one JIT, if we plan to support more than one
lucian whiteknight: right, but HLLs aren't C
whiteknight the one is where we need to start
allison atrodo: I try to take JS as a backend language seriously, but I just can't
lucian rubinius are having moderate success with llvm
whiteknight so what's the first one? v8 and most of the current-gen JS ones are out
lucian but they're only using it for assembly
they do their own optimisations
whiteknight LLVM is apparently not popular 14:52
allison atrodo: no matter how good the VM gets, the language itself is for writing web pages
atrodo: not a good general-purpose language
lucian allison: i'd dispute that
allison: but hijacking v8 is probably a bad idea
allison lucian: it's not just a predjudice on my part, I've been a JS developer almost from the start of the language
lucian i see a few platforms to target: llvm, nanojit, lightning, x86, ARM
whiteknight lucian: So pick one to start with 14:53
allison lucian: languages have domains where they're well suited, and domains where they're poorly suited
whiteknight we're not going to write a 5-way JIT subsystem to start out with
lucian allison: it's still much better than many languages people use nowadays
atrodo allison> if you had asked me a year or two ago, i would have agreed. and then this: imrannazar.com/GameBoy-Emulation-in-JavaScript
lucian whiteknight: of course not. two-way at most for prototyping, i would guess
allison lucian: I take it a bit like Java. The VM is state-of-the art, with amazing features that are still poorly exposed in the Java syntax
whiteknight lucian: okay, so pick two
lucian whiteknight: x86 and ARM, or llvm and nanojit 14:54
allison atrodo: sure, it's turing complete, and you can implement anything in a turing complete language
cotto lucian, are you suggesting cpu-specific code, and who'd maintain it?
allison atrodo: you can implement anything in assembly language
whiteknight lucian: when you say x86 and arm, what do you mean? Writing our own JIT for those?
lucian cotto: whoever'd maintain the llvm backend
whiteknight: yep
cotto lucian, ok
lucian there are only two relevant CPUs: x86 and ARM 14:55
allison atrodo: that doesn't mean it's well adapted for ease of use, maintainability, or high-quality code for that domain
lucian it's likely about as much effort as dealing with llvm, on the whole
allison drat, meeting, and this is an interesting conversation :)
later all
cotto actually, the important thing is to get M0 defined. if you want to go nuts and write a pure x86_64 jitting interpreter, that's fine. ;)
lucian waves
atrodo allison> I agree. But it makes it possible in my mind. Maybe not ideal or anything, but reasonably possible
cotto allison, thanks for dropping by
lucian cotto: of course. as long as M0 is not lower level than x86 or ARM 14:56
cotto lucian, that'd be difficult
lucian cotto: how so?
cotto x86 is pretty low-level 14:57
lucian if it's lower level that the platforms it targets, how will it ever be efficient?
cotto: nvm, misread
so if M0 has everything that x86 and ARM have in common, and is not lower level than either one, it's fine
cotto gets deconfused
whiteknight broad-spectrum optimizations are going to be happening at higher levels. HLL compilers will optimize, and PCT will optimize. Once we get down to the PIR/M0 level, what's left are peephole optimizations
lucian may want to add LLVM IR and nanojit IR there
whiteknight: exactly 14:58
whiteknight: also, there will have to be a parrot-specific JIT bit
whiteknight we don't need a JIT to be doing huge, broad optimizations. We need a JIT that does basic peephole optimizations and can emit basic platform-specific machine code
cotto yes
atrodo cotto> This is where I think composed ops could help. You'd end up with a JITable code, but if a platform understands a particular composed op, it can optimize it further
whiteknight so if LLVM's optimizations are unsuitable for dynamic languages, that doesn't impact parrot at all
we wouldn't use them anyway
atrodo platform = platform or jit engine
whiteknight So, ignoring all that crap, we need a JIT backend library that can generate machine code for our target platforms 14:59
We can do tracing and type-specializations in Parrot
lucian atrodo: that sounds useful
atrodo: but i don't think it's too relevant. x86, ARM and LLVM IR are *very* similar 15:00
whiteknight broad optimizations at the HLL and PCT levels, type-specialization and tracing at the parrot level to generate an M0 stream, and a JIt backend to do M0->machine code
lucian rather, the sane subset of x86 that everyone uses
whiteknight If M0 ops are fixed-width, tracing can actually become extremely easy 15:01
lucian whiteknight: my point about llvm is that it's only marginally better than generating C, compiling and linking at runtime
cotto and generated C can be pretty heavily optimized
whiteknight lucian: So what? For a first JIT system it doesn't need to be fantastic
Put together the prototype, build a suitable abstract interface around it, replace the backend with something better
lucian whiteknight: sure. but you end up having to deal with llvm, which is huge and buggy
whiteknight lucian; and under active development 15:02
that's a bit not to be underestimated
lucian it's been like that for years
it has only had small improvements for JITs
whiteknight lucian: that doesn't bother me
lucian that may of course change
whiteknight Parrot's object model hasn't had any love for years, but that doesn't mean I'm going to bet against it getting love in the future 15:03
lucian another option could be using an existing vm framework
whiteknight: right, but parrot's object model is microscopic by comparison
cotto whiteknight, you'd be wise not to do so ;)
lucian you may be underestimating just hog mind-bogglingly huge and buggy llvm is
s/hog/how/ 15:04
whiteknight lucian: and you may be overestimating
atrodo s/llvm/parrot ;)
cotto lucian, do you have some blog posts by hackers with scars?
whiteknight If the Rubinus people are using it, it can't be all bad
cotto atrodo, enough out of you ;)
whiteknight The plight of the unladen swallow people is an interesting story, but hardly the law of the land
lucian cotto: morepypy.blogspot.com, older posts. also rubinius and unladen swallow
whiteknight: sure, it's doable. just very, very hard. also, rubinius folks like C++ 15:05
atrodo cotto> Sorry, couldn't resist. 15:06
whiteknight What I need is to get email addresses for some of these pypy people and start communicating with them 15:07
cotto +1
lucian whiteknight: join freenode#pypy
if all of parrot is to be rewritten in M0, it could even be done with PyPy itself
write the VM in RPython, the rest in M0
get GC and JIT for free 15:08
but that's likely to be unpopular
cotto it'd be a hard sell
lucian when i have time, i'll try writing a M0 interpreter with PyPy
cotto but we'd have to have a mostly-M0 parrot first anyway
lucian sure
cotto lucian, I'd recommend waiting for a bit. I suspect some big changes will be coming down the pipeline 15:09
but I'd like to see it
lucian not like i have time for it now, anyway :) 15:10
whiteknight If we run on top of another VM, Parrot is no longer a VM in itself. It becomes little more than a runtime library 15:11
lucian whiteknight: no, PyPy is a framework for generating VMs
you write an interpreter in RPython, and it spits out a VM with a JIT for you
there's an unfortunate naming clash with pypy, the python interpreter written in RPython
py.py, rather 15:12
so the fast python vms PyPy has (pypy-c-jit) are generated by translating py.py with the PyPy translation framework to C
and during translation, interesting aspects are added (GC, JIT) 15:13
whiteknight ok
lucian in fact, if that perl M0 interpreter had been written in Python instead, we'd almost have it 15:14
cotto and we'd have ctypes 15:15
which would be quite nice
lucian cotto: there's _rawffi (or _ffi) which is just a libffi binding
ctypes on PyPy is purely app-level, on top of _rawffi
JimmyZ Parrot on pypy :) 15:16
lucian anyway, all this requires parrot being M0
which i think is a good idea, but isn't the case at all now
JimmyZ and then Perl 6 on pypy ?
cotto yeah. It's good to give it some thought, but not in too much detail.
lucian JimmyZ: sure, why not. it'd be easier to just write a perl6 interpreter directly, in fact
JimmyZ: it's another cultural thing. rubinius folks would've been much better off using PyPy, but they didn't because it's Python 15:17
JimmyZ language is not problem 15:18
s/not/not a/
lucian in some cases, it is 15:19
JimmyZ I think missing coder is a real problem
it's make me remember what linus said from a email, the creator of linux "talking is cheaper, show me the code" ;) 15:22
cotto time for noms 15:23
JimmyZ doesn't what noms means, nom branch of rakudo? 15:24
doesn't know
dafrito JimmyZ, noms is likely eating ;)
lucian JimmyZ: nom-nom-nom. muching
s/munching/
JimmyZ oh, whenever pmichaud++ said noms, I always thought nom branch of rakudo, which is exciting 15:26
hehe
cotto #ps is during dinner. I'll try to make it. 15:27
can't say for certain I'll be there though 15:28
15:34 Tene joined
whiteknight win32 build is definitely broken, and I'm not able to look at it now 15:36
15:37 darbelo joined
whiteknight wait, it looks like it's going this time 15:39
weird, must be a makefile issue 15:40
15:42 dmalcolm joined
JimmyZ built parrot successfully with strawberry perl 15:47
whiteknight win32 build, all tests pass
lucian whiteknight++
whiteknight smolder.parrot.org/app/projects/rep...ails/21141 15:48
15:54 mj41 joined 16:36 theory joined
dalek kudo/nom: 15ef06f | moritz++ | src/ (2 files):
implement numification of strings like :16<BEEF>, and :16("BEEF") style conversions

This is only a first rough cut, and does not support a lot of features		 16:45
17:05 jsut_ joined 17:12 jay joined
whiteknight mmmm. beef 17:15
herbsutter.com/2011/08/12/we-have-a...-approved/ 17:51
benabik C++0xB! 17:52
lucian huh. they still haven't taken things out, have they?
whiteknight take things....out? 17:53
that sentence doesn't parse, in the context of C++
lucian even with 7 parsing passes! bam
thank you, i'll be here all night
benabik 0xB is a significantly improved language. Lambas, auto typing, improved libraries… Now we just have to wait several years for everyone to support it. *sigh* 17:54
lucian benabik: right. but it's still the most gigantic and inconsistent language on earth 17:55
and the new standard is even more gigantic
whiteknight is it bigger than perl6? 17:57
lucian whiteknight: don't know perl6 in detail, but i'd guess it is
benabik I personally find it an extremely useful language, that adds a lot of power without adding a ton of overhead. But I also realize I'm in a significant minority.
whiteknight benabik: where you lose people is in the "without adding a ton of overhead" 17:58
17:58 contingencyplan joined
whiteknight maybe it doesn't have a lot of runtime overhead 17:58
lucian benabik: i like those particular properties. i just think it's an overly complex language
benabik whiteknight: That's what I mean. It does have an unfortunate tendency to explode in size… But when I'm trying to explore large keyspaces I need runtime performance. 17:59
lucian: I find it fairly clear. People regularly use horrible styles of programming with it, which I find unfortunate. But I find the base language clear. 18:00
lucian benabik: that surprises me a lot. i find it extremely ambiguous and odd
there's a reason it's so hard to parse 18:01
whiteknight is upgrading to FireFox 6.0 18:03
prepare for cursewords!
benabik I should probably try FF again at some point. But it has this horrible tendency to absorb all my memory.
jay benabik: I'm hooked on FF. Doing big data scrapes right now to prepare for the draft in two weeks. 18:11
benabik jay: And firefox makes that easy how? 18:12
jay lol Sorry. Fantasy Football... you can tell my mind is elsewhere. Actually have severe jetlag, too. Oh well. 18:13
benabik jay: Ah. Fair enough. Fantasy Football seems to absorb all your memory, just like Firefox aborbs all my computer's. ;-)
jay benabik: exactly. My FF frustrations include different plugin behavior on different Ubuntu installations... clearly my fault, but hard to pin down. Sometimes video works, other times not. 18:15
18:25 whiteknight joined 18:32 Coke joined
Coke ~~ ## home machine was apparently rebooted. 18:32
whiteknight hello Coke 18:36
18:50 alester joined 19:14 soh_cah_toa joined 19:25 cotto joined 19:36 kid51 joined
kid51 Coke: On OSX, does 'man openssl' have anything you can use re sha256? 19:37
19:37 daniel-s joined
tcurtis ~~ 19:38
whiteknight hello tcurtis 19:39
tcurtis hello, whiteknight. 19:41
cotto whiteknight, #ps?
benabik Arg! I must have gotten more used to the old #ps time than I thought. 19:42
cotto no complaining. I'm halfway across the world. ;)
benabik cotto: It's more just irritation at myself for forgetting to show up on time than irritation about the time. 19:43
whiteknight that time already? 19:44
cotto 'fraid so
19:52 particle1 joined 20:11 rdesfo joined
cotto soh_cah_toa, did you see that module I msg'd you? Someone did a talk on it at yapc and I thought of your HBDB test code 20:12
soh_cah_toa let's see...
there it is
cotto I just sent a link because I didn't want my attention to diverge from the talk too much. 20:13
soh_cah_toa this looks interesting
cotto: wow, i'm glad you saw this 20:14
i'm downloading the source now. see what i can borrow
cotto if it's useful enough as-is, we can bundle it 20:15
soh_cah_toa ok
whiteknight what is it? 20:23
cotto whiteknight, it encapsulates running a process and dealing with stdin/stdout/stderr and exit codes 20:24
benabik kid51++ # doing legwork 20:27
soh_cah_toa kid51++ indeed
Coke kid51: I've no tuits to figure out at the moment what the drop in replacement for that linux command is, so Iunno. 20:32
20:38 bluescreen_ joined 21:11 perlite_ joined, plobsing joined 21:45 Psyche^ joined
Coke sits down to try the release again. 22:16
sorear eep. what happened? 22:17
22:17 mj41 joined
Coke linux-specific code in the release path. 22:17
22:17 rdesfo joined
Coke my main box is OS X. re-doing on feather. 22:17
sorear ... 22:18
dalek rrot-gmp: 42941e4 | bubaflub++ | LICENSE:
Add artistic license 2.0
 22:19
rrot-gmp: 08879a3 | bubaflub++ | / (4 files):
update some docs
sorear I'd say "seriously?" but I think I know the answer.
Coke eh. there's a very small # of people that have to do the release. 22:20
and the problem is very fixable.
(it's just the use of sha256sum, SFAIK)
wtf. feather and git don't seem to be talking to each other.
*github 22:21
anyone else able to git clone/pull/fetch on feather to a github origin? 22:23
sorear yes 22:24
22:24 darbelo joined
lucian has written a long blog post honeyweb.wordpress.com 22:25
phew
sorear Coke: correction: I can pull from gist.github.com but not github.com, from featuer
feather
22:29 ReachingFarr joined
dalek website: lucian++ | The End. 22:29
website: www.parrot.org/content/end.
Coke ARGH. 22:30
so now I have to fall back to plan C, which is making "make release" work on OS X.
lucian dalek: no, bad dalek. this is the link honeyweb.wordpress.com
sorear Coke: *I can pull from the github main site* 22:32
Coke remembers he's got a linux laptop around here somewhere, and goes off to find it.
sorear: yes, but I cannot.
sorear have you tried in the last minute or two?
I was having a problem too but it started working again for me 22:33
Coke nope. it's just hanging. if I run it with -v, looks like it's talking to the server, even. 22:35
ReachingFarr Is it possible to execute parallel code inside the Parrot VM? 22:38
lucian Coke: github wfm
23:11 kid51 joined 23:23 theory joined
dukeleto Coke: sha256 = shasum -a 256 . do you have shasum on os x? 23:24
kid51 $ perl -e "print qq(abc)" | shasum -a 256 23:25
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad -
On Mac OS X 10.4.11
Will that work for us?
dukeleto yes 23:28
lucian++ # blogging
kid51 On Mac OS X: 23:32
$ shasum -a 256 Parse-File-Metadata-0.07.tar.gz
831240e0ca832283ec18016517fcbf5c8e67751c1b8213686815c5825dad8e57 Parse-File-Metadata-0.07.tar.gz
On Linux (Debian):
sha256sum Parse-File-Metadata-0.07.tar.gz 23:33
831240e0ca832283ec18016517fcbf5c8e67751c1b8213686815c5825dad8e57 Parse-File-Metadata-0.07.tar.gz
works4me
Coke dukeleto: awesome. someone should totally probe for which one of those is the right one. For now, I'm just doing the release on linux. 23:42
I will attempt to provide a patch for that post release. 23:48

Powered by Cro and the Raku® Programming Language.

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

Thank you!