Parrot 1.7.0 "African Grey" is out! | Fix issues caused by the pcc_reapply and context_auto_attrs merges | find out what's up with the slice opcode | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 1 November 2009.
dukeleto kthakore: did you have questions for me? 00:00
00:00 payload joined
kthakore dukeleto: not really 00:09
chromatic: nice
japhb chromatic, how many chapters have you got drafted at this point? 00:13
Whiteknight speaking of freeze, it's really freaking cold here 00:18
dukeleto Whiteknight: where is 'here' ? 00:22
purl comfort coraline's poodle.
Whiteknight dukeleto: inside my apartment. I turned the thermostate up to 60F, and it got *much* warmer 00:23
so I don't know how cold it was
dukeleto Whiteknight: wow
japhb Whiteknight, trying to do extreme overclocking without paying for the peltier?
chromatic I'm not sure how many chapters I have right now; maybe 25% of the book. 00:26
Whiteknight chromatic: ETA?
purl well, ETA is estimated time of arrival or Euskadi Ta Askatasuna, or like the Basque PLO
Whiteknight i'll definitely buy a copy when it's out
00:27 tetragon joined 00:28 tetragon joined
plobsing hi #parrot 00:28
chromatic I hope to have it in print by February. 00:36
00:40 abqar joined 00:41 jsut joined 00:49 Zak joined
plobsing ok, my merge auto_libjit+trunk experiment seems to be working. 01:05
I have it sitting in git. How should I proceed? 1 patch per commit? one big patch on trunk? one slightly less big patch on auto_libjit?
who should I poke to review it? 01:06
chromatic Isn't there a branch for it?
plobsing yes, auto_libjit.
chromatic Is that up to date with your patch?
plobsing no. its a little stale. 01:07
this patch takes what's there, merges trunk and fixes up some small breakages
chromatic Those sound like separate things. 01:08
plobsing and they are separate commits in my git repository. it's easy to split it up.
chromatic If I were doing this, I'd merge from trunk to branch in one commit, then fix up the breakages, and then ask for review of the branch before merge to trunk.
plobsing that's effectively what I've done, but I don't have access to the svn repo, so I've used git 01:09
chromatic Okay, then I'd like to see two patches for each of the two parts. 01:10
Then someone (Whiteknight? dukeleto?) can apply them to the branch for review.
Two patches, one for each part, I mean.
01:11 Zak joined
plobsing ok. the merge patch might be pretty big. it's effectively the size of the pcc_reapply merge 01:11
Whiteknight what am I applying where? 01:15
chromatic plobsing has a new patch to apply to the libjit framebuilder branch. 01:16
plobsing yeah, the merge commit is way too big for Trac (1.5M) 01:22
can somebody merge trunk into auto_libjit? I can advise on resolving the small conflicts that arise. 01:27
(considering I've done it once before)
dukeleto chromatic: what do you need reviewed?
chromatic plobsing's branch. 01:28
dukeleto plobsing: link for your branch?
plobsing svn or git repo? 01:29
dukeleto plobsing: git 01:30
do you need to ask? ;)
plobsing # Parrot_pcc_get_signature => 01:31
# [ qw(void_ptr void_ptr) => 'void_ptr' ],
oops
github.com/plobsing/parrot-libjit
pasting is hard
dukeleto plobsing: can you make a branch off of the github.com/leto/parrot upstream branch ? 01:36
plobsing: when was your repo last synced? 01:37
plobsing I've pulled from there if thats what you mean.
30 minutes ago
dukeleto plobsing: i see that now
plobsing: cool
01:37 mikehh joined
dukeleto plobsing: looks like you are merging with my master 01:37
plobsing: if you merge with upstream, you won't see all those extra merge commits 01:38
dalek rrot: r42255 | jkeenan++ | branches/configtests/t/steps/inter (14 files):
Continue converting step tests to use all Parrot configuration data.
plobsing dukeleto: please explain. examples would be nice.
dukeleto plobsing: so am I looking at git diff master libjit ? 01:39
plobsing that's pretty much it
libjit is an extension of the auto_libjit svn branch
dukeleto plobsing: I have very little jit experience, but I can give a review later tonight 01:40
plobsing that would be much appreciated
dukeleto plobsing: i am cloning your repo now
plobsing: anything I should know? does make coretest pass on your branch? 01:41
plobsing: what is the state of the test suite in your branch?
plobsing: also, i can give you commit access to parrot.git so that you can create branches there, from the auto-synced repo 01:42
plobsing all tests pass. --optimize has a failure in t/src/warnings.t, but so does trunk
s/all tests/whatever tests get run by make test/ 01:43
01:43 markmont joined
dukeleto plobsing: you can now commit to github.com/leto/parrot 01:43
plobsing: you should see a 'your clone url' link now 01:44
01:44 mikehh_ joined
dukeleto plobsing: don't worry about warnings.t , somebody broke that on trunk 01:44
plobsing dukeleto+: it works! thanks
dukeleto++
dukeleto plobsing: make fulltest is the best :)
plobsing I'll run that now
dukeleto plobsing: make -j 4 fulltest is the bestest :)
chromatic TEST_JOBS=n make -j n fulltest is better. 01:46
dukeleto if anybody else wants to create branches on parrot on github, shepherd them towards me
chromatic: i think TEST_JOBS is set in my .bashrc :) 01:47
i am going to add the regulars to the repo
i don't know why I haven't before
plobsing I thought the point of git was that every dev gets their own repos and then you just do pull requests
dukeleto plobsing: pull requests are more work 01:50
Tene eh, there's a variety of ways to do things.
dukeleto github is crapping itself, but I managed to add chromatic, tene, plobsing and bubaflub to the github parrot repo 01:51
that can be the repo that we get code reviews for git branches
Tene I'm really sketchy about ever relying on github. They haven't been anywhere near reliable enough for me to be comfortable.
dukeleto plobsing: the point of git is to bend it to the workflow that you want
Tene: i mirror most stuff to my gitweb instance leto.net/gitweb (not as often) and there is also gitorious 01:52
Tene: the point of git is that you don't rely on github much
Tene: it rarely goes down for more than a few hours. git allows you to work off-line and change the "canonical" master origin 01:53
Tene: so I don't see github going down as a big deal
Tene: would you feel better if I kept a mirror on git.or.cz, gitorious, github and my gitweb instance? 01:54
Tene: that is trivially possible, although it costs me a lot more bandwidth :)
01:57 kiwichris joined
dalek rrot: r42256 | jkeenan++ | branches/configtests/t/steps/init/headers-01.t:
Continue to convert steps tests to use of Parrot configuration data.
 01:58
