Parrot 0.9.1 Released | parrot.org/ | 451 RTs left!
Set by moderator on 24 February 2009.
allison I still object to the idea of Parrot never shipping a stable release 00:00
it fundamentally bothers me
chromatic I object to the idea that Parrot never ships a stable release.
I can think of a couple of dozen stable releases.
allison but, they were all numbered 0.X, which is development numbering 00:01
by that logic, we should have shipped 1.0 4 years ago
and really, we probably should have
but, we didn't
chromatic Let's not get into a discussion of magical thinking and version numbers again.
Tene_ We could pull an emacs.
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
Tene: emacs?
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
Infinoid Tene_: Yeah. Or we could NOT!
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.
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.
It was a silly suggestion.
they went from 0.18 to 19
NotFound The question may be if that power is greater than the time we spend trying to achieve it.
allison oh, Solaris-style revisioning, yes, that's silly
NotFound: well, we've spent an awful lot of time on this
NotFound: more than it's worth 00:04
chromatic bugfix_only and monthly
NotFound allison: not yet, but I fear we can walk in that direction
allison here's my compromise suggestion:
In the documents we talk about Supported and Developer releases, and use the phrase "critical bug/security fixes" 00:05
the ftp directories use "stable"/"devel" which is extensively common
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
chromatic "Developer", "stable", and "devel" already encourage certain behaviors based on their connotations. 00:08
allison chromatic: I respect your opinion.
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.
allison yes, but those behaviors are mostly what we want
chromatic Those behaviors are what YOU want.
I want to let people decide without pushing them one way or another.
allison I think you want them to upgrade every month, yes? 00:09
00:09 AndyA joined
chromatic Yes, I do. 00:09
allison okay, just so we're clear
chromatic I don't expect everyone will.
I don't particularly care about naming semantics, provided that: 00:10
1) They reflect measurable differences between types of releases 00:11
2) They accurately describe the nature of the releases
3) They don't imply additional pro or con connotations that we don't intend
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.
allison NotFound: which is a terrible scheme
chromatic Our deprecation policy doesn't really come into play there.
Infinoid NotFound: Not really. Something like "supported" and "monthly" says exactly what they should say and nothing else, I think
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?
NotFound Infinoid: "monthly" has been already critizised
Infinoid NotFound: It isn't inaccurate
NotFound Infinoid: not by me ;) 00:14
allison chromatic: "our deprecation policy doesn't really come into play" is inaccurate.
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
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)
allison chromatic: it's fine for you not to think about those things
chromatic: you can think only about each monthly release and nothing else
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 ;)
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
chromatic I thought a big part of my argument *was* external perception.
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.
chromatic YOU WILL ONLY GET CRITICAL BUGFIXES AND SECURITY PATCHES 00:18
THERE ARE TWO OF THESE RELEASES A YEAR
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)
chromatic DO NOT LEAVE IT IS NOT REAL
NO OTHER RELEASE IS STABLE WE JUST LIKE MAKING RELEASES IT MIGHT EVEN COMPILE IF YOU ARE LUCKY STOP SEND MONEY STOP 00:19
... AND THEY HAVE A PLAN
allison now that is a strawman
chromatic No one ever said the Cylons have a *good* plan.
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
Which is all the support we offer for releases.
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?
allison chromatic: yes, January and July get the maximum level of support
chromatic What's wrong with the label "supported"?
allison rurban: it's not there yet, I will edit after we close this discussion
chromatic rurban, I don't think it's in the support policy yet.
allison chromatic: it requires explanation
chromatic So does "stable"! 00:23
allison chromatic: which is fine in the docs
chromatic: anyone who has navigated FTP directories will get the difference between "devel" and "stable"
chromatic But that difference is immaterial to Parrot!
irclog.perlgeek.de/parrot/2009-03-03#i_954870 00:24
allison chromatic: there is a difference, we've already agreed on that
chromatic Okay. 00:25
We *know* what "supported" means in this context.
allison chromatic: I don't get what you're referring to with the IRC link
chromatic We *know* we have to explain it.
We *know* that the difference between a January and a February release is that we support the former but not the latter.
... thus we refer to them as "stable" and "development". 00:26
allison chromatic: plus deprecation cycles, plus packaging
chromatic You can't stick information about deprecation cycles and packaging into a single-word label. I'm deliberately ignoring that.
allison chromatic: you have the luxury of ignoring it, they are all characteristics of the Jan/Jul releases 00:27
chromatic: ignoring a third of the factors is a disadvantage in reaching a conclusion that addresses all the factors
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
"stable" does it 00:29
chromatic and, optionally, it shouldn't imply things about the other 10 releases a year
at least, things that aren't true
allison chromatic: language is full of implications, I can live with implications, as long as they don't make us sloppy 00:30
(that is, if we still work just as hard on ticket closing, etc on all the releases)
chromatic THat's exactly why I don't like stable/foo.
allison (and, don't put out a release that doesn't compile)
chromatic: that's about our internal policy 00:31
chromatic: it has nothing to do with the name
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?
chromatic If we put out 12 stable releases a year, does that say anything better about us? 00:33
allison chromatic: no
rurban inflation and arrogance
chromatic Arrogant?
purl i guess Arrogant is an understatement
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?
allison chromatic: strawman again
rurban we cannot maintain stable releases, and we do not want to.
chromatic How in the world is that a strawman?
NotFound, it happened for Perl 5.10.
rurban 12x stable a year
chromatic Or should I say, it's still happening.
allison chromatic: the idea that the name means we're taking away opportunity
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"
rurban we are changing the API, the pbc's, the pmc's, the ops all around. That's the opposite of stable.
allison chromatic: that's a problem I don't want to repeat with Parrot 1.0
chromatic Yes. In a directory on the CPAN.
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".
Thus, I agree.
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:37
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.
allison okay
chromatic If a compiler developer decides to use a February release, is that a problem? 00:39
allison chromatic: no, not a problem
chromatic Is that something to encourage or to discourage, or neither?
allison it just has certain implications
s/he won't get critical bug/security fixes to that release
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)
and, the release won't be packaged, so his/her users will have to download and compile from source 00:41
chromatic Okay, stop.
That's something we can't measure again. Let's throw that out.
allison (compile parrot, that is)
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.
allison NotFound: :)
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.
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.
gravity More like 1.5-2 years these days
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.
allison chromatic: accepted as a rabbit trail
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?
chromatic Ideally I'd like to have two simple, unambiguous, and roughly parallel terms.
gravity NotFound: Depends on what you mean
Infinoid gravity: You might not be by the time this discussion is over.
NotFound gravity: it you expect to live long enough :D
gravity Ha!
NotFound if
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."
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.
allison gravity: Colin Watson and Jeff Bailey
NotFound We can put a file in the ftp called READ_CAREFULLY_BEFORE_ASSUME_ANYTHING__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?
gravity allison: Ah, yeah Colin's wonderful, but always busy. I have yet to meet Jeff.
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.
allison chromatic: the clueless newbies need a warning
a warning before they even read the documentation
chromatic What's that, "Stick with your distro package"?
Infinoid "Buckle up." 00:50
allison chromatic: that first, and then second they need to immediately recognize what the next level of complexity is
gravity: they're all great, just busy
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"
Infinoid -> svn 00:52
allison gravity: we're producing the packages, just need them reviewed and sponsored for inclusion
Infinoid: yes
gravity allison: I can do that. How do you and all the other sponsors normally communicate? 00:53
NotFound -> patches nopasted ;)
allison gravity: email. We created an alioth group/mailing list, but has had no traffic
gravity: it's all been private email exchanges 00:54
gravity Heh, ok
chromatic What's wrong with "latest_supported_version" and "latest_monthly_version"? 00:55
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.
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?
What does "devel" mean though?
We don't know what "stable" means, and I thought we set aside the "package" rabbit trail.
I've contributed to this project for 7 years. If I don't know what these labels mean, what hope does any novice have?
allison chromatic: we set aside Debian/Ubuntu/whatever's upgrade policy as a rabbit trail 00:56
chromatic: we know what they mean because we define them
chromatic Don't you see, that's the problem!
allison chromatic: outsiders know 90% of what they mean from prior experience with other projects
chromatic: they learn the rest as they learn more about the project 00:57
00:57 ron joined
chromatic I have trouble thinking of other projects which produce stable monthly releases. 00:57
allison Bazaar 00:58
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.
They tend not to play those games. 01:00
allison which is likely where your perspective comes from
the also, IIRC, don't do bug/security fixes
chromatic Sure they do, when necessary. 01:01
They can release a new stable version of their software at any point.
allison I'm working on the support policy doc now 01:03
chromatic Fine. Go ahead. 01:04
allison I just wanted to let you know why I wasn't focused here 01:06
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).
unless of course you're talking for the logs ;) 01:10
01:47 HG` joined 02:10 buildbot joined 02:24 HG` joined 02:31 jan joined 02:50 rurban_ joined 03:36 tetragon joined 03:42 janus joined
dalek kudo: 55fb203 | pmichaud++ | src/parser/grammar.pg:
Update pod_comment to handle =begin END, some pod errors (from STD.pm).
 04:13
