Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (20 to go), merge outstanding branches; profile your favorite PIR for memory leaks with valgrind
Set by moderator on 2 September 2010.
kid51 What does ~~ mean? 00:02
tcurtis I think cotto does that just to say something so that the bots will tell him if he has a msg. (saying this instead of waiting for him to answer you is me doing similar). 00:03
00:04 theory left
Coke kid51: it's a wave. 00:07
the . is just me "what tcurtis said" 00:08
cotto is being more social than I.
00:08 theory joined 00:09 pjcj joined 00:31 contingencyplan left 00:49 whiteknight joined
dalek rrot: r48795 | plobsing++ | trunk/compilers/imcc/pbc.c:
[TT #1763] always register annotations segment with the containing directory
 00:53
00:54 Psyche^ joined 00:55 Paul_the_Greek joined
Paul_the_Greek Evening, kids. 00:55
dalek TT #1763 closed by plobsing++: Memory leak in PackFile_Annotations_new 00:56
TT #1763: trac.parrot.org/parrot/ticket/1763
00:59 Patterner left, Psyche^ is now known as Patterner
dalek kudo: c7f6f27 | kyleha++ | / (2 files):
spectests in git
 01:10
01:32 Paul_the_Greek left
kid51 msg Paul_the_Greek Your proposal for TT #1200 sounds good to me -- though we'll have to poke the people who voiced opinions in the earlier RT to get consensus. 01:42
purl Message for paul_the_greek stored.
aloha OK. I'll deliver the message.
02:11 jjore_ joined 02:12 jjore left 02:30 whiteknight left 02:35 janus left
shockwave Am I right in assuming there is no speed (or semantic) difference between: $P0 = 5 (which is sugar for: $P0 = set 5); and $P0 = assign 5 ? 02:44
plobsing shockwave: for the moment, they are duplicates. One (likely assign) should be eliminated. 02:49
tcurtis plobsing: They appear to have difference definitions. set_p_p does "$1 = $2", assign_p_p calls $1's assign_pmc vtable. 02:51
oh, that's assign_p_i. 02:52
plobsing tcurtis: yes, they differ only for the p_p case AFAICT
shockwave I actually like the duplication. 02:53
I helps keep code outputed consistent.
As in "If the value being assigned is a scalar, use 'assign". Then, it doesn't matter if the rvalue is an literal scalar or a PMC.
That's nice. 02:54
Please, don't remove it.
plobsing but it is inconsistent. set_x vtables are for set. It would make sense for assign_x vtables for assign, except that the only type that actually requires an assign is PMCs because they are reference types and sometimes need value-type assign semantics 02:56
not to mention, assign was added as an attempt to address Parrots assignment weaknesses as perceived by rakudo. I'm no expert, but AFAIK, they failed in that regard. 02:58
s/they/it/
shockwave @plobsing. If the dups are removed, I'm sure I can work around it. If it makes the code cleaner, there is no contest.
but, do NOT remove the assign_p_p one. 02:59
It's a life saver.
plobsing of course. that does something different.
shockwave cool.
plobsing It'll take a deprecation cycle as well. Not experimental, not deprecated. 03:00
shockwave Sounds resonable. 03:01
plobsing shockwave: are you actually successfully using assign_p_p? I'm somewhat surprised something that funky and underused is working. 03:05
shockwave @plobsing: Yes, I started using it today. I'm just about finished with the code generation portion of my compiler, and so I'm taking care of some low hanging fruits of optimizations. One of them is field(attribute) register caching. 03:06
This is so that there are not so many getattribute calls all over the place. 03:07
(and also setattribute)
Because of that change, I now have to use assign to make sure $P0 = $P1 does not have reference semantics when they are of scalar types.
dalek rrot: r48796 | nwellnhof++ | branches/charset_massacre (32 files):
Bring branch up-to-date with trunk
03:13 janus joined
shockwave @plobsing: I'm gonna vote no on that deprecation of the overloaded 'assign' opcodes. They just make things very convenient. 03:20
plobsing shockwave: it's not high on my todo list. and I'm growing unsure of which of set_p_i and assign_p_i is the inconsistent one. 03:22
the more I think about it, set_x_y seems inconsistent. but that would horribly break a lot of existing code generation, pir, and pbc. 03:23
(where x != y)
shockwave @plobsing: Just to re-iterate my reason of is nice to have assign overlap with the functionality: When doing $P0 = assign <scalar>; One doesn't have to worry about whether <scalar> is a literal or a PMC. Otherwise, at least in my implementation, I have to pass around info on whether something is a field (and hence reference) or not. Ugly. 03:25
s/is nice/why is nice/ 03:26
Please, consider my comments "User feedback". 03:27
plobsing what we've done in the past in this sort of situation is to create virtual ops in the pir compiler 03:29
I'm not a big fan of having a "user friendly" assembler though. It's a mess as a result.
03:29 kid51 left
shockwave I'm not sure what "virtual ops in the pir compiler" is. 03:30
plobsing there's likely already ops you use that don't actually exist. they just get translated by the pir compiler to ops or sequences of ops which do. 03:31
shockwave ah, some sort of alias.
Thanks for the help, @plobsing. 03:35
Time for bed. I can't keep my eyes open anymore. 03:36
Peace
03:36 shockwave left 03:49 tetragon left 03:58 ruoso left 04:13 ruoso joined 04:17 nwellnhof_ joined 04:21 nwellnhof left, nwellnhof_ is now known as nwellnhof 04:26 plobsing left 04:28 nwellnhof left 04:48 jsut left 05:42 cognominal left 05:43 cognominal joined 06:00 cognominal left, cognominal joined 06:49 fperrad joined
dalek a: 0b6aff1 | fperrad++ | doc/running.pod:
parrot is installed
 07:13
07:28 wagle left, nopaste left 07:29 wagle joined 07:30 theory left, nopaste joined 07:31 bacek_at_work left, bacek_at_work joined 07:40 contingencyplan joined 08:02 tcurtis left 08:07 jsut joined 08:17 jhelwig left 08:18 p6eval left, Coke left, Coke joined 08:19 s1n left, p6eval joined, bacek left, treed left, treed joined, bacek joined 08:20 s1n joined 09:11 contingencyplan left 10:14 whiteknight joined 10:29 M_o_C joined
bacek aloha, humans 11:22
11:47 elmex left 11:53 elmex joined
whiteknight good morning, bacek 11:55
bacek good evening, whiteknight 11:56
whiteknight bacek: what is the status of gc_massacre? I haven't looked at it in a while 11:57
bacek me too... 11:58
It was require good piece of work - calculating of allocated memory. 11:59
For triggering GC.
And properly encapsulated "String GC" allocations
whiteknight ok 12:01
that was for the gc_ms2.c, right? 12:02
bacek yes
but it's kinda foundation for everything else
e.g. GenGC will still reuse same "String GC" 12:03
and code to calculate allocated memory
whiteknight okay 12:04
bacek: I want to put that project back in the spotlight and try and get it complete ASAP 12:11
bacek me too 12:18
but I don't have much spare time nowdays... 12:19
whiteknight that's fine. I have some time 12:20
bacek Start with splitting "String GC". afair you've got ticket for it :) 12:25
whiteknight ok
bacek whiteknight, #828 12:27
whiteknight Did the gc_massacre branch change anything outside the gc_ms2 core? Can we merge it back to trunk without killing anything? 12:28
I would rather start a new branch that isn't so old
bacek I think so. 12:29
It was little bit of touching other parts, but pretty much encapsulated inside src/gc
whiteknight, I can sync branch with trunk 12:34
in about 10-20 minutes
whiteknight bacek: I would rather just get the changes into trunk and be able to branch from there 12:36
I'l work on that now, see how well it works
bacek there is few conflicts 12:38
whiteknight I'll look into it 12:39
if the merge is no good I won't do it, but I think we can probably get the new files into trunk without breaking anything 12:40
bacek Unlikely... 12:43
I separated "GC Stats" structure.
And trunk's GC has some changes.
whiteknight yeah 12:46
bacek I resolved all conflicts locally 12:48
trying to build branch.
12:50 Paul_the_Greek joined 12:51 M_o_C left, Paul_the_Greek left
whiteknight bah, merge to trunk is far too messy. I won't attempt a merge just yet 12:52
I'll work on the branch in-place
dalek TT #1770 created by Paul_the_Greek++: Boolean PMC without Integer 13:00
TT #1770: trac.parrot.org/parrot/ticket/1770
bacek whiteknight, I updated branch 13:13
beware :)
whiteknight bacek: okay
dalek rrot: r48797 | bacek++ | branches/gc_massacre/t/pmc/io.t:
Remove duplicated test from t/pmc/filehandle.t
 13:17
