Parrot 3.1.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Get more GSoC ideas on wiki; close tickets; stable 3.2 release; assess status of roadmap goals for 3/15 meeting.
Set by moderator on 9 March 2011.
dalek p/ctmo: f35478c | jonathan++ | src/NQP/Actions.pm:
Oops, forgot to pass args along to MAIN.
 00:03
p/ctmo: 42e8507 | jonathan++ | src/stage0/ (6 files):
Bootstrap with fixed @ARGS; need that for the compiler itself.
00:03 kid51 joined
dalek p/ctmo: 9179b83 | jonathan++ | src/NQP/Compiler.p (2 files):
Final switch over to having everything in Compiler.pm; toss Compiler.pir. For the first time, this means you can now write a compiler totally in NQP, without needing to write any PIR.
 00:10
p/ctmo: ca5da70 | jonathan++ | build/Makefile.in:
Fix make bootstrap-files.
 00:25
p/ctmo: 162e287 | jonathan++ | src/stage0/ (6 files):
Update bootstrap with fully-NQP NQP.pbc (mostly just to make sure it works ;-)).
00:49 woosley joined
dukeleto cotto: did you have a question for me last night? 01:14
dalek tracwiki: v33 | bacek++ | GSoc2011 01:47
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
dukeleto bacek_at_work++ 01:52
bubaflub hey dukeleto, i'm thinking more about the GMP wrappers for GSoC 02:01
and reading up on NCI stuff
02:02 whiteknight left
cotto dukeleto, still around? 02:18
02:19 kid51 left
cotto dukeleto, for ffi, I'm thinking about three primitive ops: one to set the return type and location, one to set a single argument type and location and one to call a C function after everything's set up. 02:25
libffi has a list of 20 types that looks like it'd be a good basis for those ops.
using that, here's what I'm thinking: 02:26
nopaste "cotto" at 192.168.1.3 pasted "M0 ffi with args" (10 lines) at nopaste.snit.ch/37370
dukeleto cotto: yep 02:29
bubaflub: mmmm, GMP wrappers
cotto I'd link to libffi's docs, but they don't seem to have them online
dukeleto !!! 02:30
bad form
cotto github.com/atgreen/libffi/blob/mas...ibffi.info <- is the closes
t
dukeleto bubaflub: another idea that i have is Parrot binding to OpenCL
bubaflub: i just got a fancy GPU and of course I need to do math with it instead of using it what it is actually for
cotto: that looks reasonable. i like it 02:31
bubaflub dukeleto: i hear OpenCL stuff is tough (regardless of wrappers)
dukeleto: but we could throw it up on the ideas wiki page 02:32
dukeleto bubaflub: tough in what way? 02:33
cotto dukeleto, actually, I think those ops wouldn't be great for generating thunks. A better interface would allow separation between thunk generation and usage.
bubaflub dukeleto: not so easy to write code that always gets a good speed boost
dukeleto: what i know is mostly hearsay
cotto maybe it'd be better to have a thunk handle or memory address as an additional arg. 02:34
dukeleto bubaflub: don't put the cart before the horse 02:35
bubaflub: having opencl bindings to parrot will open up huge possibilities
bubaflub: but yes, doing anything worthwhile is usually not trivial 02:36
bubaflub: but some things are "embarrallel", i.e. "embarrassingly parrallel"
bubaflub: and new graphics cards have like 128 GPUs on them, so doing crypto/number theory stuff just screams
cotto: i dont' fully understand the intricacies of thunk generation 02:38
cotto: but i would say, let's start simple and iterate towards greatness
cotto: we should plan an IRL M0 hackathon 02:39
bubaflub dukeleto: true to all the above
dukeleto: beyond the basics, i don't know a whole lot about OpenCL
dukeleto cotto: i would be willing to take the train up to Seattle
cotto dukeleto, cool
dukeleto bubaflub: nor do I, but I am still excited about it
cotto dukeleto, no car?
dukeleto cotto: car-free by choice 02:40
cotto dukeleto, interesting.
dukeleto cotto: have never been happier ever since I sold my truck. Portland is the bike Mecca of the US 02:41
cotto dukeleto, indeed. I wish this area were better (and drier)
dukeleto cotto: perhaps we could wrangle a meeting with particle when we meet up in Seattle
cotto: there is no bad weather, only insufficient gear
cotto: just about everything I own now is waterproof :) 02:42
cotto dukeleto, by "thunk generation", I mean that we have a good way to call a thunk that's already been set up
dukeleto cotto: i will play devil's advocate for a bit
cotto as opposed to setting one up each time we need an ffi call
dukeleto cotto: what is the minimum amount of FFI that M0 needs to know about?
cotto: can we worry about that junk at the M1 level?
cotto dukeleto, If set_args and set_returns immediately execute the code to setup the call, I don't think so 02:43
(meaning that M0 does need to know how to provide ffi thunk caching) 02:44
dukeleto ok, that is something that should be written down in the spec, since it seems important yet not immediately obvious 02:45
cotto deal 02:46
dukeleto cotto: A = { all FFI functionality }, B = { FFI functionality of M0 }, what is in A - B ?
cotto: where A - B denotes set difference
dukeleto loves being nerdy
cotto: i am trying to tease things out of you, because I really have no clue 02:47
cotto dukeleto, let me write it up and see if I can be understandable 02:48
dukeleto cotto: works for me 02:52
bubaflub dukeleto or cotto: if i'm fixin' to do a GSoC project for writing GMP bindings in PIR should i worry about M0/Lorito stuff? 02:58
cotto bubaflub, not now. Our stated goal it to preserve pir-level compatibility, so you should be fine if you use PIR. 02:59
dalek tracwiki: v34 | dukeleto++ | GSoc2011 03:00
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
bubaflub cotto: roger that.
dukeleto bubaflub: yes, you can just blissfully ignore M0 for now 03:01
bubaflub *whistles innocently*
atrodo cotto> I'm curious to know how you feel we are doing towards the m0 goal in april 03:02
dukeleto bubaflub: me and cotto are trying to redo the foundation without anyone in the top floor noticing, basically
bubaflub haha. tricky remodeling.
dukeleto bubaflub: yeah. but never-the-less, fun 03:03
atrodo: for the 3.3 release ?
atrodo: i would say, if me and cotto have a real-life hackathon one weekend, we might just be able to have some kind of prototype then
atrodo dukeleto> That time area. I can't remember if the deadline was 3.3 or pds
dukeleto atrodo: but if we interpolate from our current pace, it doesn't look good 03:04
atrodo: i haven't had time in the last few weeks due to various lifey things getting in the way
atrodo dukeleto: understandable, I've been trying to squeeze time as I've gotten it as well 03:05
dukeleto atrodo: i would say, that in terms of the spec, we have been progressing nicely
atrodo: in terms of the prototype, not so much. But I would rather have a really good spec than a decent spec and a half-ass prototype
atrodo dukeleto: I agree 03:06
dukeleto msg whiteknight i added a gsoc task about porting PL/Parrot to the new embed API. Could you fill in some details and add some appropriate links? 03:11
aloha OK. I'll deliver the message.
dalek rrot/m0-spec: 2489a7a | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add initial draft of m0 ffi
 03:12