shorten dalek's url is at xrl.us/beh89q
dalek rrot: r37101 | allison++ | trunk/docs/project/support_policy.pod:
[docs] Update the support policy with clarifications and changes based
 04:32
05:02 Andy joined 05:09 Theory joined
japhb Any svn ops around? 05:33
05:36 Ademan joined
japhb Any metacommiters? 05:41
anyone at all? 05:42
cotto nope 05:43
japhb bugger all. 05:44
purl i dunno, japhb
cotto What needs to happen? 05:46
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:48
japhb grumbles mildly about the account not being transfered automagically from the old repo 05:49
cotto I think allison can do that.
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.'
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
japhb longs for the "metacommitter or six in every time zone" of the Pugs days
japhb commits to local git repo for the time being 05:52
allison japhb: I'll set you up, what's your Trac user account? 05:54
japhb japhb
allison: Thank you.
allison okay, just a sec (has to be added to the permissions list)
japhb And sorry for the grumbling. It's been a grumbly day. :-/
allison japhb: done, and also added your permissions for ticket management 05:56
japhb: some days are like that :)
japhb allison: thanks again
allison japhb: anytime :) 05:57
dalek rrot: r37102 | japhb++ | failed to fetch changeset:
[examples/mops] Fix mops.p6 for current Perl 6 (and Rakudo)

  * Uppercase name of MAIN subroutine so that it will be executed		 06:03
