Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 25 August 2011.
00:26 whiteknight joined
whiteknight good evening, #parrot 00:31
00:44 lateau joined 00:45 lateau left 00:50 nbrown joined
soh_cah_toa whiteknight: hey, you all prepared for the storm? 01:02
whiteknight yeah, I don't think it's going to be too bad this far inland
lots of rain and wind, but nothing crazy
how about you?
soh_cah_toa that's b/c the weathermen have been saying that the way to stay safe is to work on soh_cah_toa's debug segment packfile pmc's 01:03
apparently, the capacitors and transistors in the ram used to store the code for the pmc's generate a super gigantic magical electrical field that disrupts the low-pressure center of hurricanes
that's why you'll be safe ;)
i swear, it really said that on the news ;) 01:05
whiteknight well, if they say soon the news 01:10
soh_cah_toa remember, everything on tv is true
plobsing_ why do we need a separate debug segment? from what I can tell, the proposed debug segment defines an object tree and serialization format. We already have what is supposed to be a general purpose serialization format (it has its weak spots, but still), so why go to the trouble of creating a new serialization format? 01:15
soh_cah_toa all we have is a poor line # to opcode mapping 01:16
very poor
plobsing_ I am refering to the const table
soh_cah_toa a debugger (and other analysis tools) need *a lot* more info about hll's
plobsing_ and the line # to opcode mapping works great. how it is populated is poor
soh_cah_toa i tried this summer 01:17
it won't work
plobsing_ yes there is more information needed, but defining a serialization format is shaving a yak that just got shaved yesterday
soh_cah_toa well, i'm not sure what that analogy means but this is just how debuggers are supposed to work 01:18
it's how every other compiler or vm allows debugging of object code 01:19
plobsing_ but why do we need a separate segment?
soh_cah_toa a new segment 01:20
plobsing_ the constant segment already affords arbitrary object graphs. your spec defines a tree of objects.
soh_cah_toa pretty much just pimping out the old debug segment
well, i need to know more about the source than just constants
plobsing_ but the metadata is constant, is it not? 01:21
and it can be serialized by a graph serializer, can it not?
soh_cah_toa i'm not quite sure what you're proposing. the way i see it: the constants table is for constants in the source and the debug segment is for symbolic info about the source 01:23
plobsing_ the constant segment is for arbitrary datastructures required by the bytecode
soh_cah_toa hm
plobsing_ these may or may not be constants refered to by the source 01:24
at least, as far as the user sees them
soh_cah_toa regardless of where the debug info is stored or whatever you want to call it, there's still no denying that we need a standardized format for storing symolic info about the original source 01:25
plobsing_ I agree that we need to store metadata about the source in tree form
soh_cah_toa ok
plobsing_ I disagree that we need to define a separate segment and serialization format to accomplish that 01:26
soh_cah_toa how else is there any way to?
it's worked for thousands of other vm's and compilers 01:27
plobsing_ the debug data can be contained in the constant table
soh_cah_toa that's fine
i could care less where it's stored
just that it gets stored 01:28
somewhere :)
plobsing_ the important part is that the details of serialization are managed elsewhere and the debug format can focus on the structure of the tree, which is closer to the use-case
and from the other side, PBC readers do not need to become more complicated
soh_cah_toa i agree 01:29
only a consumer of debug data need be aware of the segment
plobsing_ it also provides an easy way to refer to relevant parts of the debug tree from bytecode - the annotations segment can be used to point to arbitrary entries in the constant table. 01:32
that way, you needn't always start at the root of the tree 01:33
soh_cah_toa the format actually should make annotations "obsolete". hll's could still use them if they want but they're essentially useless to a debugger. my proposal has a line number and address table within the actual segment 01:35
plobsing_ this is a duplication. I am asserting that Parrot already contains all of the parts to construct this, but they are being assembled incorrectly. 01:36
soh_cah_toa hmm...ok
i think i'm seeing your point
01:37 particle joined
plobsing_ I'm sorry if I was unclear at first. communication is not exactly my strong soit 01:37
s/soit/suit/
soh_cah_toa no problem :)
plobsing_ nor is typing apparently
soh_cah_toa i'm glad you're bringing stuff like this up though b/c that is exactly where i'm at right now: trying to parrot-ize the parts of dwarf that are not possible or can be done differently. however, i'm no parrot guru so your input definitely helps 01:39
actually, i'm looking at docs/parrotbyte.pod now and it says the constants segment is for storing constants in the bytecode 01:41
now, does this mean any constants in the entire packfile (i.e. any and all segments) or just constants in the actual bytecode stream of opcodes?
plobsing_ well, the way I see PBC is as a graph of objects which may contain bytecode. 01:42
subs are objects which have bytecode
subs live in the constant table
soh_cah_toa that's strange. how is a subroutine a constant?
plobsing_ it is an object 01:43
and for the most part, it is constant
soh_cah_toa maybe "constant" is not the best name for it then :\\
plobsing_ parrot has a few uses of the word constant that are unintuitive at first
soh_cah_toa indeed
plobsing_ the const-ness in the constant table is a const-ness of reference 01:44
soh_cah_toa alright, i see. a poor choice of terminology but it makes sense in a long stretch i guess
so then the bytecode segment refers to any "objects" in the source file through the constants segment? 01:45
plobsing_ it was intended at one point that the objects in the table be read-only, but parrot's enforcement of those types was complicated and lackluster
soh_cah_toa: that is my current interpretation of the format, yes
soh_cah_toa ah 01:46
ok, so then i see how your point about duplication
plobsing_ soh_cah_toa: regarding the naming, would you consider the java-ish "object pool" to be more appropriate? 01:56
soh_cah_toa plobsing_: yeah, that's not bad actually 01:57
much more appropriate 01:58
plobsing_ I considered renaming it, but I was concerned that "pool" would evoke notions of GC 01:59
soh_cah_toa ah, yeah
plobsing_ I suppose we could put it to the list
soh_cah_toa sure 02:00
s/pool/table/ might not be bad either
03:51 jsut_ joined 04:41 jsut joined
benabik o/ 05:21
05:37 mj41 joined 06:29 kurahaupo joined 06:46 schmooster joined 07:03 woosley joined 07:43 rfw joined 08:07 schmooster joined 08:36 Eclesia joined
Eclesia hi 08:36
09:14 whiteknight joined 09:19 rurban joined
Eclesia hi whiteknight 09:26
whiteknight hello Eclesia 09:28
09:37 fperrad joined, contingencyplan joined 10:33 schmooster joined 11:02 schmooster joined 11:13 szabgab joined
Eclesia whiteknight: question : when I have a class pmc, how do I create a new instance of that class ? 11:15
or anyone else :D 11:16
11:35 zby_home joined
whiteknight $P1 = new $P0 11:42
or, I think there is a method $P0.instantiate()
Eclesia can't find any instantiate in parrot source 11:45
NotFound Is a vtable function, not a method. 11:50
There is a 'new' method. 11:51
Eclesia NotFound: was is the syntax in winxed for setattribute ? 11:56
getattribute(candidate,attName); <--- OK setattribute(candidate, attName, value); <-- Not OK 11:57
NotFound Eclesia: candidate.attName = value; 12:00
Eclesia *sigh* always forget parrot is for dynamic types 12:01
NotFound Or, if attName is variable, candidate.*attName = value;
12:24 jsut_ joined 12:41 ambs joined 12:48 ambs joined 13:05 TonyC joined
dalek rrot: 30a829d | NotFound++ | / (2 files):
fix C++ build:

