Parrot 3.1.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Get GSoC ideas on wiki. Merge/review tewk/select. Evaluate attribute_defs, rip out in branch
Set by moderator on 1 March 2011.
whiteknight there are a lot of languages that could use very similar logic for tokenizing 00:00
NotFound I'm not sure, maybe something based in ohm-eta will be more appropiate for general purpose usage. 00:01
plobsing Ωη supports hybrid tokenfull/tokenless parsing strategy. it could easily assimilate a foreign tokenizer. 00:02
NotFound Oh, you mean just the tokenizer.
plobsing tokenization is something that pure RecDescent/PEG does rather inefficiently 00:03
whiteknight NotFound: yeah, just the tokenizer
NotFound: I've had a few places where I wish I was able to parse strings more easily
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.
whiteknight NotFound: right, but for the most part, being able to separate out whitespace from words/identifiers, and operators is very important
plus, for any behavior we wanted changed, we could subclass
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
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.
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
NotFound No problem, then.
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.
cotto aloha, concurrency primitives paper is research.microsoft.com/en-us/um/peo.../index.htm
I got that impression.
plobsing so what are you having trouble understanding? 00:10
cotto the notation used to define the semantics of the operations 00:12
whiteknight I always hate the notations used in CS papers 00:14
cotto neither humans nor machines can understand it
plobsing that's not Haskell, that's CS mumbo jumbo
cotto It's perfect.
I know, but it's still pretty undecipherable. 00:15
It seems pretty important to understand what the primitives they're proposing are,
.
NotFound "We don't discriminate neither humans or machines."
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
NotFound cotto: maybe they plan to explain all in the "Director's cut" edition of te paper. 00:17
In the "extras" dvd. 00:18
plobsing suspects this is the "extend" portion of some "embrace and extend" strategy out of MSR.
not sure what they're embracing 00:19
NotFound A bear. 00:20
cotto You know it's good with sentences like "The term M is, as usual, the current monadic term under evaluation." 00:22
NotFound That reminds me in some way a joke about a variable named LancelotFavouriteColor... 00:23
cotto goes ... place 00:27
NotFound Here is: mindprod.com/jgloss/unmainnaming.html
"Use constant names like LancelotsFavouriteColour instead of blue and assign it hex value of 0x0204FB." 00:28
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?
sorear dusts off his 2007 Haskell Academia Hat
NotFound whiteknight: just indent the code inside subs, or something more elaborate? 00:45
whiteknight just the code inside subs would be best
well, not "best", but it would be very nice
NotFound Probably esay, but I need to take a look at some corner cases. 00:46
whiteknight it doesn't need to be perfect
NotFound I'll take a look tomorrow.
whiteknight plobsing has informed me that IMCC's error reporting is absolutely stupid if the code isn't indented
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.
NotFound IMCC always amazes me.
whiteknight plobsing: right, but smarter indenting would be nice for readability
NotFound Nice catch, it will be highly useful.
plobsing whiteknight: I find the PIR generated by Winxed to be quite readable already.
whiteknight plobsing: yes, it's nice. Some whitespace would only make it nicer 00:48
it's far nicer than reading the output of NQP or some other HLL
NotFound That problem applies also to .annotate directives? 00:50
plobsing .annotate shouldn't be affected 00:51
it only affects things where the PIR file line number matter
sorear cotto? 00:52
NotFound Good to know. I'll work on it tomorrow, going to be dnow. 00:53
01:27 lopaway is now known as lopnor 01:34 jrt4 joined 01:43 kid51 joined
dalek TT #1655 closed by plobsing++: [DEPRECATED] logical vtables 01:47
TT #1655: trac.parrot.org/parrot/ticket/1655
kid51 plobsing: Thanks for looking into that old ticket. 01:49
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:00
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
you know, any of the information that would help me actually find the source of the error
Coke seen sorear? 02:06
aloha sorear was last seen in #perl6 26 mins 19 seconds ago saying "OK".
whiteknight although to it's credit, the NQP files actually give me IMCC line numbers
sorear Coke: hi 02:07
Coke aloha, no, partcl is github.com/partcl/partcl-nqp - partcl-old is github.com/partcl/partcl
aloha Coke: Okay.
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?"
aloha OK. I'll deliver the message.
Coke sorear: I'm on the board of the grant committee and know some people on the board. 02:09
(the main board)
sorear whiteknight: You're a committer. What, or who, is stopping you from hacking Parrot to give good error messages?
Coke: who can delete data from the TPF wiki history?
Coke: and who can deactivate accounts? 02:10
Coke: I recently had to disable the #perl6 announcerbot because the TPF wiki is getting spammed hard
kid51 sorear: Could you contact the Perl Foundation board directly? 02:11
sorear kid51: I probably could, but I don't like cold calls 02:12
Coke which wiki?
www.perlfoundation.org/perl6/index.cgi ?
kid51 sorear: I have found Karen Pauley, TPF president, to be very responsive to me.
As have the perl.org sysadmins (though they might not have anything to do with perlfoundation.org) 02:13
sorear Coke: yes
Coke sorear: the last update I see is on feb 23rd. 02:15
Can you point me at a spammy page? (I can see if I have admin privs)
dalek sella: ce78029 | Whiteknight++ | src/ (2 files):
some fixes identified when I tried to run the PLA test suite
 02:16