cotto atrodo, It's a little behind where I hoped it'd be, but it's not in jeopardy. Having an idea for ffi and concurrency makes me feel like an initial M0 interp by the April release is reasonable. 03:14
dukeleto, +5 on the priorities of a spec and a prototype. 03:15
dalek tracwiki: v35 | dukeleto++ | GSoc2011 03:16
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
atrodo cotto> it looks like arg_type and arg_src are reversed between definition and examples 03:17
dalek rrot/m0-spec: 838cdc9 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
fix example code, atrodo++ for noticing
 03:19
cotto I don't see any silly mistakes.
atrodo these are not the droids we are looking for 03:20
bacek_at_work cotto, (nopaste.snit.ch/37370) you need something to hold "ffi call being generated" 03:31
e.g. 'chunk of memory' 03:32
cotto bacek_at_work, indeed I do
I also don't seem to define either dlopen or dlfunc
bacek_at_work something like "gen_call $P0, [INT32, INT32, $I0, INT32, $I1]" and than "callc 'multiple_int32', $P0" 03:35
plobsing I like what bacek_at_work describes but am concerned it might not work with fixed-width ops 03:36
cotto I like where you're going with that.
bacek_at_work plobsing, "gen_call" has 2 args, "callc" 2 args alos 03:37
also
plobsing what is [...] and where does that live?
atrodo bacek_at_work: I assume the first INT32 is the return type? 03:38
bacek_at_work atrodo, yes
plobsing and if you can get away with that, why not "$P0 = <funcptr>; callc $P0, [INT32, INT32, $I0, INT32, $I1]", avoiding the need to explicitly pass thunks around 03:40
bacek_at_work plobsing, +1
cotto plobsing, is that minimally magical though? 03:43
plobsing no more or less magical than a thunk generator
atrodo So, i just noticed something and it might be from my limited exposure to nci, but does the thunk need the types every time it's called?
cotto atrodo, that's my question too 03:44
plobsing an explicit thunk generation op enforces thunks on any Lorito impl. Combining the signature and the call give more freedom to impls to do better than thunks.
for example, compiling M0 to C, there is no need to be passing around thunks 03:46
so an op that creates thunks would add complexity and pessimization to such an implementation
cotto I see where you're going with that.
atrodo plobsing> The using only one call instead of a gen/call I can understand. But wouldn't combining the signature with the call be inefficient? 03:47
plobsing atrodo: how so?
if you are using thunks under the hood, you can cache them based on signature. If we had reified thunks, users would wind up doing that anyways. 03:48
atrodo plobsing> You have more opportunities to optimize the thunk if you know the signature ahead of time, don't you? 03:49
Plus, you have the added code of verifying the signature at every call
or am I being naive?
plobsing atrodo: I don't understand either of your points 03:50
atrodo well, when you receive the types, you have to verify that they are correct and that you have something to call with that signature with every invocation, right? 03:51
plobsing IF an implementation chooses to use thunks (and without reified thunks, they don't need to be doing so) they will build thunks either at gen-time or call-time. In either case they create a thunk, the resulting thunk will be the same, so I fail to see the opportunity for optimization.
dukeleto plobsing: can you define "reified thunks" ? 03:52
plobsing dukeleto: thunks being an explicit thing you can see, touch, and pass around 03:56
similar to "reified continuations"
dukeleto plobsing: interesting. if they aren't "reified", then what are they? mythical ? 03:57
plobsing atrodo: how would you know a signature was correct or not? would you parse header files? manually maintain a database of type info? or just let it be and assume users are calling with the correct signature? 03:58
cotto you have to assume that users know what they're doing 03:59
atrodo Oh, so it's like the rest of C and trust that the user knows that they're doing. I always hated that about C
03:59 bubaflub left
cotto lta, but hard to avoid 03:59
atrodo Then my concerns about efficiency disappears
plobsing dukeleto: I lack a good word for discussing the absence of reification. It is difficult to separate from the absence of the thing itself. 04:00
using thunks as an example, if the thunks were not reified, would you be able to tell there were thunks? 04:01
non-reified-thunks implementation cannot be differentiated from thunk-less implementation
dukeleto i feel a Zen koan coming 04:03
plobsing dukeleto: reify your enlightenment! 04:05
sorear this enlightenment was formalized, by C I think, it's the "as if" principle 04:07
an implementation can do whatever it wants, as long as the user can't detect violations of the rest of the standard 04:08
dukeleto observes a single unreified thunk clapping and is enlightened 04:18
04:48 theory left
cotto does anyone know what all the splint*.log files in andy's splint-quiet branch are? 05:13
nm. they went away 05:14
trac's wiki needs a blame 05:27
dukeleto submitted 4 talks to YAPC::NA tonight. I hope at least one is accepted. 05:32
05:42 ShaneC left 05:46 ShaneC joined 06:24 davidfetter joined 06:30 davidfetter left 07:01 rurban_ joined 07:03 rurban left, rurban_ is now known as rurban 07:26 fperrad joined, jsut_ joined
dalek rrot/m0-spec: 864c16d | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add some considerations for ffi, note a hole in the current proposal
 07:30
rrot/m0-spec: 1bd7d6c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add altneratives suggested by bacek++ and plobsing++
07:31 jsut left
cotto I feel good about the possibility of hammering that section into something sensible by the middle of the week. 07:31
07:34 mtk left 07:41 mtk joined
moritz "Parrot VM: Can't stat , code 2." 08:18
what does that mean?
nqp: pir::stat('')
p6eval nqp: OUTPUTĀ«error:imcc:syntax error, unexpected PREG, expecting '(' ('$P16')ā¤ in file 'EVAL_1' line 35169735ā¤syntax error ... somewhereā¤current instr.: 'nqp;HLL;Compiler;evalpmc' pc 30577 (gen/hllgrammar-grammar.pir:2153)ā¤Ā»
moritz nqp: pir::stat__isi('', 0) 08:19
p6eval nqp: OUTPUTĀ«error:imcc:syntax error, unexpected IREG, expecting '(' ('$I16')ā¤ in file 'EVAL_1' line 22ā¤syntax error ... somewhereā¤current instr.: 'nqp;HLL;Compiler;evalpmc' pc 30577 (gen/hllgrammar-grammar.pir:2153)ā¤Ā»
dalek p/ctmo: 1308785 | moritz++ | src/HLL/Actions.pm:
get rid of a Q:PIR block that is available as a pir:: primitive
 08:30
p/ctmo: 43a41af | moritz++ | src/HLL/Actions.pm:
convert string_to_int to nqp
p/ctmo: ea95252 | moritz++ | src/HLL/Actions.pm:
rewrite ints_to_string in nqp
p/ctmo: 7046f2c | moritz++ | src/stage0/ (6 files):
update bootstrap, just to show that it still works :-)
08:31 mj41_nb joined
dalek p/ctmo: 9e6576b | moritz++ | src/HLL/Actions.pm:
remove the last Q:PIR from HLL::Actions
 08:32