Fix wrong usages of modf in the Select PMC		 13:06
13:07 autark joined 13:11 nopaste joined
Coke is no longer at verk. 13:17
14:07 rurban joined 14:10 Coke joined 14:14 szabgab left
Eclesia NotFound: I have a problem with instanciation of winxed classes using reflection : The constructor is not called which result in an unexpected state of the created object. 14:19
example :
nopaste "Eclesia" at 192.168.1.3 pasted "Constructor not called using reflexion instanciation" (90 lines) at nopaste.snit.ch/75172
Eclesia in this class I make some initialisation of fields. when calling : new List() everything is fine 14:20
but using the reflection : clazz.new(); the initialisation is not called 14:21
NotFound Eclesia: winxed constructors are a winxed concept, the class PMC doesn't know nothing about them. 14:22
Eclesia NotFound: that means parrot does not know what is a constructor ? 14:24
it's just a method like any other ?
NotFound Eclesia: yes
Eclesia: if you want automatic initialization you can override the init and init_pmc vtables. 14:25
Eclesia NotFound: like this = function init[vtable](){ self.array = []; } ? 14:27
NotFound Eclesia: yes
Eclesia NotFound: what is the difference between init and init_pmc ? the arguments ? 14:28
NotFound Eclesia: init takes no arguments, init_pmc takes one PMC argument. 14:29
If you use clazz.new(something), init_pmc is(something) called. 14:30
Eclesia NotFound: this argument is a Hash or a PMCarray i suppose ? if several parameters are necessary
plobsing_ this always seemed unecessarily crufty, bordering on wrong to me 14:31
NotFound Eclesia: using init_pmc with pir objects is tricky, the class instantiation assumes is a Hash and tries to set the attributes with it.
plobsing_ why don't we just have a slot in the vtable that points to the String name of the constructor method, or the PMC of the constructor method? 14:32
whiteknight plobsing_: I have always wanted the same thing
Maybe in 6modelland, we will finally do that
NotFound plobsing_: according old documents, there was a plan to do something like that, but I think that feature never got implemented. 14:33
14:35 rurban joined
Eclesia Null PMC access in isa_pmc() <---- what does that mean ? 14:36
whiteknight Eclesia: it means somebody is using a Null PMC
arnsholt It's Parrot's null pointer exception. Something's trying to do something to a NULL value 14:37
14:37 woosley left
Eclesia so my init override is uncorrect ... 14:38
function init[vtable](){ self.array = []; return self; } <---- not correct ? 14:39
whiteknight looks correct
plobsing_ init should return void perhaps 14:40
NotFound Eclesia: init and init_pmc don't expect return anything. 14:41
Eclesia it doesn't make any difference 14:42
at the moment I added the init override, the reflection instanciation return null. 14:43
14:43 JimmyZ joined
dalek rrot/whiteknight/6model: 44dc6f6 | Whiteknight++ | src/6model/ (25 files):
Copy most 6model-related code as-is from the NQP repo
 14:44