rrot: r48798 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
Add preliminary support for 'lazy' GC
rrot: r48799 | bacek++ | branches/gc_massacre (259 files):
Merge branch 'master' into gc_massacre

  \tMANIFEST
  \tMANIFEST.SKIP
  \tsrc/gc/alloc_resources.c
  \tsrc/gc/gc_ms.c
  \tsrc/gc/gc_private.h
  \tsrc/gc/mark_sweep.c
  \tsrc/pmc/imageio.pmc
  \tsrc/string/api.c
  \tsrc/string/encoding/utf8.c
  \tt/op/gc-leaky-box.t		 13:34
purl hmmm... MANIFEST is useful for lots of stuff and don't forget to regenerate the manifest with perl tools/dev/mk_manifest_and_skip.pl, unless i am using git-svn
purl hmmm... MANIFEST.SKIP is Makefile.PL$
13:40 jsut_ joined 13:45 jsut left 13:49 M_o_C joined 13:50 M_o_C left 13:52 M_o_C joined 13:56 M_o_C left 13:58 M_o_C joined 14:13 plobsing joined
Coke msg plobsing please be sure to have a chat with pmichaud before ripping out any of those opcodes. kthnxbye 14:15
purl Message for plobsing stored.
aloha OK. I'll deliver the message.
plobsing ~~ 14:16
pmichaud which opcodes? 14:17
plobsing assign_p_x where x != p|pc are exact duplicates of set_p_x 14:18
are you using them for anything? 14:20
pmichaud yes, PCT and Rakudo both use them. 14:21
plobsing they use the non-pmc variants? what for? 14:22
pmichaud well, let's look at this a second.
first, assign_p_s is not the same as set_p_s
plobsing what does "assign_string_native" mean? 14:23
pmichaud "assign" and "set" actually have different meanings, when dealing with references 14:24
plobsing but with immutable strings, strings become more value-ish even if they are still implemented with pointers 14:25
pmichaud pct uses 'assign' for the meaning of "copy a value from source to target"
whereas it uses 'set' for 'bind the target to the source'
pct doesn't want to have to say "if it's an int or num, use 'set', otherwise use 'assign'"
so technically speaking, if you were to get rid of any opcodes, you would need to get rid of the set_p_i and set_p_n variants 14:26
because they're actually doing value copies instead of binds
14:27 macroron joined
plobsing I'm inclined to agree, but that would likely break a large body of existing code. 14:28
pmichaud correct 14:29
so I'm inclined to allow the duplication for now.
plobsing my course of action on this, if anything, would be to translate any eliminated duplicates in the pir compiler. 14:30
such as is done with isgt vs islt now 14:31
s/islt/isle/
pmichaud I'd be somewhat opposed to that approach also. 14:32
plobsing why?
purl why is probably because mysql blargs the big shlong
pmichaud Someday we'd like to be able to generate bytecode directly, without PIR.
and it's kind of a pain if every bytecode generator has to understand that distinction too.
plobsing and when that day comes, you'll have to deal with a less than regular opset
it is already that way. 14:33
pmichaud so, you'd keep 'assign' and remove 'set' but have it translated in the pir compiler? I might be okay with that.
14:33 tcurtis joined
pmichaud I'd be against removing assign and keeping set. 14:33
plobsing yes, set_x_y where x != y isn't really set anyways 14:35
pmichaud at any rate, I feel like it's entirely a false optimization until all assignment-versus-binding issues have been addressed
it's certainly cheaper overall to have both assign and set for the time being
than it would be to have anything have to worry about translating one to the other
plobsing what are the standing issues with assignment-vs-binding?
pmichaud trac.parrot.org/parrot/wiki/WhyDoes...icientCode is part of it 14:38
there's also an issue of lvalue semantics, especially for containers
14:39 shockwave joined
nopaste "shockwave" at 192.168.1.3 pasted "Code snippet to illustrate question." (25 lines) at nopaste.snit.ch/23235 14:41
shockwave Hi.
I have a question about lines 12 and 25 in the code snippet I posted above.
Essentially, I'm trying to assign a refeference-type value to a field(attribute) by assigning to a register that contains a reference to that attribute. It doesn't work as I thought. My question is, what is the semantics of that kind of assignment? 14:43
pmichaud shockwave: parrot doesn't really have a reference type 14:45
plobsing getattribute obtains the value of the attribute, not a reference to the attribute.
pmichaud in rakudo, we ended up creating our own
shockwave err... I remember reading something in some docs about "if you assign this value to the register, the attribute to which this point will be updated", (paraphrasing) 14:46
That's kinda like ref semantics.
pmichaud I don't remember anything like that. 14:47
plobsing where did you read that?
shockwave One sec, let me find it.
docs.parrot.org/parrot/latest/html/...s.pod.html 14:50
Attributes
purl it has been said that Attributes is perlmonks.org/?node_id=631931 or working in roles with MooseX::MethodAttributes::Role or how Catalyst assigns Action types
shockwave "Because PMCs are containers, you may modify an object's attribute by retrieving the attribute PMC and modifying its value. You don't need to call setattribute for the change to stick:" 14:51
pmichaud there are so many things wrong with that statement it's hard to know where to begin.
(and with that example) 14:52
shockwave pmichaud, I think that example works. At least with scalars.
pmichaud shockwave: no, it only works with int/num/str
shockwave Some of my validation tests have been passing, which work like so.
pmichaud $P10 = getattribute 'bar'
$P10 = $P11 # doesn't change 'bar' 14:53
and $P10 = getattribute 'bar' only gives back a PMC if one has been previously set using setattribute
otherwise it ends up being the null PMC, and then doing $P10 = 5 gives a "Null PMC" exception 14:54
plobsing shockwave: you get a PMC back, if you mutate it, you also mutate the PMC contained in the attribute; if you overwrite the register containing it, nothing happens to the attribute
pmichaud and if 'bar' is a non-scalar PMC -- e.g., a Hash or ResizablePMCArray, then $P10 = 5 doesn't do at all what you would expect
shockwave Ok, so it sorta works with ref-semantics for int/num/strings. For PMC, it's something else.
14:55 M_o_C left
shockwave @plobsing: I'm not sure what this means: "if you overwrite the register containing it, nothing happens to the attribute" 14:56
Can you explain that?
pmichaud $P10 = $P11 translates to a set opcode
thus
the above is the same as 14:57
plobsing $P0 = $P1 overwrites the contents of the $P0 register with the contents of the $P1 register
pmichaud $P10 = getattribute 'bar'
set $P10, $P11
in other words, "$P10 = $P11" doesn't mean "copy the value of the PMC at $P11 into the PMC at $P10" 14:58
it means "bind the register $P10 to the PMC at $P11"
and the attribute remains untouched
plobsing pmichaud++ # much better explanation 14:59
shockwave I'm sort of confused. I've kinda been thinking about registers for attributes as essentially acting like C pointer dereferences (*P0 = *P1), but you guys are saying that is more like pointer to pointer assignment, where only the local value is changed, but what is reference to stays the same? 15:01
plobsing exactly. $Px registers are basically pointers. 15:02
shockwave damn 15:03
Just to make sure: It does act like pointer dereference when the rvalue is a scalar: *P0 = 5 ; right? 15:04
plobsing no. it does $P0.set_integer(5). whatever the object in $P0 decides is appropriate happens.
for example, arrays extend or truncate.
shockwave ah, that makes sense. That's why it acts like it's working for scalars, because when assign an int to an Integer register, the value does get updated. Same for floats and strings. 15:05
but the atts are not actually updated to point to the new register. 15:06
pmichaud just keep in mind that '=' in PIR doesn't really mean "assignment" 15:07
it means "set"
shockwave @pmichaud: I'm slowly comming to that realization -- the hard way :|
So setattribute it is for any rvalue that is of reference type. 15:10
Thanks guys.
Coke by "reference type" do you mean "PMC"? 15:11
shockwave @Coke: Sorta. I mean a PMC that is not of scalar type. 15:12
15:12 ruoso left
shockwave A PMC that is int will just be set'ed 15:13
15:14 tetragon joined
Coke no, setattribute is for any PMC 15:16
that is, you can store /any/ PMC in an attribute.
15:18 ruoso joined
shockwave @Coke: I know. I'm just trying not to use setattribute if I don't have to. If I already have a reference to a scalar attribute, say in $P3, then '$P3 = 5' works better than the setattribute counterpart. 15:18
The discussion above was about how such thing would not work on Reference type pmcs (PMCs which are not scalar). 15:19
pmichaud setattribute simply binds an object's attribute to a PMC
shockwave @pmichaud: You're saying that "setattribute 'x', $P1" is more efficient than "$P1 = $P2" when both are ints? 15:22
pmichaud shockwave: no.
shockwave: I'm simply saying what setattribute does.
shockwave @pmichaud: I wasn't being defiant, I was just trying to understand. 15:23
pmichaud "rvalue of that is of reference type" doesn't really make sense to me
shockwave That means an rvalue which is a PMC whose value is not scalar.
pmichaud that still doesn't make sense to me. 15:24
plobsing all PMCs are reference types by definition
pmichaud neither does that
I guess I don't know what you mean by 'reference type'
shockwave It's something I'm making up to explain the concept in my mind of: 15:25
A) if $P1 is an attribute, and $P2 is a PMC that is of scalar type, then: $P1 = $P2 behaves like *$P1 = *$P2. 15:26
pmichaud $P1 is never an attribute. That's where the model breaks down.
$P1 is a register, it points to a PMC.
it may happen to point to a PMC that an attribute is also pointing to 15:27
shockwave $P1 is a register which points to an attribute.
pmichaud no
$P1 is a register that points to a PMC that an attribute may also be pointing to
but $P1 never refers to an attribute as an attribute
shockwave Ok, with your definition, it ends up meaning the same thing for me (though, thanks for the clarification). The new definition would then be: 15:28
$P1 is a register that points to a PMC that an attribute is also pointing to.
pmichaud setattribute simply changes the PMC that an attribute points to 15:29
shockwave Using the mathematically law of transitivity: a = b = c == a = c
pmichaud I should rephrase that.
setattribute simply causes an attribute to point to a PMC 15:30
shockwave This could mean, then, that setattribute $P1, $P2 -- where $P2 is a scalar PMC -- could be more effecient that $P1 = $P2, which calls $P1.set_integer() 15:31
pmichaud 15:26 <shockwave> A) if $P1 is an attribute, and $P2 is a PMC that is of scalar type, then: $P1 = $P2 behaves like *$P1 = *$P2.
this is wrong.
$P1 = getattribute obj, 'foo'
plobsing shockwave: $P1 = $P2 never calls $P1.set_integer() 15:32
pmichaud $P2 = box 5
$P1 = $P2 # 'foo' is unchanged
plobsing $P1 = 5 does, but that is because it is equivalent to '$I0 = 5; $P1 = $I0'
shockwave Yes, in this case it would be: $P1 = assign $P2, which does call $P1.set_integer() 15:33
pmichaud all that "$P1 = $P2" does is cause the register $P1 to point to the PMC given by $P2
it doesn't actually change the values of any PMCs
shockwave It's my fault that I've been leaving out the 'assign' opcode in: $P1 = assign $P2 15:34
This is, of course, totally confusing and different. 15:35
I apologize for that.
The assign opcode would only be used when $P2 is of scalar type. 15:36
plobsing why?
purl why is because mysql blargs the big shlong
shockwave That's what I meant that they acted like: *P1 = *P2
plobsing purl, forget why 15:37
purl plobsing: I forgot why
shockwave @plobsing: Why...What? Why does the assign opcode be used only for scalar PMCS? 15:38
plobsing why only for scalar types?
shockwave If so,
Because when $P2 is of non-scalar types, it tries to call set_pmc vtable func. It's much easier to just use setattribute in that case.
So, using the last definition of $P1 above, as clarified by pmichaud, where $P1 ends up being a PMC that points to a an attribute that points to another PMC; then: 15:40
$P1 = assign $P2; when $P2 is a scalar
and
setattribute self, 'x', $P2 ; when $P2 is non-scalar 15:41
that should give me the types of semantics for $P1 = $P2 that is seen on an HLL, like, say, PHP.
Correct?
tcurtis shockwave: $P1 = assign $P2 always calls the assign_pmc vtable. 15:42
shockwave @tcurtis: But those are defined for ints/nums/strings, right, so they just work out of the box.
pmichaud shockwave: not really correct, no.
certainly not like PHP, at any rate. 15:43
tcurtis shockwave: The default assign_pmc delegates to set_pmc unless the RHS is Undef. 15:47
shockwave So, what is the bottom line? setattribute is *always* the best, most efficient choice?
(in the use-cases I posted above)
tcurtis Ah, wait, scalar does define assign_pmc.
shockwave I'll post the HLL language use case I'm trying to solve.
pmichaud shockwave: you're asking about efficiency, which to me implies a functional equivalence that doesn't really exist 15:48
consider: 15:49
$P1 = split ' ', 'the quick brown fox'
setattribute obj, 'foo', $P1
$P2 = pop $P1
PHP semantics would expect that $obj.foo still contains 4 elements. In PIR, $obj.foo contains three.
moritz becase = is binding in PIR, not assignment 15:50
*because
pmichaud because *setattribute* is binding
15:50 AzureStone left
pmichaud in PHP, $array = ('the','quick','brown','fox'); $obj.foo = $array; array_pop($array); would leave $obj.foo untouched 15:51
(sorry, that should be $obj->foo = $array for proper syntax) 15:52
nopaste "shockwave" at 192.168.1.3 pasted "HLL example" (26 lines) at nopaste.snit.ch/23236 15:55
shockwave the syntax above is supposed to be: public class Test { // but that's not important. 15:56
The example above shows the types of semantics I'm looking for. 15:57
In the first Test, when field2 is assigned to field1, the contents of field2 are copied into field one, but field 2 remains untouched. 15:58
In Test2, when field2 is assigned to field1, they end up pointing to the same object.
s/object/instance
If we thought of field one as $P1 and field2 as $P2, then in Test 1, $P1 = assign $P2; and I guess in Test2 it would be setattribute self, 'field1', $P2 16:02
pmichaud sure, okay. it runs into issues later, but the opcodes you've identified will give you something of the semantics you want for this case. 16:03
shockwave pmichaud: What I was trying to find out was: A) will these give me sematics I'm looking for (which you just answered), and B) is what doing the most effecient way of doing it (as opposed to always using setattribute). 16:05
Man, I've learned more in the last 2 days about PIR's assignment semantics than I did in the past 6 months. 16:06
16:08 theory joined
pmichaud in the case of B), you're talking about two different scenarios though. 16:09
in the first (Test) case, using setattribute won't give you the same semantics 16:10
shockwave @pmichaud: Oh, sorry. You're right. Set attribute doesn't work for the first attribute. 16:11
I still asked the same question as when I came in, even thought it was answered during the discussion. 16:12
mikehh plobsing: ping
shockwave setattribute doesn't work for the first usecase. It should be: $P1 = assign $P2
Thanks for the remainder. 16:13
s/Set attribute doesn't work for the first attribute./setattribute doesn't work for the first use-case.
Thank you very much guys for being so patient and helpful. I'm gonna go implement this, now. 16:17
luben hello everybody 16:21
purl Hello Dr. Nick!
luben recent parrot segfaults when configured with --optimize
dalek rrot: r48800 | nwellnhof++ | trunk (2 files):
[pmc] Fix String.is_integer
 16:22
