Camelia, the Perl 6 bug

IRC log for #parrot, 2010-01-30

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:11 tetragon joined #parrot
00:14 * darbelo replaces conditional with API
00:15 * cotto_work replaces darbelo with API
00:16 kid51 joined #parrot
00:22 ash_ joined #parrot
00:28 cotto_work darbelo, thanks for doing this work, but is it going to be in one huge commit that's hard to review?
00:28 darbelo Probably.
00:28 cotto_work Is that evitable?
00:29 Whiteknight we'll review it
00:29 darbelo Sure.
00:29 darbelo Right now I'm doing exploration mostly.
00:29 cotto_work Sure.  It'll just be nicer to review if it's in smaller chunks.
00:30 darbelo I can commit it in chunks once I decide which way is the correct one.
00:30 cotto_work Great.  Thanks.
00:30 darbelo That will happen after I get it to build, for starters.
00:30 cotto_work Bah.  A working build is overrated.
00:32 darbelo Also, the need for foods is overpowering me.
00:33 cotto_work I feel the same way about the need for not being at work.
00:33 darbelo I'll probably get something commit-worthy in, say, two or three hours. With a full stomach.
00:35 Whiteknight my kill_array_pmc branch has some failures in the packfile* tests, so I'm very much looking forward to this cleanup
00:35 mj41_ joined #parrot
00:35 lichtkind_ joined #parrot
00:36 darbelo I can probably de-Array-ize the code too.
00:37 darbelo What did you replace Array with in pmc_freeze.c ?
00:42 Coke .
00:42 darbelo Coke: ping
00:43 Whiteknight darbelo: RPA
00:43 Whiteknight but it isn't straghtforward
00:44 Whiteknight Array returns null on shift when it's empty. RPA throws exception
00:44 Coke I'm here.
00:44 darbelo Coke: After one_make merged, we're pretty much moving into a least-common-denominator make strategy, right?
00:45 lichtkind_ joined #parrot
00:45 Coke darbelo: yes.
00:45 darbelo Tha means that we can kill the config step that determines your particular make?
00:45 Coke ... but there are some things, like dummy targets, that we can do by using the make-specific variants.
00:46 Coke darbelo: isn't that still useful to say "now run <YOUR MAKE>" ?
00:47 darbelo I have two makes, both work. Why is Configure telling me which to use?
00:47 Coke fair enough.
00:48 darbelo That's the point of using least common denominator. You can use any make you please.
00:51 dduncan joined #parrot
00:51 * darbelo leaves
00:51 darbelo Be back in afew hours
01:05 dduncan left #parrot
01:10 cconstantine joined #parrot
01:44 chromatic joined #parrot
01:46 LaVolta joined #parrot
01:57 dukeleto 'ello
01:57 cotto 'i
01:57 Whiteknight hello
01:57 plobsing hi
01:58 dukeleto so we should start planning for GSoC and stuff
01:58 dukeleto i have lots of project ideas for parrot
01:58 dukeleto shall we start a wiki page?
01:58 cotto Coke, ping
01:59 Whiteknight we have  wikipage
01:59 Whiteknight http://trac.parrot.org/parrot/wiki/BigProjectIdeas
01:59 Whiteknight just very sparse
02:01 dukeleto we may want something specific to GSoC10
02:02 dukeleto so "small" projects on that page are GSoC-worthy?
02:02 dukeleto also, what about non-core stuff. should that get listed there?
02:02 cotto It depends on the student.
02:02 dukeleto i.e. i have ideas for PL/Parrot and other HLL-related stuff
02:02 cotto Ideally they'll talk with us some and figure out what they can handle.
02:03 dukeleto cotto: sure. but having some high level descriptions really helps bring in students
02:03 dukeleto they come to us *after* they have seen a cool project idea, usually. rarely is it the other way around. of course, the best students break this rule
02:04 cotto That's probably how it'll be.
02:05 dalek tracwiki: v24 | cotto++ | GitObjections
02:05 dalek tracwiki: Mark most objections as addressed.  Feel free to disagree.
02:05 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Git​Objections?version=24&amp;action=diff
02:05 dalek tracwiki: v10 | whiteknight++ | BigProjectIdeas
02:05 dalek tracwiki: added NFG and updated size descriptions
02:05 dalek tracwiki: http://trac.parrot.org/parrot/wiki/BigP​rojectIdeas?version=10&amp;action=diff
02:05 Whiteknight medium projects on that page are gsoc-worthy, i think
02:06 Whiteknight dukeleto: that's good question (re: non-core projects). PLA could use some love of that type
02:07 Whiteknight apps and libraries that target parrot are always good things
02:11 cotto I'm all for having non-core Parrot-related GSoC projects.  The wiki seems like the best place for it.
02:28 Whiteknight I am going to advertise all project ideas on my blog. from the two posts I've had so far I've already heard from 3 potential students and 2 potential new developers
02:30 Whiteknight is there anybody around who can explain why TT #389 is really a necessity?
02:30 Whiteknight the ticket doesn't say, only that it is a "blocker for Rakudo"
02:40 ash_ Whiteknight: i'd like to work on a GSoC project if your thinking of ideas, i am still in college
02:40 chromatic joined #parrot
02:47 hercynium joined #parrot
02:48 kid51 joined #parrot
02:48 eternaleye joined #parrot
02:52 mikehh joined #parrot
02:59 eternaleye joined #parrot
03:01 cconstantine joined #parrot
03:02 Whiteknight ash_: awesome! anything in particular catch your fancy?
03:02 ash_ well, anything related to dynamicsm particularly llvm stack frame builder and l1
03:03 Whiteknight oh, nice
03:03 Whiteknight lots of projects in that area
03:05 ash_ Whiteknight: I am working on an indedpendant study, (just started) with a professor at my college on compilers, we are basically going to go through the dragon book this semester, but my kinda on-going goal is an implemetation of nqp-rx that builds against the llvm, more to see if i can figure it out and learn how all that stuff works than anything else but we'll see how that pans out
03:05 Whiteknight that sounds like a really cool project
03:06 Whiteknight there are a whole suite of optimizations that need to be added to NQP-RX and PCT
03:06 ash_ my professor liked the idea of how nqp-rx can define a mutable grammar, he's been looking into that, he hasn't currently seen a tool to do what it does
03:06 Whiteknight adding the ability for NQP-RX to directly output bytecode is a big need
03:06 mikehh joined #parrot
03:06 kid51 ash_ Some groundwork for LLVM was laid in http://trac.parrot.org/parrot/ticket/1075
03:07 Whiteknight ash_: I've got to sign off and head to bed now. Let's definitely talk about projects later?
03:07 ash_ sure, i can email you or leave a comment on your blog
03:07 Whiteknight excellent (both of which end up in my email inbox!)
03:07 ash_ i did see the llvm detect branch
03:07 Whiteknight I'll talk to you later
03:08 kid51 Am I correct in thinking that if you only have a single core on a machine, 'make -j' is of no benefit over and above 'make'?
03:08 ash_ i hear most people do # of cores + 1
03:08 plobsing kid51: there may be some benefit for IO bound steps
03:09 plobsing ash_: if you're looking to build a frame builder, feel free to ask me questions
03:09 ash_ yeah, i saw your libjit one
03:09 ash_ i am not currently working on it, but maybe later, if i have spare time
03:09 ash_ i still wish libjit would compile on OS X
03:10 plobsing I hear ya
03:11 ash_ i never tried the libjit-linear-scan-register-allocator version on google code, maybe i'll do that one real quick
03:11 mikehh joined #parrot
03:11 ash_ i duno if its just me, but i feel a bit like libjit is ummm disorganized
03:11 plobsing ash_: It's kinda moot right now, the branch is stalled out because of GC interferance (yet again)
03:12 * plobsing wishes that people would just insert more ram when their programs ran out of memeory
03:12 ash_ haha
03:12 ash_ swapon!
03:12 ash_ its like a super power for operating systems
03:16 mikehh joined #parrot
03:17 ash_ didn't someone use the boehm_gc? would that affect libjit any?
03:18 plobsing ash_: not sure. my issues stem from the fact that if you change the size of PMCs used in tests, GC passes change location wrt surrounding code, revealing and hiding bugs
03:18 kid51 IIRC bacek was experimenting with Boehm GC.  I think whiteknight commented on those efforts on his blog.
03:19 ash_ wrt? i am not familiar with that abbr.
03:19 plobsing with respect to
03:19 plobsing too many math courses
03:20 ash_ ah, got ya
03:20 ash_ hmmm
03:20 ash_ so gc moved your pointer around?
03:21 plobsing more like: I moved GC around and GC blew away someone elses pointer because they aren't respecting GC's requirements
03:22 ash_ ah
03:22 plobsing at least, that's my side of the story
03:22 ash_ is the gc_encapsulation branch maybe helpful? (seems like gc isn't properly encapsulated)
03:23 plobsing perhaps. I'm trying to stay away from GC (too much on my plate already)
03:23 plobsing ash_: a good example of a bug I hit a lot is TT #1142
03:24 * ash_ *foosh sounds as things fly over my head now*
03:27 plobsing yeah, these things tend to involve a lot of components all at once.
03:27 ash_ i'd argue i am smarter than your average bear, but most of the real issues in parrot are beyond me, so... ima just keep working on my nqp thing for now
03:32 kid51 msg bacek Did you ever get the access to languages/ you requested in TT #894 ?
03:32 purl Message for bacek stored.
03:33 mikehh joined #parrot
03:34 dalek parrot: r43644 | darbelo++ | branches/pmc_freeze_with_pmcs/src/pmc/imageio.pmc:
03:34 dalek parrot: Add a do-nothing ImageIO pmc.
03:34 dalek parrot: Copy over some definitions and add the full set of ATTRs.
03:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43644/
03:42 cotto "Imagio" sounds like it'd be a good name for a fancy hotel.
03:48 samlh joined #parrot
03:52 darbelo joined #parrot
03:52 * darbelo thaws
03:52 plobsing darbelo: are you doing a verbatim copy of src/pmc_freeze.c?
03:53 plobsing btw darbelo++ on pmc_freeze_with_pmcs branch
03:56 darbelo plobsing: Not completely.
03:56 darbelo But it starts out that way.
03:57 darbelo I did a proof of concept that replaced some conditionals with API before dinner.
03:57 darbelo Right now I'm doing a incremental conversion into that to simplify review.
03:58 cotto darbelo, you might want to hold off until kill_array_pmc gets merged.  It'll affect some of the freeze/thaw code.
03:59 darbelo I asked whiteknight about that. It's a straightforward change.
03:59 plobsing I ask because I have it in for 'id_list'. It is the same thing as 'seen'. They really should just be one element
03:59 cotto ok.
03:59 darbelo plobsing: I haven't got rid of that yet.
04:01 darbelo But I think I can make it more easily killable.
04:02 darbelo I also could make ->what irrelevant at the same time.
04:02 darbelo Let me check that.
04:02 darbelo ...
04:07 dalek parrot: r43645 | darbelo++ | branches/pmc_freeze_with_pmcs/src/pmc/imageio.pmc:
04:07 dalek parrot: Start filling out the VTABLEs.
04:07 dalek parrot: Right now this are dumb copies from the code in pmc_freeze.c
04:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43645/
04:12 darbelo Say, what is the 'new' way to call PMC methods from C ?
04:13 darbelo I haven't used that since before the big calling conventions redoing.
04:14 darbelo Parrot_pcc_invoke_method_from_c_args ?
04:16 cotto sure
04:20 * kid51 must sleep
04:20 purl $kid51->sleep(8 * 3600);
04:21 cotto Is that in ms, because that's not very long.
04:22 darbelo And "PS->" is takes PMC and STRING, with nothing coming out, right?
04:35 LaVolta joined #parrot
04:36 ash__ joined #parrot
04:38 cconstantine_ joined #parrot
04:43 cconstantine_ joined #parrot
04:47 cconstantine joined #parrot
04:51 plobsing woot! just finished a rewrite of tools/build/nativecall.pl in PIR.
04:57 cotto w00t to you sir
04:57 cotto plobsing++
04:58 cotto you could also use nqp
04:58 * cotto hopes not to hear a headdesk
05:03 plobsing cotto: I tried. did not enjoy.
05:04 cotto The learning curve can be really annoying.
05:04 darbelo Hm. That didn't work as expected.
05:04 cotto You've learned something.
05:05 darbelo That exploratory programing should be done after fixing the build.
05:12 cotto "explodatory" programming?
05:13 cconstantine joined #parrot
05:13 darbelo It would have been. If I hadn't broken the build before trying :)
05:13 plobsing cotto: it's not really the learning curve, it's that NQP has a different market which drives the design in directions that don't work out well for me
05:14 darbelo "Lets see if this works... It's no more broken than before! I'm sure it will work when I fix all of the other problems!"
05:27 cconstantine_ joined #parrot
05:27 * cotto wonders how "r->color  = add_const_str(interp, r);" ever made sense to someone
05:27 cconstantine joined #parrot
05:28 cotto pirc can't be ready soon enough
05:31 dalek parrot: r43646 | plobsing++ | trunk/tools/build/nativecall.pl:
05:31 dalek parrot: eliminate return_type_decl field in nativecall.pl
05:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43646/
05:31 dalek parrot: r43647 | plobsing++ | trunk/tools/build/nativecall.pir:
05:31 dalek parrot: rewrite nativecall.pl in PIR.
05:31 dalek parrot: TODO: figure out how to work this into the build system
05:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43647/
05:31 cotto yay!  We get our first chicken and egg problem!
05:32 cotto well, another one
05:32 cotto plobsing, you could check in a generated src/nci.c and make an optional target to rebuild it
05:35 plobsing cotto: my plan is to build miniparrot with a null_nci.c and then use it to build the full parrot
05:35 plobsing we already do that for config I beleive
05:35 plobsing the version controlled generated files is my fallback
05:36 darbelo So, miniparrot can't do NCI?
05:36 darbelo Not a huge loss.
05:37 cotto Isn't nci used internally for something?
05:37 plobsing cotto: methods on C-based PMCs
05:37 plobsing otherwise, internally we use raw nci PMCs, which don't need the frame builder thunks
05:37 darbelo Oh. CRAP.
05:38 darbelo ./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
05:38 darbelo Method 'visit_freeze_normal' not found
05:38 darbelo current instr.: 'main' pc 1214 (config_lib.pasm:324)
05:38 * darbelo facepalms.
05:38 * plobsing mentioned trying to stick to VTABLEs on the wiki. they make life so much easier
05:39 darbelo Yeah.
05:39 darbelo I see that now.
05:43 cconstantine_ joined #parrot
05:54 eternaleye joined #parrot
05:59 nopaste "tene" at 76.27.121.193 pasted "broken lazy gather/take for pmichaud" (124 lines) at http://nopaste.snit.ch/19414
06:02 pmichaud you're missing a pop_eh in "caught"
06:02 pmichaud should go right after the .get_results
06:03 Tene ><
06:03 pmichaud (no, it probably shouldn't matter.)
06:04 pmichaud other than that, your code looks to me like it ought to work
06:05 Tene It does work, for the simple cases.  Try calling .get twice on the returned iter, though.
06:05 pmichaud how are you getting the returned iter?
06:05 pmichaud just a sec, I'll apply locally and see what I see
06:05 Tene my $x = gather ...
06:06 pmichaud have a good failing test?
06:06 Tene my $x = gather for 1..10 { take $_*2 }; say 'A'; say $x.get; say 'B'; say $x.get;
06:07 Tene Oh, that fails differently than it did before...
06:07 pmichaud yeah, forgetting to pop an exception handler introduces odd behaviors.
06:08 Tene ah, because I popped the eh, yes.
06:08 Tene The problem is that the second time in .get, it invokes a continuation that then throws back into *the first .get* call.
06:08 pmichaud ohhhhhhhhh crap
06:09 Tene yeah, see?
06:09 Tene I had a way to deal with this before, but I don't remember it.
06:10 pmichaud this is where we really need Parrot to fix its roll-up semantics
06:11 Tene I think I kinda know what we can do... lemme go explore a bit.
06:12 pmichaud if you just want to do an eager implementation for now, that's fine also.
06:12 pmichaud having a working gather/take is more important than a lazy one at this point
06:12 pmichaud (since a lot of our builtins depend on it)
06:12 Tene what data type should gather {}; return, then, in the new world order?
06:13 pmichaud GatherIterator is fine for now
06:13 Tene oh, but just prepopulate a list that it walks over, or something?
06:13 pmichaud oh, you mean for an eager one
06:13 pmichaud you can create a Parcel with the returned values
06:13 pmichaud so, Parcel
06:14 Tene 'k
06:14 pmichaud basically    $P0 = new ['Parcel']
06:14 pmichaud and then push the payload from each take exception onto $P0
06:14 pmichaud (note that it has to be the opcode push, not the method call)
06:16 pmichaud that's..... weird
06:17 pmichaud (looking at the results after the patch, w/pop_eh remembered)
06:17 Tene I'll go do that first, and then go play stack gymnastics.
06:17 pmichaud hmmm
06:17 pmichaud continuations might not be a workable way to do this
06:18 pmichaud or we might need a helper block somewhere
06:18 Tene the latter is what I was going to explore.
06:18 pmichaud I think I know what is happening--want the gory details?
06:20 cotto Just as a sanity check, the things in a PackFile's constants table are never modified, right?
06:20 pmichaud afaik
06:20 pmichaud oh, maybe not
06:20 pmichaud I know subs get modified
06:20 cotto I care about strings.
06:20 pmichaud I'm not sure what all goes in the constants table
06:20 pmichaud anyway, very few things in Parrot actually seem to be constant :-|
06:21 pmichaud Tene: When we resume back into the block, it thinks its caller is the first get invocation
06:21 pmichaud (and it is.)
06:21 Tene pmichaud: Yes, exactly what I said.
06:23 Tene Well, approximately what I said.
06:23 pmichaud my best guess is to use a coroutine (yield) here.
06:23 Tene I'll try that, too.
06:24 pmichaud essentially, the coroutine is the wrapper
06:24 * pmichaud drafts
06:24 Tene Ah, yes, I see.
06:24 Tene I'll try exactly that, after I test this eager gather patch.
06:25 pmichaud want me to draft code for it?
06:25 pmichaud actually, the coroutine is almost exactly the eager gather patch :-)
06:25 pmichaud except instead of pushing into a parcel, you yield the payload back to the caller :-)
06:26 Tene Still want me to push this eager gather commit?
06:26 pmichaud either push it or nopaste it
06:26 pmichaud push is fine if it works :-)
06:27 pmichaud then I'll make suggestions for making it lazy :)
06:31 Tene Oops, forgot that the bot doesn't see ng1.
06:31 Tene I pushed a while ago.
06:31 pmichaud ah
06:36 pmichaud looking/working
06:36 pmichaud (looks good so far)
06:36 Tene Writing a coro-based sketch in PIR now.
06:36 pmichaud same here.
06:36 pmichaud I'm just going to draft, then let you steal/debug :)
06:43 nopaste "pmichaud" at 66.25.4.52 pasted "draft of gatheriterator (for Tene++)" (102 lines) at http://nopaste.snit.ch/19415
06:44 pmichaud I moved !GATHER out of control.pir and into GatherIterator
06:45 Tene Looks like what I have.  I'll report back in not too long.
06:46 pmichaud okay, great
06:56 Tene Parrot seems to break when I try it with lexicals... seems capture_lex doesn't work on coroutines, or something.  Works fine when I save state in the GatherIterator, though.
07:02 Tene oh, newclosure instead?
07:03 Tene Oh, no, that doesn't help either.  I'll stick with the attribute version.
07:12 cconstantine joined #parrot
07:19 pmichaud oh, I suspect you're right about coroutines and lexicals
07:22 Tene s'okay, it's working.
07:23 Tene I just spent 15 minutes hunting a typo. :)
07:27 nopaste "tene" at 76.27.121.193 pasted "working lazy gather/take example" (21 lines) at http://nopaste.snit.ch/19416
07:34 fperrad joined #parrot
07:35 pmichaud Tene++
07:35 eternaleye joined #parrot
07:38 nopaste "tene" at 76.27.121.193 pasted "Another fun example" (15 lines) at http://nopaste.snit.ch/19417
07:42 eternaleye joined #parrot
08:39 treed joined #parrot
08:46 treed joined #parrot
08:49 sri joined #parrot
08:50 treed joined #parrot
09:15 patspam joined #parrot
09:20 Tene pmichaud: right now, some weird stuff happens in some cases with gather/take.  I can only reproduce it when it's in a method on a class, not standalone.
09:20 nopaste "tene" at 76.27.121.193 pasted "Weird breaking case for pmichaud++" (21 lines) at http://nopaste.snit.ch/19418
09:52 iblechbot joined #parrot
09:55 TimToady joined #parrot
09:58 chromatic joined #parrot
10:06 cotto_w0rk joined #parrot
10:07 dalek parrot: r43648 | cotto++ | trunk/src/packdump.c:
10:07 dalek parrot: [packfile] make pbc_dump output line up more nicely
10:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43648/
10:10 estrabd joined #parrot
10:14 bacek_at_work joined #parrot
10:18 cotto_w0rk joined #parrot
10:18 cotto_w0rk joined #parrot
10:21 cotto_work joined #parrot
10:23 dalek parrot: r43649 | mikehh++ | trunk/MANIFEST:
10:23 dalek parrot: Re-generate MANIFEST
10:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43649/
10:23 dalek parrot: r43650 | mikehh++ | trunk/tools/build/nativecall.pir:
10:23 dalek parrot: Add svn properties
10:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43650/
10:23 cotto The pbc code makes me sad.  I need to go to bed.
10:24 cotto I can't believe Parrot's running on top of that mess.
10:24 athomason joined #parrot
10:24 cotto Actually that's not true.  I can believe it.
10:24 cotto sleep &
10:30 workbench joined #parrot
10:30 estrabd joined #parrot
10:30 TimToady joined #parrot
10:30 hudnix joined #parrot
10:30 jsut joined #parrot
10:30 jjore joined #parrot
10:30 purl joined #parrot
10:30 Infinoid joined #parrot
10:30 Khisanth joined #parrot
10:30 FullMetalHarlot joined #parrot
10:30 wagle joined #parrot
10:30 nopaste joined #parrot
10:30 eiro joined #parrot
10:30 confound joined #parrot
10:30 cxreg joined #parrot
10:30 Ryan52 joined #parrot
10:30 rhr joined #parrot
10:30 zostay joined #parrot
10:39 dalek parrot: r43651 | mikehh++ | trunk/tools/build/nativecall.pir:
10:39 dalek parrot: fix codetest failure - trailing spaces
10:39 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43651/
10:43 eternaleye joined #parrot
11:05 mikehh fulltest - testr FAIL - t/pmc/eval.t - Failed test:  12 - see TT #1142
11:05 mikehh all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#32001), fulltest) at r43651 - Ubuntu 9.10 amd64 (gcc)
11:06 mikehh that should be (gcc with --optimize)
11:09 purl joined #parrot
11:18 cotto joined #parrot
11:31 iblechbot joined #parrot
11:34 joeri joined #parrot
11:35 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32002), fulltest) at r43651 - Ubuntu 9.10 amd64 (g++ with --optimize)
11:46 cconstantine_ joined #parrot
12:15 cotto joined #parrot
12:15 bit-man joined #parrot
12:22 LaVolta joined #parrot
12:32 bit-man Hi
12:32 purl hi, bit-man.
12:32 bit-man I'm trying to implement opendir et al. and have some problems
12:33 bit-man Following http://docs.parrot.org/parrot/lates​t/html/docs/pdds/pdd22_io.pod.html I see that unlink, rmdir, and opendir must be implemented as opcodes
12:33 bit-man right ?
12:34 bit-man The problem is that I figured out how to implement a PMC but not an opcode
12:35 bit-man I mean seems that unlink and rmdir are not implemented, right ?
12:37 bit-man By chance ... do I have to look at the src/ops folder ?
12:38 cconstantine joined #parrot
12:41 bit-man anyone awake ... I'm at GMT-3 !
12:41 bit-man almost noon at Europe and toooo early for US
12:51 cognominal joined #parrot
12:59 fperrad bit-man, I think pdd22_io is out of date, these features are implemented in the OS PMC, see methods rm & readdir
13:00 bit-man So they must be implemented not as op codes but as OS PMC methods ?
13:03 bit-man fperrad, thanks !
13:08 fperrad bitman, the method rm implements unlink & rmdir
13:08 fperrad the method readdir implements opendir/readdir/closedir
13:08 fperrad but try http://trac.parrot.org/parrot/ticket/1322
13:10 bit-man fperrad, the problem with readdir is that just returns pathnames as strings
13:11 bit-man fperrad, I mean all of OS PMC returns and accepts strings then there's no need to return some FileHandle PMC right
13:12 bit-man fperrad, Just lets play with strings
13:12 bit-man Am i right ?
13:13 NotFound What kind of filehandle can rm return?
13:14 bit-man not rm but other methods like readdir
13:15 fperrad bit-man, the opcode open returns a FileHandle PMC
13:15 NotFound Makes more sense to me not having readdir or closedir methods, just opendir.
13:16 bit-man fperrad, yes but open cant'be used on folders
13:16 NotFound Then read from and close the object returned by opendir.
13:16 bit-man NotFound, for me too but because I was reading pdd22_io and the scenario depicted was completely different
13:17 bit-man then I thought the dir management methods were not implemented
13:17 bit-man or that readdir as implemented that way only for some internal usage
13:18 fperrad OS.readdir() returns an array of pathname, it encapsulates all POSIX stuff ie. opendir/readdir/closedir
13:19 NotFound Which is not very consistent with the interest in lazy lists.
13:20 bit-man fperrad, sure and it's great but because pdd22_io was referring to opendir/reddir/closedir then I thought that an implementation according o it was needed
13:20 bit-man NotFound, Sorry I don't understand you :-P
13:20 kid51 joined #parrot
13:22 NotFound bit-man: there is a lot of interest in lazy evaluation in perl6 and parrot. Encapsulating the directory opening/reading/closing in one operation is the opposite way.
13:23 NotFound Just imagine a directory with 1e10 entries to see the difference.
13:23 bit-man NotFound, got it
13:23 bit-man NotFound, :-)
13:24 NotFound I've worked with directories of several hundred milliards entries in real work, BTW.
13:27 bit-man Then would be wise to get a single readdir that encapsulates opendir/readdir/closedir
13:28 bit-man but that instead of returning an array returns a kind-of-iterator that only reatieves the next entry open request
13:28 bit-man and doesn't obtains them all and you iterate through using the Iterator PMC right ?
13:30 NotFound Good idea. Iterating should be faster and shorter than calling methods.
13:53 dalek parrot: r43652 | jkeenan++ | branches/tt1393_retcon:
13:53 dalek parrot: Creating tt1393_retcon in �https://svn.parrot.org/parrot//branches
13:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43652/
13:53 dalek parrot: r43653 | jkeenan++ | tags/tt1393_retcon-43651:
13:53 dalek parrot: Tagging trunk at r43651 so that the tt1393_retcon can later be synched to it.
13:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43653/
14:09 dalek parrot: r43654 | jkeenan++ | branches/tt1393_retcon/src​/pmc/retcontinuation.pmc:
14:09 dalek parrot: Deleting statement as suggested by lithos in �http://trac.parrot.org/par​rot/ticket/1393#comment:29.
14:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43654/
14:23 hercynium joined #parrot
14:39 cconstantine joined #parrot
14:58 TonyC joined #parrot
15:00 mikehh kid51: I get the same result in tt1393+retcon branch as in trunk
15:00 mikehh tt1393_retcon branch - fulltest - testr FAIL - t/pmc/eval.t - Failed test:  12 - see TT #1142
15:00 mikehh all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r43654 - Ubuntu 9.10 amd64 (gcc with --optimize)
15:02 kid51 mikehh  Thanks for the tests.
15:02 kid51 afk
15:02 mikehh joined #parrot
15:02 mikehh I was hoping that maybe TT #1142 might have got fixed, but unfortunately not - it only fails with gcc on amd64 - passes with g++ on amd64 and all variants on i386
15:02 lichtkind joined #parrot
15:13 plobsing_ joined #parrot
15:17 PacoLinux joined #parrot
15:24 pmichaud joined #parrot
15:24 Whiteknight joined #parrot
15:30 mikehh joined #parrot
15:35 tetragon joined #parrot
15:35 Psyche^ joined #parrot
15:36 cognominal joined #parrot
15:44 mikehh joined #parrot
15:48 cotto joined #parrot
15:54 mikehh joined #parrot
16:06 eternaleye joined #parrot
16:09 mikehh joined #parrot
16:15 dalek left #parrot
16:15 dalek joined #parrot
16:25 dalek winxed: r378 | julian.notfound++ | trunk/winxedst1.winxed:
16:25 dalek winxed: replace literal '__eval__' with a const string
16:25 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=378
16:28 mikehh joined #parrot
16:50 ash_ joined #parrot
16:54 mikehh joined #parrot
16:59 theory joined #parrot
17:12 ash_ joined #parrot
17:14 ash_ left #parrot
17:18 jan joined #parrot
17:18 cotto Coke, ping
17:19 mikehh joined #parrot
17:36 fperrad_ joined #parrot
17:43 pdcawley_ joined #parrot
17:59 davidfetter joined #parrot
18:10 mikehh joined #parrot
18:33 Whiteknight joined #parrot
18:55 Whiteknight can somebody explain to me how hash freeze/thaw works?
18:55 Whiteknight because looking at hash.pmc:freeze and thaw, it doesn't look like any of the values in the hash are actually serialized
18:56 Whiteknight and I seriously don't understand how the thaw() works there, or where those values are supposed to be coming from
19:00 theory joined #parrot
19:09 cotto The actual work happens in src/hash.c hash_visit.  From what I remember, hash_freeze and hash_thaw are called via hash_visit via the visit VTABLE function.
19:09 cotto It's a mess and took me a while to figure out back when I worked on Pipp's arrays.
19:10 cotto I think the freeze/thaw VTABLEs are called before/after visit and that visit does most of the work.  Don't ask me why.
19:11 plobsing_ freeze/thaw are for visiting non-recursive contents. visit is for recursing. it's to maintain some tree traversal ordering or something like that, even though we're not traversing a tree
19:12 cotto that makes sense
19:13 plobsing_ it makes less sense than I'd like.
19:14 cotto considerably
19:14 mikehh but there still seem to be problems thewre - see my latest comment (and plobsing++) on TT #1142
19:14 Whiteknight okay, so...how does Hash.thaw() get data from the stream into the Hash?
19:15 Whiteknight or is visit called for both freeze and thaw?
19:15 cotto yup
19:15 Whiteknight urg
19:15 cotto yup
19:15 mikehh :-}
19:16 Whiteknight is there any reason why this is all so retarded?
19:16 plobsing_ Whiteknight: the values are pulled into the hash in src/hash.c:hash_thaw()
19:16 plobsing_ look for the VTABLE_shifts
19:17 Whiteknight plobsing: would you mind taking a look at the kill_array_pmc branch?
19:17 Whiteknight I'm getting a failure in AddrRegistry.thaw, which is just a subclass of Hash
19:18 Whiteknight it's failing the assertions in Hash.thaw when that gets called
19:22 plobsing_ what are the key and entry types it is trying to use?
19:22 Whiteknight AddrRegistry uses a keytype of 3, and a value type of -92 apparently
19:22 Whiteknight that's according to GDB, I need to look up the actual value of that enum
19:23 plobsing_ -92 seems pretty bogus to me
19:26 Whiteknight that's what GDB says for "p (int)enum_type_int"
19:29 plobsing_ Whiteknight: what test is failing?
19:30 Whiteknight all the t/pmc/packfile* tests
19:30 Whiteknight packfile.t, packfileannotations, packfilesegment, etc
19:31 plobsing_ hmmm...you probably did something that rearanges the PMCs in the image (which means you need to bump PBC_COMPAT)
19:31 plobsing_ and regen the test pbcs
19:31 Whiteknight how to regen the test bpcs?
19:31 Whiteknight pbcs?
19:32 plobsing_ run tools/dev/mk_native_pbc on i386
19:32 Whiteknight damnit.
19:33 * Whiteknight boots up his Ubuntu/x86 VM
19:35 plobsing_ alternatively, you could modify mk_native_pbc to run anywhere and fix the ensuing bugs on i386 systems that probably can't read 64 bit PBCs
19:37 chromatic joined #parrot
19:40 Whiteknight at least I have a Linux/x86 setup where I can run this stuff now
19:49 NotFound mikehh: TT #1142 doesn't fail for me in amd64
19:49 dalek parrot: r43655 | whiteknight++ | branches/kill_array_pmc/PBC_COMPAT:
19:49 dalek parrot: bump PBC_COMPAT on suggestion from plobsing++
19:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43655/
20:02 plobsing_ NotFound: it comes and goes, but can be reliably reproduced with 'make testgcd'
20:06 davidfetter joined #parrot
20:07 dalek parrot: r43656 | whiteknight++ | branches/kill_array_pmc/t/native_pbc (4 files):
20:07 dalek parrot: native_pbc platform updates
20:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43656/
20:07 Whiteknight plobsing++ # bumping PBC_COMPAT worked. All tests pass in branch
20:11 mikehh NotFound: it passes for me with g++ and on i386 - it only seems to fail with gcc and only if it invokes GC mark/collect (which could make it intermittant)
20:13 chromatic You need to disable memory randomization if you're running Linux.
20:13 chromatic alias freezemem='sudo echo 0 > /proc/sys/kernel/randomize_va_space'
20:14 Whiteknight purl msg bacek once the kill_array_pmc branch merges into trunk, we can update gc_encapsulate and should not have any of the current problems with it.
20:14 purl Message for bacek stored.
20:19 Whiteknight parrot-linear-algebra passes all tests on branch
20:21 Whiteknight I have a couple ideas in mind for performance improvements to ResizablePMCArray
20:21 Whiteknight maybe that might make a good branch in the near future
20:21 plobsing_ Whiteknight: are those on ArrayTaskList?
20:21 Whiteknight plobsing_: no, these are ideas I've only had recently
20:21 Whiteknight more exploratory than "to do"
20:23 dalek parrot: r43657 | whiteknight++ | branches/kill_array_pmc/DEPRECATED.pod:
20:23 dalek parrot: remove notice about Array PMC from DEPRECATED.pod
20:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43657/
20:28 Whiteknight that might be an issue with the pmc_freeze_with_pmcs branch too. Probably needs to bump PBC_COMPAT after adding the ImageIO PMC
20:30 Whiteknight purl msg darbelo: On pmc_freeze_with_pmcs branch, I think you can bump PBC_COMPAT to fix most of your test failures
20:30 purl Message for darbelo stored.
20:33 Whiteknight actually, I'll test that right now while I have VirtualBox fired up
20:46 Whiteknight purl msg darbelo: I just tested locally. bumping PBC_COMPAT fixes some tests but not all of them. Still plenty of failures in the packfile* tests
20:46 purl Message for darbelo stored.
20:55 mj41 joined #parrot
20:56 jan joined #parrot
20:58 ttbot joined #parrot
21:34 PerlJam joined #parrot
21:54 eternaleye joined #parrot
21:58 davidfetter hello
21:58 purl salut, davidfetter.
21:58 davidfetter is there some way to arrange for parrot not to use threads?
22:00 dalek parrot: r43658 | mikehh++ | branches/kill_array_pmc/PBC_COMPAT:
22:00 dalek parrot: PBC_COMPAT requires a tab separated list
22:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43658/
22:01 mikehh whiteknight: I get a couple of t/library test failures in make test for kill_array_pmc branch (Class 'Array' not found) in t/library/range.t and t/library/test_more.t
22:02 mikehh davidfetter - supposed to be but aparently it still loads the threads module
22:02 davidfetter hrm
22:02 * davidfetter thinks threads are just generally fail
22:02 davidfetter it's that paper from cal that really convinced me
22:03 davidfetter http://www.eecs.berkeley.edu/Pub​s/TechRpts/2006/EECS-2006-1.pdf
22:09 Infinoid ... is that a problem with threads, or a problem with most languages that use threads?
22:11 pmichaud messages
22:18 kid51 joined #parrot
22:20 mikehh davidfetter: interesting paper - I agree with infinoid however - functional typy languages are much better than imperative ones in handling threads
22:21 mikehh or should I say concurrency
22:22 davidfetter mikehh, that paper pretty much convinces me that the whole thread concept is fundamentally broken
22:24 mikehh not really, just depends on how you use it - its a bit like the halting problem, in theory it's out to lunch but still we get meaningful work done
22:26 mikehh oh and also a lot a of junk (garbage :-}) of course
22:42 Infinoid I prefer to let other, smarter people than me talk about how to do concurrency well at the language level.  My main problem these days is that C just isn't particularly well equipped to handle threads, and I can think of several other languages that aren't much better
22:43 Infinoid when you set out to write a threaded application from the start, you usually end up pretty well off.  But I can't even imagine how many hacker hours were spent retrofitting threads into existing apps
22:44 Infinoid to do this right, gcc would have to give me a big fat warning when I get it wrong, like, "warning: you forgot to unlock, you dork"
22:46 mikehh to work with something like threads is would be better if the abstraction level was a bit higher, as with garbage collection - it should be implicit rather than explicit
22:46 Infinoid an __attribute__((must_be_lock​ed_before(this_other_var))) would not be amiss, either
22:46 Infinoid yes.  the C threads API is very much nuts-and-bolts
22:46 NotFound Are you calling for Ada?
22:47 mikehh yes - we shouldn't be dealing with it directly
22:47 mikehh go seems to have an interesting approach
22:48 NotFound The gane?
22:48 NotFound The game?
22:48 purl The game is to get a mild case of HSV
22:48 mikehh no golang.org
22:48 NotFound http://code.google.com/p/go/issues/detail?id=9
22:50 PacoLinux joined #parrot
22:50 Infinoid hah, Issue 9!  It reminds me of plan 9 from outer space
22:51 NotFound Note that the issue is date Nov 10 and the status is still "New"
22:52 mikehh most of the same bunch are involved -:-}
22:52 NotFound Infinoid: a little late for that type of jokes, the thread is full of them X-)
22:53 NotFound mikehh: yeah, some "NotFound" for example.
22:53 Infinoid NotFound: I make being late into an art form :)
22:55 NotFound mikehh: forget it, I misunderstood
22:55 purl NotFound, I didn't have anything matching it, i misunderstood
23:02 dalek winxed: r379 | julian.notfound++ | trunk/Makefile:
23:02 dalek winxed: add a 'pir' make target for future setup usage
23:02 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=379
23:04 theory joined #parrot
23:09 * kid51 reads that paper
23:10 mikehh kid51: I tested tt_1393_retcon on Ubuntu 9.10 i386 up to fulltest using g++ with --optimize and gcc  -with --optimize - all ok
23:11 kid51 That's good news.
23:11 kid51 I hope to get some reports from other interested parties, e.g., Util
23:11 dalek winxed: r380 | julian.notfound++ | trunk/setup. (2 files):
23:11 dalek winxed: Testing setup for plumage usage
23:11 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=380
23:12 kid51 Is there anyone on channel now who could test a branch on Win32?
23:14 NotFound kid51: I can, but on my old laptop not very fast
23:14 kid51 speed is definitely not of the essence
23:15 NotFound Booting it...
23:15 kid51 Can you do a smoke on the tt_1393_retcon branch?
23:17 kid51 "... pruning a wild mass of brambles rarely yields a satisfactory hedge."  Nice.
23:20 NotFound kid51: checking out...
23:20 purl i guess checking out is so much work
23:20 kid51 It's actually spelled:  tt1393_retcon
23:22 mikehh just on the threads issue - quoting Rob Pike
23:22 mikehh And Go is a really good language for writing multiplex servers in, where you use these things called 'go' routines, which are
23:22 mikehh kind of like threads but lighter-weight, and some communication primitives to do the multiplexing.
23:23 patspam joined #parrot
23:26 kid51 "If [Intel is] successful, and the next generation of programmers makes more intensive use of multithreading, then the next generation of computers will become nearly unusable."
23:32 cconstantine joined #parrot
23:33 NotFound The funny thing is that the multithread dance started at the times of OS/2 1.0
23:34 dngor OS/2 was threads all the way down.
23:34 NotFound More or less the same as speech recognition.
23:35 NotFound dngor: yes, and almost nobody knew how to put them to good use... just like now.
23:50 cconstantine joined #parrot
23:57 NotFound Oh, great, I must reboot windows to finish install of some cpan module :/

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

Parrot | source cross referenced