Parrot 2.8.0 released | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets; remove deprecated items (especially CodeString);
Set by moderator on 24 September 2010.
bacek_at_work then we have to handle RPA from gen2 specially to properly mark PMC from gen1 00:00
dukeleto GeJ: our github repo is a one way mirror, from svn to git, currently. You can create branches with a slash in them, tho, of the form username/branch
bacek_at_work gc.write_barrier will put RPA into "root set" for next mark
...next mark of gen1
GeJ dukeleto: Okay. I was thinking about something along those lines. I just wanted to be sure. Thanks. 00:01
dukeleto GeJ: we have a script now that syncs svn branches to github, and also deletes old branches, so if you want your branch to survive the sync process, it needs a slash in it
GeJ: there are some emails in the parrot-dev archives about it
cotto So the write barrier for your gc ensures that any PMCs that get written to will be in the same generation? 00:02
dukeleto GeJ: we are switching to git "soon", so it is good to play around with the repo, keep it up to date, etc. But the easiest way to commit your work, and apply small patches, is directly with svn. There is git-svn, but it has a steep learning curve.
GeJ: if you look at the branch list, all the ones with slashes are pure git branches, and all the others are current svn branches 00:03
00:03 kid51_at_dinner is now known as kid51
dukeleto GeJ: i have a branch called leto/git_docs that has the git documentation I have been working on 00:04
dalek tracwiki: v7 | cotto++ | GitHubTracPluginTests
tracwiki: trac.parrot.org/parrot/wiki/GitHubT...ction=diff
dukeleto GeJ: github.com/parrot/parrot/branches
GeJ: from that page, you can easily get a diff of any branch to master 00:05
bacek_at_work: is there a way to infer where write barriers need to be algorithmically, or is it a manual process currently? 00:07
00:08 ash_ joined 00:09 ash_ left
cotto dukeleto, it sounds like you want to parse c. 00:11
cotto mumbles something about lorito
dukeleto cotto: just wondering if it is possible to figure out beforehand, without parsing 00:12
00:12 whiteknight joined
plobsing is there any plan on how we intend to handle systems where shared objects are impossible or undesirable? 00:16
cotto in theory it might be, but you never know when some wacky PMC might violate your assumptions
plobsing dukeleto: some generational systems are more precise by wrapping all assignments with guards (similar to refcounting) 00:17
GeJ Hello whiteknight. 00:19
whiteknight hello GeJ
00:26 kid51 left
luben dukeleto, may be a good first approximations is to put wb on all vtables that have SETATTR in their code 00:27
plobsing luben: what about vtables that create new PMCs themselves? and what about vtables that call functions that SETATTR? 00:29
00:29 davidfetter joined
luben if vtables calls a function with SETATTR in it, may be the WB should be invoked explicitly where the SETATTR is called 00:31
plobsing if you do that for functions, why not do it everywhere? 00:32
luben because most of the time SETATTR is in a PMC and most of the time the PMC is in the youngest generation, so it does not need WB. About the first case - "vtables that create new PMCs themselves" : my understanfing is that if the PMC will mark the newly created PMC as alive in GC trace, the vtable that creates it should be behind WB 00:35
plobsing sounds like premature optimization with 0 evidence used to support a special case. I really dislike special cases. 00:36
luben its just another manner to implement write barriers - with its cons and pros 00:39
plobsing what I'm saying is that it should all be one way or all the other. either you have to mark your writes in vtables or you don't in functions. 00:40
luben the easier solution is just to call write_barrier is SETATTR macro
plobsing, yes, I agree
but there are functions that SETATTR that are not invoked from vtables 00:41
00:44 ruoso joined
dalek rrot: r49373 | plobsing++ | trunk (5 files):
calloc can return null
 00:48
