Parrot 3.2.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot is accepted for GSoC 2011! Student application deadline is Apr 8 | 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 18 March 2011.
soh_cah_toa does the parrot compiler use any debugging data formats? like dwarf or stabs? 00:02
bacek_at_work soh_cah_toa, not yet. I looks like a really good idea to implement such thing 00:04
00:04 plobsing left, plobsing joined
soh_cah_toa okay. i think that would makes things a little easier as i tackle this debugger 00:05
00:08 p6eval left 00:09 dalek left 00:11 dalek joined 00:12 p6eval joined
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
.pbc has various segments. One type of segment stores debugging info 00:15
there are segments for code, constant values, annotations, debug info, etc
soh_cah_toa oh, it already has a section for debuggin info?
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
soh_cah_toa i'm guessing it's not a standardized format 00:17
00:17 plobsing left
whiteknight no 00:19
could be
but isn't
00:20 dalek left
soh_cah_toa would that be a good idea as part of the gsoc debugger project? to implement dwarf-2 in pbc 00:20
00:21 dalek joined
whiteknight it's a good idea in theory. We need to keep scope in mind 00:21
GSoC is only 3 months long 00:22
soh_cah_toa oh, that would take a while to do?
bubaflub soh_cah_toa: write your proposal with some flexibility
soh_cah_toa: so if you have extra time, you have stuff on the timeline
soh_cah_toa: but you have some bare minimum deliverables 00:23
soh_cah_toa: also, at the mid-point you can reassess what you'll be able to do
whiteknight soh_cah_toa: I don't know how long it would take. PBC is one of the darker, dirtier parts of Parrot
we've been slowly working to improve it
soh_cah_toa okay 00:24
cotto_work pbc itself isn't that bad
how we work with it is lta though
soh_cah_toa i see 00:25
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
there's never going to be perfect isolation, it's just something to keep in mind
soh_cah_toa hmmm...okay. how would i be able to read debug information at the pir level though? 00:32
bacek_at_work soh_cah_toa, look at t/pmc/packfile*t 00:34
it's tests for Packfile* PMCs for PBC reading/writing
00:37 bubaflub_ joined, bubaflub left, bubaflub_ is now known as bubaflub
soh_cah_toa okay 00:37
i would like to learn more about the packfile but pdd13 is missing 00:39
bacek_at_work docs/pdds/draft/ 00:40
soh_cah_toa there it is. thanks
00:44 plobsing joined 00:47 kid51 is now known as kid51_at_dinner
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
00:50 woosley joined
cotto_work actually, it is somewhat far from the truth 00:53
it's good for getting the basic idea, but trust the output of pbc_dump more
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
bacek_at_work soh_cah_toa, parrot -o hello.pbc hello.pir; pbc_dump hello.pbc 00:54
cotto_work ^ what he said
bacek_at_work .pir files aren't pbcs :)
soh_cah_toa i figured it would compile down to pbc. now it's working 00:55
cotto_work pbc_dump isn't that magical 00:59
soh_cah_toa it's alright. i think i can use some of its code in the debugger 01:02
01:20 soh_cah_toa left 01:59 kid51_at_dinner is now known as kid51 02:02 whiteknight left 02:07 lucian left 02:20 bubaflub left 02:24 bubaflub joined 02:31 marcel_r joined
dalek rrot/opsc_llvm: 50f9d43 | jkeenan++ | / (2 files):
Overhaul auto::llvm to require minimum version of LLVM. Modify steps test file accordingly.
 02:38
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.
bacek_at_work kid51, thanks! 02:46
kid51, erm... On debian llc is called llc-2.7... 02:47
~/src/parrot (opsc_llvm) $ perl tools/dev/reconfigure.pl --step=auto::llvm --verbose 02:48
auto::llvm - Is minimum version of LLVM installed...Found 'llvm-gcc' version 4.2.1
Is minimum version of LLVM installed.................no.
kid51 Can you try a make realclean and then reconfigure as above 02:49
02:50 marcel_r_ joined
dalek rrot/opsc_lasm: b82f01f | (Jon Gentle)++ | co (5 files):
Begin a (very very hacky) opsc that outputs lasm for my lorito prototype
 02:54
