www.parrot.org | Prepare for 1.6.0: Improve test coverage for NameSpace and Continuation PMCs / Stability! / Port tests to PIR / Performance! / No more big branch merging until after 1.6.0
Set by moderator on 8 September 2009.
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
at least if I try to think about barriers of entry as a newbie
which I am :) 00:01
allison How is Git for source browsing tools, as in Trac?
Does it have integration with Trac? 00:02
How does it handle commit notifications (parrot-commits list)?
szbalint gitweb is written in Perl :)
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.
Whiteknight darbelo: I want good coders to have access to the code
I don't think I support a switch if it's going to regress features on Trac 00:04
that would be far too much pain
allison szbalint: gitweb looks pretty primitive
chromatic Yes, we need to keep Trac integration.
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
Whiteknight ...does email2trac work now? 00:06
darbelo allegedly, it does.
duk3leto i wouldn't propose switching to git if we couldn't have the same kind of trac integration that we do now
trac-hacks.org/wiki/GitPlugin 00:07
dalek tracwiki: v2 | dukeleto++ | GitCookbook
szbalint it's something to test I guess
dalek tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
duk3leto looks like trac supports git
Tene So... what's the trac integration with svn? I don't actually use trac enough to know what's being discussed here.
allison Whiteknight: yup, I tested it round trip, it really works 00:08
Tene: a really nice source browser, revisions act like wiki pages, and auto link from tickets
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
since you actually have the whole repository history
Tene szbalint: or just as much of it as you want.
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
szbalint: what's the interface like?
Whiteknight maybe I missed it
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
allison Whiteknight: and if you email to tickets@parrot.org it creates a new ticket
szbalint allison: multiple GUIs are available, I prefer commandline so I don't really know, just tried a few out for curiosity's sake...
chromatic tickets@parrot.org works now? That's good! 00:12
Tene :D
szbalint did anyone try to import the whole svn history into git yet btw? How's that wrt repository size?
Tene gitk and git-gui are the traditional ones... don't know about others or newer guis.
allison ah, I thought folks knew that (I did mention it in my report that week, at least)
Whiteknight see? even chromatic didn't know! And he's supposed to know everything
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
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
Tene duk3leto: ^W ?
purl ^W is ^Wine
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
Tene 'night allison
allison Tene: 'night 00:16
cotto clock?
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 /
duk3leto Tene: gitx is pretty slick if you are on os x
szbalint my experience is that a pure git checkout with all the repo history is smaller or on par with a svn HEAD checkout
duk3leto szbalint: git is about 3 times smaller, on average 00:17
dalek tracwiki: v3 | dukeleto++ | GitCookbook
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
duk3leto szbalint: since it doesn't have a .svn dir in *every* directory with a bunch of redundant information
szbalint yeah 00:18
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
but I don't think that applies here
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 :)
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 :)
dalek tracwiki: v4 | dukeleto++ | GitCookbook 00:21
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
cotto duk3leto, an index would be helpful on that page 00:22
duk3leto cotto: patches welcome :) 00:23
treed szbalint: progit.org/book/ch6-6.html
Submodules.
purl submodules are useful for something like perl's ext/ dir
duk3leto cotto: but not conflicts :)
Whiteknight duk3leto: fatal: not a git repository 00:25
(first command from the cookbook)
git checkout git://github.com/leto/parrot.git
duk3leto Whiteknight: well, i suck then 00:26
Whiteknight: duh! it shold be clone. fixing now
git clone git://github.com/leto/parrot.git 00:27
Whiteknight++ for checking my shtuff
Whiteknight okay, getting it now. This is going to take some time, isn't it?
dalek tracwiki: v5 | dukeleto++ | GitCookbook
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
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.
Whiteknight: yes, you only need to clone once. you are getting the *entire* history of parrot.
Whiteknight okay, so after this, how do I branch? 00:29
chromatic git branch <branchname>
duk3leto Whiteknight: add that now to the wiki :)
cotto duk3leto, that's why I haven't done anything yet.
Whiteknight chromatic: rephrased, where does it branch from? is the branch another clone that will take "a few minutes" to get?
treed "git checkout -b <branchname>" is arguably more useful
(Makes the branch *and* makes it the active one.)
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
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?
chromatic No clone, it's a local branch.
treed Whiteknight: Once you have the the back history, you shouldn't need to download much ever again.
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
dalek tracwiki: v6 | dukeleto++ | GitCookbook
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
Whiteknight because I have no idea what the hell the difference between those is supposed to be
szbalint treed: ah, so inside out thingy, okay
treed Whiteknight: "git branch <branchname>" makes the branch, and then you "git checkout <branchname>" to actually work on it.
Whiteknight: Or you can just do "git checkout -b <branchname>" to do both
(Which is usually what you want.) 00:32
chromatic Whiteknight, the .git file in the top-level directory *is* the repository.
Within your top-level directory, you can switch between branches at will.
You don't have to check out new checkouts for each branch you want to manage.
Understand more now? 00:33
duk3leto chromatic: unless you want to work on many branches simultaneously ;) we won't go there right now
Whiteknight: our git cookbook needs a glossary. same page or different page ?
git is like math, where people use simple words to mean very specific things 00:34
dalek tracwiki: v7 | dukeleto++ | GitCookbook
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
duk3leto Whiteknight: is that page approaching something useable for you? don't candy coat anything, tell me how it is, straight up. 00:35
Whiteknight: ALSO, you should install the git bash completion script. it shows you the current branch in your PS1, and I find that invaluable
cotto $PS1 is fun 00:36
Whiteknight chromatic: yes, that makes much more sense
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
Whiteknight I write all my own local aliases that add svn version numbers to PS1
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
so I only need to learn the right way once 00:39
treed "manifestation of the current branch" == "working directory"
chromatic: Doesn't svn have bisect, too?
search.cpan.org/~infinoid/App-SVN-B...svn-bisect
duk3leto treed: holy hotdogs, batman!
treed I guess it's not stock. 00:40
But such a tool exists for svn. (And from our own Infinoid, no less.)
But, yes, git bisect is awesome.
szbalint git blame too
treed As is "git commit -i"
And git rebase -i
purl hmmm... git rebase -i is NOT a tool for viewing a branch
treed No, it certainly is not. 00:41
00:41 sri joined, shockwave joined
Whiteknight duk3leto: where is this git bash completion script at? 00:41
treed Is there a git zsh completion module? 00:42
treed has completely forgotten why he switched to zsh back in the day.
the vi keybindings just mostly get in the way
Because there's no status line to tell me what mode I'm in.
duk3leto Whiteknight: repo.or.cz/w/git.git?a=blob;f=contr...etion.bash
Whiteknight duk3leto: so this repository you have on git, does it interact with svn.parrot.org? 00:44
like, how do I get my changes to that server?
dalek tracwiki: v8 | dukeleto++ | GitCookbook 00:45
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
tracwiki: v9 | dukeleto++ | GitCookbook
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
duk3leto Whiteknight: the github mirror is a pure git mirror of svn. you want to push changes to it?
Whiteknight: i also push some of my local git branches there, so others can see them
Whiteknight duk3leto: I don't care where I push changes to, so long as they end up on svn.parrot.org
duk3leto Whiteknight: i don't know if I answered your question 00:46
Whiteknight I don't know if I asked a sensible question
duk3leto Whiteknight: I don't think you did :) so we are even
chromatic I think you're asking about git-svn.
Whiteknight Okay, I make a change locally. I want to put that change on svn.parrot.org. I do this by typing "..."?
duk3leto git-svn makes everything exponentially more complicated 00:47
chromatic git add ... ; git commit ... ; git svn dcommit
Possibly also a git svn rebase in there. See "more complicated".
Whiteknight chromatic: and those incantations will put changes on svn.parrot.org?
that's the only result I care about
chromatic Yes.
duk3leto Whiteknight: IF you are using git-svn with the correct setup
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?"
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
Whiteknight okay. Lay that stuff on me
duk3leto Whiteknight: there is a public mirror of the entire git-svn history of parrot. i need to find that link
chromatic ... and where the rest of us say "That's why we're not big fans of git-svn."
Whiteknight I'm not daunted by learning new things. For personal growth learning new things is important 00:49
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
duk3leto Whiteknight: git-svn performs black magic. no kiddin'
chromatic All I'm saying is "Git isn't so difficult to use, once you learn a few commands".
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
Whiteknight duk3leto: That's fine, black magic, hard to use, blah blah blah. How do I do it?
duk3leto Whiteknight: that is what the git-svn wiki page is for
Whiteknight we have a page for it? link?
duk3leto Whiteknight: trac.parrot.org/parrot/wiki/git-svn-tutorial 00:52
feast on that for abit :)
Whiteknight (I find it remarkably hard to find things on the trac wiki)
duk3leto ooh, there is another git-svn mirror: moritz.faui2k3.org/files/parrot-all...svn.tar.gz
Whiteknight: the gitcookbook is meant as an intro to pure git, the git-svn-tutorial is where the real fun is :) 00:53
Whiteknight yeah, I'm reading it now 00:54
still isn't answering my question though, that I can see
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 ?
darbelo has Z's to catch.
duk3leto Whiteknight: you want to push changes to SVN from git-svn ?
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
so I type "git-svn ..." and that magically happens
and everybody is happy
duk3leto Whiteknight: that would be "git svn dcommit", which takes your local git commits and does a "distributed commit"
Whiteknight: no. you need a git-svn repo. you currently have a pure git repo
Whiteknight ah, that's the step I'm missing!
duk3leto Whiteknight: download moritz.faui2k3.org/files/parrot-all...svn.tar.gz
Whiteknight so I need a separate repo entirely? 00:57
00:57 darbelo left
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
duk3leto Whiteknight: they can be the same repo or different
Whiteknight ?
duk3leto Whiteknight: yes
Whiteknight okay.
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
duk3leto Whiteknight: first thing you should do when you download and untar that file is: cd parrot;git svn rebase
Whiteknight: git svn rebase =~ svn up 00:59
Tene Kinda. There's some nastiness there.
duk3leto Whiteknight: you can also do "git svn dcommit -n" to see a "dry run"
Tene: shhhh!
Whiteknight: so see the diff between your local copy and trunk: git diff svn/trunk.. 01:00
s/so see/to see/ 01:01
now we need to get into the idea of "commitishes" and i need to go home
Tene treed++ # agree with mail to the list 01:02
treed Sweet, I'm not completely talking out of my ass there.
treed thought that maybe he didn't really understand push if people think it could be used that way.
Tene I can *kinda* get what he's wanting to do... 01:03
but, yeah, just use keyed access, IMO
treed I kinda get it, too.
But, conceptually, those operations just aren't appropriate. 01:04
You could try to wedge it in, but the end result is likely to be complex and non-intuitive.
Tene .ie
treed Especially once you start combining push/pop, shift/unshift, and keyed access.
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.
pmichaud 1. checkout repo: git clone git@github.com:rakudo/rakudo.git
2. make modifications: vi src/foo.bar
3. commit modifications to my local repo: git commit src/foo.bar
4. push my local repo back to git master: git push
done.
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
pmichaud: I guess what I'm trying to say is, be jonathan now.
So.. nm.
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
I can save I've nevr had trouble with the above -- it works almost exactly like svn in that respect
s/save/say/
duk3leto pmichaud: helpful +!
+1 even 01:07
pmichaud if I want to commit modifications for an entire subdirectory (e.g., src/), it's git commit src
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.
pmichaud if I want to commit all modifications I've made from the current directory and lower, it's git commit .
if I want to grab the changes that others have made from the master repo, it's "git pull" 01:08
01:08 theory joined
pmichaud git seems to allow one to work with a very svn-like model if desired. 01:08
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
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
01:09 theory joined
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:11
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
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.
pmichaud exactly.
and merging a local branch to HEAD is easy
duk3leto pmichaud: feel free to add to trac.parrot.org/parrot/wiki/GitCookbook :)
pmichaud duk3leto: I don't know if the instructions I just wrote apply at all to git-svn, though. 01:14
git-svn seems to introduce a fair bit more complexity.
duk3leto pmichaud: that page is for pure git
pmichaud: we have a seperate page for git-svn
chromatic duk3leto, I could use something about suppressing the "convert leading whitespace to tab" behavior, however.
duk3leto pmichaud: hmm. you want that or you *don't* want that?
pmichaud want what? 01:15
purl well, want is often mispronounced as 'need' or broken by design, but at least it's clever
duk3leto pmichaud: i meant chromatic, sorry
chromatic I don't want that... seems like my past few commits have had leading spaces squashed into tabs.
Tene git should *not* be doing that. are you fairly confident that it's not your editor?
pmichaud I've never had leading spaces squash to tabs 01:16
at least, I'm not aware of it in rakudo
chromatic I'm very confident it's not my editor; it doesn't happen for me with SVN or SVK.
Tene nods.
chromatic I'll see what happens with my next dcommit. 01:17
I do have this in my .gitconfig: [apply]
whitespace = strip
And this in [core]:
whitespace = trailing-space,space-before-tab,indent-with-non-tab,cr-at-eol
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
treed Huh? 01:20
Is that figurative?
duk3leto likes lakes
cotto Ironically I'm moving near a lake and plan on frequently jumping into it.
treed Because I didn't intend to imply any sort of "FOAD" attitude.
cotto afk &
duk3leto treed: i didn't take any, no worries. 01:21
treed k
duk3leto has thick skin, which comes in handy when you want to tell people to change their VCS ;) 01:22
treed Haha.
Tene chromatic: yes, those settings could result in whitespace changes.
Coke replied on list. I think it depends on your use case.
chromatic I removed the indent-with-non-tab option.
Coke HLL interp suggests we be more liberal.
Tene chromatic: apply.whitespace=strip is an alias for apply.whitespace=fix
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
"repair"
Whiteknight cotto: where are you moving to? 01:24
treed replied to your reply.
Speaking of moving, I'll be moving to the Bay Area next week.
duk3leto treed: coolio, where?
treed As close to Palo Alto as possible. 01:25
Or, secondarily, as close to a caltrain station as possible.
duk3leto: You live in the bay area?
Tene I'll be moving to the Bay Area next... year, maybe.
treed Neat. 01:26
treed got a job with IMVU, starting on the 14th.
Still gotta find a place to stay.
But that's difficult from Pasadena.
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
treed Ah. 01:28
duk3leto time to bike home, see y'all later
treed Later.
Coke wonders why he said "an PMC". 01:30
Coke really needs to proof what his fingers type before he hits send.
chromatic Mrs. Coleda, your husband has what we call "Stupid fingers." 01:31
Give him a commit bit; he'll fit right in!
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.
good simpsons references never get old 01:33
new simpsons references never get quoted
chromatic You are trying to commit regicide. Your working copy is dirty. Please fix or revert all local changes and try again.
dalek tracwiki: v1 | pmichaud++ | GitCookbook-Pm 01:38
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
pmichaud there's my first draft of my workflow at present.
it probably needs some improvement for non-committers
there's probably some git command or sequence that makes creating a patch as easy as "svn diff" 01:40
Coke wonders where to go to find cheap (and safe!) us-uk flights. 01:44
01:47 shockwave joined
Tene pmichaud: 'git diff' isn't it? 01:56
02:07 Zak joined
Tene purl: msg WhiteKnight So, where is async io in your TODO list? 02:16
purl Message for whiteknight stored.
dalek TT #989 closed by jkeenan++: t/compilers/tge/grammar.t: FAIL under 'make test', but passes with ... 02:22
TT #989 reopened by jkeenan++: t/compilers/tge/grammar.t: FAIL under 'make test', but passes with ... 02:29
rtcl: r702 | coke++ | wiki/ParrotIssues.wiki:
these now have partcl tickets to reference the parrot tickets.
 02:31