00:48 Andy left 00:52 dngor joined 00:53 dngor_ left 01:11 kid51 joined
dalek tracwiki: v8 | cotto++ | GitHubTracPluginTests 01:13
tracwiki: partial test results and minor fixes to the tests
tracwiki: trac.parrot.org/parrot/wiki/GitHubT...ction=diff
01:24 Andy joined 01:32 davidfetter left 01:34 kid51_ joined 01:36 PhatEddy joined
PhatEddy kid51: ping 01:37
01:37 kid51 left
kid51_ PhatEddy pong 01:39
01:39 kid51_ is now known as kid51
PhatEddy Thx, I am looking at proposing a patch for part of the rakudo build process under win32 that uses backticks "`". 01:41
kid51 If you are proposing patches for Rakudo, you probably want #perl6 on irc.freenode.net 01:42
PhatEddy Thx - will try there.
kid51 or: open an RT for them via: rakudobug@perl.org 01:43
02:12 whiteknight left
GeJ clock? 02:13
aloha GeJ: LAX: Tue, 19:13 PDT / LON: Wed, 03:13 BST / MAD: Wed, 04:13 CEST / NYC: Tue, 22:13 EDT / SYD: Wed, 12:13 EST / TOK: Wed, 11:13 JST / UTC: Wed, 02:13 UTC
02:20 PhatEddy left 02:29 kid51 left
dalek rrot: r49374 | plobsing++ | trunk (5 files):
[C89] eliminate and add test against trailing commas in enums
 02:29
02:35 janus left, theory joined
dalek rrot: r49375 | plobsing++ | trunk (2 files):
make new codingstd test a little more codingstd conformant
 03:03
rrot: r49376 | plobsing++ | trunk/compilers/imcc (2 files):
eliminate useless includes

this prevents lex from defining INT{8,16,32}_{MIN,MAX} on non-C99 platforms that still define them somewhere		 03:20
03:31 janus joined
dalek thub-trac: 33e2770 | cotto++ | github/github.py:
fix commit message processing
 03:44
