Camelia, the Perl 6 bug

IRC log for #parrot, 2011-03-07

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 whiteknight there are a lot of languages that could use very similar logic for tokenizing
00:01 NotFound I'm not sure, maybe something based in ohm-eta will be more appropiate for general purpose usage.
00:02 plobsing Ωη supports hybrid tokenfull/tokenless parsing strategy. it could easily assimilate a foreign tokenizer.
00:02 NotFound Oh, you mean just the tokenizer.
00:03 plobsing tokenization is something that pure RecDescent/PEG does rather inefficiently
00:03 whiteknight NotFound: yeah, just the tokenizer
00:03 whiteknight NotFound: I've had a few places where I wish I was able to parse strings more easily
00:04 NotFound It's quite independant of the parser, yes. But the strings and numeric formats are specific.
00:04 plobsing I think it would be nifty to have a tokenizer, but I'm not sure how general-purpose the one in Winxed is.
00:04 whiteknight NotFound: right, but for the most part, being able to separate out whitespace from words/identifiers, and operators is very important
00:04 whiteknight plus, for any behavior we wanted changed, we could subclass
00:06 NotFound Right now it's not designed to be subclassable, but that may be changed.
00:06 whiteknight anywy, that's just an idea I had
00:07 cotto Does anyone know Haskell to a reasonable degree?
00:07 NotFound The main problem is conflict with the design goal of no dependances of libraries.
00:08 plobsing cotto: I do, but noone has forced me to learn it yet ;-)
00:08 whiteknight NotFound: winxed wouldn't need to use the library, we could just copy the code
00:08 NotFound No problem, then.
00:09 cotto I have a dim idea of what the concurrency primitives paper is talking about, but I suspect I'll need to learn Haskell better before I can grok it satisfactorily.
00:09 plobsing I read it somewhat. the HEC seems to be their equivalent of our Context PMC.
00:09 cotto aloha, concurrency primitives paper is http://research.microsoft.com/en-us/um/​people/simonpj/papers/lw-conc/index.htm
00:09 cotto I got that impression.
00:10 plobsing so what are you having trouble understanding?
00:12 cotto the notation used to define the semantics of the operations
00:14 whiteknight I always hate the notations used in CS papers
00:14 cotto neither humans nor machines can understand it
00:14 plobsing that's not Haskell, that's CS mumbo jumbo
00:14 cotto It's perfect.
00:15 cotto I know, but it's still pretty undecipherable.
00:15 cotto It seems pretty important to understand what the primitives they're proposing are,
00:15 cotto .
00:15 NotFound "We don't discriminate neither humans or machines."
00:16 cotto aloha, clock?
00:16 aloha cotto: LAX: Sun, 16:16 PST / CHI: Sun, 18:16 CST / NYC: Sun, 19:16 EST / UTC: Mon, 00:16 UTC / LON: Mon, 00:16 GMT / BER: Mon, 01:16 CET / TOK: Mon, 09:16 JST / SYD: Mon, 11:16 EST
00:17 NotFound cotto: maybe they plan to explain all in the "Director's cut" edition of te paper.
00:18 NotFound In the "extras" dvd.
00:18 * plobsing suspects this is the "extend" portion of some "embrace and extend" strategy out of MSR.
00:19 plobsing not sure what they're embracing
00:20 NotFound A bear.
00:22 cotto You know it's good with sentences like "The term M is, as usual, the current monadic term under evaluation."
00:23 NotFound That reminds me in some way a joke about a variable named LancelotFavouriteColor...
00:27 * cotto goes ... place
00:27 NotFound Here is: http://mindprod.com/jgloss/unmainnaming.html
00:28 NotFound "Use constant names like LancelotsFavouriteColour instead of blue and assign it hex value of 0x0204FB."
00:44 sorear someone is having trouble understanding the Simons?
00:44 whiteknight NotFound: how hard would it be to indent the generated PIR code from winxed?
00:44 * sorear dusts off his 2007 Haskell Academia Hat
00:45 NotFound whiteknight: just indent the code inside subs, or something more elaborate?
00:45 whiteknight just the code inside subs would be best
00:45 whiteknight well, not "best", but it would be very nice
00:46 NotFound Probably esay, but I need to take a look at some corner cases.
00:46 whiteknight it doesn't need to be perfect
00:46 NotFound I'll take a look tomorrow.
00:46 whiteknight plobsing has informed me that IMCC's error reporting is absolutely stupid if the code isn't indented
00:47 NotFound Oh.... So that is the reason? :o
00:47 plobsing it just requires whitespace at the beginning of the line. no smart indenting required.
00:47 NotFound IMCC always amazes me.
00:47 whiteknight plobsing: right, but smarter indenting would be nice for readability
00:47 NotFound Nice catch, it will be highly useful.
00:47 plobsing whiteknight: I find the PIR generated by Winxed to be quite readable already.
00:48 whiteknight plobsing: yes, it's nice. Some whitespace would only make it nicer
00:48 whiteknight it's far nicer than reading the output of NQP or some other HLL
00:50 NotFound That problem applies also to .annotate directives?
00:51 plobsing .annotate shouldn't be affected
00:51 plobsing it only affects things where the PIR file line number matter
00:52 sorear cotto?
00:53 NotFound Good to know. I'll work on it tomorrow, going to be dnow.
01:27 lopaway is now known as lopnor
01:34 jrt4 joined #parrot
01:43 kid51 joined #parrot
01:47 dalek TT #1655 closed by plobsing++: [DEPRECATED] logical vtables
01:47 dalek TT #1655: http://trac.parrot.org/parrot/ticket/1655
01:49 kid51 plobsing:  Thanks for looking into that old ticket.
02:00 whiteknight what's really maddening is not the fact that the IMCC tells me all my errors are happening on line 1. What's really frustrating is that it's telling me the errors are happening in the wrong files
02:05 whiteknight And then, I love the error message "Parent isn't a class" I get from NQP. Doesn't tell me which parent isn't a class, or which file it's happening in, or what the name of the subclass is
02:05 whiteknight you know, any of the information that would help me actually find the source of the error
02:06 Coke seen sorear?
02:06 aloha sorear was last seen in #perl6 26 mins 19 seconds ago saying "OK".
02:06 whiteknight although to it's credit, the NQP files actually give me IMCC line numbers
02:07 sorear Coke: hi
02:07 Coke aloha, no, partcl is https://github.com/partcl/partcl-nqp - partcl-old is https://github.com/partcl/partcl
02:07 aloha Coke: Okay.
02:08 sorear Coke: I hear you have TPF connections.
02:08 Coke msg plobsing - is there a trac ticket for the "must have indenting just so or line numbers go screwy?"
02:08 aloha OK. I'll deliver the message.
02:09 Coke sorear: I'm on the board of the grant committee and know some people on the board.
02:09 Coke (the main board)
02:09 sorear whiteknight: You're a committer.  What, or who, is stopping you from hacking Parrot to give good error messages?
02:09 sorear Coke: who can delete data from the TPF wiki history?
02:10 sorear Coke: and who can deactivate accounts?
02:10 sorear Coke: I recently had to disable the #perl6 announcerbot because the TPF wiki is getting spammed hard
02:11 kid51 sorear:  Could you contact the Perl Foundation board directly?
02:12 sorear kid51: I probably could, but I don't like cold calls
02:12 Coke which wiki?
02:12 Coke http://www.perlfoundation.org/perl6/index.cgi ?
02:12 kid51 sorear:  I have found Karen Pauley, TPF president, to be very responsive to me.
02:13 kid51 As have the perl.org sysadmins (though they might not have anything to do with perlfoundation.org)
02:13 sorear Coke: yes
02:15 Coke sorear: the last update I see is on feb 23rd.
02:15 Coke Can you point me at a spammy page? (I can see if I have admin privs)
02:16 dalek Rosella: ce78029 | Whiteknight++ | src/ (2 files):
02:16 dalek Rosella: some fixes identified when I tried to run the PLA test suite
02:16 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/ce78029406
02:16 Coke or I could check on a regular page. Nope.
02:16 Coke so, kid51++'s suggestion is what I would do - ping karen. feel free to mention my name.
02:17 sorear Coke: http://www.perlfoundation.org/perl6/index.cgi?1 was previously spammed
02:18 sorear notice the 102 revisions, by the same person, none useful
02:18 sorear but I guess his strategy involved moving on
02:18 sorear at one point there were 100s of attachments of HTML files with pill links
02:18 sorear someone deleted them
02:19 whiteknight left #parrot
02:19 sorear the recent changes list being empty is pretty wtfy
02:20 sorear since I've seen changes happening
02:20 Coke so it looks like someone is cleaning things up.
02:20 Coke but feel free to ping karen and ask who the admin is.
02:20 Coke need her email?
02:21 kid51 karen at perlfoundation dot org -- as the website says
02:21 kid51 You should probably also write to webmaster at perlfoundation dot org (Casey West)
02:22 kid51 (and, while you're at it, mention that www.perlfoundation.org's home page is very out of date ;-) )
02:24 Coke I wouldn't combine that, no.
02:27 kid51 This page, however, looks more actively maintained:  http://news.perlfoundation.org/
02:27 lopnor is now known as lopaway
02:28 kid51 afk
02:39 dalek nqp/slp: 2e788f6 | jonathan++ | src/ (7 files):
02:39 dalek nqp/slp: Move NQP into a HLL of its own. This is a pre-req for being able to HLL-map things for NQP's use, but will also go a long way to resolving NQP/NQP-rx symbol conflicts.
02:39 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/2e788f6386
02:39 dalek nqp/slp: eb5f068 | jonathan++ | src/NQP/ (2 files):
02:39 dalek nqp/slp: Register NQP as just NQP, not NQP-rx.
02:39 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/eb5f068feb
02:39 dalek nqp/slp: 4c71035 | jonathan++ | t/hll/0 (2 files):
02:39 dalek nqp/slp: Update a couple of tests to track NQP moving to its own HLL namespace.
02:39 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/4c710356c0
02:39 dalek nqp/slp: 3cc2814 | jonathan++ | src/stage0/ (5 files):
02:39 dalek nqp/slp: Update bootstrap.
02:39 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/3cc2814617
02:39 dalek nqp/slp: d3f4b23 | jonathan++ | / (15 files):
02:40 dalek nqp/slp: Merge branch 'master' into slp
02:40 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/d3f4b23008
02:40 dalek nqp/slp: a630c2b | jonathan++ | src/pmc/nqplexinfo.pmc:
02:40 dalek nqp/slp: Don't need to visit various a few things we'll only set up from the serialization context deserializer; clear up useless freeze/thaw that just called SUPER; add get_iter.
02:40 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/a630c2be5f
02:40 dalek nqp/slp: e08aaf1 | jonathan++ | src/pmc/nqplex (2 files):
02:40 dalek nqp/slp: Fix some marking issues.
02:40 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/e08aaf11e9
02:40 dalek nqp/slp: 5ad5467 | jonathan++ | src/ (2 files):
02:40 dalek nqp/slp: Ensure we end up with runtime lexpads being NQPLexPad.
02:40 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/5ad5467084
02:40 dalek nqp/slp: 35ee39a | jonathan++ | src/stage0/ (2 files):
02:40 dalek nqp/slp: Fiddle with the bootstrap code so things build with the new lexpad classes.
02:40 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/35ee39af40
02:40 dalek nqp/slp: a694c40 | jonathan++ | src/NQP/Actions.pm:
02:40 dalek nqp/slp: Make sure lexpads are created of the correct type in compiled code.
02:40 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/a694c40886
02:40 dalek nqp/slp: dd13f30 | jonathan++ | src/pmc/nqplex (2 files):
02:40 dalek nqp/slp: Ensure that NQPLexPad can cope with a Parrot LexInfo as well as an NQPLexInfo.
02:40 dalek nqp/slp: review: https://github.com/perl6/nqp/commit/dd13f30be0
02:44 dalek partcl-nqp: 5b1f6fa | coke++ | src/Partcl/Grammar.pm:
02:44 dalek partcl-nqp: hope these are taken in order, fix octal parse.
02:44 dalek partcl-nqp: review: https://github.com/partcl/p​artcl-nqp/commit/5b1f6fac27
02:49 dalek nqp: d3f4b23 | jonathan++ | / (15 files):
02:49 dalek nqp: Merge branch 'master' into slp
02:49 dalek nqp: review: https://github.com/perl6/nqp/commit/d3f4b23008
02:49 dalek nqp: a630c2b | jonathan++ | src/pmc/nqplexinfo.pmc:
02:49 dalek nqp: Don't need to visit various a few things we'll only set up from the serialization context deserializer; clear up useless freeze/thaw that just called SUPER; add get_iter.
02:49 dalek nqp: review: https://github.com/perl6/nqp/commit/a630c2be5f
02:49 dalek nqp: e08aaf1 | jonathan++ | src/pmc/nqplex (2 files):
02:49 dalek nqp: Fix some marking issues.
02:49 dalek nqp: review: https://github.com/perl6/nqp/commit/e08aaf11e9
02:49 dalek nqp: 5ad5467 | jonathan++ | src/ (2 files):
02:49 dalek nqp: Ensure we end up with runtime lexpads being NQPLexPad.
02:49 dalek nqp: review: https://github.com/perl6/nqp/commit/5ad5467084
02:49 dalek nqp: 35ee39a | jonathan++ | src/stage0/ (2 files):
02:49 dalek nqp: Fiddle with the bootstrap code so things build with the new lexpad classes.
02:49 dalek nqp: review: https://github.com/perl6/nqp/commit/35ee39af40
02:49 dalek nqp: a694c40 | jonathan++ | src/NQP/Actions.pm:
02:49 dalek nqp: Make sure lexpads are created of the correct type in compiled code.
02:49 dalek nqp: review: https://github.com/perl6/nqp/commit/a694c40886
02:49 dalek nqp: dd13f30 | jonathan++ | src/pmc/nqplex (2 files):
02:49 dalek nqp: Ensure that NQPLexPad can cope with a Parrot LexInfo as well as an NQPLexInfo.
02:49 dalek nqp: review: https://github.com/perl6/nqp/commit/dd13f30be0
02:49 dalek nqp: bb9ccfe | jonathan++ | src/stage0/ (4 files):
02:49 dalek nqp: Re-bootstrap with the static lexpad support.
02:50 dalek nqp: review: https://github.com/perl6/nqp/commit/bb9ccfe296
02:53 * Coke wonders why "bit_ops" doesn't seem to be loading anymore.
02:55 Coke How can I get more diagnostics from:
02:55 Coke $ ./partcl error.t
02:55 Coke error:imcc:syntax error, unexpected PREG, expecting '(' ('$P20') in file 'EVAL_2' line 12
02:56 Coke (if I run with parrot -D60 and check the file EVAL_2, that is one line away from an invocation of bnot_PP - which is the operator I'd expect this to be failing on, given the tcl involved.
03:03 Coke huh. if I dtrace partcl, it doesn't seem to even be trying to open bit_ops, which is weird, given the ".loadlib 'bit_ops'
03:12 Coke huh. .loadlib seems to have been broken at some point.
03:12 Coke I am now required to do both a .loadlib for compilation, and then have an :init with explicit "loadlib" opcodes for runtime.
03:12 kid51 left #parrot
03:14 Coke msg whiteknight check out my .loadlib IMCC issue at http://irclog.perlgeek.de/p​arrot/2011-03-07#i_3365878
03:14 aloha OK. I'll deliver the message.
03:23 Andy joined #parrot
03:26 Coke Andy: hio.
03:26 Andy hiya
03:26 Andy Sunday night Parrot code cleanup!
03:31 dalek partcl-nqp: 0d9a0fa | coke++ | src/Partcl.pir:
03:31 dalek partcl-nqp: workaround .loadlib bug
03:31 dalek partcl-nqp: (at least, behavior change)
03:31 dalek partcl-nqp: review: https://github.com/partcl/p​artcl-nqp/commit/0d9a0fadf1
03:31 dalek partcl-nqp: 3977a9d | coke++ | t/cmd_expr.t:
03:31 dalek partcl-nqp: un-TODO passing test.
03:31 dalek partcl-nqp: review: https://github.com/partcl/p​artcl-nqp/commit/3977a9dd87
03:49 dalek parrot: 8b8b3b9 | petdance++ | src/nci/ (2 files):
03:49 dalek parrot: consting, removing unused vars
03:49 dalek parrot: review: https://github.com/parrot/parrot/commit/8b8b3b93dc
03:55 hudnix left #parrot
04:00 Coke weird. TT #1886 works if I do [expr $i + 1] instead of [expr $i+1]
04:01 dalek parrot: 776e9da | petdance++ | src/pmc/nci.pmc:
04:01 dalek parrot: consting and removing unused var
04:01 dalek parrot: review: https://github.com/parrot/parrot/commit/776e9da559
04:02 dalek parrot: e7d3b58 | petdance++ | / (2 files):
04:02 dalek parrot: re-headerized
04:02 dalek parrot: review: https://github.com/parrot/parrot/commit/e7d3b58354
04:05 sigue left #parrot
04:10 sigue joined #parrot
04:17 dalek parrot: 0aaee88 | petdance++ | src/string/encoding/ (5 files):
04:17 dalek parrot: shimming up unused interps
04:17 dalek parrot: review: https://github.com/parrot/parrot/commit/0aaee88240
04:19 ttbot Parrot 0aaee882 i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/50765
04:19 dalek parrot: 3d0d837 | petdance++ | src/string/encoding/latin1.c:
04:19 dalek parrot: fixed a mistakenly shimmed interp
04:19 dalek parrot: review: https://github.com/parrot/parrot/commit/3d0d83799f
04:20 ttbot Parrot 0aaee882 i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/50766
04:21 ttbot Parrot 0aaee882 i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/50767
04:23 cotto ~~~~
04:24 Coke cotto: ~~
04:24 Coke I am down to one failing test in partcl-nqp now as well.
04:24 sorear hi cotto
04:24 sorear I saw you were having trouble with Simon-speak earlier
04:25 sorear may I help?
04:25 cotto Coke, I saw.  That's exciting.
04:25 cotto sorear, you may try
04:26 * sorear used to be a Haskell person
04:27 cotto I aspire to know enough to be dangerous.
04:29 sorear so uh... in that paper, they're breaking down the existing functions of the threaded runtime into primitives
04:29 cotto right
04:30 sorear GHC Haskell has long had M:N threads; with that paper, "primitive" threads are just OS threads, the M:N stuff is handled by Haskell code
04:30 sorear that seems to be most of the point
04:30 cotto my academic-speak to English compiler segfaults on that paper
04:30 sorear so they've added continuations (to support scheduling), and a timer callback
04:32 sorear the interesting part is "Figure 2"
04:32 sorear it's nice that they broke it down like that.
04:32 cotto well, that and all the ones after
04:34 Coke I am down to one failing test in partcl-nqp now as well.
04:34 cotto Figure 2 I'm not to far from understanding.  It's the operational semantics in figures 4, 5, 6, etc that are confusing
04:34 Coke whoops
04:35 cotto Coke, that's great.  We'll throw a Coke party.
04:36 cotto Oh.  There's a wikipedia page on operational semantics.  I should look into that.
04:38 cotto Thank you, wikipedia, and all the nerds who wrote you.
04:38 dalek parrot: 2ebb70a | petdance++ | src/pmc/namespace.pmc:
04:38 dalek parrot: flag unused interps
04:38 dalek parrot: review: https://github.com/parrot/parrot/commit/2ebb70aa7d
04:38 dalek parrot: d502f30 | petdance++ | src/pmc/mappedbytearray.pmc:
04:38 dalek parrot: consting pointers. Flagging unused interps. Removed unused var
04:38 dalek parrot: review: https://github.com/parrot/parrot/commit/d502f30181
04:41 lateau joined #parrot
04:41 lateau left #parrot
04:47 sorear cotto: mm?  Did it help much?  Any questions?
04:48 cotto sorear, not so far but I haven't given up yet.
04:50 sorear basically the idea with operational semantics is to define a set of states and a set of allowed changes between states
04:50 sorear so if you have something nondeterministic like threading?  fine, just have A -> B *and* A -> C
04:51 sorear it's a cross between pseudocode and Hoare logic
04:51 dalek parrot: 7e326a7 | petdance++ | src/string/encoding/ (3 files):
04:51 dalek parrot: Shimming unused args. Removing and localizing variables.
04:51 dalek parrot: review: https://github.com/parrot/parrot/commit/7e326a72e8
04:52 sorear most of the operational semantics rules here are just ordinary monadic-Haskell rules
04:54 sorear I basically skipped over most of the rules; they aren't useful for a quick overview
04:59 dalek parrot: 22d0a53 | petdance++ | compilers/imcc/main.c:
04:59 dalek parrot: remove unused var
04:59 dalek parrot: review: https://github.com/parrot/parrot/commit/22d0a53f0e
05:01 dalek parrot: b3c70cd | petdance++ | src/pmc/packfileannotations.pmc:
05:01 dalek parrot: removed unused last_key_id variable
05:01 dalek parrot: review: https://github.com/parrot/parrot/commit/b3c70cd283
05:09 fperrad joined #parrot
05:12 dalek parrot/opsc_llvm: 45961c9 | bacek++ | runtime/parrot/library/LLVM.pm:
05:12 dalek parrot/opsc_llvm: "Import" all LLVM C API functions.
05:12 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/45961c9247
05:35 Andy left #parrot
06:08 dalek parrot/opsc_llvm: 5012c59 | bacek++ | runtime/parrot/library/ (3 files):
06:08 dalek parrot/opsc_llvm: Add LLVM::Opaque
06:08 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/5012c59381
06:08 dalek parrot/opsc_llvm: 2ae9971 | bacek++ | runtime/parrot/library/LLVM/Module.pm:
06:08 dalek parrot/opsc_llvm: Inherit Module from Opaque
06:08 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/2ae9971f0e
06:08 dalek parrot/opsc_llvm: 3f98103 | bacek++ | / (3 files):
06:08 dalek parrot/opsc_llvm: Migrate Function and BasicBlock to be Opaque
06:08 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/3f98103b86
06:09 sorear woah!
06:09 bacek_at_work sorear, ?
06:10 sorear bacek_at_work: llvm parrot stuff.
06:10 bacek_at_work sorear, it's kind of old news already. For about 20 hours :)
06:11 sorear huh.  How are you getting around the need for C++ name mangling?
06:12 sorear bacek_at_work: yes but I only just noticed :)
06:14 plobsing sorear: LLVM has a C interface
06:14 bacek_at_work sorear, what plobsing said :)
06:14 bacek_at_work Unfortunately it's incomplete (afaik)
06:14 bacek_at_work At least python bindings has additional C++ code to work with llvm
06:17 sorear I am failing to find any documentation whatsoever for the C interface on llvm.org
06:18 sorear I read *all* the LLVM docs a few weeks ago and they never mentioned this *annoyed*
06:18 sorear months
06:18 * sorear goes and looks at source
06:19 TiMBuS include/llvm-c
06:19 sorear Is there any real documentation for the LLVM API, anywhere?
06:20 bacek_at_work sorear, nope
06:20 bacek_at_work not for C at least
06:21 cotto bacek_at_work, it took you that little time to write those binding *without* docs?
06:22 bacek_at_work cotto, erm... Almost :)
06:22 bacek_at_work Just Kaledoscope tutorial
06:22 bacek_at_work and http://npcontemplation.blogspot.com/2​008/06/secret-of-llvm-c-bindings.html
06:45 dalek parrot/opsc_llvm: 158897b | bacek++ | runtime/parrot/library/LLVM/ (4 files):
06:45 dalek parrot/opsc_llvm: Provide default .BUILD and fix Builder to use unwrap
06:45 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/158897b1a6
06:45 dalek parrot/opsc_llvm: a6d8480 | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
06:45 dalek parrot/opsc_llvm: Migrate Builder to Opaque. Add .global_string method
06:45 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/a6d8480843
06:45 dalek parrot/opsc_llvm: e4e6670 | bacek++ | t/library/llvm.t:
06:45 dalek parrot/opsc_llvm: Add test for actual call.
06:45 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/e4e66709e7
06:45 nopaste "bacek" at 192.168.1.3 pasted "HO-HO-HO! LLVM test results! I can call native function from it!" (34 lines) at http://nopaste.snit.ch/35628
06:50 plobsing bacek_at_work: nice!
06:51 bacek_at_work Step 2: ...
06:51 bacek_at_work Step 3: Profit!
06:52 plobsing I've been wondering how you might go about jitting without hitting the inferior runloops problem rather hard. Any ideas on the subject?
06:52 sorear plobsing: what is the inferior runloops problem?
06:53 plobsing sorear: when Parrot calls native calls Parrot
06:53 plobsing then the inner Parrot does something continuationy (eg: exceptions)
06:53 plobsing boom
06:54 bacek_at_work plobsing, I'm going to jit whole Sub.
06:54 bacek_at_work op-by-op
06:54 bacek_at_work any non-local jumps will return to mail loop
06:54 plobsing oic
06:54 plobsing so JIT only for leaf subs
06:55 bacek_at_work not sure will it work for longjump...
06:56 jrt4 left #parrot
06:56 bacek_at_work plobsing, yes
06:57 plobsing wait, does LLVM support anything like Fortran's ENTRY statement? then you could have multiple JIT blocks for non-leaves.
06:57 bacek_at_work invokecc/throw/whatever will return PC
06:57 plobsing and still hit the trampoline on non-local jumps
06:57 bacek_at_work plobsing, not sure. LLVM is still very new for me.
06:57 rurban_ joined #parrot
06:58 bacek_at_work Actually I never did something like thin in my entire life :)
06:58 plobsing bacek_at_work: how are you serializing the ops structure for runtime JIT?
06:58 bacek_at_work plobsing, still thinking about it.
06:59 plobsing I had some thoughts about how I'd go about that for LibJIT, but LLVM has bytecode formats already if I am not mistaken.
06:59 bacek_at_work but llvm has "bitcode" format. I'll probably just stick another pointer into opinfo_t with it
06:59 bacek_at_work yes :)
07:00 rurban left #parrot
07:00 rurban_ is now known as rurban
07:01 sorear plobsing: to avoid inferior runloop issues, the JITted code must never make a non-tail call into the op dispatcher
07:02 sorear it's totally ok for invokecc to turn into a tailcall to the main runloop, and for the main runloop to tailcall jitted code
07:02 plobsing interesting. I was thinking of maintaining a separate mapping for the JIT system, but there is little to no reason why it can't be maintained in the op_info.
07:02 sorear if the runloop has to use non-tail calls, then the jitted code has to arrange to *return* to the runloop
07:03 sorear I guess jit fragments would have to return a new IP, like invoke vtables
07:04 sorear invoke vtables are a lot like jit code; they need to be called from the runloop without using a new runloop
07:05 plobsing sorear: yeah. it's just a little messy.
07:06 plobsing bacek_at_work: I realize most of the work is already done, but are you aware of the ncidefs2pir tool for creating modules from lists of nci definitions?
07:16 theory left #parrot
07:16 jrt4 joined #parrot
07:24 jrt4 left #parrot
07:31 bacek_at_work plobsing, but it will require to create "nci file definition". Which is same amount of work
07:33 sorear Do we have a bundled runtime-wrapper-generator yet?
07:34 plobsing bacek_at_work: it requires slightly less work because it sets up the "populate namespace" code for you.
07:35 plobsing but you already wrote that part :(
07:35 plobsing sorear: "runtime wrapper generator"?
07:39 bacek_at_work plobsing, no worries. I had a plenty of time during DB wipe
07:43 lopaway is now known as lopnor
09:02 lopnor is now known as lopaway
09:13 jsut joined #parrot
09:18 jsut_ left #parrot
10:12 lucian joined #parrot
10:16 arnsholt_ left #parrot
10:21 arnsholt joined #parrot
10:22 lucian_ joined #parrot
10:22 lucian left #parrot
10:23 lopaway is now known as lopnor
10:25 lucian joined #parrot
10:25 bacek ~~
10:28 lucian_ left #parrot
10:30 lucian left #parrot
11:01 lopnor is now known as lopaway
11:21 dalek parrot/opsc_llvm: 99be336 | bacek++ | runtime/parrot/library/LLVM.pm:
11:21 dalek parrot/opsc_llvm: Remove debug output.
11:21 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/99be3368c9
11:21 dalek parrot/opsc_llvm: d331923 | bacek++ | runtime/parrot/library/llvm_lib.pir:
11:21 dalek parrot/opsc_llvm: Add LLVM::Opaque.get_pointer VTABLE to avoid unwrapping objects constantly
11:21 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/d331923724
11:21 dalek parrot/opsc_llvm: 9a84ad1 | bacek++ | runtime/parrot/library/LLVM/ (2 files):
11:21 dalek parrot/opsc_llvm: Remove a lot of .unwrap
11:21 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/9a84ad1ebd
11:21 dalek parrot/opsc_llvm: f6556ec | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
11:21 dalek parrot/opsc_llvm: Add Builder.{alloca|load|store}
11:21 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/f6556ecf72
11:52 dalek parrot/opsc_llvm: 47808d1 | bacek++ | runtime/parrot/library/LLVM/Module.pm:
11:52 dalek parrot/opsc_llvm: Add Module.add_type_name
11:52 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/47808d11ed
11:52 dalek parrot/opsc_llvm: 8c491bd | bacek++ | runtime/parrot/library/LLVM/Type.pm:
11:52 dalek parrot/opsc_llvm: Add Type.struct
11:52 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/8c491bd8a2
12:16 jsut_ joined #parrot
12:20 jsut left #parrot
12:39 janus left #parrot
12:41 janus joined #parrot
12:47 janus left #parrot
12:54 janus joined #parrot
13:01 janus left #parrot
13:01 janus joined #parrot
13:06 dalek parrot/opsc_llvm: 30e820d | bacek++ | runtime/parrot/library/LLVM/Constant.pm:
13:06 dalek parrot/opsc_llvm: Allow different wide int constants
13:06 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/30e820da44
13:06 dalek parrot/opsc_llvm: c8be6d2 | bacek++ | runtime/parrot/library/LLVM/ (2 files):
13:06 dalek parrot/opsc_llvm: Add GEP building
13:06 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/c8be6d2bad
13:06 dalek parrot/opsc_llvm: 2e341f6 | bacek++ | t/library/llvm.t:
13:06 dalek parrot/opsc_llvm: Remove useless .wrap calls
13:06 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/2e341f633a
13:14 Patterner left #parrot
13:27 fperrad_ joined #parrot
13:30 fperrad left #parrot
13:30 fperrad_ is now known as fperrad
13:30 mtk joined #parrot
13:31 masak joined #parrot
13:39 hudnix joined #parrot
13:47 lucian joined #parrot
13:56 dalek parrot: de0365c | (Gerd Pokorra)++ | compilers/data_json/JSON.nqp:
13:56 dalek parrot: add null rule in JSON.nqp
13:56 dalek parrot: review: https://github.com/parrot/parrot/commit/de0365c9d9
14:06 ambs joined #parrot
14:07 davidfetter joined #parrot
14:11 frodwith left #parrot
14:15 whiteknight joined #parrot
14:23 whiteknight good morning, #parrot
14:23 whiteknight msg cotto Check out TT #2042. I assigned to you for initial review. I don't think the "can" vtable is really needed.
14:23 aloha OK. I'll deliver the message.
14:31 dalek TT #2042 created by whiteknight++: Deprecate VTABLE_can
14:31 dalek TT #2042: http://trac.parrot.org/parrot/ticket/2042
14:32 Coke whiteknight: you could override can in your class to avoid a potentially expensive find_method lookup
14:32 Coke (for something like AUTOLOAD)
14:32 whiteknight Coke: VTABLE_can cannot be overloaded currently. At least not from PIR
14:32 Coke whiteknight: there are PMCs.
14:32 whiteknight you would have to subclass Object at the C level, then subclass Class to instantiate your new objects
14:33 whiteknight right, there are ways. It's horrible to do
14:33 Coke I present it without endorsing it as a reason for keeping the vtable.
14:33 whiteknight my branch adds the ability to override VTABLE_can, but I'm not sure I want to merge that branch
14:38 dalek Heuristic branch merge: pushed 34 commits to parrot/gerd/JSON_nqp by gerd
14:49 whiteknight Hmmm.. that error message I was complaining about yesterday was in Class PMC, not in P6object
14:58 rurban_ joined #parrot
15:00 rurban left #parrot
15:00 rurban_ is now known as rurban
15:08 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#11700) fulltest) at 3_1_0-739-gde0365c - Ubuntu 10.10 i386 (g++-4.5)
15:09 mikehh smolder #11699 failed to upload, but re-sent and #11700 was ok
15:10 whiteknight Coke: did you create a ticket for that .loadlib issue?
15:10 Coke not yet. figured odds were good the behavior changed deliberately.
15:11 Coke if not, I can open a ticket, sure.
15:11 whiteknight I might not have a chance to look at it until much later, and I don't want to forget
15:13 cotto ~~
15:14 sorear whiteknight: hi.
15:14 whiteknight hello sorear
15:15 sorear whiteknight: you're a committer.  I'd like to know, what or who is stopping you from modifying Parrot to improve the "Parrot isn't a Class" error message?
15:15 ambs_ joined #parrot
15:15 dalek parrot: b855b2f | Whiteknight++ | / (2 files):
15:15 dalek parrot: Add some (any) information to the 'Parent isn't a class' error message in Class.add_parent. This helps find which class is having the problem
15:15 whiteknight sorear: ...
15:15 dalek parrot: review: https://github.com/parrot/parrot/commit/b855b2f30b
15:16 whiteknight sorear: it turns out, nothing is stopping me
15:16 ambs left #parrot
15:16 ambs_ is now known as ambs
15:17 benabik joined #parrot
15:18 dalek TT #2043 created by coke++: .loadlib works when compiling, but not when running PBC
15:18 dalek TT #2043: http://trac.parrot.org/parrot/ticket/2043
15:19 Coke whiteknight: done
15:19 benabik Morning, #parrot
15:19 whiteknight Coke++
15:19 whiteknight good morning, benabik
15:20 Coke now I just need help tracking down #1886
15:21 benabik Finals and vacation's taken me away from IRC for a couple weeks.  Did I miss anything interesting?
15:21 whiteknight benabik: Nothing super-huge. always interesting things happening though
15:21 Coke bacek is working on an llvm backend to ops2c.
15:22 benabik That sounds awesome. Using API or generating IR?
15:23 Coke using the hidden C api.
15:24 benabik Hidden C API?
15:24 whiteknight last I looked at the LLVM docs the C api wasn't hidden. It wasn't well-advertised but I did find it with minimal effort
15:25 lucian whiteknight: it's just a little horrible
15:25 whiteknight they're a c++ project. compatibility with C is not high on their priorities list
15:25 whiteknight of course, if people start using that API, they might be more serious about maintaining it
15:27 dalek parrot/gerd/JSON_nqp: 938ab0e | (Gerd Pokorra)++ | t/compilers/data_json/to_parrot.t:
15:27 dalek parrot/gerd/JSON_nqp: switch back to test JSON from PGE
15:27 dalek parrot/gerd/JSON_nqp: review: https://github.com/parrot/parrot/commit/938ab0e8cc
15:27 dalek parrot/gerd/JSON_nqp: de4f790 | (Gerd Pokorra)++ | t/compilers/data_json/to_parrot_2.t:
15:27 dalek parrot/gerd/JSON_nqp: add test for JSON from NQP
15:27 dalek parrot/gerd/JSON_nqp: review: https://github.com/parrot/parrot/commit/de4f790013
15:27 dalek parrot/gerd/JSON_nqp: 72c0a77 | (Gerd Pokorra)++ | MANIFEST:
15:27 dalek parrot/gerd/JSON_nqp: update mainfest
15:27 dalek parrot/gerd/JSON_nqp: review: https://github.com/parrot/parrot/commit/72c0a77c13
15:32 sorear whiteknight: nice.  I was actually expecting some variation on "bureaucratic BS", but that works too.
15:32 benabik left #parrot
15:32 benabik joined #parrot
15:32 whiteknight sorear: first step is for me to reach a high level of frustration with the status quo. then I have to find the problem, fix it, and test it
15:33 whiteknight the only thing stopping me is time
15:38 Patterner joined #parrot
15:38 benabik left #parrot
15:39 benabik joined #parrot
15:39 masak left #parrot
15:43 hercynium joined #parrot
15:57 ambs left #parrot
16:03 theory joined #parrot
16:06 dalek winxed: r847 | NotFound++ | trunk/winxedst1.winxed:
16:06 dalek winxed: indent generated pir except a few cases
16:06 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=847
16:06 dalek winxed: r848 | NotFound++ | trunk/ (3 files):
16:06 dalek winxed: update installable files
16:06 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=848
16:08 dukeleto ~~
16:08 * dukeleto is working on our GSoC app
16:08 dukeleto where is our ideas page this year?
16:08 dalek plumage: 109de1c | Whiteknight++ | / (2 files):
16:08 dalek plumage: add winxed_setup as a valid way of building software. Update the rosella.json to show winxed as the setup language and as a dependency. A complete end-to-end install of rosella without winxed already on the system works
16:09 dalek plumage: review: https://github.com/parrot/​plumage/commit/109de1c9a6
16:11 davidfetter left #parrot
16:12 whiteknight dukeleto: We don't have a dedicated page, as far as I know
16:12 whiteknight we can put one together
16:13 dukeleto whiteknight: we need one for our application
16:13 dukeleto whiteknight: i think mikehh++ worked on one, but maybe that was for GCI
16:13 dukeleto http://trac.parrot.org/parrot/wiki/GSoc2011
16:13 dukeleto there it is
16:13 dukeleto it definitely needs some meat added
16:13 dalek Rosella: f68d681 | Whiteknight++ | ports/plumage/rosella.json:
16:13 dalek Rosella: update plumage metadata file to show winxed as the build tool and as a dependency
16:13 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/f68d681e92
16:13 dukeleto whiteknight: can you brain dump some of your gsoc ideas onto that page?
16:14 benabik left #parrot
16:14 benabik joined #parrot
16:14 whiteknight dukeleto: I will work on it asap
16:16 dukeleto whiteknight++
16:16 dukeleto whiteknight: they won't look at our ideas page for a few days, but the quality of it is a large part of deciding if we get in
16:19 Patterner left #parrot
16:19 Psyche^ joined #parrot
16:19 Psyche^ is now known as Patterner
16:21 whiteknight okay
16:22 dukeleto whiteknight: would you mind emailing parrot-dev and asking/reminding others to help with that page?
16:22 whiteknight sure thing
16:22 cotto_work ~~
16:22 dukeleto whiteknight: i will be having a very hectic day. Trying to get this app done with so I don't forget
16:22 dukeleto cotto_work: werd up
16:23 dukeleto whiteknight: you were in gsoc 2008, right?
16:24 dukeleto whiteknight: i can't find a summary of which parrot projects existed in gsoc in 2008 and how many passed
16:24 dukeleto whiteknight: do you know how many other parrot gsoc projects there were that year?
16:33 cotto_work this looks familiar: http://eli.thegreenplace.net/2011/03/07/fr​om-c-to-ast-and-back-to-c-with-pycparser/
16:33 dukeleto cotto_work: i need some help with the gsoc app
16:34 dukeleto cotto_work: we need to beef up our ideas page
16:35 arnsholt cotto_work: I just came to this window to see if it had been mentioned already
16:35 arnsholt (Damn you =)
16:35 cotto_work arnsholt: you mean gsoc?
16:36 NotFound "Just parenthesizing both sides of each operator quickly gets ugly. So the code uses some heuristics to not parenthesize some nodes that surely have precedence higher than all binary operators"
16:36 whiteknight dukeleto: I really can't remember the other projects from that year
16:36 cotto_work arnsholt: nm
16:36 NotFound I'm amazed. Risking errors to avoid "ugly"?
16:37 NotFound I'm perfectly sure that the C compiler doesn't care about the ugliness of too much parens.
16:37 dalek tracwiki: v3 | dukeleto++ | GSoc2011
16:37 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSoc2011?version=3&action=diff
16:37 arnsholt I assumed he meant heuristics to add parens when they weren't strictly necessary
16:38 NotFound Who cares if they aren't strictly neccessary?
16:39 atrodo I'm pretty sure all C compilers encourage code ugliness as a rule of thumb
16:39 cotto_work NotFound: indeed
16:43 cotto_work dukeleto: I'll be thinking about gsoc projects.
16:44 cotto_work I'm sure there are a few.
16:44 M_o_C joined #parrot
16:48 * dukeleto just submitted the PaFo GSoC app
16:48 * dukeleto rests
16:48 cotto_work dukeleto++
16:48 whiteknight dukeleto++
16:48 lucian btw, would anyone want to mentor me with pynie?
16:48 whiteknight lucian: what is your idea for pynie?
16:48 lucian whiteknight: uh, write it so it works?
16:49 lucian right now it's a mess (albeit a tiny one)
16:49 lucian i'd like to rewrite the compiler in python and write as few core types as possible in winxed, probably
16:49 whiteknight lucian: okay, so are you writing pynie, or a new python compiler from the ground-up?
16:50 whiteknight I think there is preference for projects writing new code, as opposed to fixing/rewriting old code
16:50 lucian whiteknight: ideally reusing as much of pynie as possible, although allison mentioned some possible license issues
16:50 whiteknight what license issues?
16:50 lucian whiteknight: i didn't ask more at the time
16:50 whiteknight okay
16:50 lucian if you look in pynie's source, there's very little that's actually useful
16:51 lucian the compiler would be dumped entirely anyway, as it uses PCT
16:51 lucian the (few) types are written in PIR and barely similar to python's
16:51 PerlJam lucian: why continue to call it pynie?  :)
16:51 whiteknight right, that's my question
16:52 lucian i didn't think much about it
16:52 lucian sounds good enough? pynie-ng?
16:52 whiteknight it seems like the better course of action would be to start fresh. Write your own compiler
16:52 whiteknight maybe the name doesn't matter. you can call it whatever you want if you are writing it
16:53 dalek tracwiki: v1 | dukeleto++ | GSoCStudentApplicationTemplate
16:53 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GSoCStudent​ApplicationTemplate?version=1&action=diff
16:53 dalek tracwiki: v2 | dukeleto++ | GSoCStudentApplicationTemplate
16:53 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GSoCStudent​ApplicationTemplate?version=2&action=diff
16:53 Coke (preference for new code) not SFAIK.
16:53 lucian whiteknight: yeah, sure
16:53 lucian calling it pynie verbatim is confusing, you're right
16:54 lucian i'd rather call it just "python"
16:54 lucian PPython perhaps
16:54 PerlJam pypar
16:54 PerlJam parpy
16:54 PerlJam parpy sounds like harpy and I'm not sure that's the right mental image  ;)
16:54 lucian i'm fine with ParrotPython
16:55 lucian anyway, i'd like to reuse one of the existing python compilers, perhaps PyPy's
16:55 lucian retarget the backend to PIR (or even winxed?)
16:55 PerlJam lucian: you mean just the parser?
16:55 lucian PerlJam: parser, peephole optimiser
16:56 PerlJam lucian: sounds like a good plan.  Build on work that's gotten a good bit of the way where you want to go.
16:56 lucian PerlJam: sort of, yes
16:57 lucian it's times like this that i wish python had standard lower-level types
16:57 lucian so that i could write more python than winxed/other
16:58 PerlJam Have you ever read pypy's mission statement?
16:59 PerlJam http://codespeak.net/pypy/dist/pypy/do​c/architecture.html#mission-statement
16:59 PerlJam I wonder if anyone has put the theory to the test
16:59 lucian PerlJam: well, they have
17:00 PerlJam in any case, that may be a way to get buy-in from the rest of the python community  which is good for everybody I think
17:01 NotFound "p: we can write new translator back-ends to target different physical and virtual platforms."
17:02 lucian NotFound: writing a parrot backend for PyPy is perfectly possible
17:02 lucian but it'd be doubly-interpreted
17:02 whiteknight lucian: a PIR/PBC backend to Py
17:02 whiteknight Py would be a very good project
17:03 whiteknight of course, whether that project produces somethign which is generally useful is a different question
17:03 lucian whiteknight: Py?
17:03 whiteknight PyPy, I hit return in the middle
17:03 lucian i see
17:04 NotFound lucian: I'm a bit tired of perfectly possible things that nobody does.
17:04 lucian NotFound: it'd be pointless
17:04 plobsing is "Py" taken as a name?
17:06 whiteknight lucian: what about a bootrapping language? Like a Python subset which could later be used to write a "real" python compiler in python?
17:06 whiteknight think NQP, but with "P=Python"
17:06 lucian whiteknight: i don't think that's very useful
17:06 M_o_C left #parrot
17:07 lucian whiteknight: all it buys you is writing the core types in a more comfortable syntax
17:07 whiteknight lucian: I don't see why not. It would be a python-syntax language. Then we could use that to write full python compilers in a way that's familiar to python coders
17:07 whiteknight okay. Just a suggestion
17:07 lucian whiteknight: it'd be nice to have an equivalent to, say, cython, on parrot
17:07 whiteknight what do you mean by that?
17:08 PerlJam whiteknight: seems like pypy has already cracked that nut.  NQPython would just eliminate one bootstrapping step.
17:08 lucian well, cython is a C-ish language with python syntax
17:08 lucian PerlJam: RPython is not really usable outside writing VMs with the PyPy framework
17:09 PerlJam lucian: so you're saying they are failing that part of their mission?
17:09 lucian PerlJam: not at all
17:10 lucian PerlJam: they have two goals 1) framework for writing fast VMs easily 2) python implementation using the framework
17:10 PerlJam yeah, ignore what I just said.  I'm temporarily insane sometimes.
17:10 lucian RPython ends up being an implementation detail of the frameowork
17:10 lucian whiteknight: so ideally, using a more wrist-friendly language instead of winxed would be nice
17:10 PerlJam lucian: however, a parroty backend (in whatever form that takes) would be a boon to parrot.
17:10 lucian but especially for GSoC, i think it's just a time waste
17:10 lucian PerlJam: and not very useful at all
17:10 lucian in my opinion anyway
17:11 whiteknight that's a fair assessment
17:11 PerlJam lucian: not useful in the same sense that PyPy itself is useful or how Jython is useful, but it would be useful for Parrot in a PR sense if nothing else
17:12 PerlJam (especially given Parrot's history and the "piethon" contest)
17:12 lucian PerlJam: the way i see it, parrot's main selling point is being able to write a compiler for a dynamic language that targets it, without interpretation
17:12 lucian that's not possible with the JVM, at least not as it is now
17:12 whiteknight lucian: a working python compiler on Parrot, which compiled Python code to either PAST (like through NQP) or directly to PIR (like through Winxed) would be a very good project
17:13 whiteknight because once you're in PAST, we can convert down to PIR, or (if some of bacek's newer work gains traction) directly down to C or even LLVM ASM
17:13 lucian PerlJam: a PyPy parrot backend would generate an interpreter, which wouldn't be very useful
17:13 whiteknight so if that's the kind of project you want to work on, I would be very supportive of it
17:13 NotFound And for extra laziness, it can target winxed and let winxed take care or pir generation gory details.
17:13 whiteknight I doubt I would be a good mentor since I don't know any Python
17:14 lucian whiteknight: i'm highly skeptical of compiling dynamic languages to static targets
17:14 lucian NotFound: yep
17:14 lucian NotFound: also, if parrot moves away from pir
17:14 lucian (when?)
17:17 whiteknight Parrot can move away from PIR as soon as some other HLL starts outputting PBC directly
17:18 whiteknight I would love to see Winxed win that race, personally
17:18 whiteknight lucian: if your heart is not set on doing something pythonish, teaching winxed about the ways of love and PBC would be quite nice
17:19 cotto_work whiteknight: I'd love to see any language win that race.
17:20 whiteknight yes, it would be nice
17:20 NotFound whiteknight: I don't think it pays to start that way until we have a clearly defined path/api/language whatever.
17:20 jnthn If PAST => POST => PBC happens then a bunch of languages can win at once. :)
17:21 whiteknight I've added a task to output PBC from POST to the GSOC tasklist page
17:21 cotto_work jnthn: this is true
17:21 whiteknight If that happens, winxed could be updated to parse through PAST/POST if desired
17:21 whiteknight or, we could write compilers in winxed which output PAST
17:22 NotFound whiteknight: What's the difference?
17:22 whiteknight no real difference
17:22 sorear PIRate already outputs PBC from POST
17:23 lucian whiteknight: i like python and i'm selfish. i'd rather do python :)
17:23 whiteknight does it really? I wasn't aware of that
17:23 dukeleto whiteknight++ # awesome gsoc idea page email
17:23 NotFound Given that winxed is a compiler written in winxed, not much difference.
17:23 * dukeleto goes to lunch
17:23 whiteknight lucian: that's fine too. we just need to find a project which you like and which we can mentor, and then we all win
17:23 whiteknight brb food
17:23 cotto_work It seems we have ops for find_method and can, and a VTABLE slot for find_method and can.  The difference seems to be that both find_method thingies uses a cache.
17:24 dalek tracwiki: v4 | whiteknight++ | GSoc2011
17:24 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSoc2011?version=4&action=diff
17:24 cotto_work Do they serve significantly different purposes?
17:26 Coke I would be happy to mentor someone doing work on, say, tcl. ;)
17:27 NotFound I'm pretty sure is doable to generate pbc directly, but the I think probaility of that way get bitrotten because the rest of the world keeps using pir is still high.
17:27 sorear well, pbc format changes ~constantly
17:28 Coke yes, but an API to generate that format shouldn't.
17:28 cotto_work Coke: exactly
17:28 NotFound That's the point. Give me an api, and make imcc use it.
17:29 cotto_work If we have tests for the api in core, we can be pretty sure to keep it working.
17:31 plobsing nah, I'm with NotFound on this. unless the primary method of generating PBC (currently IMCC) uses the API, the rest is moot.
17:31 ambs joined #parrot
17:32 NotFound In fact, it already happened with the recent dynop handling changes.
17:32 NotFound We had tests, and test just get changed.
17:33 plobsing those tests got changed because the API didn't give enough abstraction
17:34 NotFound Yes, I didn't oppose because it was still highly experimental, but the point is still valid.
17:35 plobsing it is a trade-off we need to make between control and stability. if you want to control the minute details of bytecode, we cannot give any stability guarantee.
17:35 plobsing the problem is, there is an interesting set of programs that might use such an interface
17:36 NotFound Like, say, imcc ;)
17:36 plobsing or pbc_merge, or a register allocator, or ...
17:38 Coke yes, if there is an API, and you want it stable, we use the deprecation policy. if it's experimental, there's no problem. I don't see that this is a larger problem than any of our existing API issues.
17:39 plobsing the problem is that, in the past, the API did not give enough abstraction. arbitrarily mandating deprecation policy on very internal things like bytecode is a good way to see the policy violated or development stalled.
17:40 sorear Coke: don't you loathe the deprecation policy?
17:40 Coke sorear: not especially, no.
17:40 NotFound Coke: the only problem right now is that that API still doesn't exists, so I'll keep targeting PIR.
17:41 Coke NotFound: that is absolutely an issue. ;)
17:41 Coke I would label that highly experimental, then.
17:42 plobsing there's this expectation that "experimental" things stabilize over time
17:42 plobsing we need a different category "intentionally left perpetually unstable"
17:43 Coke "internal" is a fine name. I think that having bytecode format in that category was certainly not one of the original goals.
17:45 sorear I got the impression from Dan's blog that bytecode was supposed to be stable like JVM bytecode
17:45 sorear and that apps would be distributed in .pbc frmat
17:46 plobsing that's a nice goal, and I agree with that interpretation of Dan's blog. but bytecode has become a lot more complicated since then.
17:47 Coke yah. before 1.0, however, tests to enforce some sort of stability/cross platform testing were disabled (still disabled to this day), and we eventually got to the point where we said we'd provide a way to convert bytecode from release to release, and then we said... eh. this is hard. we'll get to it eventually.
17:47 cotto_work My hope is for M0 to be extremely stable once it's finalized.
17:47 cotto_work er, M0 bytecode
17:47 plobsing we have complicated PCC conventions, mandating the existance of a constant table, with users pushing us to allow more and more arbitrary object serialization.
17:48 plobsing M0 is a poor format for transmitting ops
17:48 plobsing s/ops/programs/
17:48 cotto_work plobsing: that's likely to be true.
17:49 plobsing cotto_work: so we'll still need something analogous to our current PBC format. M0 doesn't solve this problem.
17:53 benabik left #parrot
17:56 ShaneC left #parrot
17:57 Coke plenty to fix in the meantime. What about #1886? ;)
17:58 Coke I think it's interesting that the first eval works fine.
18:02 theory left #parrot
18:04 davidfetter joined #parrot
18:14 theory joined #parrot
18:18 ShaneC joined #parrot
18:20 sorear Would it be possible to leverage opsc_full_parse to write a .h to .nci/.pir converter?
18:20 sorear Would this be a good GSoC size task?
18:21 cotto_work sorear: you'd have to be a lot smarter about dealing with C's types.
18:21 cotto_work I've been meaning to ask bacek about his thoughts on splitting out the C parsing bits into a separate hll.
18:23 dalek Heuristic branch merge: pushed 42 commits to nqp/ctmo by jnthn
18:23 sorear Well if it were easy it wouldn't be any good for a possible soc suggestion
18:23 cotto_work There was a previous project that attempted to parse headers and figure out function signatures.  I don't recall what happened to it.
18:24 plobsing left #parrot
18:30 bacek left #parrot
18:30 ShaneC1 joined #parrot
18:34 ShaneC left #parrot
18:36 ShaneC joined #parrot
18:37 Andy joined #parrot
18:38 ShaneC1 left #parrot
18:47 ShaneC1 joined #parrot
18:49 ShaneC left #parrot
18:49 whiteknight cotto_work: in TT #2042, I don't want to get rid of the "can" PIR op, I just want to get rid of the VTABLE
18:50 whiteknight the op can stay, and can actually avoid the extra level of indirection
18:51 whiteknight and then there's basically zero burden on our users
18:53 whiteknight except for the rare breed of people who are overriding VTABLE_can at the C level
18:53 cotto_work I like having fewer ops and VTABLE slots, but making life easier for users is nice too.  I could go either way.
18:54 whiteknight we can't really get rid of the "can" op, because find_method throws an exception on method not found
18:54 whiteknight can returns a bool, which is faster and friendlier
18:54 whiteknight if find_method were modified to return a null, we could talk about removing the "can" op
18:55 whiteknight but until then, I think we can live just fine without VTABLE_can
18:55 cotto_work wfm
18:57 plobsing joined #parrot
18:57 dmalcolm joined #parrot
19:03 dalek parrot: 276483b | petdance++ | / (2 files):
19:03 dalek parrot: removed unnecessary interpreters from str_rep_compatible and Parrot_str_rep_compatible, and made both of them PARROT_PURE_FUNCTIONs.
19:03 dalek parrot: review: https://github.com/parrot/parrot/commit/276483b9a2
19:05 mj41 Hmm ... logged in as mj41 - http://trac.parrot.org/parrot/wiki/GSoc2011 ... Where is "edit page" button?
19:06 Andy Are you sure you're logged in?
19:06 Andy trac.parrot.org gives me hassles all the time.
19:07 mj41 # logged in as mj41 # Logout # Preferences
19:07 Coke you may not have wiki edit privs. moment.
19:08 Coke Andy: but mostly only you, as I recall.
19:08 Coke mj41 does not seem to have ANY permissions.
19:08 silug joined #parrot
19:09 cotto_work easy fix
19:09 Coke The user mj41 has been added to the group developer.
19:09 Coke that'll probably do.
19:10 mj41 great, thanks
19:12 Andy Coke: could be.  I just know that if I have probs on trac, first thing I check is that I am actually logged in.
19:15 bacek joined #parrot
19:15 lucian sorear: cotto_work: i'm pretty sure you need a C compiler (parser) to generate full, correct introspection data
19:16 sorear lucian: we have a C compiler now.
19:16 lucian sorear: right. and it doesn't parse headers?
19:17 sorear lucian: it parses headers fine iiuc.  I'm proposing changing the backend, so that instead of C, it produces NCI declarations for included function prototypes.
19:17 lucian right
19:18 sorear bacek++ is working on a LLVM backend for our C compiler
19:19 lucian hmm. why does parrot have a C compiler?
19:21 cotto_work lucian: it only understands enough C to parse our .ops files
19:21 lucian cotto_work: i see. it seems very odd to me
19:21 cotto_work The idea is to move away from mangling C with regexes and give opsc an understand of what it's doing.
19:23 ShaneC1 left #parrot
19:24 whiteknight but, let's not throw the mangling out wholesale. A little bit of mangling can be a great stress release
19:24 lucian cotto_work: it seems to me that you might as well design a slightly nicer C and use that everywhere
19:26 ShaneC1 joined #parrot
19:26 Coke lucian: right now we're generating C. bacek is working on generating llvm.
19:27 lucian Coke: yeah, i got that. what i mean is that if for ops it was found to be easier to extend C, then why not do that for the whole of parrot?
19:27 lucian like the way Qt extends C++ with foreach
19:27 sorear lucian: that's basically what M0 is
19:27 lucian sorear: i see. so M0 is supposed to be a nicer C that translates to regular C?
19:28 dalek nqp/ctmo: 1516bd2 | jonathan++ | / (2 files):
19:28 dalek nqp/ctmo: Add a Serialization Context PMC. Just bare bones for now.
19:28 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/1516bd229c
19:28 dalek nqp/ctmo: 89c34b4 | jonathan++ | src/ (6 files):
19:28 dalek nqp/ctmo: Bring the work on compile time meta-object support so far in line with my latest thinking on how stuff will work. Quite a few little changes.
19:28 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/89c34b4167
19:28 dalek nqp/ctmo: 10e90bd | jonathan++ | src/ (2 files):
19:28 dalek nqp/ctmo: Put in place code to do fixup or deserialization. No actions to actually do yet, but that's the infrastructure. Back out setting up the meta-objects in the deserialization just yet - not quite ready for it.
19:28 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/10e90bdac8
19:29 sorear lucian: I'm not sure we've gotten quite that far yet
19:29 lucian sorear: right. so it's still being designed?
19:29 dalek tracwiki: v5 | mj41++ | GSoc2011
19:29 dalek tracwiki: TapTinder
19:29 dalek tracwiki: http://trac.parrot.org/parrot/wiki/​GSoc2011?version=5&action=diff
19:29 sorear lucian: it seems like it's going to be vaguely like C, but running stackless and with native access to PMCs
19:29 plobsing left #parrot
19:30 cotto_work It won't be especially like C.  It just has to have equivalent expressiveness
19:31 lucian i may have said this some other time, i like aspects of Cyclone, ooc and Rust
19:32 lucian Cyclone's a bit dead, but its design is very interesting
19:32 lucian especially when it comes to pointers (they get bounds checks)
19:35 atrodo cotto_work> What do you think the difficulty level is to make bacek's opsc emit lasm?
19:36 sorear atrodo: bacek wrote a Parrot binding to the LLVM API yesterday.
19:37 atrodo sorear> I saw, which between that and my recent hacking on lorito makes me ask the question
19:37 sorear if we have the LLVM API, why would we use lasm?
19:40 atrodo I'm thinking more of being able to turn the ops into lasm chunks for my lorito prototype
19:42 plobsing joined #parrot
19:43 plobsing_ joined #parrot
19:44 plobsing_ left #parrot
19:49 benabik joined #parrot
19:51 lucian left #parrot
19:51 ShaneC1 left #parrot
19:52 ShaneC joined #parrot
19:54 bacek Good morning, humans
19:54 benabik Afternoon, bacek.
19:54 sorear hello bacek
19:54 bacek aloha, benabik
19:54 bacek aloha, sorear
19:58 lucian joined #parrot
20:02 dalek parrot/opsc_llvm: 8c47cf7 | bacek++ | runtime/parrot/library/LLVM (6 files):
20:02 dalek parrot/opsc_llvm: Drop prefix LLVM from LLVM::F keys. We don't have to repeat it many times
20:02 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/8c47cf7d59
20:04 lucian_ joined #parrot
20:04 lucian left #parrot
20:11 ShaneC1 joined #parrot
20:13 ShaneC left #parrot
20:13 dalek parrot: c6a5121 | petdance++ | src/dynpmc/file.pmc:
20:13 dalek parrot: flagging unused args
20:13 dalek parrot: review: https://github.com/parrot/parrot/commit/c6a5121fbc
20:14 lucian_ left #parrot
20:16 ShaneC joined #parrot
20:20 lucian joined #parrot
20:21 ShaneC1 left #parrot
20:31 dalek parrot/opsc_llvm: 6328edc | bacek++ | runtime/parrot/library/LLVM.pm:
20:31 dalek parrot/opsc_llvm: Fix function signatures.
20:31 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/6328edc47a
20:31 dalek parrot/opsc_llvm: 650f438 | bacek++ | runtime/parrot/library/LLVM/Module.pm:
20:31 dalek parrot/opsc_llvm: Add more methods to Module.
20:31 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/650f4385af
20:31 dalek parrot/opsc_llvm: d1e4ac3 | bacek++ | runtime/parrot/library/LLVM (4 files):
20:31 dalek parrot/opsc_llvm: Rename LLVM::convert_to_struct into to_array. For aesthetic reasons
20:31 dalek parrot/opsc_llvm: mostly.
20:31 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/d1e4ac3661
20:40 ShaneC1 joined #parrot
20:41 dalek parrot/opsc_llvm: 89cee3d | bacek++ | runtime/parrot/library/ (3 files):
20:41 dalek parrot/opsc_llvm: Add stub for LLVM::Context
20:41 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/89cee3dcf9
20:41 dalek parrot/opsc_llvm: 64f2895 | bacek++ | runtime/parrot/library/LLVM/Context.pm:
20:41 dalek parrot/opsc_llvm: Add some guts to LLVM::Context
20:41 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/64f2895716
20:41 dalek parrot/opsc_llvm: 1c3e342 | bacek++ | runtime/parrot/library/LLVM/Context.pm:
20:41 dalek parrot/opsc_llvm: Add more stuff to LLVM::Context
20:41 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/1c3e342b55
20:42 plobsing bacek: be mindful that you are using many deprecated NCI things.
20:42 plobsing managedstruct, 't' signature type, etc...
20:43 ShaneC left #parrot
20:47 ambs left #parrot
20:52 plobsing left #parrot
20:53 Andy Why do we allow the memory allocation stuff in alloc_memory.c to handle a size = 0?
20:53 benabik left #parrot
20:53 bacek msg plobsing Feel free to jump on opsc_llvm branch and replace deprecated stuff with new shiny stuff.
20:53 aloha OK. I'll deliver the message.
20:55 plobsing_ joined #parrot
20:57 plobsing_ Andy: we allow for zero-sized allocations because we make them. a lot.
20:57 ShaneC joined #parrot
20:58 Coke It seems crazy to allocate no memory repeatedly, but what do I know.
20:58 plobsing_ Coke: it is useful for thinigs that will get realloc()ed
20:59 plobsing_ if you want to eliminate these allocations, be my guest. it is easy enough to find them by removing the zero-alloc handling and using a libc that returns NULL from malloc(0)
21:00 Andy whyzat plobsing_ ?
21:00 bacek plobsing_ Feel free to jump on opsc_llvm branch and replace deprecated stuff with new shiny stuff.
21:00 ShaneC1 left #parrot
21:00 plobsing_ bacek: I'm currently trying to remove the eligible NCI signatures so people stop using them
21:01 bacek plobsing_, what is replacement for "t"?
21:01 plobsing_ bacek: see http://trac.parrot.org/parrot/ticket/1931
21:01 plobsing_ there is no direct replacement. I'm removing the "sugar" from NCI. no more magic stuff.
21:02 bacek plobsing_, hang on. How I can call "foo(char*)" without such sugar???
21:02 bacek from PIR/NQP
21:02 plobsing_ pass a buffer of chars
21:02 plobsing_ a string is not a buffer of chars
21:02 plobsing_ you can provide an independant sugar layer should you so desire
21:03 NotFound plobsing_: a buffer of chars can be null?
21:03 plobsing_ this is what zavolaj does
21:03 plobsing_ NotFound: it can if you want it to be
21:04 bacek ByteBuffer PMC doesn't provide .get_pointer
21:04 plobsing_ if you want a direct analog, NCI Parrot_str_to_cstring()
21:04 bacek And zavolaj is implemented in C
21:04 plobsing_ in C? really?
21:04 bacek And I definitely don't want to write C for LLVM.
21:04 bacek aloha, zavolaj?
21:04 aloha bacek: Dunno.
21:04 tadzik that's in PErl 6
21:05 tadzik https://github.com/jnthn/zavolaj​/blob/master/lib/NativeCall.pm6
21:06 bacek aloha, zavaloaj is  https://github.com/jnthn/zavolaj
21:06 aloha bacek: Okay.
21:06 bacek plobsing_, line 63 in  https://github.com/jnthn/zavolaj​/blob/master/lib/NativeCall.pm6
21:06 plobsing_ bacek: it does that now. but the fact that it is a sugar layer on top of NCI means that things using it can be transparently switched
21:06 Andy plobsing_: Wy do we make 0-byte allocations?
21:07 Andy And right now, we only PANIC if the malloc fails and it was trying to get more than 0 bytes, but that seems wrong.
21:07 plobsing_ Andy: malloc returning NULL isn't a failure
21:07 Andy I think we ought to panic no matter how many bytes we fail to malloc.
21:07 bacek plobsing_, whatever. We have this layer now. I don't want to write new layer for no reason.
21:08 Andy plobsing_: If we malloc(N) where N>0, and malloc() returns NULL, we panic and die.  That sounds like failure, right?
21:08 plobsing_ yes. but when N==0, it is not necessarily a failure.
21:08 Andy Why?
21:08 plobsing_ because NULL is a pointer to at least 0 bytes of r/w data
21:09 Andy But dereferencing it is always fatal.
21:09 plobsing_ dereferencing it is equivalent to looking at the first allocated byte (at least). that is not the contract requested.
21:10 Andy That's not my understnading.  My understanding is that looking at NULL for any reason is fatal.
21:10 plobsing_ Andy: your understanding and my manpages understanding differ.
21:10 Andy what are you looking at?
21:11 NotFound Andy: that is Medusa.
21:11 Andy NotFound: I don't understand.
21:11 dalek parrot/opsc_llvm: 47027d4 | bacek++ | runtime/parrot/library/LLVM/Type.pm:
21:11 dalek parrot/opsc_llvm: Add more Types.
21:11 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/47027d4dfd
21:11 NotFound Andy: NM, bad joke.
21:12 plobsing_ http://pubs.opengroup.org/onlinepu​bs/009695399/functions/malloc.html
21:13 * lucian is reading http://trac.parrot.org/parrot/wiki/Lorito
21:13 Andy So you're looking at "If the size of the space requested is 0, the behavior is implementation-defined: the value returned shall be either a null pointer or a unique pointer.", right?
21:13 plobsing_ yep. that's the line. I interpret that to mean "malloc(0) can return NULL"
21:14 Andy Yes, it can.
21:14 Andy But that pointer is not usable as anything.
21:14 Andy You can't dereference NULL.
21:14 whiteknight and since parrot is a platform-abstracting VM, we should have a single codified behavior there
21:14 plobsing_ you can use a pointer without dereferencing it
21:14 Andy (and expect to live)
21:14 Andy use it how?
21:14 plobsing_ you can pass it to realloc for example
21:15 Andy But I don't think that's valid, either.
21:15 Andy Because realloc() relies on dereferencing
21:16 plobsing_ Andy: shall I point you to the appropriate opengroup spec page for that too?
21:16 Andy eh, no not
21:16 Andy plobsing_: Come on, don't talk down to me.
21:16 Andy Where is some place that we actually use this malloc-a-dummy-area-with-size-0?
21:17 lucian i'd really expect NULL malloc to do exit(1)
21:17 cotto_work atrodo: I didn't mean to ignore you.  I think it's within the realm of possibility but there isn't much point unless the target language can interact with the C parts of parrot (for now)
21:17 Andy lucian: That's what I'd expect, too.
21:17 lucian the only way parrot can protect from that is with the gc
21:18 lucian but even that is overkill
21:18 lucian exit(1) is the default sane behaviour
21:19 plobsing_ Andy: I'm sorry if I'm coming off as patronizing. But you've been spouting *opinions* that run counter to the documented behaviour.
21:19 Andy So talk to me like a person.
21:19 Andy People are allowed to be wrong.
21:19 NotFound realloc accepts NULL
21:19 Andy Yes, it does.
21:19 Andy I see that.
21:20 Andy I'm still wondering where we actually malloc pointer of size 0.
21:20 Andy Because that behavior seems fraught with peril.
21:20 NotFound In fact, you don't need malloc or free, realloc can do all teh job.
21:21 * cotto_work experiments
21:21 dalek parrot: b838b2c | petdance++ | / (2 files):
21:21 dalek parrot: mem_sys_allocate() cannot return NULL, so flag it as such
21:21 dalek parrot: review: https://github.com/parrot/parrot/commit/b838b2cb83
21:21 dalek parrot: 626b12c | petdance++ | / (2 files):
21:21 dalek parrot: mem_sys_allocate actually CAN return NULL.
21:21 dalek parrot: review: https://github.com/parrot/parrot/commit/626b12cce6
21:22 plobsing_ I'm not going to defend our usage of malloc(0). But we do it. And it isn't really a problem so long as your NULL-guards on malloc handle this case properly.
21:22 Andy I'm not asking you to defend it.  I'm trying to understand it.
21:23 plobsing_ so the easiest solution is to fix the guards, rather than running through a miriad of PANICs
21:23 Andy because there is code throughout the codebase that expects that mem_sys_allocate() returns non-NULL.
21:23 NotFound Note that malloc(0) may not return NULL, the result is platform dependant.
21:23 Andy NotFound: Yes, understood.
21:23 Andy Specifically which guards do you mean, plobsing_ ?
21:24 plobsing_ the ones in alloc_memory.c
21:24 Andy How do you see them as broken?
21:24 NotFound We don't need to do what malloc does if we don't want, we can check for zero and return a special purpose value.
21:24 plobsing_ they aren't right now. they accept NULL on zero-sized allocations. they were broken before.
21:24 Andy When we allocate 0-byte buffers, do we know that we are doing so?
21:25 Andy Could we create a malloc_size_zero() that can return NULL, so that all the other ones can know that they can NOT get a NULL back?
21:26 plobsing_ Andy: not sure. I suggest you track these down with a libc that has this behaviour. Minix libc does this. I suspect some small-footprint linux libc implementations (eg uclibc) do this as well.
21:26 NotFound I think that if we want an allocation function that doesn't accept zero the appropiate behavior is throwing, better than returning NULL.
21:27 atrodo cotto_work> no problem.  I was kind of suspecting that I'd have those kind of issues
21:27 Andy plobsing_: You could help by giving me background on where we do these zero-size mallocs.
21:27 plobsing_ Andy: I don't have that information available to me at the moment.
21:27 Andy Give me a clue.
21:27 Andy In the GC?
21:27 atrodo cotto_work> Any guess on some of the variations of interaction issues?
21:27 Andy Somewhere else?
21:27 cotto_work atrodo: that's the blocker for M0 too.  Once it has a workable set of primitives for ffi, we can start hammering out the final spec.
21:27 plobsing_ Andy: I cannot recall.
21:28 cotto_work atrodo: can you clarify what you mean?
21:29 cotto_work we don't seem to have any 0-sized allocations while running ops2c --core
21:31 atrodo cotto_work> I'm trying to form concrete examples in my head of some of the issues I would run into
21:31 Andy I'm sprinkling asserts throughout src/gc/alloc_memory.c
21:31 Andy what's the make target for the extra-heavy-duty test suite?
21:32 Tene fulltest?
21:33 mj41 atrodo: Hi. Any news about parrot-meta repository? :-)
21:33 cotto_work Andy: I suspect that you might not find too many uses of 0-sized mallocs, and that if you find any they'll be reasonable to excise.
21:34 Andy That's what I'm tracking down.
21:34 atrodo mj41> On my list :)
21:34 Andy because if we can make all the alloc_memory.c functions PARROT_CANNOT_RETURN_NULL, all of a sudden we have a world of static error checking open up to us.
21:34 atrodo mj41> I wanted to do it last night, but things came up. so I'm aiming to do something tonight
21:36 mj41 atrodo: ok, on this month todo list is good enough :-)
21:36 whiteknight left #parrot
21:40 cotto_work Andy: awesome.
21:41 Andy Specifically, splint tracks what can and can't be NULL.
21:42 Andy and if our core allocation functions can be declared PARROT_CANNOT_RETURN_NULL, then all that can propagate up.
21:42 Andy My make test runs without ever calling a 0-size allocation.
21:43 Andy plobsing_: suggestions on where I might stress it out more?
21:43 plobsing_ Andy: I ran into zero-sized allocations in the miniparrot step on minix.
21:44 plobsing_ so I'm not sure how you successfully build and test without hitting even one instance
21:44 Andy Running it you mean?  Or in source code?
21:45 plobsing_ running. yes. I got clued in by a NULL-triggered PANIC(), which means execution hit a case.
21:45 Andy What did you run?
21:45 plobsing_ make
21:45 lucian_ joined #parrot
21:45 Andy running a distclean
21:46 lucian left #parrot
21:50 Andy Make has no complaints.  Do you know what function it got the NULL back from?
21:50 cotto_work the build worked fine for me too
21:51 plobsing_ Andy: no. and I do not have my minix VM availalble ATM.
21:53 ShaneC1 joined #parrot
21:55 Andy Maybe it's one of the gc/gc*.c fies
21:55 ShaneC left #parrot
22:06 Andy ta-da
22:06 particle why don't you change the decorator to PARROT_CANNOT_RETURN_NULL and see where you get an assert error?
22:06 Andy particle: That's not what PARROT_CANNOT_RETURN_NULL does.
22:07 Andy and I have run across an assertion anyway.
22:07 particle i'm jumping into this discussion very late and without a lot of context. sorry for the distraction.
22:07 Andy I think what I'm going to do is make the mem_sys_* functions in src/gc/alloc_memory.c disallow size = 0
22:07 Andy and guarantee they return non-NULL
22:08 Andy and let the mallocs in src/gc/gc*.c do what they do now.
22:08 Andy Because the GC stuff is dark and arcane and not used by normal humans anyway.
22:11 Andy All the GC API stuff like Parrot_gc_allocate_fixed_size_storage is flagged as PARROT_CANNOT_RETURN_NULL anyway.
22:12 Andy And the GC*.c code are the only ones that would be doing anything with the 0-size mallocing anyway.
22:16 dalek winxed: r849 | NotFound++ | trunk/winxedst1.winxed:
22:16 dalek winxed: clean and improve indent of generated pir and op emiting
22:17 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=849
22:22 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#11725) fulltest) at 3_1_0-744-g626b12c - Ubuntu 10.10 i386 (g++-4.5 with --optimize)
22:23 mikehh again smolder #11724 failed, had to re-send and #11725 uploaded ok
22:24 mikehh i.e. failed to finish uploading
22:26 dalek parrot/opsc_llvm: 156d40e | bacek++ | config/gen/makefiles/root.in:
22:26 dalek parrot/opsc_llvm: Add LLVM to default build
22:26 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/156d40e4ed
22:26 mikehh see TT #2039
22:30 ShaneC joined #parrot
22:34 ShaneC1 left #parrot
22:34 lucian joined #parrot
22:35 dalek nqp/ctmo: 06a391d | jonathan++ | / (6 files):
22:35 dalek nqp/ctmo: Get setting loading working from pre-compiled code. This was a tad twisted to do, but should work nicely now.
22:35 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/06a391d238
22:37 lucian_ left #parrot
22:48 slavorg left #parrot
22:48 slavorg joined #parrot
22:57 cognominal left #parrot
22:59 rurban_ joined #parrot
22:59 bacek_at_work jnthn, ping
23:00 lucian left #parrot
23:01 rurban left #parrot
23:01 rurban_ is now known as rurban
23:01 hercynium left #parrot
23:08 bacek_at_work jnthn, unping
23:19 dalek parrot/opsc_llvm: e2e9fa6 | bacek++ | runtime/parrot/library/LLVM/Function.pm:
23:19 dalek parrot/opsc_llvm: Don't generate name in Function.append_basic_block. Expose Function.entry_block.
23:19 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/e2e9fa64a4
23:19 dalek parrot/opsc_llvm: c9ae6e7 | bacek++ | src/call/args.c:
23:19 dalek parrot/opsc_llvm: Ugly hack of parsing PCC signatures to support Object.get_pointer
23:19 dalek parrot/opsc_llvm: review: https://github.com/parrot/parrot/commit/c9ae6e77e3
23:20 plobsing_ left #parrot
23:34 lucian joined #parrot
23:45 lucian_ joined #parrot
23:49 lucian left #parrot

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

Parrot | source cross referenced