rrot/whiteknight/6model: 23e6cc3 | Whiteknight++ | src/pmc/s (3 files):
Move over some of the 6model-related PMC types
rrot/whiteknight/6model: 62fc1b7 | Whiteknight++ | / (43 files):
Add 6model files to the build. Many fixes so we can headerize.
whiteknight if we have any other requests for the object model of the future, now is a great time to ask :) 14:45
pt coretest
bleh 14:46
JimmyZ wow, whiteknight++
nopaste "Eclesia" at 192.168.1.3 pasted "init override not working" (107 lines) at nopaste.snit.ch/75173 14:51
Eclesia NotFound: here is a testcase
the main function is at the end 14:52
nopaste "NotFound" at 192.168.1.3 pasted "init and Class new" (20 lines) at nopaste.snit.ch/75174
NotFound Eclesia: this works for me
Eclesia: I don't know if you can call methods from init, the object can be half-constructed. 14:54
Eclesia NotFound: Even if I do nothing in the init it still fails 14:55
ha ... 14:56
NotFound: I found the problem, test this : 15:05
nopaste "Eclesia" at 192.168.1.3 pasted "Error in return" (23 lines) at nopaste.snit.ch/75175
Eclesia NotFound: looks like some parsing error, if you write it like this : function newInstance(var clazz){ var res = clazz.new(); return res; } then it works 15:09
ping ? 15:19
NotFound Eclesia: sorry, I'm busy now. 15:22
Eclesia no problem. 15:24
15:44 bluescreen joined 16:19 schmooster joined
whiteknight jnthn__: ping 16:20
brb 16:25
16:26 whiteknight joined
dalek rrot/whiteknight/6model: ffd67ce | Whiteknight++ | / (4 files):
Add in a first take on the 6model-specific ops. Largly copied from NQP, but I didn't bring over ops that were NQP or Rakudo specific. Some ops regarding serialization contexts need more clarification about where they belong. Do 6model initialization in interp setup instead of requiring a dynop
 16:35
