Parrot 2.8.0 released | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | smoke GC-related branches and attack GC tickets
Set by moderator on 1 October 2010.
dalek rrot: r49425 | plobsing++ | trunk (7 files):
probe for INFINITY and NAN macros provided by system headers

see TT #574		 00:13
00:36 ruoso left
dalek rrot: r49426 | mikehh++ | trunk (6 files):
ran make headerizer, added missing PARROT_CAN_RETURN_NULL
 00:59
rrot: r49427 | mikehh++ | trunk/config/auto/infnan.pm:
remove hard tabs
rrot: r49428 | mikehh++ | trunk/config/auto/infnan.pm:
remove more hard tabs (missed two)
01:03 PerlPilot joined 01:04 Util left 01:08 PerlJam left
dalek rrot: r49429 | nwellnhof++ | trunk (9 files):
[str] Prepare deprecation of string_* functions
 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)
mikehh needs a break - bbl 01:31
01:43 nwellnhof left 02:35 janus left 03:00 janus joined 03:31 dukeleto_ joined
ttbot Parrot trunk/ r49429 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/405193.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 03:39
03:41 eternaleye left 03:42 eternaleye joined
dukeleto_ that ttbot error is 'api.obj : error LNK2019: unresolved external symbol _floatval_divide_by_zero referenced in function _Parrot_str_to_num' 03:43
Coke partcl (old) now thinks that 1/3. is "0" instead of "0.33333". wonder when that happened. 04:54
05:34 dukeleto_ left
Coke blows another potentially productive hacking session tracking down a parrot issue. 05:48
Coke cries.
-> abed. 05:49
plobsing Coke: is it doing integer divide for some reason?
Coke at a guess, new_init_int doesn't respect HLL types. 05:52
which would be a huge problem. ;)
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.
plobsing how could new_init_int respect HLL types? it uses INTVAL which isn't a PMC and therefor cannot be overriden 05:55
Coke then we can't use it. 05:58
wait, what?
no, on the /creation/
not the actual int value. 05:59
the pmc type that is created is always Integer, not HLL_mapped(integer)
plobsing well of course. new_init_int asks for a specific class. If you want hll-mapped types, you should use box.
Coke GAHR>G 06:00
/I/ am not using anythign.
this is in src/pmc/integer.pmc, which I am extending.
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:02
hurm. dynself is no longer valid. 06:03
anyway, I'll leave this for someone else to fix. bedtime.
plobsing sounds like deep magic
Coke nope.
tcurtis Aren't vtables always dynamically dispatched? 06:04
plobsing tcurtis: STATICSELF.vtable_name bypasses dynamic dispatch in the name of expedience 06:05
cotto SELF is the new DYNSELF 06:06
tcurtis plobsing: ah. But, VTABLE_type(INTERP, SELF) doesn't, no?
dalek rrot: r49430 | plobsing++ | trunk/include/parrot/datatypes.h:
use has_header appropriately. should fix win32 build.
plobsing tcurtis: true. the VTABLE macros do dynamic dispatch. as does the SELF.vtable pmc2c syntax sugar 06:07
I'm just saying that not *all* dispatches to vtables are dynamic 06:08
PCC also plays fairly fast and loose with the inards of sublike objects
ttbot Parrot trunk/ r49430 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/405374.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 06:11
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:15
windows decides to try to use both cases at the same time 06:16
06:23 tcurtis left 06:38 jsut joined 06:43 jsut_ left 07:14 theory left 07:21 Kulag left, Kulag joined 07:30 Kulag left 07:34 Kulag joined 07:41 eternaleye left 07:42 Drossel joined 07:43 Kulag left 07:46 eternaleye joined 07:53 Drossel left 07:54 Kulag joined 07:55 tadzik joined 07:59 Kulag left, Kulag joined 08:04 Drossel joined 08:06 Kulag left 08:13 Drossel left 08:15 PacoLinux left 08:17 Patterner left 08:35 Kulag joined 08:43 Kulag left 08:44 Kulag joined, mj41 left 08:45 Patterner joined 08:52 Kulag left 08:55 mj41 joined 09:01 pmichaud left 09:03 ash_ joined 09:05 davidfetter left 09:11 Kulag joined 09:19 Kulag left 09:22 Kulag joined 09:41 Kulag left 09:42 Kulag joined 10:00 ash_ left 10:07 Kulag left, Kulag joined 10:11 sjn left 10:12 sjn joined 10:22 Kulag left 10:25 Kulag joined, jsut_ joined 10:29 jsut left 10:33 Patterner left 10:37 Kulag left, Kulag joined 10:43 Kulag left 10:49 mikehh left 10:54 Kulag joined 10:57 Patterner joined 11:06 Kulag left 11:08 Kulag joined 11:11 Patterner left 11:29 Patterner joined 11:31 whiteknight joined 11:51 mikehh joined
whiteknight good morning, #parrot 11:58
mikehh hi whiteknight 12:19
BTW we still have a problem with the Windows build on Taptinder
12:29 mikehh left, mikehh joined 12:34 kid51 joined
whiteknight blargh 12:41
I love good news in the morning
kid51 good morning, whiteknight 12:47
whiteknight hello kid51. How are you today 12:50
?
kid51 I'm getting ready to go back to NYC
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.
whiteknight ah, sorry. I am not good at remembering my own schedule, so there's no way I get yours correct 12:54
13:15 kid51 left 13:20 Patterner left 13:30 Psyche^ joined, Psyche^ is now known as Patterner 13:50 jan left 13:55 whiteknight left
Coke Infinoid++ 13:59
# svn-bisect
14:15 PacoLinux joined
Infinoid woohoo, free karma :) 14:35
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:39
14:56 jan joined
cotto ~~ 15:13
15:29 ash_ joined 15:41 tadzik left 15:53 tadzik joined
mikehh plobsing: you around 16:02
16:11 davidfetter joined 16:18 AzureStone left
dalek rrot: r49431 | mikehh++ | trunk/src/datatypes.c:
change #ifdef to #ifndef (comes into play only if not defined) - this should fix the windows build
 16:20
mikehh I think the last comment on TT #922 is spam 16:22
mikehh waiting patiently for TapTinder 16:26
mikehh I lie
16:33 AzureStone joined
plobsing mikehh: pong 16:41
mikehh plobsing: I think I fixed the Windows build problem in r49431, not sure - waiting on TapTinder 16:44
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:45
but we'll see if your fix works 16:46
mikehh it never failed on the X86_64, just the i386 build
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
mikehh still waiting for the result - it has done the rest 16:49
plobsing maybe the machine gave up 16:51
16:52 M_o_C joined 16:53 dukeleto_ joined 17:15 AzureSto_ joined 17:17 AzureStone left
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:26
17:28 dukeleto_ left, dukeleto_ joined
mikehh bah TapTinder is still running the build for MSWin32/i386 (and the tests for cygwin/i386) 17:31
Great it build ok 17:36
plobsing yay. you fixed it! mikehh++ 17:37
mikehh plobsing: it took me a couple of hours to find it - a one letter change :-{ 17:41
plobsing: it's pretty obvious in retrospect, but those are the sort of things that take forever 17:42
it's called HINDsight :-} 17:43
17:50 patspam joined, patspam left 17:53 theory joined 18:08 tadzik left 18:09 tadzik joined 18:28 tadzik left
cotto mikehh, you would be the one to have that. ;) 18:35
mikehh you would be surprised how many people I have to tell that my name is prounced as in HINDsight NOT HINDia 18:42
cotto You could tell people your middle name is "B". 18:43
though that could have other unintended effects 18:44
mikehh he - it's H
cotto Sure, but "hehind" isn't a word.
mikehh could bring out the donkey in me 18:45
dalek rrot: r49432 | plobsing++ | trunk/src/scheduler.c:
process events on sleep start even if parrot doesn't have threads
 19:09
19:25 ash__ joined 19:29 ash_ left, ash__ is now known as ash_ 19:30 theory left
nopaste "bluescreen" at 192.168.1.3 pasted "Can this patch be a possible fix for ticket #1769 (morph not working)" (22 lines) at nopaste.snit.ch/23943 19:32
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:37
bluescreen plobsing: you saying that objects should not morph? 19:40
plobsing not at all. the code right above your patch handles morphing on types that define how to do it. 19:41
morphing of types that don't know how seems like it would be doomed to failure 19:42
for one, the attributes would be completely jumbled 19:43
bluescreen agree, objects can may totally different from one to another
so then morph should throw an exception for objects that doesn't have an override 19:44
jnthn That patch is doomed to epic fail. 19:46
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.
Rakudo has an op for doing it int he subclass direction.
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
jnthn bluescreen: importantly, ti's a sueprset.
plobsing: Oh, for sure it's the meta-model's task.
I didn't quite decide how to do it in 6model yet. 19:49
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:50
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.
plobsing worst case, we define a become primitive in the GC 19:52
jnthn (I didn't say it was a good example. ;-))
Anyway, reblessing to subclass can be done, but it's pretty evil.
We use it in Rakudo to handle mix-ins.
Which can happen in-place. 19:53
GeJ Bonjour everyone.
plobsing jnthn: (re: rebless_subclass) my eyes! it cannot be unseen! 19:54
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:55
jnthn plobsing: lol! 19:57
plobsing bluescreen: I would suggest adding ".sub 'morph' :vtable('morph')" to the root class of your heirarchy 20:00
I'm not too sure how the implementation of that would look. It's probably doable though. 20:01
bluescreen jnthn: does the memmove really works? that looks dangerous too 20:03
20:03 davidfetter left
jnthn bluescreen: The trick is that you end up with as many PMCs around as before, just with different contents. 20:04
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.
maybe not likely, but possible
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...
plobsing bluescreen: yes. I'm thinking along the lines of smalltalk's become
jnthn plobsing: Yes, it makes a lot of assumptions. 20:09
plobsing: Once Rakudo switches to its new meta-model implementation, it can go away.
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.
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
The really messy part that dynop is dealing with the case where we go PMC -> class.
That simply won't be an issue because the new meta-model doesn't support PMC inheritance.
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?
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:13
plobsing: Passing objects from other languages should be fine - that's important to make work. 20:14
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
The goal is to keep the core really small.
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.
jnthn Yes, that would also work out. 20:16
I think we'll be able to build the compatibility bits people want.
bluescreen jnthn: my point is you might loose some low level optimizations like mro
plobsing cool. so its just a matter of providing a default that is more sane for more people.
bluescreen: low level optimizations that are NYI for years? 20:17
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
20:18 tcurtis joined
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:23
plobsing bluescreen: every HLL has it's own idea of how objects work. many are similar, but none are identical. 20:26
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
because it will never be good enough 20:27
20:27 whiteknight joined
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:31
jnthn I think 6model offers some hope in that it provides a very minimal core and an API. 20:32
The core doesn't even know what a class is.
So it's fine for langauges to implement meta-objects that match the API and get their semantics.
bluescreen yeah in that case I'd move towards to a micro-core
plobsing bluescreen: because it gives people working in LLLs and MLLs an object system (which people tend to want) 20:33
PIR, nqp, and winxed users are (mostly) fine with parrot's default object system
jnthn Further, having *something* that's there out of the box is useful, even if languages end up customizing bits of it. 20:34
20:34 jsut_ left, jsut joined 20:39 dukeleto_ left 20:56 M_o_C left 21:00 PerlPilot left 21:15 tcurtis left 21:19 tcurtis joined, tcurtis left
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:20
plobsing is bar in the same unit as foo? 21:22
sorear yes 21:23
plobsing then you'd likely want to use static resolution ".const 'Sub' $P0 = 'bar'" 21:24
sorear then $P0() \\n $P() \\n .return \\n ? 21:25
plobsing yeah. there's probably some tricks you can pull by exploiting the null args and returns 21:28
sorear Too many errors. Correct some first. 21:38
2310 ns per call on the ladder benchmark, PIR 21:41
1240 for Perl 5 on the same hardware
r49277
plobsing show me teh codez 21:43
sorear gist.github.com/608979 # Perl 6 21:56
nopaste "sorear" at 192.168.1.3 pasted "# Perl 5" (32 lines) at nopaste.snit.ch/23945 21:57
21:58 whiteknight left
nopaste "sorear" at 192.168.1.3 pasted "# PIR" (276 lines) at nopaste.snit.ch/23946 21:58
plobsing hmmm... can't see anything off the level there 22:04
but your perl5 version should fail x0 DNE 22:06
GeJ cheater! 22:07
plobsing GeJ: care to elaborate?
GeJ anouncing numbers to make parrot look bad compared to Perl 5 while the Perl 5 is actually b0rked. That's cheating! 22:08
jnthn sorear: Your x1 calls x0 which is missing. I guess just a missed first line when copy/pasting. 22:10
plobsing seeing as the other examples do not include an x0, I'd say it's also an old version of the benchmark 22:11
sorear yes, the actual version of the p5 I used had sub x1 { } 22:16
I pasted the wrong file there ... (named 'x'. Yes, very descriptive.) 22:17
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
repeat twice and use second number
for Rakudo, I also did a very-low-level run to measure startup overhead (4.3 sec here), and subtracted that
the other systems measured had startup overhead <= 0.5 seconds and no attempt at correction was made 22:19
plobsing 1090518910/14136321143 22:24
aloha: 1090518910/14136321143 22:25
arg
anyways, what I'm trying to get at is that Sub.invoke takes 7.7% of that time (non-inclusive) 22:26
seems kinda heavy
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:30
plobsing GeJ: then you'd have to tailcall in perl5 to be fair 22:31
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
sorear plobsing: Only 7.7%? I created that benchmark to isolate the cost of my Sub.invoke equivalent 22:40
nopaste "plobsing" at 192.168.1.3 pasted "sorearbench callgrind (non-inclusive)" (72 lines) at nopaste.snit.ch/23948 22:42
sorear (it wasn't originally going to be run on Parrot at all; this was a curiousity move)
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.
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:46
22:56 particle joined, dukelet0 joined 22:59 particle1 left 23:00 whiteknight joined
whiteknight my kid is going to think his name is "goddamnit" for the first few years 23:01
it's probably the most common thing that we say to him 23:02
cotto whiteknight, ping 23:11
whiteknight pong
cotto what version of parrot were you using with the instrument code?
whiteknight I thought it was 2.8.0 23:18
it may have been shortly after that
cotto tries with 2.8.0 23:19
23:20 jsut_ joined
cotto Looks like the symlink to the latest dev release is out of date. 23:21
cotto fixes 23:22
whiteknight it may have been a weird problem on my machine 23:23
I never rule that possibility out
23:25 jsut left
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.
relatively easy fix 23:33

Powered by Cro and the Raku® Programming Language.

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

Thank you!