09:19 Drossel left 09:20 contingencyplan left
dalek p/ctmo-no-p6regex.pir: b33dc05 | moritz++ | / (3 files):
first shot at removing P6Regex.pir. Diws with "Can only use get_how on a RakudoObject"
 09:27
09:27 jsut joined, Kulag joined 09:31 lucian joined, alin joined 09:32 jsut_ left 09:45 lucian_ joined 09:48 lucian left 09:51 lucian_ left 09:53 lucian joined 09:54 Kulag left 09:55 woosley left 09:59 lucian left 10:03 jsut_ joined 10:07 jsut left 10:12 particle1 joined 10:15 particle left 10:16 ShaneC left 10:30 Kulag joined 10:51 ambs joined
Coke . 12:05
12:07 novabyte joined
novabyte is there any news on the development status of Lorito? is there any codebase for the project? 12:10
atrodo novabyte> Besides my prototype side project, the only development has been on the m0-spec github.com/parrot/parrot/blob/m0-s...d32_m0.pod 12:19
novabyte atrodo: is your prototype available to look at? 12:20
atrodo novabyte> github.com/atrodo/lorito 12:21
novabyte atrodo: the M0 spec describes the VM as something different to Lorito? why two different names? 12:22
atrodo but it does predate the spec, so it's not aligned with the spec
novabyte> Mostly because the term lorito gets tossed around for a lot of different things. M0 is a part of the Lorito group and has a narrow, specific definition 12:23
novabyte atrodo: thx. I wanted to do some work on Lorito for my master's thesis, after remembering it while researching projects. Everything seems very heavily scattered around... 12:25
12:25 bluescreen joined
atrodo novabyte> It's getting better the more people work on it 12:25
12:26 lucian joined
novabyte atrodo: of course, but adoption should be as easy as possible IMHO :) 12:26
atrodo novabyte> I agree, certainly 12:27
novabyte atrodo: I'm got 4 months focused time to work, I'm not sure whether I'd be spending a lot of that time (too much) gathering a formal specification for the development. 12:28
atrodo novabyte> gathering a formal spec for lorito? 12:30
12:30 whiteknight joined
novabyte atrodo: or a subset of it that I could use to develop the VM. 12:30
* or a subset of the VM* (more likely) 12:31
moritz novabyte: I guess it's more productive to spend more time prototyping and less speccing
atrodo novabyte> Interesting. So mind if I ask what the thesis is on?
whiteknight good morning, #parrot 12:32
novabyte moritz: the problem is at the end I have to conclude on how "successful" the research/development was... very difficult without goals
morning 12:33
moritz novabyte: there are ways to set goals that allow such prototyping
novabyte: there is already a rough consensus about what ops should be supported (around 20, iirc) 12:34
whiteknight novabyte: What level is this research project of yours? Bachelors? Masters?
moritz novabyte: so your goal could be "a prototype that can run those 20 ops, at least as fast as parrot can execute comparable ops now"
novabyte atrodo: the thesis topic is open at the moment. my supervisor (and I) are interested in VM, compiler optimisations, superoptimisers...
atrodo novabyte> neat, sounds fun 12:35
novabyte whiteknight: it's masters (not enough time to do a lot :()
whiteknight okay
novabyte whiteknight: got to earn some money after that ;)
moritz novabyte: jnthn_ has a proposal for speeding up multi dispatch in rakudo - maybe you'd be also interested in that kind of optimization :-)
it was for GSOC, but could probably be "stolen" 12:36
whiteknight novabyte: In preparation for GSoC this year, we're putting together a list of potential projects here: trac.parrot.org/parrot/wiki/GSoc2011
novabyte: Many of those projects could be "scaled up" to fill 4 months of work
moritz novabyte: gist.github.com/866304
novabyte moritz & whiteknight: thx I'll have a look
whiteknight doing something lorito-related would be nice too. You'll probably want to talk to cotto and dukeleto about that
novabyte whiteknight: I read about lorito a while ago (from proggit) seemed very interesting, thus the research into its progress :) 12:38
whiteknight novabyte: yeah, it is very interesting stuff. When do you have to have your project idea submitteD?
novabyte whiteknight: technically by the end of the week, but the dept are loose enough about it as long as I give info on what I've been researching 12:39
whiteknight novabyte: Okay. Definitely hang around in the channel, especially when cotto and dukeleto come online. They're on the west coast, so they usually meander in after a few hours 12:40
we'll definitely work with you to try and find a suitable project 12:41
novabyte whiteknight: sounds great, I can't be online too long now but I'll drop in again later
whiteknight okay, awesome
novabyte the other idea I've toyed with (very straightforward) is to write a Oberon-2 compiler using the LLVM. one of my lecturers in the dept writes a lot of Oberon-2 code and is really hopeful I'll work on it 12:43
whiteknight interested in writing an Oberon-2 compiler for Parrot? 12:44
novabyte whiteknight: lol hadn't even thought about it
I was planning on writing the compiler in D or Go. 12:45
whiteknight oh, we don't have either of those languages on Parrot (yet) 12:46
novabyte whiteknight: I thought Parrot was targeted at dynamic languages? 12:48
12:49 NotFound_b joined
lucian novabyte: not strictly 12:49
novabyte: a static-lang vm is usually a subset of a dynamic-lang vm, from an expresiveness p.o.v 12:50
atrodo novabyte> I've done some research into doing static languages on parrot. Seemed feasible, albeit with a couple adjustments 12:51
novabyte lucian: agreed, isn't it usually performance that's the defining factor in languages like D and Go? 12:52
lucian novabyte: well, are they really fast? i'd say go is rather slow 12:53
the benchmarks game agrees shootout.alioth.debian.org/u32/benc...p;lang=all
dalek tracwiki: v36 | whiteknight++ | GSoc2011
tracwiki: +some links to the embed API code and in-repo docs
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
tracwiki: v37 | whiteknight++ | GSoc2011
tracwiki: also, I can help mentor this.
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
novabyte lucian: benchmarks are usually good at showing benchmarks ;) real world code tends to work differently (arguably programmer skill is usually the most limiting factor) 12:55
lucian novabyte: sure, benchmarks only model number crunching usually 12:56
atrodo lucian> That graph is rather fascinating
lucian novabyte: but my point is, performance isn't very relevant
novabyte lucian: agreed 12:57
lucian novabyte: so if Java on Parrot is slow at first, so what? 12:58
same for oberon-2
or w/e
whiteknight what's most interesting from our perspective is gaining the ability to interface existing javascript code with libraries written in other languages which previously have not been compatible with the JVM
lucian s/javascript/java/ ?
whiteknight ah yes, java 12:59
lucian there is a ton of java code out there, yes
it's very tedious, though
novabyte lucian: aren't language bindings doing that? e.g. python->C bindings ...etc. 13:00
lucian novabyte: python-java bindings?
novabyte lucian: no idea
lucian novabyte: pylucene is horrible
it embeds the jvm in cpython 13:01
java-erlang bindings?
ruby-python bindings?
it's nowhere near close to actually working on parrot, but it's the only vm with any hope of getting there, afaik
novabyte lucian: ok, I see. 13:02
lucian novabyte: so you'd still have an ffi of sorts between parrot languages, but the common denominator would be much more expressive than C
novabyte lucian: yep 13:03
ok I have to go. thank you to everyone for all the help. I've got a lot to think about. :) 13:09
atrodo goodluck novabyte 13:10
novabyte atrodo: thx.
13:10 novabyte left 13:23 particle1 left
dalek tracwiki: v38 | whiteknight++ | GSoc2011 13:25
tracwiki: Add in a proposal about writing a bootstrapped JavaScript compiler for Parrot.
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
13:25 particle joined 13:26 mtk left 13:31 mtk joined 13:33 dmalcolm joined 13:35 NotFound_b left, NotFound_b joined
Coke NotFound: when you wrote winxed, what were your bootstrapping steps? 13:40
13:43 NotFound_b left 13:44 NotFound_b joined
whiteknight NotFound wrote the first compiler for Wixned in c++ 13:44
the stage1 compiler is written in winxed itself
NotFound_b Coke: write the stage 0 compiler in c++, start writing a parser in winxed, improve both until the winxed parser becomes a full compiler. 13:45
This is a post about the process written before it was completed: notfound.posterous.com/self-hosted-...hy-and-how 13:49
13:51 mj41_nb left
jnthn_ nqp-rx was bootstrapped by first using PGE, iirc. 13:51
Same pattern. Piggy-back on an existing compiler until yours is good enough to compile itself.
atrodo It's an aged old problem
whiteknight tale as old as time, song as old as rhyme, winxed and the beast 13:55
atrodo whiteknight++
dukeleto ~~ 13:56
Coke amusingly, that link is... notfound. 14:06
Coke digs for it on the full list.
14:07 Andy joined
NotFound_b Coke: it works for me cliking on it in konversation. 14:09
atrodo I could open it as well
14:15 dd070 joined
dukeleto dd070: welcome to this fine corner of the interwebs 14:16
dd070 :)
tx
m back after long time
dukeleto dd070: what brings you back?
cotto ~~ 14:17
14:18 particle left
dd070 suddenly parrot came in mind again. my hand clicked the link. 14:19
14:19 particle joined
dukeleto dd070: well, we must be doing something right. which link? 14:20
dd070 link to enter this channel. :) 14:21
I had got overview of parrot and perl6 some times back. 14:22
I read somewhere that Perl5 and Perl6 is to co-exists. 14:23
dukeleto dd070: we consider them "sister languges" these days 14:24
dd070: lots of features in perl 6 have trickled sideways to perl 5
dd070: Moose is basically the perl 6 object system in perl 5
14:24 mj41_nb joined
dd070 Yes. I am familiar with Moose (and Catalyst). little bit curious to know when so many people will started using Perl6 for new projects. 14:29
14:29 contingencyplan joined
lucian dd070: when it'll actually work, is my guess 14:31
dalek nxed: r857 | NotFound++ | trunk/winxedst1.winxed:
codingstd fixes
 14:34