luben ok, fixed by nwellnhof++ 16:23
plobsing mikehh: pong 16:24
mikehh plobsing: I am getting g++ build failures with src/pmc/nci.pmc - line 359 16:27
plobsing: ok with gcc but warnings 16:28
luben no, it is not fixes, still segfaults
purl okay, luben.
plobsing mikehh: I'll look into it. 16:29
mikehh plobsing: ./src/pmc/nci.pmc:359: warning: assignment from incompatible pointer type - also
./src/pmc/nativepccmethod.pmc:116: warning: assignment from incompatible pointer type
plobsing: same assignment 16:31
so it will probably also blow up in g++
I tried adding (nci_thunk_t) but it needs more 16:32
plobsing should be resolved in r48802. 16:36
mikehh plobsing: trying now 16:38
dalek rrot: r48801 | mikehh++ | trunk/MANIFEST.generated:
fix distro_tests failure - add pmc/nativepccmethod files to MANIFEST.generated
 16:39
rrot: r48802 | plobsing++ | trunk/src/pmc (2 files):
add casts to placate C++
mikehh plobsing: looks like it works 16:45
plobsing: that's what comes from not looking closely enough at the output - fixed the first but got the error on the second - thought the error was still the first :-{ 16:54
luben msg chromatic it seems that r48783 (Removed GC blocking when installing subs) introduced a bug when parrot is compiled with --optimize 17:07
purl Message for chromatic stored.
aloha OK. I'll deliver the message.
17:09 M_o_C joined 17:25 AzureStone joined
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets ( 17:29
dukeleto says darn 17:29
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (12 to go), merge brances; profile your favorite PIR for memory leaks with valgrind 17:29
dukeleto Everyone: please update the closed ticket count in the /topic when you see a ticket closed. It should be correct now. 17:30
whiteknight cannot make hll_map work today
pmichaud ...is anything using String.is_integer? 17:31
that seems like a method that wants deprecation. 17:32
whiteknight I think I would agree 17:34
pmichaud log says it was added in dec 2005 but doesn't give any indication why 17:36
dukeleto pmichaud: do you have a chance to make me an admin on the parrot github org, so I can add others?
pmichaud dukeleto: done. 17:37
17:37 davidfetter joined
dukeleto pmichaud++ 17:38
davidfetter: howdy
purl que tal, dukeleto.
davidfetter hai dukeleto
davidfetter getting ready to grill some grillables
well, to prep the things that will eventually be grillables ;) 17:39
pmichaud looks like String.is_integer was (is?) being used by partcl
at least, that's what the surrounding log entries indicate.
it doesn't appear to be used by partcl anymore, however. 17:40
whiteknight dukeleto++ 17:42
nopaste "Whiteknight" at 192.168.1.3 pasted "Can anybody see why this snippet doesn't work?" (25 lines) at nopaste.snit.ch/23237 17:43
whiteknight this hll_map thing is killing me
pmichaud whiteknight: ...you aren't in a different HLL? 17:47
I don't know if you can remap things inside of the 'parrot' HLL. 17:48
whiteknight pmichaud: hmmm... damnit 17:49
luben msg chromatic Ignore my previous message, the error is somewhere in porting string_join to string_builder. It manifests in Parrot_str_clone - s->strstart is out of bounds
purl Message for chromatic stored.
aloha OK. I'll deliver the message.
whiteknight pmichaud: is there anyway to specify an HLL in NQP?
Coke dukeleto: if everyone updates the ticket count, it's going to be updated too many times. 17:50
dukeleto Coke: the first one to see a closed ticket does it 17:51
pmichaud whiteknight: depends on where you're wanting to specify it
whiteknight pmichaud: I have a test file that I'm trying write to test hll maps 17:52
so I can put it anywhere in the file
Coke dukeleto: and how do I know I'm the first one?
dalek kudo: 77a72a3 | pmichaud++ | src/core/IO.pm:
Refactor slurp($filename) to use Parrot's .readall($filename);

