Camelia, the Perl 6 bug

IRC log for #parrot, 2009-09-09

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 szbalint my point was that there is already a built in time delay, I don't think there would be anyone who would say "well I'd contribute, if not for the project's tendency to use git"...
00:00 szbalint at least if I try to think about barriers of entry as a newbie
00:01 szbalint which I am :)
00:01 allison How is Git for source browsing tools, as in Trac?
00:02 allison Does it have integration with Trac?
00:02 allison How does it handle commit notifications (parrot-commits list)?
00:02 szbalint gitweb is written in Perl :)
00:03 darbelo szbalint: hand Whiteknight a ~200 line patch removing shitty code, he'll *force* a commit bit on you rather than reviewing another one of those.
00:03 treed allison: Unsure about Trac, but git has the appropriate pre/post-commit hooks.
00:03 Whiteknight darbelo: I want good coders to have access to the code
00:04 Whiteknight I don't think I support a switch if it's going to regress features on Trac
00:04 Whiteknight that would be far too much pain
00:04 allison szbalint: gitweb looks pretty primitive
00:04 chromatic Yes, we need to keep Trac integration.
00:05 szbalint there apparently multiple plugins for trac - git integration, I don't have first hand experience with that issue
00:05 allison so it might work, or it might require a few revisions to get a working version like email2trac did
00:06 Whiteknight ...does email2trac work now?
00:06 darbelo allegedly, it does.
00:06 duk3leto i wouldn't propose switching to git if we couldn't have the same kind of trac integration that we do now
00:07 duk3leto http://trac-hacks.org/wiki/GitPlugin
00:07 dalek tracwiki: v2 | dukeleto++ | GitCookbook
00:07 szbalint it's something to test I guess
00:07 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=2&action=diff
00:07 duk3leto looks like trac supports git
00:07 Tene So... what's the trac integration with svn?  I don't actually use trac enough to know what's being discussed here.
00:08 allison Whiteknight: yup, I tested it round trip, it really works
00:08 allison Tene: a really nice source browser, revisions act like wiki pages, and auto link from tickets
00:09 Whiteknight allison: any kind of announcement or documentation about it?
00:09 szbalint allison: gitweb is quite basic, but with git you can browse the repository locally with applications running on localhost itself - so for advanced usage that's the solution probably
00:09 szbalint since you actually have the whole repository history
00:09 Tene szbalint: or just as much of it as you want.
00:10 Tene Git supports shallow clones.
00:10 allison Whiteknight: I thought I saw a message from Coke run by the mailing list when we got it working
00:10 allison szbalint: what's the interface like?
00:10 Whiteknight maybe I missed it
00:11 allison Whiteknight: essentially, if you reply to a ticket email message, it gets added as a comment to the ticket
00:11 Whiteknight oh, that's hot
00:11 allison Whiteknight: and if you email to tickets@parrot.org it creates a new ticket
00:11 szbalint allison: multiple GUIs are available, I prefer commandline so I don't really know, just tried a few out for curiosity's sake...
00:12 chromatic tickets@parrot.org works now?  That's good!
00:12 Tene :D
00:12 szbalint did anyone try to import the whole svn history into git yet btw? How's that wrt repository size?
00:12 Tene gitk and git-gui are the traditional ones... don't know about others or newer guis.
00:12 allison ah, I thought folks knew that (I did mention it in my report that week, at least)
00:12 Whiteknight see? even chromatic didn't know! And he's supposed to know everything
00:13 chromatic I tried responding to a ticket, didn't see if it worked that way.
00:13 duk3leto szbalint: we have a git-svn mirror, but I haven't gotten the info public yet
00:14 duk3leto szbalint: the git-svn metadata takes up a lot of space. it is quite large. i can get you the exact figure in a bit
00:14 * duk3leto says "screw you" to firefox for losing the most recent changes to the git cookbook
00:14 Tene duk3leto: ^W ?
00:14 purl ^W is ^Wine
00:15 * allison has to be up and on the road in less than 8 hours, turning in
00:15 szbalint debian sid has about 4-5 git guis
00:15 Tene 'night allison
00:16 allison Tene: 'night
00:16 cotto clock?
00:16 purl cotto: LAX: Tue 5:16pm PDT / CHI: Tue 7:16pm CDT / NYC: Tue 8:16pm EDT / LON: Wed 1:16am BST / BER: Wed 2:16am CEST / IND: Wed 5:46am IST / TOK: Wed 9:16am JST / SYD: Wed 10:16am EST /
00:16 duk3leto Tene: gitx is pretty slick if you are on os x
00:16 szbalint my experience is that a pure git checkout with all the repo history is smaller or on par with a svn HEAD checkout
00:17 duk3leto szbalint: git is about 3 times smaller, on average
00:17 dalek tracwiki: v3 | dukeleto++ | GitCookbook
00:17 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=3&action=diff
00:17 duk3leto szbalint: since it doesn't have a .svn dir in *every* directory with a bunch of redundant information
00:18 szbalint yeah
00:18 szbalint one thing git doesn't do and that's the reason we didn't switch over to it from svn at $job is partial checkouts
00:18 szbalint but I don't think that applies here
00:19 szbalint partial checkout as in checking out a subdirectory from a svn repo
00:19 duk3leto szbalint: git has submodules, which solve that problem in a different (better) way :)
00:20 duk3leto szbalint: also, svn allows you to commit a partial tree, if you are in a subdir, which I find completely horrendous
00:20 szbalint oh, interesting. Haven't heard about that yet :)
00:21 dalek tracwiki: v4 | dukeleto++ | GitCookbook
00:21 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=4&action=diff
00:22 cotto duk3leto, an index would be helpful on that page
00:23 duk3leto cotto: patches welcome :)
00:23 treed szbalint: http://progit.org/book/ch6-6.html
00:23 treed Submodules.
00:23 purl submodules are useful for something like perl's ext/ dir
00:23 duk3leto cotto: but not conflicts :)
00:25 Whiteknight duk3leto: fatal: not a git repository
00:25 Whiteknight (first command from the cookbook)
00:25 Whiteknight git checkout git://github.com/leto/parrot.git
00:26 duk3leto Whiteknight: well, i suck then
00:26 duk3leto Whiteknight: duh! it shold be clone. fixing now
00:27 duk3leto git clone git://github.com/leto/parrot.git
00:27 duk3leto Whiteknight++ for checking my shtuff
00:27 Whiteknight okay, getting it now. This is going to take some time, isn't it?
00:27 dalek tracwiki: v5 | dukeleto++ | GitCookbook
00:27 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=5&action=diff
00:28 Whiteknight I only need to do this clone operation once, right?
00:28 duk3leto Whiteknight: checkout just a pure git repo? perhaps a few minutes, depending on your net speed.
00:28 duk3leto Whiteknight: yes, you only need to clone once. you are getting the *entire* history of parrot.
00:29 Whiteknight okay, so after this, how do I branch?
00:29 chromatic git branch <branchname>
00:29 duk3leto Whiteknight: add that now to the wiki :)
00:29 cotto duk3leto, that's why I haven't done anything yet.
00:29 Whiteknight chromatic: rephrased, where does it branch from? is the branch another clone that will take "a few minutes" to get?
00:29 treed "git checkout -b <branchname>" is arguably more useful
00:29 treed (Makes the branch *and* makes it the active one.)
00:30 duk3leto Whiteknight: on the wiki now
00:30 Whiteknight treed: I won't want "arguably" anything. I just want the most simple way to do a few things
00:30 szbalint treed: hm, I might be slow but submodules appear to be about "embedding" another git repo in a git repo's tree. How would I go on to check out a git repo where I'm interested in only a (potentially) small part of the tree?
00:30 chromatic No clone, it's a local branch.
00:30 treed Whiteknight: Once you have the the back history, you shouldn't need to download much ever again.
00:31 treed szbalint: You change your method such that directories that might be wanted separately are separate, and included in the main repo.
00:31 Whiteknight chromatic: see, there's obviously some disconnect between git terminology and my internal representation
00:31 dalek tracwiki: v6 | dukeleto++ | GitCookbook
00:31 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=6&amp;action=diff
00:31 Whiteknight because I have no idea what the hell the difference between those is supposed to be
00:31 szbalint treed: ah, so inside out thingy, okay
00:31 treed Whiteknight: "git branch <branchname>" makes the branch, and then you "git checkout <branchname>" to actually work on it.
00:31 treed Whiteknight: Or you can just do "git checkout -b <branchname>" to do both
00:32 treed (Which is usually what you want.)
00:32 chromatic Whiteknight, the .git file in the top-level directory *is* the repository.
00:32 chromatic Within your top-level directory, you can switch between branches at will.
00:32 chromatic You don't have to check out new checkouts for each branch you want to manage.
00:33 chromatic Understand more now?
00:33 duk3leto chromatic: unless you want to work on many branches simultaneously ;) we won't go there right now
00:33 duk3leto Whiteknight: our git cookbook needs a glossary. same page or different page ?
00:34 duk3leto git is like math, where people use simple words to mean very specific things
00:34 dalek tracwiki: v7 | dukeleto++ | GitCookbook
00:34 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=7&amp;action=diff
00:35 duk3leto Whiteknight: is that page approaching something useable for you? don't candy coat anything, tell me how it is, straight up.
00:35 duk3leto Whiteknight: ALSO, you should install the git bash completion script. it shows you the current branch in your PS1, and I find that invaluable
00:36 cotto $PS1 is fun
00:36 Whiteknight chromatic: yes, that makes much more sense
00:37 Whiteknight duk3leto: I'll try to follow along for now, it's going alright for what I am trying to do
00:37 szbalint .git is your full blown repo, while the files you're working with are a manifestation of the current branch. git checkout switches the contents of the files/directories to the branch based on info in .git
00:37 Whiteknight I write all my own local aliases that add svn version numbers to PS1
00:38 chromatic You don't even want to know about the niceness that is git bisect.
00:38 Whiteknight what is going to make this merge possible for me, considering I'm like functionally retarded with these kinds of things, is that I have an elaborate set of macros that I can just redefine
00:39 Whiteknight so I only need to learn the right way once
00:39 treed "manifestation of the current branch" == "working directory"
00:39 treed chromatic: Doesn't svn have bisect, too?
00:39 treed http://search.cpan.org/~infinoid/​App-SVN-Bisect-0.8/bin/svn-bisect
00:39 duk3leto treed: holy hotdogs, batman!
00:40 treed I guess it's not stock.
00:40 treed But such a tool exists for svn. (And from our own Infinoid, no less.)
00:40 treed But, yes, git bisect is awesome.
00:40 szbalint git blame too
00:40 treed As is "git commit -i"
00:40 treed And git rebase -i
00:40 purl hmmm... git rebase -i is NOT a tool for viewing a branch
00:41 treed No, it certainly is not.
00:41 sri joined #parrot
00:41 shockwave joined #parrot
00:41 Whiteknight duk3leto: where is this git bash completion script at?
00:42 treed Is there a git zsh completion module?
00:42 * treed has completely forgotten why he switched to zsh back in the day.
00:42 treed the vi keybindings just mostly get in the way
00:42 treed Because there's no status line to tell me what mode I'm in.
00:42 duk3leto Whiteknight: http://repo.or.cz/w/git.git?a=blob;f=c​ontrib/completion/git-completion.bash
00:44 Whiteknight duk3leto: so this repository you have on git, does it interact with svn.parrot.org?
00:44 Whiteknight like, how do I get my changes to that server?
00:45 dalek tracwiki: v8 | dukeleto++ | GitCookbook
00:45 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=8&amp;action=diff
00:45 dalek tracwiki: v9 | dukeleto++ | GitCookbook
00:45 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=9&amp;action=diff
00:45 duk3leto Whiteknight: the github mirror is a pure git mirror of svn. you want to push changes to it?
00:45 duk3leto Whiteknight: i also push some of my local git branches there, so others can see them
00:45 Whiteknight duk3leto: I don't care where I push changes to, so long as they end up on svn.parrot.org
00:46 duk3leto Whiteknight: i don't know if I answered your question
00:46 Whiteknight I don't know if I asked a sensible question
00:46 duk3leto Whiteknight: I don't think you did :) so we are even
00:46 chromatic I think you're asking about git-svn.
00:46 Whiteknight Okay, I make a change locally. I want to put that change on svn.parrot.org. I do this by typing "..."?
00:47 duk3leto git-svn makes everything exponentially more complicated
00:47 chromatic git add ... ; git commit ... ; git svn dcommit
00:47 chromatic Possibly also a git svn rebase in there.  See "more complicated".
00:47 Whiteknight chromatic: and those incantations will put changes on svn.parrot.org?
00:47 Whiteknight that's the only result I care about
00:47 chromatic Yes.
00:47 duk3leto Whiteknight: IF you are using git-svn with the correct setup
00:48 Whiteknight okay, I got a "yes" and a "maybe"
00:48 chromatic This is where someone like allison says "Blurgh, argh, that sucks, that is awful, that is way too many commands, why would you do it that way?"
00:48 duk3leto Whiteknight: in your *current* setup, having a git repo branched from github, you can't commit to svn. you need the git-svn metadata magic
00:48 Whiteknight okay. Lay that stuff on me
00:48 duk3leto Whiteknight: there is a public mirror of the entire git-svn history of parrot. i need to find that link
00:48 chromatic ... and where the rest of us say "That's why we're not big fans of git-svn."
00:49 Whiteknight I'm not daunted by learning new things. For personal growth learning new things is important
00:50 duk3leto Whiteknight: git-svn is daunting, no matter who you are.
00:50 Whiteknight I find some software is more amenable to the learning process then others
00:50 duk3leto Whiteknight: git-svn performs black magic. no kiddin'
00:50 chromatic All I'm saying is "Git isn't so difficult to use, once you learn a few commands".
00:51 chromatic Don't mistake the git-svn complexity for the rest of Git.
00:51 duk3leto git is easy to use. git-svn is a necessary evil
00:51 Whiteknight duk3leto: That's fine, black magic, hard to use, blah blah blah. How do I do it?
00:51 duk3leto Whiteknight: that is what the git-svn wiki page is for
00:51 Whiteknight we have a page for it? link?
00:52 duk3leto Whiteknight: https://trac.parrot.org/pa​rrot/wiki/git-svn-tutorial
00:52 duk3leto feast on that for abit :)
00:52 Whiteknight (I find it remarkably hard to find things on the trac wiki)
00:52 duk3leto ooh, there is another git-svn mirror: http://moritz.faui2k3.org/fil​es/parrot-all-git-svn.tar.gz
00:53 duk3leto Whiteknight: the gitcookbook is meant as an intro to pure git, the git-svn-tutorial is where the real fun is :)
00:54 Whiteknight yeah, I'm reading it now
00:54 Whiteknight still isn't answering my question though, that I can see
00:55 duk3leto Whiteknight: please rephrase question
00:55 darbelo While I wait for my bit to be activated, can someone review/commit the patch attached to TT#986 ?
00:55 * darbelo has Z's to catch.
00:55 duk3leto Whiteknight: you want to push changes to SVN from git-svn ?
00:56 Whiteknight duk3leto: I have the git repo that I pulled from your guthub thingy. I make changes locally. I want to commit those changes to svn.parrot.org
00:56 Whiteknight so I type "git-svn ..." and that magically happens
00:56 Whiteknight and everybody is happy
00:56 duk3leto Whiteknight: that would be "git svn dcommit", which takes your local git commits and does a "distributed commit"
00:56 duk3leto Whiteknight: no. you need a git-svn repo. you currently have a pure git repo
00:56 Whiteknight ah, that's the step I'm missing!
00:56 duk3leto Whiteknight: download http://moritz.faui2k3.org/fil​es/parrot-all-git-svn.tar.gz
00:57 Whiteknight so I need a separate repo entirely?
00:57 darbelo left #parrot
00:57 duk3leto Whiteknight: unpack that, *then* you will have a git-svn repo
00:57 Whiteknight okay, and from there I can commit to svn.parrot.org
00:57 duk3leto Whiteknight: they can be the same repo or different
00:57 Whiteknight ?
00:57 duk3leto Whiteknight: yes
00:57 Whiteknight okay.
00:58 duk3leto Whiteknight: from within a git-svn repo, you can commit to : pure git OR svn. from within a pure git repo, you can only commit to another git repo
00:58 Whiteknight okay. Makes sense
00:58 duk3leto Whiteknight: first thing you should do when you download and untar that file is: cd parrot;git svn rebase
00:59 duk3leto Whiteknight: git svn rebase =~ svn up
00:59 Tene Kinda.  There's some nastiness there.
00:59 duk3leto Whiteknight: you can also do "git svn dcommit -n" to see a "dry run"
00:59 duk3leto Tene: shhhh!
01:00 duk3leto Whiteknight: so see the diff between your local copy and trunk: git diff svn/trunk..
01:01 duk3leto s/so see/to see/
01:01 duk3leto now we need to get into the idea of "commitishes" and i need to go home
01:02 Tene treed++ # agree with mail to the list
01:02 treed Sweet, I'm not completely talking out of my ass there.
01:02 * treed thought that maybe he didn't really understand push if people think it could be used that way.
01:03 Tene I can *kinda* get what he's wanting to do...
01:03 Tene but, yeah, just use keyed access, IMO
01:03 treed I kinda get it, too.
01:04 treed But, conceptually, those operations just aren't appropriate.
01:04 treed You could try to wedge it in, but the end result is likely to be complex and non-intuitive.
01:04 Tene .ie
01:04 treed Especially once you start combining push/pop, shift/unshift, and keyed access.
01:05 pmichaud would it be helpful or non-helpful for me to contribute the git commands I use every day with the rakudo repo?
01:05 chromatic Helpful.
01:05 pmichaud 1.  checkout repo:    git clone git@github.com:rakudo/rakudo.git
01:05 pmichaud 2.  make modifications:    vi src/foo.bar
01:05 pmichaud 3.  commit modifications to my local repo:    git commit src/foo.bar
01:05 pmichaud 4.  push my local repo back to git master:   git push
01:05 pmichaud done.
01:06 Tene pmichaud: I don't remember you having much trouble with git.  I remember jonathan having trouble with git.  I'd be curious to hear about the problems he had.
01:06 Tene pmichaud: I guess what I'm trying to say is, be jonathan now.
01:06 Tene So.. nm.
01:06 pmichaud I can't say what problems jonathan has had because I don't know where his "model" of working with git departs from mine
01:06 pmichaud I can save I've nevr had trouble with the above -- it works almost exactly like svn in that respect
01:06 pmichaud s/save/say/
01:06 duk3leto pmichaud: helpful +!
01:07 duk3leto +1 even
01:07 pmichaud if I want to commit modifications for an entire subdirectory (e.g., src/), it's    git commit src
01:07 chromatic Yeah, that's what confuses me too.  I don't know why I made it so difficult, but that part does work very much like SVN did.
01:07 pmichaud if I want to commit all modifications I've made from the current directory and lower, it's    git commit .
01:08 pmichaud if I want to grab the changes that others have made from the master repo, it's  "git pull"
01:08 theory joined #parrot
01:08 pmichaud git seems to allow one to work with a very svn-like model if desired.
01:08 pmichaud it allows lots of other models as well, but one doesn't have to know about them to be a basic user of a git-based repo
01:09 pmichaud if I want to generate a patch that I can submit to RT/Trac/whatever (following the svn model), then I don't do a "git commit" -- I just do either "git diff" or "git format-patch"
01:09 theory joined #parrot
01:11 pmichaud (if I do a "git commit" it does make creating the patch more complicated... but by definition I've gone outside of the svn way of doing things if I do that)
01:12 chromatic Depends if you create it on a local branch....
01:12 pmichaud yes, creating a local branch does make things a bit more complex.  There the trick is to realize that you're creating the branch in your local clone and not on the master repo
01:13 pmichaud and "a bit more complex" means "only slightly more complex", not "omg this is incredibly hard" complex
01:13 chromatic Diffing between a local branch and HEAD is easy though.
01:13 pmichaud exactly.
01:13 pmichaud and merging a local branch to HEAD is easy
01:13 duk3leto pmichaud: feel free to add to https://trac.parrot.org/parrot/wiki/GitCookbook :)
01:14 pmichaud duk3leto: I don't know if the instructions I just wrote apply at all to git-svn, though.
01:14 pmichaud git-svn seems to introduce a fair bit more complexity.
01:14 duk3leto pmichaud: that page is for pure git
01:14 duk3leto pmichaud: we have a seperate page for git-svn
01:14 chromatic duk3leto, I could use something about suppressing the "convert leading whitespace to tab" behavior, however.
01:14 duk3leto pmichaud: hmm. you want that or you *don't* want that?
01:15 pmichaud want what?
01:15 purl well, want is often mispronounced as 'need' or broken by design, but at least it's clever
01:15 duk3leto pmichaud: i meant chromatic, sorry
01:15 chromatic I don't want that... seems like my past few commits have had leading spaces squashed into tabs.
01:15 Tene git should *not* be doing that.  are you fairly confident that it's not your editor?
01:16 pmichaud I've never had leading spaces squash to tabs
01:16 pmichaud at least, I'm not aware of it in rakudo
01:16 chromatic I'm very confident it's not my editor; it doesn't happen for me with SVN or SVK.
01:16 * Tene nods.
01:17 chromatic I'll see what happens with my next dcommit.
01:17 chromatic I do have this in my .gitconfig: [apply]
01:17 chromatic whitespace = strip
01:17 chromatic And this in [core]:
01:17 chromatic whitespace       = trailing-space,space-before-tab​,indent-with-non-tab,cr-at-eol
01:18 Coke oh was treed the one on list who told me to jump in a lake? good to know. =-)
01:18 Tene Coke: no, looks like he said that to leto
01:20 treed Huh?
01:20 treed Is that figurative?
01:20 * duk3leto likes lakes
01:20 cotto Ironically I'm moving near a lake and plan on frequently jumping into it.
01:20 treed Because I didn't intend to imply any sort of "FOAD" attitude.
01:20 cotto afk &
01:21 duk3leto treed: i didn't take any, no worries.
01:21 treed k
01:22 * duk3leto has thick skin, which comes in handy when you want to tell people to change their VCS ;)
01:22 treed Haha.
01:22 Tene chromatic: yes, those settings could result in whitespace changes.
01:22 Coke replied on list. I think it depends on your use case.
01:22 chromatic I removed the indent-with-non-tab option.
01:22 Coke HLL interp suggests we be more liberal.
01:22 Tene chromatic: apply.whitespace=strip is an alias for apply.whitespace=fix
01:23 duk3leto chromatic: i use the same whitespace setting, and I don't have that issue, but perhaps our editors are setup differently or git hates you more
01:23 Tene it will repair anything that your core.whitespace disallows
01:23 Tene "repair"
01:24 Whiteknight cotto: where are you moving to?
01:24 * treed replied to your reply.
01:24 treed Speaking of moving, I'll be moving to the Bay Area next week.
01:24 duk3leto treed: coolio, where?
01:25 treed As close to Palo Alto as possible.
01:25 treed Or, secondarily, as close to a caltrain station as possible.
01:25 treed duk3leto: You live in the bay area?
01:25 Tene I'll be moving to the Bay Area next... year, maybe.
01:26 treed Neat.
01:26 * treed got a job with IMVU, starting on the 14th.
01:26 treed Still gotta find a place to stay.
01:26 treed But that's difficult from Pasadena.
01:27 treed So I'm figuring to just drive up on the 13th and either crash someone's couch, or get a hotel for that first week, as I look for an apartment.
01:27 duk3leto treed: nope, i am in Portland, OR
01:28 treed Ah.
01:28 duk3leto time to bike home, see y'all later
01:28 treed Later.
01:30 * Coke wonders why he said "an PMC".
01:30 * Coke really needs to proof what his fingers type before he hits send.
01:31 chromatic Mrs. Coleda, your husband has what we call "Stupid fingers."
01:31 chromatic Give him a commit bit; he'll fit right in!
01:32 * treed totally read that in the Robot Devil's voice.
01:32 Whiteknight we're sorry. The fingers you have used to dial are too fat. You can order a special dialing wand by mashing the keypad with your palm now.
01:33 Whiteknight good simpsons references never get old
01:33 Whiteknight new simpsons references never get quoted
01:33 chromatic You are trying to commit regicide.  Your working copy is dirty.  Please fix or revert all local changes and try again.
01:38 dalek tracwiki: v1 | pmichaud++ | GitCookbook-Pm
01:38 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Gi​tCookbook-Pm?version=1&amp;action=diff
01:38 pmichaud there's my first draft of my workflow at present.
01:38 pmichaud it probably needs some improvement for non-committers
01:40 pmichaud there's probably some git command or sequence that makes creating a patch as easy as "svn diff"
01:44 * Coke wonders where to go to find cheap (and safe!) us-uk flights.
01:47 shockwave joined #parrot
01:56 Tene pmichaud: 'git diff' isn't it?
02:07 Zak joined #parrot
02:16 Tene purl: msg WhiteKnight So, where is async io in your TODO list?
02:16 purl Message for whiteknight stored.
02:22 dalek TT #989 closed by jkeenan++: t/compilers/tge/grammar.t:  FAIL under 'make test', but passes with ...
02:29 dalek TT #989 reopened by jkeenan++: t/compilers/tge/grammar.t:  FAIL under 'make test', but passes with ...
02:31 dalek partcl: r702 | coke++ | wiki/ParrotIssues.wiki:
02:31 dalek partcl: these now have partcl tickets to reference the parrot tickets.
02:31 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=702
02:31 dalek partcl: r703 | coke++ | wiki/ParrotIssues.wiki:
02:31 dalek partcl: this issue has been resolved.
02:31 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=703
02:32 dalek TT #732 closed by coke++: Coroutine contexts not getting freed
02:36 dalek TT #68 reopened by coke++: runtime/parrot/library/tcpstream.pir broken
02:39 dalek TT #68 closed by coke++: runtime/parrot/library/tcpstream.pir broken
02:41 dalek partcl: r704 | coke++ | wiki/ParrotIssues.wiki:
02:41 dalek partcl: The answer? Socket.pmc
02:41 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=704
02:42 janus joined #parrot
02:46 dalek partcl: r705 | coke++ | wiki/ParrotIssues.wiki:
02:46 dalek partcl: Deleting wiki page ParrotIssues.
02:46 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=705
02:47 hercynium joined #parrot
02:59 dalek TT #995 created by coke++: segfault in ?? (directory_destroy)
02:59 Coke ok, I'm creating these faster than you close them! =-)
03:07 Coke any io people here?
03:08 Coke (what kind of 'address' is expected when you invoke 'connect' on a Socket?
03:11 Coke ah. whatever sockaddr returns? hurm.
03:13 TiMBuS joined #parrot
03:31 shockwave joined #parrot
03:32 shockwave Hello. I have some code that looks like so:
03:32 shockwave .namespace ['Empty']
03:32 shockwave .sub __x__Empty :load :init :anon
03:32 shockwave .local pmc __x__Empty_class
03:32 shockwave __x__Empty_class = newclass ['Empty']
03:32 shockwave .end
03:32 shockwave When I compile this code, I get this error:
03:32 shockwave Friggin dos, I can't copy and paste.
03:32 shockwave Well, it says that class 'Empty' is already registered.
03:33 treed Maybe it is?
03:33 shockwave That's the only code I've got.
03:33 shockwave I haven't registered anything else.
03:33 treed Maybe it's clashing with something in Parrot?
03:34 shockwave No, that's not it. I changed the name, and the same thing.
03:34 treed Try removing the brackets?
03:35 shockwave Same
03:35 treed Dunno, then.
03:35 treed Maybe it's getting run twice somehow.
03:35 treed Use debugging says before and after th enewclass line?
03:36 Coke if you're doing :load and :init, how are you running the file?
03:36 shockwave parrot test.pir
03:36 shockwave I removed :init, and it doesn't give me the error.
03:37 shockwave But don't I need init for files that are ran like: parrot filename.pir?
03:37 dalek TT #996 created by coke++: Socket.pmc should implement readline
03:37 shockwave I got that code from the Mysql example.
03:37 treed I don't think so?
03:37 treed Usually if you have a pir file, you have a :main function
03:38 treed If you're going to be running it directly, anyway.
03:38 Coke actually, yah, I can duplicate that error.
03:38 Coke treed: oh.
03:38 Coke yah. that's probaby it; you have :init /and/ that's your implicit :main
03:38 treed Dunno if his issue is expected behavior though.
03:38 treed There's such a thing as implicit :main?
03:38 Coke yup.
03:39 Coke ":main else first sub."
03:39 Coke so that's getting invoked as :init and then :main
03:39 Coke so add an empty main or ditch the :init
03:40 Coke ... which I see you already did like 20 lines ago.
03:40 shockwave I'm planning create pir files from the HLL, each containing one class. Is :load is the way to go in order to make sure that a definition function gets ran when I do ".include 'filename'" ?
03:40 treed Yeah.
03:40 Coke no. =-)
03:40 treed That's how Cardinal does it.
03:40 Coke not necessarily.
03:40 treed Eh?
03:41 Coke :init is for things run from the command line.
03:41 treed Oh
03:41 Coke :load is for things loaded with load_bytecode.
03:41 treed Well, Cardinal does :init :load :anon
03:41 treed But that's good to know.
03:41 Coke things loaded via include... are not either. they are whatever the file that included them was.
03:42 Coke so you can have an .include that gets load'd or an .include that gets :init'd
03:42 Coke (it's the includ-er that matters)
03:42 jdv79 Coke: whatsup with your obsession with tcl?
03:42 jdv79 i've ask 3 times in #tcl about the testing protocol/format/whatever with no answer:(
03:42 Coke what an odd question.
03:42 Coke Yah. they think I'm crazy.
03:42 shockwave So what's the recommened way to make sure my class get's defined when .include'ed ?
03:43 jdv79 the community in #tcl is not as helpful as the ones in #perl
03:43 Coke shockwave: the .include doesn't matter. pretend that code appears directly in what .include'd it - how are you loading /that/ file?
03:43 treed shockwave: Declare it both :load and :init
03:43 treed To be safe.
03:43 Coke or sorry. =-)
03:44 Coke that will probably work, though, yes.
03:44 shockwave I see that the way to go with this will probably be lots of experimentation for me.
03:44 Coke jdv79: the core commiters are helpful.
03:44 shockwave Well, I guess it comes with the territory. :)
03:44 shockwave Thanks, guys.
04:08 dalek parrot: r41168 | petdance++ | trunk/include/parrot/compiler.h:
04:08 dalek parrot: improvements for the clang noreturn
04:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41168/
04:11 ttbot Parrot trunk/ r41168 i386-linux-thread-multi make error http://tt.ro.vutbr.cz/file/cmdout/87780.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
04:13 jdv79 Coke: seriously, why?
04:13 purl well, seriously, why is it luser code?
04:15 Andy joined #parrot
04:15 Coke jdv79: no good reason
04:16 * Coke finally has a smolder kick off without dying on the ssl cert
04:16 beta left #parrot
04:18 dalek parrot: r41169 | petdance++ | trunk/include/parrot/compiler.h:
04:18 dalek parrot: reverting previous patch, that I committed w/o even testing it, assuming that all would be OK with what Simon sent me.  Bad Andy.
04:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41169/
04:18 Coke bad andy is also andy-- !
04:18 Andy Waaaah
04:18 Coke good andy, bad andy. I'm the guy with the gun.
04:19 Andy I don't know why I came here tonight.
04:19 Coke for the love?
04:19 * Coke is not looking forward to rolling his own readline in PIR.
04:19 Andy oh whoops, mixed up my movie references
04:19 Coke This is my boomstick?
04:20 Coke jack and shit, and jack left town?
04:20 Andy I've never seen Army of Darkness, actually
04:20 Coke GAH!:ILH!
04:20 Andy I was thinking that that was Reservoir Dogs
04:20 Coke IM me your address I'll snail mail you a copy
04:20 Coke it's the cheese that keeps on giving.
04:21 Coke I'm fairly certain I have the low rent version of the dvd.
04:21 Coke (plus the high rent versioN)
04:28 dalek parrot: r41170 | petdance++ | trunk/include/parrot/compiler.h:
04:28 dalek parrot: handle clang compiler directives
04:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41170/
04:29 Andy it's not a matter of being unable to get it
04:29 Andy I just haven't seen it
04:32 dukeleto +1 to boomsticks
04:45 Coke Andy: get thee to a netflix!
04:45 Coke "you found me beautiful once..."
04:45 Andy gave up netflix
04:45 Andy just a matter of time.
04:47 Coke anyone have any opinions on whether Socket PMC should implement readline?
04:57 dalek partcl: r706 | coke++ | trunk/runtime/ (4 files):
04:57 dalek partcl: update issue 106
04:57 dalek partcl: just leaves the readline issue on Socket in [gets]
04:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=706
05:08 kyle_l5l joined #parrot
05:15 Zak joined #parrot
05:22 cotto I'm tempted to post a poll on parrot.org to gauge people's opinions on using git.
05:22 cotto s/using/switching Parrot to/
05:24 cotto wording is always tricky
05:24 dukeleto cotto: you know how I feel about *that* issue
05:25 PerlJam cotto: you think people's opinions have changed much in the last year or so?
05:25 cotto PerlJam, what do you mean?
05:26 cotto was there a previous poll or discussion?
05:26 PerlJam There was a discussion about a year ago or so.
05:27 Coke at the time, we were already (for some reason) changing tons of other infrastructure, too. times have changed.
05:27 PerlJam no formal poll though.  Just informal talk
05:27 cotto I may end up posting one, but it's too late to come up with adequate wording atm.
05:28 cotto I also hate to create polarization.
05:28 PerlJam cotto: yes, it's best to do when you're well-rested and can word things properly.
05:28 PerlJam cotto++ good luck too.
05:28 cotto I don't know much, but I know you have to be really careful.
05:29 Coke anyone know what the valid values of whence are for the seek opcode?
05:29 Coke (and if so, can you put that in the seek op docs?
05:31 PerlJam probably 0, 1, and 2 corresponding to "seek from beginning", "seek from current position", and "seek from end"  :)
05:31 PerlJam But that's just a complete guess from having used something called seek() in another language once or twice before.
05:32 PerlJam ;)
05:32 Coke looks like a good guess based on the C function the opcode calls. can you upate the docs? =-)
05:34 PerlJam let's see if the barrier to entry is too high on this machine ...
05:34 PerlJam Which docs are you referring to exactly?
05:36 Coke src/ops/io.ops //seek
05:44 Coke ugh. filehandle and socket don't have the same api?
05:44 Coke (print vs. send)?
05:45 jrtayloriv bacek_at_work, Why is it necessary to memset(ptr, 0, pool->object_size); in src/gc/gc_ms::gc_ms_get_free_object() ? What type of horrible things would happen if we didn't zero out the memory?
05:47 dalek parrot: r41171 | duff++ | trunk/src/ops/io.ops:
05:47 dalek parrot: Document a guess about the valid values for the whence parameter to seek()
05:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41171/
05:50 Coke ok. here's a git horror story. I just made 2 git commits to a git-svn repo. I did an interactive rebase using packy's gitsquash script. it said a rebaes was alreadyin progress, so I did a git rebase --abort
05:51 Coke Now I cannot find the 2 commits I had before the gitsquash.
05:51 Coke any suggestions?
05:51 purl any suggestions are welcome.  (including ripping it out entirely :))
05:52 Coke am I screwed?
05:52 dukeleto Coke: git reflot
05:52 dukeleto git reflog
05:52 dukeleto coke: your data is still there, no worries
05:52 Coke wierd. those are not in git log
05:52 dukeleto find the sha1 in git reflog, then "git reset sha1"
05:53 Coke I could have used you a few months ago. :|
05:53 dukeleto coke: git reflog keeps track of every commit, even if it is not attached to any branch tip. it gets periodically cleared up (by default 2 months, configurable in .gitconfig)
05:54 dukeleto Coke: i accept payment in beer and chocolate :)
05:56 Coke ok. how do I un-reset something I shouldn't have reset? =-)
05:58 dukeleto coke: say what?
05:58 purl say is println
05:58 fperrad joined #parrot
05:58 dukeleto you may need git reset --hard sha1 if you have modifications that you want to throw away
05:59 Coke I did "git reset foo". it was the wrong foo.
05:59 Coke (reading docs... ok.)
06:00 Coke git reset does not read as if it is re-applying a lone commit to HEAD.
06:03 Coke the sha1 is the 7 digit hex leading the reflog?
06:03 treed that's the beginning part of it, yeah
06:03 treed Which is usually all you need.
06:04 treed What is it that you're trying to do?
06:04 fperrad allison, have you seen my recent email about load_language & WMLScript ?
06:05 dukeleto coke: you can use any unique part of a sha1
06:06 dukeleto coke: reset restores the current position of your HEAD to a given sha1
06:06 Coke dukeleto: I'm trying to do 2 of these resets in a row. when I do the second one, the reset is for a very old revision.
06:07 Coke is there a way to git reflog to show the full sha1 so I can avoid issues? or should I not be doing multiple resets in a row without a git svn dcommit?
06:07 dukeleto coke: reset changes where the symbolic ref HEAD points. it changes your current location, but doesn't effect commit data
06:08 Coke urf? so this isn't applying those two commits, it's just changing the head pointer?
06:08 dukeleto coke: yeah
06:08 Coke (effectively discarding any work that happened after that point?)
06:08 dukeleto coke: i think you want to cherry-pick 2 sha1's onto a branch, am I correct ?
06:09 Coke yes.
06:09 dukeleto Coke: you have a branch that is missing 2 commits, yes?
06:09 dukeleto ah
06:09 dukeleto coke: find the 2 sha1's then:
06:09 Coke (it's the local ... trunk, I guess)
06:09 Coke dukeleto: got 'em.
06:09 dukeleto git cherry-pick sha1
06:09 dukeleto git cherry-pick sha2
06:09 NotFound joined #parrot
06:10 Coke cherry pick is complaining that there is a conflict in a file that that commit didn't touch.
06:11 dukeleto coke: nopaste the error and the output of "git status -a"
06:11 Coke (this is the same one that when I tried to do the reset, seemed to pick a completely different commit.)
06:11 dukeleto do you have local modifications ?
06:11 dukeleto i.e. the output of "git status -a"
06:11 nopaste "coke" at 72.228.52.192 pasted "# On branch master # Changes t" (24 lines) at http://nopaste.snit.ch/17892
06:12 Coke dukeleto: no.
06:12 dalek TT #997 created by gerd++: [BUG] Segmentation fault by building TGE on ppc64
06:12 Coke (not before I try the cherry pick. :|
06:12 dukeleto coke: the commit probably changes config/PARROT_VERSION, yes?
06:13 Coke no!
06:13 dukeleto coke: what does "git diff head" say ?
06:13 Coke fatal: ambiguous argument 'head': unknown revision or path not in the working tree.Use '--' to separate paths from revisions
06:14 Coke after I run the cherry pick, config/PARROT_VERSION is listed as both U and M. but that commit should have only changed runtime/builtin/puts.pir
06:15 dukeleto coke: what does git --version say?
06:15 dukeleto coke: i guess older git's prefer HEAD
06:15 Coke 1.5.6.5
06:15 dukeleto coke: jurassic :)
06:16 Coke git diff head shows the change to that file that it's complaining about.
06:16 dukeleto coke: is the change valid? a conflict ?
06:16 Coke That commit message has nothing to do with that file.
06:16 dukeleto you can do "git checkout config/PARROT_VERSION" to basically do the same as "svn revert file"
06:16 Coke (git show sha1 for that message does agree with all the other brokenness,though.)
06:17 Coke git checkout config/PARROT_VERSION; git status - shows it as unmerged.
06:17 Coke (git status -a shows it as modified)
06:18 Coke This is about the time when I say "Hg sounds good" =-)
06:18 Coke At least the other cherry pick might work, testing.
06:19 jrtayloriv Big time sleepy time. Nighty night.
06:19 Coke I think the commit for the second one is fubar in reflog.
06:19 Coke by my own hand or not, I cannot say.
06:20 dukeleto coke: interesting
06:20 dukeleto coke: git add file to say that you are done "merging it"
06:21 dukeleto coke: git add config/PARROT_VERSION after you to "git checkout config/PARROT_VERSION", then commit the result
06:22 Coke I just did a git reset -hard
06:22 dalek partcl: r707 | coke++ | trunk/runtime/builtin/ (2 files):
06:22 dalek partcl: initial versions of [seek] and [tell]
06:22 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=707
06:22 dalek partcl: r708 | coke++ | trunk/runtime/builtin/puts.pir:
06:22 dalek partcl: Fix bug introduced with new [socket] impl.
06:22 dalek partcl: (Sockets can't print, and FileHandles cannot send)
06:22 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=708
06:23 Coke then I cherry picked the one that wasn't fubar, and then I manually reconstructed the other one (which thankfully was small)
06:23 dukeleto coke: so you are in better shape ?
06:23 dukeleto in your case, you probably wanted the --hard from the beginning. that would have been less headache, methinks
06:23 Coke Yes. I do wish that interactive rebase hadn't eaten my commits in the first place.
06:23 chromatic joined #parrot
06:24 Coke that's the sort of error that I don't think could have happened with svn. =-)
06:25 dukeleto coke: interactive rebase is a delicious self-animated chainsaw :)
06:27 Coke iwbni packy's script stopped you /before/ you shot yourself inthe foot.
06:27 Coke (gitsquash, on the wiki)
06:28 dukeleto Coke: his script is a little scary
06:28 dukeleto coke: i use the bash function grh ()
06:28 dukeleto {
06:28 dukeleto git rebase -i head~$1
06:28 dukeleto }
06:29 dukeleto so i manually inspect the last few commits and see how many i want to rebase
06:29 dukeleto coke: more safer :)
06:29 Coke the problem was that there was already an interactive in progress.
06:29 dukeleto so rebasing the last 5 commits is "grh 5"
06:29 dukeleto coke: rebase has screwed me too, but reflog always saves me
06:29 Coke mm. glad I know about it. =-)
06:30 Coke I bet this [seek] and [tell] net me zero spec tests...
06:41 dalek tracwiki: v10 | dukeleto++ | GitCookbook
06:41 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=10&amp;action=diff
06:42 dukeleto coke: i updated the git cookbook, please review :)
06:46 bacek_at_work dukeleto: consider removing "git commit -a". It's way too dangerous.
06:47 chromatic It's just about as dangerous as svn ci.
06:47 bacek_at_work (and I don't think that we should encourage usage of it)
06:47 dukeleto bacek_at_work: i guess i live dangerously :)
06:47 bacek_at_work chromatic: svn is dangerous by it self :)
06:47 dukeleto bacek_at_work: i constantly look at "git status -a"
06:48 dukeleto bacek_at_work: as well as having notification in your PS1 about local changes/etc.
06:48 dukeleto bacek_at_work: i understand that -a could be dangerous for newcomers, but i use it instead of having to "git add" each file.
06:48 dukeleto bacek_at_work: i make many incremental commits, so -a is not dangerous for me
06:49 Coke dukeleto: IWBNI if it also mentioned cherry-pick, but otherwise, nice.
06:49 Coke bacek_at_work: for folks coming from svn, git commit -a is just fine.
06:49 dukeleto coke: ah, yes. forgot
06:50 Coke git add/git commit is the next level of complexity after that.
06:50 Coke dukeleto++
06:50 * Coke needs to get to bed. :|
06:55 dukeleto git is serious about data loss :)
06:56 dalek tracwiki: v11 | dukeleto++ | GitCookbook
06:56 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=11&amp;action=diff
06:58 Khisanth joined #parrot
07:02 mberends joined #parrot
07:03 Zak joined #parrot
07:06 dalek tracwiki: v12 | dukeleto++ | GitCookbook
07:06 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=12&amp;action=diff
07:10 dalek tracwiki: v13 | dukeleto++ | GitCookbook
07:10 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=13&amp;action=diff
07:11 chromatic Does that mean Coke is a Git convert now?
07:13 dukeleto chromatic: looks promising :)
07:14 chromatic Next up, whiteknight and NotFound.
07:26 MoC joined #parrot
07:33 mikehh I find one of my major problems with git is figgerin' out where I am at - at least with svn we have sequential revision numbers
07:33 iblechbot joined #parrot
07:34 moritz looking at 'git log' often helps me with that
07:34 mikehh yeah - but I don't have to look with svn :-}
07:35 moritz aye
07:35 moritz they had to let svn be better at one thing, at least ;-)
07:37 moritz but you know you can get sequence numbers out of git
07:37 moritz with git-describe
07:37 moritz which gives you last tag + commits since last tag + short SHA1
07:39 dukeleto mikehh: get a recent (1.6.x) version of git and then do: git log --pretty=format:'%C(yellow)%h%Creset %s %Cred%an%Creset %Cblue%d%Creset %Cgreen%cr%Creset %cd' --graph --all
07:39 dukeleto mikehh: i have that aliased to "git plog"
07:39 mikehh well I've got git in  my git repository :-}
07:40 dukeleto mikehh: color coded ascii art revision history, with committer, date and branch names
07:40 mikehh I was only sayin' that it is easy to follow where you are with svn
07:41 mikehh plus perl, rakudo, cardinal, lua and others
07:42 mikehh mind you I've got llvm, clang, parrot, partcl, and a few others in svn
07:43 mikehh and some ubuntu stuff in bzr
07:44 mikehh which is also a good option to consider
07:44 purl okay, mikehh.
07:46 treed purl: forget which
07:46 purl treed: I forgot which
07:46 mikehh dukeleto: just updated cpanp and your BigRat module
07:47 dukeleto mikehh: whoa dude, you are on the bleeding edge :)
07:47 mikehh also DateTime::TimeZone
07:53 dalek tracwiki: v14 | dukeleto++ | GitCookbook
07:53 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=14&amp;action=diff
07:54 * moritz sees that dukeleto++'s parrot on github has all the svn branches - nice
07:54 dukeleto moritz: indeed :) i have a handy little script that pulls them all and pushes them to github
07:56 dukeleto moritz: http://github.com/leto/Util/b​lob/master/bin/update_parrot <-- could use some generalization and love, but works for me :)
07:56 moritz nice :-)
08:07 dalek tracwiki: v15 | dukeleto++ | GitCookbook
08:07 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=15&amp;action=diff
08:18 HG` joined #parrot
08:27 bacek joined #parrot
08:37 masak joined #parrot
08:40 TiMBuS do threads work in rakudo yet?
08:42 TiMBuS i made my perl 6 irc bot but all it does is !8ball which is.. kinda lame. wanna add support for twitter but without threads it's going to be an issue.
08:43 TiMBuS and i recently read something about threads in parrot being sorta crash prone in hll's? or something?
08:44 moritz TiMBuS: that's right. There's a ticket for that, which contains patches
08:44 moritz which need testing and review
08:45 TiMBuS i see
08:52 kyle_l5l I'm still slowly chugging away at threads+hlls.
08:54 moritz kyle_l5l: I see that you commented on that tickets that parts of one patch should not be applied... could you please upload a single patch that replace the three existing patches? it's getting a bit hard to understand what's needed and what not, IMHO
08:55 dukeleto i totally borked my svn by attempting to upgrade it on os x, now I haven't had a working svn in 2 days: http://gist.github.com/183599
08:55 dukeleto installing from source or ports doesn't seem to fix it
08:55 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41171 - Ubuntu 9.04 i386 (g++)
08:55 kyle_l5l moritz, sure
08:56 dukeleto type "make test" in the subversion source and you will feel a hollow wind pas you, as you realize that your version control system HAS NO TESTS
08:59 bacek dukeleto: erm... Really? They don't have single test??? OMGBBQ!
09:00 bacek o hai, btw
09:00 athomason joined #parrot
09:01 bacek jrtayloriv: ping.
09:01 mberends joined #parrot
09:09 mikehh rakudo (62879bb) builds on parrot r41171 - make test / make spectest (up to 28212) PASS - Ubuntu 9.04 i386 (g++)
09:09 mikehh rakudo - t/spec/S03-operators/arith.rakudo - TODO passed:   131
09:09 mikehh rakudo - t/spec/S06-multi/proto.rakudo, t/spec/S12-attributes/class.rakudo and t/spec/S14-roles/basic.rakudo - Non-zero wait status: 11 (Segfault after passing tests)
09:11 fperrad_ joined #parrot
09:19 einstein joined #parrot
09:25 mikehh partcl r708 builds on parrot r41171 - make test random failures with segfault - Ubuntu 9.04 i386 (g++)
09:28 mikehh partcl - if I make realclean, svn update -r699, make test TEST_JOBS=5 - PASS, make realclean, svn update -r 700, make test TEST_JOBS=5 - random failures (segfaults)
09:30 mikehh partcl - the file updated above is src/tclsh.pir
09:49 mikehh decnum_dynpmcs r181 builds on parrot r41171 - make test PASS - Ubuntu 9.04 i386 (g++)
09:50 mikehh cardinal builds on parrot r41171 - rake teat:all - same 3 failures - ubuntu 9.04 i386 (g++)
09:51 mikehh ok - I am going to reboot to amd64 now - bbl
10:07 HG` joined #parrot
10:17 mikehh joined #parrot
10:40 dalek parrot: r41172 | bacek++ | trunk/src/jit/i386 (2 files):
10:41 dalek parrot: [cage] Make headerize happy about JIT-generated functions
10:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41172/
10:50 bacek joined #parrot
10:54 iblechbot joined #parrot
11:14 dalek TT #973 closed by bacek++: Review content of src/gc/alloc_register.c and src/call/context.c and merge ...
11:57 bkuhn joined #parrot
12:07 whoppix joined #parrot
12:08 whiteknight joined #parrot
12:14 ruoso joined #parrot
12:14 whiteknight good morning #parrot
12:15 whiteknight Tene: ping
12:19 whiteknight purl msg Tene work on io_cleanups stalled. Infinoid was working on pipes but he is busy IRL. Pipes would be nice but we definitely need to cleanup the IO system before we start adding to it. I could put a branch together for that purpose soonish and see how it goes. Interested in helping?
12:19 purl Message for tene stored.
12:20 JimmyZ joined #parrot
12:40 Coke dukeleto: svn on OS X, there's a .dmg installer for that.
12:40 Infinoid (cleaning up IO)++
12:40 Coke whiteknight: so I find myself having to write code that checks which IO object type I'm using to determine which methods to invoke on it.
12:40 Coke Is this intentional?
12:41 whiteknight Coke: Shouldn't be
12:41 Coke Socket vs. FileHandle , 'send' vs 'print', e.g.
12:41 whiteknight my "vision" for that whole system is much more unified then it is currently
12:42 whiteknight Ideally I would like there to be no fundamental difference between IO PMC types until the very deepest layer where we actually have to interact with the OS
12:42 whiteknight so PIR code would treat all IO Handle objects identically
12:42 whiteknight and we can properly subclass them
12:43 Coke ok. I'll close my eyes and think of england in the meanwhile.
12:43 whiteknight ..oh yes that response makes complete sense to me
12:43 Coke whiteknight: any comments on my readline for socket RFC?
12:43 whiteknight #?
12:43 purl # is moderated
12:43 Coke "recent"?
12:43 Coke checking.
12:44 Coke TT #996
12:45 Coke tcl has [gets] which basically does a readline on an arbitrary IO object. so I can use the readline opcode (which is apparently a shim over the readline method - why bother?) and Socket cannot readline.
12:46 Austin joined #parrot
12:46 whiteknight the probem was that the IO system was written before the Socket PMC was really added. Socket was sort of tacked on as an after thought and is only a thin wrapper around the berkley API
12:49 Coke waaaafar thin.
12:55 Coke partcl parrot problems is http://code.google.com/p/partcl/issues/list​?can=2&amp;q=status=Parrot&amp;sort=status&​amp;colspec=ID%20status%20Type%20Difficulty​%20Priority%20Milestone%20Owner%20Summary
13:06 Coke shorten that?
13:06 purl That URL is at http://xrl.us/bfjj37 [code.google.com]
13:07 Coke no, partcl parrot problems is http://xrl.us/bfjj37 [code.google.com]
13:07 purl okay, Coke.
13:07 Coke (whee, lazybot)
13:12 dalek rakudo: 872cd0d | pmichaud++ | docs/spectest-progress.csv:
13:12 dalek rakudo: Revise spectest-progress.csv results since August 2009 release to
13:12 dalek rakudo: use the updated and more-accurate counting of the spectest suite.
13:12 dalek rakudo: (moritz++)
13:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​72cd0dfa1a565de83fc4c59d76007bde74aa21c
13:12 dalek rakudo: 5960161 | pmichaud++ | docs/spectest-progress.csv:
13:12 dalek rakudo: spectest-progress.csv update: 436 files, 14268 (69.3% of 20599) pass, 0 fail
13:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​9601615368406078308c5c0423ce4bf6b8252a4
13:28 jrtayloriv whiteknight, Do you know why is it necessary to memset(ptr, 0, pool->object_size); in src/gc/gc_ms::gc_ms_get_free_object()? What type of horrible things would happen if we didn't zero out the memory? Is it just good practice to do this?
13:29 jrtayloriv A lot of the GC benchmarks spend a lot of time memset()ing things to 0 in various places, and I can figure out why this needs to be done.
13:30 jrtayloriv s/I can/I can't/ ...
13:40 particle jrtayloriv: can you make the memset optional, perhaps done only by a -D flag?
13:40 NotFound joined #parrot
13:40 whiteknight jrtayloriv: throughout the GC it checks if pointers are null and marks them if not
13:41 particle that will give us something to play with
13:41 whiteknight so we can't have a pointer with uninitialized garbage
13:42 particle whiteknight: so it's not like our setting ints to 0 or strings to null on init?
13:42 particle it's actually a 'feature' of the gc?
13:43 jrtayloriv whiteknight, OK, thanks.
13:46 whiteknight jrtayloriv: now, if we could do it in a fast and consistent way without memset, that would be fine too
13:48 NotFound As Coke said yesterday, I prefer some slowness than random segfaults.
13:49 whiteknight it might be a worthwhile exercise to take a look at what is getting memset and when, and then comparing that to the initilization routines of the various object types
13:49 whiteknight so if pmc_new is already initializing all the necessary fields, we don't also need to memset inside the GC
13:49 NotFound Don't forget pmc_new_noinit
13:50 whiteknight they both probably call something like Parrot_gc_new_pmc_header
13:51 PacoLinux joined #parrot
13:52 Austin NotFound: Sadly, we have both.
13:54 NotFound Austin: but the balance between the two can be easily made a lot worse.
13:55 HG` joined #parrot
13:55 Austin Cheer up, they told me. Things could always be worse.
13:55 Austin So I cheered up. And sure enough, things got worse.
13:55 whiteknight Austin: talking about performance problems?
13:55 Austin No. Performance problems plus random segfaults.
13:56 Austin (Except they're not random. They always come at the end.)
13:56 whiteknight we're working on it :)
13:57 Austin I  don't let it get to me. I'm feeding bad data to PCT, so it segfaults.
13:57 Austin It's faster than printing an error message, I guess.
13:57 NotFound Austin: they're not random now, after adding some memset and several other things.
13:58 Austin I know they're not random. They always come at the end.
13:58 particle joined #parrot
14:00 NotFound In Eval.destroy, in all cases I backtraced.
14:02 pmichaud for me, I generally get segfaults at the end whenever I have a :load/:init sub that throws an exception.
14:02 pmichaud (there are many ways in which this can happen.)
14:04 skv joined #parrot
14:04 moritz planetsvg.com has a nice feature - a feed from a google search for svg blogs
14:05 moritz I wonder how hard or easy it would be to make such a thing for parrot or Perl 6
14:05 moritz afk
14:05 Andy joined #parrot
14:06 NotFound pmichaud: that makes sense. If eval gets invalid packfile structures from imcc, it can easily fail while trying to destroy them.
14:07 Austin Whiteknight: fwiw, I upgraded to 41166 with no problems y-day.
14:07 whiteknight that's good!
14:09 pmichaud See TT #833 for more about imcc and exceptions
14:13 theory joined #parrot
14:13 whiteknight yeah, #833 is the bane of my existance
14:15 whiteknight I swear by the power of greyskull that I will fix it one day
14:22 NotFound I think I have an attempt of fix somewhere, I'll try to find it later today.
14:23 whiteknight A fix wouldn't be hard to make. the problem I found was getting people to agree on which fix to make
14:24 whiteknight because all of them would imply certain significant architectural changes to get right
14:25 NotFound Well, letting it break the VM is hardly an architecturaly desired state of art.
14:25 whiteknight agreed
14:27 Austin Do the one that involves taking things out.
14:27 Austin If they both do, then do the one that involves taking the most things out.
14:30 whiteknight Austin: any solution is likely going to require adding. And lots of adding
14:31 NotFound whiteknight: not so much. Just catch exceptions, so some cleanup, and rethrowing. The "some cleanup" part may be tricky, though.
14:32 NotFound s/so/do
14:32 whiteknight NotFound: right, you need to identify which runloop you are currently in, which runloop the handler was in, and perform the rethrow if the two aren't the same
14:33 whiteknight and you'll also need to cleanup exception handlers in the scheduler that were created in an inner runloop after that runloop has exited
14:33 whiteknight so each ExceptionHandler PMC needs a RunloopID field added, plus logic to check the RunloopID and logic in the scheduler to not mark handlers from dead runloops
14:33 NotFound whiteknight: a C exception handler gets rid of that by doing a longjmp
14:34 whiteknight right, so we have to do more differentiating between C and PIR exception handlers
14:34 payload joined #parrot
14:35 whiteknight It's all very doable, but non-trivial and worth having a good plan in place beforehand
14:36 NotFound whiteknight: we don't need to solve the general case just to catch failures inside load_bytecode or eval.
14:37 Austin Whiteknight: off the current topic, I just read your blog about startup+GC. I had been thinking about that for a while (the startup issue, not specifically GC) and I think the right answer is to use two interps. The first is the "loader" and just has enough stuff to set up the second.
14:37 whiteknight Austin, I've thought about that too. Problem is that interpreter creation is very expensive
14:38 Austin Maybe not.
14:38 whiteknight creating two at startup is prohibitive
14:38 Austin If the bootstrap interpreter is only doing one thing, it can be "static".
14:38 NotFound Interpreter creation and destruction are labyrinths
14:38 whiteknight that too
14:39 whiteknight there is a lot of refactoring that needs to happen in the startup code, and a lot of opportunities to streamline and optimize
14:40 Austin Bud Light presents: Real Men of Genius. Today we salute you, mister Gangsta rapper posse member.
14:40 whiteknight nice
14:41 cotto joined #parrot
14:41 cotto hi
14:43 Austin If only args were being handled right, this would be good code. :(
14:43 whiteknight good code? are you smoking something?
14:51 Psyche^ joined #parrot
14:51 whiteknight we need to go through all this code with a goddamn hatchet
14:51 whiteknight but it isn't a sufficient pain point yet that it's on the priority list
15:07 dalek parrot: r41173 | NotFound++ | trunk (2 files):
15:07 dalek parrot: [cage] simplify FPA.get_repr and improve his test
15:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41173/
15:08 cotto NotFound, why not just rip out get_repr?  It's deprecated.
15:08 davidfetter joined #parrot
15:09 NotFound I must read DEPRECATED more frequently X-)
15:09 whiteknight I haven't even looked at it since the rush after 1.4.0
15:11 NotFound I don't see any mention of get_repr in DEPRECATED.pod
15:12 particle it's mentioned in the pdd
15:12 particle i don't know if it's in deprecated.pod
15:13 particle or whether there's a ticket
15:15 AndyA joined #parrot
15:15 particle Coke: look who's here
15:17 NotFound "candidate for deprecation"?
15:28 JimmyZ joined #parrot
15:28 cotto NotFound, my mistake.  For some reason I thought it was on the way out.
15:29 cotto I'm glad I found that out before deleting all the get_repr VTABLEs.
15:29 cotto It's kinda like having Stupid Fingers except it's in my head. ;)
15:32 NotFound cotto: no problem... Do you have any Vista system with SMB2 open? }:)
15:33 cotto nope
15:33 mikehh_ joined #parrot
15:34 cotto I don't start work until Monday and I can't imagine any reason to have a Vista box at home. ;)
15:40 NotFound cotto: I have one that came with the box, I rebooted with Vista yesterday just to see the BSOD X-)
15:42 cotto A BSOD?  In Vista?  I'm shocked.
15:45 cotto You should send an electronic message of some sort to the manufacturer of that product.
15:45 SMSD joined #parrot
15:46 NotFound cotto: Who is that, BuenaVista?
15:47 SMSD Hi I want to know the differences b/w register and stack based VM's....parrot VM is register based so what are the advantages...please help
15:49 jrtayloriv SMSD, see http://www.sidhe.org/~dan/​blog/archives/000189.html and www.usenix.org/events/vee05​/full_papers/p153-yunhe.pdf
15:51 * cotto is going to work orientation.
15:51 cotto afk &
15:53 SMSD jrtayloriv: thanks but i had seen them sir....are there any other resources regarding this matter?
15:53 particle also http://docs.parrot.org/parrot/la​test/html/docs/overview.pod.html
15:53 particle smsd: google is your friend
15:54 particle e.g: http://docs.parrot.org/parrot/la​test/html/docs/overview.pod.html
15:54 particle er
15:54 particle http://www.usenix.org/events/ve​e05/full_papers/p153-yunhe.pdf
15:54 SMSD particle: yes thanks
15:54 particle oh, right, jrtayloriv++ sent that already
15:55 particle dis is also a register-based vm (memory transfer vm, they call it)
15:55 purl okay, particle.
15:55 SMSD jrtayloriv: i am not able to access the sidhe.org site
15:57 jrtayloriv dis is also "You dissin' me? You're messing with the wrong bot."
15:57 purl okay, jrtayloriv.
15:58 mikehh joined #parrot
15:59 SMSD thanks for the help guys
16:00 SMSD left #parrot
16:00 Tene whiteknight: *obviously* the solution to the startup problem is to make the GC swappable at runtime.
16:00 Tene whiteknight: I'd love to help with IO stuff.
16:02 whiteknight Tene: awesome. What we most need is to unify all the internal paths to support FileHandles and Sockets
16:02 Tene Coke: way way back on August 4, you claimed that when using git-svn, you saw something squashing all local commits into a single commit to the svn repo.
16:02 Tene whiteknight: Explain more?
16:02 whiteknight I was hoping we would have proper Pipes that we could include, but we will just need to keep them in mind for later
16:03 whiteknight Tene: Well, when we want to act on a socket, we call one function. When we want to act on a file handle we call other functions
16:03 whiteknight we need to unify all that so we call one set of functions for all IO handle types
16:03 Tene Ah.
16:04 davidfetter joined #parrot
16:04 Tene Yes, that would be nice.
16:04 Tene Socket is... less good than it could be. :)
16:05 whiteknight This means that all IO handle types will have a standard set of methods (write, writeline, read, readline, open, close, etc)
16:05 payload joined #parrot
16:05 whiteknight we can unify things all the way down until we finally talk to the OS. Then we do a quick switch statement and pass the handle to the proper function
16:05 whiteknight this also means that we get everything for everybody: buffering for sockets and pipes, for example
16:07 Tene :) yay
16:07 Tene Can you write up a list of what the API is?
16:09 bkuhn joined #parrot
16:24 * Coke returns from offsiting.
16:27 Coke (interpreter creation) - please check out tcl's [interp] for all the things I need an interpreter-like thing to do.
16:27 Coke msg AndyA Cheers!
16:27 purl Message for andya stored.
16:28 Coke tene (squashing all local commits) yup. It was probably 'stupid fingers', but if you have a story that makes it not my fault, all ears.
16:36 hercynium joined #parrot
16:57 whiteknight joined #parrot
17:08 Tene Coke: No, I have no idea how to get that behavior without asking for it; sorry.
17:09 Coke ok. no worries. no longer a problem to be solved.
17:09 Tene kk
17:09 Coke ... this temporary blindness is of some concern, however.
17:09 Coke (just those dilating eyedrops. woof.)
17:12 joeri joined #parrot
17:46 bacek joined #parrot
17:47 Tene whiteknight: Austin Hastings' proposal, which you indirectly replied to, did specify a proposal for adopting an already-used model of push/pop from a fixed array.
17:47 Tene erm... Andy Dougherty.
17:50 whiteknight I don't see why we would add push/pop to the fixed arrays. If we want those things we should use the resizable ones
17:50 whiteknight I would be much more in favor of deprecating Fixed*Array types
18:02 darbelo joined #parrot
18:08 whiteknight maybe I'm just missing something
18:14 Tene whiteknight: The only issue is consistency with the interface... do something at least vaguely reasonable on these things that claim to be arrays.
18:14 chromatic joined #parrot
18:15 whiteknight To be fair, an "array" by definition only claims to have keyed indexing
18:15 whiteknight something that is more then an array should also implement an additional interface
18:15 japhb whiteknight, re: your Refactoring Parrot Startup post ... how can you delay executing :immediate subs until after the entire main program is compiled?  I thought the whole point of :immediate is that it forces a switch to execution mode right then and there (as soon as the :immediate sub has been compiled) before continuing compilation ....
18:15 whiteknight japhb: that's one of the "problems" I brush aside :(
18:16 japhb That's a big problem.  :-)
18:16 Tene japhb: just drop support for :immediate subs!
18:16 whiteknight not necessarily.
18:16 whiteknight Instead of invoking IMCC once, we can iterate over IMCC. It returns the "next" sub as soon as it's time to return it
18:16 japhb What about running the compile/execute as continuations or as a bytecode generator that produces chunks at a time ... ?
18:17 whiteknight so IMCC immediately returns immediate subs, which execute, and then IMCC gets called again to get the next thing
18:17 japhb yup, that's one of the things I was thinking of.
18:17 whiteknight it's a problem, but not impossible to get past
18:17 whiteknight The bigger issue is that :immediate subs are used to create PMC constants in the packfile
18:17 japhb OK, as long as you're open to doing chunking at least, my objection is gone.
18:18 japhb ><
18:18 whiteknight so then we need to handle that in some way
18:18 japhb I forgot all about the packfile mess, sigh.
18:18 whiteknight that's the official name for it
18:26 payload1 joined #parrot
18:28 hercynium joined #parrot
18:34 Coke whiteknight: please show me in the docs where "does array" means anything at all. =-)
18:34 whiteknight Coke: nowhere.
18:34 purl nowhere is the method for calculating significant wave height using an FFT on pressure data. or Dodge City, KS
18:35 whiteknight that doesn't mean it shouldn't mean something
18:35 mokurai joined #parrot
18:35 Coke right. As long as it means what I want, that's fine. =-)
18:36 whiteknight A lot of languages do differentiate between a simple "array" and a "stack" or "queue"
18:39 particle does is in the pmc pdd iirc
18:42 whiteknight this is all probably an allison question.
18:44 dalek close: r101 | Austin++ | trunk/library/close/Compiler/Config.pm:
18:44 dalek close: Commented out NOTE and DUMP calls in Config.pm
18:44 dalek close: review: http://code.google.com/p/close/source/detail?r=101
18:44 dalek close: r102 | Austin++ | trunk/library/close/Compiler/ (2 files):
18:44 dalek close: Added missing .pm files
18:44 dalek close: review: http://code.google.com/p/close/source/detail?r=102
18:47 chromatic I'm not sure why there's such a heated discussion; it all comes down to complexity for me.
18:48 chromatic We *could* let you push up to a limit, but then we run into weird edge case semantics that are difficult to understand and likely not easy to program.
18:48 mberends joined #parrot
18:48 chromatic If you ask for a fixed array, don't treat it like a stack or a queue or a vector.
18:48 Coke chromatic: Splitting the aggregate types is fine.
18:49 Coke chromatic: but also: I'm specifically talking about the case where someone /hands/ you an aggregate.
18:49 Coke not one where you're picking the right PMC for the job.
18:50 Coke particle: does is listed, but, as i recall, just as a list of potential types which I updated at one point to match the plain text listings from code.
18:50 chromatic That's a case of documentation, I believe.
18:53 particle whiteknight: implement pmroles, and the world is your oyster
18:54 whiteknight pmroles?
19:05 dalek close: r103 | Austin++ | trunk/src/parser/expression (2 files):
19:05 dalek close: Fixed asm-expr / postfix-call issue
19:05 dalek close: review: http://code.google.com/p/close/source/detail?r=103
19:19 NotFound When asking about adding more functionality to some pmc "just in case" please remember that in addition to the code to add it, we must also write tests.
19:20 Coke chromatic: nothing enforces those settings, it's basically just annotation. I can make my "Frobulator" say it does array when it's really just Undef.
19:20 NotFound And even some nice guy may be tempted to write documentation X-)
19:20 Coke (granted, if you like, we go boom, and it's your fault for giving me the bad pmc, but does always struck me as not entirely useful)
19:21 chromatic I can document that I return you a Sub but return you an Undef and that's my fault too.  We can't prevent documentation from lying.
19:22 NotFound sub lier is also Undef ?
19:22 NotFound sub but Undef ?
19:37 hercynium joined #parrot
19:39 quek joined #parrot
19:39 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41173 - Ubuntu 9.04 amd64 (g++)
19:41 Coke chromatic: so at this point I'll settle for making the documentation consistent.
19:42 whiteknight no settling! We have an impressive development team here. Let's work out what we want and make that happen
19:42 chromatic Yep, I can work with the JIT plan.
19:43 Coke chromatic: "can't we all just get along?"
19:43 Coke (oh wait, we can.)
19:44 particle it seems a little f'd up to me that the one platform where jit 'works' now will be the one where it doesn't tomorrow, but whatever.
19:44 whiteknight where won't it work?
19:44 particle windows + llvm = no joy
19:45 chromatic Really?
19:45 Coke particle: how well is jit working for you now? =-)
19:45 whiteknight so we have a JIT system that supports multiple backends
19:45 particle the msvc port is experimental
19:46 NotFound And the current parrot jit is mature?
19:46 whiteknight let's not compare apples to bullshit
19:46 particle gee, thanks for that.
19:47 chromatic particle, does the JIT give measurable performance improvements on Windows?
19:48 particle i don't know, i haven't measured
19:48 chromatic Okay.
19:48 particle is there a pre-existing jit that works on all our target platforms?
19:48 chromatic I don't know that.
19:48 whiteknight I have to check
19:48 particle a large percentange of dynamic language users use windows
19:48 whiteknight libJIT might. Lightning might
19:49 chromatic LLVM is *probably* the best choice for portability, especially if ARM is important (and ARM is *very* important).
19:49 whiteknight nanoJIT does, but it isn't in a form where we can use it
19:49 particle no matter how much you ignore it or deride it
19:49 particle make the jit interface pluggable
19:50 particle then we can use best-of-breed jits on various platforms
19:50 whiteknight that's my entire plan, in a nutshell
19:50 particle and you can start with llvm first
19:50 whiteknight pluggable = better
19:50 Coke particle: according to http://llvm.org/docs/GettingStarted.html, there is llvm for windows.
19:50 particle pluggability at parrot core is the only way we survive long term
19:51 particle coke: it's good with cygwin, experimental with msvc iirc
19:51 whiteknight I don't think it's the only way, but it is a compelling feature
19:51 whiteknight especally if our plugin systems are better then GCC's for instance
19:51 Coke yes. much like all of parrot.
19:51 NotFound We can write a jit plugin that does nothing, as a start
19:51 whiteknight NotFound: better yet, we can use the one we have :)
19:52 NotFound whiteknight: if you are masochistic enough... ;)
19:53 whiteknight my theory is that we are already parsing our OPS files, and generating code in a variety of forms to execute them
19:53 particle whiteknight: given our level of funding and committer time, we need to make it *very easy* for contributors to add value to parrot
19:53 whiteknight so all we need to do is output additional forms for JIT engines to use
19:53 particle oh, and if the llvm-on-windows answer is to introduce llvm folks to ms folks, i'll gladly help
19:54 whiteknight it's a parser problem more then anything else. I don't suspect there will be a hell of a lot of C code for us to write
19:54 Tene particle: introduce them at high speed?
19:54 whiteknight where "hell of a lot of C code" can mean many different things
19:56 NotFound A funny excercise can be: take a .pbc file and generate optimized C code that can run with an embedded parrot.
19:56 whiteknight of course, realizing that there is more parsing and code generating to be doing, we need to seriously consider whether we want to do that in Perl5 or PCT
19:57 whiteknight and if PCT, then there's a bootstrapping step
19:57 darbelo Also: PCT is better, Perl5 is faster.
19:57 whiteknight Perl5 is faster *now*
19:58 whiteknight we have a world-class parsing engine in our repo, it's probably good to use that
19:58 NotFound And maybe someday we can even get rid of lexx/yacc
19:59 whiteknight NotFound: entirely possible. If Parrot only runs PBC natively and has a separate compilation step (think java and javac)
19:59 Tene as well, remember that this isn't runtime speed, it's compilation time.
19:59 TimToady phone
19:59 NotFound whiteknight: if parrot run pbc, we can have a pbc pir compiler
20:00 whiteknight exactly
20:00 einstein the svn certificate gives the following message "The certificate hostname does not match."
20:00 whiteknight now imagine how much simpler (and FASTER!) Parrot startup will be without IMCC in there
20:00 Tene einstein: where are you getting that specifically?
20:00 NotFound einstein: With which hostname?
20:01 einstein https://svn.parrot.org:443
20:01 Tene einstein: it works for me...
20:01 NotFound Also for me
20:01 darbelo whiteknight: pirc needs some more love before we can kill IMCC.
20:02 NotFound darbelo: pirc is also lexx/yacc based
20:02 purl okay, NotFound.
20:02 whiteknight darbelo: what we were talking about is not using IMCC or PIRC at all
20:02 einstein it did work in the past but now it comes with this error
20:02 whiteknight have a PCT-based compiler only
20:03 Tene and generate pbc straight from POST
20:03 NotFound Anyway, imcc startup surely can be put out of the way when just loading and running a pbc.
20:03 whiteknight Tene: YES! Exactly
20:04 darbelo Oh, the one bacek had on github? That sounds cool.
20:04 NotFound Will not be a good idea to use different names?
20:04 whiteknight I was thinking about having pluggable front-ends. We set up a standard API and people can plug in whatever frontend they want
20:05 whiteknight We hand in either a filename or a string of code, and the frontend returns PBC
20:05 Tene I'm wondering if we should have a word for non-pluggable instead of a term for pluggable, as Parrot is migrating towards an everything-pluggable system.
20:05 whiteknight and if frontends are pluggable, we can swap out IMCC/PIRC with something else entirely. Parrot could be natively running a much higher-level language if it wanted to
20:05 NotFound We need a PluggablePMCArray X-)
20:06 whiteknight We could take the Perl5 parser wholesale and add it in as a frontend for Parrot
20:06 Tene Sup dawg, I heard you like plugging.
20:06 whiteknight and program Parrot natively in Perl5
20:07 treed "Everything Pluggable" is a good goal.
20:07 * Tene plugs treed.
20:07 whiteknight treed: it's also a ticket!
20:07 treed It demonstrates that you're using encapsulation.
20:07 NotFound And for fans we can sell a "Parrot Unplugged" special edition
20:07 treed Tene: :o
20:08 whiteknight allison++
20:08 whiteknight (Great email she just sent out, everybody should read it
20:08 Tene Just now?  After the jit one?
20:08 treed The JIT one?
20:08 * treed doesn't have anything newer than that.
20:09 MoC "Parrot, a Virtual Machine for running dynamic languages. And for building Virtual Machines running dynamic languages."
20:09 MoC ;)
20:12 whiteknight parrot kicks ass, and will kick more in the future
20:12 NotFound You'll be assimilated!
20:13 Tene NotFound: pluggably?
20:14 NotFound Tene: that's for 3.6 at least
20:14 NotFound Pluggable world
20:16 theory joined #parrot
20:17 theory joined #parrot
20:28 HG` joined #parrot
20:28 whiteknight So what we need now is a series of tickets outlining what we need to do to make JIT happen
20:29 whiteknight (1) Design lorito
20:29 whiteknight (2) Lorito parser with multiple backends (C code in several formats, LLVM code)
20:29 whiteknight (3) redirection --runcore=jit to the fast core
20:29 whiteknight (4) rip out the current JIT system
20:30 whiteknight (5) read LLVM documentation like mad men
20:30 whiteknight (6)???
20:30 whiteknight (7)PROFIT!
20:30 moritz join the llvm developers IRC channel ;-)
20:30 moritz (if they have one)
20:30 whiteknight I dont know. They have a mailing list that I am already on
20:30 dukeleto joined #parrot
20:31 NotFound (8) Make a C compiler with PCT
20:31 Tene #llvm on irc.oftc.net
20:31 Tene I'm idling there now.
20:32 chromatic I'll take #3; it's trivial.
20:32 darbelo (5) can be done simultaneously with the others. (3) and (4) don't need to wait on (1) or (2) either.
20:32 particle i'll take #7
20:33 darbelo I volunteer for 4
20:33 chromatic #3 waits until after 1.6.
20:33 * darbelo likes ripping out stuff.
20:33 whiteknight chromatic: we can make a branch ow and merge it after 1.6
20:34 whiteknight Everybody: Find things you want to do, create a ticket, and be owner of it
20:34 NotFound Didn't we say something about short live of branches?
20:35 NotFound Forget it, 1.6 is near enough
20:35 purl NotFound, I didn't have anything matching it, 1.6 is near enough
20:35 particle whiteknight: it's like a 10 line patch, including docs. no need for a branch
20:35 whiteknight NotFound: 1.6 is out in less then 1week!
20:35 particle #3, that is
20:35 whiteknight particle: but we can start ripping out the JIT code too
20:35 whiteknight We need to scalpel out everything but the NCI thunk generator
20:36 chromatic I can make a local Git branch.
20:36 chromatic .o0O scaryy O0o.
20:36 whiteknight you git people and your black magic!
20:36 particle could you instead update news and platforms? :P
20:36 dalek tracwiki: v11 | chromatic++ | JITRewrite
20:36 dalek tracwiki: added specific JIT replacement tasks and volunteers
20:36 dalek tracwiki: https://trac.parrot.org/parrot/wiki/J​ITRewrite?version=11&amp;action=diff
20:37 whiteknight particle: I updated NEWS a few days ago with the big things this month
20:37 * particle assumes he won't have to do any file updates, just run make release && tar :)
20:37 whiteknight platforms does need an update though
20:38 whiteknight do we need a PCT-based C compiler for this?
20:38 whiteknight or a C-generating backend?
20:39 chromatic A C-generating backend should handle it.
20:40 whiteknight I think Lorito will be easy enough to design now
20:40 dalek tracwiki: v12 | whiteknight++ | JITRewrite
20:40 dalek tracwiki: https://trac.parrot.org/parrot/wiki/J​ITRewrite?version=12&amp;action=diff
20:40 whiteknight start with LLVM ops, make them look a little more like PASM ops, ignore anything we don't like, and add a little sugar
20:41 eiro joined #parrot
20:41 Coke einstein: I think your browser might be overly anxious. (it's a multi-host cert, should be ok.)
20:42 * whiteknight has to go home now. Later
20:42 bacek joined #parrot
20:44 einstein ok
20:46 quek joined #parrot
20:47 Coke And we did just replace the old (expired) cert. this one is from a different provider (which my command line stuff was anxious about at one point.)
20:53 cotto Should we be reading the docs for all the jit libraries so we know that whatever interface we design makes sense?
20:54 quek left #parrot
20:55 darbelo cotto: Probably, but LLVM goes first, so it makes sense to read it's docs first.
20:55 cotto it may also be the case that any interface that works for llvm works for the other systems.  I don't have enough experience to say.
20:56 darbelo I gues that depends on how ll llvm is :)
21:01 Coke (llvm goes first) only if you assume that /someone/ read the docs and that their choice is sane.
21:01 Coke (which I am, but just to be clear.)
21:03 darbelo Sanity is a pretty big thing to acuse people of, young man.
21:04 Tene Coke: you am sane
21:04 Tene ?
21:07 Coke I am assuming.
21:11 davidfetter joined #parrot
21:18 davidfetter joined #parrot
21:23 allison joined #parrot
21:23 davidfetter joined #parrot
21:26 fperrad left #parrot
21:35 joeri left #parrot
21:41 beta joined #parrot
21:41 beta left #parrot
21:49 bacek joined #parrot
21:49 bacek Good morning everyone except purl
21:50 bacek seen Whiteknight
21:50 purl Whiteknight was last seen on #parrot 1 hours, 7 minutes and 57 seconds ago, saying: has to go home now. Later
21:52 davidfetter joined #parrot
21:52 darbelo Hmm. There is a bunch of broken 'testing only' functions in src/pmc_freeze.c wonder if I can rim them out...
21:53 bacek darbelo: kill 'em. KILLEMALL!
21:56 cotto darbelo, what he said
21:56 Zak joined #parrot
22:03 * Coke mumbles something about six segfaults.
22:04 bacek Coke: I can't repoduce #967...
22:05 ruoso joined #parrot
22:06 Coke bacek: that's the one that notfound said he fixed in https://trac.parrot.org/parrot/changeset/40974 ?
22:07 bacek Coke: yeah... Can we close ticket?
22:07 NotFound Uh, forget to put a note in the ticket, sorry
22:07 purl NotFound, I didn't have anything matching to put a note in the ticket, sorry
22:07 Coke bacek: sure.
22:08 Coke partcl parrot problems?
22:08 purl partcl parrot problems is http://xrl.us/bfjj37 [code.google.com]
22:08 Coke (anything in that list that says "segfault" is probably still open.)
22:08 Tene partcl parrot successes?
22:08 bacek NotFound: can you close ticket? I'm not going to steal your karma :)
22:09 Coke partcl parrot successes is <reply>*cricket noise*
22:09 Coke partcl #107 might be the cause of mikehh's random segfaults.
22:10 Coke (and it's packfile goodness!)
22:10 Coke -> noms
22:10 * bacek hate packfiles...
22:12 NotFound bacek: done
22:13 bacek duff?
22:13 purl duff is perljam
22:15 dalek TT #967 closed by NotFound++: segfault in utf8_set_position
22:15 darbelo svn diff | wc -l 346
22:17 NotFound Coke: mmmmm... I'm thinking that interp->initial_pf may be the source of all evil.
22:17 darbelo NotFound: Anything with "_pf" on it's name is a source of evil.
22:18 NotFound darbelo: agreed, but that in particular may be related to the Eval.destroy thing
22:19 NotFound The same packfile may be destroyed from several places.
22:19 darbelo Oh, you were looking for a *specific* evil. My bad.
22:19 NotFound All evil related with dying at exit, I mean
22:21 bacek tclsh is crashing under valgrind... Hm...
22:23 Whiteknight joined #parrot
22:26 darbelo Hmm. nopaste.pl needs WWW/Mechanize.pl, wonder if that's in ports.
22:26 Andy it should install with CPAN no prob
22:26 Andy but it's likely to be in ports.
22:27 darbelo Ah, it is. Installing now.
22:27 NotFound I think I have a fix, evne if ugly
22:27 darbelo Andy: using cpan can complicate upgrades, I'd rather use ports when there's one available.
22:28 Andy understood
22:29 dalek parrot: r41174 | bacek++ | trunk/src/pmc/continuation.pmc:
22:29 dalek parrot: [cage] Don't try to mark not-fully-construted Continuation.
22:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41174/
22:29 dalek parrot: r41175 | bacek++ | trunk/include/parrot/compiler.h:
22:29 dalek parrot: [cage] Fix compilation without clang and with g++.
22:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41175/
22:30 darbelo All tests successful.
22:30 purl darbelo: that's because you wrote only one test, slacker!
22:32 dalek parrot: r41176 | NotFound++ | trunk/src/pmc/eval.pmc:
22:32 dalek parrot: [core] quick and dirty fix for TT #995
22:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41176/
22:33 NotFound Uh, a little too dirty
22:33 bacek_ joined #parrot
22:35 nopaste "darbelo" at 200.49.154.172 pasted "Kill broken functions with fire. bacek++ cotto++" (347 lines) at http://nopaste.snit.ch/17895
22:36 chromatic Whoa, time to optimize tools/dev/pprof2cg.pl.
22:36 dalek parrot: r41177 | NotFound++ | trunk/src/pmc/eval.pmc:
22:36 dalek parrot: [cage] fix c++ failure from r41176
22:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41177/
22:37 darbelo bacek_, cotto : Killed 'em all. Want to review/commit http://nopaste.snit.ch/17895 ?
22:37 bacek_ darbelo: looking
22:38 bacek_ darbelo: make headerizer?
22:38 darbelo Left it out of the patch. You should run it if you apply it.
22:38 cotto chromatic, what do you suggest?
22:39 NotFound Coke: let's hope r41176/r41177 fixes several segafults
22:39 chromatic cotto, I'll take a look and see what jumps out at me.
22:39 cotto chromatic, are you just noticing how slow it is?
22:39 chromatic Yes.
22:39 chromatic It'll take a while to burn through 168MB of logs, but even still...
22:40 cotto I haven't bothered to optimize it at all.
22:40 chromatic I know a bit about Perl 5.  Maybe something will be obvious.
22:41 cotto So I've heard.
22:41 darbelo bacek_: It was already 340+ lines of patch without headerizing, I figured more than that would complicate review.
22:41 bacek_ darbelo: no worries.
22:43 rg1 joined #parrot
22:44 chromatic We do get output though....
22:44 NotFound Uh, no, that fix is not enough to solve them all.
22:44 chromatic Perl6Object::Build is *expensive*.
22:46 dalek parrot: r41178 | bacek++ | trunk/src/pmc_freeze.c:
22:46 dalek parrot: [cage] Remove unused functions from src/pmc_freeze.c. Patch courtesy of darbelo++
22:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41178/
22:55 Whiteknight I didn't know chromatic knew perl5! I thought his blog posts were all hypothetical!
22:56 Whiteknight somebody needs to get darbelo a damn commit bit!!
22:56 bacek_ Somebody have to submit CLA!
22:58 darbelo Sent it already, but it's way more fun to make you guys commit stuff for me.
22:58 darbelo ;)
23:00 cotto I'll commit you
23:00 cotto to an institution ;)
23:00 pmichaud I hear that marriage is a great institution :)
23:03 bacek Whiteknight: I'm start thinking about major GC "clean-up".
23:03 darbelo Clean it with fire?
23:03 * cotto hands a machete to bacek
23:03 bacek darbelo: yeah. Something like this :)
23:04 * bacek rejecting cotto's machete and get flamethrower.
23:05 Hunger joined #parrot
23:05 * darbelo applies for a patent on the 'flame-throwing machete'
23:07 Whiteknight bacek: cleanup or implementing a new core?
23:07 Whiteknight or both :)
23:08 bacek Whiteknight: clean-up first, generational compacting gc second :)
23:09 bacek We can have is almost for free with new attributes allocation schema.
23:09 cognominal joined #parrot
23:09 bacek mprotect?
23:10 bacek purl: mprotect?
23:10 purl bacek: no idea
23:10 bacek bah. Useless girl...
23:11 cotto darbelo, good patch.
23:12 jan joined #parrot
23:12 bacek Whiteknight: my current idea: Expose gc functions via GC_subsystem (gc-refactor branch); Implement compacting of ATTRibutes; (Don't compact PMC* by itself); Use mprotect to get cheap "old-to-new" pointers tracing.
23:13 NotFound PackFile segments direct usage are planned to be replace by his PMC counterparts?
23:13 bacek NotFound: TT#504.
23:13 darbelo cotto: Not a big deal, really. It's just removing stuff. I'm good at that :)
23:14 Whiteknight bacek: I don't think that gets us anything, we don't sweep the attributes pools, so we don't need to move items to be faster for sweeping
23:14 Whiteknight compacting the attributes pools won't help anything
23:14 bacek Whiteknight: it will. (more)
23:15 Hunger joined #parrot
23:15 bacek If we compact "old" ATTRibutes into single set of pages we can mprotect them for writing (more)
23:16 bacek When someone will try to write into protected attribute we'll mark page with "dirty" flag
23:16 NotFound The coredumps at exit seems to be all double destruction of PackFile, there is no much point in add workarounds if this will change soon.
23:16 bacek In "mark" phase we will just ignore "clean" old pages.
23:17 Whiteknight bacek: but the PMCs aren't marked like that, and we don't mark attributes
23:17 darbelo NotFound: fsvo soon...
23:18 bacek Whiteknight: we do mark attributes. Every custom Foo.mark marking attributes
23:18 NotFound darbelo: sooner if we work on that instead of in the problems caused for no having that.
23:18 Whiteknight bacek: we don't mark the attributes structure itself, we mark the thigs that it points to
23:18 bacek Whiteknight: ah. Yes.
23:19 darbelo NotFound: True.
23:19 bacek So, when "attributes structure" belong to "clean old" page we can skip marking of pointers.
23:19 cotto This is charming.  After splitting the profiling runcore off into a separate file, it appears to run rakudo hello world 10x slower.
23:20 cotto Somehow it's also running about 10x more instructions.
23:20 Whiteknight bacek: but the PMCs are located in a different page, and they still need to get marked somehow
23:20 NotFound cotto: Lack of global inlining ability of the compiler?
23:20 bacek Whiteknight: yes. I'm not going to remove this phase.
23:21 cotto NotFound, that wouldn't explain why it's running 10x more PIR instructions.
23:22 NotFound cotto: uh... no
23:23 bacek Whiteknight: anyway, first thing is expose current GC functions via GC_subsystem to decouple GC. Then we can break underlying stuff.
23:23 Whiteknight bacek: agreed
23:23 bacek And it's $dayjob time.
23:28 hercynium joined #parrot
23:29 cotto It's odd because that commit did nothing but copy a couple files and delete some lines, apart from the makefile updates.
23:30 darbelo cotto: a change in rakudo maybe?
23:31 cotto nope.  I've been testing against the same rakudo version.
23:31 cotto s/version/revision/
23:31 kyle_l5l joined #parrot
23:32 kid51 joined #parrot
23:33 darbelo ghosts?
23:33 purl In this room where shadows live / And ghosts that failed learned time forgives / Welcome friends, please stay awhile / Our story start with one small child ...
23:34 pmichaud maybe some change to vtable handling?
23:34 pmichaud i.e., things that weren't being handled by PIR vtables in one runcore are being handled that way in another?
23:34 pmichaud (yes, I'm grasping at straws)
23:35 cotto I'm seeing if I can nail it down to a single revision, before which profiling is fast and after which it's slow.
23:36 pmichaud oh yes, I was going to see how parrot changes since 1.5.0 have affected rakudo spectest timings
23:36 pmichaud I'll do that real quick
23:37 chromatic I have an idea about PMC recycling in generated code, but that'll be an experiment on my part....
23:39 cotto ok.  it looks like the slowdown happens in the revision before I split out the profiling runcore
23:39 cotto this'll be fun
23:40 darbelo cotto: which rev is that?
23:40 cotto darbelo, r41150
23:42 kid51 smolder down again?
23:42 dalek parrot: r41179 | mikehh++ | trunk/src/pmc_freeze.c:
23:42 dalek parrot: codetest failure - pod syntax
23:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41179/
23:43 darbelo "* Move SQLite3.pir from ext/ to library/ so it can be installed"? That r41150?
23:45 cotto darbelo, that's the revision right *before* I split off the runcore.
23:46 darbelo Oh, I was asking about the slowdown. It happens before splitting, right?
23:47 cotto darbelo, that's what I'm trying to figure out.
23:49 darbelo cotto: do you build optimized?
23:50 cotto darbelo, no, but the difference isn't attributable to that.  --optimize speeds profiled rakudo hw from ~3m to ~2m
23:51 cotto (when the slowdown is in effect)
23:51 darbelo That's r41140 off the hook then.
23:53 cotto ?
23:53 cotto oic
23:56 darbelo or maybe not, I have no clue when NDEBUG is (or isn't) #defined.
23:57 cotto I'll find out.
23:57 cotto 41120 is fast
23:58 NotFound pmichaud: exception handlers must be run in the context where the exception was thrown in order to be able to acces his lexicals?
23:58 skv_ joined #parrot

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

Parrot | source cross referenced