Camelia, the Perl 6 bug

IRC log for #parrot, 2009-03-04

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 allison I still object to the idea of Parrot never shipping a stable release
00:00 allison it fundamentally bothers me
00:00 chromatic I object to the idea that Parrot never ships a stable release.
00:00 chromatic I can think of a couple of dozen stable releases.
00:01 allison but, they were all numbered 0.X, which is development numbering
00:01 allison by that logic, we should have shipped 1.0 4 years ago
00:01 allison and really, we probably should have
00:01 allison but, we didn't
00:01 chromatic Let's not get into a discussion of magical thinking and version numbers again.
00:01 Tene_ We could pull an emacs.
00:02 allison names and numbers do have power, we can use that power when it's to our advantage and ignore it when it's not
00:02 allison Tene: emacs?
00:02 purl hmmm... emacs is a lisp interpreter that pretends its builtin editor is a toy :) or escape meta alt control shift or a not-so-bad OS, but lacking a good editor
00:02 Infinoid Tene_: Yeah.  Or we could NOT!
00:03 allison Tene: sorry, I'm a vim user, what's the reference?
00:03 chromatic Emacs decided a couple of years ago to stop faffing about arguing about whether to increment a minor minor version number or a major version number and jumped some 19 major major version numbers.
00:03 Tene_ allison: they realized that they were never going to get to 1.0, so they just dropped the leading 0. from their 0.X releases.
00:03 Tene_ It was a silly suggestion.
00:03 Tene_ they went from 0.18 to 19
00:03 NotFound The question may be if that power is greater than the time we spend trying to achieve it.
00:03 allison oh, Solaris-style revisioning, yes, that's silly
00:03 allison NotFound: well, we've spent an awful lot of time on this
00:04 allison NotFound: more than it's worth
00:04 chromatic bugfix_only and monthly
00:04 NotFound allison: not yet, but I fear we can walk in that direction
00:04 allison here's my compromise suggestion:
00:05 allison In the documents we talk about Supported and Developer releases, and use the phrase "critical bug/security fixes"
00:05 allison the ftp directories use "stable"/"devel" which is extensively common
00:06 chromatic No, thank you.
00:06 allison and, we make sure the documentation is clear on the advantages/disadvantages of each, without encouraging either
00:06 tetragon joined #parrot
00:08 chromatic "Developer", "stable", and "devel" already encourage certain behaviors based on their connotations.
00:08 allison chromatic: I respect your opinion.
00:08 chromatic I also reject the idea that the ubiquity of "stable"/"devel" in other projects has any bearing on our project with its very different support policies.
00:08 allison yes, but those behaviors are mostly what we want
00:08 chromatic Those behaviors are what YOU want.
00:08 chromatic I want to let people decide without pushing them one way or another.
00:09 allison I think you want them to upgrade every month, yes?
00:09 AndyA joined #parrot
00:09 chromatic Yes, I do.
00:09 allison okay, just so we're clear
00:09 chromatic I don't expect everyone will.
00:10 chromatic I don't particularly care about naming semantics, provided that:
00:11 chromatic 1) They reflect measurable differences between types of releases
00:11 chromatic 2) They accurately describe the nature of the releases
00:11 chromatic 3) They don't imply additional pro or con connotations that we don't intend
00:12 NotFound I think that 3) gives no other way than foo/bar
00:12 chromatic I believe the only measurable differences between a January and a February release are that we may, as necessary, release critical bug and security patches for the January release.
00:12 allison NotFound: which is a terrible scheme
00:12 chromatic Our deprecation policy doesn't really come into play there.
00:12 Infinoid NotFound: Not really.  Something like "supported" and "monthly" says exactly what they should say and nothing else, I think
00:13 allison chromatic: Like I said, I respect your opinion. But, you haven't convinced me.
00:13 chromatic What's inaccurate or incomplete about what I just wrote?
00:13 NotFound Infinoid: "monthly" has been already critizised
00:13 Infinoid NotFound: It isn't inaccurate
00:14 NotFound Infinoid: not by me ;)
00:14 allison chromatic: "our deprecation policy doesn't really come into play" is inaccurate.
00:15 chromatic If we only ever backport bugfixes to the January/July releases, deprecation cycles aren't important to those releases.
00:15 allison chromatic: external perceptions and packaging considerations also come into play
00:15 rurban strictly speaking re our new deprecation policy we would need 1.0 (March), 1.0.1, 1.0.2 -> 1.1 (July), 1.1.1 -> 2.0 (January)
00:15 allison chromatic: it's fine for you not to think about those things
00:15 allison chromatic: you can think only about each monthly release and nothing else
00:16 allison chromatic: developers in general can think only about each monthly release and nothing else
00:16 NotFound In general I just think about my next commit ;)
00:17 rurban well, if they have to wait for 6 month for a major rewrite to get in, they will care
00:17 allison NotFound: yes, that's generally true
00:17 chromatic I thought a big part of my argument *was* external perception.
00:17 allison chromatic: we're not adding the January/July cycle as a convenience for developers, it's aimed at a different audience, and that audience needs to understand whatever name we give them.
00:18 chromatic YOU WILL ONLY GET CRITICAL BUGFIXES AND SECURITY PATCHES
00:18 chromatic THERE ARE TWO OF THESE RELEASES A YEAR
00:18 allison they need to understand it at a superficial level without reading the documentation (though they won't get the full depth of the meaning until they read the documentation)
00:18 chromatic DO NOT LEAVE IT IS NOT REAL
00:19 chromatic NO OTHER RELEASE IS STABLE WE JUST LIKE MAKING RELEASES IT MIGHT EVEN COMPILE IF YOU ARE LUCKY STOP SEND MONEY STOP
00:19 chromatic ... AND THEY HAVE A PLAN
00:19 allison now that is a strawman
00:19 chromatic No one ever said the Cylons have a *good* plan.
00:21 chromatic Okay, so the difference between the January release and the February release is that we may make critical bugfixes as necessary for the January release.
00:21 chromatic Which is all the support we offer for releases.
00:22 chromatic Or the maximum level of support we offer for releases.
00:22 rurban Where is that sentence about CRITICAL BUGFIXES AND SECURITY PATCHES? I cannot find it?
00:22 allison chromatic: yes, January and July get the maximum level of support
00:22 chromatic What's wrong with the label "supported"?
00:22 allison rurban: it's not there yet, I will edit after we close this discussion
00:22 chromatic rurban, I don't think it's in the support policy yet.
00:22 allison chromatic: it requires explanation
00:23 chromatic So does "stable"!
00:23 allison chromatic: which is fine in the docs
00:23 allison chromatic: anyone who has navigated FTP directories will get the difference between "devel" and "stable"
00:23 chromatic But that difference is immaterial to Parrot!
00:24 chromatic http://irclog.perlgeek.de/​parrot/2009-03-03#i_954870
00:24 allison chromatic: there is a difference, we've already agreed on that
00:25 chromatic Okay.
00:25 chromatic We *know* what "supported" means in this context.
00:25 allison chromatic: I don't get what you're referring to with the IRC link
00:25 chromatic We *know* we have to explain it.
00:25 chromatic We *know* that the difference between a January and a February release is that we support the former but not the latter.
00:26 chromatic ... thus we refer to them as "stable" and "development".
00:26 allison chromatic: plus deprecation cycles, plus packaging
00:26 chromatic You can't stick information about deprecation cycles and packaging into a single-word label.  I'm deliberately ignoring that.
00:27 allison chromatic: you have the luxury of ignoring it, they are all characteristics of the Jan/Jul releases
00:27 allison chromatic: ignoring a third of the factors is a disadvantage in reaching a conclusion that addresses all the factors
00:28 chromatic You want a single-word label which denotes all of 1) support policy 2) deprecation policy 3) packaging policy?
00:28 allison one that gets close, yes
00:29 allison "stable" does it
00:29 chromatic and, optionally, it shouldn't imply things about the other 10 releases a year
00:29 chromatic at least, things that aren't true
00:30 allison chromatic: language is full of implications, I can live with implications, as long as they don't make us sloppy
00:30 allison (that is, if we still work just as hard on ticket closing, etc on all the releases)
00:30 chromatic THat's exactly why I don't like stable/foo.
00:30 allison (and, don't put out a release that doesn't compile)
00:31 allison chromatic: that's about our internal policy
00:31 allison chromatic: it has nothing to do with the name
00:32 chromatic Except for the external perceptions you told me I don't have to worry about.
00:32 allison if we put out 10 reliable development releases a year, does that say anything bad about us?
00:33 chromatic If we put out 12 stable releases a year, does that say anything better about us?
00:33 allison chromatic: no
00:33 rurban inflation and arrogance
00:33 chromatic Arrogant?
00:33 purl i guess Arrogant is an understatement
00:34 NotFound chromatic: Do you think that a directory name in a ftp will have a big impact in the external perception?
00:34 chromatic It's arrogant to give people the chance to upgrade to a well-tested, stable piece of software as frequently as possible?
00:34 allison chromatic: strawman again
00:34 rurban we cannot maintain stable releases, and we do not want to.
00:34 chromatic How in the world is that a strawman?
00:34 chromatic NotFound, it happened for Perl 5.10.
00:34 rurban 12x stable a year
00:34 chromatic Or should I say, it's still happening.
00:34 allison chromatic: the idea that the name means we're taking away opportunity
00:35 chromatic I have no idea what that means, allison.
00:35 allison chromatic: the problem there is that they released 5.10 and refused to call it "stable"
00:35 rurban we are changing the API, the pbc's, the pmc's, the ops all around. That's the opposite of stable.
00:35 allison chromatic: that's a problem I don't want to repeat with Parrot 1.0
00:35 chromatic Yes.  In a directory on the CPAN.
00:36 rurban we are deprecating functions and methods without keeping the old versions around
00:36 chromatic Hm, that almost argues that the word "stable" can mean many, many things that aren't all compatible nor immediately obvious from just the single word "stable".
00:36 chromatic Thus, I agree.
00:37 rurban we don't give advice how to uprade from old deprecated names to the new ones. the DEPRECATION.pod only lists either the old names or the new ones. but not the rule.
00:38 rurban the stable versions I maintain, change every two years, when a security bug appears. It's a branch. That's stable. Not changing at all.
00:38 chromatic Let me ask a different question.
00:38 allison okay
00:39 chromatic If a compiler developer decides to use a February release, is that a problem?
00:39 allison chromatic: no, not a problem
00:39 chromatic Is that something to encourage or to discourage, or neither?
00:39 allison it just has certain implications
00:39 allison s/he won't get critical bug/security fixes to that release
00:40 chromatic Is that distinction something we can describe in a single term used to label a February release as different from a January release?
00:40 allison that release doesn't have the same deprecation policy as the January release (that is, features added in that release may have been temporary/experimental)
00:41 allison and, the release won't be packaged, so his/her users will have to download and compile from source
00:41 chromatic Okay, stop.
00:41 chromatic That's something we can't measure again.  Let's throw that out.
00:41 allison (compile parrot, that is)
00:42 allison A can/can't install a package seems pretty measurable
00:42 NotFound If we want two words unambiguous and free of any negative connotation I think ascii is not enough, we must use APL charset, at least.
00:42 allison NotFound: :)
00:42 chromatic You can't measure what people will package in the future!  We don't know what FreeBSD will do.  We don't know what Gentoo will do.  We don't know what Debian will do.
00:43 chromatic We don't even know what *Rakudo* will do.
00:43 allison if the past is any predictor, Debian will upgrade once every 3-4 years. I hope the past isn't a predictor.
00:43 gravity More like 1.5-2 years these days
00:44 allison gravity: the last release of Parrot on Debian is 0.4.x
00:44 chromatic That's Debian's problem, and Debian will have to fix that.
00:44 allison chromatic: accepted as a rabbit trail
00:45 gravity I'd be happy to talk about parrot in Debian when you guys are done with the current discussion :-)
00:45 NotFound gravity: Are you young?
00:45 chromatic Ideally I'd like to have two simple, unambiguous, and roughly parallel terms.
00:45 gravity NotFound: Depends on what you mean
00:45 Infinoid gravity: You might not be by the time this discussion is over.
00:45 NotFound gravity: it you expect to live long enough :D
00:45 gravity Ha!
00:45 NotFound if
00:46 allison gravity: sounds good, our Debian sponsors are pretty busy, so we haven't made much progress there
00:46 chromatic I don't want any term where a potential user can look and see "Oh, that one's a lot newer, but it sounds like I have to be a Parrot developer to use it.  I'll stick with something else."
00:47 gravity allison: I spoke to mako about it actually. I'm not sure who your other sponsors are these days.
00:47 chromatic If we can point to three sentences in the documentation (or even in the FTP header) which explains just those differences, fine.
00:47 allison gravity: Colin Watson and Jeff Bailey
00:48 NotFound We can put a file in the ftp called READ_CAREFULLY_BEFORE_ASSUME_A​NYTHING__YOU_HAVE_BEEN_WARNED
00:48 chromatic *Apart from upgrading concerns*, is there anything in a February release itself which makes it, itself, apart from upgrading concerns, unstable?
00:48 gravity allison: Ah, yeah Colin's wonderful, but always busy. I have yet to meet Jeff.
00:49 allison chromatic: for the people who read it, sure, but the people who will read it are the more advanced users
00:49 chromatic We're talking about people writing compilers here.  I think we can assume some level of clue.
00:49 allison chromatic: the clueless newbies need a warning
00:49 allison a warning before they even read the documentation
00:49 chromatic What's that, "Stick with your distro package"?
00:50 Infinoid "Buckle up."
00:50 allison chromatic: that first, and then second they need to immediately recognize what the next level of complexity is
00:50 allison gravity: they're all great, just busy
00:51 gravity allison: Well, I'm happy to work on it. I'd like to see updates in unstable at a regular rate, and also to have some rakudo snapshots in experimental at least.
00:51 allison scale of complexity: "package" -> "stable" -> "devel"
00:52 Infinoid -> svn
00:52 allison gravity: we're producing the packages, just need them reviewed and sponsored for inclusion
00:52 allison Infinoid: yes
00:53 gravity allison: I can do that. How do you and all the other sponsors normally communicate?
00:53 NotFound -> patches nopasted ;)
00:53 allison gravity: email. We created an alioth group/mailing list, but has had no traffic
00:54 allison gravity: it's all been private email exchanges
00:54 gravity Heh, ok
00:55 chromatic What's wrong with "latest_supported_version" and "latest_monthly_version"?
00:55 chromatic Implicitly we have a contract with all of our users that the monthlies are stable (in terms of not crashing), reasonably complete for the features they implement, and well-tested.
00:55 chromatic Apart from upgrade concerns, and concerns about critical patches, both of which I believe are out of scope for labeling an individual release, what's a better description for a monthly release?
00:55 chromatic What does "devel" mean though?
00:55 chromatic We don't know what "stable" means, and I thought we set aside the "package" rabbit trail.
00:55 chromatic I've contributed to this project for 7 years.  If I don't know what these labels mean, what hope does any novice have?
00:56 allison chromatic: we set aside Debian/Ubuntu/whatever's upgrade policy as a rabbit trail
00:56 allison chromatic: we know what they mean because we define them
00:56 chromatic Don't you see, that's the problem!
00:56 allison chromatic: outsiders know 90% of what they mean from prior experience with other projects
00:57 allison chromatic: they learn the rest as they learn more about the project
00:57 ron joined #parrot
00:57 chromatic I have trouble thinking of other projects which produce stable monthly releases.
00:58 allison Bazaar
00:59 allison it's a popular strategy among the agile set
00:59 chromatic Funny you mention that.  I don't know many agile projects with stable/devel releases.
01:00 chromatic They tend not to play those games.
01:00 allison which is likely where your perspective comes from
01:00 allison the also, IIRC, don't do bug/security fixes
01:01 chromatic Sure they do, when necessary.
01:01 chromatic They can release a new stable version of their software at any point.
01:03 allison I'm working on the support policy doc now
01:04 chromatic Fine.  Go ahead.
01:06 allison I just wanted to let you know why I wasn't focused here
01:09 allison chromatic: I do understand that you still disagree, and I respect your point of view.
01:09 rg (02:04:48) chromatic left the room (quit: Quit: Leaving).
01:10 rg unless of course you're talking for the logs ;)
01:47 HG` joined #parrot
02:10 buildbot joined #parrot
02:24 HG` joined #parrot
02:31 jan joined #parrot
02:50 rurban_ joined #parrot
03:36 tetragon joined #parrot
03:42 janus joined #parrot
04:13 dalek rakudo: 55fb203 | pmichaud++ | src/parser/grammar.pg:
04:13 dalek rakudo: Update pod_comment to handle =begin END, some pod errors (from STD.pm).
04:13 dalek rakudo: Remove some trailing spaces.
04:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​5fb2036441a64d3ee20d08bfa9c6871a9d46ebb
04:13 shorten dalek's url is at http://xrl.us/beh89q
04:32 dalek parrot: r37101 | allison++ | trunk/docs/project/support_policy.pod:
04:32 dalek parrot: [docs] Update the support policy with clarifications and changes based
04:32 dalek parrot: on #parrotsketch and #parrot conversation.
04:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37101/
05:02 Andy joined #parrot
05:09 Theory joined #parrot
05:33 japhb Any svn ops around?
05:36 Ademan joined #parrot
05:41 japhb Any metacommiters?
05:42 japhb anyone at all?
05:43 cotto nope
05:44 japhb bugger all.
05:44 purl i dunno, japhb
05:46 cotto What needs to happen?
05:48 japhb I never set up my Trac account so that I would be able to commit against the new repo.  I just did that.  I'd like to commit, but apparently there's something else I'm missing.
05:49 * japhb grumbles mildly about the account not being transfered automagically from the old repo
05:49 cotto I think allison can do that.
05:50 japhb spof?
05:50 purl rumour has it spof is Single Point Of Failure or Fuckage or 'This is called the "Jesus nut." It holds the rotor on the helicopter.'
05:51 cotto I'd expect there to be other people who can do that, but I don't know who they are.
05:51 japhb nodnod
05:51 * japhb longs for the "metacommitter or six in every time zone" of the Pugs days
05:52 * japhb commits to local git repo for the time being
05:54 allison japhb: I'll set you up, what's your Trac user account?
05:54 japhb japhb
05:54 japhb allison: Thank you.
05:54 allison okay, just a sec (has to be added to the permissions list)
05:54 japhb And sorry for the grumbling.  It's been a grumbly day.  :-/
05:56 allison japhb: done, and also added your permissions for ticket management
05:56 allison japhb: some days are like that :)
05:56 japhb allison: thanks again
05:57 allison japhb: anytime :)
06:03 dalek parrot: r37102 | japhb++ | failed to fetch changeset:
06:03 dalek parrot: [examples/mops] Fix mops.p6 for current Perl 6 (and Rakudo)
06:03 dalek parrot: * Fix pod for minimal Perl 6 compliance
06:03 dalek parrot: * Uppercase name of MAIN subroutine so that it will be executed
06:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37102/
06:04 japhb "failed to fetch changeset"?
06:14 Tene joined #parrot
06:15 cotto That's how trac rolls.
06:16 allison cotto: I always thought that was dalek?
06:23 dalek parrot: r37103 | japhb++ | trunk/examples/mops/mops.p6:
06:23 dalek parrot: [examples/mops] mops.p6: Fix pod (typos, errors, poor wording)
06:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37103/
06:27 dalek parrot: r37104 | japhb++ | trunk/examples/mops/mops.p6:
06:27 dalek parrot: [examples/mops] mops.p6: fix comments and pod to match mops_intval.pasm
06:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37104/
06:28 contingencyplan joined #parrot
06:30 dalek parrot: r37105 | japhb++ | trunk/examples/mops/mops.p6:
06:30 dalek parrot: [examples/mops] mops.p6: Fix missed reference to mops_intval.pasm
06:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37105/
06:31 japhb dalek or trac are running really slowly
06:32 japhb that string came in a git svn dcommit -- so three commits over the course of a few seconds, not 8-10 minutes ...
06:34 dalek parrot: r37106 | allison++ | trunk/docs/project (2 files):
06:34 dalek parrot: [doc] Took a few minutes to update the Metacommitter guide after adding
06:34 dalek parrot: a committer (an existing committer who just created a Trac account).
06:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37106/
06:50 Ademan joined #parrot
06:51 allison japhb: I wonder if dalek is following commit email messages? those were delayed in the list approval queue until I added your "virtual" email address to the accepts list
06:52 allison (virtual email being japhb@svn.parrot.org)
06:53 japhb allison: sounds possible.  We'll see next time I commit ...
06:53 cotto I thought dalek followed rss feeds.
07:06 uniejo joined #parrot
07:39 cotto coke++ #twip
07:50 szabgab joined #parrot
08:02 TiMBuS joined #parrot
08:12 xinming joined #parrot
08:13 xinming left #parrot
08:20 Khisanth joined #parrot
08:22 dalek parrot: r37107 | allison++ | trunk/parrotbug:
08:22 dalek parrot: [cage] Committing a modified version of Patrick's patch from TT #27.
08:22 dalek parrot: This change disables the "send" feature, and directs the user to submit
08:22 dalek parrot: their created report to Trac. (The information captured by parrotbug can
08:23 dalek parrot: be handy, especially when working with inexperienced users.)
08:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37107/
08:56 dalek rakudo: a2f5064 | (Moritz Lenz)++ | t/spectest.data:
08:56 dalek rakudo: Track changed test file names by frew++ in t/spectest.data
08:56 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​2f5064e7725e2a70f32041dc4b5d73a3d6f6fd7
08:57 shorten dalek's url is at http://xrl.us/beh9rg
09:04 alvar joined #parrot
09:08 gryphon joined #parrot
09:21 justin joined #parrot
09:23 mberends joined #parrot
09:59 cotto joined #parrot
11:01 riffraff joined #parrot
12:07 cotto The Continuation PMC tests are minimal.
12:31 cotto I guess they get plenty of indirect coverage, though.
12:33 rg1 joined #parrot
12:51 protorom joined #parrot
12:58 protorom left #parrot
13:02 Infinoid allison, cotto, japhb: yes, dalek follows rss feeds, so it would be trac slowness
13:04 Infinoid it fetches the link from the rss in order to get the list of changed files.  when that fetch hits an LWP timeout, the result is "failed to fetch changeset"
13:05 Infinoid it was either that or ignore the commit entirely, but I figured it should give the karma and show the log as best it can.
13:29 msmouse joined #parrot
13:37 Infinoid What's the best way to do a redirect / bounce in Drupal?  Do I just put in an HTML content page with a meta/refresh tag, or is there a better way?
13:39 msmouse left #parrot
13:40 masak joined #parrot
13:40 dalek parrot: r37108 | fperrad++ | trunk/config/gen/makefiles (2 files):
13:40 dalek parrot: [makefile] try to prevent problem with implicit rule (see r37098). But it's just a comment.
13:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37108/
13:48 Infinoid I'm also unable to find an "attach" or "upload" sort of link in drupal.  There are 5 pdf files from the parrotcode.org//talks/ page which need moving over
13:56 Tene_ joined #parrot
14:00 gryphon joined #parrot
14:10 jsut|w3rk joined #parrot
14:10 masak joined #parrot
14:26 dalek rakudo: cc1e659 | pmichaud++ | docs/spectest-progress.csv:
14:26 dalek rakudo: spectest-progress.csv update: 256 files, 5648 passing, 0 failing
14:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​c1e659a8b29aee21b99e63c239d68106cc69031
14:26 shorten dalek's url is at http://xrl.us/beh973
14:30 rg1 ouch. how did rakudo lose over 1k passing tests?
14:31 pmichaud someone reorganized the spectest suite last night but didn't update rakudo's t/spectest.data file.
14:31 pmichaud a bunch of test files got renamed.
14:45 moritz pmichaud: I did the rename
14:45 moritz in a2f5064e7725e2a70f32041dc4b5d73a3d6f6fd7
14:45 moritz did I forget to push it?
14:47 rg1 dalek reported it. but i have no idea how git works.
14:48 pmichaud moritz: yes, but the rename came after 00:00 CST
14:48 pmichaud the tests moved before 00:00 CST
14:48 pmichaud (and I report statistics as of 00:00 CST)
14:48 moritz that's unfortunate
14:48 rg1 oh, so it will get back to 7k+ in tomorrow's report?
14:49 moritz yes
14:49 moritz (unless somebody breaks it again in the mean time ;-)
14:52 dalek rakudo: 8637bed | pmichaud++ | docs/spectest-progress.csv:
14:52 dalek rakudo: spectest-progress.csv correction to total spectest count
14:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​637bed4561c1232f97bd23bd3790d4b6d02ede6
14:52 shorten dalek's url is at http://xrl.us/beiaba
14:52 dalek rakudo: b60ccaf | pmichaud++ | tools/test_summary.pl:
14:52 dalek rakudo: Add S32 to test_summary.pl scanning.
14:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​60ccafa5e5f736edd2aebcd0e6eef31e4f5f194
14:52 shorten dalek's url is at http://xrl.us/beiabc
14:58 msmouse joined #parrot
15:20 Patterner joined #parrot
15:22 msmouse joined #parrot
15:27 ron joined #parrot
15:35 mj41 joined #parrot
15:53 Whiteknight joined #parrot
15:56 Infinoid this is what my car looked like half an hour ago: https://quack.glines.org/up​load/infinoid/03042009.jpg
15:56 pmichaud Infinoid: nice paint job... perhaps a bit heavy on the white, though.
15:57 Infinoid Apparently, this is what "spring" looks like here.
15:57 szbalint wow nice, all the snow finally melted here last week :)
15:57 pmichaud we didn't get any snow here this year.
15:57 pmichaud lots of very cold days, but no snow.
16:05 Theory joined #parrot
16:06 Theory joined #parrot
16:11 dalek rakudo: 33ddc70 | pmichaud++ | src/classes/Grammar.pir:
16:11 dalek rakudo: Allow Grammar.parse() and Grammar.parsefile() to take options.
16:11 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​3ddc701ab594d7617de4dcdfeeeb4f5f4ac2761
16:11 shorten dalek's url is at http://xrl.us/beiakf
16:17 davidfetter joined #parrot
16:19 Whiteknight infinoid, where do you live? My car looked like that yesterday
16:23 Infinoid Whiteknight: lake tahoe
16:24 Whiteknight oh wow, so nowhere near me
16:27 Util Three days ago, we had 2 inches of snow in mid-Alabama; the most I recall in 20 years. My neighbor's snowman has still not completely melted.
16:28 Util davidfetter: Did you resolve your `make rpms` issues?
16:28 davidfetter Util, not yet
16:28 * davidfetter on f10, fwiw
16:29 Infinoid Whiteknight: whereabouts are you?
16:29 Infinoid any drupal experts in the house?
16:30 Whiteknight Infinoid: I'm near Philadelphia
16:31 Util I tried it (on Mandriva) for the first time yesterday.
16:31 Util It bombed in the `rpmbuild` step, because '0.9.1-devel' is an invalid version identifier.
16:31 Util The version cannot contain a dash; it is reserved for seperation: Name-Version-Revision.
16:38 dalek parrot: r37109 | Util++ | trunk/docs (4 files):
16:38 dalek parrot: [docs] Typos - s/navitate/navigate/; Committer has 2 "m"s and 2 "t"s
16:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37109/
16:40 Theory joined #parrot
16:45 davidfetter Util, i tried from the tarball and it bombed on what appeared to be some kind of mixup with CRLF
16:47 bacek joined #parrot
16:59 dalek parrot: r37110 | Util++ | trunk/src/sub.c:
16:59 dalek parrot: Typo in sub.c - s/sctatchpad/scratchpad/
16:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37110/
17:05 Whiteknight joined #parrot
17:28 Tene joined #parrot
17:46 barney joined #parrot
17:48 Whiteknight_ joined #parrot
18:01 szabgab joined #parrot
18:10 Psyche^ joined #parrot
18:21 Theory joined #parrot
18:22 mikehh joined #parrot
18:30 tuxdna joined #parrot
18:53 justin joined #parrot
18:58 protorom joined #parrot
18:59 protorom left #parrot
19:16 DietCoke joined #parrot
19:16 Coke .
19:17 Whiteknight .?
19:18 PerlJam END OF LINE.
19:18 Coke "Here I am. Especially you, purl, who likes to spam me with things when I speak."
19:19 Coke PerlJam: Yes I'm old. Old enough to remember when the MCP was just a chess program!
19:20 Coke ... hey, just like skynet.
19:36 allison http://www.randsinrepose.com/archi​ves/2009/01/18/the_larry_test.html
19:36 shorten allison's url is at http://xrl.us/beibfd
19:45 Coke allison: thanks for updating support_policy. I need to read the updated version.
19:46 dalek pipp: bbf5a2c | (Bernhard Schmalhofer)++ |  (5 files):
19:46 dalek pipp: Add a '--run-pir' option to pipp.pbc.
19:46 dalek pipp: For some reason this fails when run by t/harness.
19:46 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/bbf5a2c5e826697af18de1442146f1933f11022d
19:46 shorten dalek's url is at http://xrl.us/beibgg
19:46 dalek pipp: bd1c7f3 | (Bernhard Schmalhofer)++ | t/harness:
19:46 dalek pipp: The exex sub needs to return an array of strings.
19:46 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/bd1c7f36b3abecfd09ca889dced9239fcf58dc49
19:46 shorten dalek's url is at http://xrl.us/beibgk
19:46 dalek pipp: 63e6188 | (Bernhard Schmalhofer)++ | t/pmc/ (2 files):
19:46 dalek pipp: The pragma .loadlib conflicts with running via --run-pir
19:46 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/63e6188fccad7c7ce2e6282ef2409479242696b7
19:46 shorten dalek's url is at http://xrl.us/beibgp
19:46 ron Is the hll modifier for pmcs intended to effect aspects of pmc operation other than method access and the "maps" modifier?
19:47 rurban joined #parrot
19:48 Tene ron: iirc it also affects the hll namespace that the class is registered in
19:49 rg oh yes, about that: The section on platform support could also be a bit clearer. Since Linux is running on quite a number of hardware platforms, I believe the current perception is that you actually only mean Linux/i386. I'd love to see some kind of support for 64bit bit in there aswell.
19:50 Tene I've been running Parrot on 64bit linux for as long as I'v ebeen working with parrot.
19:50 Tene JIT doesn't work last I checked, though.
19:51 Tene but that was quite a while back.
19:51 rg tene: it still doesn't. and i'm not asking it should. only that an effort is made to generally have all tests passing for the default core.
19:52 jan joined #parrot
19:54 ron Tene: I find your answer a bit confusing.  Yes the only(?) point of the hll modifier to to effect the pmc namespace but I did say a 'pmc' and not a high level class.  Other than mapping a core pmc to the hll namespace and and setting the namespace for methods - does the hll modifier effect anything else?
19:56 dalek parrot: r37111 | coke++ | trunk/docs/project/support_policy.pod:
19:56 dalek parrot: [docs] Convert faux lists into actual POD lists.
19:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37111/
19:59 Coke ron - to answer that question, I'd look at pmc2c.pl (and the perl libs it uses) to see what happens to the hll keyword.
19:59 Coke I don't know off the top of my head, or I'd just answer it.
20:03 ron Coke: thanks for answering here - I am trying to follow up on my earlier misunderstanding of rt#40438 that you noticed in your reply from last week on my posting to that rt.
20:06 davidfetter hi
20:06 davidfetter Util, around?
20:07 ron I did notice that partcl used hll and maps on several PMCs but also noticed that, other than autoboxing, all tests passed when I removed the hll and maps modifiers from all dynpmcs (except tccllist).
20:07 pmichaud phone
20:07 Whiteknight so allison, what is our Larry test for 1.0?
20:08 allison Whiteknight: it was interesting to me, because the critical milestones we set up at the Parrot developer summit were an excellent Larry test
20:08 rurban rg: linux/x64 support is much poorer than i386. jist does not work, reading i386 pbcs does not work.
20:08 ron Coke: can you remember, off the top of your head, any other reason for adding the hll and maps modifiers to the dynpmcs (I was looking at stable), than autoboxing?
20:09 rurban rg: strict ptr_alignment=8 breaks us
20:09 rg rurban: those 2 are the only points i can think of. ptr_alignment is not an issue on amd64.
20:09 rurban yes, but it's unfortunate
20:10 rg btw, i doubt there's much i can do to help you with reading i386 pbc. i've looked at the failure and i can't make any sense of it.
20:10 rurban rg: btw can you update the native_pbcs on the missing platforms for the latest PBC_COMPAT change?
20:11 rg sure, but i expected there would be another 1 or 2 coming anyway
20:11 rurban rg: this is the alignment issue which I tried to solve in the huge patch tt254-64bit-pbc.patch but it is far too huge for 1.0 and I cannot test it
20:12 rurban currently I only have a 386 laptop without 64bit support and can only guess
20:12 Coke ron: yes.
20:13 Coke for example: .param pmc args :slurpy
20:13 Coke that gets the hll-mapped version of a resizablepmcarray.
20:13 ron That is why I left out tcllist
20:13 NotFound rurban: the problem lies here: few people use 64 bit machines.
20:13 * Coke checks out the ticket again.
20:13 rurban but sooner or later they'll switch
20:14 NotFound rurban: I've been hearing that for years
20:14 rurban our new buildbot e.g. is 64bit
20:14 NotFound So the "sooner" is timed out :D
20:14 rurban sooner than later
20:14 rg notfound: any serious server will be 64bit these days.
20:15 NotFound rg: I don't work on parrot on serious servers
20:15 Coke ron: ah, that one.
20:15 rg but the people who will run parrot will do so on serious servers, so i think our goal should be to offer at least some support.
20:16 NotFound I can't even ask permission from my bosses, because they even't understand what I'm talking about :D
20:16 Coke (support for 64bit) It might be helpful to tag all the trac tickets regarding 64bit with a "64bit" tag.
20:16 NotFound rg: yes, but having a goal is a poor help if almost nothing have the tools-.
20:16 Coke then we have a list we can point to and say, "just these left."
20:17 rurban ok, will do
20:17 Coke I for one don't have a 64bit box to test on.
20:17 rurban It would help if my various patches get tested
20:20 ron Your answer was basically right AFAICT - I did some tests on static pmcs and they seem to have the same problem but since they don't normally have hll modifiers I think its probably less important.
20:21 rurban rg: can you test the TT#264 hints patch?
20:21 rurban oops #364 it is
20:22 rurban https://trac.parrot.org/parrot/attachmen​t/ticket/364/tt364-sparc-memalign.patch
20:22 shorten rurban's url is at http://xrl.us/beibnk
20:23 NotFound pdd13_bytecode.pod is up to date?
20:24 rg ok, that one's new. i'll have a look.
20:24 ron I guess I am looking to clarify the ticket by noting that PerlString probably used an hll modifier and the problem is to get the hll modifier on pmcs, and particularly dynpmcs, to have the right effect on the sub/method namespace - any thoughts?
20:24 NotFound "A number of things in this proposed PDD differ from the old implementation, and few items are not yet implemented." ---> This sucks
20:24 rurban NotFound: yes
20:24 rurban this is the current state, milestone is 2.6
20:25 rurban but just a few pmc items are missing => jonathan
20:25 NotFound The "proposed" is out of place, the document is not in the draft directory.
20:26 dalek pipp: 7ced896 | (Bernhard Schmalhofer)++ | t/ (2 files):
20:26 dalek pipp: Run tests with ./pipp
20:26 dalek pipp: Workaround for t/embed/eval.t
20:26 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/7ced896f4cf9e8df38bf00bd522f843a4d87d2f2
20:26 shorten dalek's url is at http://xrl.us/beibof
20:26 dalek pipp: 55e0a42 | (Bernhard Schmalhofer)++ | t/harness:
20:26 rurban "A number of things in this proposed PDD differ from the old implementation" yes, we can remove that, but we should mention the previous version briefly
20:26 dalek pipp: path_to_parrot() is no longer needed
20:26 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/55e0a42ce770c70c636f0f4ff13154120a298302
20:26 shorten dalek's url is at http://xrl.us/beiboh
20:26 NotFound Not removing, clarifying
20:27 rurban NotFound: what is missing is the --ops and --pmc problem for which I'll write a proposal to extend the header or uuid
20:27 NotFound rurban: What about the "proposed" word?
20:27 rurban In the pdd? go away, its implemented
20:28 NotFound rurban: then someone who knows about must fix the document.
20:28 rurban will do. let me finish the 64bit keywords first
20:29 NotFound rurban: thanks
20:32 Coke long term, the PDDs shouldn't mention what was, only what is and will be.
20:32 Coke (our users don't care what we did in 0.3.4)
20:32 NotFound My idea is to write a program to read pbc and check them, completely free of parrot code and headers.
20:34 NotFound Coke: good point. Historical information can be put in a document dedicated to that.
20:34 rg notfound: what would that be good for? check the specification?
20:34 NotFound rg: aye
20:35 Coke NotFound: or eliminated.
20:35 Coke NotFound: there's always svn.
20:35 dalek pipp: e0ab920 | (Bernhard Schmalhofer)++ | build/templates/Makefile.in:
20:35 dalek pipp: Eliminate make-target  build-common
20:35 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/e0ab9209966c28eb859c371c5a92d426b8a6b0d1
20:35 shorten dalek's url is at http://xrl.us/beibpt
20:35 dalek pipp: 2596f5b | (Bernhard Schmalhofer)++ | build/templates/Makefile.in:
20:35 NotFound rg: Check it in a way free of assumptions that can be wrong.
20:35 dalek pipp: Clean up unused vars
20:35 dalek pipp: review: http://github.com/bschmalhofer/pipp/commit​/2596f5b3523fc4011468ebf9762d1b9a5a2ba713
20:35 shorten dalek's url is at http://xrl.us/beibpv
20:37 NotFound Coke: that depends only of having people interested in writing such document.
20:38 ron Coke: do I seem to be headed off in the right direction on rt 40438 ?
20:39 Coke ron: did you post something else on the ticket?
20:39 Coke I apparently missed the recap portion here, if not.
20:39 ron not yet
20:39 Coke what is your direction? =-)
20:39 Coke sorry. scatterbrained and at $work.
20:40 ron I guess I am looking to clarify the ticket by noting that PerlString probably used an hll modifier and the problem is to get the hll modifier on pmcs, and particularly dynpmcs, to have the right effect on the sub/method namespace?
20:41 Coke I would verify that the dynpmcs we have in core allow subclassing.
20:41 Coke if /those/ work, then pursue the HLL angle.
20:42 japhb joined #parrot
20:43 ron Why isn't that covered by mdiep's posting to the ticket in March '07.  If I update his example with Pelr6Str it seems to work.
20:44 NotFound Coke: and check if there is a test for that, and write one if not, preferably.
20:45 nopaste "rurban" at 93.210.227.234 pasted "proposed pdd13_bytecode.patch" (85 lines) at http://nopaste.snit.ch/15773
20:45 Coke ron: checking.
20:47 NotFound Did we have a definition of the meaning of 'byte' in parrot documents?
20:47 Coke ron: rt is completely non responsive for me here.
20:48 Coke so I can't check.
20:49 rg notfound: do we need one? a byte should be pretty clear. i've seen a definition of char and grapheme and stuff in the string related docs.
20:49 nopaste "ron" at 168.100.250.30 pasted "mdiep's short posting on 40438" (19 lines) at http://nopaste.snit.ch/15774
20:49 NotFound rg: I think we need it, but it seems is not a popular point of view.
20:50 rurban one byte is unsigned char for us
20:50 rurban and everyone else I guess
20:50 NotFound rurban: wrong, for lots of people is '8 bits'
20:51 moritz "an octet"
20:51 rg that's what i'd assume
20:51 rg a byte is 8 bits, 0..255, no meaning attached.
20:51 NotFound moritz: one day I suggested using octect, and TinToaddy almost killed me ;)
20:51 rurban is there a conflict? we have two-byte encodings, yes
20:52 NotFound rg: we use C, and the C standard use byte as 'size of char'
20:52 moritz NotFound: apparently you survived ;-)
20:52 ron Coke: I just noposted the posting - if you missed it ...
20:52 Coke NotFound: timtoady is perl6. Are you talkinga bout perl6 or parrot?
20:52 NotFound moritz: I'm almost as hard as Bruce Willis
20:53 Coke ron: hurm. if that's the case, this might actually be already fixed with other object stuff.
20:53 NotFound Coke: not sure. He says we already have that definition, but I think he talked about perl6 documents.
20:54 ron Coke
20:54 NotFound rurban: no conflict as long as nobdy uses a compiler where CHAR_BIT != 8
20:55 rurban but we go with the compiler, not with 8bit assumption
20:55 ron You still need the ".HLL parrot" AFAICT and that would seem to be the problem.
20:55 rg notfound: the confusion starts when you start talking implementation and that c calls it char, whereas these days a character will not always fit into a byte.
20:55 rurban char <> character of course
20:55 NotFound rg: the charset and encoding problems are orthogonal with that.
20:57 rg i think a byte is a pretty safe term to use.
20:58 NotFound rg: maybe, but it does not harm to explictly stat what meaning we use.
21:02 NotFound rurban: I'd like to drop the "word size" thing and use opcode size instead.
21:03 rurban It is explained "An opcode corresponds to a word size"
21:03 NotFound And word size is?
21:03 rurban it is in fact the ptrsize, not the wordsize
21:04 ron Well - no one is saying I am headed in the wrong direction on the problem so off I go I guess.
21:05 rurban Nope, sorry. not opcode_t is the wordsize, opcode_t* is the ptrsize, both are used in the pbc, just wordsize is stored in the header, ptrsize not.
21:05 NotFound rurban: even worse, then. Is easier to drop it than to add long explanations.
21:06 rurban wordsize should be explained as intsize
21:06 rurban I rather wanted to explain the confusing point of cross-platform wordsize matters.
21:07 NotFound rurban: but that explanations may end to be "is the size of an opcode"
21:07 rurban "An opcode corresponds to the cpu wordsize"
21:08 NotFound rurban: I think that most platforms we work on have not a fixed word size.
21:08 rurban To add "The ptrsize is silently assumed to be the same as the opcode size."
21:08 rg notfound: huh?
21:09 NotFound rg: in the x86 word instructions have not fixed length, and there are several sizes of integer and integer operations.
21:09 NotFound world
21:10 rurban An opcode corresponds to the word size, defined as long. The ptrsize is silently assumed to be the same as the opcode size.
21:10 rurban better?
21:10 purl better is to create a new set of classes
21:11 rg i think the term word/word size is best avoided.
21:11 rurban well, wordsize is used as term in the header.
21:12 rurban so we should refer to that
21:12 NotFound rurban: I think the simpler solution is to describe the field in the header as "opcode size"
21:12 rg that would probably be better, but also probably a huge change
21:13 NotFound I'd also drop the (ASCII) thing in the description of the magic string. 0xFE is not ascii.
21:15 nopaste "rurban" at 93.210.227.234 pasted "proposed pdd13_bytecode.patch #2" (96 lines) at http://nopaste.snit.ch/15775
21:16 Coke purl, no, better is <reply>
21:16 purl okay, Coke.
21:16 NotFound rurban: clear enough for anow
21:17 rg can't say anything about the diff, but i guess i should really read the whole document rsn ;)
21:18 rurban ...And I almost thought I got long double jit working. not yet ready for prime time
21:19 NotFound rurban: Can you take a look at examples/embed and update Makefile.msvc?
21:19 rurban tommorrow, I'm just debugging jit
21:19 NotFound rurban: ok
21:21 rg rurban: if you're into jit, do you think you can help me with "coke's favourite ticket" ( http://rt.perl.org/rt3/Tic​ket/Display.html?id=36086 )?
21:23 rurban looks like the other jit issue with wrong integer rounding
21:23 dalek parrot: r37112 | rurban++ | trunk/docs/pdds/pdd13_bytecode.pod:
21:23 rurban I tried to sanify the fp_eq macro in my single-float work
21:23 dalek parrot: [docs] minor cleanup as per #parrot irc discussion
21:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37112/
21:24 rurban ok; I'll take a look
21:24 rurban I have the very same issues right now with NaN on long double jit
21:25 rg ok then just finish your issues, maybe it will go away ;)
21:26 rurban rg: this is a i->n issue, I have a different problem right now. i->n => nan
21:28 rg hitting exactly nan is interesting
21:28 rurban or it could be a wrong optimizer using the non-assigned register for the 2nd calculation
21:28 rurban wrongly paralellizing instructions
21:29 rg i didn't think i386 was parallelizing instructions.
21:31 rg what's keeping me stumped is that if i substitute sinh with atan it works although the only difference i can find is a different call address
21:32 rurban there's no single i386 anymore in existance. it's always at last i686, and this uses the int and fpu unit in parallel
21:33 rurban t/op/jitn_5.pasm is abouzt the same. this is afling right now for me
21:33 rurban afling => failing
21:34 szbalint I guess if a fling is failing then that's a missed opportunity :)
21:35 NotFound rg: several math functions can be macros, using them as function addresses can give unexpected results.
21:35 NotFound s/rg/rurban
21:36 rurban I have only sub in my case, which might be a macro for add, but I doubt it.
21:37 NotFound rurban: I mean C functions, not parrot ones
21:37 rurban in jit land not anymore
21:38 rurban We only use very few CALL_FUNCTION, mainly for strings
21:39 NotFound What does jit use for sinh, direct conversion to fp machine code?
21:39 rg sinh is my bug
21:40 rg and no, there's no sinh fp opcode
21:40 rg it should be a math library function call, although it's pretty well hidden.
21:40 rg (so far i only found a call into a jump table)
21:41 rurban we have only sin/cos/sqrt/pow. not any transitive functions in jit.
21:42 rurban It could be the P_ARITH macro which is missing some _n variants
21:42 rurban Parrot_ifunless_x_ic uses this
21:45 rurban nope, I was wrong.
22:02 GeJ Good morning everyone
22:07 Infinoid hi GeJ
22:17 rurban s/transitive/transcendental/
22:24 Whiteknight joined #parrot
22:47 dalek rakudo: 086b4ba | (Moritz Lenz)++ | t/spectest.data:
22:47 dalek rakudo: we pass action-stubs.t, add it to spectest.data
22:47 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​86b4ba8f5a217cbfe6c58cfdb670156f4866c8a
22:47 shorten dalek's url is at http://xrl.us/beib9v
23:29 Limbic_Region joined #parrot
23:35 allison purl: 1.0 is “Shipping a 1.0 product isn’t going to kill you, but it will try.” http://www.randsinrepose.com​/archives/2006/04/20/10.html
23:35 purl ...but 1.0 is 1 is true or SOOO 2006...
23:36 allison purl: 1.0 is also “Shipping a 1.0 product isn’t going to kill you, but it will try.” http://www.randsinrepose.com​/archives/2006/04/20/10.html
23:36 purl okay, allison.
23:41 Infinoid allison: hi!  got a moment?
23:41 allison Infinoid: sure
23:41 Infinoid (if you're not too busy being attacked by 1.0 and all of that)
23:41 allison :)
23:41 allison go ahead
23:41 Infinoid Ok.  I need to make some drupal pages that bounce to other sites, and I also need to upload some binary files.  (PDFs from the talk pages)
23:42 Infinoid was wondering if you could tell me the right way to do those
23:42 Infinoid s/talk pages/talks page/
23:42 Infinoid For the bounces, I can just stick a meta refresh tag into an html page, but I figured I'd better ask in case there's a better way
23:43 allison for the second, every page allows you to attach files to it
23:43 Psyche^ joined #parrot
23:43 Infinoid Is there a link for that which I'm missing somewhere?
23:43 allison See http://www.parrot.org/foundation/legal for an example
23:43 Infinoid I don't see an "upload" or an "attach"
23:44 allison Infinoid: when you click "Edit" on the page, down near the bottom you should see "File attachments"
23:44 Infinoid Ah.  Too obvious, I missed it.  Thanks.
23:44 allison it's buried
23:45 Infinoid Lots of widgets on that edit page
23:45 allison Infinoid: aye, we keep wanting more features :)
23:45 allison on the first, what kind of page do you want?
23:46 allison that is, do you want an actual page with content in Drupal, or do you just want a www.parrot.org URL that redirects to another page?
23:46 Infinoid I want to do something like http://www.parrotcode.org/openpatches.html and bounce the client to https://trac.parrot.org/parrot/report/15
23:46 Infinoid I just want a redirect
23:46 nopaste "NotFound" at 213.96.228.50 pasted "pbc_checker - perliminary version" (222 lines) at http://nopaste.snit.ch/15777
23:46 Infinoid I don't need to encapsulate the content
23:46 allison okay, then you want the Aliases feature
23:47 allison Infinoid: let me check and see if you have access to that feature at the moment...
23:47 Infinoid I didn't think aliases could target URLs outside the site.  I'll look again
23:47 NotFound Can someone compile this and try with parrot_config.pbc in some non-i386 platform?
23:48 dalek rakudo: 412cbe9 | (Moritz Lenz)++ | t/spectest.data:
23:48 dalek rakudo: [t/spectest] add new S06-signature/positional.t
23:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​12cbe95b09fdb881b07e3c76075233ed79faffd
23:48 shorten dalek's url is at http://xrl.us/beich7
23:48 allison Infinoid: there are two different kinds, one is "URL aliases" which are only local, and the other is "URL redirects" which can be external
23:48 Infinoid oh, ok.  I only have URL aliases
23:48 moritz NotFound: does amd64 count as non-i386?
23:48 rg notfound: would amd64 be non-i386 enough?
23:48 moritz heh
23:48 allison Infinoid: http://www.parrot.org/smolder is an external redirect
23:49 NotFound rg: yeah
23:49 Infinoid nice.  I don't think I have access to those, or I don't know where to look (there's no URL redirects in the menu on the right, but there is URL aliases)
23:50 moritz NotFound: compiles on amd64
23:50 moritz NotFound: and does not complain loudly about perl6.pbc
23:51 NotFound moritz: and the information shown looks reasonable?
23:51 moritz yes
23:51 nopaste "rg" at 62.216.212.107 pasted "pbc_checker parrot_config.pbc output" (10 lines) at http://nopaste.snit.ch/15778
23:51 nopaste "moritz" at 91.10.184.100 pasted "output for NotFound" (11 lines) at http://nopaste.snit.ch/15779
23:51 allison Infinoid: I've bumped up your permissions, use them wisely :)
23:52 Infinoid thanks, I'll try not to break anything
23:53 * moritz mostly knows Infinoid++ from unbreaking stuff ;-)
23:53 NotFound moritz: 0 directory entries is not reasonable to me
23:54 rg it's not nan, how would we know ;)
23:54 moritz NotFound: I probably don't know PBC enough to know what's reasonable
23:54 NotFound moritz: please try with parrot_config.pbc
23:54 rg notfound: i also have 0 directory entries with parrot_config.pbc
23:54 moritz also 0 Directory entries
23:55 moritz you could use perl + unpack, it  should be pretty portable
23:56 NotFound moritz: I'm more fluent with c++ than with perl
23:56 rg moritz: sorry, i think unpack make pretty unreadable code
23:57 moritz I said nothing about readability ;-)
23:57 NotFound Did we alredy have some store of binary pbc from several platforms?
23:58 rg there are pbc in t/native_pbc
23:59 rg the 64bit versions are outdated one update

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

Parrot | source cross referenced