japhb "failed to fetch changeset"? 06:04
06:14 Tene joined
cotto That's how trac rolls. 06:15
allison cotto: I always thought that was dalek? 06:16
dalek rrot: r37103 | japhb++ | trunk/examples/mops/mops.p6:
[examples/mops] mops.p6: Fix pod (typos, errors, poor wording)
 06:23
rrot: r37104 | japhb++ | trunk/examples/mops/mops.p6:
[examples/mops] mops.p6: fix comments and pod to match mops_intval.pasm
 06:27
06:28 contingencyplan joined
dalek rrot: r37105 | japhb++ | trunk/examples/mops/mops.p6:
[examples/mops] mops.p6: Fix missed reference to mops_intval.pasm
 06:30
japhb dalek or trac are running really slowly 06:31
that string came in a git svn dcommit -- so three commits over the course of a few seconds, not 8-10 minutes ... 06:32
dalek rrot: r37106 | allison++ | trunk/docs/project (2 files):
[doc] Took a few minutes to update the Metacommitter guide after adding
 06:34
06:50 Ademan joined
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:51
(virtual email being japhb@svn.parrot.org) 06:52
japhb allison: sounds possible. We'll see next time I commit ... 06:53
cotto I thought dalek followed rss feeds.
07:06 uniejo joined
cotto coke++ #twip 07:39
07:50 szabgab joined 08:02 TiMBuS joined 08:12 xinming joined 08:13 xinming left 08:20 Khisanth joined
dalek rrot: r37107 | allison++ | trunk/parrotbug:
[cage] Committing a modified version of Patrick's patch from TT #27.

their created report to Trac. (The information captured by parrotbug can be handy, especially when working with inexperienced users.)		 08:22
kudo: a2f5064 | (Moritz Lenz)++ | t/spectest.data:
Track changed test file names by frew++ in t/spectest.data
 08:56
shorten dalek's url is at xrl.us/beh9rg 08:57
09:04 alvar joined 09:08 gryphon joined 09:21 justin joined 09:23 mberends joined 09:59 cotto joined 11:01 riffraff joined
cotto The Continuation PMC tests are minimal. 12:07
I guess they get plenty of indirect coverage, though. 12:31
12:33 rg1 joined 12:51 protorom joined 12:58 protorom left
Infinoid allison, cotto, japhb: yes, dalek follows rss feeds, so it would be trac slowness 13:02
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:04
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:05
13:29 msmouse joined
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:37
13:39 msmouse left 13:40 masak joined
dalek rrot: r37108 | fperrad++ | trunk/config/gen/makefiles (2 files):
[makefile] try to prevent problem with implicit rule (see r37098). But it's just a comment.
 13:40
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:48
13:56 Tene_ joined 14:00 gryphon joined 14:10 jsut|w3rk joined, masak joined
dalek kudo: cc1e659 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 256 files, 5648 passing, 0 failing
 14:26