See TT #1749 for related parrot details.
pmichaud whiteknight: if you're wanting an nqp program to run in a different hll namespace -- no, we don't have that yet. 17:53
I've been thinking of a 'use hll ...' pragma but haven't implemented it yet.
dukeleto Coke: irclogs 17:54
Coke: if you see a closed ticket line on IRC, and the topic hasn't changed, you are the first one to see it
tcurtis: what is your github id? 17:57
tcurtis dukeleto: ekiru
Coke dukeleto: PITA. You're on your own. 18:00
whiteknight I feel like that has to be a bug. Why wouldn't we be allowed to override type mappings in the default HLL? 18:02
dukeleto Coke: come up with something better. Please.
Coke: a bot could update it, i guess. 18:03
plobsing doesn't trac have a database that could be queried? 18:04
whiteknight pmichaud: as a basic estimation, how difficult would a "use hll" pragma be to implement? I'll happily do it myself, just looking for an idea of how much time I need to set aside 18:06
Coke dukeleto: we don't care about that number enough to update it in realtime.
s/we/I/
whiteknight Coke: if he cares enough, don't discourage him!
Coke and it's easy enough to calculate from the timeline.
whiteknight: he's not saying he'll do it, he's trying to get other people to do it for him. ;)
whiteknight dukeleto: it may be an SQLite3 DB 18:07
Coke trac.parrot.org/parrot/timeline?fro...ate=Update 18:08
mikehh t/examples/namespace.t - Failed => get_string() not implemented in class 'NativePCCMethod
all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48802 - Ubuntu 10.04 amd64 (g++)
pmichaud whiteknight: I don't think it would take very long. 18:10
szbalint dukeleto: why don't you set a milestone for it and grab ticket numbers based on that?
dukeleto szbalint: i don't actually know how to do that 18:14
whiteknight pmichaud: okay. I have a few minutes to spare today since I can't get these tests written. I'll take a stab at a patch
18:14 theory left
dukeleto Parrot has a proper avatar on github! github.com/parrot pmichaud++ 18:14
pmichaud whiteknight: essentially, upon seeing the 'hll' pragma you want to change the 'hll' attribute of the current PAST::Block to match. 18:15
whiteknight okay. I was hoping it would be so easy
pmichaud well, I don't know what roadbumps might be in the way :-)
dukeleto Coke: I didn't start the "update the ticket count in the topic meme", but it seems useful. just trying to make it continue 18:16
18:17 contingencyplan joined
whiteknight pmichaud: I'm not super-duper familiar with this repo. I'm updating stage-0? stage-1? stage-2? 18:17
18:18 PacoLinux left
pmichaud none 18:18
you'd want to update NQP/Grammar.pm and NQP/Actions.pm
we don't write NQP in pir anymore :-)
stage[012] are all generated files. 18:19
looks like src/NQP/Grammar.pm needs a 'use' statement
whiteknight ah, right. Sorry. I see where I need to go now
thanks
szbalint dukeleto: ther is already a 2.8 milestone actually. You can modify tickets the normal way to assign them to milestones and this will give you a nice overview: trac.parrot.org/parrot/milestone/2.8 (nothing there yet atm, as no tickets are assigned to 2.8) 18:20
pmichaud and then src/NQP/Actions.pm would need an action method to handle the 'use' statement
szbalint *there
dalek TT #1771 created by whiteknight++: Cannot hll_map in parrot HLL 18:21
TT #1771: trac.parrot.org/parrot/ticket/1771
dukeleto szbalint: thanks for that info, but I am not sure that solves our issue. We just want a count of how many tickets were closed in time period X 18:23
18:25 nwellnhof joined
szbalint ah I see. I misunderstood your intention :) 18:25
moritz dukeleto: re parrot on github/branches, I like the prefix approach 18:28
nopaste "plobsing" at 192.168.1.3 pasted "[PATCH] HLL mapping for root hll" (34 lines) at nopaste.snit.ch/23238 18:29
moritz dukeleto: just ignore any branches that contain a '/', so that we can have branches named topic/gc or cleanup/configure or so
plobsing whiteknight: I can get your example to work with the patch at nopaste.snit.ch/23238 18:30
whiteknight plobsing++. I figured it would be an easy fix, I'm wondering whether there is a design or policy reason why the current behavior is what it is 18:31
but thanks for putting together a patch so quickly!
pmichaud I'm guessing the design reason is to keep type lookups in the parrot HLL fast 18:32
otherwise things can get really slow really quick. 18:33
whiteknight that would be a reasonable explanation. I would need to look to see if there would be a performance issue 18:34
pmichaud just from looking at the lines surrounding that patch, there is.
when not in the parrot HLL, Parrot_get_HLL_type ends up doing two array lookups 18:35
(and possibly more)
I must be reading this wrong. 18:39
It looks like you pay those lookup penalties simply for declaring your language in a different HLL, whether you map a type or not.
whiteknight we can identify the common case where there are no HLL maps in the root HLL, and not look at all
pmichaud that's not the "common case", from a hll perspective. Sorry.
whiteknight it is in the root HLL
obviously, since there never has been a working map in that HLL 18:40
pmichaud Seems to me that the better approach would be to make type mapping more efficient for all hlls, not just the parrot HLL.
18:40 Andy joined
whiteknight yes, that's very true 18:41
I have to go for a little bit. I'll be back later tonight 18:42
18:42 whiteknight left
pmichaud it's worth noting that the lines 18:45
- if (!hll_id || hll_id == PARROT_HLL_NONE)
- return core_type;
-
were added very recently (r48486) by chromatic
added on 2010-08-13, in fact. It'd be strange to take them back out :-) 18:46
18:47 kid51 joined 18:48 macroron left 18:55 PacoLinux joined 18:58 kid51 left
dukeleto moritz: yeah, ignoring branches with a / sounds like a good approach 19:01
moritz: to be more specific, not deleting github branches with a / sounds like a good approach 19:05
19:05 NotFound joined
NotFound Hi 19:05
moritz dukeleto: that's what I meant, yes
dukeleto NotFound: wilkommen 19:06
smash hello everyone 19:24
dalek rrot: r48803 | nwellnhof++ | trunk (2 files):
[pmc] StringBuilder should update compatible encodings
 19:27
