Camelia, the Perl 6 bug

IRC log for #parrot, 2010-10-03

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:13 dalek parrot: r49425 | plobsing++ | trunk (7 files):
00:13 dalek parrot: probe for INFINITY and NAN macros provided by system headers
00:13 dalek parrot: papers over SIGFPE errors on various platforms (netbsd-alpha, minix-i386-ack)
00:13 dalek parrot: see TT #574
00:13 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49425/
00:36 ruoso left #parrot
00:59 dalek parrot: r49426 | mikehh++ | trunk (6 files):
00:59 dalek parrot: ran make headerizer, added missing PARROT_CAN_RETURN_NULL
00:59 dalek parrot: re-ran make headerizer - test ok
00:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49426/
00:59 dalek parrot: r49427 | mikehh++ | trunk/config/auto/infnan.pm:
00:59 dalek parrot: remove hard tabs
00:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49427/
00:59 dalek parrot: r49428 | mikehh++ | trunk/config/auto/infnan.pm:
00:59 dalek parrot: remove more hard tabs (missed two)
00:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49428/
01:03 PerlPilot joined #parrot
01:04 Util left #parrot
01:08 PerlJam left #parrot
01:30 dalek parrot: r49429 | nwellnhof++ | trunk (9 files):
01:30 dalek parrot: [str] Prepare deprecation of string_* functions
01:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49429/
01:30 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#403) fulltest) at r49428 - Kubuntu 10.10 RC amd64 (gcc-4.5 with --optimize)
01:31 * mikehh needs a break - bbl
01:43 nwellnhof left #parrot
02:35 janus left #parrot
03:00 janus joined #parrot
03:31 dukeleto_ joined #parrot
03:39 ttbot Parrot trunk/ r49429 MSWin32-x86-multi-thread make error http://tt.taptinder.org/file/cmdout/405193.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
03:41 eternaleye left #parrot
03:42 eternaleye joined #parrot
03:43 dukeleto_ that ttbot error is 'api.obj : error LNK2019: unresolved external symbol _floatval_divide_by_zero referenced in function _Parrot_str_to_num'
04:54 Coke partcl (old) now thinks that 1/3. is "0" instead of "0.33333". wonder when that happened.
05:34 dukeleto_ left #parrot
05:48 * Coke blows another potentially productive hacking session tracking down a parrot issue.
05:48 * Coke cries.
05:49 Coke -> abed.
05:49 plobsing Coke: is it doing integer divide for some reason?
05:52 Coke at a guess, new_init_int doesn't respect HLL types.
05:52 Coke which would be a huge problem. ;)
05:53 cotto aloha msg whiteknight Your fork of parrot-instrument doesn't build for me with the latest parrot.
05:53 aloha cotto: OK. I'll deliver the message.
05:55 plobsing how could new_init_int respect HLL types? it uses INTVAL which isn't a PMC and therefor cannot be overriden
05:58 Coke then we can't use it.
05:58 Coke wait, what?
05:58 Coke no, on the /creation/
05:59 Coke not the actual int value.
05:59 Coke the pmc type that is created is always Integer, not HLL_mapped(integer)
05:59 plobsing well of course. new_init_int asks for a specific class. If you want hll-mapped types, you should use box.
06:00 Coke GAHR>G
06:00 Coke /I/ am not using anythign.
06:00 Coke this is in src/pmc/integer.pmc, which I am extending.
06:02 Coke the invocation of pmc_new_init_int is using type(SELF), which is probably wrong. I'm guessing that DYNSELF might be more appropriate.
06:03 Coke hurm. dynself is no longer valid.
06:03 Coke anyway, I'll leave this for someone else to fix. bedtime.
06:03 plobsing sounds like deep magic
06:03 Coke nope.
06:04 tcurtis Aren't vtables always dynamically dispatched?
06:05 plobsing tcurtis: STATICSELF.vtable_name bypasses dynamic dispatch in the name of expedience
06:06 cotto SELF is the new DYNSELF
06:06 tcurtis plobsing: ah. But, VTABLE_type(INTERP, SELF) doesn't, no?
06:06 dalek parrot: r49430 | plobsing++ | trunk/include/parrot/datatypes.h:
06:06 dalek parrot: use has_header appropriately. should fix win32 build.
06:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49430/
06:07 plobsing tcurtis: true. the VTABLE macros do dynamic dispatch. as does the SELF.vtable pmc2c syntax sugar
06:08 plobsing I'm just saying that not *all* dispatches to vtables are dynamic
06:08 plobsing PCC also plays fairly fast and loose with the inards of sublike objects
06:11 ttbot Parrot trunk/ r49430 MSWin32-x86-multi-thread make error http://tt.taptinder.org/file/cmdout/405374.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
06:15 plobsing OK I really don't know how to fix that win32 build failure. I probe for a feature and provide implementations for both existant and non-existant cases.
06:16 plobsing windows decides to try to use both cases at the same time
06:23 tcurtis left #parrot
06:38 jsut joined #parrot
06:43 jsut_ left #parrot
07:14 theory left #parrot
07:21 Kulag left #parrot
07:21 Kulag joined #parrot
07:30 Kulag left #parrot
07:34 Kulag joined #parrot
07:41 eternaleye left #parrot
07:42 Drossel joined #parrot
07:43 Kulag left #parrot
07:46 eternaleye joined #parrot
07:53 Drossel left #parrot
07:54 Kulag joined #parrot
07:55 tadzik joined #parrot
07:59 Kulag left #parrot
07:59 Kulag joined #parrot
08:04 Drossel joined #parrot
08:06 Kulag left #parrot
08:13 Drossel left #parrot
08:15 PacoLinux left #parrot
08:17 Patterner left #parrot
08:35 Kulag joined #parrot
08:43 Kulag left #parrot
08:44 Kulag joined #parrot
08:44 mj41 left #parrot
08:45 Patterner joined #parrot
08:52 Kulag left #parrot
08:55 mj41 joined #parrot
09:01 pmichaud left #parrot
09:03 ash_ joined #parrot
09:05 davidfetter left #parrot
09:11 Kulag joined #parrot
09:19 Kulag left #parrot
09:22 Kulag joined #parrot
09:41 Kulag left #parrot
09:42 Kulag joined #parrot
10:00 ash_ left #parrot
10:07 Kulag left #parrot
10:07 Kulag joined #parrot
10:11 sjn left #parrot
10:12 sjn joined #parrot
10:22 Kulag left #parrot
10:25 Kulag joined #parrot
10:25 jsut_ joined #parrot
10:29 jsut left #parrot
10:33 Patterner left #parrot
10:37 Kulag left #parrot
10:37 Kulag joined #parrot
10:43 Kulag left #parrot
10:49 mikehh left #parrot
10:54 Kulag joined #parrot
10:57 Patterner joined #parrot
11:06 Kulag left #parrot
11:08 Kulag joined #parrot
11:11 Patterner left #parrot
11:29 Patterner joined #parrot
11:31 whiteknight joined #parrot
11:51 mikehh joined #parrot
11:58 whiteknight good morning, #parrot
12:19 mikehh hi whiteknight
12:19 mikehh BTW we still have a problem with the Windows build on Taptinder
12:29 mikehh left #parrot
12:29 mikehh joined #parrot
12:34 kid51 joined #parrot
12:41 whiteknight blargh
12:41 whiteknight I love good news in the morning
12:47 kid51 good morning, whiteknight
12:50 whiteknight hello kid51. How are you today
12:50 whiteknight ?
12:50 kid51 I'm getting ready to go back to NYC
12:52 whiteknight oh, you're out west this weekend, aren't you?
12:52 kid51 No, I've been in Toronto since Wednesday.  Out west is next week.
12:54 whiteknight ah, sorry. I am not good at remembering my own schedule, so there's no way I get yours correct
13:15 kid51 left #parrot
13:20 Patterner left #parrot
13:30 Psyche^ joined #parrot
13:30 Psyche^ is now known as Patterner
13:50 jan left #parrot
13:55 whiteknight left #parrot
13:59 Coke Infinoid++
13:59 Coke # svn-bisect
14:15 PacoLinux joined #parrot
14:35 Infinoid woohoo, free karma :)
14:39 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#414) fulltest) at r49430 - Ubuntu 10.10 RC amd64 (g++-4.5 with --optimize)
14:56 jan joined #parrot
15:13 cotto ~~
15:29 ash_ joined #parrot
15:41 tadzik left #parrot
15:53 tadzik joined #parrot
16:02 mikehh plobsing: you around
16:11 davidfetter joined #parrot
16:18 AzureStone left #parrot
16:20 dalek parrot: r49431 | mikehh++ | trunk/src/datatypes.c:
16:20 dalek parrot: change #ifdef to #ifndef (comes into play only if not defined) - this should fix the windows build
16:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49431/
16:22 mikehh I think the last comment on TT #922 is spam
16:26 * mikehh waiting patiently for TapTinder
16:26 * mikehh I lie
16:33 AzureStone joined #parrot
16:41 plobsing mikehh: pong
16:44 mikehh plobsing: I think I fixed the Windows build problem in r49431, not sure - waiting on TapTinder
16:45 plobsing now that I've had some time to think about the problem, I think the problem is that I'm using #ifdef in stead of #if
16:46 plobsing but we'll see if your fix works
16:46 mikehh it never failed on the X86_64, just the i386 build
16:47 mikehh I thinkl it is related to the PARROT_HAS_INF_NAN test
16:47 plobsing maybe win64 has INFINITY and NAN defined in math.h
16:49 mikehh still waiting for the result - it has done the rest
16:51 plobsing maybe the machine gave up
16:52 M_o_C joined #parrot
16:53 dukeleto_ joined #parrot
17:15 AzureSto_ joined #parrot
17:17 AzureStone left #parrot
17:26 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#415) fulltest) at r49431 - Ubuntu 10.10 RC amd64 (gcc-4.5)
17:28 dukeleto_ left #parrot
17:28 dukeleto_ joined #parrot
17:31 mikehh bah TapTinder is still running the build for MSWin32/i386 (and the tests for cygwin/i386)
17:36 mikehh Great it build ok
17:37 plobsing yay. you fixed it! mikehh++
17:41 mikehh plobsing: it took me a couple of hours to find it - a one letter change :-{
17:42 mikehh plobsing: it's pretty obvious in retrospect, but those are the sort of things that take forever
17:43 mikehh it's called HINDsight :-}
17:50 patspam joined #parrot
17:50 patspam left #parrot
17:53 theory joined #parrot
18:08 tadzik left #parrot
18:09 tadzik joined #parrot
18:28 tadzik left #parrot
18:35 cotto mikehh, you would be the one to have that. ;)
18:42 mikehh you would be surprised how many people I have to tell that my name is prounced as in HINDsight NOT HINDia
18:43 cotto You could tell people your middle name is "B".
18:44 cotto though that could have other unintended effects
18:44 mikehh he - it's H
18:44 cotto Sure, but "hehind" isn't a word.
18:45 mikehh could bring out the donkey in me
19:09 dalek parrot: r49432 | plobsing++ | trunk/src/scheduler.c:
19:09 dalek parrot: process events on sleep start even if parrot doesn't have threads
19:09 dalek parrot: This isn't the best solution. the thread will execute all pending tasks and then sleep for the specified duration in stead of executing pending tasks during the sleep interval. But it does prevent coretest from hanging on t/pmc/timer.t on threadless platforms.
19:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49432/
19:25 ash__ joined #parrot
19:29 ash_ left #parrot
19:29 ash__ is now known as ash_
19:30 theory left #parrot
19:32 nopaste "bluescreen" at 192.168.1.3 pasted "Can this patch be a possible fix for ticket #1769 (morph not working)" (22 lines) at http://nopaste.snit.ch/23943
19:37 plobsing that seems wrong to me. morphing should only work on things that have a well defined way to morph (eg: by setting up the vtable override)
19:40 bluescreen plobsing: you saying that  objects should not morph?
19:41 plobsing not at all. the code right above your patch handles morphing on types that define how to do it.
19:42 plobsing morphing of types that don't know how seems like it would be doomed to failure
19:43 plobsing for one, the attributes would be completely jumbled
19:43 bluescreen agree, objects can may totally different from one to another
19:44 bluescreen so then morph should throw an exception for objects that doesn't have an override
19:46 jnthn That patch is doomed to epic fail.
19:47 plobsing bluescreen: quite probably. alternatively, have a look at Parrot_pmc_reuse_by_class
19:47 jnthn Possibly morph to a super or subclass could be made to work.
19:47 jnthn Rakudo has an op for doing it int he subclass direction.
19:48 bluescreen jnthn: is the same thing coz subclasses can have different attribs
19:48 plobsing jnthn: that's more the job of the metamodel and is fully supported by adding a morph vtable override
19:48 jnthn bluescreen: importantly, ti's a sueprset.
19:48 jnthn plobsing: Oh, for sure it's the meta-model's task.
19:49 jnthn I didn't quite decide how to do it in 6model yet.
19:50 bluescreen plobsing: once the HLL created the new replacement ( morphed object) for an object how should it replace the pointer (PMC *) with the new one?
19:51 plobsing hmmm... I think it is doable, though I don't know how.
19:51 jnthn See rebless_subclass dynop in Rakudo's dynops for an example.
19:52 plobsing worst case, we define a become primitive in the GC
19:52 jnthn (I didn't say it was a good example. ;-))
19:52 jnthn Anyway, reblessing to subclass can be done, but it's pretty evil.
19:52 jnthn We use it in Rakudo to handle mix-ins.
19:53 jnthn Which can happen in-place.
19:53 GeJ Bonjour everyone.
19:54 plobsing jnthn: (re: rebless_subclass) my eyes! it cannot be unseen!
19:55 bluescreen I've banged my head with this as I want to support dynamic inheritance in my HLL, so I've to create a new class everytime parents change and migrate objects to the new class with
19:57 jnthn plobsing: lol!
20:00 plobsing bluescreen: I would suggest adding ".sub 'morph' :vtable('morph')" to the root class of your heirarchy
20:01 plobsing I'm not too sure how the implementation of that would look. It's probably doable though.
20:03 bluescreen jnthn: does the memmove really works? that looks dangerous too
20:03 davidfetter left #parrot
20:04 jnthn bluescreen: The trick is that you end up with as many PMCs around as before, just with different contents.
20:05 jnthn bluescreen: It "really works" in so far as it's used in Rakudo every time you do a mix-in though. :-)
20:05 plobsing it is dangerous. that pokes deep into parrot internals. it works with parrot now, but changes to the way GC manages PMC's/attributes/etc could break it.
20:05 plobsing maybe not likely, but possible
20:07 plobsing we might want to encapsulate part of that on the parrot side of things. that way, if we make such a change, it might be transparent to users.
20:07 bluescreen there should be an op to do that...
20:07 plobsing bluescreen: yes. I'm thinking along the lines of smalltalk's become
20:09 jnthn plobsing: Yes, it makes a lot of assumptions.
20:09 jnthn plobsing: Once Rakudo switches to its new meta-model implementation, it can go away.
20:10 plobsing jnthn: really? you won't have any need to change the representation of objects in-place anymore?
20:10 jnthn It's just the best I could come up with to work with Class/Object PMCs.
20:11 jnthn plobsing: I meant mroe than op will be able to go away. I'll still need to be able to do it, but I can put it in using some cleaner approach.
20:11 jnthn The really messy part that dynop is dealing with the case where we go PMC -> class.
20:11 jnthn That simply won't be an issue because the new meta-model doesn't support PMC inheritance.
20:12 bluescreen jnthn: are you going to have a rakudo's inheritance engine ?
20:12 plobsing "doesn't support PMC inheritance". does that objects passed to rakudo from other languages won't work, or that you can't extend parrot types from rakudo?
20:13 jnthn bluescreen: Inheritance is not a primitive in the core, it's just something implemented by a meta-class that's iterested in providing it.
20:14 jnthn plobsing: Passing objects from other languages should be fine - that's important to make work.
20:15 jnthn Inheriting from Parrot types - there won't be PMC inheritance support in a deep sense, *but* I expect it'll be possible to write a meta-class that does some delegation-y model.
20:15 jnthn The goal is to keep the core really small.
20:15 plobsing would it be possible to use 'rawpmc' as a different object representation? I think the docs mentioned something about being able to do something similar with GObj.
20:16 jnthn Yes, that would also work out.
20:16 jnthn I think we'll be able to build the compatibility bits people want.
20:16 bluescreen jnthn: my point is you might loose some low level optimizations like mro
20:16 plobsing cool. so its just a matter of providing a default that is more sane for more people.
20:17 plobsing bluescreen: low level optimizations that are NYI for years?
20:18 jnthn bluescreen: Actually I'm on course to get a bunch of optimizations possible that can't be done with the current Parrot object model.
20:18 tcurtis joined #parrot
20:23 bluescreen mmm, don't get me wrong, but shouldn't HLLs work towards extending parrot to fit more languages ? than reinvent the wheel? I mean whatever its holding P6 might hold other HLLs
20:26 plobsing bluescreen: every HLL has it's own idea of how objects work. many are similar, but none are identical.
20:26 plobsing ideally parrot should be providing a framework for them to cohabitate in stead of tryingn to provide an object system that is "good enough" for everyone
20:27 plobsing because it will never be good enough
20:27 whiteknight joined #parrot
20:31 bluescreen plobsing: then why bothering in creating an object model at all? if it will never be good enough and most HLLs will implement their-way
20:32 jnthn I think 6model offers some hope in that it provides a very minimal core and an API.
20:32 jnthn The core doesn't even know what a class is.
20:32 jnthn So it's fine for langauges to implement meta-objects that match the API and get their semantics.
20:32 bluescreen yeah in that case I'd move towards to a micro-core
20:33 plobsing bluescreen: because it gives people working in LLLs and MLLs an object system (which people tend to want)
20:33 plobsing PIR, nqp, and winxed users are (mostly) fine with parrot's default object system
20:34 jnthn Further, having *something* that's there out of the box is useful, even if languages end up customizing bits of it.
20:34 jsut_ left #parrot
20:34 jsut joined #parrot
20:39 dukeleto_ left #parrot
20:56 M_o_C left #parrot
21:00 PerlPilot left #parrot
21:15 tcurtis left #parrot
21:19 tcurtis joined #parrot
21:19 tcurtis left #parrot
21:20 sorear What's the most efficient way to write sub foo { bar; bar } in PIR?  (I'm doing sub-call microbenchmarks on a few VMs)
21:22 plobsing is bar in the same unit as foo?
21:23 sorear yes
21:24 plobsing then you'd likely want to use static resolution ".const 'Sub' $P0 = 'bar'"
21:25 sorear then $P0() \n $P() \n .return \n ?
21:28 plobsing yeah. there's probably some tricks you can pull by exploiting the null args and returns
21:38 sorear Too many errors.  Correct some first.
21:41 sorear 2310 ns per call on the ladder benchmark, PIR
21:41 sorear 1240 for Perl 5 on the same hardware
21:41 sorear r49277
21:43 plobsing show me teh codez
21:56 sorear http://gist.github.com/608979 # Perl 6
21:57 nopaste "sorear" at 192.168.1.3 pasted "# Perl 5" (32 lines) at http://nopaste.snit.ch/23945
21:58 whiteknight left #parrot
21:58 nopaste "sorear" at 192.168.1.3 pasted "# PIR" (276 lines) at http://nopaste.snit.ch/23946
22:04 plobsing hmmm... can't see anything off the level there
22:06 plobsing but your perl5 version should fail x0 DNE
22:07 GeJ cheater!
22:07 plobsing GeJ: care to elaborate?
22:08 GeJ anouncing numbers to make parrot look bad compared to Perl 5 while the Perl 5 is actually b0rked. That's cheating!
22:10 jnthn sorear: Your x1 calls x0 which is missing. I guess just a missed first line when copy/pasting.
22:11 plobsing seeing as the other examples do not include an x0, I'd say it's also an old version of the benchmark
22:16 sorear yes, the actual version of the p5 I used had sub x1 { }
22:17 sorear I pasted the wrong file there ... (named 'x'.  Yes, very descriptive.)
22:18 sorear testing methodology: change the first function called up and down until at least 30 seconds used, then divide by the total number of calls
22:18 sorear repeat twice and use second number
22:18 sorear for Rakudo, I also did a very-low-level run to measure startup overhead (4.3 sec here), and subtracted that
22:19 sorear the other systems measured had startup overhead <= 0.5 seconds and no attempt at correction was made
22:24 plobsing 1090518910/14136321143
22:25 plobsing aloha: 1090518910/14136321143
22:25 plobsing arg
22:26 plobsing anyways, what I'm trying to get at is that Sub.invoke takes 7.7% of that time (non-inclusive)
22:26 plobsing seems kinda heavy
22:30 GeJ how about tailcall'ing the second call of $P0 ? ( technically, the Perl 5 version returns the result of the second call to xN() )
22:31 plobsing GeJ: then you'd have to tailcall in perl5 to be fair
22:32 GeJ hum, true.
22:32 plobsing but I doubt it would buy much. the only thing it would do is free up some garbage sooner
22:40 sorear plobsing: Only 7.7%?  I created that benchmark to isolate the cost of my Sub.invoke equivalent
22:42 nopaste "plobsing" at 192.168.1.3 pasted "sorearbench callgrind (non-inclusive)" (72 lines) at http://nopaste.snit.ch/23948
22:42 sorear (it wasn't originally going to be run on Parrot at all; this was a curiousity move)
22:43 plobsing like I said, that's non-inclusive cost. other costs like allocating and populating contexts fall under that
22:43 sorear oh. exclusive time.
22:46 plobsing that's why I think it is a little on the heavy side of things. we might want to take steps to reduce that somehow.
22:56 particle joined #parrot
22:56 dukelet0 joined #parrot
22:59 particle1 left #parrot
23:00 whiteknight joined #parrot
23:01 whiteknight my kid is going to think his name is "goddamnit" for the first few years
23:02 whiteknight it's probably the most common thing that we say to him
23:11 cotto whiteknight, ping
23:11 whiteknight pong
23:11 cotto what version of parrot were you using with the instrument code?
23:18 whiteknight I thought it was 2.8.0
23:18 whiteknight it may have been shortly after that
23:19 * cotto tries with 2.8.0
23:20 jsut_ joined #parrot
23:21 cotto Looks like the symlink to the latest dev release is out of date.
23:22 * cotto fixes
23:23 whiteknight it may have been a weird problem on my machine
23:23 whiteknight I never rule that possibility out
23:25 jsut left #parrot
23:30 whiteknight I don't have my normal dev box right now, so nothing is reliable
23:30 cotto It comes closer to building but doesn't quite get there with 2.8.0.
23:33 cotto relatively easy fix

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

Parrot | source cross referenced