dukeleto i think the git documentation is mostly done. i am sure it can be improved, but the core of it is there now 03:48
plobsing dukeleto: you were looking into parrot on embedded systems, correct? 03:50
dukeleto github.com/parrot/parrot/blob/leto%...rkflow.pod 03:51
cotto dukeleto++
03:52 preflex left
dukeleto plobsing: yes. I haven't had time lately to mess with that, but I am very interested in it. 03:52
plobsing have you put any thought towards how to deal with parrot's addiction to DLLs (dynpmcs, dynops, etc...)?
dukeleto github.com/parrot/parrot/blob/leto%...nology.pod
Comments and questions about the git docs welcome. 03:53
plobsing: it is an issue for things like real-time operating systems
plobsing: i haven't really seen a good reason for dynpmc's
plobsing: dynops i can see, and if necessary, PBC can be created that includes dynops,IIRC. But what is the use case for dynpmc's ? 03:55
plobsing I think in a regular desktop system with multiple applications using dynpms, they may have value. But on an embedded system, you know beforehand what you need. 03:56
dukeleto plobsing: yes, i envision flavors of parrot, customized to different needs
03:56 preflex joined
plobsing But more important than use case, is the need for a workaround. There are systems out there that don't implement dynamic loading at all. 03:57
dukeleto plobsing: versions optimized for speed for desktop use and memory use for embedded systems
plobsing: i don't think RTEMS does dynamic loading yet, but I hear they are working on it. But yes, many don't.
plobsing: i could see somebody that doesn't have dynloading want, say, the Random dynop 03:58
plobsing: dynops can be compiled into parrot if necessary, right? 03:59
plobsing MINIX doesn't seem to implement dynamic loading either. That's the only real blocker I've hit trying to port parrot to minix.
dukeleto plobsing: very interesting
plobsing: which version of minix are you using?
plobsing dukeleto: dynops and dynpmcs should be trivially statically addable (there has to be a real word for that) to core parrot 04:00
just dump the .ops or .pmc file into the appropriate folder. then reconfig in the case of dynpmc, ./ops2c --core in the case of dynops.
you would run into problems when you try to .loadlib 'perl6_ops' though. Need to hack parrot's dynamic loading to keep track of what we've static'd 04:01
uname -a => Minix 10.0.2.15 3 1.7 i686 04:02
that was the latest stable release when I downloaded it yesterday 04:03
dalek tracwiki: v9 | cotto++ | GitHubTracPluginTests 04:04
tracwiki: I guess that's why we have tests.
tracwiki: trac.parrot.org/parrot/wiki/GitHubT...ction=diff
dukeleto plobsing: do you have a ticket or branch for your minix work? perhaps we can ask some minix people to help 04:10
plobsing no branch or ticket ATM. all the changes so far have been small.
dukeleto plobsing: i've met one of the minix devs at the gsoc mentor summit, i can tell them we are interested in getting parrot to work on minix if I see him again 04:11
plobsing I wouldn't go making too many promises. I'm interested to the point where I'm willing to spend 5 minutes every couple of hours working on it. 04:12
dukeleto plobsing: does parrot compile at all on minix?
plobsing: that is why we ask for help :)
plobsing dukeleto: I get to the stage where it tries to compile dynpmcs. so yes, core parrot compiles. 04:13
modulo a couple hacks and workarounds which I am now cleaning up and commiting to core.
s/core/trunk/
dukeleto plobsing: showing them that we care enough about minix to try and make things works. I am not promising support, or anything like that.
plobsing: can you do a "make smolder_coretest" on your minix box, so we can get a smoke report for it? 04:15
plobsing heh, I'll try
dukeleto plobsing: perhaps after you commit to core, but whatev
plobsing: it would never have more than "experimental" support, but perhaps the minix folk are interested in having a VM for dynamic languages on their OS 04:16
plobsing: the only reason parrot works on openbsd is because of darbelo, it isn't supported. But I am glad that parrot (mostly) works on openbsd. 04:17
plobsing minix/openbsd/etc *shouldn't* be too hard to get working. they are posix after all. 04:18
dukeleto plobsing: devil is in the details 04:22
plobsing: if we had a buildfarm, small changes that break builds would be caught early, instead of lingering for a long time 04:23
cotto git++
git add -p FTW
plobsing the devil is in the details. minix is more posix compliant than any of the systems we "officially" support 04:24
and still doesn't quite work
dukeleto: are you suggesting that we have alternative oses in the build farm? the number of boxen/vmen could balloon quickly. 04:26
dukeleto plobsing: yep, the more the better
plobsing: hopefully a few for each supported OS and at least one for the experimentally supported OS's 04:27
dalek thub-trac: c4d8935 | cotto++ | github/github.py:
add a redirect to the hook so trac doesn't complain about sending an empty response
 04:29
thub-trac: 5e01436 | cotto++ | github/github.py:
fix config option check
thub-trac: f983969 | cotto++ | github/ (2 files):
fix hook code when the revmap is enabled
rrot: r49377 | mikehh++ | trunk/t/codingstd/c_enum.t:
fix perlcritic failure - remove hard tabs
 05:01
rrot: r49378 | plobsing++ | trunk (7 files):
test for timespec directly in stead of guessing at internal details of system headers
05:04 ash_ joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#311) fulltest) at r49377 - Ubuntu 10.10 beta amd64 (g++-4.5) 05:19
pre-config tests say No tests exist for configure step auto::timespec at t/configure/026-options_test.t line 18 and 05:25
No tests exist for configure step auto::timespec at t/configure/049-options_test_prepare.t line 16
plobsing mikehh: sorry, I couldn't think of any tests for it 05:27
it's more of an "obviously no bugs" rather than a "no obvious bugs" type software 05:28
but I'll try to think some up
mikehh and you got hard tabs in config/auto/timespec.pm - you want to fix that or shall I 05:29
plobsing arg. why is it that I always forget that vim autovars don't get applied when you're writing the file for the first time? 05:31
05:32 Andy left
dalek rrot: r49379 | plobsing++ | trunk/config/auto/timespec.pm:
[codingstd] tabs
 05:35
plobsing config/gen/platform/generic/stat.c contains BSD stat extensions. in fact, the only thing that separates win32 and generic is that win32 only expects posixy behaviour where generic assumes bsd extended. 05:40
that seems backwards
mikehh who is our OpenGL person 05:44
I'm getting a bunch of can't handle type messages in gen::opengl since I updated Ubuntu 10.10 beta amd64 05:47
plobsing NotFound? I think
mikehh NotFound: ping 05:48
plobsing I've been getting those type messages for months here on Arch.
hmmmm... praise tells a different story
japhb or Infinoid
cotto Mmmmm. Arch. 05:49
plobsing sorry to have mislead
mikehh I don't think it is serious, nut I am not getting them on Ubuntu 10.04 amd64/i386 (haven't set up 10.10 beta i386 yet)
but
dalek rrot: r49380 | mikehh++ | trunk/config/auto (2 files):
add svn properties
 05:52
mikehh plobsing: which ones are you getting, maybe I can fix it 05:59
nopaste "plobsing" at 192.168.1.3 pasted "opengl_warnings" (7 lines) at nopaste.snit.ch/23795 06:04
mikehh plobsing: yeah I am getting that one also some can't handle type 'longlong'; 06:09
let me have a look
sorear How are we on FreeBSD? 06:11
plobsing should work. last reported success was 20090720 though (according to PLATFORMS). 06:13
mikehh hmmn - OpenGL -> TT #1182 06:14
06:29 dalek left, PerlJam left 06:30 Util left, dukeleto left, hatseflats left, pmichaud left
cotto Say someone refers to a git commit id on the wiki ambiguously. What would be the right thing to do? 06:40
i.e. there are commits deadbeef100000000000000000000000000000000 and deadbeef200000000000000000000000000000000, and someone writes deadbeef. 06:41
s/i.e./e.g./ 06:42
06:44 dalek joined
GeJ statistically, that'd be really bad luck. 06:45
dalek tracwiki: v10 | cotto++ | GitHubTracPluginTests
tracwiki: add incomplete test for ambiguous git ids
tracwiki: trac.parrot.org/parrot/wiki/GitHubT...ction=diff
06:45 PerlJam joined 06:46 dukeleto joined
cotto Sure, but I want to dtrt should it happen. 06:46
06:50 Util joined 06:51 pmichaud joined 06:58 dukeleto left, dalek left, PerlJam left, pmichaud left, Util left 07:03 fperrad joined 07:19 ruoso left 07:24 dalek joined, PerlJam joined 07:25 dukeleto joined, pmichaud joined, Util joined 07:32 ruoso joined, hatseflats joined 07:38 theory left 07:43 tadzik joined 07:50 lucian_ left
cotto dukeleto, do you have any plans on writing the script to send messages to parrot-commits for git commits using github's api? 07:52
07:57 lucian joined 07:59 fperrad left
bacek_at_work cotto, there is service hook available to send mails. No need for any development. 08:01
cotto right, but does it send out the full diff?
bacek_at_work hmm. let me check
cotto dukeleto seems to think not
bacek_at_work Commit: 09ffd6797b5e59ffa3664f56d1e3071d7cef6013 08:03
github.com/bacek/aloha/commit/09ffd...1d7cef6013
Author: vasily.chekalkin <vasily.chekalkin@optusnet.com.au>
Date: 2010-09-29 (Wed, 29 Sep 2010)
Changed paths:
M lib/Bot/BasicBot/Pluggable/Module/Clock.pm
Log Message:
-----------
Add bit of documentation for email commit testing.
apparently not...
cotto It should be pretty simple. 08:04
They at least have a reasonably well-documented api. 08:05
08:15 lucian left 08:18 lucian joined 08:46 bacek left
dalek rrot: r49381 | bacek++ | branches/generational_gc/src/pmc/class.pmc:
Add write barrier call when we update Class.attrib_cache
 08:51
08:55 lucian left 08:57 bacek joined, lucian joined 09:24 ruoso left 09:36 ruoso joined 09:52 particle1 left 09:56 particle joined 10:07 ruoso left 10:27 contingencyplan left 10:35 lucian left 10:42 tadzik left 11:45 nwellnhof joined 11:50 whiteknight joined
whiteknight good morning, #parrot 12:08
12:13 mj41 left 12:15 mj41 joined 12:20 bluescreen joined 12:30 fperrad joined
dalek rrot: r49382 | plobsing++ | trunk/config/gen/makefiles/root.in:
avoid trying to build dynamic shared objects if we don't have dynamic linking
 12:32
12:38 p6eval left, p6eval joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#332) fulltest) at r49382 - Ubuntu 10.10 beta amd64 (gcc-4.5 with --optimize) 12:57
whiteknight mikehh: How is Ubuntu 10.10 beta? 13:08
13:19 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
mikehh whiteknight: couple of minor problems, nothing serious, a lot of good stuff 13:34
mikehh need to go shopping, bbl 13:38
13:41 tadzik joined 14:27 tadzik left 14:51 ash_ left 14:54 theory joined 15:22 nwellnhof left 15:23 ruoso joined 15:26 allison joined 15:29 nwellnhof joined 15:30 jsut joined 15:35 patspam joined, patspam left, jsut_ left 15:41 lucian joined 16:11 fperrad_ joined 16:13 fperrad left, fperrad_ is now known as fperrad 16:23 nwellnhof left
pmichaud Parrot hashes seem to be ordered again. 16:38
(nopaste coming)
gist.github.com/603084 # parrot hashes now act ordered? 16:43
whiteknight interesting 16:46
besides being weird, does this constitute a problem?
(I'm trying to figure out if this is a "bug" or "unintended feature") 16:47
dukeleto collapses into a stable eigenstate in #parrot 16:52
whiteknight takes dukeleto to a stable eigenhospital after he collapsed 17:01
probably from low blood eigensugar 17:03
pmichaud well, it's not truly a "bug", other than some people might start to inadvertently rely on it. 17:04
actually, it came up because someone was relying on the non-ordering behavior of hashes and was surprised when they all became ordered. 17:05
(relying on non-ordering behavior is equally as erroneous as relying on ordering behavior, imo)
whiteknight pmichaud: okay. I'm mostly concerned about the performance of it. Obviously we don't want the overhead of keeping hash entries sorted
maybe what we need to do is to change the behavior every release, so nobody relies on it either way :) 17:06
pmichaud right, that's why I'm primarily reporting it, in case it's indicative of a possible performance issue.
TimToady++ also notes that it can be a DoS issue, since hashes become predictable.
whiteknight ok, that part is more serious 17:08
TimToady well, whether it's potentially DoS depends on how it's implemented 17:13
whiteknight assume the worst 17:15
17:28 kid51 joined
kid51 msg plobsing When adding a config step, you should add a corresponding test file, e.g., t/steps/auto/01-timespec.t. 17:30
aloha OK. I'll deliver the message.
kid51 msg plobsing Also, adding a config step should probably have been preceded by post to list or by Trac ticket. 17:31
aloha OK. I'll deliver the message. 17:32
Coke I reiterate my question regarding the usefulness of those tests. 17:34
msg dukeleto - you should be a trac admin, and therefore capable of giving GeJ a commit bit. look at docs/project/meta*, give it a whirl, and let me know if you have any issues. 17:35
aloha OK. I'll deliver the message.
17:36 ruoso left
Coke (reiterate) but it's a very old question that's probably already been dealt with. Apologies. 17:36
17:36 kid51 left
Coke msg dukeleto - you weren't a trac admin, but are now. 17:37
aloha OK. I'll deliver the message.
dukeleto Coke: will try now 17:39
luben_work hashes are not entirely ordered 17:41
hash iteration is done in linear scan of the buckets - if no key was deleted, the iteartion order is the order of addition of the tuples to the hash 17:43
it's faster that way
dukeleto realizes that we should probably do something about the languages svn repo in our git conversion 17:44
luben_work I do not see how this could be used for DoS attacks
dukeleto luben_work: so you are saying that pmichaud's example is only ordered because nothing was deleted?
luben_work: perl 5 used to have ordered hashes, but then it is possible to create pathological hash misses 17:45
17:46 contingencyplan joined
luben_work yes, if we delete a key, we free a bucket. next tupple added will go in that bucket 17:46
this are not ordered hashes, when we look keys we use hash indexes, they are not ordered 17:47
dukeleto luben_work: www.cs.rice.edu/~scrosby/hash/Crosb...ec2003.pdf
luben_work the order of iteration does not reveal noting about how the keys are hashed 17:48
dukeleto luben_work: or www.cs.rice.edu/~scrosby/hash/Crosb...index.html
whiteknight dukeleto: (re: languages svn repo) Repos in git are cheap. We split each language out into it's own project on github 17:50
or, into their own repos under the Parrot organization banner
since that repo gets such little traffic, it might actually make a very good test case 17:51
17:51 allison left
dukeleto whiteknight: git repos are cheap, but creating 20 little git repos out of the languages repo doesn't sound fun for me. it wouldn't be hard, but it would be time-consuming 17:53
whiteknight dukeleto: So maybe you don't do it. I would be happy to
dukeleto whiteknight: have you used git filter-branch before?
Coke the whole point of shoving those repos in the languages repo is that no one wanted them. I'm not sure expending more energy on them is a good plan. 17:54
whiteknight like I said, they're interesting test cases. Plus, I can't think of any reason besides "doesn't sound fun for me" why they all should have been jammed together into the same repo in the first place
Coke: Maybe I want them now
Coke knock yourself out.
whiteknight dukeleto: no, I have not. But I'm a young dog and can learn new tricks
Coke: Will do, with a hammer :)
dukeleto whiteknight: the general idea is that we can use git filter-branch to create new repos for each language directory in the language svn repo 17:55
whiteknight: filter-branch has many options for out to filter out commits. one of them is by file/directory name
atrodo I think parrot needs more focus for more implemented languages 17:56
17:56 Drossel is now known as Kulag
Coke atrodo: we can't focus on the languages we have. 17:56
dukeleto whiteknight: first you will need to convert the languages repo to one big git repo, then you will split up that big repo into smaller language repos with filter-branch
whiteknight: i suggest reading "git help filter-branch"
whiteknight dukeleto: Okay, that all makes good sense to me
I've done the svn->git conversion before, so that's one step down 17:57
atrodo Coke> I know, and that's what i was trying to get at.
dukeleto whiteknight: cool. you can use git svn or whatever way you want. the languages svn repo doesn't have nearly as much history as the parrot repo, so it shouldn't take very long 17:58
moritz I found stackoverflow.com/questions/696043/...repository to be useful for the pugs repo migration
whiteknight thanks
like I said, this is a kind of easy test case
dukeleto moritz++
whiteknight if it works demonstrably well here, the community may have more confidence in the whole-hog migration later
moritz erm, that link itself is pretty useless, but it oints to stackoverflow.com/questions/359424/...repository which in turn is what I used :-)
dukeleto whiteknight: so i guess the plan is to make each language in the language svn repo be a separate git repo under the parrot github organization 17:59
whiteknight Yeah, that's probably a good plan.
That way all the parroteers will have access to it 18:00
dukeleto whiteknight: then we get commit access controls for free. Currently, every user in the github org has push+pull access to all the parrot github repos
whiteknight yeah 18:01
moritz (github organizations)++
dukeleto whiteknight: i would suggest doing the languages in order of "vitality". what is the most active language in the languages repo?
whiteknight: you probably want to do 1 language, and give it a stress test, make sure it has all the files you want/etc, before splitting out every language
i think this will be good for publicity of parrot languages. people will be able to see all the github repos for each language, instead of them being hidden in a languages repo 18:02
perhaps that will get more people to contribute
and i am thinking we need some kind of document for "I want to hack on a Parrot language, where should I start?" 18:03
which lists the most active languages, where they live (soon to be github) and some beginner advice for working on them
any volunteers? 18:04
whiteknight yes, that's an excellent idea
we do have a page of languages, but it's a little bit dense
dukeleto whiteknight: yes, scary for a newbie. But it is very informative for advanced users
GeJ: ping! 18:05
msg GeJ you need to make a trac account on trac.parrot.org so I can give you a commit bit
aloha OK. I'll deliver the message.
whiteknight he has one, I think
dukeleto whiteknight: nope. he isn't listed on the track users page, as far as I can see. Coke told me to do it.
luben_work dukeleto, I read the paper. I think that the current implementation of hashes in parrot does not reveal collision details 18:06
whiteknight "geraud"
dukeleto luben_work: sounds good to me. Is there anything in our docs that tells users that our hashes are not ordered, and they shouldn't rely on that?
whiteknight: ah, I was looking for GeJ
whiteknight I made that same mistake before too 18:07
luben_work ordering of the hashes that we see in hash iteration is ordering of memory allocation for the list nodes
Coke msg chromatic www.modernperlbooks.com/mt/2010/09/...ation.html has a bad link near the end of the article.
aloha OK. I'll deliver the message.
luben_work nobody could derive nothing from this order.
there is a special case for hashes with integer key that could be expoited, because they are traversed by index, so it reveals the internal structure of the hashtable 18:09
dukeleto luben_work: good to know. It might be nice to add a note to our docs explaining what you are telling us
whiteknight in very small words
luben_work but they are used only in parrot internals
I will look in the docs directory and add a note to hash description paragraph 18:11
dukeleto whiteknight: take a look at the bottom of our CREDITS file
whiteknight: that authormap will be useful in the conversion of the languages repo
whiteknight: authormaps will map various committer names to one standard name, so that commits aren't split across different names for the same actual people 18:12
whiteknight: not a huge deal, but nice to have
msg GeJ i've found your user "geraud" and given you svn commit access. Please test it out by adding yourself to CREDITS 18:13
aloha OK. I'll deliver the message.
dukeleto GeJ?
anybody know his email?
whiteknight I have it 18:16
also, you should have it when i forwarded his CLA to the directors list
luben_work As I read the articles I find that we have some naming of the internal structures that is differend from the common one 18:17
what is commonly named "buckets", we call it "index", what is commonly called "entries" in a list, we call it "buckets" in the list 18:18
sorear luben_work: "reveal structure"? You know our current hash tables are 100% predictable in bucket structure, right?
luben_work haha, yes... the structure is the same, the internal ordering is not predictable, because hash_seed is random for every run of the interpreter 18:19
18:20 davidfetter joined
sorear looking at src/hash.c it seems that string hashing entirely ignores hash_seed 18:20
int hashing uses hash_seed in such a way as to not reduce DoSability at all 18:21
luben_work no, it does not, the same seed is used directly by Parrot_str_to_hashval 18:22
this was about key_hash_STRING
about integers - I do not know if the current aproach make DoSing easier 18:23
now rethinking it, we do not need hash_seed in Hash datastructure, because it's always the same with interp->hash_seed 18:24
sorear buckets[(x ^ y) & z] = buckets[(x & z) ^ (y' = y & z)] 18:25
luben_work yes buckets[(x ^ y) & z] = buckets[(x & z) ^ (y & z)] 18:28
y is random (per parrot execution), z depends on hash size 18:29
18:35 theory left
sorear luben_work: the point is that y does nothing to break up long hash chains 18:37
it just rearranges existing buckets
luben_work yes 18:38
we should look for better hash function for numeric keys 18:51
18:51 Andy joined 19:04 luben_work left 19:18 allison joined, M_o_C joined 19:21 lucian_ joined 19:23 lucian left, elmex left 19:42 elmex joined 19:56 theory joined
TimToady phonifications 20:01
20:02 whiteknight left 20:13 bluescreen left
GeJ Bonjour everyone. 20:18
moritz bon soir
GeJ If I were nitpicking, I'd say it would be one word. 20:20
Servus moritz.
dukeleto: pong. 20:22
moritz if I were nitpicking, I'd say that the greeting is one word, but saying that the evening is nice is fine in two words :-) 20:23
GeJ A good thing that you're not nitpicking then. :) 20:24
moritz :-) 20:25
dukeleto GeJ: you have a commit bit. test it out :)
GeJ: check your email 20:26
cotto If I were nitpicking, I'd have more nits.
davidfetter nits grow up to be lice 20:32
20:50 aloha left 20:57 aloha joined, lucian_ left
GeJ Incoming... 21:06
21:08 kid51 joined 21:09 whiteknight joined
GeJ I can't believe it... My first commit, and I've got this strange feeling that I already screwed it. 21:10
cotto sees no commit 21:11
therefore, no mistake
21:13 M_o_C left
kid51 r49383 | geraud | 2010-09-29 17:06:31 -0400 (Wed, 29 Sep 2010) | 5 lines 21:13
No problem there.
Welcome aboard.
dalek ast: 0e3783c | moritz++ | S12-introspection/attributes.t:
[attributes.t] test .get_value and .set_value
 21:16
