% davidfetter has left davidfetter!~davidfett@start.fetter.org % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se % darbelo has left darbelo!~darbelo@190.3.135.207 % Psyche^ has joined #parrot % ask_ has left ask_!~ask@pat-tdc.opera.com % Patterner has left Patterner!~Psyche@e177113108.adsl.alicedsl.de % Psyche^ is now known as Patterner r26688 | kjs++ | trunk: : [NEWS] add news about added operators to NQP diff: http://www.parrotvm.org/svn/parrot/revision?rev=26688 r26689 | allison++ | trunk: : [pdd] Completed the core architectural component of the Strings PDD. Still : adding API sections. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26689 someone can add to the perl6 status that hash composer is missing and array composer buggy % skv has joined #parrot % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk % dalek has left dalek!dalek@feather.perl6.nl % PerlJam has left PerlJam!duff@feather.perl6.nl % jonathan has left jonathan!jonathan@feather.perl6.nl % wolverian has left wolverian!wolverian@feather.perl6.nl % leo has left leo!lt@feather.perl6.nl % pmichaud has left pmichaud!pmichaud@feather.perl6.nl % Juerd has left Juerd!juerd@feather.perl6.nl % ruoso has joined #parrot % kj has joined #parrot * diakopter notes that [the link to] feather is down. % dalek has joined #parrot % PerlJam has joined #parrot % wolverian has joined #parrot % jonathan has joined #parrot % pmichaud has joined #parrot % Juerd has joined #parrot % leo has joined #parrot % Infinoid has left Infinoid!infinoid@omgwtfbbq.info % kid51 has joined #parrot % contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com % muixirt has joined #parrot % contingencyplan has joined #parrot % skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net % rdice has joined #parrot % kid51 has left kid51!~jkeen@pool-70-107-8-43.ny325.east.verizon.net % particl1 has joined #parrot % Infinoid has joined #parrot % particle has left particle!~particle@c-24-19-3-148.hsd1.mn.comcast.net % wknight8111 has joined #parrot % skids has joined #parrot % IllvilJa has joined #parrot % gryphon has joined #parrot % ruz has left ruz!~cubic@85.112.113.222 % ask has joined #parrot % ruz has joined #parrot is parrotcode.org down? looks like the dns was hacked pmichaud@orange:~$ nslookup parrotcode.org Server: 192.168.1.1 Address: 192.168.1.1#53 oops, wrong address -- never mind <-- tired ping works to parrotcode.org, but no response on port 80 ok someone volunteer to report the issue (after verifying) to webmaster@perl.org ? r26690 | coke++ | type_ids: : [tools] : parrotbug requires a configure'd parrot to work. Be more gentle when : informing the users about it. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26690 I just loaded www.parrotcode.org just fine. particl1: does parrotbug ``work'' on windows? % sjansen has joined #parrot (or anyone else with windows. =-) If so, I think we can resolve RT41601 % particl1 is now known as particle i guess i should ttake a look... % peepsalot has joined #parrot * particle reconfigs and rebuilds it appears to be working for me now * Coke notes that parrotbug just needs a config. ==> Sending message to recipient... I am terribly sorry, but I cannot find sendmail, or a close equivalent, and the perl package Mail::Send has not been installed, so I can't send your bug report. We apologize for the inconvenience. So you may attempt to find some way of sending your message, it has so, i gotta get a module or two I assume it tells you where the file was saved? i'll retry after installing them yep, i must have been throttled away So you may attempt to find some way of sending your message, it has been left in the file 'C:\Users\particle\AppData\Local\Temp\bugrep05840'. % AndyA has left AndyA!~andy@82.152.157.85 that's the text of the message, but not any of the other info (category, severity, etc) presumably that's in the file. I'd say that's "working". =-) * Coke finds another email address that might be the guy that owns the macport. i've installed Mail::Send and am trying again % Theory has joined #parrot % AndyA has joined #parrot ==> Sending message to recipient... Died at C:/usr/bin/perl-5.10.0/site/lib/Mail/Mailer.pm line 284, line 7. it's b0rk Ok. if you have time, a patch would be great, otherwise I can take a look at it at home at some point. r26691 | coke++ | trunk: : [docs] : "I am happy to report improvements for both cc and gcc since last time I : ran a full 'make test'." -- Andy Dougherty (RT #52376) diff: http://www.parrotvm.org/svn/parrot/revision?rev=26691 % Andy has left #parrot * Debolaz tries to run a binary perl6 and gets a coredump in his face. % jan has joined #parrot Debolaz: what platform? Well, it did work for some things, but when I tried to declare a class with a method it went up in flames. FreeBSD 7 maybe try it with parrot perl6.pbc instead of the binary or submit it to rakudobug@perl.org and we can take a look perl6.pbc worked fine. hmmmm must be something to do with compile/link. Or perhaps a GC issue. I'd definitely report it to rakudobug then using pbc_to_exe-generated executable also blew up my squaak compiler once % davidfetter has joined #parrot % Psyche^ has joined #parrot % Patterner has left Patterner!~Psyche@e177115046.adsl.alicedsl.de % Psyche^ is now known as Patterner % barney has joined #parrot % kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl r26692 | bernhard++ | trunk: : Let svn ignore the generated, that is copied, file exec_dep.c. : Clean up exec_dep.c diff: http://www.parrotvm.org/svn/parrot/revision?rev=26692 pmichaud: ping pmichaud: can you take http://rt.perl.org/rt3/Ticket/Display.html?id=44447 ? even if all you do is add a note about how to move forward? % barney has left barney!~bernhard@dslb-084-058-181-232.pools.arcor-ip.net % barney has joined #parrot % peeps[work] has joined #parrot coke: sure, I'll take care of it. :-) Done. % mncharity has joined #parrot sehr gut, thanks. * Coke now has 30 rt tickets. 44+751+95 890 45 + 751 + 95 891 % rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com barney: that should refer to the similar ticket for perl6. hi. I'm groveling over the PAST spec, and will likely leave a trail of comments as I go. Questions/comments would be welcome and appreciated. tnx. in http://www.parrotcode.org/docs/pdd/pdd26_ast.html , Var scope() "package" refers to a possible 'namespace' attribute, which is otherwise unmentioned as a possible attribute of Var. these are better sent to the list, so they're not forgotten. r26693 | bernhard++ | trunk: : [HQ9+] : No need to load non-existing 'hq9plus_group'. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26693 PS in 9 coke: i'll likely be a bit late shower & * Infinoid practices his inflection and tone. "Berift of life, it rests in peace! If you hadn't nailed it to the perch, it'd be pushing up the daisies!" % chromatic has joined #parrot #ps in 2 particle: re list post, please feel free? the exercise of seems rather a misson creep. mncharity: yes, but you're more likely to get results if you inconvenience yourself instead of us. =-) re pdd26_ast.html , similar issue with Var slurpy() mentioning a 'named' attribute, which is not otherwise documented as a possible Var attribute. Oh, wow, I'm here again during #ps. re inconvenience, ah, ok - my purpose is synthesizing an IR node set I can use for a few weeks from kp6/redsix/STD5/PAST. the "reports of PAST doc oddities" is a side effect. well, not entirely, also an opportunity to hear "oh, that's gone now, we punted that because x". but what gets done with the observations is out of my mission scope. ;) they're basically fyi's. mncharity: you don't need to join, you only need to mail p2 and wait for a moderator to approve I'm still unclear as to the goal of redsix etc; mind enlightening me or at least attempting? particle: you back? yep chromatic: to win! oh ... that's probably something different :) chromatic: sure, let's see... redsix was a 2006 quick (order month) implementation of p6 in ruby. There's a history in http://svn.pugscode.org/pugs/misc/pX/Common/redsix/2006/README , but basically, pugs had gotten stuck, so redsix was written as a non-haskell pugs, set up to boostrap into p6. mncharity's url is at http://xrl.us/biqr5 What do you get out of the bootstrap? mncharity: named is an attribute for all PAST nodes, not just PAST::Var. (It may be undocumented, yes.) mncharity: you're correct that PAST::Var is probably missing documentation for the namespace attribute. the project ran over my time budget, and pugs got unstuck for a while, so it became inactive. it occasionally got dusted over the years, but basically hasn't been worked on since. so that's redsix. re 'named', ah, ok. not just 'name', but 'named' too. got it. tnx I agree it's a lot to put on one character difference -- but I went with named to match the parrot calling conventions (which also uses "named") 'name' is the name of the variable or block 'named' is how it's referred as a named parameter in a call re 'What do you get out of the bootstrap?', the ability to work in p6. which is a much nicer language to write language implementation in than p5/ruby/common-lisp/smalltalk/etc/etc. as well as being a nice target state. You need to have a platform on which to run it though. % ruoso has left ruoso!~ruoso@195.23.92.2 re need platform, indeed. and in so far as some platform doesn't quite match the intended use, there is cost. but there's also a world of effort invested in compilers for assorted languages, etc. some platforms will no doubt give much better performance than others for different aspects of p6. someone suggested yesterday a fortran backend for large-scale numerical computing. :) Yeah, but someone has to write it. re one character difference, oh, np, I was just repeating to make sure I understood. re 'someone has to write it', or have written it. indeed. Is redsix such a platform then? re 'goal of redsix etc', one etc is elf, my current focus. it's a bootstrapped backend (using an external parser, while waiting for STD to become usable, to then become fully bootstrapped). it's intent it to provide people the ability to start creating large-scale p6 programs. pugs never quite got there. What's the underlying platform? mncharity: Say I was such a person, how would I use elf to create large scale perl 6 programs? re 'Is redsix such a platform then?', no. a ruby backend might be interesting, because the ruby object model is looks to be close enough to p6 to be able to use it fairly directly, and thus with fairly low overhead. but while some of the ideas from redsix might be recycled, the redsix codebase is dead. fairly thoroughly dead now that elf is working. re elf underlying platform, the current one is p5. a Moose-ish p5 mostly. but a derivative which trades some Moose foundation-for-correctness for a more-hackish-but-faster p5 code, has been suggested. re 'how would I use elf to create large scale perl 6 programs', wait a few days? :) http://svn.pugscode.org/pugs/misc/elf/elf_c_src/README shows how how elf_c, the most recent elf, compiles it self. basically whole-program compilation of the mentioned p6 files. the intent is to get that down to something like ../elf_c -x -o ../elf_c1 ElfC.pm . but, mncharity: how much of STD does elf grok? Or, put another way, what's missing? the dialect of p6 supported is currently quite narrow and kludgey. mostly characterized by "whatever was quick and easy for the bootstrap". vague plan is modularize (so people can easily resume work on the backends they were pursuing before hitting kp6, or longer ago, pugs, limits), less icky IR which can be lived with for at least a few weeks, and start churning out Prelude, backends focused on conformance rather than convenience, and beginning the slog through the test suite. Do you plan to build everything that Perl 5 doesn't support but Perl 6 needs in Perl 6 then? re 'how much of STD does elf grok', zip. well, I haven't tested it - perhaps some code fragments. but it's using STD_red, a copy of STD hand translated badly into ruby, as an external parser. basically, as STD5 matures, it can become an alternate parser. As it matures enough to be plausibly translated back into p6 (eg, "metholate2"), it can use that. and in some distant day it may be up to parsing STD.pm directly. But very not hmm, that was a long entry. if anyone got clipped, sing out. "But very not..." "But very not rsn." % kj has joined #parrot re "Do you plan to build everything that Perl 5 doesn't support but Perl 6 needs in Perl 6 then?", not I. Big picture is I'd like to build most everything in p6. p5 is not a backend which gives me warm fuzzies, but various other people care about it, and it was a plausible place to do the backend bootstrap. my objective with elf is to get other people unstuck. To get people unstuck and able to write Perl 6, you need an AST emitted from a working Perl 6 parser which runs on a working Perl 6 backend? yes. no? % allison has joined #parrot allison: just curious, what's the timeline for concurrency? do we currently do any multithreading? (I'm wondering how effective our testing of Harmony GC will be.) mncharity: I think you're falling into the same trap as other implementations have. "I'll do all this work so that we can get a minimal Perl 6 going and *other people* can finish it off" is the impression I get from you now. Infinoid: yes, we're currently multi-threaded Infinoid: so what we're doing now is implementing the final spec, mainly a matter of refinement and cleanup great, thanks. Infinoid: I don't know if Harmony's GC is going to work with Parrot, it may be too custom to Java's needs to be useful, but it's worth experimenting it sounds like they are actively trying to make it standalone. The question is how big the adaptation layer needs to be, right? ... and how it finds live objects. Infinoid: yes, well, or if an adaption layer is even possible Infinoid: it depends on how great the mismatch of assumptions is It was mentioned earlier that it was at least hoped that version 1.0 of parrot would be ready this year, but when is it expected to be possible to write "real" applications with rakudo, even if not officially condoned and maybe with unstable results? Debolaz: at least you can use the NQP Perl 6 subset :-) is parrot's 1.0 tied to raduko? Infinoid: I suggested to the SoC student that he focus on developing Harmony's API for as a pluggable GC. That alone is a huge summer project Infinoid: Bound and gagged. :-P Debolaz: I expect people to be able to write "real" applications with rakudo by this summer it would help if we knew what features are needed-but-missing (i.e., for prioritizing) Infinoid: well, having a usable implementation of 2 major languages is one of the 1.0 goals Infinoid: currently rakudo and pynie are our top candidates re trap, the hypothesis is indeed something like "the reason people are no longer writing p6 is the same reason *I* haven't been - you can't. attempting non-small code in pugs becomes an exercise in working around pugsbugs, which on the inactive codebase, can't actually be fixed. and kp6 is painfully slow (plus perhaps a couple of other issues)" plus the hypothesis allison: well, I'll make sure he doesn't get blocked on the parrot side of things :) you're right, though, it does sound like a lot of work. pmichaud: So you would encourage me to try implementing things with rakudo and bitch about it when it doesn't work? :) (Or at least make a note of it:) I'm not sure about it being that much work. A good GC only has a couple of entry and exit points in its API. Debolaz: yes, if you can handle a little frustration at times :-) Infinoid: many thanks "if you create a p6 implementation in which people can pursue the things they have already demonstrated interest in pursuing, but give them happy pragmatics (speed, easy customization and stability), then they will return and resume their work". % barney has left barney!~bernhard@dslb-084-058-181-232.pools.arcor-ip.net Debolaz: unfortunately I've been distracted by non-rakudo items for a few months, but that appears to be resolving itself now (now you may have to change all of the rest of the system to have lock points around acquiring GCable items, but that's a different problem) chromatic: one of the things that makes me nervous is: how tied are we to the current GC? the other plugins are in varying stages of functionality, and apparently, they have been for years. Less so than last year. Debolaz: but I would be very happy to hear reports of "I wanted to do this in rakudo but it doesn't work yet" I expect some more bugs to crop up, and I look forward to fixing them. % pelagic has joined #parrot Without some careful thought (or a great deal of luck) I think we'll have trouble with any non-stop-the-world collection. It seems like I should learn a lot about GC internals sometime in the near future. at some point, I'd love it if you could elaborate on that. PerlJam: avoiding "yet another dead-ish p6 implementation" was indeed the defining design objective of the exercise. I believe elf has the right properties, but we'll see. probably within a week or so, as a couple of people seem to be in a busy wait, so if they adopt it, at least someone is unstuck. Mostly the problem is that if you move a GCable element (copying or compacting collector), you have to update all of the pointers to that element before they try to use it. I suppose that means they have to be scanned for, or have backreferences. Infinoid: right, and currently there is no mechanism for backreferences, or intermediate pointers I think that was everyone's questions. Others welcome. /me -> back to IR exploration. mncharity, why build a new platform? re "platform", same meaning a before, a compiler target? *as Right. Every bootstrap needs to run on *something*, whether you emit C from Scheme or Smalltalk or Perl 5 from ELF or PIR/PBC from PCT. Not that PCT is a bootstrap. allison: is such a mechanism proposed, or should I try a couple of halfbaked things and let you guys tell me how wrong I am? :) * Infinoid promises to spend a couple of days trying to wrap his head around all of this stuff, in any case. Infinoid: it's not currently spec'd. In fact, we're not planning to implement a compacting or copying collector until after 1.0 allison: note that we have a few SOC proposals re: gc. % pelagic has left pelagic!~pelagic@15.23.3.213.fix.bluewin.ch Infinoid, a copying collector isn't too bad. If you're willing to live with stop-the-world, we could change pobject_lives() such that it copies or updates. well, Harmony is not a stop-the-world GC, so it sounds like things might break gloriously. We have to pass in the pointer location, but that'll get rid of some boilerplate. Harmony probably requires a read barrier. re 'why build a new platform?', because new platform x gives you something you want that your current ones don't. eg, Moose p5 added for easier and eventually more conformant p6 compilation than the preceeding bare p5. ruby might provide faster method calls, an object system which might be wielded to implement true p6 oo without much overhead, crude jit, and thus be faster and more correct than a p5 platform. a common lisp platform would provide mature and wizzy compilers. ... etc. a 'not-very conformant but compiles to p5-compatible code' might provide the ability to write cpan modules in something like p6. ok. Thanks for the answers, guys. And so you want people who're already working on such a platform that can actually run Perl 6 code today to dump out an AST so that people who are blocking on the non-existence of an as-yet-unwritten platform can ... wait a little longer for that as-yet-unwritten platform to get to the point where they can actually run Perl 6 code? I mean, I can see the theoretical benefits of running on a mature Lisp platform or Smalltalk or Rhino or whatever, but none of those experiments have ever worked beyond "Hey, I can parse Perl 6 lexical variable declarations and simple if/else blocks!" me puzzled by preceeding paragraph... let's see... *previous I'm reading a lot of "this platform might do this" and "that platform could do that", but practically speaking, where's the beef? is "people who're already working on such a platform that can actually run Perl 6 code today to dump out an AST" a reference to earlier interest in getting a yaml dump of ast from rakudo? Yes. ah, ok. re yaml dump of ast, I ended up following pmichaud's suggestion to scrape the --target=parse output, and built a project elf_on_rakudo on it. the parsing ended up being rather slower than I was hoping for, and STD_red seemed to be working fairly well, and so an elf_on_STD_red was done. that then became the current elf. also, yaml turned out to be a problematic interchange format. elf_on_STD_red hit both yaml bugs, and performance issues, eventually switching to a more "I know you are running p5 - here is a dump format you can just eval there" interchange approach. 'match("rule name",0,1,"the text which matched",{...})'. which was much faster and less buggy. You want to write Perl 6 in Perl 6, right? so the "yaml from rakudo parse" is no longer of near-term interest. sorry I didn't gc that sufficiently. yes a dump of PGE matches would still be of interest however. in whatever format Well it's not *my* interest, but I'm only speaking for myself. I've no interest in telling other volunteers what to do. I wasn't suggesting it was. r26694 | allison++ | trunk: : [pdd] Clarification to Strings PDD from Jim Keenan. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26694 In your mind, the simplest/most desirable/easiest way to write Perl 6 in Perl 6 at this point is to use Rakudo to parse Perl 6 code into a parse tree, export that parse tree somehow, parse that exported tree into an application written in Perl 6 and running on Perl 5? mncharity: you can dump pge match objects atm. that process seems awfully convoluted to me That's why I'm asking. I feel like I'm missing something. if it were me, and I know it's not, I would write Rakudo V 1.0 in PIR/NQP. Then write Rakudo V2.0 in Rakudo V1.0, etc. that way you don't have to wait for a new tool/platform to be available before you can make a release % ruoso has joined #parrot r26695 | kjs++ | trunk: : [pdd29] check in initial pdd stub for compiler tools. update manifest. keywords are set. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26695 chromatic: no. but s/Rakudo/STD_red/, and that is what elf is currently doing. elf_on_rakudo did what you described - but I consider it dead code. as for whether elf is 'the simplest/most desirable/easiest way to write Perl 6 in Perl 6 at this point', it's certainly letting me write p6 code which nothing other than pugs might run, without worrying about getting hung up on pugsbugs, and with a much faster edit-test cycle. so, yes. Is STD_red a Perl 6 grammar parser written in Ruby? STD_red is a kludge of a direct hand translation of STD.pm into ruby. it parses, buggily, p6. upside is its fast, and the coverage is much better than STD5 at present. token foo { {...p6 code...} } -> def foo() { b=bar and h=hee and ...ruby code... and _make_a_match(..b..h..) } What features does Rakudo need to support before it's a more viable platform than elf? than elf itself, rather than the STD_red part of elf? hmm... r26696 | kjs++ | trunk: : [pdd29] fix copyright year; add a reference and add an abstract line. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26696 % kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl so rakudo has a more real parser. you'd loose bootstrap, but for many things that doesn't matter. matters for backend and primitives work, somewhat for Prelude, not at all for much else. so after that, it's just performance? Why would you lose bootstrap? elf_c, the current "elf of Monday night, today, and hopefully move off it later this week", can compile http://svn.pugscode.org/pugs/misc/elf/elf_c_src/ in about 20 sec, and run it in doing the same task in 10 (the other half being the parser). rakudo needn't be that fast, and much work is on smaller things, and one can do makefile-like 'avoidance of compilation'. So while rakudo was too slow for elf_on_rakudo, it may be fine to be viable, leveraging its other advantages. re 'Why would you lose bootstrap?', because rakudo isn' % findlay has joined #parrot t implemented in p6? so one still faces a variant of the pugs "I really need to do x, my compiler won't let me, and there is nothing I can do about, so I spend time trying to find workarounds". Do you think then that the complexity of bootstrapping is less a barrier to overcome than the complexity of learning, say, NQP? * ewilhelm ponders toggling the instruction set for nqp directly into the cpu's front-panel... well, the backend portion of the bootstrap is done. cost paid. cost for the front end is mostly writing a "regex on regexp" implementation in p6. of which there is already a p5, so it shouldn't be too bad. vs NQP, the pain of maintaining STD_red should be included, though it's been at least slightly amortized over helping with STD.pm work. re barrier, There's a conceptual cost of understanding the layers, and bugs in lower layers tend to be much more difficult to find and to diagnose. the key question short-term, this week, will be "you got this dialect working, it's a dialect you personally understand and has what you most wanted. but as to whether *I* understand and can use it, and whether it has the features *I* need for comfortable development..." for a multiperson value of I, is unclear. the question which follows is how rapidly a feature set which makes people generally happy can be grown. re layers, and expecially error reporting, agreed. currently taking advantage of the p5 layer being readable, but that doesn't scale. current story is that the/a emitter should rsn start inserting #line's refering back to the original p6 source. or let users toggle that. or some such. the info is available at emit time, it just hasn't been enough of an irritant (barely), to happen yet. % rafl has left rafl!~rafl@62.75.161.67 Your conjecture then is that there are more people willing to learn Perl 6 and how to write a bootstrapping compiler than there are willing to learn NQP? % rafl has joined #parrot re conjecture, no. that there are more people willing to learn Perl 6 than NQP seems clear. that [...] to learn some elf dialect of p6 than learn NPQ, of course depends entirely on how extensive the dialect support becomes, and when. Unclear. But that's not the near-term objective. That there are more _p6 compiler writers_ wishing to work in bootstrapped p6 rather than in NQP on parrot is the conjecture. well, hypothesis. What's the near-term objective then? support the '_p6 compiler writers_ wishing to work in bootstrapped p6 rather than in NQP on parrot'. I thought that wasn't your near-term goal. What is your near-term goal *not*, then? while pugs also supported a population of people writing "some random module" in p6, their (not) being able to get work done does not at present directly hurt a development critical path towards Christmas. And won't until we have enough of the language working that their language-design feedback becomes key. * ewilhelm notes parallel that squeak was written in a subset of smalltalk (though smalltalk was already a mature language at that point) % ruz has left ruz!~cubic@85.112.113.222 It really would be nice to be able to write Random::Perl::Module to use with Parrot. % allison has left allison!~chatzilla@63.105.17.30 Sure, but the open question is "Is bootstrapping a likely way to get there?" My opinion is no secret: you'll end up reinventing something that looks very much like Parrot to do so. Tene: use in what way? Couldn't perl5 be embedded (with limited connectivity ala inline) via C with a small matter of code? % ruz has joined #parrot of course, the squeak developers were apple employees :-/ ewilhelm: Perl 6 modules, I mean. well, that sort of supposes that rakudo is done, no? No, why? % gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net People wrote modules for Perl 5.000 despite Perl 5.10 being a decade away. well, what breaks if I write Random::Perl::Module (e.g. File::Fu) in perl 6 today? % skids has left skids!bri@charon.clarku.edu I don't understand the word "breaks" in this context. what doesn't work? Look buddy, doesn't work is a strong statement. Does it sit on the couch all day? Is it making faces at you? Does it want more money? Is it sleeping with purl's girlfriend? Please be specific! iiuc, operator overloading isn't fully specified Sure, and that means for File::Fu to work as written, Rakudo needs to support that type of operator overloading. Unless that's absolutely the last thing added to Rakudo, I'm not sure that Rakudo has to be done for you do port File::Fu. s/done/in some satisfactory state of readiness/ i.e. everyone has their own threshold of ride-along vs wait vs contribute Yeah, but not all of them are "It must be DONE". That's why I like to ask for specifics. http://www.perlfoundation.org/perl6/index.cgi?what_can_i_do_with_perl_6_today ewilhelm's url is at http://xrl.us/biq6w * ewilhelm is curious when the "3D graphics" stub will become a link % iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-190.dynamic.mnet-online.de % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se % jan has joined #parrot * davidfetter wonders whether ewilhelm is the same ewilhelm he heard on talk of the nation today This one is a Josh, not a Kaiser. heh * davidfetter fails to note any early april stuff on parrotcode.org it must just be too subtle the site was down this morning, that counts pmichaud: one more for the todo list, but it seems unambiguous. PAST::Op pasttype(for) mentions an otherwise unmentioned 'arity' attribute. --target=PAST shows it in Block, but only if explicit arguments are given (eg, "foo () -> $x {3}" but not "foo () {3}"). fyi. I think I'm all set. thanks for your help. % Limbic_Region has joined #parrot davidfetter: I think I'm the one you had a beer with several months ago in portland w00t! % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk % sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com now that PDD17 renamed "does" to "provides", are the "does" and "does_pmc" VTABLE method names also going to change? % nopaste has joined #parrot % skids has joined #parrot % muixirt has left muixirt!~user@p57B4FF0E.dip.t-dialin.net % tetragon has left tetragon!~seneca@216.126.67.44 % peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com r26697 | allison++ | trunk: : [pdd] A few more clarifications to the Strings PDD, while responding to mailing : list comments. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26697 % tetragon has joined #parrot % ruoso has left ruoso!~ruoso@81.84.156.87 cotto_work: they probably should I'm less convinced. The justification for s/does/provides/ in PMCs is so as not to confuse the syntax for applying a role to a PMC with the syntax for declaring that the PMC fulfills the same duties as if you had applied that role to the PMC. so, which one does the current op naming suggest? and which one should it suggest? (I'm just a lowly cage cleaner.) The *opcode* name asks "Do you perform this role?" The does *keyword* in PMCs says "Compose in this role at compilation time." The provides keyword in PMCs says "I fulfill this role without composition." % Ademan has left Ademan!~dan@h-68-164-168-66.snfccasy.dynamic.covad.net how does one become a lowly cage cleaner? you compose the "lowly_cage_cleaner" role, with the "does" keyword. :) % Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net you don't subclass the committer class with limited attributes? I think the committer traits can be added at runtime Subclassing would break Liskov. my $wknight8111 := new 'Committer', 'cage_cleaner'; haha, i think i mixed PIR and NQP syntax * wknight8111 hangs his head in shame % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se I've been bouncing back and forth between the two all day, trying to write my Octave port % Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net % slightlyoff has joined #parrot r26698 | chromatic++ | trunk: : [PDD] Typo fixes and minor formatting nits. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26698 * Coke sends out his promised type id email. ... is there anything else I owe parrot today? feed the bird. * Coke heads off to read his new spider robinson book. % Juerd_ has joined #parrot % Juerd_ has left Juerd_!juerd@feather.perl6.nl % Juerd_ has joined #parrot % Juerd has left Juerd!juerd@feather.perl6.nl % Juerd_ is now known as Juerd % grim_fandango has joined #parrot % guru has joined #parrot % Andy has joined #parrot % Theory has joined #parrot % wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % guru has left guru!~guru@bas7-toronto01-1242513962.dsl.bell.ca Hrm... I can't view the ticket mentioned in one of the TODO tests that's crashing on me Wow, I actually have a running laptop with internet access at my hotel tonight. And nothing is broken. Tene: knock on wood As long as you don't knock on the laptop ;) % AndyA has left AndyA!~andy@82.152.157.85 or touch it or look at it tetragon: rt seems to be working, here. is there something wrong with that particular ticket? 46511 But... but... but... svn up! I need my svn up! I don't have permission to view it tetragon: there are two urls to view tickets, one public and one private. hmm. neither do I. Or something weird like that. (and I'm logged in and everything) I'm also logged in I set up an account after one of my replies was eaten by some mail server Tene: neither the Ticket/Display.html nor the Public/Bug/Display.html will view it whatever permissions it needs, I don't have them I think I'm set up with basic committer privs It's test 14 of t/pmc/threads.t nice. # Failed (TODO) test 'CLONE_CODE | CLONE_CLASSES; superclass built-in' # at t/pmc/threads.t line 664. # Exited with error code: [SIGNAL 11] % AndyA has joined #parrot I get SIGNAL 10 sig11 is SIGSEGV on my OS My one keeps putting SIGBUS in the crash reports, but depending upon the test I can get 10, 6, and I think I've seen others well, whatever names those numbers map to, its crashing, and that's bad. :) Time to create a new ticket, as I have no idea what the hidden one is about I even know which thread crashed + local $TODO = "vtable overrides aren't properly cloned RT# 46511"; -- from r22492 diff % jjore is now known as zz_jjore % zz_jjore is now known as jjore Anyway, the one for it I created is 52398 cool. % tetragon has left tetragon!~seneca@76-10-182-190.dsl.teksavvy.com % tetragon has joined #parrot % mncharity has left mncharity!~jobsearch@c-76-24-29-201.hsd1.ma.comcast.net tetragon, I just fixed the segfault in RT #41097. You did? Yep, going to check it in in a second. r26699 | chromatic++ | trunk: : [IMCC] Made IMCC report an error when encountering get_results, get_params, : set_args, and set_returns opcodes with the wrong number of arguments. Fixes RT : #41097. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26699 On a non-crash note, test 2 of t/compilers/imcc/syn/regressions.t is failing on me It can't find the opcode div_i_ic_ic ooh. what platform? ppc I reopened #43048 yesterday because of the same thing on amd64 been banging my head on the table, trying to find out what's different about amd64... maybe its something different about x86 instead. I can see about copying a fresh source tree over to my 32-bit Intel Mac, and see what it does there ok. Coke tested it on x86 linux and saw no problems there I spent a bunch of time poking around in gdb yesterday. (single-instruction-stepping through longjmp is fun, by the way.) found a difference of behavior in compilers/imcc/parser_util.c line 653: the retval was NULL on both platforms, but the "ok" flag was set to 11 on x86 and it was 0 on amd64. but that's as far as I got with it % wknight8111 has joined #parrot 32-bit intel mac passes the test Which runcore? I'm also getting 0 for ok on line 653 on ppc And 11 on i386 chromatic: all of them. occurs with -C, -f, -g, -j, -p, -S, -t, or whatever's used by default. That should be easy to reproduce. need an account to poke around on? ok is 11 in its undefined state on i386, but not on ppc I thought 11 looked suspicious, since the function in question only sets it to 1 The second time flow goes through there on i386, it starts as 110 And is then set to 0 by IMCC_subst_constants I wonder if initializing ok to 0 causes it to break on x86. * Infinoid tries it There are some cases in IMCC_subst_constant where ok isn't touched A single return statement awesome, it does break x86. I think that return is being hit i386 passes because ok remains 11 * tetragon sets yet another breakpoint "Infinoid" at 76.215.208.106 pasted "Initialize the darned variable." (13 lines) at http://nopaste.snit.ch/12606 I'm tempted to check that in, as-is. * Infinoid likes breaking x86. Stuff gets fixed when its reproducible on x86. :P Yep, it's hitting the return that doesn't modify ok Wow. That's not a lovely function at all. Line 980 of optimizer.c That's the return that doesn't touch ok It ought to. Well, unlike the other two returns in the function, it doesn't With the appropriate modification, do you get the segfault? That case was one that that didn't segfault It just failed I haven't tested the 41097 changes yet % Andy has left Andy!~Andy@64.81.227.163 % Ademan has joined #parrot what does this code need to do, to make the test pass? % jan has joined #parrot I'm not sure whether ok should be set to 0 or 1 for that return, but neither value seems to have an effect on the test. % zarchne has joined #parrot r26700 | chromatic++ | trunk: : [t] Untodo the test for RT #41097, which is passing as of r26699. diff: http://www.parrotvm.org/svn/parrot/revision?rev=26700 the way I understand it, it tries a constant-folding optimization, fails that, and so does it at runtime. (That much is consistant between platforms.) The weird thing is that x86 wasn't breaking at runtime, I guess because of the uninitialized "ok" variable. So does that mean we need the 'div_i_ic_ic' op after all? Looks like it to me. I tried adding it, but... * Infinoid looks to see what else breaks on x86 when "ok" is initialized to 0 chromatic: Your segfault fix works on ppc Good. "chromatic" at 63.105.17.30 pasted "Test Patch to Fix IMCC syntax regression" (1428 lines) at http://nopaste.snit.ch/12607 hooray for make -j, hooray for ccache. * tetragon wonders about if anything special needs to be done for ppc Hm, it looks like *ok = 0 is wrong. ok 2 - cannot constant fold div by 0 Probably some of the PPC JIT is wrong in that some of the functions now take interp as their first argument. That'd be in src/jit/ppc/core.jit % wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net Heavily macro-ized and templated code. chromatic: patch looks good on amd64 Something breaks x86 horribly though. Feh, *ok = 0 was equivalent to what your amd64 and my ppc were doing Hrm... the build process crashing generally isn't a good sign I had to do a realclean before it built cleanly Yeah, I invalidated bytecode. hmm, I see no x86 breakage. % Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net I don't, if I do the int i = 0; t/compilers/imcc/syn/regressions.t passes ppc oh, I do see breakage, just not in the test I had originally tried. t/compilers/imcc/syn/op.t for example I also see breakage in op.t breakage is consistent between x86 and amd64 Tests 16 and 26-31 fail yep * Infinoid heads off to bed, goodnight only t/compilers/imcc/imcpasm/opt1.t fails for me. test 15 I also get a failure in t/compilers/imcc/syn/const.t Test 2 Couldn't find the opcode add_i_ic_ic The op.t failures are of the same variety of not finding opcodes "Infinoid" at 76.215.208.106 pasted "Test failures in t/compilers/imcc/ from http://nopaste.snit.ch/12607" (518 lines) at http://nopaste.snit.ch/12608 (that's on amd64) *gone* Ah, but I added the opcode in my patch. Loads of sigbus opt1.t has a load of failing tests, opt2.t has three tests that not only fail, but sigbus "chromatic" at 63.105.17.30 pasted "Test Patch for IMCC Regressions, Take Two" (1429 lines) at http://nopaste.snit.ch/12609 Is that patch any better? Revert the old one, and try this one. If you already did a make realclean for the old one, no need to do it again for this one. Bah, right after I started one Here's a chance to plug ccache then. r26701 | duff++ | trunk: : [rakudo] Add loop statement diff: http://www.parrotvm.org/svn/parrot/revision?rev=26701 All tests under t/compilers/imcc/reg and syn pass But test 15 of imcpasm/opt1.t fails No sigbus crashes in t/compilers/imcc/* other than syn/macro.t test 32, which is not a new failure I expect opt1 to fail No other failures in imcpasm Where were you getting the segfault before? the macro.t test 32 one? It didn't change not ok 32 - invalid label syntax # TODO RT#47978, RT#51104 Oh. Is t/compilers/imcc/syn/regressions.t passing now then? LYes So it fixed that much anyway. purl, messages msg Coke Does http://nopaste.snit.ch/12609 make sense for fixing t/compilers/imcc/syn/regressions.t? Message for coke stored. % chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net