dukeleto dd070: rakudo perl 6 works pretty well 14:37
dd070: speed is still a concern, but there are lots of smart people making both rakudo and parrot faster, as we speak
lucian dukeleto: dd070: what i meant was, when it actually works for practical things. no GUI binding, even 14:38
moritz dukeleto: and many non-smart people too :-)
dukeleto moritz: do you know the current status of GUI bindings for rakudo? 14:39
moritz dukeleto: I was replying to your "lots of smart people making both rakudo and parrot faster, as we speak" :-) 14:40
dukeleto moritz: yes, and I was asking you a new question :)
moritz: i would put myself in the (smart + non-smart)/2 camp 14:41
NotFound_b You can do a sort of gui binding by using a perl5 gui lib via blizkost.
dukeleto lucian: parrot has basic X, OpenGL and SDL binding, i thought, but they definitely need some love
moritz ah
sorry, can't read today
dukeleto: TK via blizkost was basically usable, last someone tried 14:42
there was also some binding for the toolkit that comes with e17 - Tene made that
not sure what the status is though
NotFound_b There is a also a library that embeds tcl/tk 14:43
14:44 dd070 left
lucian i see 14:44
ttk is ok, i guess 14:45
NotFound_b gtk2 via blizkost also works. I've half-done a winxed binding for it.
lucian isn't that embedding perl5? 14:46
NotFound_b lucian: yes
lucian shudders
whiteknight isn't that the whole point of Parrot, to be able to use libraries between multiple dynamic languages transparently? 14:47
NotFound_b Also, if we use a Parrot binding for something via X, using X is an implementation detail that may be changed later. 14:49
lucian whiteknight: yes, but embedding an existing C runtime seems .. weird
lucian prefers FFIs
NotFound_b: true 14:50
NotFound_b lucian: being able to use the full CPAN isn't weird at all to me.
lucian i guess i just hate perl5 too much 14:51
using perl5 libs, you'd still have to deal with the language, if nothing else in corner cases
NotFound_b lucian: I'm not a big fan of perl5, but I've done things like embedding perl in a C++ progran just to use the Telnet module.
lucian NotFound_b: then why not just use perl/other language nicer than C++ in the first place? 14:52
NotFound_b lucian: because C++ is nice to me.
14:54 lucian left, lucian joined
NotFound_b lucian: because C++ is nice to me. 14:54
lucian i think i have an old empathy 14:55
NotFound_b: i see. i guess
NotFound_b If not, probably winxed stage 0 had been written in perl, python, ruby... 14:56
cotto_work ~~
NotFound_b Or haven't been written at all. 14:57
15:01 rurban_ joined, dip joined 15:03 rurban left, rurban_ is now known as rurban, PacoLinux joined
lucian is off. bye! 15:07
15:07 lucian left
dalek sella/gh-pages: 354721a | Whiteknight++ | index.html:
github generated gh-pages branch
 15:09