rrot/opsc_lasm: 7616c50 | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
Start outputting some basic, non-quite-functional statements
02:54 marcel_r_ left 02:56 marcel_r left, alin left
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:58
02:59 kid51 left
bacek_at_work atrodo, ping 03:12
atrodo bacek_at_work> pong
bacek_at_work atrodo, can branch from opsc_llvm for lorito playground?
ooops
sorry
I misread branch name. 03:13
My bad...
atrodo yea, the name is very similar
bacek_at_work anyway, you can look into Ops::Op for ideas about how to produce output based on multidispatch 03:14
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.
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:18
bacek_at_work atrodo, I'm working on same thing in jit_prototype branch :) 03:20
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.
dalek TT #2049 created by pmhppumwnbx8++: Read about Removing System Tool Virus 03:28
TT #2049: trac.parrot.org/parrot/ticket/2049
sorear bacek_at_work: nqp-rx multidispatch == pir multidispatch 03:29
bacek_at_work sorear, ok-ok :)
dukeleto tracspam-- 03:34
sorear why aren't first posts on trac queued for moderation?
it works beautifully for the mailing lists 03:35
plobsing sorear: are you one of the brave souls moderating the mailing lists? 03:39
sorear plobsing: no, I'm an outsider who notices that the lists are run way better than trac 03:40
legitimate first posts on trac are rare, and the spam load on trac is far lower than the spam load on public email 03:41
plobsing why does trac even get spam? don't we nofollow all external links? what's the angle? 03:43
atrodo the few external links I checked on the front trac page didn't have nofollow on them 03:52
cotto ~~ 04:06
some spam doesn't even have links 04:07
04:08 bubaflub left
cotto How did that tracspam not hit parrot-tickets? 04:14
I'm not disappointed, just curious.
dalek TT #2051 created by cvxzhkluqh8++: The Start off of Memory Foam 04:15
TT #2051: trac.parrot.org/parrot/ticket/2051
cotto baleeted 04:16
I don't like where this is going
05:04 Drossel joined, Kulag left
dalek rrot/m0-spec: afbd98c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
tighten the description of M0's various tables
 05:05