dukeleto kiwichris: yo dude!
rrot: r42257 | jkeenan++ | branches/configtests/t/steps/init/hints/darwin-01.t:
No longer need to import Parrot::Configure.
kiwichris dukeleto, hi
dukeleto, have parrot running on a real PC how, not simulated using qemu
dukeleto kiwichris: !!! 01:59
01:59 Zak joined
kiwichris dukeleto, up till now I have been simulating a PC. It is now on real PC hardware. 02:00
dukeleto kiwichris: that is really cool!
kiwichris: take a picture?
purl It'll last longer!
dukeleto kiwichris: sometimes purl is right :)
kiwichris: have you submitted a patch to trac? 02:01
kiwichris:
kiwichris dukeleto, don't encourage it !!
plobsing make fulltest -j3 => fail in t/pmc/threads.t
kiwichris dukeleto, after that one of these www.axman.com/?q=node/247
plobsing prove t/pmc/threads.t => pass
dukeleto plobsing: run prove 10 times. threads.t is known to fail intermittently 02:02
kiwichris: so parrot is running on a V2 ColdFire ?
kiwichris dukeleto, not yet but I will get it too soon'ish 02:03
dukeleto kiwichris: what is it running on now? what are the specs? 02:04
kiwichris: also, what time is it by you?
plobsing for i in $(seq 1 10); do prove t/pmc/threads.t; done => PASS x 10 02:05
dukeleto kiwichris: an amazing bit of info would be for you to run some of those benchmarks on qemu, records the times, and then do the same without qemu and/or on crazy-cool hardware :)
plobsing: is prove using an installed parrot?
kiwichris dukeleto, no idea, an old'ish Pentium but the rest is a guess, maybe 1G of memory, I will find out when am next to the hardware
dukeleto plobsing: delete your installed parrot to be sure, or move it aside
kiwichris: good to know. I didn't know RTEMS worked on pentiums :) 02:06
plobsing dukeleto: nuked installed parrot from space. same result. 02:07
dukeleto plobsing: can you get "make fulltest" to pass threads.t? is it only the parallel fulltest that makes threads fail? 02:10
kiwichris dukeleto, exit question if that is ok ? 02:11
dukeleto kiwichris: you can ask any question whenever you want :) 02:13
kiwichris: also, if you make an account on github, i can allow you to create a branch on the parrot git mirror that i keep there 02:14
kiwichris: if you want to play with git :)
kiwichris dukeleto, I suppose adding a parameter to Parrot_new is not ok given it is an API.
dukeleto, thanks, but I think the patch will be small. 02:15
dukeleto kiwichris: we have a deprecation policy
kiwichris: :)
kiwichris: if it is a backwards compatible api change, it can be done whenever
kiwichris dukeleto, I need to set an exit_hook in the interp struct and the sooner the better. If NULL the system exit is called.
02:16 eternaleye joined
dukeleto kiwichris: if it is not, then stuff needs deprecating and that takes 6 months 02:16
kiwichris dukeleto, I could add a Parrot_new_with_exit_hook, or something smaller.
dukeleto kiwichris: that sounds pretty reasonable right now
kiwichris dukeleto, is make_interpreter an API or internal ?> 02:17
dukeleto kiwichris: that is a totally new function to create an interpreter object, so there is no deprecation policy coming into effect
kiwichris: and only people who want a custom exit handler pay the extra cost, because it is opt-in
kiwichris: i like it
kiwichris dukeleto, great, so I propose add the hook parameter to make_intrepreter and then a new Parrot_new_* 02:18
dukeleto kiwichris: i would call it Parrot_new_with_exit_handler
chromatic Did you see Parrot_on_exit?
dukeleto chromatic: that calls the system exit() unconditionally
kiwichris chromatic, and exit == reboot for me
plobsing kiwichris: what if a user wants to trigger a reboot from parrot? 02:20
kiwichris plobsing, good question
chromatic I don't understand the problem then.
kiwichris plobsing, can they call exit directly 02:21
chromatic It sounds like you want to add a new function to Parrot for one platform to bypass the exit(3) call.
cotto Has anyone seen Primer?
kiwichris chromatic, RTEMS is a single address space, single process OS. An exit does not return control to the user, rather it reboots the whole target
dukeleto plobsing: your diff has 273 files changed. 02:22
plobsing from master?
or from auto_libjit?
dukeleto plobsing: am I doing git diff libjit auto_libjit?
plobsing: you said git diff master libjit before
plobsing its tricky...
chromatic I'd rather have a system-specific exit call than create a new way to exit that isn't really exit.
plobsing ultimately, it'll want to diff with master. and you need prior knowledge of auto_libjit to diff with it. 02:23
dukeleto chromatic: we just need a flag so that we can *conditionally* exit(3) inside Parrot_on_exit()
plobsing so diff with master is easier. also probably smaller
chromatic For an OS-specific behavior? That feels like the wrong place to do it.
plobsing dukeleto: can you nopaste the list of changed files
kiwichris chromatic, I was going to let the user manage this with a handler they provide than attempt to dictate a policy. 02:24
dukeleto plobsing: you can see them with git diff master libjit --name-only
chromatic: can we add an argument to Parrot_on_exit() ?
chromatic How about we put a platform-specific way to override exit() in src/platform.c? 02:25
plobsing dukeleto: git diff master libjit --name-only | wc -l => 32
dukeleto chromatic: that sounded like it might incur the dep policy, so we were thinking a new function is opt-in
plobsing 273 seems a wee bit high
dukeleto $ git diff master libjit --name-only | wc -l
273
plobsing: nopaste the command: cat .git/config in your repo
chromatic: what is the best way without incurring the deprecation policy? 02:26
02:26 markmont left
dukeleto chromatic: should we just check if the current OS is RTEMS and *not* do the final exit(3) ? that seems hackish 02:26
chromatic Figure out some way that calling exit(3) in Parrot_exit() won't reboot RTEMS.
dukeleto chromatic: exit(3) on rtems = reboot 02:27
chromatic No, we add a new internal-only wrapper around exit(3). For most platforms, it's still exit(3). For RTEMS, it's... whatever's most appropriate. yield() or whatever.
plobsing configure flag?
dukeleto chromatic: i see, says the blind man
chromatic No deprecation necessary. 02:28
dukeleto chromatic: what about setting a custom final exit handler?
kiwichris chromatic, this is fine with me
dukeleto chromatic: nice solution
kiwichris chromatic, is platform.c generated by configure ?
chromatic Yes. 02:29
See config/gen/platform/*
I suspect, but cannot prove, that we'll need more platform-specific code for RTEMS in there anyway. 02:30
kiwichris chromatic, yes I tend to agree as we get into Parrot more 02:31
nopaste "plobsing" at 76.68.74.120 pasted "plobsing's git/config" (17 lines) at nopaste.snit.ch/18568 02:32
kiwichris chromatic, I would make a patch for platform.c but the Configure.pl magic is beyond me. 02:33
02:34 dngor joined
chromatic Yeah, that needs a bit of research. 02:34
We need to figure out how to get the right platform name in place so that the configure step can build src/platform.c correctly. 02:36
dukeleto kiwichris: we will take care of the build auto-generation stuff. 02:40
kiwichris dukeleto, thanks. I will hack Parrot_exit for now 02:43
dukeleto chromatic: what about adding a cross compile flag to Configure ? 02:44
chromatic: perl Configure.pl --cross=rtems-i386 02:45
kiwichris dukeleto, we normally use "--target=i386-rtems4.10" where the arch is first and the version of RTEMS last.
dukeleto chromatic: what kiwichris said 02:46
02:47 diakopter joined
dukeleto chromatic: i am willing to work on that 02:47
chromatic I'd like to see it. kid51 may know a lot better about what Configure.pl needs for that though.
dukeleto chromatic: i've discovered some of her dark secrets, but I am sure more await 02:48
02:52 kid51 joined
kid51 plobsing ping 02:53
dukeleto kid51: ping!
kid51 dukeleto pong
plobsing kid51: pong
kid51 plobsing: pcc_reapply_merge_fixups.patch in TT 1105: Do you want that merged into the branch or into trunk? 02:54
plobsing looking to merge to branch first, but trunk is pretty close. 02:55
however, disregard my last message. the patches were too big
pcc_reapply merge is 1.5M
dukeleto kid51: i want to implement cross compiling in Configure.pl
kid51: chromatic said I should talk to you 02:56
plobsing also the second patch (actually attached) includes regular trunk commit activity
bad patch postings, sorry
02:56 allison joined
kid51 plobsing I'll be happy to apply any patches you want to the auto_libjit branch. Just line them up. 02:58
plobsing kid51: the first one is too big to post in track: merge pcc_reapply + resolve conflicts 02:59
kid51 But since I'm back to working on configuration issues, my focus is away from core issues.
plobsing I don't know how to proceed on that. 03:00
03:00 payload1 joined
kid51 Hmm. Then I recommend you post to parrot-dev what you've done, where you stand, what needs to be done next, etc. 03:01
I'm not awake enough right now to focus on this, sorry. 03:02
dukeleto: Have you read the documentation in Configure.pl on file-based configuration?
plobsing kid51: no problem. I have plenty of other tasks I need/want to do
kid51 That functionality was requested by particle as a step toward cross-compiling.
03:04 Zak joined
plobsing Should I put my ideas about NCI up on the wiki, under NCITasklit, or on the NCI RFC ticket, TT1192? 03:08
kid51 plobsing: Cet. par., go with the Trac ticket. 03:10
03:10 JimmyZ joined
kid51 speaking only for $self, I check the Trac log (specifically, report 10) obsessively. But I go to the wiki much less frequently. 03:11
Others probably work differently. YMMV.
plobsing realized the track ticket is more specific. my thoughts are more general. going with the wiki page. 03:16
dukeleto kid51: a bit 03:29
kid51: the platforms overrides are not going to solve the issue of cross-compiling 03:30
dalek TT #1194 created by jkeenan++: 7 config steps improperly rely on Perl 5 %Config 'OSNAME' element 03:40
03:41 janus joined
kid51 dukeleto: Well, I haven't had to think much about the issue of cross-compiling since Jerry asked me to do that ... and that was 17 months ago! 03:42
Decades in Parrot years ;-)
So, if you can post to list or open a TT or something, that will give me something to think about.
dukeleto kid51: have you seen everything going on with the rtems port? it is to support that 03:44
kid51: but yes, I will make a ticket
kid51 dukeleto: I haven't had time to keep up with everything that's happening in Parrot these days. 03:45
And Coke's request that I move some tickets from RT to TT has provoked me to go back and re-examine long-standing configuration issues. 03:46
dalek rrot: r42258 | jkeenan++ | branches/convert_OSNAME:
Create a branch to work on TT #1194.
tracwiki: v116 | dukeleto++ | WikiStart 03:48
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
dukeleto kid51: leto.net/dukeleto.pl/2009/11/realti...rrots.html
dalek rrot: r42259 | jkeenan++ | branches/configtests/t/steps (10 files):
Continue to convert steps tests to use of Parrot configuration data.
 03:49
03:56 JimmyZ_ joined
dalek TT #1195 created by dukeleto++: Add cross-compiling support to Configure.pl, such as ... 03:57
kid51 must sleep 03:58
purl $kid51->sleep(8 * 3600);
nopaste "dukeleto" at 69.64.235.54 pasted "look what the sneaky ruby rockstars have done with whois perl.com" (11 lines) at nopaste.snit.ch/18569 04:01
chromatic Your mistake is thinking that perl.com has been relevant at all in 2009. 04:02
dukeleto chromatic: you mean their mistake :)
chromatic: you are the one 'denting' about perl.com ;)
chromatic It still gets Google juice, despite it being nothing more than an ad platform for the domain host. 04:03
dukeleto chromatic: yes. that irks me too
chromatic: perhaps they need to be taught a lesson
chromatic I have some small hope that the owner of the domain may eventually yank it back from them and do *something* relevant with it. 04:05
04:06 mokurai joined
dukeleto msg japhb i am noticing plumage takes quite a bit longer to compile now 04:10
purl Message for japhb stored.
nopaste "dukeleto" at 69.64.235.54 pasted "latest plumage does not compile for me due to POD issues" (19 lines) at nopaste.snit.ch/18570 04:16
dukeleto msg japhb actually, it doesn't compile: nopaste.snit.ch/18570
purl Message for japhb stored.
japhb dukeleto, pong 04:21
Hmmm, it was compiling fine when I committed last ...
Weird, that looks like NQP regressed handling of POD 04:22
dukeleto japhb: which commit of nqp-rx are you using? 04:23
japhb: i am using 1ee030e7d
japhb 4bb93132de80e0b5598cf3014002a3c64ad6a4ae
Not sure how old that it.
er is 04:24
Checking just now that latest plumage compiles for sure with that nqp-rx 04:25
... yup
So it's an nqp-rx regression.
dukeleto japhb: that is 7 commits ahead of mine
japhb dukeleto, then maybe you need to update ... ;-) 04:26
dukeleto japhb: 4bb9313 [nqp]: Enable Perl 6 pod comments. pmichaud 2 days ago Mon Nov 2 21:41:02 2009
japhb heh
nice that I caught the right commit perfectly
plobsing japhb: looking at NCITaskList 04:27
japhb: could you elaborate on why the current structure API is painful and slow?
dukeleto it would be nice if --gen-parrot did a svn revert -R && svn up instead of checking out parrot again 04:28
plobsing japhb: also what are SoA, AoS, and "Counted Strings"?
dukeleto plobsing: Struct of Arrays, Array of Structs 04:29
japhb plobsing, the method for describing a structure is this baroque style in which you push special tokens (several per structure field) onto an array-like thing, but then sometimes set properties on certain elements of that array also, and then instantiate structures based on that description, and then the converse to get data back out of a structure returned by a function 04:30
plobsing japhb: you only have to make the description object once 04:31
AFAICT
japhb Counted strings are Pascal, Java, Forth, etc. style strings in which the length precedes an unterminated buffer, unlike the C style which has no length information, but does have a terminator
plobsing oic
just say pascal strings 04:32
and I'll know
japhb plobsing, sure. But heaven help you if you are trying to use an API with a bazillion use-once structures. Like, say, most of the graphics APIs.
plobsing japhb: padded strings?
japhb: wrt ugly struct API, write a wrapper. 04:33
japhb I didn't say just Pascal strings, because each different language has a different way of doing the length. Forth uses exactly one byte. Java IIRC uses BER-encoded ints.
plobsing and you want *all* of them?
japhb plobsing, buffers/strings that will be padded to some multiple of a fixed size block, using a certain pad byte, and that pad byte should be added/removed automatically across the NCI barrier. 04:34
plobsing, we should be able to do Perl 5 pack(), or be embarrassed. 04:35
Now, I'm not saying we have to do it all *immediately*, but
you did ask what we weren't handling yet. :-) 04:36
And as for "write a wrapper", that just makes the performance issues worse.
I described above that the struct-handling API was ugly and painful to use. But it's also SLOW.
As in, limits the maximum performance of OpenGL code. 04:37
dukeleto lastest nqp doesn't even compile
plobsing japhb: I don't see how to make the struct definition easier. if you want a wrapping accessor, you have to tell it about the structure.
japhb: the alternative is to just use a byte array and manage the offsets yourself
japhb plobsing, I'd be happy to do it, if there was some way to do so. But there ought to be a PMC that can do it for me, efficiently. 04:38
04:39 nbrown joined
dukeleto msg pmichaud latest nqp-rx does not compile for me: nopaste.snit.ch/18571 04:39
purl Message for pmichaud stored.
plobsing japhb: zero-copy R/W access to buffer contents
japhb: isn't that already provided for by the NCI types?
japhb I ought to be able to say I'm doing an AoS like OpenGL's GL_T2F_C4UB_V3F, and then say I want to set the red byte of the 15th structure member to 255, and have it be a couple mad's and a write. 04:40
plobsing I am not smart enough to understand half of what you just said 04:41
mads?
purl mads are they the folks who stuck joel on the space station?
japhb I don't currently believe pulling strings out of a char ** for example is zero copy, but I could just be out of date. 04:42
plobsing there's no copying being done in the framebuilder.
japhb fused Multiply ADd instructions
plobsing I don't know about elsewhere
at least for 'V' type arguments 04:44
japhb And GL_T2F_C4UB_V3F means "Texture coordinates comprised of two floats, followed by a color comprised of four unsigned bytes, followed by a vertex position comprised of three floats"
dukeleto japhb: i am compiling 4bb9313 now, which looks promising
japhb dukeleto, cool beans
dukeleto japhb: it is going to be a bumpy ride :) 04:45
fuck. spoke too soon. it failed as well
japhb plobsing, A lot of my performance issues boil down to this: I need to sling around multi-megabyte buffers back and forth to the video driver. I need minimal overhead. 04:46
nopaste "dukeleto" at 69.64.235.54 pasted "nqp-rx 4bb9313 does not compile either" (52 lines) at nopaste.snit.ch/18572
plobsing japhb: I'm pretty sure 'p' and 'V' arg types are your friend there 04:47
japhb And I consider OpenGL to be a basic stress test that is currently standing in for some of the problems that other APIs will eventually have, like for instance database APIs, when the row count starts getting really big.
dukeleto japhb: which platform/os are you on?
japhb dukeleto, currently debian/i386
well, i686, actually
dukeleto japhb: 4bb doesn't compile for me
japhb: i am blowing away the parrot dir in the nqp-rx repo and trying again 04:48
japhb plobsing, if we're going to do things with just bare void buffers, then we need a really good equivalent of pack() and unpack(). I need to be able to say, put the value from this PIR $N0 register into this spot in the buffer, as a 16-bit half float. 04:49
dukeleto japhb: or my installed parrot is conflicting
japhb dukeleto, --gen-parrot is dead to me. I do everything through the installed parrot, which I've configured with --prefix=/usr/local/parrot .
plobsing, I apologize if it sounds like I'm being really demanding, but I got my hopes up summer of 2008 when someone was working on a full C header parser for GSoC that was designed to produce automatic, efficient C structure/union wrappers. AFAIK, it was never completed. 04:52
I don't think it's impossible. Just not easy.
(Clearly, C compilers have to do it. :-) 04:53
plobsing japhb: being demanding of ourselves is a good thing
means we provide it before a user whines about it
s/a user/too many users/ 04:54
japhb plobsing, and unfortunately I've banged my head on a lot of things that are simply impossible in the current NCI, like correct callback handling. (glutcb is a massive hack that is completely unable to handle multiple interpreters or multiple threads)
... and constants that I can't specify because they are near to 2^32, and thus destroyed by sign mangling. 04:55
plobsing japhb: time for a hardware upgrade ;-)
04:56 theory joined
japhb ... and huge swaths of OpenGL on windows, which depends greatly on GetProcAddress functions. 04:56
plobsing japhb: that's the easiest problem to fix from my POV
japhb ... and any API with a long long argument, and so on.
Man, I hope so.
kurahaupo japhb: apropos "put this number at this byte-offset as a 16-bit half-float" ... I was thinking recently about restructuring how Arrays are done, and what I have in mind would mesh very well with your problem. 04:57
japhb Windows is a special place in hell, because of its twisted type sizing in Win64.
plobsing I tend to lean towards worse is better here, so expect to do more work for it
japhb I don't mind creating wrappers for low-level functionality, as long as the low-level design does not make it impossible for the wrappers to be efficient. 04:58
Designs that for example want a method call for locating an element followed by another method call to set it, and no way to amortize across a tight loop that's setting consecutive elements, for example ... that would suck. 04:59
kurahaupo Basically, refactor array handling into two parts: element type coercion on the one hand, and on the other, convert-index-to-byte-offset-with-optional-resizing (plus push, pop, etc)
dukeleto japhb: nuking the generated parrot made it work 05:00
japhb dukeleto, excellent.
kurahaupo So if there's another source of "this byte offset", doing the type mangling would already be provided...
japhb has to get a few spare cycles soon to write the code for Plumage to be able to upgrade Parrot out from under itself.
dukeleto japhb: it seems that the gen-parrot option gets confused if you change branches
japhb dukeleto, yeah, a lot of our Makefiles are not branch-hopping-friendly 05:01
dukeleto japhb: yay, I just ran the test suite with the new nqp-rx and everything passed!
japhb Almost makes me want to figure out how to have the makefile depend on the current branch name
dukeleto, yup! 05:02
kurahaupo japhb: so you'd like my set_element and get_element to auto-increment the byte pointer?
kurahaupo apologizes for the conversational lag... 05:03
japhb plobsing, kurahaupo, a low-level API I would like to wrap would provide a function to determine the stride of an array, whether that stride is made of primitive types or of structures (taking into account proper alignment padding), so that I can ask the API for the offset of element N, and be able to just increment that offset by the stride when I want to loop from N, N+1, N+2 ... N+M 05:04
dukeleto msg pmichaud 4bb93132 is what japhb and I are currently using in nqp-rx. let us know when master compiles :)
purl Message for pmichaud stored.
kurahaupo japhb: makes sense, yes.
plobsing japhb: should be possible. braindumping to NCITaskList ATM
kurahaupo japhb: would you need multidimensional strides? 05:06
kurahaupo thinks a very quick way to transpose a matrix would be to swap the strides of the two dimensions
japhb I should also be able to ask for the offset within a structure of each of its elements. Then I can happily say 'put the value from this register into this data type at this offset'. Then writing the wrapper becomes easy and quick.
kurahaupo, see PDL in the Perl 5 world. Arbitrary affine transforms are handled by just editing the header that points at the low level buffer, and loops across multi-dimensional arrays get all offset and stride information from that header. Which means multiple different views of the same underlying data are easy, with different dimensionality and dimension ordering. :-) 05:08
plobsing japhb: PDL is awesome (I've used it before), but I think all we are looking to do is provide the tools that P6DL might use 05:09
japhb PDL also has data flow, but that's a bit more advanced than we need to consider for this stuff. ;-)
right
But I just mentioned one I'd forgotten ... the ability to apply different structure definitions to the same buffer. Which means that the low-level API needs to separate the structure information from the data pointer. 05:10
plobsing that could just be a set_pointer on different struct PMCs
each providing a different view
japhb plobsing, sure ... but I point it out to make sure that GC is kept happy. 05:11
kurahaupo ISTR that Strings are now r/o, which means you can borrow their byte buffers with impunity?
japhb And also on that note, we need to remember something that the current NCI actually has *conceptually* right (though I don't know about in practice) ... the difference between Parrot-managed memory and external library-managed memory. So Parrot doesn't try to GC something the external library wants to own, for example. 05:12
kurahaupo, it's been a year since I even looked at the Strings implementation, so I'm out of date on that. 05:13
chromatic STRINGs are still mutable.
japhb is amazed that chromatic had not said something earlier in this discussion. ;-) 05:14
kurahaupo chromatic: is that slated to change?
chromatic It's a possibility.
First, we need to make a case for deprecating the modify-in-place behavior of STRING APIs (on the wiki). 05:15
We probably need STRINGNULL before that.
Coke cotto: yes, I've seen Primer++ (+=100)
japhb It would be really swank, btw, if we could tell Parrot's GC that an external library effectively has an active reference to a Parrot buffer, without having to copy the data in said buffer to prevent GC of live data. And then later to be able to tell Parrot's GC that the library has let go of its "reference" to the buffer. 05:17
chromatic In theory, Parrot_gc_register_pmc should do that. 05:18
plobsing that should somehow be available from PIR then
chromatic I think that's the pin/unpin opcodes. 05:19
japhb OpenGL for example has several APIs that lock and unlock buffers between the user program and the video driver. It's eventually going to be necessary to support those, as they are increasingly becoming the "standard way" of passing great gobs of data across.
oh, excellent.
plobsing japhb, chromatic: I have put my thoughts on japhb's NCI issues at the bottom of trac.parrot.org/parrot/wiki/NCITasklist 05:20
japhb looking .... 05:21
dalek tracwiki: v2 | plobsing++ | NCITasklist 05:22
tracwiki: plobsing's naive thoughts
tracwiki: trac.parrot.org/parrot/wiki/NCITas...ction=diff
chromatic #
*
o
# allow more direct PIR access to NCI PMC (particularily creation)
Is that different from the dlfunc opcode?
plobsing dlfunc is too restrictive
if I get a pointer to a function otherwise, I can't call it 05:23
chromatic How do you get that pointer otherwise?
japhb dlfunc doesn't handle GetProcAddress functions, where you are manually asking a library for a function pointer, and then want an NCI Thunk wrapped around that pointer
kurahaupo notices it's time to go $HOME; goodnight everyone
japhb chromatic, it is REALLY common in the OpenGL world (especially on Windows boxen) to do most functions via pointers grabbed from *GetProcAddress() 05:24
chromatic Fair enough.
japhb In fact, there are (several!) libraries that do nothing but run across the entire defined OpenGL API doing GetProcAddress on every function and filling huge vtables.
cotto Coke, I'm confused. (happily I was having a problem with the voices being way too quiet that was solved by unplugging and replugging my headphones.) 05:25
I'm sure it'll be a little easier to get the second time.
japhb It's nuts, but it's essentially routing around ancient Microsoft brain damage.
dalek tracwiki: v19 | kurahaupo++ | ArrayTasklist
tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff
Coke cotto: (confused) by the movie?
dukeleto japhb: in the USING file, shouldn't we tell users "sudo plumage install ..." ?
Coke Your brain should be oozing out the side when you're done.
cotto quite 05:26
japhb Plumage does sudo automatically when it discovers it can't write to the Parrot bin dir.
;-)
And the reason you want it that way, is that you want to reserve the sudo for just the install phase itself, not all the other phases that led up to it. 05:27
dalek TT #1196 created by pmichaud++: 'parrot foo' automatically finds and invokes foo.pbc
japhb I don't want to run fetch, configure, build, test, as root
plobsing, thank you for listening and writing down your thoughts in the Wiki. 05:28
plobsing japhb: I'm not stopping there. that's pushed as yet another task to do soon (sometime this month) 05:29
japhb :-)
plobsing mostly because some things would benefit by deprecations ASAP
Coke japhb: should plumage not run previous steps if possible?
so then "plumage test partcl; sudo plumage install partcl" works quicker? 05:30
plobsing dukeleto: wrt huge number of files modified with libjit changes (3 hours ago) 05:31
dukeleto: are you doing git diff master parrot-libjit/master --name-only | wc -l
05:31 Zak joined
japhb Coke, I thought about that. I decided that *for now* it's a premature optimization -- remember that if the tests fail, and you haven't told plumage to ignore failures in that step, it will refuse to install. So you can safely do all your testing by asking it to install. ;-) 05:31
plobsing dukeleto: or git diff master parrot-libjit/libjit --name-only | wc -l
dukeleto: (the second one is the diff I'm after) 05:32
japhb Coke, but yes, I plan to eventually add an option to be something like ./plumage --only install foo
And it will only do the steps it *has* to do.
dukeleto plobsing: i will try that in a few. i think we were diffing different things before ;) 05:36
dalek TT #1197 created by coke++: Need some way to copy/rename files from parrot. 05:37
TT #1198 created by kjs++: interactive mode doesn't save lexicals correctly
Coke chromatic: on 1196, I believe pdd30 suggests installing under a languages dir.
plobsing dukeleto: I just realized. I'll push what I want you to diff as a new branch 05:38
dukeleto: because that's what you'll wind up doing eventually anyways
japhb Anyone have any last minute things waiting on me? 05:40
Otherwise I'm off for the night ....
dalek rrot-plumage: a92d932 | leto++ | :
[t] Upgrade t/harness to utilize string interpolation
 05:41
chromatic languages?
purl languages is trac.parrot.org/parrot/wiki/Languages
dukeleto japhb: i am not so happy about t/harness depending on src/lib/Glue.pbc
japhb mmph?
Why? 05:42
dukeleto japhb: i want to break that dependency, i want t/harness to be self-contained
japhb: i only use qx() and split()
japhb dukeleto, that's going to be non-trivial, because of NQP not having a runtime. Glue basically is our runtime.
But you could certainly just inline the PIR if you wanted to.
dukeleto japhb: do I rely on global variable that get defined in PIR? 05:43
japhb yes.
see bottom of Glue.pir for those.
dukeleto japhb: i use slurp() too
dalek TT #1199 created by coke++: automatically create config.log during build
japhb yup. Amazing how much you need from there, isn't it?
dukeleto japhb: but I think I can re-write stuff with regexen. maybe not slurp(), though 05:44
japhb Well, tank on it a bit, and I'll talk to you later or tomorrow.
dukeleto japhb: i want to use that harness in another repo, which doesn't have "the glue".
japhb dukeleto, pmichaud was thinking of providing an optional 'P6' library with NQP, based loosely on Glue.pir ... so that may solve your problem. 05:45
OK, AFK for now.
dukeleto japhb: cool! night. 05:46
japhb: or I just copy Glue.pir as well, for now 05:47
eternaleye cotto: Coke: I made it halfway through Primer before my brain asploded 05:49
dalek TT #1200 created by coke++: sprintf formatting for exponents needs to be standardized 05:50
TT #1201 created by coke++: Parrot::Pmc2c::Emitter line # error
Coke trac is slowwwwwwwwwwwwwww 05:51
plobsing dukeleto: pushed experimental branch auto_libjit_pcc_reapply to your github parrot repo 05:52
dalek rrot-plumage: bebf8d4 | leto++ | :
[t] Add note about where canonical home of t/harness is, in case it star...
dukeleto plobsing: cool! 05:54
plobsing: how do you want me to review it?
plobsing build + test would be a good start 05:55
Coke RT: 89 tickets 05:56
05:56 kurahaupo joined
plobsing from there, have a glance at the meat of the change: config/gen/{libjit.pm,libjit/frame_builder_libjit_c.in} 05:58
there's also some changes in src/pmc/nci.pmc that merit review 06:00
dukeleto plobsing: what should I diff it against? master? 06:03
plobsing parrot trunk. I assume master =~ parrot trunk, so yes 06:04
dukeleto plobsing: yes.
plobsing dukeleto: could you be more specific?
dukeleto plobsing: master and upstream branches on the parrot github mirror are ~ to trunk 06:08
plobsing: upstream = trunk, master = trunk + merge commits
plobsing awesome
diff with master then
dukeleto plobsing: ok
Coke RT is now down to 85 tickets; I'm not feeling the love. 06:13
35 of those are assigned. 06:14
35/85
purl 0.411764705882353
Coke 85-35
purl 50
Coke so if everyone with a commit bit ported 2 of the unowned tickets to trac...
dalek rrot: r42260 | coke++ | trunk/compilers/imcc/optimizer.c:
Remove reference to rejected ticket.
dukeleto Coke++ # with love 06:24
Coke I'd rather you moved some tickets. =-) 06:25
cotto clipperz++ 06:26
Coke osx-- 06:28
cotto dukeleto, what's with the sudden interest in getting Parrot on RTEMS? 06:31
dukeleto cotto: i hung out with some RTEMS core devs at the gsoc conference 06:33
cotto: so we were like, "let's see if we can get this to work"
cotto: beer was involved
Coke ... so if I give you beer, you'll work on partcl?
dukeleto Coke: yes. 06:35
cotto Sweet. Beer does great things sometimes. 06:38
sometimes, not so much
dukeleto Coke: i still can't resolve tickets on RT 06:39
Coke: anything I assign to you, you should close
Coke: i can't even reassign it to you!
Coke: this is madness.
dalek TT #1204 created by dukeleto++: Implement all TODO comments in t/pmc/parrotio.t
dukeleto Coke: can you close all the RT's that I am adding "This is now tracked at" messages to ? 06:41
dalek TT #1205 created by dukeleto++: Test exporting MMD subroutines in t/pmc/exporter.t 06:46
rrot: r42261 | dukeleto++ | trunk/t/pmc/exporter.t:
[cage] Update bug tracker details for a TODO in t/pmc/exporter.t
 06:47
TT #1206 created by dukeleto++: Test more return values in t/pmc/io_iterator.t 06:53
06:56 davidfetter joined
dukeleto davidfetter: howdy 06:58
purl salut, dukeleto.
davidfetter hai dukeleto
what's the latest? :)
dukeleto davidfetter: parrot is being ported to a real-time os, RTEMS, and NQP is going through a large upgrade as well 06:59
davidfetter too cool :)
davidfetter in paris atm, getting ready for pgday.eu 07:00
dukeleto davidfetter: be sure to recruit some people for pl/parrot!
davidfetter will do. anything in particular you want highlighted?
dukeleto davidfetter: tell people that they can write *fast* and *cross-platform* stored procedures in PIR/NQP when pl/parrot works, as well as use stored procedures from any language running on parrot 07:03
davidfetter dukeleto, will do :)
07:04 uniejo joined
cotto Was the consensus that nqp-rx would have regularly-updated snapshots in Parrot trunk? 07:05
davidfetter 'sup cotto
dukeleto cotto: there was no consensus, other than a one-time nqp-rx upgrade. but plumage just switched over to nqp-rx
cotto: so the theory is, parrot core will come with a "good-enough" NQP (nqp-rx) and you can always upgrade that with plumage 07:06
cotto way to increase the pressure
that sounds workable
dukeleto cotto: it seems to be a happy middle ground between stability, deprecation cycles and developer sanity 07:07
cotto: do you have the power to close RT tickets? 07:08
cotto: i can reply, but i cannot reassign or resolve/close
cotto I should 07:10
lemme try
would "resolved" or "rejected" be more true? 07:11
dukeleto cotto: any 07:12
cotto works for me
ok
I'll troll through the list of any numbers that need to be resolved.
dukeleto cotto: if you can close all the RT's that I have been cc'ing to parrot-dev in the last few minutes, that would be awesome
dalek TT #1207 created by dukeleto++: Non-existent lexical throws exception
dukeleto cotto: also, the latest modified trac tickets should have a link to the RT they are replacing 07:13
cotto: icanhaz.com/parrotbugs :)
cotto done 07:15
dalek tracwiki: v3 | bubaflub++ | ConvertTestsToParrot 07:18
tracwiki: Test that check errors can use dies_ok(), throws_like() and throws_substring()
tracwiki: trac.parrot.org/parrot/wiki/Conver...ction=diff
TT #1208 created by dukeleto++: Optimize Parrot_pbc_read to do fewer stat() calls 07:22
diakopter anyone, what's an example of a p6regex in nqp-rx... 07:24
dukeleto diakopter: one sec
diakopter ok 07:28
dukeleto diakopter: ^<[a]>
diakopter: good examples are in the t/p6regex directory of the nqp-rx repo
nqp-rx? 07:29
purl nqp-rx is probably a rewrite of NQP and PGE.
dukeleto purl, forget nqp-rx
purl dukeleto: I forgot nqp-rx
dukeleto purl, nqp-rx is github.com/perl6/nqp-rx
purl OK, dukeleto.
dukeleto Coke: can you close rt.perl.org/rt3/Ticket/Display.html?id=46861 too? 07:31
cotto not now, he can't ;)
dukeleto cotto: i meant to ask you :))
cotto I have a moderately effective dtrt() implementation 07:33
dukeleto cotto++ 07:39
cotto: and rt.perl.org/rt3/Ticket/Display.html?id=50894 :) 07:42
dalek TT #1209 created by dukeleto++: parrot -O Fails Tests
dukeleto can rt.perl.org/rt3/Ticket/Display.html?id=48439 be closed? llvm is listed in PLATFORMS 07:45
07:46 payload joined
dukeleto cotto: please close rt.perl.org/rt3/Ticket/Display.html?id=48439 as well 07:47
cotto with that, I'm out 07:52
dukeleto++
dukeleto cotto: thanks for the help 07:53
dalek rrot: r42262 | chromatic++ | trunk/src/pmc/default.pmc:
[PMC] Removed RT #46665 TODO comment; there's no real value to walking the MRO

thing. PMCs that do something different for their parentage (Class, Object) override the appropriate vtable entries anyway.		 07:56
08:11 elmex joined 08:17 eternaleye joined 08:25 iblechbot joined 08:29 payload joined 08:33 fperrad joined
dalek rrot: r42263 | chromatic++ | trunk/lib/Parrot (2 files):
[lib] Added an exception to ops processor when it (presumably accidentally)
 08:44
08:53 JimmyZ joined
dalek rrot: r42264 | chromatic++ | trunk/lib/Parrot/Pmc2c (2 files):
[lib] Made PMC emitters throw exceptions when encountering unknown NCI
 08:54
08:59 particle joined 09:07 payload1 joined
dalek TT #1210 created by bubaflub++: [PATCH] t/op/inf_nan.t converted to PIR 09:13
09:25 JimmyZ_ joined 09:31 mokurai left 09:36 bacek joined
bacek o hai 09:37
moritz lolitsbacek!
09:38 payload joined
bacek moritz, OH NOES! EVERYBODY PANIC! :) 09:39
chromatic bacek, did you see my comment on TT #1187? 09:40
bacek chromatic, nope. Going to check now 09:41
chromatic, there is no your comments on this ticket... 09:42
chromatic Hm, it's on the list. I wonder why it didn't make it into Trac. 09:43
An optimized Parrot (built with -DNDEBUG) will not export the Parrot_pcc_warnings_on() symbol, thanks to a series of clever macro definitions in include/parrot/context.h:
$ nm -g blib/lib/libparrot.so | grep Parrot_pcc_warnings
We need to fix those macros so that the symbols always get exported but the Parrot core itself can use the quick accessors.
bacek chromatic, hm... Let me check it 09:45
dalek rrot: r42265 | chromatic++ | trunk/compilers/imcc/cfg.c:
[IMCC] Used the "new" way to see if an IMC_Unit represents a PCC sub in IMCC's
 09:46
bacek chromatic, why gcc on OSX fails to expand nested macros?
chromatic I don't know; I know nothing about Mac OS X except that it's apparently some sort of Adamsian Advanced Unix Substitute.
bacek chromatic, :) 09:47
bah... Why xchat switched from ':' to ',' in tab completion?
moritz a famous german blogger always calls Mac OS X a "Unix with a funny hat" 09:48
bacek chromatic, looks like it failing early. On "Ugly cheat" comment. 09:49
chromatic I suspect the right approach is to append _fun to the names of all of these functions and define the macro for the in-core, optimized case differently from the macro for the out-of-core case. 09:50
I'd have done it, but I have an acute case of the premier Perl virtue.
bacek chromatic, I tend to disagree. We can just fix pmc2c to produce header files inside include/parrot/pmc directory. It will bring us closer to "installed parrot" and we can use #include "pmc/pmc_foo.h" in core sources without appending "../" or "../../" all over the place 09:52
chromatic I like that idea, but I don't understand the connection to TT #1187. 09:53
bacek chromatic, include/parrot/context.h, line 32
chromatic That's not the problem I see with t/src/warnings.t. 09:54
bacek chromatic, it is problem. On OSX "context.h" gets included somehow before defining PARROT_IN_CORE 09:55
t/src/warnings_2.c:15: error: dereferencing pointer to incomplete type 09:56
telling exactly this
chromatic # Failed to build 't/src/warnings_2': t/src/warnings_2.o: In function `main': 09:57
# /home/chromatic/dev/gitparrot/t/src/warnings_2.c:14: undefined reference to `Parrot_pcc_warnings_on'
# collect2: ld returned 1 exit status
I had the pointer warning, but I fixed that (on Linux, at least) the other day.
bacek and changing pmc2c to produce headers inside include/parrot/pmc will allow us to include pmc_context unconditionally. 09:58
10:12 kthakore joined
bacek chromatic, actually it should generate headers in "include/pmc" 10:15
10:38 kiwichris joined
dalek rrot: r42266 | fperrad++ | trunk (5 files):
[library] a new PIR library which allows configure step with an installed Parrot and no dependency.
 11:04
rkdown: c035be3 | fperrad++ | Configure.pir:
the stuff is now in a library which comes with Parrot
 11:06
11:08 bacek joined 11:16 shorten joined 11:25 nbrown joined 11:35 plobsing joined 11:45 payload joined
Coke finds he owes dukeleto a beer. 12:08
msg chromatic there are /two/ different ticket-related lists. one goes to the users, one goes to trac. 12:09
purl Message for chromatic stored.
12:12 iblechbot joined 12:29 ruoso joined
dalek rrot: r42267 | NotFound++ | trunk (2 files):
check for null string in Parrot_oo_get_class_str, TT #1107
 12:42
plobsing hi #parrot! 12:47
ttbot Parrot trunk/ r42267 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/132687.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 12:48
dalek rrot: r42268 | NotFound++ | trunk/src/oo.c:
fix a strict C violation introduced in r42267, ttbot++
 12:55
Coke msg cotto thanks for closing out those tickets; I went back through and changed the migrated ones from 'resolved' to 'reject' to match the other tickets that were migrated-but-not-fixed. 13:09
purl Message for cotto stored.
Coke cotto++ 13:10
dukeleto++
chromatic++ # actually closing some tickets the old fashioned way! 13:11
RT: now at 70
13:15 whiteknight joined 13:17 kid51 joined
whiteknight good morning #parrot 13:17
kid51 good morning whiteknight 13:18
msg mikehh Could you give the 'convert_OSNAME' branch a 'make fulltest' run on your 64-bit platform? See trac.parrot.org/parrot/ticket/1194. Thanks. 13:20
purl Message for mikehh stored.
13:22 he__ joined, he__ left
whiteknight has a LOT of emails this morning 13:23
Coke++
dukeleto++
Coke regarding my sent-just-now, any bikeshed ideas on how to mark tickets as 'this is resolved" in the docs? 13:27
TT #12354 is a live issue... TT #-12344 ? TT *12345 ? 13:28
my thinking is it would be nice to know at a glance if the comment was because something was broken or because it was fixe.d. 13:29
13:51 davidfetter joined 13:58 mikehh joined 14:24 kj joined 14:32 payload joined 14:33 masak joined 15:08 patspam joined 15:13 payload joined 15:20 joeri joined 15:26 s1n joined 15:27 _particle_ joined, Psyche^ joined 15:41 whiteknight joined
Coke only 70 tickets to go. Will you be the person to close out lucky ticket # 42 ? only one way to be sure. 15:46
dalek rrot: r42269 | dukeleto++ | trunk/t/op/00ff-unix.t:
[t][TT# 1186] Convert t/op/00ff-unix.t to PIR, bubaflub++
Coke perl6 people: is rt.perl.org/rt3/Ticket/Display.html?id=60098 closable? 15:47
actually, yes, I'm going to call it.)
dalek TT #1186 closed by dukeleto++: [PATCH] convert t/op/00ff-unix.t to PIR 15:48
15:56 mikehh joined 15:57 theory joined 16:07 fperrad joined 16:24 payload joined 16:48 mikehh joined
whiteknight is happy about fperrad++'s random number module 16:52
NotFound whiteknight: You won a lottery using it? 16:53
whiteknight not that happy
fperrad whiteknight, Math/rand.pir or Math/Random/mt19937ar.pir ? 16:55
whiteknight mt19937ar 16:56
fperrad whiteknight, mt19937 will leave the nest, see github.com/fperrad/parrot-MT19937
whiteknight yes, that's what I'm looking at right now 16:57
I didn't realize mt19937 was in the repo at all
I've been wanting to implement an MWC generator for Parrot 17:01
maybe I will do that sometime
Coke (Leave) don't forget to open a ticket and put it in DEprecated. 17:04
mwc? 17:06
whiteknight multiply-with-carry 17:07
it's a very nice PRNG algorithm with extensible period
17:13 desertm4x joined 17:14 szabgab joined
Coke RT: 69 tickets left. 17:21
jonathan: should I steal back the tickets I assigned to you? 17:22
jonathan Coke: In RT, I seem to ahve 2. 17:23
(for Parrot)
46687[TODO] [C] Correct destruction of PackFile objects0parrotopen # I think I'm unlikely to fix that, but given other work done in the area, it may already be done
Coke jonathan: yup. probably bc you opened the original ticket.
figured you'd know if it needed transferring. 17:24
jonathan Right
61224.eof returns false if last read call read the last byte of the file, but not beyond
Coke (or because you volunteered ages ago)
2/69
purl 0.0289855072463768
jonathan I think on that second one, there was some debate as to whether that behavior was by design.
Coke that's 3% of the tickets. You could really make a difference. =-)
jonathan Coke: to be honest, it's a design call rather than a bug. 17:25
We work around it in Rakudo.
I don't mind which way it goes.
Don't know what the criteria is for mvoing to trac either ;-) 17:26
Coke everything goes.
(unless it's bogus or done.)
jonathan I'd move the .eof one over. It's probably still worth a final design ruling, which it appears not to have got. 17:27
If the comment in #46687 still exists, then I'd say move it over - if the comment is gone, it can be closed.
pmichaud note there's already a ticket in trac referring to eof issues 17:28
(the readline ticket)
they should probably reference each other
jonathan They may boil down to one and the same. 17:30
In fact, I think they do.
Coke jonathan: ok. I stole 61224 just now, but won't mind if you steal it back. 17:31
jonathan: danke.
jonathan Coke: Thank you.
Coke er, blagodaria. or whatever language you're speaking these days. 17:32
jonathan: was the trac ticket #760 ? 17:34
dalek TT #1211 created by coke++: make realclean doesn't remove src/dynpmc/Makefile
17:34 davidfetter joined
jonathan Coke: Heh, Slovak. :-) 17:34
Coke ah, dakujem! 17:35
jonathan Coke: I'm pretty sure they're related problems.
Coke ETOOMUCHANALYSIS. 17:36
jonathan Ah, and yes, that was the trac ticket I think Pm was thinking of. It's the one I was.
dalek TT #1212 created by jonathan++: .eof returns false if last read call read the last byte of the file, but ... 17:37
NotFound About the .eof thing: the current way is the sane one. Languages that want read-ahead must do themselves. 17:41
Coke NotFound: comment on the ticket. 17:42
(please)
NotFound Coke: I think I'v already do that months ago...
Coke danke.
17:43 desertm4x_ joined, darbelo joined
Coke I don't see that on #760 or the new one, btw. 17:43
(#1212)
NotFound The design reason is: if you want to read ahead, you can do. If you do it always, you can't simulate not have done it.
Coke (you do have commentson #760, but not that.)
NotFound Maybe it was at #ps, not in the ticket- 17:44
Coke NotFound: sure you can. if you make every read go through whatever that mechanism is.
NotFound Coke: yeah, and you can't even not use parrot ;)
can
Coke NotFound: I'm often tempted.
though I take it you mean you could circumvent whatever parrot used and just use C. Sure. 17:45
NotFound Is not reasonable to force any language that wants no read ahead to not use the standard handles.
Coke standard /parrot/ handles? 17:46
NotFound Yes
PerlJam ETOOMANYNOTS
(had to read it 3 times to grok)
NotFound PerlJam: ENOTTOOMANYNOTNOTS
Coke k. if you're using a parrot handle, then you can avoid the direct C-level access. If it's in-core, it's standard. =-)
but. 17:47
I'm fine with someone doing this as an IO subclass or something and then sharing it.
parrot has enough other broken stuff to fix.
darbelo PerlJam: It makes sense in spanish :)
PerlJam darbelo: heh!
Coke qualquier?
NotFound The point is that is a lot easier to do read ahead when wanted that find a way to avoid it when not wanted. 17:48
darbelo reads messages
Coke++ # KHAAAAAN 17:49
17:49 mokurai joined
Coke spells that wrong. 17:49
NotFound darbelo: Are yiu saying that Spaniards are negative? ;) 17:50
darbelo NotFound: I'm not negating they are not.
;) 17:51
Coke NotFound: looks like 57028 could be resolved by deleting code.
you want that one? 17:53
NotFound Coke: if is related to the register allocatror, better that chromatic take a look at it.
Coke it is. I'll take it and just rip it out. 17:54
dalek rrot: r42270 | coke++ | trunk/config/gen/makefiles/root.in:
add missing dependency.
 18:01
Coke GAH. 18:04
dalek rrot: r42271 | coke++ | trunk/config/gen/makefiles/root.in:
more missing dependencies.
 18:05
Coke did someone just add pmc_context.h as an include all over the place, or am I just lucky today?
cotto_work Coke, istr someone did that 18:06
Coke BACEK! 18:07
bacek--
bacek++ #perhaps a slight overreaction.
NotFound Contexts are used in lots of places. 18:08
dalek rrot: r42272 | coke++ | trunk/config/gen/makefiles/root.in:
MORE missing dependencies
Coke msg bacek when you add an include to a c file, you MUST add it as a dependency in root.in
purl Message for bacek stored.
Coke *sigh* 18:09
Coke starts checkdepend.pl 18:12
cotto_work Coke, why not write it in nqp? 18:13
darbelo Coke: I think andy had a branch with something similar.
cotto_work it's abandoned
Coke darbelo: we already pinged him about it. 18:19
cotto_work: ... because I don't speak perl6 ?
I'm just going to whip something up. if folks want to change it later, fine with me. 18:20
Coke is just sick of fixing this bug.
cotto_work sure. nqp would be ideal, but a perl script is better than what we're doing now.
NotFound I can try do something with Winxed, but first myst find a wat to use regexes. 18:21
cotto_work (though using nqp would make moving partcl to pct easier)
Coke cotto_work: how would using nqp for this stupid script help partcl? 18:22
18:22 Andy joined
cotto_work If you want to switch partcl to pct, you'll have to write some nqp. 18:22
Learning some of it now will make that easier. 18:23
dalek rrot: r42273 | fperrad++ | trunk (2 files):
[library] genfile handles conditioned line
 18:24
Coke i prefer doing that jit
cotto_work your call 18:25
18:26 sjohnson joined
dalek rkdown: 976a224 | fperrad++ | (2 files):
use conditioned lines
 18:30
shorten dalek's url is at xrl.us/bf2xkr
nopaste "coke" at 72.228.52.192 pasted "hacky first cut at checkdepend" (55 lines) at nopaste.snit.ch/18576 18:45
Coke a verrrry rough first pass that at least gives me something useful if I do perl checkdepend.pl | ack pmc_ 18:46
that could, with some thought, be turned into a distro test.
nopaste "NotFound" at 213.96.228.50 pasted "First step to locate #include to track C dependencies" (22 lines) at nopaste.snit.ch/18577 18:50
NotFound Can someone tell me if this is a correct way of using PGE::P5Regex ?
Coke NotFound: that doesn't take the makefile into account, does it?
NotFound Coke: is just a first step 18:51
Coke ok. my first step is further than yours. =-)
just don't want to duplicate effort.
darbelo Coke: You have a longer stride :) 18:52
NotFound Coke: It took me more time because I needed to implement compreg first X-)
Coke IWBNI make had a preprocessor.
is there a way to say "show me what the makefile would look like if you interpolated all the variables? 18:53
NotFound Coke: I don't think a duplicate effort is a waste, if you have two implementations we can test one with the other.
s/you/we
Coke NotFound: <shrug> it's a waste for me. have fun. =-) 18:54
I just want the /problem/ solved.
NotFound And I must write more code to implement and test features of winxed anyway.
18:56 jhorwitz joined 19:03 chromatic joined
diakopter oh hi 19:05
purl privet, diakopter.
diakopter say what
purl say is, like, Say is way better than typing print "$foo\\ all the time
diakopter hm
19:07 pmichaud joined, particle joined
NotFound Coke: Do you remeber if there is some ticket calling for a dependcy checker? 19:24
cotto_work NotFound, trac.parrot.org/parrot/ticket/893 19:26
NotFound cotto_work: thanks 19:27
Coke cotto_work: feel free to combine those tickets. =-)
NotFound Did a said yet that parrot is poweful? 19:33
Coke ? 19:37
whiteknight ETOOMANYTYPOS 19:38
NotFound Sorry, I'm with a coldness and my english is even worse than usuallyç 19:39
cotto_work NotFound, you have a cold?
My mom always told me "Don't get sick." I wish I'd listened.
NotFound cotto_work: yes, but nothing important. 19:40
darbelo I was told "Dont *be* sick." but I didn't listen either.
;)
whiteknight I knew a guy once who didn't listen to his mother. 20 years later, BAM! hit by a bus 19:41
always listen to your mother
NotFound There was a guy that go, and died. Moral: dont' go.
cotto_work also, watch out for buses 19:42
whiteknight ...that's what mother said :)
NotFound watch his PCIs
19:53 jan joined
Coke how to regen the makefile? 19:55
(without a full config?)
20:04 dalek joined
dalek TT #1213 created by coke++: need a tool to check make dependencies 20:05
diakopter twimc, I converted my STD/ast interpreter (in perl/js(v8)) to a PAST interpreter (in js(v8))
20:06 PerlJam joined 20:08 Util joined, dukeleto joined
diakopter ... I guess it could be called jsPAST, er something 20:08
20:11 Infinoid joined 20:13 pmichaud_ joined, jonathan joined 20:33 allison joined
nopaste "darbelo" at 190.192.220.13 pasted "Remove instantiate_str() VTABLE, take one" (440 lines) at nopaste.snit.ch/18580 20:44
"darbelo" at 190.192.220.13 pasted "Error with the above patch" (7 lines) at nopaste.snit.ch/18581 20:47
Coke has an updated version of that script and will see about adding it later. 20:50
20:51 joeri left
nopaste "darbelo" at 190.192.220.13 pasted "Remove instantiate_str() VTABLE, take two (Less diff noise. Still fails.)" (372 lines) at nopaste.snit.ch/18582 20:53
whiteknight darbelo++ 20:54
darbelo I anyone can tell what the heck I'm doing wrong in nopaste.snit.ch/18582 I'll be very happy.
The error I get is in nopaste.snit.ch/18581 which means that something that I'm creating a constant PMC where I shouldn't, but I can't really tell where. 20:56
whiteknight why are you using constant_pmc_new in make_string_pmc
darbelo The call I removed was passing PObj_constant_FLAG to the VTABLE, that called constant_pmc_new() internally. 20:58
Coke seen bacek? 20:59
purl bacek was last seen on #parrot 10 hours, 43 minutes and 46 seconds ago, saying: chromatic, actually it should generate headers in "include/pmc"
whiteknight ah, okay 21:00
dalek TT #1213 closed by coke++: need a tool to check make dependencies 21:02
21:03 mokurai joined 21:06 mikehh joined
darbelo Ha! Found it! 21:16
of course, that only means it fails differently. 21:17
but I call that progress.
And now it works. 21:20
(paste errosr)--
(paste errors)-- too
cotto_work darbelo++ 21:21
now we need to nuke some of those math ops
s/ops/vtables/
Coke is getting 271 missing dependencies. 21:22
cotto_work eek
I guess I shouldn't be surprised though.
Every time we lift up a rock we expose a whole new colony of bugs. 21:23
nopaste "coke" at 72.228.52.192 pasted "output of checkdepend.pl" (1811 lines) at nopaste.snit.ch/18584
Coke (they appear to be mostly pmc related.) 21:24
(and I'm skipping a lot)
darbelo $(GENERAL_H_FILES)-- 21:25
Coke darbelo: yes, well, it was an easy solution when we didn't have a tool to track deps. =-)
I'll check this at some point. 21:26
darbelo If we can manage to remove that, I'm sure parallel build can get faster on multicore boxes.
A lot more brittle, but faster.
chromatic I wouldn't think it makes things more brittle. 21:27
Coke Sure. Open a ticket.
moritz robust is much more important than fast, in the case of parallel builds
Coke given a tool to make sure we're not screwing anything up... 21:28
darbelo chromatic: They'll be easier to break when shuffling includes. Maybe the word is 'sensitive'
Coke bah, I'll just commit now.
darbelo Coke++ 21:29
JFDI++
moritz I'll complain if it breaks the build ;-) 21:30
Coke there, have fun.
moritz: I tested code/distro before committing.
(though I did modify the file after that. =-) 21:31
there. now someone else please look at that and make it pass. =-)
dalek rrot: r42274 | coke++ | trunk (2 files):
Add a tool to verify makefile deps based on C #includes.
Coke (and then avoid skipping any includes)
(and then make it run in distro_tests)
darbelo we have a distro_tests? 21:32
Coke or something, yes.
chromatic I like that idea. 21:33
Coke msg bacek - you need to run tools/dev/checkdepend.pl and clean up.
purl Message for bacek stored.
cotto_work iwbni dependency resolution were part of the configure process
darbelo I'm assuming it runs as part of fulltest, right?
Coke msg bacek (unless someone beats you to it.)
purl Message for bacek stored.
Coke cotto_work: for now, easier to find problames after they're made; could rework it to prevent them.
cotto_work yes
one thing at a time 21:34
Let's see some commits! 21:41
mikehh Coke: I get - 1..312 - # Looks like you failed 271 tests of 312. 22:00
cotto_work yeah. there's a couple failures 22:03
dalek rrot: r42275 | darbelo++ | trunk (2 files):
Remove all calls to the instantiate_str() VTABLE.
 22:07
22:08 Whiteknight joined
dalek rrot: r42276 | darbelo++ | trunk/src/pmc (4 files):
Remove the now unused instantiate_str() VTABLE from all four PMC that implemented it.
 22:11
cotto_work darbelo, feel free to remove that from vtable.tbl (just be sure to bump PBC_compat) 22:13
darbelo cotto_work: next commit ;) 22:14
dalek rrot: r42277 | darbelo++ | trunk (4 files):
Remove mentions of the instantiate_str() VTABLE from the documentation and auxiliary scripts.
darbelo Not this one, the next commit ;) 22:15
22:20 FullMetalHarlot joined
dalek rrot: r42278 | fperrad++ | trunk (2 files):
[library] genfile handles conditioned line with logical expression
 22:21
darbelo cotto_work: Wait I have to bump PBC_COMPAT for VTABLE deletions? 22:23
cotto_work yup. it changes the bytecode format
darbelo I though that was for ops.
Thanks for the tip.
22:23 leto joined
cotto_work I may have been wrong. 22:24
Whiteknight I don't think it has anythign to do with bytecode
leto howdy! just a heads up: the machine that updates the parrot github mirror died and I am currently attempting to get stuff set back up
so the parrot github repo may not get updated until later today
cotto_work I must have been thinking of ops.
22:25 leto joined
Whiteknight leto++ 22:26
darbelo commit went in without the bump.
We can still do it later if it was needed. 22:27
chromatic I can't think of why it might change PBC. 22:28
cotto_work My mistake. 22:29
dalek rrot: r42279 | darbelo++ | trunk/src/vtable.tbl:
Remove the instantiate_str() VTABLE from vtable.tbl
cotto_work chromatic, would it be a bad idea to excise the bitwise vtable functions? 22:31
chromatic That doesn't mean it doesn't change PBC, only that I have no idea why.
cotto_work, aren't some of those deprecated anyway?
cotto_work DEPRECATED says "Current list of VTABLE functions will be reviewed and cleaned." 22:32
darbelo The deprecation notice in DEPRECATED.pod is wide enough we could remove anything we wanted, really.
chromatic I thought I remembered a specific list somewhere. 22:34
Oh joy, RT #57028, PGE, pdd25cx, and the register alligator. I need a snack first. 22:35
cotto_work yup. they're mentioned in docs/embed.pod 22:36
dalek rrot: r42280 | jonathan++ | trunk/runtime/parrot/library/P6object.pir:
Addition to P6object to make sure it can handle Rakudo ng branch's metamodel requirements.
 22:45
TT #1072 closed by darbelo++: deprecate vtable function instantiate_str 22:46
22:57 allison joined
Coke ... config/auto/pmc.pmc is borked. 23:17
(it's generating the PMC deps, and /it's/ missing things.)
cotto_work That's what you get for turning over rocks. 23:20
Coke and I am assuming there's logic duplicated there (one to generate the makefile deps, one to generate the #includes later) 23:21
darbelo Coke: Just don't assume sanity.
Coke opens a new ticket. 23:25
23:32 plobsing joined
plobsing hi #parrot 23:34
Coke reconsiders the ticket. 23:35
darbelo hi plobsing
23:37 mokurai joined
chromatic Hm, removing instantiate_str() and the other commits since last night gave us 1.511% better performance on fib.pir. 23:38
darbelo Did you manage to update the frame builder to curent pcc internals?
chromatic Not the old frame builder, no. 23:39
cotto_work I wonder what nuking the bitwise vtable functions will do for us.
darbelo Sorry, that was for plobsing, I meant his libjit one.
I think he was working on updating it, last I heard.
plobsing darbelo: yes.
unfortunately I had a brain fart yesterday and generated a 1.5M patch. 23:40
I have a workaround
mutch smaller patches. yay
darbelo That's a big patch.
plobsing exactly
my new strategy generates 3 patches, ~100K each 23:41
1/5 the size
total
darbelo What was the old approach and what is the new one? 23:42
plobsing old approach diff against auto_libjit branch. new approach, diff against master
the problem was that pcc_reapply merge is a huge diff
dalek tracwiki: v3 | japhb++ | NCITasklist 23:43
tracwiki: Add link to IRC log of discussion
tracwiki: trac.parrot.org/parrot/wiki/NCITas...ction=diff
shorten dalek's url is at xrl.us/bf2y5f
darbelo master? You are using git, then. I can see how that can go wrong.
plobsing master = trunk
darbelo svn <-> git interactions are messy when branches are involved. 23:44
plobsing while that may contribute, if I were working in svn, I still would have made a huge diff the old way 23:45
darbelo Yeah, but svn users often extract a patchset to reapply on a new branch instead of merging. 23:46
Coke fixes the PMCs deps without opening a ticket.
darbelo That happeden on the pcc branch a few times.
Coke++
dalek rrot-plumage: 607e316 | japhb++ | :
[META] TODO: Add repository metadata todos
shorten dalek's url is at xrl.us/bf2y5s
Coke that brings me down to only 53 missing deps. 23:47
darbelo Coke++
dalek rrot: r42281 | coke++ | trunk/config/auto/pmc.pm:
Fix some PMC dependencies.

   - recent PCC changes probably added more deps on other pmcs, but these were never reflected in the makefile deps.		 23:48
darbelo plobsing: anyways, are those diffs up anywhere? 23:51
plobsing I have added to TT#1105. It contains 3 patches and instructions for applying them.
darbelo looks
plobsing: looks good. Want me to create a new branch and apply thise diffs? 23:56
plobsing please do

Powered by Cro and the Raku® Programming Language.

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

Thank you!