rtcl: r703 | coke++ | wiki/ParrotIssues.wiki:
this issue has been resolved.
TT #732 closed by coke++: Coroutine contexts not getting freed 02:32
TT #68 reopened by coke++: runtime/parrot/library/tcpstream.pir broken 02:36
TT #68 closed by coke++: runtime/parrot/library/tcpstream.pir broken 02:39
rtcl: r704 | coke++ | wiki/ParrotIssues.wiki:
The answer? Socket.pmc
 02:41
02:42 janus joined
dalek rtcl: r705 | coke++ | wiki/ParrotIssues.wiki:
Deleting wiki page ParrotIssues.
 02:46
02:47 hercynium joined
dalek TT #995 created by coke++: segfault in ?? (directory_destroy) 02:59
Coke ok, I'm creating these faster than you close them! =-)
any io people here? 03:07
(what kind of 'address' is expected when you invoke 'connect' on a Socket? 03:08
ah. whatever sockaddr returns? hurm. 03:11
03:13 TiMBuS joined 03:31 shockwave joined
shockwave Hello. I have some code that looks like so: 03:32
.namespace ['Empty']
.sub __x__Empty :load :init :anon
.local pmc __x__Empty_class
__x__Empty_class = newclass ['Empty']
.end
When I compile this code, I get this error:
Friggin dos, I can't copy and paste.
Well, it says that class 'Empty' is already registered.
treed Maybe it is? 03:33
shockwave That's the only code I've got.
I haven't registered anything else.
treed Maybe it's clashing with something in Parrot?
shockwave No, that's not it. I changed the name, and the same thing. 03:34
treed Try removing the brackets?
shockwave Same 03:35
treed Dunno, then.
Maybe it's getting run twice somehow.
Use debugging says before and after th enewclass line?
Coke if you're doing :load and :init, how are you running the file? 03:36
shockwave parrot test.pir
I removed :init, and it doesn't give me the error.
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
shockwave I got that code from the Mysql example.
treed I don't think so?
Usually if you have a pir file, you have a :main function
If you're going to be running it directly, anyway. 03:38
Coke actually, yah, I can duplicate that error.
treed: oh.
yah. that's probaby it; you have :init /and/ that's your implicit :main
treed Dunno if his issue is expected behavior though.
There's such a thing as implicit :main?
Coke yup.
":main else first sub." 03:39
so that's getting invoked as :init and then :main
so add an empty main or ditch the :init
... 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'" ?
treed Yeah.
Coke no. =-)
treed That's how Cardinal does it.
Coke not necessarily.
treed Eh?
Coke :init is for things run from the command line. 03:41
treed Oh
Coke :load is for things loaded with load_bytecode.
treed Well, Cardinal does :init :load :anon
But that's good to know.
Coke things loaded via include... are not either. they are whatever the file that included them was.
so you can have an .include that gets load'd or an .include that gets :init'd 03:42
(it's the includ-er that matters)
jdv79 Coke: whatsup with your obsession with tcl?
i've ask 3 times in #tcl about the testing protocol/format/whatever with no answer:(
Coke what an odd question.
Yah. they think I'm crazy.
shockwave So what's the recommened way to make sure my class get's defined when .include'ed ?
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?
treed shockwave: Declare it both :load and :init
To be safe.
Coke or sorry. =-)
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.
Coke jdv79: the core commiters are helpful.
shockwave Well, I guess it comes with the territory. :)
Thanks, guys.
dalek rrot: r41168 | petdance++ | trunk/include/parrot/compiler.h:
improvements for the clang noreturn
 04:08
ttbot Parrot trunk/ r41168 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/87780.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 04:11
jdv79 Coke: seriously, why? 04:13
purl well, seriously, why is it luser code?
04:15 Andy joined
Coke jdv79: no good reason 04:15
Coke finally has a smolder kick off without dying on the ssl cert 04:16
04:16 beta left
dalek rrot: r41169 | petdance++ | trunk/include/parrot/compiler.h:
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
Coke bad andy is also andy-- !
Andy Waaaah
Coke good andy, bad andy. I'm the guy with the gun.
Andy I don't know why I came here tonight. 04:19
Coke for the love?
Coke is not looking forward to rolling his own readline in PIR.
Andy oh whoops, mixed up my movie references
Coke This is my boomstick?
jack and shit, and jack left town? 04:20
Andy I've never seen Army of Darkness, actually
Coke GAH!:ILH!
Andy I was thinking that that was Reservoir Dogs
Coke IM me your address I'll snail mail you a copy
it's the cheese that keeps on giving.
I'm fairly certain I have the low rent version of the dvd. 04:21
(plus the high rent versioN)
dalek rrot: r41170 | petdance++ | trunk/include/parrot/compiler.h:
handle clang compiler directives
 04:28
Andy it's not a matter of being unable to get it 04:29
I just haven't seen it
dukeleto +1 to boomsticks 04:32
Coke Andy: get thee to a netflix! 04:45
"you found me beautiful once..."
Andy gave up netflix
just a matter of time.
Coke anyone have any opinions on whether Socket PMC should implement readline? 04:47
dalek rtcl: r706 | coke++ | trunk/runtime/ (4 files):
update issue 106
 04:57