shorten dalek's url is at xrl.us/beh973
rg1 ouch. how did rakudo lose over 1k passing tests? 14:30
pmichaud someone reorganized the spectest suite last night but didn't update rakudo's t/spectest.data file. 14:31
a bunch of test files got renamed.
moritz pmichaud: I did the rename 14:45
in a2f5064e7725e2a70f32041dc4b5d73a3d6f6fd7
did I forget to push it?
rg1 dalek reported it. but i have no idea how git works. 14:47
pmichaud moritz: yes, but the rename came after 00:00 CST 14:48
the tests moved before 00:00 CST
(and I report statistics as of 00:00 CST)
moritz that's unfortunate
rg1 oh, so it will get back to 7k+ in tomorrow's report?
moritz yes 14:49
(unless somebody breaks it again in the mean time ;-)
dalek kudo: 8637bed | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv correction to total spectest count
 14:52
shorten dalek's url is at xrl.us/beiaba
dalek kudo: b60ccaf | pmichaud++ | tools/test_summary.pl:
Add S32 to test_summary.pl scanning.
shorten dalek's url is at xrl.us/beiabc
14:58 msmouse joined 15:20 Patterner joined 15:22 msmouse joined 15:27 ron joined 15:35 mj41 joined 15:53 Whiteknight joined
Infinoid this is what my car looked like half an hour ago: quack.glines.org/upload/infinoid/03042009.jpg 15:56
pmichaud Infinoid: nice paint job... perhaps a bit heavy on the white, though.
Infinoid Apparently, this is what "spring" looks like here. 15:57
szbalint wow nice, all the snow finally melted here last week :)
pmichaud we didn't get any snow here this year.
lots of very cold days, but no snow.
16:05 Theory joined 16:06 Theory joined
dalek kudo: 33ddc70 | pmichaud++ | src/classes/Grammar.pir:
Allow Grammar.parse() and Grammar.parsefile() to take options.
 16:11
shorten dalek's url is at xrl.us/beiakf
16:17 davidfetter joined
Whiteknight infinoid, where do you live? My car looked like that yesterday 16:19
Infinoid Whiteknight: lake tahoe 16:23
Whiteknight oh wow, so nowhere near me 16:24
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:27
davidfetter: Did you resolve your `make rpms` issues? 16:28
davidfetter Util, not yet
davidfetter on f10, fwiw
Infinoid Whiteknight: whereabouts are you? 16:29
any drupal experts in the house?
Whiteknight Infinoid: I'm near Philadelphia 16:30
Util I tried it (on Mandriva) for the first time yesterday. 16:31
It bombed in the `rpmbuild` step, because '0.9.1-devel' is an invalid version identifier.
The version cannot contain a dash; it is reserved for seperation: Name-Version-Revision.
dalek rrot: r37109 | Util++ | trunk/docs (4 files):
[docs] Typos - s/navitate/navigate/; Committer has 2 "m"s and 2 "t"s
 16:38
16:40 Theory joined
davidfetter Util, i tried from the tarball and it bombed on what appeared to be some kind of mixup with CRLF 16:45
16:47 bacek joined
dalek rrot: r37110 | Util++ | trunk/src/sub.c:
Typo in sub.c - s/sctatchpad/scratchpad/
 16:59
17:05 Whiteknight joined 17:28 Tene joined 17:46 barney joined 17:48 Whiteknight_ joined 18:01 szabgab joined 18:10 Psyche^ joined 18:21 Theory joined 18:22 mikehh joined 18:30 tuxdna joined 18:53 justin joined 18:58 protorom joined 18:59 protorom left 19:16 DietCoke joined
Coke . 19:16
Whiteknight .? 19:17
PerlJam END OF LINE. 19:18
Coke "Here I am. Especially you, purl, who likes to spam me with things when I speak."
PerlJam: Yes I'm old. Old enough to remember when the MCP was just a chess program! 19:19
... hey, just like skynet. 19:20
allison www.randsinrepose.com/archives/2009..._test.html 19:36
shorten allison's url is at xrl.us/beibfd
Coke allison: thanks for updating support_policy. I need to read the updated version. 19:45
dalek pp: bbf5a2c | (Bernhard Schmalhofer)++ | (5 files):
Add a '--run-pir' option to pipp.pbc.
 19:46
shorten dalek's url is at xrl.us/beibgg
dalek pp: bd1c7f3 | (Bernhard Schmalhofer)++ | t/harness:
The exex sub needs to return an array of strings.
shorten dalek's url is at xrl.us/beibgk
dalek pp: 63e6188 | (Bernhard Schmalhofer)++ | t/pmc/ (2 files):
The pragma .loadlib conflicts with running via --run-pir
shorten dalek's url is at xrl.us/beibgp
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
Tene ron: iirc it also affects the hll namespace that the class is registered in 19:48
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:49
Tene I've been running Parrot on 64bit linux for as long as I'v ebeen working with parrot. 19:50
JIT doesn't work last I checked, though.
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
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:54
dalek rrot: r37111 | coke++ | trunk/docs/project/support_policy.pod:
[docs] Convert faux lists into actual POD lists.
 19:56
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
I don't know off the top of my head, or I'd just answer it.
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:03
davidfetter hi 20:06
Util, around?
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
Whiteknight so allison, what is our Larry test for 1.0?
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.
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?
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.
rurban yes, but it's unfortunate
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?
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
currently I only have a 386 laptop without 64bit support and can only guess 20:12
Coke ron: yes.
for example: .param pmc args :slurpy 20:13
that gets the hll-mapped version of a resizablepmcarray.
ron That is why I left out tcllist
NotFound rurban: the problem lies here: few people use 64 bit machines.
Coke checks out the ticket again.
rurban but sooner or later they'll switch
NotFound rurban: I've been hearing that for years 20:14
rurban our new buildbot e.g. is 64bit
NotFound So the "sooner" is timed out :D
rurban sooner than later
rg notfound: any serious server will be 64bit these days.
NotFound rg: I don't work on parrot on serious servers 20:15
Coke ron: ah, that one.
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.
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.
NotFound rg: yes, but having a goal is a poor help if almost nothing have the tools-.
Coke then we have a list we can point to and say, "just these left."
rurban ok, will do 20:17
Coke I for one don't have a 64bit box to test on.
rurban It would help if my various patches get tested
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:20
rurban rg: can you test the TT#264 hints patch? 20:21
oops #364 it is
trac.parrot.org/parrot/attachment/...lign.patch 20:22
shorten rurban's url is at xrl.us/beibnk
NotFound pdd13_bytecode.pod is up to date? 20:23
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?
NotFound "A number of things in this proposed PDD differ from the old implementation, and few items are not yet implemented." ---> This sucks
rurban NotFound: yes
this is the current state, milestone is 2.6
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.
dalek pp: 7ced896 | (Bernhard Schmalhofer)++ | t/ (2 files):
Run tests with ./pipp
 20:26
shorten dalek's url is at xrl.us/beibof
dalek pp: 55e0a42 | (Bernhard Schmalhofer)++ | t/harness:
path_to_parrot() is no longer needed
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
shorten dalek's url is at xrl.us/beiboh
NotFound Not removing, clarifying
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?
rurban In the pdd? go away, its implemented
NotFound rurban: then someone who knows about must fix the document. 20:28
rurban will do. let me finish the 64bit keywords first
NotFound rurban: thanks 20:29
Coke long term, the PDDs shouldn't mention what was, only what is and will be. 20:32
(our users don't care what we did in 0.3.4)
NotFound My idea is to write a program to read pbc and check them, completely free of parrot code and headers.
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?
NotFound rg: aye
Coke NotFound: or eliminated. 20:35
NotFound: there's always svn.
dalek pp: e0ab920 | (Bernhard Schmalhofer)++ | build/templates/Makefile.in:
Eliminate make-target build-common
shorten dalek's url is at xrl.us/beibpt
dalek pp: 2596f5b | (Bernhard Schmalhofer)++ | build/templates/Makefile.in:
Clean up unused vars
NotFound rg: Check it in a way free of assumptions that can be wrong.
shorten dalek's url is at xrl.us/beibpv
NotFound Coke: that depends only of having people interested in writing such document. 20:37
ron Coke: do I seem to be headed off in the right direction on rt 40438 ? 20:38
Coke ron: did you post something else on the ticket? 20:39
I apparently missed the recap portion here, if not.
ron not yet
Coke what is your direction? =-)
sorry. scatterbrained and at $work.
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:40
Coke I would verify that the dynpmcs we have in core allow subclassing. 20:41
if /those/ work, then pursue the HLL angle.
20:42 japhb joined
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:43
NotFound Coke: and check if there is a test for that, and write one if not, preferably. 20:44
nopaste "rurban" at 93.210.227.234 pasted "proposed pdd13_bytecode.patch" (85 lines) at nopaste.snit.ch/15773 20:45
Coke ron: checking.
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.
so I can't check. 20:48
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 nopaste.snit.ch/15774
NotFound rg: I think we need it, but it seems is not a popular point of view.
rurban one byte is unsigned char for us 20:50
and everyone else I guess
NotFound rurban: wrong, for lots of people is '8 bits'
moritz "an octet" 20:51
rg that's what i'd assume
a byte is 8 bits, 0..255, no meaning attached.
NotFound moritz: one day I suggested using octect, and TinToaddy almost killed me ;)
rurban is there a conflict? we have two-byte encodings, yes
NotFound rg: we use C, and the C standard use byte as 'size of char' 20:52
moritz NotFound: apparently you survived ;-)
ron Coke: I just noposted the posting - if you missed it ...
Coke NotFound: timtoady is perl6. Are you talkinga bout perl6 or parrot?
NotFound moritz: I'm almost as hard as Bruce Willis
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.
ron Coke 20:54
NotFound rurban: no conflict as long as nobdy uses a compiler where CHAR_BIT != 8
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.
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.
rurban char <> character of course
NotFound rg: the charset and encoding problems are orthogonal with that.
rg i think a byte is a pretty safe term to use. 20:57
NotFound rg: maybe, but it does not harm to explictly stat what meaning we use. 20:58
rurban: I'd like to drop the "word size" thing and use opcode size instead. 21:02
rurban It is explained "An opcode corresponds to a word size" 21:03
NotFound And word size is?
rurban it is in fact the ptrsize, not the wordsize
ron Well - no one is saying I am headed in the wrong direction on the problem so off I go I guess. 21:04
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.
rurban wordsize should be explained as intsize 21:06
I rather wanted to explain the confusing point of cross-platform wordsize matters.
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"
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."
rg notfound: huh?
NotFound rg: in the x86 word instructions have not fixed length, and there are several sizes of integer and integer operations. 21:09
world
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
better?
purl better is to create a new set of classes
rg i think the term word/word size is best avoided. 21:11
rurban well, wordsize is used as term in the header.
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"
rg that would probably be better, but also probably a huge change
NotFound I'd also drop the (ASCII) thing in the description of the magic string. 0xFE is not ascii. 21:13
nopaste "rurban" at 93.210.227.234 pasted "proposed pdd13_bytecode.patch #2" (96 lines) at nopaste.snit.ch/15775 21:15
Coke purl, no, better is <reply> 21:16
purl okay, Coke.
NotFound rurban: clear enough for anow
rg can't say anything about the diff, but i guess i should really read the whole document rsn ;) 21:17
rurban ...And I almost thought I got long double jit working. not yet ready for prime time 21:18
NotFound rurban: Can you take a look at examples/embed and update Makefile.msvc? 21:19
rurban tommorrow, I'm just debugging jit
NotFound rurban: ok
rg rurban: if you're into jit, do you think you can help me with "coke's favourite ticket" ( rt.perl.org/rt3/Ticket/Display.html?id=36086 )? 21:21
rurban looks like the other jit issue with wrong integer rounding 21:23
dalek rrot: r37112 | rurban++ | trunk/docs/pdds/pdd13_bytecode.pod:
[docs] minor cleanup as per #parrot irc discussion
rurban I tried to sanify the fp_eq macro in my single-float work
rurban ok; I'll take a look 21:24
I have the very same issues right now with NaN on long double jit
rg ok then just finish your issues, maybe it will go away ;) 21:25
rurban rg: this is a i->n issue, I have a different problem right now. i->n => nan 21:26
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
wrongly paralellizing instructions
rg i didn't think i386 was parallelizing instructions. 21:29
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:31
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:32
t/op/jitn_5.pasm is abouzt the same. this is afling right now for me 21:33
afling => failing
szbalint I guess if a fling is failing then that's a missed opportunity :) 21:34
NotFound rg: several math functions can be macros, using them as function addresses can give unexpected results. 21:35
s/rg/rurban
rurban I have only sub in my case, which might be a macro for add, but I doubt it. 21:36
NotFound rurban: I mean C functions, not parrot ones 21:37
rurban in jit land not anymore
We only use very few CALL_FUNCTION, mainly for strings 21:38
NotFound What does jit use for sinh, direct conversion to fp machine code? 21:39
rg sinh is my bug
and no, there's no sinh fp opcode 21:40
it should be a math library function call, although it's pretty well hidden.
(so far i only found a call into a jump table)
rurban we have only sin/cos/sqrt/pow. not any transitive functions in jit. 21:41
It could be the P_ARITH macro which is missing some _n variants 21:42
Parrot_ifunless_x_ic uses this
nope, I was wrong. 21:45
GeJ Good morning everyone 22:02
Infinoid hi GeJ 22:07
rurban s/transitive/transcendental/ 22:17
22:24 Whiteknight joined
dalek kudo: 086b4ba | (Moritz Lenz)++ | t/spectest.data:
we pass action-stubs.t, add it to spectest.data
 22:47