GeJ kid51: I think I srewed up the encoding.
dalek kudo: 100b868 | moritz++ | src/core/Attribute.pm:
implement Attribute.{get,set}_value
 21:18
rrot: r49383 | geraud++ | trunk/CREDITS:
Add myself to the CREDITS file.
 21:19
rrot: r49384 | jkeenan++ | branches/string_macros (10 files):
Set SVN file metadata properties.
kid51 GeJ: I see that you made the commit -- but where's your own credit? 21:21
Oh, I see.
sorear GeJ: If you add a U: GeJ line, dalek will credit you correctlyh 21:22
kid51 This file is encoded in UTF-8
sorear (CREDITS is so big because dalek uses it, so all of the projects dalek reports on do)
kid51 Gej: See entry for Fran�ois Perrad. That may give you a clue as to how to get your � in.
Gej: For your first codingstd challenge, check out the string_macros branch and get t/coding/c_arg_assert.t to pass. 21:25
It's failing src/string/encoding/shared.h
mikehh can help you out. 21:26
msg luben In string_macros branch, t/examples/shootout.t is still failing Test 16 21:28
aloha OK. I'll deliver the message.
21:29 fperrad left
kid51 aloha, so far, lacks purl's ability to respond to 'messages' and 'messages erase' 21:29
msg aloha If you see purl give her a shout-out from kid51 21:30
aloha OK. I'll deliver the message.
kid51 CREDITS look good now 21:32
dalek rrot: r49385 | jkeenan++ | trunk/CREDITS:
Add my IRC handle.
 21:36