05:08 kyle_l5l joined 05:15 Zak joined
cotto I'm tempted to post a poll on parrot.org to gauge people's opinions on using git. 05:22
s/using/switching Parrot to/
wording is always tricky 05:24
dukeleto cotto: you know how I feel about *that* issue
PerlJam cotto: you think people's opinions have changed much in the last year or so? 05:25
cotto PerlJam, what do you mean?
was there a previous poll or discussion? 05:26
PerlJam There was a discussion about a year ago or so.
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
cotto I may end up posting one, but it's too late to come up with adequate wording atm.
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.
cotto++ good luck too.
cotto I don't know much, but I know you have to be really careful.
Coke anyone know what the valid values of whence are for the seek opcode? 05:29
(and if so, can you put that in the seek op docs?
PerlJam probably 0, 1, and 2 corresponding to "seek from beginning", "seek from current position", and "seek from end" :) 05:31
But that's just a complete guess from having used something called seek() in another language once or twice before.
;) 05:32
Coke looks like a good guess based on the C function the opcode calls. can you upate the docs? =-)
PerlJam let's see if the barrier to entry is too high on this machine ... 05:34
Which docs are you referring to exactly?
Coke src/ops/io.ops //seek 05:36
ugh. filehandle and socket don't have the same api? 05:44
(print vs. send)?
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:45
dalek rrot: r41171 | duff++ | trunk/src/ops/io.ops:
Document a guess about the valid values for the whence parameter to seek()
 05:47
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:50
Now I cannot find the 2 commits I had before the gitsquash. 05:51
any suggestions?
purl any suggestions are welcome. (including ripping it out entirely :))
Coke am I screwed? 05:52
dukeleto Coke: git reflot
git reflog
coke: your data is still there, no worries
Coke wierd. those are not in git log
dukeleto find the sha1 in git reflog, then "git reset sha1"
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)
Coke: i accept payment in beer and chocolate :) 05:54
Coke ok. how do I un-reset something I shouldn't have reset? =-) 05:56
dukeleto coke: say what? 05:58
purl say is println
05:58 fperrad joined
dukeleto you may need git reset --hard sha1 if you have modifications that you want to throw away 05:58
Coke I did "git reset foo". it was the wrong foo. 05:59
(reading docs... ok.)
git reset does not read as if it is re-applying a lone commit to HEAD. 06:00
the sha1 is the 7 digit hex leading the reflog? 06:03
treed that's the beginning part of it, yeah
Which is usually all you need.
What is it that you're trying to do? 06:04
fperrad allison, have you seen my recent email about load_language & WMLScript ?
dukeleto coke: you can use any unique part of a sha1 06:05
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.
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
Coke urf? so this isn't applying those two commits, it's just changing the head pointer? 06:08
dukeleto coke: yeah
Coke (effectively discarding any work that happened after that point?)
dukeleto coke: i think you want to cherry-pick 2 sha1's onto a branch, am I correct ?
Coke yes. 06:09
dukeleto Coke: you have a branch that is missing 2 commits, yes?
ah
coke: find the 2 sha1's then:
Coke (it's the local ... trunk, I guess)
dukeleto: got 'em.
dukeleto git cherry-pick sha1
git cherry-pick sha2
06:09 NotFound joined
Coke cherry pick is complaining that there is a conflict in a file that that commit didn't touch. 06:10
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.)
dukeleto do you have local modifications ?
i.e. the output of "git status -a"
nopaste "coke" at 72.228.52.192 pasted "# On branch master # Changes t" (24 lines) at nopaste.snit.ch/17892
Coke dukeleto: no. 06:12
dalek TT #997 created by gerd++: [BUG] Segmentation fault by building TGE on ppc64
Coke (not before I try the cherry pick. :|
dukeleto coke: the commit probably changes config/PARROT_VERSION, yes?
Coke no! 06:13
dukeleto coke: what does "git diff head" say ?
Coke fatal: ambiguous argument 'head': unknown revision or path not in the working tree.Use '--' to separate paths from revisions
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:14
dukeleto coke: what does git --version say? 06:15
coke: i guess older git's prefer HEAD
Coke 1.5.6.5
dukeleto coke: jurassic :)
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 ?
Coke That commit message has nothing to do with that file.
dukeleto you can do "git checkout config/PARROT_VERSION" to basically do the same as "svn revert file"
Coke (git show sha1 for that message does agree with all the other brokenness,though.)
git checkout config/PARROT_VERSION; git status - shows it as unmerged. 06:17
(git status -a shows it as modified)
This is about the time when I say "Hg sounds good" =-) 06:18
At least the other cherry pick might work, testing.
jrtayloriv Big time sleepy time. Nighty night. 06:19
Coke I think the commit for the second one is fubar in reflog.
by my own hand or not, I cannot say.
dukeleto coke: interesting 06:20
coke: git add file to say that you are done "merging it"
coke: git add config/PARROT_VERSION after you to "git checkout config/PARROT_VERSION", then commit the result 06:21
Coke I just did a git reset -hard 06:22
dalek rtcl: r707 | coke++ | trunk/runtime/builtin/ (2 files):
initial versions of [seek] and [tell]
rtcl: r708 | coke++ | trunk/runtime/builtin/puts.pir:
Fix bug introduced with new [socket] impl.
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 ?
in your case, you probably wanted the --hard from the beginning. that would have been less headache, methinks
Coke Yes. I do wish that interactive rebase hadn't eaten my commits in the first place.
06:23 chromatic joined
Coke that's the sort of error that I don't think could have happened with svn. =-) 06:24
dukeleto coke: interactive rebase is a delicious self-animated chainsaw :) 06:25
Coke iwbni packy's script stopped you /before/ you shot yourself inthe foot. 06:27
(gitsquash, on the wiki)
dukeleto Coke: his script is a little scary 06:28
coke: i use the bash function grh ()
{
git rebase -i head~$1
}
so i manually inspect the last few commits and see how many i want to rebase 06:29
coke: more safer :)
Coke the problem was that there was already an interactive in progress.
dukeleto so rebasing the last 5 commits is "grh 5"
coke: rebase has screwed me too, but reflog always saves me
Coke mm. glad I know about it. =-)
I bet this [seek] and [tell] net me zero spec tests... 06:30
dalek tracwiki: v10 | dukeleto++ | GitCookbook 06:41
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
dukeleto coke: i updated the git cookbook, please review :) 06:42
bacek_at_work dukeleto: consider removing "git commit -a". It's way too dangerous. 06:46
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)
dukeleto bacek_at_work: i guess i live dangerously :)
bacek_at_work chromatic: svn is dangerous by it self :)
dukeleto bacek_at_work: i constantly look at "git status -a"
bacek_at_work: as well as having notification in your PS1 about local changes/etc. 06:48
bacek_at_work: i understand that -a could be dangerous for newcomers, but i use it instead of having to "git add" each file.
bacek_at_work: i make many incremental commits, so -a is not dangerous for me
Coke dukeleto: IWBNI if it also mentioned cherry-pick, but otherwise, nice. 06:49
bacek_at_work: for folks coming from svn, git commit -a is just fine.
dukeleto coke: ah, yes. forgot
Coke git add/git commit is the next level of complexity after that. 06:50
dukeleto++
Coke needs to get to bed. :|
dukeleto git is serious about data loss :) 06:55
dalek tracwiki: v11 | dukeleto++ | GitCookbook 06:56
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
06:58 Khisanth joined 07:02 mberends joined 07:03 Zak joined
dalek tracwiki: v12 | dukeleto++ | GitCookbook 07:06
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
tracwiki: v13 | dukeleto++ | GitCookbook 07:10
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
chromatic Does that mean Coke is a Git convert now? 07:11
dukeleto chromatic: looks promising :) 07:13
chromatic Next up, whiteknight and NotFound. 07:14
07:26 MoC joined
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
07:33 iblechbot joined
moritz looking at 'git log' often helps me with that 07:34
mikehh yeah - but I don't have to look with svn :-}
moritz aye 07:35
they had to let svn be better at one thing, at least ;-)
but you know you can get sequence numbers out of git 07:37
with git-describe
which gives you last tag + commits since last tag + short SHA1
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
mikehh: i have that aliased to "git plog"
mikehh well I've got git in my git repository :-}
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
plus perl, rakudo, cardinal, lua and others 07:41
mind you I've got llvm, clang, parrot, partcl, and a few others in svn 07:42
and some ubuntu stuff in bzr 07:43
which is also a good option to consider 07:44
purl okay, mikehh.
treed purl: forget which 07:46
purl treed: I forgot which
mikehh dukeleto: just updated cpanp and your BigRat module
dukeleto mikehh: whoa dude, you are on the bleeding edge :) 07:47
mikehh also DateTime::TimeZone
dalek tracwiki: v14 | dukeleto++ | GitCookbook 07:53
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
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
moritz: github.com/leto/Util/blob/master/bi...ate_parrot <-- could use some generalization and love, but works for me :) 07:56
moritz nice :-)
dalek tracwiki: v15 | dukeleto++ | GitCookbook 08:07
tracwiki: trac.parrot.org/parrot/wiki/GitCoo...ction=diff
08:18 HG` joined 08:27 bacek joined 08:37 masak joined
TiMBuS do threads work in rakudo yet? 08:40
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:42
and i recently read something about threads in parrot being sorta crash prone in hll's? or something? 08:43
moritz TiMBuS: that's right. There's a ticket for that, which contains patches 08:44
which need testing and review
TiMBuS i see 08:45
kyle_l5l I'm still slowly chugging away at threads+hlls. 08:52
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:54
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: gist.github.com/183599 08:55
installing from source or ports doesn't seem to fix it
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41171 - Ubuntu 9.04 i386 (g++)
kyle_l5l moritz, sure
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:56
bacek dukeleto: erm... Really? They don't have single test??? OMGBBQ! 08:59
o hai, btw 09:00
09:00 athomason joined
bacek jrtayloriv: ping. 09:01
09:01 mberends joined
mikehh rakudo (62879bb) builds on parrot r41171 - make test / make spectest (up to 28212) PASS - Ubuntu 9.04 i386 (g++) 09:09
rakudo - t/spec/S03-operators/arith.rakudo - TODO passed: 131
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 09:19 einstein joined
mikehh partcl r708 builds on parrot r41171 - make test random failures with segfault - Ubuntu 9.04 i386 (g++) 09:25
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:28
partcl - the file updated above is src/tclsh.pir 09:30
decnum_dynpmcs r181 builds on parrot r41171 - make test PASS - Ubuntu 9.04 i386 (g++) 09:49
cardinal builds on parrot r41171 - rake teat:all - same 3 failures - ubuntu 9.04 i386 (g++) 09:50
ok - I am going to reboot to amd64 now - bbl 09:51
10:07 HG` joined 10:17 mikehh joined
dalek rrot: r41172 | bacek++ | trunk/src/jit/i386 (2 files):
[cage] Make headerize happy about JIT-generated functions
 10:40
