Camelia, the Perl 6 bug

IRC log for #parrot, 2011-03-23

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 soh_cah_toa does the parrot compiler use any debugging data formats? like dwarf or stabs?
00:04 bacek_at_work soh_cah_toa, not yet. I looks like a really good idea to implement such thing
00:04 plobsing left #parrot
00:04 plobsing joined #parrot
00:05 soh_cah_toa okay. i think that would makes things a little easier as i tackle this debugger
00:08 p6eval left #parrot
00:09 dalek left #parrot
00:11 dalek joined #parrot
00:12 p6eval joined #parrot
00:14 soh_cah_toa debugging information is normally stored in the .debug_info section in object files. however, all code is compiled into pbc; not object code. so the debugging info would have to be stored in the generated pbc, right?
00:14 whiteknight right
00:15 whiteknight .pbc has various segments. One type of segment stores debugging info
00:15 whiteknight there are segments for code, constant values, annotations, debug info, etc
00:15 soh_cah_toa oh, it already has a section for debuggin info?
00:16 whiteknight src/debug.c contains most debug-related code. It'sa big file, but will be worthwhile to skim it
00:16 bacek_at_work soh_cah_toa, yes. You can use pbc_dump to look at it
00:17 soh_cah_toa i'm guessing it's not a standardized format
00:17 plobsing left #parrot
00:19 whiteknight no
00:19 whiteknight could be
00:19 whiteknight but isn't
00:20 dalek left #parrot
00:20 soh_cah_toa would that be a good idea as part of the gsoc debugger project? to implement dwarf-2 in pbc
00:21 dalek joined #parrot
00:21 whiteknight it's a good idea in theory. We need to keep scope in mind
00:22 whiteknight GSoC is only 3 months long
00:22 soh_cah_toa oh, that would take a while to do?
00:22 bubaflub soh_cah_toa: write your proposal with some flexibility
00:22 bubaflub soh_cah_toa: so if you have extra time, you have stuff on the timeline
00:23 bubaflub soh_cah_toa: but you have some bare minimum deliverables
00:23 bubaflub soh_cah_toa: also, at the mid-point you can reassess what you'll be able to do
00:23 whiteknight soh_cah_toa: I don't know how long it would take. PBC is one of the darker, dirtier parts of Parrot
00:23 whiteknight we've been slowly working to improve it
00:24 soh_cah_toa okay
00:24 cotto_work pbc itself isn't that bad
00:24 cotto_work how we work with it is lta though
00:25 soh_cah_toa i see
00:30 whiteknight We do plan on doing work on the bytecode stuff in the future. Ideally, the debugger won't get too involved in bytecode so that we can make changes without breaking the debugger
00:30 whiteknight there's never going to be perfect isolation, it's just something to keep in mind
00:32 soh_cah_toa hmmm...okay. how would i be able to read debug information at the pir level though?
00:34 bacek_at_work soh_cah_toa, look at t/pmc/packfile*t
00:34 bacek_at_work it's tests for Packfile* PMCs for PBC reading/writing
00:37 bubaflub_ joined #parrot
00:37 bubaflub left #parrot
00:37 bubaflub_ is now known as bubaflub
00:37 soh_cah_toa okay
00:39 soh_cah_toa i would like to learn more about the packfile but pdd13 is missing
00:40 bacek_at_work docs/pdds/draft/
00:40 soh_cah_toa there it is. thanks
00:44 plobsing joined #parrot
00:47 kid51 is now known as kid51_at_dinner
00:50 cotto_work soh_cah_toa: that pdd isn't too far from the truth atm.  pbc_dump -d should help you get a handle on what actual pbc files look like
00:50 woosley joined #parrot
00:53 cotto_work actually, it is somewhat far from the truth
00:53 cotto_work it's good for getting the basic idea, but trust the output of pbc_dump more
00:53 soh_cah_toa i'm trying to run a simple hello world pir file through pbc_dump -d but i don't get any output
00:54 bacek_at_work soh_cah_toa, parrot -o hello.pbc hello.pir; pbc_dump hello.pbc
00:54 cotto_work ^ what he said
00:54 bacek_at_work .pir files aren't pbcs :)
00:55 soh_cah_toa i figured it would compile down to pbc. now it's working
00:59 cotto_work pbc_dump isn't that magical
01:02 soh_cah_toa it's alright. i think i can use some of its code in the debugger
01:20 soh_cah_toa left #parrot
01:59 kid51_at_dinner is now known as kid51
02:02 whiteknight left #parrot
02:07 lucian left #parrot
02:20 bubaflub left #parrot
02:24 bubaflub joined #parrot
02:31 marcel_r joined #parrot
02:38 dalek parrot/opsc_llvm: 50f9d43 | jkeenan++ | / (2 files):
02:38 dalek parrot/opsc_llvm: Overhaul auto::llvm to require minimum version of LLVM.  Modify steps test file accordingly.
02:38 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/50f9d43e58
02:40 kid51 msg bacek_at_work In opsc_llvm branch: make realclean; git pull origin opsc_llvm; perl Configure.pl --test=build --verbose-step=auto::llvm
02:40 aloha OK. I'll deliver the message.
02:46 bacek_at_work kid51, thanks!
02:47 bacek_at_work kid51, erm... On debian llc is called llc-2.7...
02:48 bacek_at_work ~/src/parrot (opsc_llvm) $ perl tools/dev/reconfigure.pl --step=auto::llvm --verbose
02:48 bacek_at_work auto::llvm -          Is minimum version of LLVM installed...Found 'llvm-gcc' version 4.2.1
02:48 bacek_at_work Is minimum version of LLVM installed.................no.
02:49 kid51 Can you try a make realclean and then reconfigure as above
02:50 marcel_r_ joined #parrot
02:54 dalek parrot/opsc_lasm: b82f01f | (Jon Gentle)++ | co (5 files):
02:54 dalek parrot/opsc_lasm: Begin a (very very hacky) opsc that outputs lasm for my lorito prototype
02:54 dalek parrot/opsc_lasm: review: https://github.com/parrot/parrot/commit/b82f01fc2d
02:54 dalek parrot/opsc_lasm: 7616c50 | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
02:54 dalek parrot/opsc_lasm: Start outputting some basic, non-quite-functional statements
02:54 dalek parrot/opsc_lasm: review: https://github.com/parrot/parrot/commit/7616c50284
02:54 marcel_r_ left #parrot
02:56 marcel_r left #parrot
02:56 alin left #parrot
02:58 kid51 bacek_at_work:  I have to sleep.  If you can't get the config step to work and it blocks you, revert to the next older version and send me email about problem.  (But I doubt very much that Debian would name an executable 'llc-2.7' without symlinking 'llc' to it.)
02:59 kid51 left #parrot
03:12 bacek_at_work atrodo, ping
03:12 atrodo bacek_at_work> pong
03:12 bacek_at_work atrodo, can branch from opsc_llvm for lorito playground?
03:12 bacek_at_work ooops
03:12 bacek_at_work sorry
03:13 bacek_at_work I misread branch name.
03:13 bacek_at_work My bad...
03:13 atrodo yea, the name is very similar
03:14 bacek_at_work anyway, you can look into Ops::Op for ideas about how to produce output based on multidispatch
03:15 atrodo Yea, I looked at it.  Sadly my nqp-fu is poor, so I'm learning as I'm hacking at it
03:15 bacek_at_work atrodo, nqp multidispatch == pir multidispatch.
03:18 atrodo It's not so much the multidispatch but the whole flow of operation that I'm still working on getting a solidgrasp on
03:20 bacek_at_work atrodo, I'm working on same thing in jit_prototype branch :)
03:21 atrodo bacek_at_work> I'm going to be following that branch to see how I should have done it
03:21 bacek_at_work atrodo, deal. I probably will have some basic skeleton in next few days.
03:28 dalek TT #2049 created by pmhppumwnbx8++: Read about Removing System Tool Virus
03:28 dalek TT #2049: http://trac.parrot.org/parrot/ticket/2049
03:29 sorear bacek_at_work: nqp-rx multidispatch == pir multidispatch
03:29 bacek_at_work sorear, ok-ok :)
03:34 dukeleto tracspam--
03:34 sorear why aren't first posts on trac queued for moderation?
03:35 sorear it works beautifully for the mailing lists
03:39 plobsing sorear: are you one of the brave souls moderating the mailing lists?
03:40 sorear plobsing: no, I'm an outsider who notices that the lists are run way better than trac
03:41 sorear legitimate first posts on trac are rare, and the spam load on trac is far lower than the spam load on public email
03:43 plobsing why does trac even get spam? don't we nofollow all external links? what's the angle?
03:52 atrodo the few external links I checked on the front trac page didn't have nofollow on them
04:06 cotto ~~
04:07 cotto some spam doesn't even have links
04:08 bubaflub left #parrot
04:14 cotto How did that tracspam not hit parrot-tickets?
04:14 cotto I'm not disappointed, just curious.
04:15 dalek TT #2051 created by cvxzhkluqh8++: The Start off of Memory Foam
04:15 dalek TT #2051: http://trac.parrot.org/parrot/ticket/2051
04:16 cotto baleeted
04:16 cotto I don't like where this is going
05:04 Drossel joined #parrot
05:04 Kulag left #parrot
05:05 dalek parrot/m0-spec: afbd98c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
05:05 dalek parrot/m0-spec: tighten the description of M0's various tables
05:05 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/afbd98c1fb
05:05 dalek parrot/m0-spec: a6283e4 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
05:05 dalek parrot/m0-spec: remove an unneeded op, add a couple more
05:05 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/a6283e4e37
05:05 dalek parrot/m0-spec: 236f884 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
05:05 dalek parrot/m0-spec: add a couple missing ops to the ffi interface
05:05 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/236f88484e
05:05 dalek parrot/m0-spec: 56c644b | cotto++ | docs/pdds/draft/pdd32_m0.pod:
05:05 dalek parrot/m0-spec: reorganize op list, add ffi and total count
05:05 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/56c644b89c
05:07 cotto that puts M0 at 25 ops, 21 if the temporary ones aren't counted
05:08 dukeleto very interesting
05:09 Kulag joined #parrot
05:09 theory joined #parrot
05:10 cotto With everything in there for ffi, I'm surprised the count was so low
05:10 Drossel left #parrot
05:10 sorear "INSP registers (fixed number of each)"
05:10 sorear How fixed?
05:10 sorear Are we going back to 32 of each?
05:12 cotto I don't know.  32 sounds low.
05:12 sorear otoh 64 of each is rather wasteful
05:13 cotto If op arguments are 1 byte, that means we're stuck with no more than 256 slots in the variables table
05:13 cotto actually, that's not true
05:13 plobsing cotto: you don't need dlopen. you can "dlsym $P0, null, '<funcname>'" to get a handle on any symbol in Parrot. including Parrot_dlopen, which can be used to build-out a full-featured FFI in M1.
05:14 cotto plobsing, good idea
05:15 theory left #parrot
05:15 sorear cotto: replacement-PIR-compiler may need to have spill logic
05:15 plobsing we had spill logic in the past
05:15 sorear I just doubt that fixed size contexts make that much sense
05:16 sorear "SPARC"
05:17 cotto sorear, that can be done by memset/memget
05:18 cotto which should probably have different names to avoid confusion with C's memset
05:18 sorear cotto: have you ever tried 6502 programming?
05:19 cotto sorear, can't say I have
05:19 sorear memory allocation is going through ffi?
05:19 sorear not going to be done using M0 ops?
05:20 sorear is the GC going to be in M0?
05:20 cotto sorear, the gc will be on top of M0
05:20 plobsing sorear: the 2 most common cases (compile to C, JIT), the common pattern for ffi isn't really that bad
05:21 plobsing dlsym -> ccall
05:21 plobsing any self-respecting C compiler or JIT will make that damn-near optimal
05:21 sorear plobsing: does dlsym use an S register?  does it JIT to a dlsym() call?
05:22 plobsing we should really not call it dlsym. csym seems better.
05:22 plobsing sorear: the compiler can know (or should be able to know) when it is called with a constant
05:22 cotto plobsing, wfm
05:23 plobsing cotto: I'm not just proposing a naming difference. csym shouldn't accept a library handle and be limited to the Parrot core symbols.
05:24 plobsing limit the scope
05:24 cotto plobsing, so the dl* stuff would go through csym?
05:24 cotto dlopen and dlsym
05:24 plobsing cotto: dl* should mostly be implemented in M1 with the full FFI
05:25 plobsing M0 needs just enough to run itself and M1
05:25 cotto agreed
05:25 cotto are you saying csym on its own is enough, or csym plus the other function handle bits?
05:26 plobsing I don't really understand the function handle bits or the need in general to have specialized function handles in M0
05:27 cotto the idea is to provide an interface that makes sense for whatever kind of interpreter M0 bytecode might run on top of
05:28 plobsing but why should you need to explicitly allocate the space for the arguments? anything not matching set_arg*; csym?; ccall; get_ret; is invalid and the compiler should just choke.
05:29 plobsing which means these aren't things you can pass around, and therefore we should not be exposing handles to them
05:29 sorear What is the point of ctx_arg on line 290?
05:30 cotto sorear, that's the current context, which is the first argument to any op
05:31 cotto plobsing, I see what you're saying now.
05:31 sorear cotto: that doesn't make a whole lot of sense to me
05:32 sorear cotto: saying "oh, mr. op, the current context is in register 4" doesn't make sense, since register 4 cannot be located without... the current context
05:32 cotto plobsing, my thinking is that the implementation of ccall will be smart enough to put args where the function handle says they should go.
05:33 sorear depending on the CPU and how much we expect M1+ code to allocate, it might make sense to have allocation be more direct than a ccall
05:34 plobsing cotto: but as soon as you expose a handle the call-stack, you create the opportunity to do dynamic things like writting functions that populate other functions arguments, which is not implementable without throwing a whole bunch of magic into ccall.
05:34 sorear GHC in particular keeps HeapPtr and HeapLimit as registers and does allocation with inline code
05:37 cotto plobsing, I don't quite understand what you're saying, your suggestion is sounds simpler than function handles.
05:38 cotto sorear, possibly yes, but for now the goal is to get something running
05:38 cotto I'm not saying that anything's near final.
05:38 sorear cotto: if "portable M0 code" is going to rely on ccalls, it would probably be a good idea to spec them
05:40 sorear on some level I wonder what the point of "few ops" is, if any M0 implementation has to have 50+ ccalls
05:41 plobsing cotto: I'm saying what you've called function handles, sounds to me like stack handles, and that adds the possibility for complex behaviour, which necessitates an M0-implementation that (a) contains too much complexity (b) bails on certain inputs, possibly only at runtime, to avoid said complexity. Neither of these options appeal to me.
05:42 plobsing my approach is to define a system where it is not possible to specify this complex behaviour
05:43 cotto let me pseudocode an example to make sure I understand what you're saying
05:45 plobsing it is a similar concept to PG's Blub language
05:46 sorear cotto: why is shl an op, but memory allocation isn't?
05:46 sorear cotto: what if *all* non-control-flow non-ffi operators became ccalls?
05:47 plobsing sorear: that is the extreme case
05:47 plobsing and that still permits efficient implementation (albeit, such an implementation is not the most obvious)
05:48 cotto http://nopaste.snit.ch/38471
05:49 cotto plobsing, something like that?
05:49 cotto sorear, the bitwise ops need work
05:49 plobsing cotto: that looks close. what are the 0's on csym for?
05:50 cotto null, though I guess that's not necessary
05:50 sorear plobsing: what I'm saying is that I don't think pdd32 is the right place to decide what operations should be inlined on $cpu
05:51 cotto I was in a dlsym frame of mind
05:51 plobsing also, cstring as a distinct type for FFI isn't necessarily a good idea
05:51 cotto "hand-waving"
05:52 plobsing I've deprecated it from the current NCI and have a branch which has the goal of eliminating it.
05:52 cotto ffi_type_pointer would be closer to the truth
05:52 plobsing sorear: the interpreter is free to inline ccall functions if it so chooses.
05:53 cotto Yes.  The interpreter can be arbitrarily smart.  We just can't assume that it is.
05:53 sorear plobsing: the interpreter is also free to use support routines for mult_n on systems without FPU.  So the distinction is 1. not semantically relevant 2. pdd complexity bloat
05:54 plobsing I see your point. The distinction between ops and ccalls is artificial.
05:55 plobsing but then where does that leave us?
05:58 cotto That does make an interesting question.
05:59 sorear niecza went down the route of eschewing a FFI in favor of hundreds of wrapper ops.
05:59 sorear I recommend you don't do this.
06:00 cotto I don't think our mistakes will be from having too many ops (again).
06:01 wagle left #parrot
06:01 wagle joined #parrot
06:02 cotto though if I knew what they were going to be, I wouldn't make them
06:06 giwi joined #parrot
06:15 Kulag left #parrot
06:17 Kulag joined #parrot
06:18 cotto bikeshed question: what'd be a better name for int2num and num2int?  The "2" reminds me of php.
06:18 alin joined #parrot
06:19 cosimo left #parrot
06:21 sorear cotto: I beleive FIX and FLOAT were the names used in TAOCPv2
06:22 plobsing you could go the C route and have an explicit "to" which is longer than either of the types (eg: hton)
06:22 plobsing itof and ftoi I guess
06:23 cotto that's what I'm leaning toward
06:23 cotto or iton/ntoi if the registers are called Nx
06:27 Kulag left #parrot
06:28 Kulag joined #parrot
06:31 ShaneC left #parrot
06:40 * cotto sleeps.  plobsing, thanks for the simplifications.
06:46 ShaneC joined #parrot
07:00 woosley1 joined #parrot
07:03 woosley left #parrot
07:05 fperrad joined #parrot
07:06 rurban_ joined #parrot
07:09 rurban left #parrot
07:09 rurban_ is now known as rurban
07:28 alin left #parrot
07:38 particle left #parrot
07:40 woosley1 left #parrot
08:00 woosley joined #parrot
08:06 jsut joined #parrot
08:11 jsut_ left #parrot
08:15 woosley1 joined #parrot
08:18 woosley left #parrot
08:32 Kulag left #parrot
08:35 alin joined #parrot
08:35 Kulag joined #parrot
08:39 Drossel joined #parrot
08:39 Kulag left #parrot
08:54 nopaste left #parrot
08:57 nopaste joined #parrot
09:18 woosley1 left #parrot
09:32 Eduardow left #parrot
09:38 mikehh left #parrot
09:56 bacek ~~
10:00 kid51 joined #parrot
10:21 bacek left #parrot
10:30 dalek parrot/jit_prototype: 67151ce | bacek++ | runtime/parrot/library/LLVM/Type.pm:
10:30 dalek parrot/jit_prototype: Create complex parrot's types once only.
10:30 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/67151ce904
10:30 dalek parrot/jit_prototype: ae04e65 | bacek++ | runtime/parrot/library/LLVM/Type.pm:
10:31 dalek parrot/jit_prototype: Add * variants of parrot types.
10:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/ae04e65f3a
10:31 dalek parrot/jit_prototype: 1738a31 | bacek++ | runtime/parrot/library/LLVM/Function.pm:
10:31 dalek parrot/jit_prototype: Add Function.return_type.
10:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/1738a3173c
10:31 dalek parrot/jit_prototype: d96afc5 | bacek++ | / (2 files):
10:31 dalek parrot/jit_prototype: Add Module type introspection.
10:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/d96afc573d
10:31 dalek parrot/jit_prototype: 4430c2e | bacek++ | / (2 files):
10:31 dalek parrot/jit_prototype: Add Module.find_function
10:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/4430c2e56b
10:31 dalek parrot/jit_prototype: 9a0e222 | jkeenan++ | / (5 files):
10:31 dalek parrot/jit_prototype: Add generated files to .gitignore and MANIFEST.generated.  Re-run mk_manifest_and_skip.pl.  Add files as needed to FLUID_FILES_2 target in config/gen/makefiles/root.in.
10:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/9a0e222cf4
10:31 dalek parrot/jit_prototype: 50f9d43 | jkeenan++ | / (2 files):
10:31 dalek parrot/jit_prototype: Overhaul auto::llvm to require minimum version of LLVM.  Modify steps test file accordingly.
10:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/50f9d43e58
10:31 dalek parrot/jit_prototype: d4a977f | bacek++ | / (9 files):
10:31 dalek parrot/jit_prototype: Merge branch 'opsc_llvm' into jit_prototype
10:31 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/d4a977faff
10:33 bacek joined #parrot
10:38 ascent left #parrot
10:38 ascent joined #parrot
10:44 kid51 jit_prototype branch: http://smolder.parrot.org/app/​projects/report_details/12931 (linux/i386, no llvm) failures in several files
10:53 bacek kid51, thanks. But branch is far-far away from any testable state.
11:15 moritz is there a list of what the parrot_config conf keys mean?
11:15 moritz if yes, where?
11:39 kid51 moritz:  Do you mean %Parrot::Config::Generated::PConfig?  If so, then the answer is: No.
12:11 nopaste "bacek" at 192.168.1.3 pasted "Most cynical thing I ever done with parrot." (99 lines) at http://nopaste.snit.ch/38473
12:14 nopaste "bacek" at 192.168.1.3 pasted "Most cynical thing I ever done with parrot. (updated version)" (136 lines) at http://nopaste.snit.ch/38474
12:14 bacek ~~
12:14 bacek I _can_ implement runcore in PIR :)
12:16 * bacek is leaving laughing devilishly
12:16 bacek I can implement JIT in NQP. And run it through it self :)
12:23 kid51 left #parrot
12:25 lucian joined #parrot
12:27 mtk joined #parrot
12:30 moritz that's what pypy attempted (or even does), no?
12:33 whiteknight joined #parrot
12:34 whiteknight left #parrot
12:37 lucian moritz: i missed some log. what did pypy attempt?
12:37 moritz 13:16 <@bacek> I can implement JIT in NQP. And run it through it self :)
12:37 moritz lucian: there's also a link to public logs in the topic here
12:38 lucian moritz: ah. sorry
12:38 lucian no, that's not what pypy does
12:38 lucian but it should be doable on parrot
12:38 moritz it didn't jit itself?
12:39 lucian moritz: pypy has two parts: a python interpreter written in pure python
12:39 lucian and a translator framework that takes RPython running programs and translates to lower level code
12:39 lucian so what they do is translate the python interpreter to C
12:39 lucian the JIT and GC are injected by the framework during translation
12:40 whiteknight joined #parrot
12:40 lucian moritz: so in the final VM pypy generates, the JIT is native code
12:40 whiteknight good morning, #parrot
12:40 moritz lucian: thanks for the explanation
12:41 lucian yw, hope it helps. it's a rather confusing project, but quite impressive
12:42 bacek aloha, whiteknight
12:42 lucian gm
12:42 bacek You'll love http://nopaste.snit.ch/38474 :)
12:49 whiteknight bacek: what is that?
12:52 bacek skeleton to implement runloop in PIR :)
12:52 whiteknight oh, nice
12:52 bacek Little bit cynical :)
12:56 mtk left #parrot
12:58 ascent left #parrot
12:58 ascent joined #parrot
13:03 whiteknight not cynical, this is very awesome
13:03 mtk joined #parrot
13:06 bluescreen joined #parrot
13:07 samwho joined #parrot
13:07 estrabd left #parrot
13:07 samwho left #parrot
13:08 estrabd joined #parrot
13:14 particle joined #parrot
13:17 bluescreen left #parrot
13:17 bluescreen joined #parrot
13:18 plobsing left #parrot
13:30 davidfetter joined #parrot
13:31 Eduardow2 joined #parrot
13:32 giwi left #parrot
13:40 Payne joined #parrot
13:49 giwi joined #parrot
13:57 plobsing joined #parrot
13:58 Payne left #parrot
14:02 giwi left #parrot
14:09 dalek TT #2052 created by azqrzdpsydcbig5++: The Fundamental Cause of Challenge Coins
14:09 dalek TT #2052: http://trac.parrot.org/parrot/ticket/2052
14:16 moritz trac spam
14:20 * Coke wonders wtf these people think that's going to do. anyone who would see that spam is now going to, at best, ignore it, and at worst, get a hate-on for that thing that is  being advertized.
14:20 Coke Go make the world a better place, you idiots.
14:21 moritz Coke: the answer is simple. Free links, SEO
14:22 moritz google isn't smart enough to recognize non-tech product links on a tech site as spam
14:22 moritz and all in all it still seems to pay off for them, otherwise they wouldn't do it
14:23 whiteknight the question is whether is pays off as much as a different strategy would
14:23 whiteknight I have to believe there are better ways to spread the message
14:26 bluescreen left #parrot
14:30 Andy_ joined #parrot
14:36 davidfetter left #parrot
14:42 mikehh joined #parrot
14:46 dalek nqp/ctmo: 81203dc | jonathan++ | src/Regex.pir:
14:46 dalek nqp/ctmo: Fix --target=pa[rse|st] - got broken at some point in this branch.
14:46 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/81203dc952
14:46 Andy__ joined #parrot
14:46 Andy_ left #parrot
14:50 Andy_ joined #parrot
14:50 Andy__ left #parrot
14:53 giwi joined #parrot
15:07 rurban_ joined #parrot
15:09 rurban left #parrot
15:09 rurban_ is now known as rurban
15:12 davidfetter joined #parrot
15:14 lucian left #parrot
15:17 Patterner left #parrot
15:18 Psyche^ joined #parrot
15:18 Psyche^ is now known as Patterner
15:28 dalek TT #2053 created by iofglptbqrud6++: Level of popularity Of Blue Buffalo Dog Food As well as Blue Buffalo ...
15:28 dalek TT #2053: http://trac.parrot.org/parrot/ticket/2053
15:29 moritz more trac spam :(
15:29 hudnix left #parrot
15:30 hudnix joined #parrot
15:31 davidfetter left #parrot
15:34 lucian joined #parrot
15:36 hudnix left #parrot
15:37 hudnix joined #parrot
15:37 alin left #parrot
15:42 theory joined #parrot
15:52 PacoLinux left #parrot
15:56 whiteknight FFFUUUUUU
15:58 dalek parrot/m0-spec: ab8c0d0 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
15:58 dalek parrot/m0-spec: simplify ffi, rename a couple ops, make most of the ffi section incorrect
15:58 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/ab8c0d057b
16:10 hercynium joined #parrot
16:10 cotto left #parrot
16:21 theory left #parrot
16:25 cotto_work ~~
16:31 bluescreen joined #parrot
16:45 bluescreen left #parrot
16:54 giwi left #parrot
17:00 bluescreen joined #parrot
17:14 Drossel left #parrot
17:14 Kulag joined #parrot
17:25 plobsing left #parrot
17:29 ShaneC left #parrot
17:33 plobsing joined #parrot
17:56 dmalcolm joined #parrot
18:06 ShaneC joined #parrot
18:11 [hercynium] joined #parrot
18:13 [hercynium]_ joined #parrot
18:16 hercynium left #parrot
18:17 [hercynium] left #parrot
18:17 [hercynium]_ is now known as hercynium
18:18 Coke So, one of our track spams was for a coin-based website.
18:18 Coke s/track/trac/
18:18 Coke if you whois that site, you get a home address and a gmail address. I wonder if that sort of thing is reportable somewhere.
18:27 alin joined #parrot
18:27 hercynium coin-based... makes me imagine people trying to insert a quarter into their cd-rom drives
18:31 alin left #parrot
18:45 alin joined #parrot
18:45 davidfetter joined #parrot
18:51 alin left #parrot
18:56 alin joined #parrot
18:58 davidfetter left #parrot
18:59 alin left #parrot
19:07 dalek parrot/m0-spec: 7751fa0 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
19:07 dalek parrot/m0-spec: update ffi section to match plobsing++'s suggestion
19:07 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/7751fa0fab
19:32 atrodo cotto_work> busy on m0-spec today?
19:48 bluescreen left #parrot
19:56 marcel_r joined #parrot
19:56 samwho joined #parrot
19:56 plobsing left #parrot
19:56 samwho left #parrot
19:56 ambs joined #parrot
20:04 samwho joined #parrot
20:32 Eduardow2 is now known as Eduardow
20:35 whiteknight_ joined #parrot
20:39 whiteknight left #parrot
20:39 whiteknight_ is now known as whiteknight
20:48 dalek winxed: r872 | NotFound++ | trunk/winxedst0.cpp:
20:48 dalek winxed: indent code generated in stage 0, unfinished
20:48 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=872
20:48 samwho left #parrot
20:50 bluescreen joined #parrot
20:54 bluescreen left #parrot
20:56 mj41 joined #parrot
20:58 dalek TT #2054 created by pwdiiobamvxlg0++: Chemical Suppliers - UK - Leading Suppliers of Substances employed as ...
20:58 dalek TT #2054: http://trac.parrot.org/parrot/ticket/2054
21:00 plobsing joined #parrot
21:02 cotto_work unspammed
21:07 particle1 joined #parrot
21:11 particle left #parrot
21:25 marcel_r left #parrot
21:32 fperrad left #parrot
21:41 soh_cah_toa joined #parrot
21:49 Andy_ left #parrot
22:14 lucian_ joined #parrot
22:15 sigue left #parrot
22:17 lucian left #parrot
22:21 kid51 joined #parrot
22:21 mtk left #parrot
22:23 mj41 left #parrot
22:28 mtk joined #parrot
22:31 Hackbinary left #parrot
22:34 ambs left #parrot
22:36 wknight8111 joined #parrot
22:37 bacek_at_work ~~
22:39 kid51 bacek_at_work: I noticed you merged opsc_llvm into another branch; are you going to continue to develop in opsc_llvm?
22:39 bacek_at_work kid51, yes. jit_prototype branch is "independent" piece of work
22:39 kid51 k
22:40 bacek_at_work I want opsc_llvm "finished" and merged back to master. Probably after 3.3
22:41 bacek_at_work kid51, (llvm in debian) Looks like they start putting versioned binaries since 2.7. Without providing "alternatives".
22:41 kid51 Were you able to overcome the obstacles you mentioned re my revision of config/auto/llvm.pm?
22:41 kid51 I'll take that as a No.
22:41 kid51 That is so weird.  After all, we don't say:
22:42 jsut_ joined #parrot
22:42 kid51 perl-5.12.0 -E 'say "hello world";'
22:42 bacek_at_work yes, I know.
22:42 bacek_at_work Very undebian way.
22:43 bacek_at_work I think we can have workaround for it.
22:43 bacek_at_work llvm-config-2.7 --bindir returns "/usr/lib/llvm-2.7/bin/"
22:44 bacek_at_work which contains non-versioned binaries
22:44 bacek_at_work if we put --with-llvm-config=/path/to/llvm-config into Configure.pl
22:45 bacek_at_work we can use bindir to find out llvm version
22:45 kid51 But we should not tie ourselves down to the debian way of doing things (wrong).
22:45 kid51 After all, people could compile llvm from source, no?
22:45 bacek_at_work (And it actually better. Because I have 3 versions of LLVM installed and I have no easy way to specify which version to use)
22:46 kid51 I'll have to ponder this more.
22:46 jsut left #parrot
22:47 bacek_at_work With compiling llvm from source way to specify llvm-config in COnfigure.pl will be even more convenient.
22:47 nopaste "bacek" at 192.168.1.3 pasted "llvm-config --bindir usage for kid51++" (6 lines) at http://nopaste.snit.ch/38479
22:49 kid51 okay, I'll get to that later.  Have to submit a talk proposal for YAPC tonight.
22:49 bacek_at_work kid51, ok.
22:49 bacek_at_work thanks for your help
22:50 bacek_at_work jfyi, llvm-config --cflags produced "-O2 -DNDEBUG". Which is bad. It will switch parrot to "optimized' build if we will use it as is.
23:06 rurban_ joined #parrot
23:07 sigue joined #parrot
23:09 rurban left #parrot
23:09 rurban_ is now known as rurban
23:10 hercynium left #parrot
23:18 bacek_at_work msg kid51 I think auto::icu is really close to what we need for LLVM.
23:18 aloha OK. I'll deliver the message.
23:30 ShaneC left #parrot
23:37 kid51 is now known as kid51_at_dinner
23:43 ShaneC joined #parrot
23:50 ShaneC left #parrot
23:52 ShaneC joined #parrot

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced