www.parrot.org/ | 285 RTs left | Next release: 2009-07-21
Set by moderator on 18 July 2009.
00:01 theory_ joined 00:15 theory joined 00:20 mokurai joined
cotto Hmmm. I wonder how scary the Rakudo code covered by that failing test is. 00:33
mikehh bacek: trying now 00:38
00:42 theory joined 00:47 Whiteknight joined, Limbic_Region joined
kid51 Applying bacek's patch on linux/i386, 'make test' succeeded. Am testing with it on Darwin/PPC as well. 00:49
That being said, I'm concerned about the number of instances this week in which something in Parrot, while passing all of Parrot's tests, caused some failure in a language 00:50
IIRC we've had breakage in both Rakudo and Lua.
Is the code in these languages poking into Parrot's internals without authorization? 00:51
Or is it that Parrot is exposing stuff it shouldn't.
Since I'm not working on any of the languages, the only tests I can do anything about are Parrot's. 00:52
00:52 bacek joined
cotto kid51, my understanding is that those failures are because the HLLs depended on hash key ordering, which they shouldn't have. 00:53
kid51 cotto: [sigh of relief]
I would never have suspected that hash keys would ever be thought of as ordered. 00:54
... but that's my Perl 5 legacy speaking.
cotto Ideally we'd have the option to randomize them to ensure that code depending on the ordering failed noisily. Nothing should be depending on the ordering. 00:56
kid51 Here's a passing Smolder done with bacek's patch applied. smolder.plusthree.com/app/public_pr...ails/25181
cotto (imho; it may actually be a Bad Idea apart from debugging purposes)
nm. It does appear to be random. 00:59
nopaste "cotto" at 74.61.2.46 pasted "non-determinism in attr initialization in rakudo" (17 lines) at nopaste.snit.ch/17318 01:01
kid51 hmmm 01:02
nopaste "cotto" at 74.61.2.46 pasted "running the previous nopaste" (44 lines) at nopaste.snit.ch/17319 01:03
kid51 looks at cotto's paste and realizes he hasn't been keeping up with Perl 6
kid51 will have to learn that perl 6 thing some day
cotto Once it runs at a reasonable speed, it'll be amazing. 01:04
kid51 puts it on his TODO list, right after "Learn enough C to understand Parrot"
cotto If you wait long enough, you'll even be able to buy a book. 01:05
kid51 Well, I've often thought I'd do it when Randal would come out with Learning Perl 6 -- but it appears it will be brian d foy who will do that 01:06
Actually, what I *will* I buy is the Parrot book
... whenever it next appears in printed form. 01:07
mikehh bacek: make test PASSes - Ubuntu 9.04 amd64 01:09
kid51 bacek: make test PASSes Darwin PPC 01:22
mikehh bacek: make fulltest PASSes - Ubuntu 9.04 amd64
Whiteknight I'm disheartened by this hash issue 01:23
it's definitely annoying that anybody has been relying on hash ordering
and it's very annoying that some of Parrots test suite has been testing for a specific hash order until recently
cotto I'm digging into the PIR generated by rakudo to see how it could be fixed.
Whiteknight okay, awesome 01:24
kid51 Whiteknight: which Parrot test was that
Whiteknight one of the PAST tests, was testing the output of _dumper against a string literal 01:25
I'm really looking forward to the Parrot book being published 01:32
cotto does anyone understand what capture_lex does? 01:35
01:42 mokurai joined
kid51 The C<capture_lex> opcode is used to attach the current lexical 01:43
environment to any subroutines that are lexically nested within
the current sub. This is normally done either when the outer
sub is entered or just prior to invoking the inner sub.
vi +149 ./docs/pdds/pdd20_lexical_vars.pod
Whiteknight cotto: honestly, no
kid51: One of those cases where the documentation isn't really helpful 01:44
kid51 Whiteknight: What does it lack?
cotto tries to reread that without Powerthirst playing in the background... 01:45
kid51 vi +573 ./src/sub.c 01:46
pmichaud I know what capture_lex does. 01:49
cotto I somehow figured you would. 01:50
pmichaud (hash ordering) It's not that we expected hash ordering to be preserved, it's just that we also didn't have tests that would show failures when it wasn't.
i.e., if we were relying on hash ordering, it was completely inadvertent, not designed. 01:51
cotto yeah
If there aren't explicit tests it's easy for bad assumptions to sneak in. 01:52
pmichaud, do you know offhand what code I should be looking at?
pmichaud cotto: for what?
purl i heard for was => 'rw' lazy defaults make pretty good sense, don't they?
pmichaud for the ordered hash issue? 01:53
cotto nopaste.snit.ch/17319
pmichaud In order for that to work, Rakudo will probably have to keep track of an attribute order with each element, so that it knows the order in which to initialize the attributes.
I'm not at all certain what that will entail. 01:54
My best guess at this point is that Rakudo will need to keep a private list of attributes for each class, rather than relying on Parrot to do it. 01:55
then instead of introspecting the class to learn the list of available attributes, it'll look at that private list.
cotto so basically way over my head 01:56
pmichaud it's a little over mine, even.
the primary method to be changed is likely BUILD
src/classes/Object.pir:293 I think. 01:57
01:57 Tene joined
pmichaud currently we do the attribute initialization with 01:57
attributes = inspect parrotclass, 'attributes'
it = iter attributes
and then loop through the attributes to initialize each in sequence 01:58
it'd be a useful question to ask whether Parrot classes should use OrderedHash instead of Hash for attributes, though. 01:59
cotto That'd solve the problem nicely. Can attributes get deleted? OrderedHash has (or had before the merge) issues with that. 02:00
pmichaud VTABLE void remove_attribute(STRING *name) {
so yes, it's apparently supported (if the class hasn't been instantiated yet) 02:01
but no, Rakudo doesn't rely on attribute removeal (afaik) 02:02
cotto It doesn't matter. It's hacky OrderedHash's implementation but it doesn't cause any odd behavior. 02:04
s/hacky/hacky in/ 02:06
pmichaud I suppose Rakudo could initialize all attributes (e.g. to undef) prior to evaluating any of the initializers. 02:07
but I'm pretty sure we have to ensure that the attributes are initialized in the order given in the source.
Whiteknight attribute names could be stored in an ordered array at compile time and moved into an unordered hash when they are initialized
(if initialization is the only place that relies on it) 02:08
pmichaud that's what I said above, effectively
01:55 <pmichaud> My best guess at this point is that Rakudo will need to keep a private list of attributes for each class, rather than relying on Parrot to do it.
Whiteknight well you can still rely on Parrot to store things, just later in the process 02:09
pmichaud I'm saying I can't rely on Parrot for the ordering of the list of attributes.
that's all I'm saying.
Whiteknight noted
pmichaud yes, the rest works out okay.
Whiteknight pmichaud: so is this a resolvable problem before the release, or do we need to back out the hash changes until afterwards? 02:10
cotto Using an OrderedHash in class->attrib_metadata doesn't work, although I only tried the most naive solution.
02:12 dukeleto joined
cotto (in Parrot's src/pmc/class.pmc +493) 02:12
pmichaud Whiteknight: I don't know if it's resolvable prior to release. Jonathan isn't back until Monday. Tomorrow morning I leave for OSCON.
I might be able to work on it while on the plane, although I really should get the interop pdd in shape prior to release. 02:13
I might be able to get it fixed on monday, either during the tutorial session I'm attending or in the evening if/when there's nothing else going on.
Whiteknight I obviously want to keep the hash stuff in trunk, but I would be fine backing it out for a few days for the purpose of the release if needed by rakudo 02:14
cotto It sounds like the better option is to back out the changes, make sure a deprecation is in place and put it back after the release.
pmichaud do we have anything that now depends on the new changes?
cotto I don't like the idea of only maybe having a release that doesn't break Rakudo.
Whiteknight nothing "relies" on hashes being unordered, no 02:15
although I think he fixed a few other things with it, so people will start to rely on the unbrokenness eventually
pmichaud yes, I'm wondering if those other fixes remain valid after backing out the changes. I think it's likely that they're still valid, but I'm just wondering. 02:16
Whiteknight I've looked at the changeset, it's pretty comprehensive. I don't know how easy it would be to pick and choose which features to keep
pmichaud I suggest we don't back out the changes until tomorrow night. 02:17
I _think_ I can get a workaround in rakudo by then.
Whiteknight noted
cotto pmichaud, sounds good 02:18
Whiteknight that would be awesome, I would be glad to help but I think it's beyond my abilities
or, beyond my knowledge of Rakudo
cotto we should have a firm deadline though, otherwise it could cause some panic when whoever tries to back out the changes.
Whiteknight things have changed pretty dramatically since I last looked through the rakudo parser
pmichaud (looking at code) 02:23
it looks to me as though attrib_cache isn't used 02:24
Whiteknight what is attrib_cache?
pmichaud I think that originally it was intended to be a fast attribute-to-index lookup 02:25
so that attribute slots could be allocated when they are used
Whiteknight where is that, in the class PMC?
pmichaud yes.
Whiteknight ok
pmichaud and the earliest used attributes would tend to get earlier slots (on the assumption they're most used)
oops 02:26
it's used, but in object.pmc
Whiteknight oh
pmichaud I'm a little surprised that switching attrib_metadata to OrderedHash doesn't work. 02:27
okay, I think I might have a Rakudo workaround. 02:30
it'll take me a couple of hours to implement. 02:31
(and test)
cotto Whiteknight++ #documenting this to parrot-dev
02:45 TiMBuS joined 02:48 janus joined
pmichaud Do we know what test was/is failing in Rakudo because of the ordered hash issue? 02:56
02:58 mokurai joined
cotto t/spec/S12-attributes/instance.rakudo 02:58
purl somebody said t/spec/S12-attributes/instance.rakudo was still intermittent - passes 3 fails twice 121-122
bacek pmichaud: 03:19
18:28\t\trakudo:     S12-attributes/instance.rakudo 121 - Can initialize one attribute based on another (1)
18:28\t\trakudo:     S12-attributes/instance.rakudo 122 - Can initialize one attribute based on another (2)
(Here shortly)
cotto It's nondeterministic so it'll sometimes pass. 03:20
bacek cotto: indeed. 03:23
03:28 Andy joined
pmichaud okay, I'm testing a working around now. 03:34
(But I'm also packing at the same time, so it may be a bit slow :-)
bacek pmichaud++
03:35 theory_ joined
pmichaud ugh, my workaround isn't going to work. 03:35
I'll have to think about it a bit more.
03:36 theory__ joined
cotto bacek, ping 03:39
bacek cotto: pong shortly 03:40
cotto bacek, I have a patch to update the grammar and actions for opsc to parse explicit preambles. I'd like your thoughts on whether the generated past looks sane.
bacek nopaste it
nopaste "cotto" at 74.61.2.46 pasted "updated opsc grammar and actions with explicit preambles" (116 lines) at nopaste.snit.ch/17321
purl i think nopaste it is See /who is nopaste for the URL.
nopaste "cotto" at 74.61.2.46 pasted "ops file and resulting past" (106 lines) at nopaste.snit.ch/17322 03:43
bacek cotto: looks all right. It will parse empty files though. 03:44
cotto so?
bacek It will successfully parse some garbage without warnings :) 03:45
Not a big problem anyway. 03:46
cotto Ok. I was just making sure that the changes are sane before I start making the tests pass again.
bacek cotto: they are sane. 03:48
cotto Yay. I'm sane!
bacek cotto: I didn't tell anything about you!
afk # back to kids and home work. 03:49
japhb Given that the OpenGL stuff is A) open to change whenever NCI or cross-HLL library handling changes, but B) is not really core ... should I mark the whole subsystem "experimental" to allow for changes that may happen before 2.0? 03:52
dalek rrot: r40147 | cotto++ | branches/ops_pct/src (2 files):
[opsc] switch to explicit preambles for a couple ops I missed earlier
 03:56
cotto japhb, +1
japhb cotto: OK, will do.
Did Tene and pmichaud ever manage to make progress on the cross-HLL stuff? 03:57
03:58 theory joined 04:00 theory_ joined 04:01 theory joined
pmichaud japhb: not yet I haven't 04:01
I was hoping to do that yesterday, but things around the house commanded my attention
04:02 theory__ joined
japhb pmichaud: I understand that problem well .... 04:05
04:06 theory_ joined
dalek TT #852 created by japhb++: Mark OpenGL subsystem as experimental 04:17
rrot: r40148 | japhb++ | trunk/DEPRECATED.pod:
Mark OpenGL binding and related libraries experimental
 04:19
04:22 theory joined 04:23 Andy joined 04:34 davidfetter joined
cotto comitted! 04:35
committed!
dalek rrot: r40149 | cotto++ | branches/ops_pct/compilers/opsc (4 files):
[opsc] update test, grammar and actions to use explict preambles
 04:36
cotto bacek_at_work, feel free to clean up the grammar to filter out junk
pmichaud I wonder if it'd be feasible to add a ResizableStringArray to Class PMC to keep track of the order in which attributes are added 04:41
although the more I think about it, the more I think that Class really ought to have an OrderedHash 04:42
(I tried adding a ResizableStringArray as a property attached to classes that Rakudo creates... but the problem is that not all of the classes we use are created by Rakudo) 04:43
cotto Using an OrderedHash makes the most sense but it'll mean more than changing class's init VTABLE function. 04:44
pmichaud I wonder why, though.
cotto It'd be less surprising.
pmichaud (why it means more than changing class's init VTABLE function)
oh, I have another workaround that might work. 04:45
It'll be another hour or so before I can try it, though.
(more household tasks here that have to be done before I leave in ~10 hrs)
cotto clock?
purl cotto: LAX: Sat 9:45pm PDT / CHI: Sat 11:45pm CDT / NYC: Sun 12:45am EDT / LON: Sun 5:45am BST / BER: Sun 6:45am CEST / IND: Sun 10:15am IST / TOK: Sun 1:45pm JST / SYD: Sun 2:45pm EST /
cotto are you the same as CHI? 04:46
pmichaud yes
it's 23:46 here now
I leave for the airport at 09:30
cotto yay for last-minute {h|p}acking
pmichaud indeed
afk for a while -- will try my workaround a bit later 04:47
Andy Does anything need any help right now? 04:48
cotto t/oo/attributes.t segfaults if attribute_metadata is an OrderedHash. I'll dig in since it sounds like more fun than anything I'm supposed to be doing.
Andy, like what?
Andy dunno. 04:49
I'm just pokin' around with splint
dalek rrot: r40150 | petdance++ | trunk/src/call/ops.c:
consting
cotto L1 is underspecified. You'd get lots of brownie points for starting a spec.
;)
Andy I don't eve know what L1 is 04:50
04:56 dukeleto joined, dukeleto_ joined
cotto Andy, that's the problem. Nobody does. 04:57
but that wasn't a serious suggestion 05:00
serious cat I'm not
05:05 bacek joined
cotto bacek, could you look at why t/oo/attributes.t fails when you change attrib_metadata to be an OrderedHash? 05:06
I think it might have something to do with keys or iterators.
I'm tempted to start a WTFIsL1 wiki page filled with gibberish just so people will start to flesh the thing out. 05:15
dalek rrot: r40151 | petdance++ | trunk/src/sub.c:
removed unused var
 05:16
bacek cotto: because OrderedHash is hack... 05:27
pmichaud Looks like I have a workaround in place.
bacek Hooray! 05:29
nopaste "pmichaud" at 72.181.176.220 pasted "Rakudo with OrderedHash workaround" (37 lines) at nopaste.snit.ch/17323
"pmichaud" at 72.181.176.220 pasted "Rakudo without OrderedHash workaround" (45 lines) at nopaste.snit.ch/17324 05:30
pmichaud I'm running a spectest now; if it passes, I'll commit.
that should hopefully get us at least through the release. 05:31
cotto Woohoo!
pmichaud++
bacek pmichaud: does Rakudo support removal of attributes? OrderedHash will epicly fail in this case :(
pmichaud bacek: my workaround is not actually using OrderedHash 05:32
bacek: it's still using Hash
cotto I asked that too. Apparently it doesn't.
bacek pmichaud++ # Yaaa Hooo!
pmichaud but for places where it matters, it keeps an independent list of the order of the attributes
cotto bacek, are you saying that OrderedHash is a candidate for refactoring?
pmichaud and uses that independent list if it exists
(actually, it creates the independent list in all cases at the moment)
eventually, if Parrot is able to provide an OrderedHash for the Class PMC, we'll use that 05:33
bacek cotto: such "refactoring" usually called "rewrite from scratch"...
pmichaud if Parrot decides that it won't use an OrderedHash for class attributes, then we'll see about optimizing the creation/maintenance of the parallel list
cotto yeah. I don't know if there'd be a way to use the existing data structures in a proper ordered hash.
bacek pmichaud: I think we should use OrderedHash for attributes. But we need sane OrderedHash beforehand. 05:34
cotto pmichaud, what's the eta on the spectest
pmichaud on this machine, 45 mins
cotto is that parallel?
pmichaud no.
cotto could it be?
pmichaud I'm not set up for parallel spectests at the moment.
and my fast machine is otherwise occupied right now. 05:35
cotto It's as simple as chromatic's mj alias, isn't it?
pmichaud I don't know what that is.
bacek "make -j3"
cotto alias mj='TEST_JOBS=5 make -j9'
pmichaud would that be "make -j9 spectest"?
Because I'm not doing a build -- I'm doing a test. 05:36
bacek cotto: TT#813
afk again # household...
pmichaud I'll try with TEST_JOBS=5
that doesn't seem to do anything. 05:37
cotto bacek, I agree. It'd be better to have a different purpose-built data structure than trying to inherit.
s/have/use/ 05:38
pmichaud setting TEST_JOBS doesn't seem to do anything on my system.
cotto Are you using TEST_JOBS and -j9 ? 05:39
pmichaud I'm going to guess that the version of Test::Harness that I have doesn't support parallel testing.
cotto (or some other number
)
pmichaud The -j9 probably doesn't do anything.
There's only one make command to be run.
yes, even with -j9, no improvement. 05:40
cotto pmichaud, it works for me. I'm seeing 5 perl6 processes in top. 05:41
pmichaud cotto: what version of Test::Harness do you have on your system?
cotto how do I find that out?
pmichaud perldoc Test::Harness, perhaps?
mine says 2.64
cotto same
so "TEST_JOBS=5 make -j9 spectest" doesn't spawn multiple processes? 05:43
pmichaud no.
cotto odd
pmichaud do you have TAP::Harness on your system?
cotto I appear to. 05:44
pmichaud ah, I don't.
cotto <3 parallel testing
pmichaud I suspect that's the difference. parallel testing was introduced with TAP::Harness, I think
anyway, I'll let the existing spectest run.... I don't want to add other new variables into the test right now 05:45
(such as a different test harness)
cotto It's really nice
sure
pmichaud I might try updating the harness after the spectest run and see what happens.
(won't matter much on this machine since I'll be out of town all week) 05:46
cotto It also makes my lap nice and toasty.
pmichaud heh
my notebook runs a lot cooler since I got the ssd drive
boots faster, too, but doesn't seem to compile significantly quicker
cotto I discovered that I could double my RAM (to 3GB) for $26 shipped. 05:47
pmichaud yeah
05:47 theory_ joined
pmichaud I did that with my previous laptop -- it was very nice to get the speed improvement so cheaply 05:47
cotto it'd be worth it if I had any income
pmichaud my new one has 3GB, I can expand to 8GB if I want to spend lots of $$
<3 my notebook
cotto what model? 05:48
purl model is my interface to my data
pmichaud HP Elitebook 2530P
it's 33% faster than my desktop.
(and my desktop isn't exactly old or slow)
cotto I found some cool Linux games on sale for $5, but I'll probably need a new upgrade before they'll be playable. 05:49
linuxlock.blogspot.com/2009/07/are-...ll-be.html
pmichaud need to fold+pack some clothes -- bbiab
cotto need to apply for jobs -- bhfaw 05:50
pmichaud try -j9, I hear you get more jobs that way :-P 05:51
cotto That's simultaneously the best and worst advice I've heard for the last several months. 05:52
Hmmm. One place is asking for "Orcale" experience as a plus. 05:55
sounds like a vegetable 05:58
or maybe Orc ale
wow: www.forbes.com/feeds/ap/2009/06/24/...80581.html 05:59
06:35 Infinoid_ joined 06:38 confound_ joined, TimToady joined, workbench joined
dalek kudo: 02dd257 | pmichaud++ | src/ (3 files):
Parrot's Class.attributes method no longer returns attribute

the order is somewhat unpredictable). Since we need to initialize attributes in the order they were declared, add a @!attribute_list property and 'attriter' method to the Class PMC that allows Rakudo keep track of the order in which attributes are declared.		 06:46
06:51 bacek joined
cotto Yay! It's fixed and we don't have to undo the key/iter refactor. 06:52
Tene anyone around here have access to cygwin? 06:57
06:57 mberends joined 07:00 szabgab joined
dalek kudo: e759b14 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to latest tested Parrot.
 07:09
rrot: r40152 | cotto++ | branches/ops_pct/compilers/opsc/op:
[opsc] delete the now-unused op dir
 07:19
rrot: r40153 | tene++ | trunk/runtime/parrot/library/Curses.pir:
Add panels support to Curses.pir
 07:22
07:24 mikehh_ joined
cotto I just used tab completion to turn "multi.pas" into "multi.past". Maybe it's time for bed. 07:31
treed Heh. 07:34
07:40 iblechbot joined
dalek rrot: r40154 | cotto++ | branches/ops_pct (5 files):
[opsc] move (and attempt to use) code from op.pm to oplib.pm, remove now-obsolete files, update manifest
 07:48
07:55 bacek joined
bacek Hooray! pmichaud++ 08:03
mikehh All Tests PASS (pre/post config, smolder, fulltest) at r40154 - Ubuntu 9.04 amd64 08:17
rakudo (e759b14) on parrot r40154 (spec at r27606) fails t/spec/S06-signature/optional.rakudo - test 11 08:34
08:51 flh joined 09:11 bacek joined 09:19 mokurai1 joined 09:29 mokurai1 left
dalek a: f777fca | fperrad++ | src/lib/lfs.pir:
lfs.attributes() : emulate iteration in an ordered hash
 10:22
11:13 MoC joined 12:25 Whiteknight joined 12:34 iblechbot joined
Whiteknight good morning #parrot 12:38
13:09 szabgab joined 13:15 Limbic_Region joined 13:35 [1]Limbic_Region joined 13:38 confound joined 13:40 fperrad joined
whoppix good morning, Whiteknight. 13:41
Whiteknight good morning whoppix 13:45
whoppix Whiteknight, made me a list yet?
Whiteknight no, I've been lazy and busy
but mostly lazy
whoppix yeah, I know that :)
jdv79 Whiteknight: my only thought on your latest post is this: don't some things require being run within "compile time"? 13:48
i don't know enough to answer that but that's all i could come up with against the idea.
Whiteknight jdv79: sort of, but the line for where compile time ends and runtime begins is a little fuzzy and we can be liberal with it 13:49
things like :immediate and :postcomp should run immediately after compilation, but exactly _who_ runs it after compilation is a different issue
jdv79 i guess "compile time" could just be before runtime and after imcc time. hmm..
Whiteknight right
jdv79 nice
Whiteknight if you are brave enough to dig into the IMCC logic, it actually completes the compilation phase and then loops over all the generated sub objects and executes the ones that need it immediately 13:52
in fact the :main function gets called from inside IMCC at this point
13:57 kid51 joined 14:06 [1]Limbic_Region joined
Whiteknight nopaste? 14:13
purl rumour has it nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo
dalek TT #853 created by fperrad++: Can't load OpenGL 14:23
14:23 tetragon joined 15:03 theory joined
japhb fperrad: #853 is effectively a reversion of someone else's commit to do the opposite. 15:13
I originally used .include, as you have it, but someone went through and converted it to runtime load ... I don't know why.
Found it: trac.parrot.org/parrot/changeset/38693 15:18
Ticket updated. 15:22
pmichaud Good morning, #parrot (from airport)
Whiteknight good morning pmichaud 15:24
pmichaud gone again (time to board) 15:31
bbl
15:43 AndyA joined, skids joined
dalek rrot: r40155 | whiteknight++ | trunk (2 files):
[Win64] Two fixes for Win64 that help with build and execution.
 15:45
15:53 whiteknight joined
whiteknight where are the datatypes like INTVAL defined? 16:09
I can't seem to find it
16:22 chromatic joined
whiteknight might finally have figured out how to get Parrot working on Win64 16:28
whiteknight holds his breath
16:33 mokurai joined
whiteknight Parrot builds on win64!! 16:39
(although it's already failed one test because of an out-of-memory VM PANIC, so that's not a good sign) 16:41
16:47 jan joined
dalek rrot: r40156 | jkeenan++ | trunk/src/ops/sys.ops:
Update documentation of spawnw() to reflect movement of TODO tickets from RT to Trac.
 16:48
16:54 Psyche^ joined
whiteknight yay! we officially have a Win64 smolder report posted (and it's not pretty) 16:57
smolder.plusthree.com/app/public_pr...ails/25220 16:58
MoC I suppose it's especially bad that the 64bit tests fail completely? 16:59
(op/64bit.t) 17:00
whiteknight yeah 17:05
i have to commit a few fixes because it doesn't even build out of the box
fperrad japhb, after reading your comment in #853, I'll apply now my patch 17:06
17:07 szabgab joined 17:15 Whiteknight joined
dalek kudo: 415514b | moritz++ | docs/release_guide.pod:
[docs] more markup for release_guide.pod
 17:15
kudo: d27f384 | moritz++ | tools/progress-graph.pl:
[tools/progress-graph.pl] remove debugging output; use larger font on y axis
kudo: 630b0a0 | moritz++ | src/builtins/any-num.pir:
implement .Int, right now as a synonym for .int.
kudo: b7b45a3 | moritz++ | CREDITS:
give kyle++ some CREDITS
 17:16
kudo: 0b9d7af | moritz++ | docs/ChangeLog:
[docs] more ChangeLog updates
kudo: f9d6284 | (Kyle Hasselbacher)++ | Test.pm:
[Test.pm] (eval_)dies_ok should not accept "Null PMC access"

Signed-off-by: moritz <moritz@faui2k3.org>
kudo: d99b5b8 | moritz++ | src/setting/Hash.pm:
implement Array ~~ Hash
17:25 kid51 joined
japhb fperrad: Note that NotFound has taken the ticket, and says he'll look at it tomorrow. 17:32
fperrad japhb, I see that, so I wait
japhb fperrad: cool beans.
fperrad japhb, what do you think about a refactor of config/gen/opengl.pm with template ? 17:33
Whiteknight irclogs? 17:34
purl i guess irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
japhb fperrad: I like having OpenGL.pir and OpenGL_funcs.pir separate, because OpenGL.pir is hand-written code, and OpenGL_funcs.pir is completely generated. It makes it easy to be clear about what is safe to hand-edit and what is not. It also makes clear what parts opengl.pm alters and what it does not. 17:36
That's why I went with separate files and a .include
There is also the GLUT callbacks library, which is pseudo-templated; but there's not a whole lot I can do about that cleanly. 17:37
The whole thing is an abomination, and definitely not thread- or interpreter-safe, but there's just no other way with current Parrot NCI.
(the whole thing == GLUT callbacks library) 17:38
Adding this Q/A to ticket .... 17:39
fperrad japhb, OK for the record 17:41
japhb done 17:42
fperrad: thanks for using the OpenGL binding ... it needs more users. :-) 17:44
fperrad: I'm also curious why this problem affects Lua and not Rakudo or pure PIR ...? 17:45
dalek rrot: r40157 | whiteknight++ | trunk/config/gen/platform/generic/platform_limits.h:
[win64] commit a small fix, probably in the worst possible way, to account for the fact that LLONG_MAX and LLONG_MIN don't appear to be defined in 64-bit cl.exe
japhb When NotFound made his original patch, I was OK with it because it didn't seem to have any obvious negative impact at the time (and thus I had no real reason to object). 17:46
fperrad japhb, OpenGL.pir uses the namespace 'OpenGL', but OpenGL_funcs.pir not 17:49
I try to add this namespace in OpenGL_funcs.pir, but it isn't enought
japhb Oh interesting ...
purl vedy vedy iinterestink
japhb That sounds buggish. 17:50
fperrad In any case, the best way to ship OpenGL is one PBC, not 2. Even when there are 2 PIR files. 17:55
japhb fperrad: I agree, but NotFound presumably had his reasons, so I trusted him until proven otherwise. :-) 17:56
dalek rrot: r40158 | jkeenan++ | trunk/src/pmc/os.pmc:
Add inline comment referring to TT #849 calling for way of setting mtime and atime. One POD formatting correction.
 18:02
rrot: r40159 | moritz++ | trunk/include/parrot/compiler.h:
[cage] tabs to spaces
 18:15
18:18 Whiteknight joined
moritz t/codingstd/c_header_guards.t fails because include/parrot/platform_limits.h and config/gen/platform/generic/platform_limits.h are the same file, and thus use the same header guard 18:34
18:35 whiteknight joined 18:37 jjore joined
MoC nopaste? 19:22
purl somebody said nopaste was at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo
nopaste "MoC" at 91.11.13.84 pasted "mingw32-make fails." (8 lines) at nopaste.snit.ch/17325
19:23 davidfetter joined
MoC If someone could take a look at it please. 19:23
r40159 (=current HEAD) 19:24
whiteknight hmm, that's weird 19:35
but I am leaving now and don't have time to dig into it 19:36
create a ticket on Trac, somebody will fix it 19:38
dalek TT #854 created by jkeenan++: config/inter/progs.pm: Figure out why -libpath: needs to be removed from ... 19:56
moderator www.parrot.org/ | 284 RTs left | Next release: 2009-07-21 19:57
20:03 |MoC| joined
kid51 moritz: At r40159, I cannot reproduce the header_guards failure you described earlier. Did you fix it? 20:18
moritz kid51: no
20:20 payload joined 21:01 iblechbot joined 21:10 MoC joined 21:13 tetragon joined 21:23 dukeleto joined 21:33 theory joined 21:59 tetragon joined 22:37 rg joined 22:40 kid51 joined 22:56 particle1 joined
dalek rrot: r40160 | jkeenan++ | trunk/lib/Parrot/Pmc2c/PMC/RO.pm:
Tidy up some inline comments.
 23:02
23:40 jhorwitz joined
jhorwitz chromatic: ping 23:43
dalek TT #855 created by jkeenan++: config/init/defaults.pm: Profiling options are too specific to GCC 23:47
moderator www.parrot.org/ | 283 RTs left | Next release: 2009-07-21 23:48
mokurai joined
dalek rrot: r40161 | jkeenan++ | trunk/config/init/defaults.pm:
Remove inline comment referring to now closed RT #41496.
 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!