rrot: r49386 | geraud++ | trunk/CREDITS:
Fix encoding and pet dalek for karma to come.
GeJ kid51: branch checked out, built, running fulltest. Will have a look later. Duty calls and I need to get in touch with the surgeon. 21:45
kid51 Salud 21:46
luben kid51, string_macros is nick's branch 21:56
kid51 luben : k 22:16
msg nwellnhof In string_macros branch, t/examples/shootout.t is still failing Test 16 22:17
aloha OK. I'll deliver the message.
kid51 leaves to go out drinking with rdice 22:18
22:18 kid51 left 22:23 ruoso joined 22:26 allison left 22:29 Coke left 22:31 allison joined 22:38 whiteknight left 22:59 Andy left 23:06 whiteknight joined
sorear whiteknight++ 23:34
whiteknight sorear? 23:43
I don't think I've done anything karma-worthy today 23:44
bacek_at_work whiteknight-- # lazy slacker! :) 23:54
aloha, humans
whiteknight lazy slacker!?! I've been filling out IRS paperwork for PaFo. I'm definitely not slacking
sorear whiteknight: not today, but I didn't catch you at the time yesterday
bacek_at_work whiteknight++ # not being lazy slacker :) 23:55
whiteknight unfortunately, the IRS doesn't have a git repo, a karma bot, or a dalek plugin

Powered by Cro and the Raku® Programming Language.

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

Thank you!