rrot/m0-spec: a6283e4 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
remove an unneeded op, add a couple more
rrot/m0-spec: 236f884 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add a couple missing ops to the ffi interface
rrot/m0-spec: 56c644b | cotto++ | docs/pdds/draft/pdd32_m0.pod:
reorganize op list, add ffi and total count
cotto that puts M0 at 25 ops, 21 if the temporary ones aren't counted 05:07
dukeleto very interesting 05:08
05:09 Kulag joined, theory joined
cotto With everything in there for ffi, I'm surprised the count was so low 05:10
05:10 Drossel left
sorear "INSP registers (fixed number of each)" 05:10
How fixed?
Are we going back to 32 of each?
cotto I don't know. 32 sounds low. 05:12
sorear otoh 64 of each is rather wasteful
cotto If op arguments are 1 byte, that means we're stuck with no more than 256 slots in the variables table 05:13
actually, that's not true
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.
cotto plobsing, good idea 05:14
05:15 theory left
sorear cotto: replacement-PIR-compiler may need to have spill logic 05:15
plobsing we had spill logic in the past
sorear I just doubt that fixed size contexts make that much sense
"SPARC" 05:16
cotto sorear, that can be done by memset/memget 05:17
which should probably have different names to avoid confusion with C's memset 05:18
sorear cotto: have you ever tried 6502 programming?
cotto sorear, can't say I have 05:19
sorear memory allocation is going through ffi?
not going to be done using M0 ops?
is the GC going to be in M0? 05:20
cotto sorear, the gc will be on top of M0
plobsing sorear: the 2 most common cases (compile to C, JIT), the common pattern for ffi isn't really that bad
dlsym -> ccall 05:21
any self-respecting C compiler or JIT will make that damn-near optimal
sorear plobsing: does dlsym use an S register? does it JIT to a dlsym() call?
plobsing we should really not call it dlsym. csym seems better. 05:22
sorear: the compiler can know (or should be able to know) when it is called with a constant
cotto plobsing, wfm
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:23
limit the scope 05:24
cotto plobsing, so the dl* stuff would go through csym?
dlopen and dlsym
plobsing cotto: dl* should mostly be implemented in M1 with the full FFI
M0 needs just enough to run itself and M1 05:25
cotto agreed
are you saying csym on its own is enough, or csym plus the other function handle bits?
plobsing I don't really understand the function handle bits or the need in general to have specialized function handles in M0 05:26
cotto the idea is to provide an interface that makes sense for whatever kind of interpreter M0 bytecode might run on top of 05:27
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:28
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?
cotto sorear, that's the current context, which is the first argument to any op 05:30
plobsing, I see what you're saying now. 05:31
sorear cotto: that doesn't make a whole lot of sense to me
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.
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:33
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
cotto plobsing, I don't quite understand what you're saying, your suggestion is sounds simpler than function handles. 05:37
sorear, possibly yes, but for now the goal is to get something running 05:38
I'm not saying that anything's near final.
sorear cotto: if "portable M0 code" is going to rely on ccalls, it would probably be a good idea to spec them
on some level I wonder what the point of "few ops" is, if any M0 implementation has to have 50+ ccalls 05:40
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:41
my approach is to define a system where it is not possible to specify this complex behaviour 05:42
cotto let me pseudocode an example to make sure I understand what you're saying 05:43
plobsing it is a similar concept to PG's Blub language 05:45
sorear cotto: why is shl an op, but memory allocation isn't? 05:46
cotto: what if *all* non-control-flow non-ffi operators became ccalls?
plobsing sorear: that is the extreme case 05:47
and that still permits efficient implementation (albeit, such an implementation is not the most obvious)
cotto nopaste.snit.ch/38471 05:48
plobsing, something like that? 05:49
sorear, the bitwise ops need work
plobsing cotto: that looks close. what are the 0's on csym for?
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
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
cotto "hand-waving"
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
plobsing sorear: the interpreter is free to inline ccall functions if it so chooses.
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
plobsing I see your point. The distinction between ops and ccalls is artificial. 05:54
but then where does that leave us? 05:55
cotto That does make an interesting question. 05:58
sorear niecza went down the route of eschewing a FFI in favor of hundreds of wrapper ops. 05:59
I recommend you don't do this.
cotto I don't think our mistakes will be from having too many ops (again). 06:00
06:01 wagle left, wagle joined
cotto though if I knew what they were going to be, I wouldn't make them 06:02
06:06 giwi joined 06:15 Kulag left 06:17 Kulag joined
cotto bikeshed question: what'd be a better name for int2num and num2int? The "2" reminds me of php. 06:18
06:18 alin joined 06:19 cosimo left
sorear cotto: I beleive FIX and FLOAT were the names used in TAOCPv2 06:21
plobsing you could go the C route and have an explicit "to" which is longer than either of the types (eg: hton) 06:22
itof and ftoi I guess
cotto that's what I'm leaning toward 06:23
or iton/ntoi if the registers are called Nx
06:27 Kulag left 06:28 Kulag joined 06:31 ShaneC left
cotto sleeps. plobsing, thanks for the simplifications. 06:40
06:46 ShaneC joined 07:00 woosley1 joined 07:03 woosley left 07:05 fperrad joined 07:06 rurban_ joined 07:09 rurban left, rurban_ is now known as rurban 07:28 alin left 07:38 particle left 07:40 woosley1 left 08:00 woosley joined 08:06 jsut joined 08:11 jsut_ left 08:15 woosley1 joined 08:18 woosley left 08:32 Kulag left 08:35 alin joined, Kulag joined 08:39 Drossel joined, Kulag left 08:54 nopaste left 08:57 nopaste joined 09:18 woosley1 left 09:32 Eduardow left 09:38 mikehh left
bacek ~~ 09:56
10:00 kid51 joined 10:21 bacek left
dalek rrot/jit_prototype: 67151ce | bacek++ | runtime/parrot/library/LLVM/Type.pm:
Create complex parrot's types once only.
 10:30