dukeleto moritz: i've updated my script to not remove branches with /'s, thanks for the suggestion 19:35
cotto dukeleto++ 19:59
pmichaud gist.github.com/566282 # why Parrot's GC is so painful :( 20:10
gist.github.com/raw/566282/69c06d2e...file1.perl # without github formatting ugliness
GeJ Bonjour everyone. 20:12
moritz pmichaud: maybe write that as an example to the mailing list, just to make sure everybody is aware of that problem to its full extend 20:13
pmichaud moritz: yes, I've been thinking of doing just that. 20:15
20:20 mikehh left
dukeleto pmichaud: so that says that parrot is spending ~20s to load perl6.pbc and the associated GC runs? just making sure I understand 20:20
moritz dukeleto: afaict it spends the time in long marker&sweep runs, because there are many more objects 20:21
and they are reconsidered every time anew
pmichaud dukeleto: no. It takes less than ~1 sec to load perl6.pbc 20:25
After after loading perl6.pbc, it takes 20 seconds to slurp the file. 20:26
20:26 mikehh joined
pmichaud message sent to parrot-dev 20:33
purl Message for sent stored.
NotFound I have a segfault during build in amd64 with --optimize 20:34
r48802
luben NotFound, me too. It seems that bug is manifested with gcc-4.5 and not with gcc-4.4 20:35
I have tracked it to sting_join porting to StringBuilder 20:36
NotFound Ugly 20:37
luben gcc-4.4 -O3 shows another bug, but I am not sure if it is related 20:38
dukeleto i've started a git workflow doc. it is nascent, but it is a start! github.com/parrot/parrot/blob/leto%...rkflow.pod 20:42
20:46 tcurtis_ joined, tcurtis left, tcurtis_ is now known as tcurtis
dukeleto pmichaud: ah, i understand now 20:47
gcc bugs, oh my!
luben dukeleto, I think it is not bug in gcc
NotFound My segfault is in CodeString.pmc. I thought CodeString was deprecated. 20:48
dukeleto luben: that is slightly more comforting
NotFound: eligible in 2.7 20:49
NotFound dukeleto: sometimes I assume that when we deprecate things we stop using them.
dukeleto NotFound: it looks like PGE and a few tests use it 20:52
NotFound dukeleto: yeah, and that's why parrot doesn't build 20:53
dukeleto NotFound: nqp-rx needs it to actually
NotFound Then why is eligible?
dukeleto NotFound: ext/nqp-rx/src/stage0/Regex-s0.pir uses it
NotFound No need to answer that. 20:54
dukeleto NotFound: ok :)
20:54 theory joined
sorear Regex-s0.pir is not a source file 20:55
NotFound The funny thing is that the backtrace shows a line where Parrot_str_join is called and the next frame is in Parrot_str_clone
dukeleto sorear: yes, i know it is generated, but it still uses a codestring PMC 20:57
NotFound: are you using an optimized build?
NotFound dukeleto: without --optimize it build 20:58
bacek aloha, humans 21:00
mikehh hiho bacek 21:04
bacek hi mikehh
cotto aloha, bacek 21:06
dukeleto++ again 21:08
dukeleto NotFound: adding in debug symbols might be useful. might not 21:09
cotto: danke. working on the git workflow docs now!
21:40 Andy left 21:42 tcurtis left 21:51 luben left, luben joined 22:02 fperrad left
NotFound Axiom: every time we abuse string internals we create subtle bugs. 22:12
22:27 M_o_C left 22:32 plobsing_ joined
dalek rrot: r48804 | NotFound++ | trunk/src/pmc/stringbuilder.pmc:
build a new string from the buffer instead of cloning a not fully valid string in StringBuilder get_string
 22:32