Coke or I could check on a regular page. Nope.
so, kid51++'s suggestion is what I would do - ping karen. feel free to mention my name.
sorear Coke: www.perlfoundation.org/perl6/index.cgi?1 was previously spammed 02:17
notice the 102 revisions, by the same person, none useful 02:18
but I guess his strategy involved moving on
at one point there were 100s of attachments of HTML files with pill links
someone deleted them
02:19 whiteknight left
sorear the recent changes list being empty is pretty wtfy 02:19
since I've seen changes happening 02:20
Coke so it looks like someone is cleaning things up.
but feel free to ping karen and ask who the admin is.
need her email?
kid51 karen at perlfoundation dot org -- as the website says 02:21
You should probably also write to webmaster at perlfoundation dot org (Casey West)
(and, while you're at it, mention that www.perlfoundation.org's home page is very out of date ;-) ) 02:22
Coke I wouldn't combine that, no. 02:24
kid51 This page, however, looks more actively maintained: news.perlfoundation.org/ 02:27
02:27 lopnor is now known as lopaway
kid51 afk 02:28
dalek p/slp: 2e788f6 | jonathan++ | src/ (7 files):
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
p/slp: eb5f068 | jonathan++ | src/NQP/ (2 files):
Register NQP as just NQP, not NQP-rx.
p/slp: 4c71035 | jonathan++ | t/hll/0 (2 files):
Update a couple of tests to track NQP moving to its own HLL namespace.
p/slp: 3cc2814 | jonathan++ | src/stage0/ (5 files):
Update bootstrap.
p/slp: d3f4b23 | jonathan++ | / (15 files):
Merge branch 'master' into slp
p/slp: a630c2b | jonathan++ | src/pmc/nqplexinfo.pmc:
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.
p/slp: e08aaf1 | jonathan++ | src/pmc/nqplex (2 files):
Fix some marking issues.
p/slp: 5ad5467 | jonathan++ | src/ (2 files):
Ensure we end up with runtime lexpads being NQPLexPad.
p/slp: 35ee39a | jonathan++ | src/stage0/ (2 files):
Fiddle with the bootstrap code so things build with the new lexpad classes.
p/slp: a694c40 | jonathan++ | src/NQP/Actions.pm:
Make sure lexpads are created of the correct type in compiled code.
p/slp: dd13f30 | jonathan++ | src/pmc/nqplex (2 files):
Ensure that NQPLexPad can cope with a Parrot LexInfo as well as an NQPLexInfo.
rtcl-nqp: 5b1f6fa | coke++ | src/Partcl/Grammar.pm:
hope these are taken in order, fix octal parse.
 02:44
p: d3f4b23 | jonathan++ | / (15 files):
Merge branch 'master' into slp
 02:49
p: a630c2b | jonathan++ | src/pmc/nqplexinfo.pmc:
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.
p: e08aaf1 | jonathan++ | src/pmc/nqplex (2 files):
Fix some marking issues.
p: 5ad5467 | jonathan++ | src/ (2 files):
Ensure we end up with runtime lexpads being NQPLexPad.
p: 35ee39a | jonathan++ | src/stage0/ (2 files):
Fiddle with the bootstrap code so things build with the new lexpad classes.
p: a694c40 | jonathan++ | src/NQP/Actions.pm:
Make sure lexpads are created of the correct type in compiled code.
p: dd13f30 | jonathan++ | src/pmc/nqplex (2 files):
Ensure that NQPLexPad can cope with a Parrot LexInfo as well as an NQPLexInfo.
p: bb9ccfe | jonathan++ | src/stage0/ (4 files):
Re-bootstrap with the static lexpad support.
Coke wonders why "bit_ops" doesn't seem to be loading anymore. 02:53
How can I get more diagnostics from: 02:55
$ ./partcl error.t
error:imcc:syntax error, unexpected PREG, expecting '(' ('$P20') in file 'EVAL_2' line 12
(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. 02:56
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:03
huh. .loadlib seems to have been broken at some point. 03:12
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
Coke msg whiteknight check out my .loadlib IMCC issue at irclog.perlgeek.de/parrot/2011-03-07#i_3365878 03:14
aloha OK. I'll deliver the message.
03:23 Andy joined
Coke Andy: hio. 03:26
Andy hiya
Sunday night Parrot code cleanup!
dalek rtcl-nqp: 0d9a0fa | coke++ | src/Partcl.pir:
workaround .loadlib bug
 03:31
rtcl-nqp: 3977a9d | coke++ | t/cmd_expr.t:
un-TODO passing test.
rrot: 8b8b3b9 | petdance++ | src/nci/ (2 files):
consting, removing unused vars
 03:49
03:55 hudnix left
Coke weird. TT #1886 works if I do [expr $i + 1] instead of [expr $i+1] 04:00
dalek rrot: 776e9da | petdance++ | src/pmc/nci.pmc:
consting and removing unused var
 04:01
rrot: e7d3b58 | petdance++ | / (2 files):
re-headerized
 04:02
04:05 sigue left 04:10 sigue joined
dalek rrot: 0aaee88 | petdance++ | src/string/encoding/ (5 files):
shimming up unused interps
 04:17
ttbot Parrot 0aaee882 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/50765 04:19
dalek rrot: 3d0d837 | petdance++ | src/string/encoding/latin1.c:
fixed a mistakenly shimmed interp
ttbot Parrot 0aaee882 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/50766 04:20
Parrot 0aaee882 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/50767 04:21
cotto ~~~~ 04:23
Coke cotto: ~~ 04:24
I am down to one failing test in partcl-nqp now as well.
sorear hi cotto
I saw you were having trouble with Simon-speak earlier
may I help? 04:25
cotto Coke, I saw. That's exciting.
sorear, you may try
sorear used to be a Haskell person 04:26
cotto I aspire to know enough to be dangerous. 04:27
sorear so uh... in that paper, they're breaking down the existing functions of the threaded runtime into primitives 04:29
cotto right
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
that seems to be most of the point
cotto my academic-speak to English compiler segfaults on that paper
sorear so they've added continuations (to support scheduling), and a timer callback
the interesting part is "Figure 2" 04:32
it's nice that they broke it down like that.
cotto well, that and all the ones after
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
Coke whoops
cotto Coke, that's great. We'll throw a Coke party. 04:35
Oh. There's a wikipedia page on operational semantics. I should look into that. 04:36
Thank you, wikipedia, and all the nerds who wrote you. 04:38
dalek rrot: 2ebb70a | petdance++ | src/pmc/namespace.pmc:
flag unused interps
rrot: d502f30 | petdance++ | src/pmc/mappedbytearray.pmc:
consting pointers. Flagging unused interps. Removed unused var
04:41 lateau joined, lateau left
sorear cotto: mm? Did it help much? Any questions? 04:47
cotto sorear, not so far but I haven't given up yet. 04:48
sorear basically the idea with operational semantics is to define a set of states and a set of allowed changes between states 04:50
so if you have something nondeterministic like threading? fine, just have A -> B *and* A -> C
it's a cross between pseudocode and Hoare logic 04:51
dalek rrot: 7e326a7 | petdance++ | src/string/encoding/ (3 files):
Shimming unused args. Removing and localizing variables.
sorear most of the operational semantics rules here are just ordinary monadic-Haskell rules 04:52
I basically skipped over most of the rules; they aren't useful for a quick overview 04:54
dalek rrot: 22d0a53 | petdance++ | compilers/imcc/main.c:
remove unused var
 04:59
rrot: b3c70cd | petdance++ | src/pmc/packfileannotations.pmc:
removed unused last_key_id variable
 05:01
05:09 fperrad joined
dalek rrot/opsc_llvm: 45961c9 | bacek++ | runtime/parrot/library/LLVM.pm:
"Import" all LLVM C API functions.
 05:12
05:35 Andy left
dalek rrot/opsc_llvm: 5012c59 | bacek++ | runtime/parrot/library/ (3 files):
Add LLVM::Opaque
 06:08
rrot/opsc_llvm: 2ae9971 | bacek++ | runtime/parrot/library/LLVM/Module.pm:
Inherit Module from Opaque
rrot/opsc_llvm: 3f98103 | bacek++ | / (3 files):
Migrate Function and BasicBlock to be Opaque
sorear woah! 06:09
bacek_at_work sorear, ?
sorear bacek_at_work: llvm parrot stuff. 06:10
bacek_at_work sorear, it's kind of old news already. For about 20 hours :)
sorear huh. How are you getting around the need for C++ name mangling? 06:11
bacek_at_work: yes but I only just noticed :) 06:12
plobsing sorear: LLVM has a C interface 06:14
bacek_at_work sorear, what plobsing said :)
Unfortunately it's incomplete (afaik)
At least python bindings has additional C++ code to work with llvm
sorear I am failing to find any documentation whatsoever for the C interface on llvm.org 06:17
I read *all* the LLVM docs a few weeks ago and they never mentioned this *annoyed* 06:18
months
sorear goes and looks at source
TiMBuS include/llvm-c 06:19
sorear Is there any real documentation for the LLVM API, anywhere?
bacek_at_work sorear, nope 06:20
not for C at least
cotto bacek_at_work, it took you that little time to write those binding *without* docs? 06:21
bacek_at_work cotto, erm... Almost :) 06:22
Just Kaledoscope tutorial
and npcontemplation.blogspot.com/2008/0...dings.html
dalek rrot/opsc_llvm: 158897b | bacek++ | runtime/parrot/library/LLVM/ (4 files):
Provide default .BUILD and fix Builder to use unwrap
 06:45