rrot/jit_prototype: ae04e65 | bacek++ | runtime/parrot/library/LLVM/Type.pm:
Add * variants of parrot types.
rrot/jit_prototype: 1738a31 | bacek++ | runtime/parrot/library/LLVM/Function.pm:
Add Function.return_type.
rrot/jit_prototype: d96afc5 | bacek++ | / (2 files):
Add Module type introspection.
rrot/jit_prototype: 4430c2e | bacek++ | / (2 files):
Add Module.find_function
rrot/jit_prototype: 9a0e222 | jkeenan++ | / (5 files):
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.
rrot/jit_prototype: 50f9d43 | jkeenan++ | / (2 files):
Overhaul auto::llvm to require minimum version of LLVM. Modify steps test file accordingly.
rrot/jit_prototype: d4a977f | bacek++ | / (9 files):
Merge branch 'opsc_llvm' into jit_prototype
10:33 bacek joined 10:38 ascent left, ascent joined
kid51 jit_prototype branch: smolder.parrot.org/app/projects/rep...ails/12931 (linux/i386, no llvm) failures in several files 10:44
bacek kid51, thanks. But branch is far-far away from any testable state. 10:53
moritz is there a list of what the parrot_config conf keys mean? 11:15
if yes, where?
kid51 moritz: Do you mean %Parrot::Config::Generated::PConfig? If so, then the answer is: No. 11:39
nopaste "bacek" at 192.168.1.3 pasted "Most cynical thing I ever done with parrot." (99 lines) at nopaste.snit.ch/38473 12:11
"bacek" at 192.168.1.3 pasted "Most cynical thing I ever done with parrot. (updated version)" (136 lines) at nopaste.snit.ch/38474 12:14
bacek ~~
I _can_ implement runcore in PIR :)
bacek is leaving laughing devilishly 12:16
I can implement JIT in NQP. And run it through it self :)
12:23 kid51 left 12:25 lucian joined 12:27 mtk joined
moritz that's what pypy attempted (or even does), no? 12:30
12:33 whiteknight joined 12:34 whiteknight left
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 :)
lucian: there's also a link to public logs in the topic here
lucian moritz: ah. sorry 12:38
no, that's not what pypy does
but it should be doable on parrot
moritz it didn't jit itself?
lucian moritz: pypy has two parts: a python interpreter written in pure python 12:39
and a translator framework that takes RPython running programs and translates to lower level code
so what they do is translate the python interpreter to C
the JIT and GC are injected by the framework during translation
12:40 whiteknight joined
lucian moritz: so in the final VM pypy generates, the JIT is native code 12:40
whiteknight good morning, #parrot
moritz lucian: thanks for the explanation
lucian yw, hope it helps. it's a rather confusing project, but quite impressive 12:41
bacek aloha, whiteknight 12:42
lucian gm
bacek You'll love nopaste.snit.ch/38474 :)
whiteknight bacek: what is that? 12:49
bacek skeleton to implement runloop in PIR :) 12:52
whiteknight oh, nice
bacek Little bit cynical :)
12:56 mtk left 12:58 ascent left, ascent joined
whiteknight not cynical, this is very awesome 13:03
13:03 mtk joined 13:06 bluescreen joined 13:07 samwho joined, estrabd left, samwho left 13:08 estrabd joined 13:14 particle joined 13:17 bluescreen left, bluescreen joined 13:18 plobsing left 13:30 davidfetter joined 13:31 Eduardow2 joined 13:32 giwi left 13:40 Payne joined 13:49 giwi joined 13:57 plobsing joined 13:58 Payne left 14:02 giwi left
dalek TT #2052 created by azqrzdpsydcbig5++: The Fundamental Cause of Challenge Coins 14:09
TT #2052: trac.parrot.org/parrot/ticket/2052
moritz trac spam 14:16
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
Go make the world a better place, you idiots.
moritz Coke: the answer is simple. Free links, SEO 14:21
google isn't smart enough to recognize non-tech product links on a tech site as spam 14:22
and all in all it still seems to pay off for them, otherwise they wouldn't do it
whiteknight the question is whether is pays off as much as a different strategy would 14:23
I have to believe there are better ways to spread the message
14:26 bluescreen left 14:30 Andy_ joined 14:36 davidfetter left 14:42 mikehh joined
dalek p/ctmo: 81203dc | jonathan++ | src/Regex.pir:
Fix --target=pa[rse|st] - got broken at some point in this branch.
 14:46