luben NotFound, ping 22:42
NotFound pong 22:43
luben NotFound, does the last commit fixes the bug for you
NotFound luben: yes
luben strange, I am trying here with -O3 and is still here... I have some differend fix that I am testing now 22:44
NotFound luben: amd64?
purl amd64 is Hammer, yeah.
luben yes
pastebin.com/iTLxTXVW 22:50
this is my suggestion. it fixes optimized builds on amd64 (-O2 and -O3)
it works successfully with parrot_str_clone in StringBuilder 22:51
NotFound I don't like that much gc blocking
luben neither do I 22:52
bacek you don't need GC blocking in this case 22:53
C<result> will be handled by GC properly
luben bacek, trying here 22:54
:( it segfaults 22:55
I thing that not C<result> is collected here 22:56
but part of the string that is in process to be joined 22:57
bacek than it's bug in StringBuilder I think
luben May be yes. Previous Parrot_str_join was blocking GC, during its job, so I just used the same approach 22:58
bacek previous approach was workaround for STRING**. 23:00
Current approach doesn't require it
NotFound Blocking gc in loops with a lot vtable calls to pmc of unknown types isn't exception safe. 23:01
bacek afk # dayjob 23:02
luben OK, than it is a bug in StringBuilder 23:04
nopaste "luben" at 192.168.1.3 pasted "join patch" (59 lines) at nopaste.snit.ch/23239 23:10
luben this is the same, rearranged patch - if it turns usefull somehow. 23:11
23:11 pjcj left 23:12 pjcj joined
NotFound luben: try r48805. Shouldn't be directly related with the problem, but who knosw. 23:12
luben OK
yes, it is fixed 23:16
NotFound Amazing 23:21
luben here, it works also with Parrot_str_clone in StringBuilder.get_string 23:22
dalek rrot: r48805 | NotFound++ | trunk/src/pmc/codestring.pmc:
use concat instead of join when possible in CodeString
 23:23
NotFound The problem probably lies in cloning a STRINGNULL 23:25
Or a NULL
nwellnhof NotFound: i found a possible problem in Parrot_str_clone 23:38
NotFound nwellnhof: Only one? ;) 23:41
nwellnhof only one. but it looks like the stringbuilder is likely to trigger it. 23:42
i just made a commit
but i never had any stringbuilder related crashes 23:43
NotFound nwellnhof: looks like is crashing only in amd64 optimized builds 23:46
s/is/was
nwellnhof i'm on 32bit here 23:47
23:47 smash left 23:48 smash joined, smash left 23:52 plobsing_ left
dalek rrot: r48806 | nwellnhof++ | trunk/src/string/api.c:
[str] Set buflen in str_clone
 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!