rrot/opsc_llvm: a6d8480 | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
Migrate Builder to Opaque. Add .global_string method
rrot/opsc_llvm: e4e6670 | bacek++ | t/library/llvm.t:
Add test for actual call.
nopaste "bacek" at 192.168.1.3 pasted "HO-HO-HO! LLVM test results! I can call native function from it!" (34 lines) at nopaste.snit.ch/35628
plobsing bacek_at_work: nice! 06:50
bacek_at_work Step 2: ... 06:51
Step 3: Profit!
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?
plobsing sorear: when Parrot calls native calls Parrot 06:53
then the inner Parrot does something continuationy (eg: exceptions)
boom
bacek_at_work plobsing, I'm going to jit whole Sub. 06:54
op-by-op
any non-local jumps will return to mail loop
plobsing oic
so JIT only for leaf subs
bacek_at_work not sure will it work for longjump... 06:55
06:56 jrt4 left
bacek_at_work plobsing, yes 06:56
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
plobsing and still hit the trampoline on non-local jumps
bacek_at_work plobsing, not sure. LLVM is still very new for me.
06:57 rurban_ joined
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?
bacek_at_work plobsing, still thinking about it.
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
yes :)
07:00 rurban left, rurban_ is now known as rurban
sorear plobsing: to avoid inferior runloop issues, the JITted code must never make a non-tail call into the op dispatcher 07:01
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.
sorear if the runloop has to use non-tail calls, then the jitted code has to arrange to *return* to the runloop
I guess jit fragments would have to return a new IP, like invoke vtables 07:03
invoke vtables are a lot like jit code; they need to be called from the runloop without using a new runloop 07:04
plobsing sorear: yeah. it's just a little messy. 07:05
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:06
07:16 theory left, jrt4 joined 07:24 jrt4 left
bacek_at_work plobsing, but it will require to create "nci file definition". Which is same amount of work 07:31
sorear Do we have a bundled runtime-wrapper-generator yet? 07:33
plobsing bacek_at_work: it requires slightly less work because it sets up the "populate namespace" code for you. 07:34
but you already wrote that part :( 07:35
sorear: "runtime wrapper generator"?
bacek_at_work plobsing, no worries. I had a plenty of time during DB wipe 07:39
07:43 lopaway is now known as lopnor 09:02 lopnor is now known as lopaway 09:13 jsut joined 09:18 jsut_ left 10:12 lucian joined 10:16 arnsholt_ left 10:21 arnsholt joined 10:22 lucian_ joined, lucian left 10:23 lopaway is now known as lopnor 10:25 lucian joined
bacek ~~ 10:25
10:28 lucian_ left 10:30 lucian left 11:01 lopnor is now known as lopaway
dalek rrot/opsc_llvm: 99be336 | bacek++ | runtime/parrot/library/LLVM.pm:
Remove debug output.
 11:21
rrot/opsc_llvm: d331923 | bacek++ | runtime/parrot/library/llvm_lib.pir:
Add LLVM::Opaque.get_pointer VTABLE to avoid unwrapping objects constantly
rrot/opsc_llvm: 9a84ad1 | bacek++ | runtime/parrot/library/LLVM/ (2 files):
Remove a lot of .unwrap
rrot/opsc_llvm: f6556ec | bacek++ | runtime/parrot/library/LLVM/Builder.pm:
Add Builder.{alloca|load|store}
rrot/opsc_llvm: 47808d1 | bacek++ | runtime/parrot/library/LLVM/Module.pm:
Add Module.add_type_name
 11:52
rrot/opsc_llvm: 8c491bd | bacek++ | runtime/parrot/library/LLVM/Type.pm:
Add Type.struct
12:16 jsut_ joined 12:20 jsut left 12:39 janus left 12:41 janus joined 12:47 janus left 12:54 janus joined 13:01 janus left, janus joined
dalek rrot/opsc_llvm: 30e820d | bacek++ | runtime/parrot/library/LLVM/Constant.pm:
Allow different wide int constants
 13:06
rrot/opsc_llvm: c8be6d2 | bacek++ | runtime/parrot/library/LLVM/ (2 files):
Add GEP building
rrot/opsc_llvm: 2e341f6 | bacek++ | t/library/llvm.t:
Remove useless .wrap calls
13:14 Patterner left 13:27 fperrad_ joined 13:30 fperrad left, fperrad_ is now known as fperrad, mtk joined 13:31 masak joined 13:39 hudnix joined 13:47 lucian joined
dalek rrot: de0365c | (Gerd Pokorra)++ | compilers/data_json/JSON.nqp:
add null rule in JSON.nqp
 13:56
14:06 ambs joined 14:07 davidfetter joined 14:11 frodwith left 14:15 whiteknight joined
whiteknight good morning, #parrot 14:23
msg cotto Check out TT #2042. I assigned to you for initial review. I don't think the "can" vtable is really needed.
aloha OK. I'll deliver the message.
dalek TT #2042 created by whiteknight++: Deprecate VTABLE_can 14:31
TT #2042: trac.parrot.org/parrot/ticket/2042
Coke whiteknight: you could override can in your class to avoid a potentially expensive find_method lookup 14:32
(for something like AUTOLOAD)
whiteknight Coke: VTABLE_can cannot be overloaded currently. At least not from PIR
Coke whiteknight: there are PMCs.
whiteknight you would have to subclass Object at the C level, then subclass Class to instantiate your new objects
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.
whiteknight my branch adds the ability to override VTABLE_can, but I'm not sure I want to merge that branch
dalek Heuristic branch merge: pushed 34 commits to parrot/gerd/JSON_nqp by gerd 14:38
whiteknight Hmmm.. that error message I was complaining about yesterday was in Class PMC, not in P6object 14:49
14:58 rurban_ joined 15:00 rurban left, rurban_ is now known as rurban
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:08
smolder #11699 failed to upload, but re-sent and #11700 was ok 15:09
whiteknight Coke: did you create a ticket for that .loadlib issue? 15:10
Coke not yet. figured odds were good the behavior changed deliberately.
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
cotto ~~ 15:13
sorear whiteknight: hi. 15:14
whiteknight hello sorear
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
15:15 ambs_ joined
dalek rrot: b855b2f | Whiteknight++ | / (2 files):
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: ...
whiteknight sorear: it turns out, nothing is stopping me 15:16
15:16 ambs left, ambs_ is now known as ambs 15:17 benabik joined
dalek TT #2043 created by coke++: .loadlib works when compiling, but not when running PBC 15:18
TT #2043: trac.parrot.org/parrot/ticket/2043
Coke whiteknight: done 15:19
benabik Morning, #parrot
whiteknight Coke++
good morning, benabik
Coke now I just need help tracking down #1886 15:20
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
Coke bacek is working on an llvm backend to ops2c.
benabik That sounds awesome. Using API or generating IR? 15:22
Coke using the hidden C api. 15:23
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
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
of course, if people start using that API, they might be more serious about maintaining it
dalek rrot/gerd/JSON_nqp: 938ab0e | (Gerd Pokorra)++ | t/compilers/data_json/to_parrot.t:
switch back to test JSON from PGE
 15:27
rrot/gerd/JSON_nqp: de4f790 | (Gerd Pokorra)++ | t/compilers/data_json/to_parrot_2.t:
add test for JSON from NQP
rrot/gerd/JSON_nqp: 72c0a77 | (Gerd Pokorra)++ | MANIFEST:
update mainfest
sorear whiteknight: nice. I was actually expecting some variation on "bureaucratic BS", but that works too. 15:32
15:32 benabik left, benabik joined
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:32
the only thing stopping me is time 15:33
15:38 Patterner joined, benabik left 15:39 benabik joined, masak left 15:43 hercynium joined 15:57 ambs left 16:03 theory joined
dalek nxed: r847 | NotFound++ | trunk/winxedst1.winxed:
indent generated pir except a few cases
 16:06
nxed: r848 | NotFound++ | trunk/ (3 files):
update installable files
dukeleto ~~ 16:08
dukeleto is working on our GSoC app
where is our ideas page this year?
dalek umage: 109de1c | Whiteknight++ | / (2 files):
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:11 davidfetter left
whiteknight dukeleto: We don't have a dedicated page, as far as I know 16:12
we can put one together
dukeleto whiteknight: we need one for our application 16:13
whiteknight: i think mikehh++ worked on one, but maybe that was for GCI
trac.parrot.org/parrot/wiki/GSoc2011
there it is
it definitely needs some meat added
dalek sella: f68d681 | Whiteknight++ | ports/plumage/rosella.json:
update plumage metadata file to show winxed as the build tool and as a dependency
dukeleto whiteknight: can you brain dump some of your gsoc ideas onto that page?
16:14 benabik left, benabik joined
whiteknight dukeleto: I will work on it asap 16:14
dukeleto whiteknight++ 16:16
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, Psyche^ joined, Psyche^ is now known as Patterner
whiteknight okay 16:21
dukeleto whiteknight: would you mind emailing parrot-dev and asking/reminding others to help with that page? 16:22
whiteknight sure thing
cotto_work ~~
dukeleto whiteknight: i will be having a very hectic day. Trying to get this app done with so I don't forget
cotto_work: werd up
whiteknight: you were in gsoc 2008, right? 16:23
whiteknight: i can't find a summary of which parrot projects existed in gsoc in 2008 and how many passed 16:24
whiteknight: do you know how many other parrot gsoc projects there were that year?
cotto_work this looks familiar: eli.thegreenplace.net/2011/03/07/fr...pycparser/ 16:33
dukeleto cotto_work: i need some help with the gsoc app
cotto_work: we need to beef up our ideas page 16:34
arnsholt cotto_work: I just came to this window to see if it had been mentioned already 16:35
(Damn you =)
cotto_work arnsholt: you mean gsoc?
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
cotto_work arnsholt: nm
NotFound I'm amazed. Risking errors to avoid "ugly"?
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
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
arnsholt I assumed he meant heuristics to add parens when they weren't strictly necessary
NotFound Who cares if they aren't strictly neccessary? 16:38
atrodo I'm pretty sure all C compilers encourage code ugliness as a rule of thumb 16:39
cotto_work NotFound: indeed
dukeleto: I'll be thinking about gsoc projects. 16:43
I'm sure there are a few. 16:44
16:44 M_o_C joined
dukeleto just submitted the PaFo GSoC app 16:48
dukeleto rests
cotto_work dukeleto++
whiteknight dukeleto++
lucian btw, would anyone want to mentor me with pynie?
whiteknight lucian: what is your idea for pynie?
lucian whiteknight: uh, write it so it works?
right now it's a mess (albeit a tiny one) 16:49
i'd like to rewrite the compiler in python and write as few core types as possible in winxed, probably
whiteknight lucian: okay, so are you writing pynie, or a new python compiler from the ground-up?
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
whiteknight what license issues?
lucian whiteknight: i didn't ask more at the time
whiteknight okay
lucian if you look in pynie's source, there's very little that's actually useful
the compiler would be dumped entirely anyway, as it uses PCT 16:51
the (few) types are written in PIR and barely similar to python's
PerlJam lucian: why continue to call it pynie? :)
whiteknight right, that's my question
lucian i didn't think much about it 16:52
sounds good enough? pynie-ng?
whiteknight it seems like the better course of action would be to start fresh. Write your own compiler
maybe the name doesn't matter. you can call it whatever you want if you are writing it
dalek tracwiki: v1 | dukeleto++ | GSoCStudentApplicationTemplate 16:53
tracwiki: trac.parrot.org/parrot/wiki/GSoCStu...ction=diff
tracwiki: v2 | dukeleto++ | GSoCStudentApplicationTemplate
tracwiki: trac.parrot.org/parrot/wiki/GSoCStu...ction=diff
Coke (preference for new code) not SFAIK.
lucian whiteknight: yeah, sure
calling it pynie verbatim is confusing, you're right
i'd rather call it just "python" 16:54
PPython perhaps
PerlJam pypar
parpy
parpy sounds like harpy and I'm not sure that's the right mental image ;)
lucian i'm fine with ParrotPython
anyway, i'd like to reuse one of the existing python compilers, perhaps PyPy's 16:55
retarget the backend to PIR (or even winxed?)
PerlJam lucian: you mean just the parser?
lucian PerlJam: parser, peephole optimiser
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
it's times like this that i wish python had standard lower-level types 16:57
so that i could write more python than winxed/other
PerlJam Have you ever read pypy's mission statement? 16:58
codespeak.net/pypy/dist/pypy/doc/ar...-statement 16:59
I wonder if anyone has put the theory to the test
lucian PerlJam: well, they have
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:00
NotFound "p: we can write new translator back-ends to target different physical and virtual platforms." 17:01
lucian NotFound: writing a parrot backend for PyPy is perfectly possible 17:02
but it'd be doubly-interpreted
whiteknight lucian: a PIR/PBC backend to Py
Py would be a very good project
of course, whether that project produces somethign which is generally useful is a different question 17:03
lucian whiteknight: Py?
whiteknight PyPy, I hit return in the middle
lucian i see
NotFound lucian: I'm a bit tired of perfectly possible things that nobody does. 17:04
lucian NotFound: it'd be pointless
plobsing is "Py" taken as a name?
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
think NQP, but with "P=Python"
lucian whiteknight: i don't think that's very useful
17:06 M_o_C left
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
okay. Just a suggestion
lucian whiteknight: it'd be nice to have an equivalent to, say, cython, on parrot
whiteknight what do you mean by that?
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
PerlJam: RPython is not really usable outside writing VMs with the PyPy framework
PerlJam lucian: so you're saying they are failing that part of their mission? 17:09
lucian PerlJam: not at all
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.
lucian RPython ends up being an implementation detail of the frameowork
whiteknight: so ideally, using a more wrist-friendly language instead of winxed would be nice
PerlJam lucian: however, a parroty backend (in whatever form that takes) would be a boon to parrot.
lucian but especially for GSoC, i think it's just a time waste
PerlJam: and not very useful at all
in my opinion anyway
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
(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
that's not possible with the JVM, at least not as it is now
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
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
whiteknight so if that's the kind of project you want to work on, I would be very supportive of it
NotFound And for extra laziness, it can target winxed and let winxed take care or pir generation gory details.
whiteknight I doubt I would be a good mentor since I don't know any Python
lucian whiteknight: i'm highly skeptical of compiling dynamic languages to static targets 17:14
NotFound: yep
NotFound: also, if parrot moves away from pir
(when?)
whiteknight Parrot can move away from PIR as soon as some other HLL starts outputting PBC directly 17:17
I would love to see Winxed win that race, personally 17:18
lucian: if your heart is not set on doing something pythonish, teaching winxed about the ways of love and PBC would be quite nice
cotto_work whiteknight: I'd love to see any language win that race. 17:19
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.
jnthn If PAST => POST => PBC happens then a bunch of languages can win at once. :)
whiteknight I've added a task to output PBC from POST to the GSOC tasklist page 17:21
cotto_work jnthn: this is true
whiteknight If that happens, winxed could be updated to parse through PAST/POST if desired
or, we could write compilers in winxed which output PAST
NotFound whiteknight: What's the difference? 17:22
whiteknight no real difference
sorear PIRate already outputs PBC from POST
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
dukeleto whiteknight++ # awesome gsoc idea page email
NotFound Given that winxed is a compiler written in winxed, not much difference.
dukeleto goes to lunch
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
brb food
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.
dalek tracwiki: v4 | whiteknight++ | GSoc2011 17:24
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
cotto_work Do they serve significantly different purposes?
Coke I would be happy to mentor someone doing work on, say, tcl. ;) 17:26
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
Coke yes, but an API to generate that format shouldn't. 17:28
cotto_work Coke: exactly
NotFound That's the point. Give me an api, and make imcc use it.
cotto_work If we have tests for the api in core, we can be pretty sure to keep it working. 17:29
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
17:31 ambs joined
NotFound In fact, it already happened with the recent dynop handling changes. 17:32
We had tests, and test just get changed.
plobsing those tests got changed because the API didn't give enough abstraction 17:33
NotFound Yes, I didn't oppose because it was still highly experimental, but the point is still valid. 17:34
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
the problem is, there is an interesting set of programs that might use such an interface
NotFound Like, say, imcc ;) 17:36
plobsing or pbc_merge, or a register allocator, or ...
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:38
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:39
sorear Coke: don't you loathe the deprecation policy? 17:40
Coke sorear: not especially, no.
NotFound Coke: the only problem right now is that that API still doesn't exists, so I'll keep targeting PIR.
Coke NotFound: that is absolutely an issue. ;) 17:41
I would label that highly experimental, then.
plobsing there's this expectation that "experimental" things stabilize over time 17:42
we need a different category "intentionally left perpetually unstable"
Coke "internal" is a fine name. I think that having bytecode format in that category was certainly not one of the original goals. 17:43
sorear I got the impression from Dan's blog that bytecode was supposed to be stable like JVM bytecode 17:45
and that apps would be distributed in .pbc frmat
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:46
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.
er, M0 bytecode
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.
M0 is a poor format for transmitting ops 17:48
s/ops/programs/
cotto_work plobsing: that's likely to be true.
plobsing cotto_work: so we'll still need something analogous to our current PBC format. M0 doesn't solve this problem. 17:49
17:53 benabik left 17:56 ShaneC left
Coke plenty to fix in the meantime. What about #1886? ;) 17:57
I think it's interesting that the first eval works fine. 17:58
18:02 theory left 18:04 davidfetter joined 18:14 theory joined 18:18 ShaneC joined
sorear Would it be possible to leverage opsc_full_parse to write a .h to .nci/.pir converter? 18:20
Would this be a good GSoC size task?
cotto_work sorear: you'd have to be a lot smarter about dealing with C's types. 18:21
I've been meaning to ask bacek about his thoughts on splitting out the C parsing bits into a separate hll.
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
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 18:30 bacek left, ShaneC1 joined 18:34 ShaneC left 18:36 ShaneC joined 18:37 Andy joined 18:38 ShaneC1 left 18:47 ShaneC1 joined 18:49 ShaneC left
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:49
the op can stay, and can actually avoid the extra level of indirection 18:50
and then there's basically zero burden on our users 18:51
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.
whiteknight we can't really get rid of the "can" op, because find_method throws an exception on method not found 18:54
can returns a bool, which is faster and friendlier
if find_method were modified to return a null, we could talk about removing the "can" op
but until then, I think we can live just fine without VTABLE_can 18:55
cotto_work wfm
18:57 plobsing joined, dmalcolm joined
dalek rrot: 276483b | petdance++ | / (2 files):
removed unnecessary interpreters from str_rep_compatible and Parrot_str_rep_compatible, and made both of them PARROT_PURE_FUNCTIONs.
 19:03