shorten dalek's url is at xrl.us/beib9v
23:29 Limbic_Region joined
allison purl: 1.0 is “Shipping a 1.0 product isn’t going to kill you, but it will try.” www.randsinrepose.com/archives/2006...20/10.html 23:35
purl ...but 1.0 is 1 is true or SOOO 2006...
allison purl: 1.0 is also “Shipping a 1.0 product isn’t going to kill you, but it will try.” www.randsinrepose.com/archives/2006...20/10.html 23:36
purl okay, allison.
Infinoid allison: hi! got a moment? 23:41
allison Infinoid: sure
Infinoid (if you're not too busy being attacked by 1.0 and all of that)
allison :)
go ahead
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)
was wondering if you could tell me the right way to do those 23:42
s/talk pages/talks page/
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
allison for the second, every page allows you to attach files to it 23:43
23:43 Psyche^ joined
Infinoid Is there a link for that which I'm missing somewhere? 23:43
allison See www.parrot.org/foundation/legal for an example
Infinoid I don't see an "upload" or an "attach"
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.
allison it's buried
Infinoid Lots of widgets on that edit page 23:45
allison Infinoid: aye, we keep wanting more features :)
on the first, what kind of page do you want?
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 www.parrotcode.org/openpatches.html and bounce the client to trac.parrot.org/parrot/report/15
I just want a redirect
nopaste "NotFound" at 213.96.228.50 pasted "pbc_checker - perliminary version" (222 lines) at nopaste.snit.ch/15777
Infinoid I don't need to encapsulate the content
allison okay, then you want the Aliases feature
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
NotFound Can someone compile this and try with parrot_config.pbc in some non-i386 platform?
dalek kudo: 412cbe9 | (Moritz Lenz)++ | t/spectest.data:
[t/spectest] add new S06-signature/positional.t
 23:48
shorten dalek's url is at xrl.us/beich7
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
Infinoid oh, ok. I only have URL aliases
moritz NotFound: does amd64 count as non-i386?
rg notfound: would amd64 be non-i386 enough?
moritz heh
allison Infinoid: www.parrot.org/smolder is an external redirect
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)
moritz NotFound: compiles on amd64 23:50
NotFound: and does not complain loudly about perl6.pbc
NotFound moritz: and the information shown looks reasonable? 23:51
moritz yes
nopaste "rg" at 62.216.212.107 pasted "pbc_checker parrot_config.pbc output" (10 lines) at nopaste.snit.ch/15778
"moritz" at 91.10.184.100 pasted "output for NotFound" (11 lines) at nopaste.snit.ch/15779
allison Infinoid: I've bumped up your permissions, use them wisely :)
Infinoid thanks, I'll try not to break anything 23:52
moritz mostly knows Infinoid++ from unbreaking stuff ;-) 23:53
NotFound moritz: 0 directory entries is not reasonable to me
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
NotFound moritz: please try with parrot_config.pbc
rg notfound: i also have 0 directory entries with parrot_config.pbc
moritz also 0 Directory entries
you could use perl + unpack, it should be pretty portable 23:55
NotFound moritz: I'm more fluent with c++ than with perl 23:56
rg moritz: sorry, i think unpack make pretty unreadable code
moritz I said nothing about readability ;-) 23:57
NotFound Did we alredy have some store of binary pbc from several platforms?
rg there are pbc in t/native_pbc 23:58
the 64bit versions are outdated one update 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!