14:46 Andy__ joined, Andy_ left 14:50 Andy_ joined, Andy__ left 14:53 giwi joined 15:07 rurban_ joined 15:09 rurban left, rurban_ is now known as rurban 15:12 davidfetter joined 15:14 lucian left 15:17 Patterner left 15:18 Psyche^ joined, Psyche^ is now known as Patterner
dalek TT #2053 created by iofglptbqrud6++: Level of popularity Of Blue Buffalo Dog Food As well as Blue Buffalo ... 15:28
TT #2053: trac.parrot.org/parrot/ticket/2053
moritz more trac spam :( 15:29
15:29 hudnix left 15:30 hudnix joined 15:31 davidfetter left 15:34 lucian joined 15:36 hudnix left 15:37 hudnix joined, alin left 15:42 theory joined 15:52 PacoLinux left
whiteknight FFFUUUUUU 15:56
dalek rrot/m0-spec: ab8c0d0 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
simplify ffi, rename a couple ops, make most of the ffi section incorrect
 15:58
16:10 hercynium joined, cotto left 16:21 theory left
cotto_work ~~ 16:25
16:31 bluescreen joined 16:45 bluescreen left 16:54 giwi left 17:00 bluescreen joined 17:14 Drossel left, Kulag joined 17:25 plobsing left 17:29 ShaneC left 17:33 plobsing joined 17:56 dmalcolm joined 18:06 ShaneC joined 18:11 [hercynium] joined 18:13 [hercynium]_ joined 18:16 hercynium left 18:17 [hercynium] left, [hercynium]_ is now known as hercynium
Coke So, one of our track spams was for a coin-based website. 18:18
s/track/trac/
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
hercynium coin-based... makes me imagine people trying to insert a quarter into their cd-rom drives 18:27
18:31 alin left 18:45 alin joined, davidfetter joined 18:51 alin left 18:56 alin joined 18:58 davidfetter left 18:59 alin left
dalek rrot/m0-spec: 7751fa0 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
update ffi section to match plobsing++'s suggestion
 19:07
atrodo cotto_work> busy on m0-spec today? 19:32
19:48 bluescreen left 19:56 marcel_r joined, samwho joined, plobsing left, samwho left, ambs joined 20:04 samwho joined 20:32 Eduardow2 is now known as Eduardow 20:35 whiteknight_ joined 20:39 whiteknight left, whiteknight_ is now known as whiteknight
dalek nxed: r872 | NotFound++ | trunk/winxedst0.cpp:
indent code generated in stage 0, unfinished
 20:48
20:48 samwho left 20:50 bluescreen joined 20:54 bluescreen left 20:56 mj41 joined
dalek TT #2054 created by pwdiiobamvxlg0++: Chemical Suppliers - UK - Leading Suppliers of Substances employed as ... 20:58
TT #2054: trac.parrot.org/parrot/ticket/2054
21:00 plobsing joined
cotto_work unspammed 21:02
21:07 particle1 joined 21:11 particle left 21:25 marcel_r left 21:32 fperrad left 21:41 soh_cah_toa joined 21:49 Andy_ left 22:14 lucian_ joined 22:15 sigue left 22:17 lucian left 22:21 kid51 joined, mtk left 22:23 mj41 left 22:28 mtk joined 22:31 Hackbinary left 22:34 ambs left 22:36 wknight8111 joined
bacek_at_work ~~ 22:37
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
kid51 k
bacek_at_work I want opsc_llvm "finished" and merged back to master. Probably after 3.3 22:40
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?
I'll take that as a No.
That is so weird. After all, we don't say:
22:42 jsut_ joined
kid51 perl-5.12.0 -E 'say "hello world";' 22:42
bacek_at_work yes, I know.
Very undebian way.
I think we can have workaround for it. 22:43
llvm-config-2.7 --bindir returns "/usr/lib/llvm-2.7/bin/"
which contains non-versioned binaries 22:44
if we put --with-llvm-config=/path/to/llvm-config into Configure.pl
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).
After all, people could compile llvm from source, no?
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)
kid51 I'll have to ponder this more. 22:46
22:46 jsut left
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 nopaste.snit.ch/38479
kid51 okay, I'll get to that later. Have to submit a talk proposal for YAPC tonight. 22:49
bacek_at_work kid51, ok.
thanks for your help
jfyi, llvm-config --cflags produced "-O2 -DNDEBUG". Which is bad. It will switch parrot to "optimized' build if we will use it as is. 22:50
23:06 rurban_ joined 23:07 sigue joined 23:09 rurban left, rurban_ is now known as rurban 23:10 hercynium left
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 23:37 kid51 is now known as kid51_at_dinner 23:43 ShaneC joined 23:50 ShaneC left 23:52 ShaneC 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!