rrot/whiteknight/6model: 813618e | Whiteknight++ | .gitignore:
Add 6model dirs to gitignore
 16:36
16:38 kid51 joined
benabik o/ 16:40
whiteknight++
whiteknight hello benabik 16:41
benabik whiteknight: You tend to have quite excellent branches.
whiteknight they're only excellent until we try to merge. That's when hell breaks loose 16:42
benabik Details. 16:43
cotto whiteknight, is your plan to copy/adapt 6model?
whiteknight yes. Copy as much as I can, to make the eventual transition for NQP easier
I'm going to have to start a branch of NQP soon to deduplicate things like pmc types and ops 16:44
this branch is going to need a lot of work before we get to that point. Lots of codestd fixes throughout, etc 16:45
16:47 ambs joined
dalek TT #1199 closed by jkeenan++: automatically create config.log during build 16:52
TT #1199: trac.parrot.org/parrot/ticket/1199
rrot/whiteknight/6model: e960b1d | Whiteknight++ | / (4 files):
Several fixes. Parrot builds again
 16:54
16:56 benabik joined, dodathome joined
NotFound Eclesia: the function toStringTree is not defined. Other than that, your example works for me. 17:04
Eclesia NotFound: test the last pastebin
NotFound: nopaste.snit.ch/75175 17:05
NotFound: I found another bug a few minuts ago : class Foo{ function Foo(){} } function main(){ new Foo(); } 17:09
NotFound Eclesia: strange... if you do: var x = clazz.new(); return x; it works. Some problem with the tailcall optimization. 17:11
I think there is a ticket about tailcalling methods on PMCs. 17:13
dalek TT #2186 created by whiteknight++: Add 6model to Parrot 17:23
TT #2186: trac.parrot.org/parrot/ticket/2186
17:24 schmooster joined
dalek rrot/whiteknight/6model: aaa3aa2 | Whiteknight++ | api.yaml:
+note about 6model being experimental to api.yaml
 17:30
moritz temporarily achieved a load average of > 145 with a 'make -j' in parrot :-) 17:39
then the OOM killer took my browser, mail client, feed reader and a few dozen GCC processes 17:40
Coke msg kid51 instead of asking on every ticket if we should keep this kind of ticket in the systme, please ask on list or in #parrotsketch. KTHNKS. 17:42
aloha OK. I'll deliver the message.
Coke I also don't see the need to say "any update" when clearly there is no update. I may be the only person who actually finds those annoying, though. 17:47
17:50 not_gerd joined
not_gerd hello, #parrot 17:51
kid51 Coke: You are.
dalek rrot/whiteknight/6model: 1111878 | moritz++ | src/6model/ (2 files):
start to clean up a few codetest failures
 17:52
kid51 For all practical purposes, no one other than me does any cage cleaning/review of old tickets.
dalek rrot/whiteknight/6model: c906d08 | moritz++ | src/pmc/sixmodelobject.pmc:
tabs -> spaces
not_gerd cotto: any ideas yet what would cause gist.github.com/1171152 ? 17:53
Coke not_gerd: any local changeS? 17:57
kid51 not_gerd: Which platform? 18:00
not_gerd Coke, kid51: msys-MINGW32, so quite a lot of changes (see github.com/gerdr/parrot/tree/gerdr/msys ) 18:01
cotto said ha'd take a look as he wrote the test...
^he'd
it's 1/3 of the remaining failures on msys-MINGW32, and I don't really have any idea how to debug that... 18:02
dalek rrot/whiteknight/6model: eb87275 | moritz++ | / (4 files):
more random codetest fixes
 18:15
kudo/nom: 0adc742 | Coke++ | t/spectest.data:
run this fudged test
 18:21