mj41 Hmm ... logged in as mj41 - trac.parrot.org/parrot/wiki/GSoc2011 ... Where is "edit page" button? 19:05
Andy Are you sure you're logged in? 19:06
trac.parrot.org gives me hassles all the time.
mj41 # logged in as mj41 # Logout # Preferences 19:07
Coke you may not have wiki edit privs. moment.
Andy: but mostly only you, as I recall. 19:08
mj41 does not seem to have ANY permissions.
19:08 silug joined
cotto_work easy fix 19:09
Coke The user mj41 has been added to the group developer.
that'll probably do.
mj41 great, thanks 19:10
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:12
19:15 bacek joined
lucian sorear: cotto_work: i'm pretty sure you need a C compiler (parser) to generate full, correct introspection data 19:15
sorear lucian: we have a C compiler now. 19:16
lucian sorear: right. and it doesn't parse headers?
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
sorear bacek++ is working on a LLVM backend for our C compiler 19:18
lucian hmm. why does parrot have a C compiler? 19:19
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
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
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
Coke lucian: right now we're generating C. bacek is working on generating llvm. 19:26
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
like the way Qt extends C++ with foreach
sorear lucian: that's basically what M0 is
lucian sorear: i see. so M0 is supposed to be a nicer C that translates to regular C?
dalek p/ctmo: 1516bd2 | jonathan++ | / (2 files):
Add a Serialization Context PMC. Just bare bones for now.
 19:28