dukeleto it must be Monday because my first cup of coffee had absolutely no effect on me 15:10
cotto_work As an added bonus, #ps is now at a different time. 15:14
dukeleto cotto_work: i put #ps on UTC on our google calendar, so I never have to remember that :)
cotto_work: i just set up some SMS/email reminders and google figures that junk out 15:15
15:15 dmalcolm left
dalek sella/gh-pages: 23a459f | Whiteknight++ | index.html:
quick html cleanup
 15:16
atrodo As an even added bonus, I won't miss it because I'll be there an hour early if I forget
it == #ps
15:16 janus left, janus` joined
cotto_work Happy Ļ€ day! 15:20
15:28 mikehh_ joined, dmalcolm joined 15:32 mikehh left 15:36 mikehh_ is now known as mikehh
mikehh opbots, names 15:37
Coke wonders what advantage using PCT gives him. 15:43
whiteknight great. #ps is moved again? I hate daylight savings time 15:47
it looks like I wont be attending #ps again for another 6 months
dukeleto whiteknight: that really sucks
whiteknight: #ps didn't move, just our collection perception of time
cotto_work whiteknight: blech
NotFound_b #ps time doesn't move at all, that's the whole point.
whiteknight it moves relative to the rest of my schedule 15:48
atrodo Perhaps it is not #ps that moves, but you that moves. Meditate on that
NotFound_b whiteknight: your schedule moves relative to Earth's time.
cotto_work What is the sound of one parrot clapping? 15:49
dukeleto whiteknight: is your $job inflexible about taking off for #ps ? 15:51
Coke Certainly around DST is a good time to ask folks if we need to reschedule PS. (Keeping in mind that we have to go through it again in a few weeks for the EU) 15:54
whiteknight dukeleto: #ps now happens during my commute 15:55
dukeleto whiteknight: ah. sadface. 15:56
whiteknight previously, when it was happening during work hours, I was able to attend
cotto_work whiteknight: when does your commute typically happen? 15:58
whiteknight 4:30-5:30 EST 16:02
Coke wonders if there is a timezone that means "eastern, with whatever DST rules are currently in effect." 16:16
(as opposed to EST vs. EDT) 16:17
atrodo Generally, I will just say "Eastern" and hope the other person understands that it implies the current DST rules
16:18 theory joined
Coke atrodo: same here. 16:18
16:19 Psyche^ joined, Patterner left, Psyche^ is now known as Patterner 16:22 plobsing left 16:27 bluescreen left
kthakore dukeleto: yes yes they do! 16:32
sorear Coke: TZ='America/New York' should do it 16:34
16:34 mj41_nb left
Coke sorear: I was referring to english: like whiteknight's send, where he added "EST". 16:41
16:42 dmalcolm left
Coke Where the natural thing might be to say "Eastern". 16:42
16:42 bluescreen joined 16:53 dmalcolm joined 16:58 plobsing joined 17:27 alin left 17:30 ShaneC joined 17:42 dmalcolm left 17:45 lucian joined 17:57 dd070 joined 18:15 dd070 left 18:16 plobsing left 18:28 plobsing joined, bluescreen left 18:29 lucian_ joined 18:33 lucian left
dalek sella/gh-pages: b8a5d7d | Whiteknight++ | index.html:
add links to the dependencies section
 18:33
sella/gh-pages: f68dac3 | Whiteknight++ | index.html:
fill out index.html with information about the various component libraries
 18:34
nxed: r858 | NotFound++ | trunk/winxedst1.winxed:
fix null non-var arguments to predefs
 18:35
18:41 sigue left, sigue joined 18:45 mj41_nb joined 18:47 bluescreen joined 19:07 zby_home joined 19:08 GodFather joined 19:11 GodFather left 19:12 GodFather joined 19:13 cogno joined 19:15 lucian joined 19:16 lucian_ left
dalek nxed: r859 | NotFound++ | trunk/winxedst (2 files):
generate die opcode for throw with string argument, diagnose error when is not
 19:19
nxed: r860 | NotFound++ | trunk/pir/winxed_compiler.pir:
update installable compiler
19:28 GodFather left 19:33 alin joined 19:39 hercynium joined 19:45 lucian_ joined 19:48 lucian left, plobsing left 19:49 cogno left 19:52 cogno joined 19:56 twinshadow joined, twinshadow left
cotto_work seen novabyte 20:07
aloha novabyte was last seen in #parrot 6 hours 57 mins ago leaving the channel.
20:16 plobsing joined
cotto_work hi plobsing 20:21
plobsing cotto_work: hi 20:25
20:30 whiteknight left 20:34 dodathome joined 20:36 perlite_ joined 20:40 perlite left, perlite_ is now known as perlite 20:56 ambs left
bacek_at_work ~~ 21:20
21:25 kid51 joined
cotto_work hio bacek_at_work 21:31
bacek_at_work aloha, cotto_work
21:38 cogno left 21:39 bluescreen left
cotto_work bacek_at_work: when you suggested "gen_call $P0, [INT32, INT32, $I0, INT32, $I1]" for ffi, what did [...] represent? 21:41
21:42 lucian joined
bacek_at_work cotto_work, [ret_val_type, arg0_type, arg0, arg1_type, arg1] 21:43
21:46 lucian_ left 21:48 dodathome left
cotto_work bacek_at_work: right, but what does the [...] construct translate to in terms of M0 registers? 21:52
bacek_at_work cotto_work, no idea. "Key PMC"? 21:53
"thunk"?
"something to hold all this stuff"
cotto_work it sounds like the kind of thing that M1+ would be good for 21:54
bacek_at_work cotto_work, nope. Consider your example with multiple "set_arg". You need some intermediate storage for it. 21:55
Same storage is used here. Slightly more explicitly
cotto_work bacek_at_work: sure
plobsing I interpret it as an array of ints constant. If you claim M0 doesn't have such things, they can be emulated by having the next op be a 'goto +10' and then using an in-line buffer.
cotto_work plobsing: that sounds reasonable 21:56
21:58 alin left 22:00 alin joined 22:08 novabyte joined, theory left 22:10 mtk left 22:15 whiteknight joined 22:17 mtk joined 22:19 zby_home left
kid51 ~~ 22:21
whiteknight ++
tadzik %% 22:24
dalek sella/gh-pages: ec14085 | Whiteknight++ | i (2 files):
Add in the new logo image. Some cosmetic fixes to the page
 22:25
sella/gh-pages: 869882f | Whiteknight++ | index.html:
small cosmetic fixes
 22:28
sella: 4729323 | Whiteknight++ | LICENSE:
+LICENSE file
22:31 theory joined 22:33 mj41_nb left 22:35 hercynium left 22:37 lucian left 22:38 alin left 23:01 rurban_ joined 23:03 rurban left, rurban_ is now known as rurban 23:10 theory left 23:17 bacek_at_work left
cotto_work @@ 23:22
23:41 aloha left 23:45 arnsholt left
cotto_work decommutes 23:48
23:49 novabyte left 23:55 theory joined
dalek p/ctmo-no-p6regex.pir: aa87ead | jonathan++ | src/Regex/P6Regex/Grammar.pm:
Need to still use the HLL library; was missed when removing the P6Regex PIR file.
 23:58
p/ctmo-no-p6regex.pir: 1eb4e1b | jonathan++ | build/Makefile.in:
Another round of Makefile changes to work towards getting things working again after removing P6Regex.pir.
p/ctmo-no-p6regex.pir: 9ace6d6 | jonathan++ | src/Regex/P6Regex/ (2 files):
Need to use block form of packages when there's multiple in a file.
p/ctmo-no-p6regex.pir: d014f94 | jonathan++ | src/Regex/P6Regex/Compiler.pm:
Work around a MAIN bug.
p/ctmo-no-p6regex.pir: 4460cea | jonathan++ | src/Regex/P6Regex/Compiler.pm:
Move regex compiler init to the right place; now all tests pass that pass in the ctmo branch.
23:58 bacek_at_work joined
dalek p/ctmo-no-p6regex.pir: 9cdb417 | jonathan++ | src/NQP/Actions.pm:
Fix MAIN bug.
 23:58
p/ctmo-no-p6regex.pir: e3036b0 | jonathan++ | src/stage0/ (6 files):
Update bootstrap with MAIN fix and P6Regex.pir gone.
p/ctmo-no-p6regex.pir: 749d34c | jonathan++ | src/Regex/P6Regex/Compiler.pm:
Toss workaround for MAIN bug.
23:59 aloha joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!