Camelia, the Perl 6 bug

IRC log for #parrot, 2010-09-29

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 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
00:00 bacek_at_work gc.write_barrier will put RPA into "root set" for next mark
00:00 bacek_at_work ...next mark of gen1
00:01 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
00:01 dukeleto GeJ: there are some emails in the parrot-dev archives about it
00:02 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.
00:03 dukeleto 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 kid51_at_dinner is now known as kid51
00:04 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
00:04 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GitHub​TracPluginTests?version=7&action=diff
00:04 dukeleto GeJ: http://github.com/parrot/parrot/branches
00:05 dukeleto GeJ: from that page, you can easily get a diff of any branch to master
00:07 dukeleto bacek_at_work: is there a way to infer where write barriers need to be algorithmically, or is it a manual process currently?
00:08 ash_ joined #parrot
00:09 ash_ left #parrot
00:11 cotto dukeleto, it sounds like you want to parse c.
00:11 * cotto mumbles something about lorito
00:12 dukeleto cotto: just wondering if it is possible to figure out beforehand, without parsing
00:12 whiteknight joined #parrot
00:16 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
00:17 plobsing dukeleto: some generational systems are more precise by wrapping all assignments with guards (similar to refcounting)
00:19 GeJ Hello whiteknight.
00:19 whiteknight hello GeJ
00:26 kid51 left #parrot
00:27 luben dukeleto, may be a good first approximations is to put wb on all vtables that have SETATTR in their code
00:29 plobsing luben: what about vtables that create new PMCs themselves? and what about vtables that call functions that SETATTR?
00:29 davidfetter joined #parrot
00:31 luben if vtables calls a function with SETATTR in it, may be the WB should be invoked explicitly where the SETATTR is called
00:32 plobsing if you do that for functions, why not do it everywhere?
00:35 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:36 plobsing sounds like premature optimization with 0 evidence used to support a special case. I really dislike special cases.
00:39 luben its just another manner to implement write barriers - with its cons and pros
00:40 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
00:40 luben plobsing, yes, I agree
00:41 luben but there are functions that SETATTR that are not invoked from vtables
00:44 ruoso joined #parrot
00:48 dalek parrot: r49373 | plobsing++ | trunk (5 files):
00:48 dalek parrot: calloc can return null
00:48 dalek parrot: rtfm: malloc(3)
00:48 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49373/
00:48 Andy left #parrot
00:52 dngor joined #parrot
00:53 dngor_ left #parrot
01:11 kid51 joined #parrot
01:13 dalek tracwiki: v8 | cotto++ | GitHubTracPluginTests
01:13 dalek tracwiki: partial test results and minor fixes to the tests
01:13 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GitHub​TracPluginTests?version=8&action=diff
01:24 Andy joined #parrot
01:32 davidfetter left #parrot
01:34 kid51_ joined #parrot
01:36 PhatEddy joined #parrot
01:37 PhatEddy kid51: ping
01:37 kid51 left #parrot
01:39 kid51_ PhatEddy pong
01:39 kid51_ is now known as kid51
01:41 PhatEddy Thx, I am looking at proposing a patch for part of the rakudo build process under win32 that uses backticks "`".
01:42 kid51 If you are proposing patches for Rakudo, you probably want #perl6 on irc.freenode.net
01:42 PhatEddy Thx  - will try there.
01:43 kid51 or: open an RT for them via: rakudobug@perl.org
02:12 whiteknight left #parrot
02:13 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 #parrot
02:29 kid51 left #parrot
02:29 dalek parrot: r49374 | plobsing++ | trunk (5 files):
02:29 dalek parrot: [C89] eliminate and add test against trailing commas in enums
02:29 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49374/
02:35 janus left #parrot
02:35 theory joined #parrot
03:03 dalek parrot: r49375 | plobsing++ | trunk (2 files):
03:03 dalek parrot: make new codingstd test a little more codingstd conformant
03:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49375/
03:20 dalek parrot: r49376 | plobsing++ | trunk/compilers/imcc (2 files):
03:20 dalek parrot: eliminate useless includes
03:20 dalek parrot: move remaining user-defined lex includes to top
03:20 dalek parrot: this prevents lex from defining INT{8,16,32}_{MIN,MAX} on non-C99 platforms that still define them somewhere
03:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49376/
03:31 janus joined #parrot
03:44 dalek github-trac: 33e2770 | cotto++ | github/github.py:
03:44 dalek github-trac: fix commit message processing
03:44 dalek github-trac: review: http://github.com/cotto/github-trac/commit​/33e27704162d19095f144fe89f9bbb4a83fade3f
03:48 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:50 plobsing dukeleto: you were looking into parrot on embedded systems, correct?
03:51 dukeleto http://github.com/parrot/parrot/blob/leto​%2Fgit_docs/docs/project/git_workflow.pod
03:51 cotto dukeleto++
03:52 preflex left #parrot
03:52 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...)?
03:52 dukeleto http://github.com/parrot/parrot/blob/leto%2​Fgit_docs/docs/project/git_terminology.pod
03:53 dukeleto Comments and questions about the git docs welcome.
03:53 dukeleto plobsing: it is an issue for things like real-time operating systems
03:53 dukeleto plobsing: i haven't really seen a good reason for dynpmc's
03:55 dukeleto 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:56 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 #parrot
03:57 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
03:57 dukeleto plobsing: i don't think RTEMS does dynamic loading yet, but I hear they are working on it. But yes, many don't.
03:58 dukeleto plobsing: i could see somebody that doesn't have dynloading want, say, the Random dynop
03:59 dukeleto 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.
03:59 dukeleto plobsing: very interesting
03:59 dukeleto plobsing: which version of minix are you using?
04:00 plobsing dukeleto: dynops and dynpmcs should be trivially statically addable (there has to be a real word for that) to core parrot
04:00 plobsing 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.
04:01 plobsing 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:02 plobsing uname -a => Minix 10.0.2.15 3 1.7 i686
04:03 plobsing that was the latest stable release when I downloaded it yesterday
04:04 dalek tracwiki: v9 | cotto++ | GitHubTracPluginTests
04:04 dalek tracwiki: I guess that's why we have tests.
04:04 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GitHub​TracPluginTests?version=9&action=diff
04:10 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.
04:11 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:12 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?
04:12 dukeleto plobsing: that is why we ask for help :)
04:13 plobsing dukeleto: I get to the stage where it tries to compile dynpmcs. so yes, core parrot compiles.
04:13 plobsing modulo a couple hacks and workarounds which I am now cleaning up and commiting to core.
04:13 plobsing s/core/trunk/
04:13 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.
04:15 dukeleto 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
04:15 dukeleto plobsing: perhaps after you commit to core, but whatev
04:16 dukeleto 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:17 dukeleto 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:18 plobsing minix/openbsd/etc *shouldn't* be too hard to get working. they are posix after all.
04:22 dukeleto plobsing: devil is in the details
04:23 dukeleto 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++
04:23 cotto git add -p FTW
04:24 plobsing the devil is in the details. minix is more posix compliant than any of the systems we "officially" support
04:24 plobsing and still doesn't quite work
04:26 plobsing 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
04:27 dukeleto plobsing: hopefully a few for each supported OS and at least one for the experimentally supported OS's
04:29 dalek github-trac: c4d8935 | cotto++ | github/github.py:
04:29 dalek github-trac: add a redirect to the hook so trac doesn't complain about sending an empty response
04:29 dalek github-trac: review: http://github.com/cotto/github-trac/commit​/c4d8935a57a15b7822fe50a5a82296fb7b3d0279
04:29 dalek github-trac: 5e01436 | cotto++ | github/github.py:
04:29 dalek github-trac: fix config option check
04:29 dalek github-trac: review: http://github.com/cotto/github-trac/commit​/5e014367391878b5a3c402ed0e1e1f97db1dafc1
04:29 dalek github-trac: f983969 | cotto++ | github/ (2 files):
04:29 dalek github-trac: fix hook code when the revmap is enabled
04:29 dalek github-trac: review: http://github.com/cotto/github-trac/commit​/f983969fcfdd61cd2691ab2fb45798377dc33749
05:01 dalek parrot: r49377 | mikehh++ | trunk/t/codingstd/c_enum.t:
05:01 dalek parrot: fix perlcritic failure - remove hard tabs
05:01 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49377/
05:01 dalek parrot: r49378 | plobsing++ | trunk (7 files):
05:01 dalek parrot: test for timespec directly in stead of guessing at internal details of system headers
05:01 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49378/
05:04 ash_ joined #parrot
05:19 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:25 mikehh pre-config tests say No tests exist for configure step auto::timespec at t/configure/026-options_test.t line 18 and
05:25 mikehh No tests exist for configure step auto::timespec at t/configure/049-options_test_prepare.t line 16
05:27 plobsing mikehh: sorry, I couldn't think of any tests for it
05:28 plobsing it's more of an "obviously no bugs" rather than a "no obvious bugs" type software
05:28 plobsing but I'll try to think some up
05:29 mikehh and you got hard tabs in  config/auto/timespec.pm - you want to fix that or shall I
05:31 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:32 Andy left #parrot
05:35 dalek parrot: r49379 | plobsing++ | trunk/config/auto/timespec.pm:
05:35 dalek parrot: [codingstd] tabs
05:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49379/
05:40 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 plobsing that seems backwards
05:44 mikehh who is our OpenGL person
05:47 mikehh 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
05:48 mikehh NotFound: ping
05:48 plobsing I've been getting those type messages for months here on Arch.
05:48 plobsing hmmmm... praise tells a different story
05:48 plobsing japhb or Infinoid
05:49 cotto Mmmmm.  Arch.
05:49 plobsing sorry to have mislead
05:49 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)
05:49 mikehh but
05:52 dalek parrot: r49380 | mikehh++ | trunk/config/auto (2 files):
05:52 dalek parrot: add svn properties
05:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49380/
05:59 mikehh plobsing: which ones are you getting, maybe I can fix it
06:04 nopaste "plobsing" at 192.168.1.3 pasted "opengl_warnings" (7 lines) at http://nopaste.snit.ch/23795
06:09 mikehh plobsing: yeah I am getting that one also some can't handle type 'longlong';
06:09 mikehh let me have a look
06:11 sorear How are we on FreeBSD?
06:13 plobsing should work. last reported success was 20090720 though (according to PLATFORMS).
06:14 mikehh hmmn - OpenGL -> TT #1182
06:29 dalek left #parrot
06:29 PerlJam left #parrot
06:30 Util left #parrot
06:30 dukeleto left #parrot
06:30 hatseflats left #parrot
06:30 pmichaud left #parrot
06:40 cotto Say someone refers to a git commit id on the wiki ambiguously.  What would be the right thing to do?
06:41 cotto i.e. there are commits deadbeef100000000000000000000000000000000 and deadbeef200000000000000000000000000000000, and someone writes deadbeef.
06:42 cotto s/i.e./e.g./
06:44 dalek joined #parrot
06:45 GeJ statistically, that'd be really bad luck.
06:45 dalek tracwiki: v10 | cotto++ | GitHubTracPluginTests
06:45 dalek tracwiki: add incomplete test for ambiguous git ids
06:45 dalek tracwiki: http://trac.parrot.org/parrot/wiki/GitHubT​racPluginTests?version=10&action=diff
06:45 PerlJam joined #parrot
06:46 dukeleto joined #parrot
06:46 cotto Sure, but I want to dtrt should it happen.
06:50 Util joined #parrot
06:51 pmichaud joined #parrot
06:58 dukeleto left #parrot
06:58 dalek left #parrot
06:58 PerlJam left #parrot
06:58 pmichaud left #parrot
06:58 Util left #parrot
07:03 fperrad joined #parrot
07:19 ruoso left #parrot
07:24 dalek joined #parrot
07:24 PerlJam joined #parrot
07:25 dukeleto joined #parrot
07:25 pmichaud joined #parrot
07:25 Util joined #parrot
07:32 ruoso joined #parrot
07:32 hatseflats joined #parrot
07:38 theory left #parrot
07:43 tadzik joined #parrot
07:50 lucian_ left #parrot
07:52 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:57 lucian joined #parrot
07:59 fperrad left #parrot
08:01 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?
08:01 bacek_at_work hmm. let me check
08:01 cotto dukeleto seems to think not
08:03 bacek_at_work Commit: 09ffd6797b5e59ffa3664f56d1e3071d7cef6013
08:03 bacek_at_work http://github.com/bacek/aloha/commit/09​ffd6797b5e59ffa3664f56d1e3071d7cef6013
08:03 bacek_at_work Author: vasily.chekalkin <vasily.chekalkin@optusnet.com.au>
08:03 bacek_at_work Date:   2010-09-29 (Wed, 29 Sep 2010)
08:03 bacek_at_work Changed paths:
08:03 bacek_at_work M lib/Bot/BasicBot/Pluggable/Module/Clock.pm
08:03 bacek_at_work Log Message:
08:03 bacek_at_work -----------
08:03 bacek_at_work Add bit of documentation for email commit testing.
08:03 bacek_at_work apparently not...
08:04 cotto It should be pretty simple.
08:05 cotto They at least have a reasonably well-documented api.
08:15 lucian left #parrot
08:18 lucian joined #parrot
08:46 bacek left #parrot
08:51 dalek parrot: r49381 | bacek++ | branches/generational_gc/src/pmc/class.pmc:
08:51 dalek parrot: Add write barrier call when we update Class.attrib_cache
08:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49381/
08:55 lucian left #parrot
08:57 bacek joined #parrot
08:57 lucian joined #parrot
09:24 ruoso left #parrot
09:36 ruoso joined #parrot
09:52 particle1 left #parrot
09:56 particle joined #parrot
10:07 ruoso left #parrot
10:27 contingencyplan left #parrot
10:35 lucian left #parrot
10:42 tadzik left #parrot
11:45 nwellnhof joined #parrot
11:50 whiteknight joined #parrot
12:08 whiteknight good morning, #parrot
12:13 mj41 left #parrot
12:15 mj41 joined #parrot
12:20 bluescreen joined #parrot
12:30 fperrad joined #parrot
12:32 dalek parrot: r49382 | plobsing++ | trunk/config/gen/makefiles/root.in:
12:32 dalek parrot: avoid trying to build dynamic shared objects if we don't have dynamic linking
12:32 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49382/
12:38 p6eval left #parrot
12:38 p6eval joined #parrot
12:57 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)
13:08 whiteknight mikehh: How is Ubuntu 10.10 beta?
13:19 Patterner left #parrot
13:19 Psyche^ joined #parrot
13:19 Psyche^ is now known as Patterner
13:34 mikehh whiteknight: couple of minor problems, nothing serious, a lot of good stuff
13:38 * mikehh need to go shopping, bbl
13:41 tadzik joined #parrot
14:27 tadzik left #parrot
14:51 ash_ left #parrot
14:54 theory joined #parrot
15:22 nwellnhof left #parrot
15:23 ruoso joined #parrot
15:26 allison joined #parrot
15:29 nwellnhof joined #parrot
15:30 jsut joined #parrot
15:35 patspam joined #parrot
15:35 patspam left #parrot
15:35 jsut_ left #parrot
15:41 lucian joined #parrot
16:11 fperrad_ joined #parrot
16:13 fperrad left #parrot
16:13 fperrad_ is now known as fperrad
16:23 nwellnhof left #parrot
16:38 pmichaud Parrot hashes seem to be ordered again.
16:38 pmichaud (nopaste coming)
16:43 pmichaud http://gist.github.com/603084    # parrot hashes now act ordered?
16:46 whiteknight interesting
16:46 whiteknight besides being weird, does this constitute a problem?
16:47 whiteknight (I'm trying to figure out if this is a "bug" or "unintended feature")
16:52 * dukeleto collapses into a stable eigenstate in #parrot
17:01 * whiteknight takes dukeleto to a stable eigenhospital after he collapsed
17:03 whiteknight probably from low blood eigensugar
17:04 pmichaud well, it's not truly a "bug", other than some people might start to inadvertently rely on it.
17:05 pmichaud 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 pmichaud (relying on non-ordering behavior is equally as erroneous as relying on ordering behavior, imo)
17:05 whiteknight pmichaud: okay. I'm mostly concerned about the performance of it. Obviously we don't want the overhead of keeping hash entries sorted
17:06 whiteknight 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.
17:06 pmichaud TimToady++ also notes that it can be a DoS issue, since hashes become predictable.
17:08 whiteknight ok, that part is more serious
17:13 TimToady well, whether it's potentially DoS depends on how it's implemented
17:15 whiteknight assume the worst
17:28 kid51 joined #parrot
17:30 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.
17:31 kid51 msg plobsing Also, adding a config step should probably have been preceded by post to list or by Trac ticket.
17:32 aloha OK. I'll deliver the message.
17:34 Coke I reiterate my question regarding the usefulness of those tests.
17:35 Coke 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 #parrot
17:36 Coke (reiterate) but it's a very old question that's probably already been dealt with. Apologies.
17:36 kid51 left #parrot
17:37 Coke msg dukeleto - you weren't a trac admin, but are now.
17:37 aloha OK. I'll deliver the message.
17:39 dukeleto Coke: will try now
17:41 luben_work hashes are not entirely ordered
17:43 luben_work 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 luben_work it's faster that way
17:44 * 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
17:44 dukeleto luben_work: so you are saying that pmichaud's example is only ordered because nothing was deleted?
17:45 dukeleto luben_work: perl 5 used to have ordered hashes, but then it is possible to create pathological hash misses
17:46 contingencyplan joined #parrot
17:46 luben_work yes, if we delete a key, we free a bucket. next tupple added will go in that bucket
17:47 luben_work this are not ordered hashes, when we look keys we use hash indexes, they are not ordered
17:47 dukeleto luben_work: http://www.cs.rice.edu/~scrosby/ha​sh/CrosbyWallach_UsenixSec2003.pdf
17:48 luben_work the order of iteration does not reveal noting about how the keys are hashed
17:48 dukeleto luben_work: or http://www.cs.rice.edu/~scrosby/hash/C​rosbyWallach_UsenixSec2003/index.html
17:50 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 whiteknight or, into their own repos under the Parrot organization banner
17:51 whiteknight since that repo gets such little traffic, it might actually make a very good test case
17:51 allison left #parrot
17:53 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
17:53 dukeleto whiteknight: have you used git filter-branch before?
17:54 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
17:54 whiteknight Coke: Maybe I want them now
17:54 Coke knock yourself out.
17:54 whiteknight dukeleto: no, I have not. But I'm a young dog and can learn new tricks
17:54 whiteknight Coke: Will do, with a hammer :)
17:55 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 dukeleto whiteknight: filter-branch has many options for out to filter out commits. one of them is by file/directory name
17:56 atrodo I think parrot needs more focus for more implemented languages
17:56 Drossel is now known as Kulag
17:56 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
17:56 dukeleto whiteknight: i suggest reading "git help filter-branch"
17:56 whiteknight dukeleto: Okay, that all makes good sense to me
17:57 whiteknight 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.
17:58 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 http://stackoverflow.com/questions/69​6043/how-do-i-split-a-git-repository to be useful for the pugs repo migration
17:58 whiteknight thanks
17:58 whiteknight like I said, this is a kind of easy test case
17:58 dukeleto moritz++
17:58 whiteknight if it works demonstrably well here, the community may have more confidence in the whole-hog migration later
17:58 moritz erm, that link itself is pretty useless, but it oints to http://stackoverflow.com/questions/359424/det​ach-subdirectory-into-separate-git-repository which in turn is what I used :-)
17:59 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.
18:00 whiteknight 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
18:01 whiteknight yeah
18:01 moritz (github organizations)++
18:01 dukeleto whiteknight: i would suggest doing the languages in order of "vitality". what is the most active language in the languages repo?
18:01 dukeleto 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
18:02 dukeleto 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 dukeleto perhaps that will get more people to contribute
18:03 dukeleto 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 dukeleto which lists the most active languages, where they live (soon to be github) and some beginner advice for working on them
18:04 dukeleto any volunteers?
18:04 whiteknight yes, that's an excellent idea
18:04 whiteknight we do have a page of languages, but it's a little bit dense
18:04 dukeleto whiteknight: yes, scary for a newbie. But it is very informative for advanced users
18:05 dukeleto GeJ: ping!
18:05 dukeleto msg GeJ you need to make a trac account on trac.parrot.org so I can give you a commit bit
18:05 aloha OK. I'll deliver the message.
18:05 whiteknight he has one, I think
18:05 dukeleto whiteknight: nope. he isn't listed on the track users page, as far as I can see. Coke told me to do it.
18:06 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"
18:06 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?
18:06 dukeleto whiteknight: ah, I was looking for GeJ
18:07 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
18:07 Coke msg chromatic http://www.modernperlbooks.com/mt/2010/0​9/the-right-approach-to-deprecation.html has a bad link near the end of the article.
18:07 aloha OK. I'll deliver the message.
18:07 luben_work nobody could derive nothing from this order.
18:09 luben_work 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
18:09 whiteknight in very small words
18:09 luben_work but they are used only in parrot internals
18:11 luben_work 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
18:11 dukeleto whiteknight: that authormap will be useful in the conversion of the languages repo
18:12 dukeleto 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 dukeleto whiteknight: not a huge deal, but nice to have
18:13 dukeleto 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.
18:13 dukeleto GeJ?
18:13 dukeleto anybody know his email?
18:16 whiteknight I have it
18:16 whiteknight also, you should have it when i forwarded his CLA to the directors list
18:17 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:18 luben_work 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?
18:19 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:20 davidfetter joined #parrot
18:20 sorear looking at src/hash.c it seems that string hashing entirely ignores hash_seed
18:21 sorear int hashing uses hash_seed in such a way as to not reduce DoSability at all
18:22 luben_work no, it does not, the same seed is used directly by  Parrot_str_to_hashval
18:22 luben_work this was about key_hash_STRING
18:23 luben_work about integers - I do not know if the current aproach make DoSing easier
18:24 luben_work now rethinking it, we do not need hash_seed in Hash datastructure, because it's always the same with interp->hash_seed
18:25 sorear buckets[(x ^ y) & z] = buckets[(x & z) ^ (y' = y & z)]
18:28 luben_work yes buckets[(x ^ y) & z] = buckets[(x & z) ^ (y & z)]
18:29 luben_work y is random (per parrot execution), z depends on hash size
18:35 theory left #parrot
18:37 sorear luben_work: the point is that y does nothing to break up long hash chains
18:37 sorear it just rearranges existing buckets
18:38 luben_work yes
18:51 luben_work we should look for better hash function for numeric keys
18:51 Andy joined #parrot
19:04 luben_work left #parrot
19:18 allison joined #parrot
19:18 M_o_C joined #parrot
19:21 lucian_ joined #parrot
19:23 lucian left #parrot
19:23 elmex left #parrot
19:42 elmex joined #parrot
19:56 theory joined #parrot
20:01 TimToady phonifications
20:02 whiteknight left #parrot
20:13 bluescreen left #parrot
20:18 GeJ Bonjour everyone.
20:18 moritz bon soir
20:20 GeJ If I were nitpicking, I'd say it would be one word.
20:20 GeJ Servus moritz.
20:22 GeJ dukeleto: pong.
20:23 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:24 GeJ A good thing that you're not nitpicking then. :)
20:25 moritz :-)
20:25 dukeleto GeJ: you have a commit bit. test it out :)
20:26 dukeleto GeJ: check your email
20:26 cotto If I were nitpicking, I'd have more nits.
20:32 davidfetter nits grow up to be lice
20:50 aloha left #parrot
20:57 aloha joined #parrot
20:57 lucian_ left #parrot
21:06 GeJ Incoming...
21:08 kid51 joined #parrot
21:09 whiteknight joined #parrot
21:10 GeJ I can't believe it... My first commit, and I've got this strange feeling that I already screwed it.
21:11 * cotto sees no commit
21:11 cotto therefore, no mistake
21:13 M_o_C left #parrot
21:13 kid51 r49383 | geraud | 2010-09-29 17:06:31 -0400 (Wed, 29 Sep 2010) | 5 lines
21:13 kid51 No problem there.
21:13 kid51 Welcome aboard.
21:16 dalek roast: 0e3783c | moritz++ | S12-introspection/attributes.t:
21:16 dalek roast: [attributes.t] test .get_value and .set_value
21:16 dalek roast: review: http://github.com/perl6/roast/commit/0e​3783c40da3eadab107c59b93020c32867ec134
21:16 GeJ kid51: I think I srewed up the encoding.
21:18 dalek rakudo: 100b868 | moritz++ | src/core/Attribute.pm:
21:18 dalek rakudo: implement Attribute.{get,set}_value
21:18 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​00b868e436c785dba0fe1ba5678db70340c374a
21:19 dalek parrot: r49383 | geraud++ | trunk/CREDITS:
21:19 dalek parrot: Add myself to the CREDITS file.
21:19 dalek parrot: I hereby solemnly swear that I'll try to not break anything. I said I'll try.
21:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49383/
21:19 dalek parrot: r49384 | jkeenan++ | branches/string_macros (10 files):
21:19 dalek parrot: Set SVN file metadata properties.
21:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49384/
21:21 kid51 GeJ:  I see that you made the commit -- but where's your own credit?
21:21 kid51 Oh, I see.
21:22 sorear GeJ: If you add a U: GeJ line, dalek will credit you correctlyh
21:22 kid51 This file is encoded in UTF-8
21:22 sorear (CREDITS is so big because dalek uses it, so all of the projects dalek reports on do)
21:22 kid51 Gej:  See entry for Fran�ois Perrad.  That may give you a clue as to how to get your � in.
21:25 kid51 Gej:  For your first codingstd challenge, check out the string_macros branch and get t/coding/c_arg_assert.t  to pass.
21:25 kid51 It's failing src/string/encoding/shared.h
21:26 kid51 mikehh can help you out.
21:28 kid51 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 #parrot
21:29 kid51 aloha, so far, lacks purl's ability to respond to 'messages' and 'messages erase'
21:30 kid51 msg aloha If you see purl give her a shout-out from kid51
21:30 aloha OK. I'll deliver the message.
21:32 kid51 CREDITS look good now
21:36 dalek parrot: r49385 | jkeenan++ | trunk/CREDITS:
21:36 dalek parrot: Add my IRC handle.
21:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49385/
21:36 dalek parrot: r49386 | geraud++ | trunk/CREDITS:
21:36 dalek parrot: Fix encoding and pet dalek for karma to come.
21:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/49386/
21:45 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:46 kid51 Salud
21:56 luben kid51, string_macros is nick's branch
22:16 kid51 luben : k
22:17 kid51 msg nwellnhof In string_macros branch, t/examples/shootout.t is still failing Test 16
22:17 aloha OK. I'll deliver the message.
22:18 * kid51 leaves to go out drinking with rdice
22:18 kid51 left #parrot
22:23 ruoso joined #parrot
22:26 allison left #parrot
22:29 Coke left #parrot
22:31 allison joined #parrot
22:38 whiteknight left #parrot
22:59 Andy left #parrot
23:06 whiteknight joined #parrot
23:34 sorear whiteknight++
23:43 whiteknight sorear?
23:44 whiteknight I don't think I've done anything karma-worthy today
23:54 bacek_at_work whiteknight-- # lazy slacker! :)
23:54 bacek_at_work aloha, humans
23:54 whiteknight lazy slacker!?! I've been filling out IRS paperwork for PaFo. I'm definitely not slacking
23:54 sorear whiteknight: not today, but I didn't catch you at the time yesterday
23:55 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

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

Parrot | source cross referenced