10:50 bacek joined 10:54 iblechbot joined
dalek TT #973 closed by bacek++: Review content of src/gc/alloc_register.c and src/call/context.c and merge ... 11:14
11:57 bkuhn joined 12:07 whoppix joined 12:08 whiteknight joined 12:14 ruoso joined
whiteknight good morning #parrot 12:14
Tene: ping 12:15
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
Coke dukeleto: svn on OS X, there's a .dmg installer for that. 12:40
Infinoid (cleaning up IO)++
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.
Is this intentional?
whiteknight Coke: Shouldn't be 12:41
Coke Socket vs. FileHandle , 'send' vs 'print', e.g.
whiteknight my "vision" for that whole system is much more unified then it is currently
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
so PIR code would treat all IO Handle objects identically
and we can properly subclass them
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
Coke whiteknight: any comments on my readline for socket RFC?
whiteknight #?
purl # is moderated
Coke "recent"?
checking.
TT #996 12:44
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:45
12:46 Austin joined
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:46
Coke waaaafar thin. 12:49
partcl parrot problems is code.google.com/p/partcl/issues/lis...%20Summary 12:55
shorten that? 13:06
purl That URL is at xrl.us/bfjj37 [code.google.com]
Coke no, partcl parrot problems is xrl.us/bfjj37 [code.google.com] 13:07
purl okay, Coke.
Coke (whee, lazybot)
dalek kudo: 872cd0d | pmichaud++ | docs/spectest-progress.csv:
Revise spectest-progress.csv results since August 2009 release to

  (moritz++)		 13:12