whiteknight moritz++ 18:26
kid51 whiteknight: With an all g++ build, I'm getting the same build failures in your branch as we recently did in master 18:45
nopaste "Eclesia" at 192.168.1.3 pasted "NotFound : another winxed bug" (23 lines) at nopaste.snit.ch/75207 18:50
Eclesia NotFound: value is not incremented : expected result 0 1 but is 0 0 18:52
question : I can add bug reports on the parrot tracker ? or it's somewhere else ? 18:57
whiteknight ? 19:01
whiteknight ?
moritz Eclesia: you should be able to. If not, somebody needs to give you permissions 19:02
Eclesia moritz: I don't see any component 'winxed' when I create a new ticket, that's why I ask
dalek rrot/whiteknight/6model: 9369d70 | jkeenan++ | src/ (9 files):
[codingstd] C parentheses, mostly.
 19:03
rrot/whiteknight/6model: 5e5a0a5 | jkeenan++ | src/ (9 files):
[codingstd] Add codas to .c and .pmc files.
whiteknight Winxed is a separate project. It has a different issue tracker
kid51 Hmm, I pushed some to wrong branch
whiteknight github.com/NotFound/Winxed/issues
Eclesia: you have ++ as post-increment 19:04
it increases AFTER the assignment
self.INC++ would increase it. Or, do self.INC = ++(int(self.INC)); 19:05
kid51 Hmm, I guess 9369d7063f went to the correct branch, after all 19:06
cotto ohai 19:08
Eclesia whiteknight: I see, so i was incrementing the unboxed value only. 19:09
19:11 mj41 joined
cotto not_gerd, what happens when you profile something? 19:11
./parrot -Rprofiling foo.pir 19:12
whiteknight Eclesia: no, you were incrementing the value AFTER the assignment 19:14
you need to increment it before 19:15
not_gerd cotto: seems to work and generates files called parrot.pprof.XXXX 19:18
dalek rrot/whiteknight/6model: ea45636 | jkeenan++ | src/ (16 files):
[codingstd] Add copyright notices. Fix excessively long lines.
 19:21
cotto not_gerd, interesting. 19:23
moritz uhm. 19:25
Are these files actually Copyright (C) 2011, Parrot Foundation? 19:26
I'm pretty sure that parts of these files where developed under a grand from TPF
cotto Yeah. let's revert that commit for the time being.
kid51 Sorry, I thought they were all whiteknight's work. 19:27
19:27 contingencyplan joined
moritz and even if, the CLA is not a copyright assignment 19:28
just a licensing agreement
cotto kid51, that'd be severely impressive coding, even for whiteknight
or bacek, for that matter ;)
kid51 So, who does own the copyright on them?
If PaFo doesn't/won't, perhaps they should be in a github repo other than parrot's. 19:29
cotto I don't mind things like that being in our repo, provide people know not to merge into master until the issues are resolved. 19:30
kid51 Aaah, but cotto: You know how tempting it is to merge things into master ;-) 19:31
cotto I can take a hint.
cotto goes off to fix the g++ build
kid51 cotto: I applied NotFound's patch to this branch; I got different errors on g++ build. 19:32
src/6model/repr_registry.c: In function 'void register_repr(parrot_interp_t*, STRING*, REPROps*)':
src/6model/repr_registry.c:50: error: invalid conversion from 'void*' to 'REPROps**'
src/6model/repr_registry.c:52: error: invalid conversion from 'void*' to 'REPROps**'
make: *** [src/6model/repr_registry.o] Error 1
I'm now trying a gcc build in branch to rule out possibility that codingstd fixes induced errors.
19:33 mj41 joined
kid51 branch builds with NotFound's patch applied, running make test 19:33
So, I suspect we have *different* g++ build problems in this branch. 19:34
Should I commit NotFound's patch to 6model branch?
cotto I don't see any g++ breakage in master atm. NotFound++ 19:35
kid51 Then, I'll apply his patch to branch as well.
cotto kid51, make sure to sync with whiteknight about that. 19:36
kid51 Note: His patch doesn't solve problem of test failures on non-Linux systems.
whiteknight: ping
cotto goes shopping
kid51 msg whiteknight Shall I apply to 6model branch the same patch that NotFound applied to master re select.pmc and g++ build? 19:37
aloha OK. I'll deliver the message.
kid51 whiteknight/6model branch: Linux/i386: all gcc build: smolder.parrot.org/app/projects/rep...ails/22064 Failures in 3 files in make test 19:39
not_gerd good night, #parrot 19:42
nopaste "kid51" at 192.168.1.3 pasted "t/src/checkdepend.t failures in 6model branch" (2409 lines) at nopaste.snit.ch/75208 19:43
19:51 nbrown joined
whiteknight kid51: pong 19:52
kid51: it's not a big deal right now. We can merge from master when it's a good point to do so 19:53
kid51 Alright. As reported above, I suspect we have additional g++ build problems in that branch. 19:55
whiteknight: So who owns copyright on those files you added. 19:56
?
whiteknight kid51: jnthn wrote them, and he's a CLA signatory I believe
he's also consented to them being moved in. We can talk to him about specifics, but I suspect the standard copyright notices are a good start
20:11 mj41 joined 21:11 soh_cah_toa joined
dalek rrot: 67bc4de | nwellnhof++ | src/dynext.c:
Don't use ->strstart in src/dynext.c
 21:23