p/ctmo: 89c34b4 | jonathan++ | src/ (6 files):
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.
p/ctmo: 10e90bd | jonathan++ | src/ (2 files):
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.
sorear lucian: I'm not sure we've gotten quite that far yet 19:29
lucian sorear: right. so it's still being designed?
dalek tracwiki: v5 | mj41++ | GSoc2011
tracwiki: TapTinder
tracwiki: trac.parrot.org/parrot/wiki/GSoc201...ction=diff
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
cotto_work It won't be especially like C. It just has to have equivalent expressiveness 19:30
lucian i may have said this some other time, i like aspects of Cyclone, ooc and Rust 19:31
Cyclone's a bit dead, but its design is very interesting 19:32
especially when it comes to pointers (they get bounds checks)
atrodo cotto_work> What do you think the difficulty level is to make bacek's opsc emit lasm? 19:35
sorear atrodo: bacek wrote a Parrot binding to the LLVM API yesterday. 19:36
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?
atrodo I'm thinking more of being able to turn the ops into lasm chunks for my lorito prototype 19:40
19:42 plobsing joined 19:43 plobsing_ joined 19:44 plobsing_ left 19:49 benabik joined 19:51 lucian left, ShaneC1 left 19:52 ShaneC joined
bacek Good morning, humans 19:54
benabik Afternoon, bacek.
sorear hello bacek
bacek aloha, benabik
aloha, sorear
19:58 lucian joined
dalek rrot/opsc_llvm: 8c47cf7 | bacek++ | runtime/parrot/library/LLVM (6 files):
Drop prefix LLVM from LLVM::F keys. We don't have to repeat it many times
 20:02