kudo: 5960161 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 436 files, 14268 (69.3% of 20599) pass, 0 fail
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:28
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:29
s/I can/I can't/ ... 13:30
particle jrtayloriv: can you make the memset optional, perhaps done only by a -D flag? 13:40
13:40 NotFound joined
whiteknight jrtayloriv: throughout the GC it checks if pointers are null and marks them if not 13:40
particle that will give us something to play with 13:41
whiteknight so we can't have a pointer with uninitialized garbage
particle whiteknight: so it's not like our setting ints to 0 or strings to null on init? 13:42
it's actually a 'feature' of the gc?
jrtayloriv whiteknight, OK, thanks. 13:43
whiteknight jrtayloriv: now, if we could do it in a fast and consistent way without memset, that would be fine too 13:46
NotFound As Coke said yesterday, I prefer some slowness than random segfaults. 13:48
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
so if pmc_new is already initializing all the necessary fields, we don't also need to memset inside the GC
NotFound Don't forget pmc_new_noinit
whiteknight they both probably call something like Parrot_gc_new_pmc_header 13:50
13:51 PacoLinux joined
Austin NotFound: Sadly, we have both. 13:52
NotFound Austin: but the balance between the two can be easily made a lot worse. 13:54
13:55 HG` joined
Austin Cheer up, they told me. Things could always be worse. 13:55
So I cheered up. And sure enough, things got worse.
whiteknight Austin: talking about performance problems?
Austin No. Performance problems plus random segfaults.
(Except they're not random. They always come at the end.) 13:56
whiteknight we're working on it :)
Austin I don't let it get to me. I'm feeding bad data to PCT, so it segfaults. 13:57
It's faster than printing an error message, I guess.
NotFound Austin: they're not random now, after adding some memset and several other things.
Austin I know they're not random. They always come at the end. 13:58
13:58 particle joined
NotFound In Eval.destroy, in all cases I backtraced. 14:00
pmichaud for me, I generally get segfaults at the end whenever I have a :load/:init sub that throws an exception. 14:02
(there are many ways in which this can happen.)
14:04 skv joined
moritz planetsvg.com has a nice feature - a feed from a google search for svg blogs 14:04
I wonder how hard or easy it would be to make such a thing for parrot or Perl 6 14:05
afk
14:05 Andy joined
NotFound pmichaud: that makes sense. If eval gets invalid packfile structures from imcc, it can easily fail while trying to destroy them. 14:06
Austin Whiteknight: fwiw, I upgraded to 41166 with no problems y-day. 14:07
whiteknight that's good!
pmichaud See TT #833 for more about imcc and exceptions 14:09
14:13 theory joined
whiteknight yeah, #833 is the bane of my existance 14:13
I swear by the power of greyskull that I will fix it one day 14:15
NotFound I think I have an attempt of fix somewhere, I'll try to find it later today. 14:22
whiteknight A fix wouldn't be hard to make. the problem I found was getting people to agree on which fix to make 14:23
because all of them would imply certain significant architectural changes to get right 14:24
NotFound Well, letting it break the VM is hardly an architecturaly desired state of art. 14:25
whiteknight agreed
Austin Do the one that involves taking things out. 14:27
If they both do, then do the one that involves taking the most things out.
whiteknight Austin: any solution is likely going to require adding. And lots of adding 14:30
NotFound whiteknight: not so much. Just catch exceptions, so some cleanup, and rethrowing. The "some cleanup" part may be tricky, though. 14:31
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
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
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
NotFound whiteknight: a C exception handler gets rid of that by doing a longjmp
whiteknight right, so we have to do more differentiating between C and PIR exception handlers 14:34
14:34 payload joined
whiteknight It's all very doable, but non-trivial and worth having a good plan in place beforehand 14:35
NotFound whiteknight: we don't need to solve the general case just to catch failures inside load_bytecode or eval. 14:36
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
Austin Maybe not. 14:38
whiteknight creating two at startup is prohibitive
Austin If the bootstrap interpreter is only doing one thing, it can be "static".
NotFound Interpreter creation and destruction are labyrinths
whiteknight that too
there is a lot of refactoring that needs to happen in the startup code, and a lot of opportunities to streamline and optimize 14:39
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
cotto hi 14:41
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
whiteknight we need to go through all this code with a goddamn hatchet 14:51
but it isn't a sufficient pain point yet that it's on the priority list
dalek rrot: r41173 | NotFound++ | trunk (2 files):
[cage] simplify FPA.get_repr and improve his test
 15:07
cotto NotFound, why not just rip out get_repr? It's deprecated. 15:08
15:08 davidfetter joined
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
NotFound I don't see any mention of get_repr in DEPRECATED.pod 15:11
particle it's mentioned in the pdd 15:12
i don't know if it's in deprecated.pod
or whether there's a ticket 15:13
15:15 AndyA joined
particle Coke: look who's here 15:15
NotFound "candidate for deprecation"? 15:17
15:28 JimmyZ joined
cotto NotFound, my mistake. For some reason I thought it was on the way out. 15:28
I'm glad I found that out before deleting all the get_repr VTABLEs. 15:29
It's kinda like having Stupid Fingers except it's in my head. ;)
NotFound cotto: no problem... Do you have any Vista system with SMB2 open? }:) 15:32
cotto nope 15:33
15:33 mikehh_ joined
cotto I don't start work until Monday and I can't imagine any reason to have a Vista box at home. ;) 15:34
NotFound cotto: I have one that came with the box, I rebooted with Vista yesterday just to see the BSOD X-) 15:40
cotto A BSOD? In Vista? I'm shocked. 15:42
You should send an electronic message of some sort to the manufacturer of that product. 15:45
15:45 SMSD joined
NotFound cotto: Who is that, BuenaVista? 15:46
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:47
jrtayloriv SMSD, see www.sidhe.org/~dan/blog/archives/000189.html and www.usenix.org/events/vee05/full_p...-yunhe.pdf 15:49
cotto is going to work orientation. 15:51
afk &
SMSD jrtayloriv: thanks but i had seen them sir....are there any other resources regarding this matter? 15:53
particle also docs.parrot.org/parrot/latest/html/...w.pod.html
smsd: google is your friend
e.g: docs.parrot.org/parrot/latest/html/...w.pod.html 15:54
er
www.usenix.org/events/vee05/full_pa...-yunhe.pdf
SMSD particle: yes thanks
particle oh, right, jrtayloriv++ sent that already
dis is also a register-based vm (memory transfer vm, they call it) 15:55
purl okay, particle.
SMSD jrtayloriv: i am not able to access the sidhe.org site
jrtayloriv dis is also "You dissin' me? You're messing with the wrong bot." 15:57
purl okay, jrtayloriv.
15:58 mikehh joined
SMSD thanks for the help guys 15:59
16:00 SMSD left
Tene whiteknight: *obviously* the solution to the startup problem is to make the GC swappable at runtime. 16:00
whiteknight: I'd love to help with IO stuff.
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.
whiteknight: Explain more?
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
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
we need to unify all that so we call one set of functions for all IO handle types
Tene Ah.
16:04 davidfetter joined
Tene Yes, that would be nice. 16:04
Socket is... less good than it could be. :)
whiteknight This means that all IO handle types will have a standard set of methods (write, writeline, read, readline, open, close, etc) 16:05
16:05 payload joined
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
this also means that we get everything for everybody: buffering for sockets and pipes, for example
Tene :) yay 16:07
Can you write up a list of what the API is?
16:09 bkuhn joined
Coke returns from offsiting. 16:24
(interpreter creation) - please check out tcl's [interp] for all the things I need an interpreter-like thing to do. 16:27
msg AndyA Cheers!
purl Message for andya stored.
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:28
16:36 hercynium joined 16:57 whiteknight joined
Tene Coke: No, I have no idea how to get that behavior without asking for it; sorry. 17:08
Coke ok. no worries. no longer a problem to be solved. 17:09
Tene kk
Coke ... this temporary blindness is of some concern, however.
(just those dilating eyedrops. woof.)
17:12 joeri joined 17:46 bacek joined
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
erm... Andy Dougherty.
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
I would be much more in favor of deprecating Fixed*Array types
18:02 darbelo joined
whiteknight maybe I'm just missing something 18:08
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
18:14 chromatic joined
whiteknight To be fair, an "array" by definition only claims to have keyed indexing 18:15
something that is more then an array should also implement an additional interface
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 ....
whiteknight japhb: that's one of the "problems" I brush aside :(
japhb That's a big problem. :-) 18:16
Tene japhb: just drop support for :immediate subs!
whiteknight not necessarily.
Instead of invoking IMCC once, we can iterate over IMCC. It returns the "next" sub as soon as it's time to return it
japhb What about running the compile/execute as continuations or as a bytecode generator that produces chunks at a time ... ?
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.
whiteknight it's a problem, but not impossible to get past
The bigger issue is that :immediate subs are used to create PMC constants in the packfile
japhb OK, as long as you're open to doing chunking at least, my objection is gone.
>< 18:18
whiteknight so then we need to handle that in some way
japhb I forgot all about the packfile mess, sigh.
whiteknight that's the official name for it
18:26 payload1 joined 18:28 hercynium joined
Coke whiteknight: please show me in the docs where "does array" means anything at all. =-) 18:34
whiteknight Coke: nowhere.
purl nowhere is the method for calculating significant wave height using an FFT on pressure data. or Dodge City, KS
whiteknight that doesn't mean it shouldn't mean something 18:35
18:35 mokurai joined
Coke right. As long as it means what I want, that's fine. =-) 18:35
whiteknight A lot of languages do differentiate between a simple "array" and a "stack" or "queue" 18:36
particle does is in the pmc pdd iirc 18:39
whiteknight this is all probably an allison question. 18:42
dalek ose: r101 | Austin++ | trunk/library/close/Compiler/Config.pm:
Commented out NOTE and DUMP calls in Config.pm
 18:44
ose: r102 | Austin++ | trunk/library/close/Compiler/ (2 files):
Added missing .pm files
chromatic I'm not sure why there's such a heated discussion; it all comes down to complexity for me. 18:47
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
18:48 mberends joined
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.
chromatic: but also: I'm specifically talking about the case where someone /hands/ you an aggregate. 18:49
not one where you're picking the right PMC for the job.
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.
particle whiteknight: implement pmroles, and the world is your oyster 18:53
whiteknight pmroles? 18:54
dalek ose: r103 | Austin++ | trunk/src/parser/expression (2 files):
Fixed asm-expr / postfix-call issue
 19:05
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:19
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-)
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)
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:21
NotFound sub lier is also Undef ? 19:22
sub but Undef ?
19:37 hercynium joined 19:39 quek joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41173 - Ubuntu 9.04 amd64 (g++) 19:39
Coke chromatic: so at this point I'll settle for making the documentation consistent. 19:41
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.
Coke chromatic: "can't we all just get along?" 19:43
(oh wait, we can.)
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?
particle windows + llvm = no joy
chromatic Really? 19:45
Coke particle: how well is jit working for you now? =-)
whiteknight so we have a JIT system that supports multiple backends
particle the msvc port is experimental
NotFound And the current parrot jit is mature? 19:46
whiteknight let's not compare apples to bullshit
particle gee, thanks for that.
chromatic particle, does the JIT give measurable performance improvements on Windows? 19:47
particle i don't know, i haven't measured 19:48
chromatic Okay.
particle is there a pre-existing jit that works on all our target platforms?
chromatic I don't know that.
whiteknight I have to check
particle a large percentange of dynamic language users use windows
whiteknight libJIT might. Lightning might
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
particle no matter how much you ignore it or deride it
make the jit interface pluggable
then we can use best-of-breed jits on various platforms 19:50
whiteknight that's my entire plan, in a nutshell
particle and you can start with llvm first
whiteknight pluggable = better
Coke particle: according to llvm.org/docs/GettingStarted.html, there is llvm for windows.
particle pluggability at parrot core is the only way we survive long term
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
especally if our plugin systems are better then GCC's for instance
Coke yes. much like all of parrot.
NotFound We can write a jit plugin that does nothing, as a start
whiteknight NotFound: better yet, we can use the one we have :)
NotFound whiteknight: if you are masochistic enough... ;) 19:52
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
whiteknight so all we need to do is output additional forms for JIT engines to use
particle oh, and if the llvm-on-windows answer is to introduce llvm folks to ms folks, i'll gladly help
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?
whiteknight where "hell of a lot of C code" can mean many different things
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
and if PCT, then there's a bootstrapping step 19:57
darbelo Also: PCT is better, Perl5 is faster.
whiteknight Perl5 is faster *now*
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
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.
TimToady phone
NotFound whiteknight: if parrot run pbc, we can have a pbc pir compiler
whiteknight exactly 20:00
einstein the svn certificate gives the following message "The certificate hostname does not match."
whiteknight now imagine how much simpler (and FASTER!) Parrot startup will be without IMCC in there
Tene einstein: where are you getting that specifically?
NotFound einstein: With which hostname?
einstein svn.parrot.org:443 20:01
Tene einstein: it works for me...
NotFound Also for me
darbelo whiteknight: pirc needs some more love before we can kill IMCC.
NotFound darbelo: pirc is also lexx/yacc based 20:02
purl okay, NotFound.
whiteknight darbelo: what we were talking about is not using IMCC or PIRC at all
einstein it did work in the past but now it comes with this error
whiteknight have a PCT-based compiler only
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.
whiteknight Tene: YES! Exactly
darbelo Oh, the one bacek had on github? That sounds cool. 20:04
NotFound Will not be a good idea to use different names?
whiteknight I was thinking about having pluggable front-ends. We set up a standard API and people can plug in whatever frontend they want
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.
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
NotFound We need a PluggablePMCArray X-)
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.
whiteknight and program Parrot natively in Perl5
treed "Everything Pluggable" is a good goal. 20:07
Tene plugs treed.
whiteknight treed: it's also a ticket!
treed It demonstrates that you're using encapsulation.
NotFound And for fans we can sell a "Parrot Unplugged" special edition
treed Tene: :o
whiteknight allison++ 20:08
(Great email she just sent out, everybody should read it
Tene Just now? After the jit one?
treed The JIT one?
treed doesn't have anything newer than that.
MoC "Parrot, a Virtual Machine for running dynamic languages. And for building Virtual Machines running dynamic languages." 20:09
;)
whiteknight parrot kicks ass, and will kick more in the future 20:12
NotFound You'll be assimilated!
Tene NotFound: pluggably? 20:13
NotFound Tene: that's for 3.6 at least 20:14
Pluggable world
20:16 theory joined 20:17 theory joined 20:28 HG` joined
whiteknight So what we need now is a series of tickets outlining what we need to do to make JIT happen 20:28
(1) Design lorito 20:29
(2) Lorito parser with multiple backends (C code in several formats, LLVM code)
(3) redirection --runcore=jit to the fast core
(4) rip out the current JIT system
(5) read LLVM documentation like mad men 20:30
(6)???
(7)PROFIT!
moritz join the llvm developers IRC channel ;-)
(if they have one)
whiteknight I dont know. They have a mailing list that I am already on
20:30 dukeleto joined
NotFound (8) Make a C compiler with PCT 20:31
Tene #llvm on irc.oftc.net
I'm idling there now.
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.
particle i'll take #7
darbelo I volunteer for 4 20:33
chromatic #3 waits until after 1.6.
darbelo likes ripping out stuff.
whiteknight chromatic: we can make a branch ow and merge it after 1.6
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?
Forget it, 1.6 is near enough 20:35
purl NotFound, I didn't have anything matching it, 1.6 is near enough
particle whiteknight: it's like a 10 line patch, including docs. no need for a branch
whiteknight NotFound: 1.6 is out in less then 1week!
particle #3, that is
whiteknight particle: but we can start ripping out the JIT code too
We need to scalpel out everything but the NCI thunk generator
chromatic I can make a local Git branch. 20:36
.o0O scaryy O0o.
whiteknight you git people and your black magic!
particle could you instead update news and platforms? :P
dalek tracwiki: v11 | chromatic++ | JITRewrite
tracwiki: added specific JIT replacement tasks and volunteers
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
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 :)
whiteknight platforms does need an update though
do we need a PCT-based C compiler for this? 20:38
or a C-generating backend?
chromatic A C-generating backend should handle it. 20:39
whiteknight I think Lorito will be easy enough to design now 20:40
dalek tracwiki: v12 | whiteknight++ | JITRewrite
tracwiki: trac.parrot.org/parrot/wiki/JITRew...ction=diff
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
Coke einstein: I think your browser might be overly anxious. (it's a multi-host cert, should be ok.) 20:41
whiteknight has to go home now. Later 20:42
20:42 bacek joined
einstein ok 20:44
20:46 quek joined
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:47
cotto Should we be reading the docs for all the jit libraries so we know that whatever interface we design makes sense? 20:53
20:54 quek left
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.
darbelo I gues that depends on how ll llvm is :) 20:56
Coke (llvm goes first) only if you assume that /someone/ read the docs and that their choice is sane. 21:01
(which I am, but just to be clear.)
darbelo Sanity is a pretty big thing to acuse people of, young man. 21:03
Tene Coke: you am sane 21:04
?
Coke I am assuming. 21:07
21:11 davidfetter joined 21:18 davidfetter joined 21:23 allison joined, davidfetter joined 21:26 fperrad left 21:35 joeri left 21:41 beta joined, beta left 21:49 bacek joined
bacek Good morning everyone except purl 21:49
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
darbelo Hmm. There is a bunch of broken 'testing only' functions in src/pmc_freeze.c wonder if I can rim them out... 21:52
bacek darbelo: kill 'em. KILLEMALL! 21:53
cotto darbelo, what he said 21:56
21:56 Zak joined
Coke mumbles something about six segfaults. 22:03
bacek Coke: I can't repoduce #967... 22:04
22:05 ruoso joined
Coke bacek: that's the one that notfound said he fixed in trac.parrot.org/parrot/changeset/40974 ? 22:06
bacek Coke: yeah... Can we close ticket? 22:07
NotFound Uh, forget to put a note in the ticket, sorry
purl NotFound, I didn't have anything matching to put a note in the ticket, sorry
Coke bacek: sure.
partcl parrot problems? 22:08
purl partcl parrot problems is xrl.us/bfjj37 [code.google.com]
Coke (anything in that list that says "segfault" is probably still open.)
Tene partcl parrot successes?
bacek NotFound: can you close ticket? I'm not going to steal your karma :)
Coke partcl parrot successes is <reply>*cricket noise* 22:09
partcl #107 might be the cause of mikehh's random segfaults.
(and it's packfile goodness!) 22:10
-> noms
bacek hate packfiles...
NotFound bacek: done 22:12
bacek duff? 22:13
purl duff is perljam
dalek TT #967 closed by NotFound++: segfault in utf8_set_position 22:15
darbelo svn diff | wc -l 346
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.
NotFound darbelo: agreed, but that in particular may be related to the Eval.destroy thing 22:18
The same packfile may be destroyed from several places. 22:19
darbelo Oh, you were looking for a *specific* evil. My bad.
NotFound All evil related with dying at exit, I mean
bacek tclsh is crashing under valgrind... Hm... 22:21
22:23 Whiteknight joined
darbelo Hmm. nopaste.pl needs WWW/Mechanize.pl, wonder if that's in ports. 22:26
Andy it should install with CPAN no prob
but it's likely to be in ports.
darbelo Ah, it is. Installing now. 22:27
NotFound I think I have a fix, evne if ugly
darbelo Andy: using cpan can complicate upgrades, I'd rather use ports when there's one available.
Andy understood 22:28
dalek rrot: r41174 | bacek++ | trunk/src/pmc/continuation.pmc:
[cage] Don't try to mark not-fully-construted Continuation.
 22:29
rrot: r41175 | bacek++ | trunk/include/parrot/compiler.h:
[cage] Fix compilation without clang and with g++.
darbelo All tests successful. 22:30
purl darbelo: that's because you wrote only one test, slacker!
dalek rrot: r41176 | NotFound++ | trunk/src/pmc/eval.pmc:
[core] quick and dirty fix for TT #995
 22:32
NotFound Uh, a little too dirty 22:33
22:33 bacek_ joined
nopaste "darbelo" at 200.49.154.172 pasted "Kill broken functions with fire. bacek++ cotto++" (347 lines) at nopaste.snit.ch/17895 22:35
chromatic Whoa, time to optimize tools/dev/pprof2cg.pl. 22:36
dalek rrot: r41177 | NotFound++ | trunk/src/pmc/eval.pmc:
[cage] fix c++ failure from r41176
darbelo bacek_, cotto : Killed 'em all. Want to review/commit nopaste.snit.ch/17895 ? 22:37
bacek_ darbelo: looking
darbelo: make headerizer? 22:38
darbelo Left it out of the patch. You should run it if you apply it.
cotto chromatic, what do you suggest?
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.
cotto chromatic, are you just noticing how slow it is?
chromatic Yes.
It'll take a while to burn through 168MB of logs, but even still...
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.
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.
bacek_ darbelo: no worries.
22:43 rg1 joined
chromatic We do get output though.... 22:44
NotFound Uh, no, that fix is not enough to solve them all.
chromatic Perl6Object::Build is *expensive*.
dalek rrot: r41178 | bacek++ | trunk/src/pmc_freeze.c:
[cage] Remove unused functions from src/pmc_freeze.c. Patch courtesy of darbelo++
 22:46
Whiteknight I didn't know chromatic knew perl5! I thought his blog posts were all hypothetical! 22:55
somebody needs to get darbelo a damn commit bit!! 22:56
bacek_ Somebody have to submit CLA!
darbelo Sent it already, but it's way more fun to make you guys commit stuff for me. 22:58
;)
cotto I'll commit you 23:00
to an institution ;)
pmichaud I hear that marriage is a great institution :)
bacek Whiteknight: I'm start thinking about major GC "clean-up". 23:03
darbelo Clean it with fire?
cotto hands a machete to bacek
bacek darbelo: yeah. Something like this :)
bacek rejecting cotto's machete and get flamethrower. 23:04
23:05 Hunger joined
darbelo applies for a patent on the 'flame-throwing machete' 23:05
Whiteknight bacek: cleanup or implementing a new core? 23:07
or both :)
bacek Whiteknight: clean-up first, generational compacting gc second :) 23:08
We can have is almost for free with new attributes allocation schema. 23:09
23:09 cognominal joined
bacek mprotect? 23:09
purl: mprotect? 23:10
purl bacek: no idea
bacek bah. Useless girl...
cotto darbelo, good patch. 23:11
23:12 jan joined
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:12
NotFound PackFile segments direct usage are planned to be replace by his PMC counterparts? 23:13
bacek NotFound: TT#504.
darbelo cotto: Not a big deal, really. It's just removing stuff. I'm good at that :)
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
compacting the attributes pools won't help anything
bacek Whiteknight: it will. (more)
23:15 Hunger joined
bacek If we compact "old" ATTRibutes into single set of pages we can mprotect them for writing (more) 23:15
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.
bacek In "mark" phase we will just ignore "clean" old pages.
Whiteknight bacek: but the PMCs aren't marked like that, and we don't mark attributes 23:17
darbelo NotFound: fsvo soon...
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.
Whiteknight bacek: we don't mark the attributes structure itself, we mark the thigs that it points to
bacek Whiteknight: ah. Yes.
darbelo NotFound: True. 23:19
bacek So, when "attributes structure" belong to "clean old" page we can skip marking of pointers.
cotto This is charming. After splitting the profiling runcore off into a separate file, it appears to run rakudo hello world 10x slower.
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
NotFound cotto: Lack of global inlining ability of the compiler?
bacek Whiteknight: yes. I'm not going to remove this phase.
cotto NotFound, that wouldn't explain why it's running 10x more PIR instructions. 23:21
NotFound cotto: uh... no 23:22
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
bacek And it's $dayjob time.
23:28 hercynium joined
cotto It's odd because that commit did nothing but copy a couple files and delete some lines, apart from the makefile updates. 23:29
darbelo cotto: a change in rakudo maybe? 23:30
cotto nope. I've been testing against the same rakudo version. 23:31
s/version/revision/
23:31 kyle_l5l joined 23:32 kid51 joined
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 ...
pmichaud maybe some change to vtable handling? 23:34
i.e., things that weren't being handled by PIR vtables in one runcore are being handled that way in another?
(yes, I'm grasping at straws)
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:35
pmichaud oh yes, I was going to see how parrot changes since 1.5.0 have affected rakudo spectest timings 23:36
I'll do that real quick
chromatic I have an idea about PMC recycling in generated code, but that'll be an experiment on my part.... 23:37
cotto ok. it looks like the slowdown happens in the revision before I split out the profiling runcore 23:39
this'll be fun
darbelo cotto: which rev is that? 23:40
cotto darbelo, r41150
kid51 smolder down again? 23:42
dalek rrot: r41179 | mikehh++ | trunk/src/pmc_freeze.c:
codetest failure - pod syntax
darbelo "* Move SQLite3.pir from ext/ to library/ so it can be installed"? That r41150? 23:43
cotto darbelo, that's the revision right *before* I split off the runcore. 23:45
darbelo Oh, I was asking about the slowdown. It happens before splitting, right? 23:46
cotto darbelo, that's what I'm trying to figure out. 23:47
darbelo cotto: do you build optimized? 23:49
cotto darbelo, no, but the difference isn't attributable to that. --optimize speeds profiled rakudo hw from ~3m to ~2m 23:50
(when the slowdown is in effect) 23:51
darbelo That's r41140 off the hook then.
cotto ? 23:53
oic
darbelo or maybe not, I have no clue when NDEBUG is (or isn't) #defined. 23:56
cotto I'll find out. 23:57
41120 is fast
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
23:58 skv_ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!