21:25 Limbic_Region joined
dalek TT #630 closed by nwellnhof++: src/dynext.c uses STRING's ->strstart 21:34
TT #630: trac.parrot.org/parrot/ticket/630
kid51 nwellnof++ for responding to cage cleaner! 21:43
dalek rrot/whiteknight/6model: 4766619 | jkeenan++ | config/gen/makefiles/root.in:
Extensive work on Makefile template to get checkdepend.t into shape.
 21:45
whiteknight nwellnhof! 21:53
dalek nxed: 27f914e | NotFound++ | winxedst1.winxed:
fix bug on new used in void context, reported by Eclesia++
 21:56
cotto ~~ 22:06
whiteknight hello cotto 22:23
22:27 kid51 joined
dalek rrot: fd91687 | jkeenan++ | config/gen/makefiles/root.in:
Declare a Makefile variable for two headers almost always used together.
 23:00
23:08 Coke joined
dalek rrot/whiteknight/6model: c366000 | NotFound++ | / (2 files):
fix C++ build:

Fix wrong usages of modf in the Select PMC		 23:18
whiteknight yay! I love seeing people work on this branch 23:20
NotFound whiteknight: just a cherry-pick 23:23
whiteknight still, it's good
23:23 rfw joined
NotFound Now for some more... 23:23
dalek rrot/whiteknight/6model: 615bd0d | NotFound++ | src/6model/repr_registry.c:
use more appropiate allocation macros for shortness and C++ correctness
 23:25
NotFound Now it builds with C++ in my box
23:33 Kulag joined
whiteknight Awesome! NotFound++ 23:37
NotFound whiteknight: How is a SixModelbject iitialized? I don't see any init vtable 23:42
cotto NotFound, ask jnthn__ 23:43
whiteknight honestly, I have no idea. I haven't been in it enough
I think the metaobject does a lot of it
NotFound A pmc test that fails tries to create one and fails.
Mmmm... there is a exclusion list on it. Easy. 23:44
whiteknight most of it doesn't work yet. I havent bootstrapped the new ops yet 23:46
so some of those new ops may hold answers
dalek rrot/whiteknight/6model: 6e1a418 | NotFound++ | t/pmc/pmc.t:
add SixModelObject to types_we_cant_test for PMC initializaion tests
whiteknight I'll make bootstrap-ops now, see what we can get 23:47
NotFound Now it fails only a test on extend.t 23:48
whiteknight yeah, I added 6model initialization to the interp initialization, so I think that shouldn't happen twice
the NQP source uses a lot of global static variables, so I try to reduce some of that 23:49
NotFound The test is fixed, but we should prevent the crash in the case of new 'SixModelObject' 23:50
whiteknight ok
NotFound The fails in extend.t seems to be infinite recursion 23:51
whiteknight oh, good
I love infinite recursion
NotFound ...and beyond!
23:51 Khisanth joined
whiteknight I love loving infinite recursion 23:52
NotFound I think the bug reported by Eclesia on taicall method Class.new is from parrot, not from winxed. 23:54
whiteknight ok
damnit 23:55
blah, the new 6model.ops file wasn't added by bootstrap-ops
okay, I think I need to add it specifically to compilers/opsc/ops2c.nqp 23:57
since it is helpfully not getting that information from the makefile

Powered by Cro and the Raku® Programming Language.

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

Thank you!