20:04 lucian_ joined, lucian left 20:11 ShaneC1 joined 20:13 ShaneC left
dalek rrot: c6a5121 | petdance++ | src/dynpmc/file.pmc:
flagging unused args
 20:13
20:14 lucian_ left 20:16 ShaneC joined 20:20 lucian joined 20:21 ShaneC1 left
dalek rrot/opsc_llvm: 6328edc | bacek++ | runtime/parrot/library/LLVM.pm:
Fix function signatures.
 20:31
rrot/opsc_llvm: 650f438 | bacek++ | runtime/parrot/library/LLVM/Module.pm:
Add more methods to Module.
rrot/opsc_llvm: d1e4ac3 | bacek++ | runtime/parrot/library/LLVM (4 files):
Rename LLVM::convert_to_struct into to_array. For aesthetic reasons
20:40 ShaneC1 joined
dalek rrot/opsc_llvm: 89cee3d | bacek++ | runtime/parrot/library/ (3 files):
Add stub for LLVM::Context
 20:41
rrot/opsc_llvm: 64f2895 | bacek++ | runtime/parrot/library/LLVM/Context.pm:
Add some guts to LLVM::Context
rrot/opsc_llvm: 1c3e342 | bacek++ | runtime/parrot/library/LLVM/Context.pm:
Add more stuff to LLVM::Context
plobsing bacek: be mindful that you are using many deprecated NCI things. 20:42
managedstruct, 't' signature type, etc...
20:43 ShaneC left 20:47 ambs left 20:52 plobsing left
Andy Why do we allow the memory allocation stuff in alloc_memory.c to handle a size = 0? 20:53
20:53 benabik left
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
plobsing_ Andy: we allow for zero-sized allocations because we make them. a lot. 20:57
20:57 ShaneC joined
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
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) 20:59
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
plobsing_ bacek: I'm currently trying to remove the eligible NCI signatures so people stop using them 21:00
bacek plobsing_, what is replacement for "t"? 21:01
plobsing_ bacek: see trac.parrot.org/parrot/ticket/1931
there is no direct replacement. I'm removing the "sugar" from NCI. no more magic stuff.
bacek plobsing_, hang on. How I can call "foo(char*)" without such sugar??? 21:02
from PIR/NQP
plobsing_ pass a buffer of chars
a string is not a buffer of chars
you can provide an independant sugar layer should you so desire
NotFound plobsing_: a buffer of chars can be null? 21:03
plobsing_ this is what zavolaj does
NotFound: it can if you want it to be
bacek ByteBuffer PMC doesn't provide .get_pointer 21:04
plobsing_ if you want a direct analog, NCI Parrot_str_to_cstring()
bacek And zavolaj is implemented in C
plobsing_ in C? really?
bacek And I definitely don't want to write C for LLVM.
aloha, zavolaj?
aloha bacek: Dunno.
tadzik that's in PErl 6
github.com/jnthn/zavolaj/blob/mast...veCall.pm6 21:05
bacek aloha, zavaloaj is github.com/jnthn/zavolaj 21:06
aloha bacek: Okay.
bacek plobsing_, line 63 in github.com/jnthn/zavolaj/blob/mast...veCall.pm6
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
Andy plobsing_: Wy do we make 0-byte allocations?
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
Andy I think we ought to panic no matter how many bytes we fail to malloc.
bacek plobsing_, whatever. We have this layer now. I don't want to write new layer for no reason.
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.
Andy Why?
plobsing_ because NULL is a pointer to at least 0 bytes of r/w data
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.
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.
Andy what are you looking at?
NotFound Andy: that is Medusa. 21:11
Andy NotFound: I don't understand.
dalek rrot/opsc_llvm: 47027d4 | bacek++ | runtime/parrot/library/LLVM/Type.pm:
Add more Types.
NotFound Andy: NM, bad joke.
plobsing_ pubs.opengroup.org/onlinepubs/00969...alloc.html 21:12
lucian is reading 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?
plobsing_ yep. that's the line. I interpret that to mean "malloc(0) can return NULL"
Andy Yes, it can. 21:14
But that pointer is not usable as anything.
You can't dereference NULL.
whiteknight and since parrot is a platform-abstracting VM, we should have a single codified behavior there
plobsing_ you can use a pointer without dereferencing it
Andy (and expect to live)
use it how?
plobsing_ you can pass it to realloc for example
Andy But I don't think that's valid, either. 21:15
Because realloc() relies on dereferencing
plobsing_ Andy: shall I point you to the appropriate opengroup spec page for that too? 21:16
Andy eh, no not
plobsing_: Come on, don't talk down to me.
Where is some place that we actually use this malloc-a-dummy-area-with-size-0?
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)
Andy lucian: That's what I'd expect, too.
lucian the only way parrot can protect from that is with the gc
but even that is overkill 21:18
exit(1) is the default sane behaviour
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.
People are allowed to be wrong.
NotFound realloc accepts NULL
Andy Yes, it does.
I see that.
I'm still wondering where we actually malloc pointer of size 0. 21:20
Because that behavior seems fraught with peril.
NotFound In fact, you don't need malloc or free, realloc can do all teh job.
cotto_work experiments 21:21
dalek rrot: b838b2c | petdance++ | / (2 files):
mem_sys_allocate() cannot return NULL, so flag it as such
rrot: 626b12c | petdance++ | / (2 files):
mem_sys_allocate actually CAN return NULL.
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.
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.
NotFound Note that malloc(0) may not return NULL, the result is platform dependant.
Andy NotFound: Yes, understood.
Specifically which guards do you mean, plobsing_ ?
plobsing_ the ones in alloc_memory.c 21:24
Andy How do you see them as broken?
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.
plobsing_ they aren't right now. they accept NULL on zero-sized allocations. they were broken before.
Andy When we allocate 0-byte buffers, do we know that we are doing so?
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:25
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.
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.
plobsing_ Andy: I don't have that information available to me at the moment.
Andy Give me a clue.
In the GC?
atrodo cotto_work> Any guess on some of the variations of interaction issues?
Andy Somewhere else?
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.
plobsing_ Andy: I cannot recall.
cotto_work atrodo: can you clarify what you mean? 21:28
we don't seem to have any 0-sized allocations while running ops2c --core 21:29
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
what's the make target for the extra-heavy-duty test suite?
Tene fulltest? 21:32
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.
Andy That's what I'm tracking down. 21:34
atrodo mj41> On my list :)
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.
atrodo mj41> I wanted to do it last night, but things came up. so I'm aiming to do something tonight
mj41 atrodo: ok, on this month todo list is good enough :-) 21:36
21:36 whiteknight left
cotto_work Andy: awesome. 21:40
Andy Specifically, splint tracks what can and can't be NULL. 21:41
and if our core allocation functions can be declared PARROT_CANNOT_RETURN_NULL, then all that can propagate up. 21:42
My make test runs without ever calling a 0-size allocation.
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.
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?
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?
plobsing_ make
21:45 lucian_ joined
Andy running a distclean 21:45
21:46 lucian left
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
plobsing_ Andy: no. and I do not have my minix VM availalble ATM. 21:51
21:53 ShaneC1 joined
Andy Maybe it's one of the gc/gc*.c fies 21:55
21:55 ShaneC left
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?
Andy particle: That's not what PARROT_CANNOT_RETURN_NULL does.
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.
Andy I think what I'm going to do is make the mem_sys_* functions in src/gc/alloc_memory.c disallow size = 0
and guarantee they return non-NULL
and let the mallocs in src/gc/gc*.c do what they do now. 22:08
Because the GC stuff is dark and arcane and not used by normal humans anyway.
All the GC API stuff like Parrot_gc_allocate_fixed_size_storage is flagged as PARROT_CANNOT_RETURN_NULL anyway. 22:11
And the GC*.c code are the only ones that would be doing anything with the 0-size mallocing anyway. 22:12
dalek nxed: r849 | NotFound++ | trunk/winxedst1.winxed:
clean and improve indent of generated pir and op emiting
 22:16
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:22
again smolder #11724 failed, had to re-send and #11725 uploaded ok 22:23
i.e. failed to finish uploading 22:24
dalek rrot/opsc_llvm: 156d40e | bacek++ | config/gen/makefiles/root.in:
Add LLVM to default build
 22:26
mikehh see TT #2039
22:30 ShaneC joined 22:34 ShaneC1 left, lucian joined
dalek p/ctmo: 06a391d | jonathan++ | / (6 files):
Get setting loading working from pre-compiled code. This was a tad twisted to do, but should work nicely now.
 22:35
22:37 lucian_ left 22:48 slavorg left, slavorg joined 22:57 cognominal left 22:59 rurban_ joined
bacek_at_work jnthn, ping 22:59
23:00 lucian left 23:01 rurban left, rurban_ is now known as rurban, hercynium left
bacek_at_work jnthn, unping 23:08
dalek rrot/opsc_llvm: e2e9fa6 | bacek++ | runtime/parrot/library/LLVM/Function.pm:
Don't generate name in Function.append_basic_block. Expose Function.entry_block.
 23:19
rrot/opsc_llvm: c9ae6e7 | bacek++ | src/call/args.c:
Ugly hack of parsing PCC signatures to support Object.get_pointer
23:20 plobsing_ left 23:34 lucian joined 23:45 lucian_ joined 23:49 lucian left

Powered by Cro and the Raku® Programming Language.

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

Thank you!