Parrot 0.9.1 Released | parrot.org/ | 458 RTs left!
Set by moderator on 18 February 2009.
dalek rrot: r36872 | jkeenan++ | trunk/docs/book/ch04_pir_subroutines.pod:
Did some of the spelling/grammatical corrections suggested by Heiko.
 00:06
00:09 AndyA joined
dalek rrot: r36873 | jkeenan++ | trunk/docs/book/ch04_pir_subroutines.pod:
Did one more of the spelling/grammatical corrections suggested by Heiko.
 00:10
particle rakudo: say 7 % 10 + '0' 00:27
polyglotbot OUTPUT[7␤]
particle rakudo: say '0' + (7 % 10)
polyglotbot OUTPUT[7␤]
particle rakudo: say ('0' + (7 % 10)).Str 00:28
polyglotbot OUTPUT[Num<0xb6bb2b80>␤]
particle hrmm
rakudo: say 'a'
polyglotbot OUTPUT[a␤]
particle ah, right-o.
rakudo: say (7 % 10 + '0').PARROT 00:29
polyglotbot OUTPUT[Float␤]
particle rakudo: say ('0' + (7 % 10)).PARROT
polyglotbot OUTPUT[Float␤]
particle rakudo: say ('0' + (7 % 10)).Str.PARROT
polyglotbot OUTPUT[String␤]
particle rakudo: say ('0' + (7 % 10)).Str
polyglotbot OUTPUT[Num<0xb6c4fb80>␤]
particle rakudo: say Str('0' + (7 % 10)) 00:33
polyglotbot OUTPUT[invoke() not implemented in class 'Perl6Str'␤current instr.: '_block14' pc 102 (EVAL_16:47)␤called from Sub '!UNIT_START' pc 18229 (src/builtins/guts.pir:321)␤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 950 (src/PCT/HLLCompiler.pir:527)␤called from Sub 'parrot;PCT;HLLCompiler;evalfiles'
..pc 1275 (src/PCT/HLLCompiler.pir:688)␤called fr...
Tene particle: I don't know if anybody ever updated polyglotbot to work with rakudo having moved out of the repo
particle rakudo: %?VM{CONFIG}{revision}.say 00:34
polyglotbot OUTPUT[Scope not found for PAST::Var '%?VM' in ␤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:102)␤called from Sub 'parrot;PAST;Compiler;post_children' pc 2075 (src/PAST/Compiler.pir:410)␤called from Sub 'parrot;PAST;Compiler;call' pc 4312
..(src/PAST/Compiler.pir:1094)␤called from Sub 'parrot;PAST;Compiler;post_ch...
particle rakudo: %*VM{CONFIG}{revision}.say
polyglotbot OUTPUT[Could not find non-existent sub CONFIG␤current instr.: '_block14' pc 62 (EVAL_17:42)␤called from Sub '!UNIT_START' pc 18229 (src/builtins/guts.pir:321)␤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 950 (src/PCT/HLLCompiler.pir:527)␤called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc
..1275 (src/PCT/HLLCompiler.pir:688)␤called from Sub ...
particle ok, i've gotta look up the source, sorry for the noise
Tene rakudo: say %*VM<CONFIG><revision>
polyglotbot OUTPUT[Method 'postcircumfix:{ }' not found for invocant of class 'Failure'␤current instr.: 'postcircumfix:{ }' pc 3633 (src/classes/Associative.pir:77)␤called from Sub '_block14' pc 94 (EVAL_17:47)␤called from Sub '!UNIT_START' pc 18229 (src/builtins/guts.pir:321)␤called from Sub
..'parrot;PCT;HLLCompiler;eval' pc 950 (src/PCT/HLLCompiler.pir:527...
particle duh! thanks.
rakudo: %?VM<CONFIG><revision>.say 00:35
polyglotbot OUTPUT[Scope not found for PAST::Var '%?VM' in ␤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:102)␤called from Sub 'parrot;PAST;Compiler;post_children' pc 2075 (src/PAST/Compiler.pir:410)␤called from Sub 'parrot;PAST;Compiler;call' pc 4312
..(src/PAST/Compiler.pir:1094)␤called from Sub 'parrot;PAST;Compiler;post_ch...
particle how do i coerce an Int into a Str?
Tene ~, I'd guess
particle again, duh. 00:36
chromatic sprintf
Tene rakudo: my $a = 1; say (~$a).WHAT 00:37
polyglotbot OUTPUT[Str␤]
Tene rakudo: my Int $a = 1; say (~$a).WHAT
polyglotbot OUTPUT[Str␤]
Tene rakudo: my Int $a = 1; say (~$a).perl
polyglotbot OUTPUT["1"␤]
nopaste "particle" at 76.121.106.245 pasted "Int.perl (in perl)" (26 lines) at nopaste.snit.ch/15669 00:38
jonathan particle: erm, NaN just applies to Num, no? 00:39
particle er, yeah. right.
jonathan++ # saved one line :)
jonathan particle: Does only Str method perl() { 00:40
parse?
purl parse is overused
particle jonathan: i hadn't checked yet, building rakudo 00:41
jonathan If it does it doesn't enofrce the return type yet.
But it may well parse.
00:41 sproingie left
particle 's okay, i typed my return val anyway 00:41
jonathan Aye,
particle hrmm, will while $tmp /= 10 > 0 parse as i hope it to? 00:42
Tene I think so.
jonathan Depends what you're hoping. ;-) 00:43
But it looks right to me.
particle rakudo: my Int $t = 50; repeat { $t.say } while $t /= 10 > 0;
polyglotbot OUTPUT[50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤ 00:44
..0␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤5...
Tene rakudo: my $a = 50; $t /= 5; say $t; 00:45
polyglotbot OUTPUT[Scope not found for PAST::Var '$t' in ␤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:102)␤called from Sub 'parrot;PAST;Compiler;post_children' pc 2075 (src/PAST/Compiler.pir:410)␤called from Sub 'parrot;PAST;Compiler;call' pc 4312
..(src/PAST/Compiler.pir:1094)␤called from Sub 'parrot;PAST;Compiler;post_chil...
particle rakudo: my Int $t = 50; repeat { $t -= $t % 10; $t.say } while $t /= 10 > 0;
Tene rakudo: my $t = 50; $t /= 5; say $t;
particle sorry, polyglotbot! 00:47
polyglotbot OUTPUT[50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤ 00:48
..0␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤50␤5...
OUTPUT[10␤]
Tene rakudo.past: .say while $_ /= 10 > 5 00:49
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 past" (135 lines) at nopaste.snit.ch/15670
Tene No, it doesn't parse how you want. 00:50
particle so it seems :)
Tene $_ /= ( 10 > 5)
particle adds parens
rakudo: my Int $t = 51; repeat { $t -= $t % 10; $t -= $t % 10; $t.say } while ($t /= 10) > 0; 00:51
polyglotbot OUTPUT[50␤0␤]
00:53 _timbunce joined 00:59 japhb joined
Tene purl: msg pmichaud Can I get commit privs on rakudo? 01:11
purl Message for pmichaud stored.
01:29 Fayland_logger joined 01:40 chromatic joined 01:47 timbunce joined 01:53 chromatic joined 02:06 PJF joined
dalek rrot: r36874 | chromatic++ | trunk/t/steps/auto_fink-01.t:
[t] Skipped all Fink configuration tests everywhere but Darwin.
 02:39
02:42 Theory joined
dalek rrot: r36875 | chromatic++ | trunk/t/pmc/sub.t:
[t] Removed TODO from stringification of Undef PMC under warnings mode tests,
 02:51
02:56 estrabd joined 02:57 Tene joined 02:59 bacek joined
dalek tracwiki: v7 | jimmy++ | ParrotLongTermRoadmap 03:03
tracwiki: fixed wrong column
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/begrog
03:08 PJF left 03:39 autarch joined 03:42 janus joined 03:44 autarch left 04:02 Andy joined 04:17 bacek joined 04:22 chrisdolan joined 04:23 rurban_ joined 04:47 leto_ joined 05:01 MariachiElf joined 05:09 Theory joined 05:38 masak joined
Infinoid Perl shaves more yaks per day than all the bovine fetishists on the planet, combined. 06:15
cotto Is it just me or is "Parrot_mmd_multi_dispatch_from_c_args" a bit redundant? 06:24
06:32 mikehh joined 06:33 jonathan joined 06:34 dalek joined, estrabd joined 06:44 cotto joined
dalek tracwiki: v5 | Infinoid++ | ParrotQuotes 06:58
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
shorten dalek's url is at xrl.us/begr6g
dalek n: 2984157 | Jarrod++ | (3 files):
Applied a few handy patches provided by fperrad++
 07:04
shorten dalek's url is at xrl.us/begr6t
TiMBuS woah 07:08
im on dalek's list? :o
cotto looks like fun 07:16
TiMBuS ha 07:19
07:23 leto_ joined 07:24 alinbsp joined 07:40 uniejo joined 07:42 leto_ joined
cotto Why does Parrot hate me? 07:49
07:50 iblechbot joined
dalek kudo: 543e228 | (Moritz Lenz)++ | t/spectest.data:
add an integration test to t/spectest.data
 08:00
shorten dalek's url is at xrl.us/begr8e
dalek kudo: 3bcf8dd | (Moritz Lenz)++ | t/spectest.data:
we pass S29-any/isa.t, add it to t/spectest.data
shorten dalek's url is at xrl.us/begr8g
dalek kudo: b7c3233 | (Moritz Lenz)++ | t/spectest.data:
add test for Junction.eigenstates to spectest.data
shorten dalek's url is at xrl.us/begr8i
dalek kudo: 9288850 | (Moritz Lenz)++ | src/ (4 files):
expose Junction.eigenstates as a public method
shorten dalek's url is at xrl.us/begr8k
08:04 integral joined
dalek tracwiki: v64 | fperrad++ | Languages 09:31
tracwiki: update languages a-h
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
shorten dalek's url is at xrl.us/begser
09:45 PantheraPardus joined
dalek tracwiki: v65 | fperrad++ | Languages 10:02
tracwiki: update languages j-p
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
shorten dalek's url is at xrl.us/begsfm
dalek lscript: b652f57 | (Francois Perrad)++ | Configure.pl:
downcase language
 10:17
shorten dalek's url is at xrl.us/begsgp
dalek tracwiki: v66 | fperrad++ | Languages 10:29
tracwiki: update languages r-z
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
shorten dalek's url is at xrl.us/begsg9
dalek n: 33619ae | Jarrod++ | config/makefiles/root.in:
Applied a small patch to patch a patch :) fperrad++
 10:34
shorten dalek's url is at xrl.us/begshj
10:38 uniejo joined
dalek lscript: 87b3260 | (François Perrad)++ | (10 files):
fix case sensitive path
 10:46
shorten dalek's url is at xrl.us/begshs
dalek lscript: 8956a4a | (François Perrad)++ | Configure.pl:
Merge branch 'master' of git@github.com:fperrad/wmlscript
shorten dalek's url is at xrl.us/begshu
dalek rrot: r36876 | fperrad++ | trunk/languages/dotnet/t/exceptions.t:
[dotnet] skip all test, exceptions cause infinite loop.
 10:57
rrot: r36877 | fperrad++ | trunk/config/gen/makefiles/languages.in:
[external languages] add Perk from github.com/chrisdolan/perk
 11:29
11:39 bacek joined 11:53 iblechbot joined 12:05 pjcj joined 12:21 rurban_ joined
TiMBuS rakudo: our $glob = 1; 12:27
polyglotbot RESULT[1]
TiMBuS rakudo: $*glob += 2; say $*glob;
polyglotbot OUTPUT[2␤]
TiMBuS well, thats one way to have non-strict variable declarations, and in the rakudo 'repl' they're persistent because they're global. this is handy. 12:31
12:32 rg1 joined 13:28 PantheraPardus left
bacek nopaste? 13:34
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
nopaste "bacek" at 87.250.243.86 pasted "Undef patch for jonathan" (30 lines) at nopaste.snit.ch/15671 13:35
13:42 jq joined 13:53 Whiteknight joined
dalek rk: 020d701 | (Chris Dolan)++ | (2 files):
A few Makefile improvements
 13:54
shorten dalek's url is at xrl.us/begsr9
14:08 jimmy joined 14:31 gryphon joined 14:50 rdice joined 14:59 Tene_ joined 15:06 geof joined
nopaste "rurban" at 157.247.252.15 pasted ""'I' is not a valid sprintf format" exceptions" (11 lines) at nopaste.snit.ch/15672 15:08
NotFound rurban: what's the problem with that code? 15:11
Coke_afk when you throw an exception, aren't the line numbers from the PIR already printed? 15:28
dalek kudo: 7d6683a | pmichaud++ | build/PARROT_REVISION:
Need to bump PARROT_REVISION for setting to work.
 15:30
shorten dalek's url is at xrl.us/begsyq
dalek kudo: 6c983dc | pmichaud++ | (15 files):
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/begsys
Coke 'I' is not a valid sprintf format
current instr.: 'main' pc 3 (foo.pir:3)
(see, it's already there.)
msg Infinoid you can help by proposing a sane layout of the site that maps nicely to the output of "make html", allows for multiple versions of the docs to exist at the same time, (including svn-latest), perhaps with aliases to named things like "stable" or "devel" 15:32
purl Message for infinoid stored.
Coke msg Infinoid also, attaching a tarball of the 'make html' from the 0.9.1 release (and pointers on where to shove it) would also be helpful. 15:33
purl Message for infinoid stored.
Infinoid hi, Coke 15:35
I posted a script to TT #305 which does "make html" and rsyncs the result into a webroot. Is that sane enough?
I think we can run it (or something similar to it) from cron, hourly or daily or whatever 15:36
having multiple versions of them is an interesting idea. Maybe that script should be used to produce the "svn-latest" version 15:38
Coke I'm sure that script will be fine, but haven't read it. =-) 15:40
Infinoid So, the toplevel of the site has a few subdirectories, such as 0.9.0, 0.9.1, 1.0.0 and svn-latest, and maybe an index.html to let you choose between them. I would really *really* like to have a "stable" symlink pointing to the most recent release version, so we can link to it
(is that a reasonable proposition?)
Coke yes. and devel should point to, e.g. 0.9.1
we should probably have at least one dir level under the doc root to allow for examples. 15:41
er, 'expansion'.
(sometimes my fingers on autopilot autocomplete wrong. =-)
I can ssh right now. moment.
NotFound Will be better to have an index.pbc to demonstrate mod_parrot usage ;) 15:43
Coke something like "repository/"
15:43 leto_ joined
Infinoid ok. anything like that would work for me... I haven't really thought about how it should be laid out until you asked 15:43
I was sorta just assuming we'd stick "make html" output into a webroot directly, but your approach seems saner 15:44
Coke ok. make me a 0.9.1 doc-tar-ball while waiting. =-)
Infinoid I have to drive to work now... can have it for you in 30min
bbl &
Coke k. perhaps the channel will come up with a good top level dir name by then.
15:46 Andy joined
Coke www.parrot.org/release/current is broken. 15:51
maybe it's just my proxy. hurm.
Infinoid: I'm doing the docbuild now 15:53
here's a temporary version: don't advert yet: 15:58
docs.parrot.org/repository/0.9.1/html/
I'm thinking maybe 'release' would be better than repository. 15:59
moritz 'which'
Coke that seems too placeholdery. 16:00
(added a softlink of devel -> 0.9.1)
here's a sample from another project: 16:01
gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/
should 0.9.1 be parrot-0.9.1 ? 16:02
(it's a little repetitive, but gives us some room.)
ah. what about docs.parrot.org/parrot/0.9.1/html ? 16:03
moritz I like that
Coke changed.
rg i think the parrot is already in the domain. here's another example: www.postgresql.org/docs/8.3/static/index.html
Coke rg: the domain is for the foundation. the dir is for the project. 16:04
moritz rg: it's in the domain, but maybe there will be other projects
Coke (just trying to future proof things.)
moritz rg: like bytecode translators, languages, additional compilers - whatever
NotFound Electoral campaigns X-)
Infinoid I dunno. The http:// tells me it's online, and the hostname "docs.parrot.org" tells me pretty much everything else I need to know 16:06
but that's just me.
rg in my experience you can never foresee all the things you might want to do in the future. ;) but another level of parrot won't hurt
NotFound You can do wathever yo want in the future with domain names, for example: foundation.parrot.org, languages.parrot.org ... 16:08
Infinoid html.docs.parrot.org
html.stable.docs.parrot.org
heh.
it's probably possible to go overboard with stuff like that :)
NotFound Just a touch in dns and apache confs, and ready to play
particle trac.parrot.org/parrot/ 16:09
docs.parrot.org/parrot/
Infinoid www.parrot.org/parrot/
NotFound ETOOMUCHPARROT
Infinoid (speaking of which, parrot.org needs a better 404 page, I'll add that to my list)
parrot.docs.parrot.org/parrot/
particle kicks Infinoid
NotFound It's dead! 16:10
Coke again, this is just "parrot the project is not parrot the foundation".
(even though right now it nearly is.)
particle coke: agreed. docs.parrot.org/parrot/1.0/
16:10 Eevee joined
Coke particle: with a trailing "html" dir because that's how our 'make html' works. 16:11
NotFound You can call it "vm"
Infinoid we can work around the html/ subdirectory in various ways
particle coke: can we get rid of the html dir with a redirect?
*rewrite
Infinoid for svn-stable, I was thinking of just rsyncing html/* instead of html
Coke Infinoid: you need the resources/ directory. 16:12
(ditto to particle)
particle is that where the css lives?
Infinoid err, svn-latest, or whatever it is
I'm confused. resources, as opposed to what?
(I don't mind it, I just don't understand the reasoning) 16:13
16:14 mikehh joined
Coke the resources/ directory. 16:16
without it, the html doesn't render.
(it has images, css.. ) 16:17
and the html/ directory expects it to sit in a sister directory.
Infinoid oh, ok 16:18
particle ok, but it doesn't have to be visible to the world, and it can be linked
Coke (visible to the world) yes it does, it has to be in the docroot.
these are user visible files. 16:19
Infinoid if it's a problem, we can fix the "make html" output
in fact, we could just make resources/ a subdir of html/, which would make the links simpler 16:20
I dunno. if there are any tasks there, I'm happy to work on them 16:21
dalek kudo: 6445d09 | (Moritz Lenz)++ | t/spectest.data:
four more passing spectests
 16:26
kudo: 00e9db4 | (Moritz Lenz)++ | .gitignore:
ignore perl6_s1.pc and src/gen_settings.pm
shorten dalek's url is at xrl.us/begs66
shorten dalek's url is at xrl.us/begs68
rg infinoid: you just need to watch that you don't break it for the local filesystem.
16:29 AndyA joined
Coke Infinoid: we can do that, but we still have a 0.9.1 release out there to worry about. If we can get it working in svn (which implies it'll work for 1.0) in some other fashion, that's fine with me. 16:29
I'm just trying to get the docs on the web with the least fuss. 16:30
any votes on changing the top level 'parrot' to 'vm' or 'pvm' ?
moritz votes for staying with 'parrot'
16:31 Tene joined
Infinoid parrot works 16:31
Whiteknight votes "parrot" 16:32
Infinoid Coke: I volunteer to fix up 0.9.1 by hand. (Or more likely, get a 0.9.1 checkout, apply make-html patches and regenerate)
So is that what we want to do? Any other issues I should work on while I'm in there?
Coke I'm not convinced it's necessary. 16:34
I'd rather see the /contents/ updated than shuffling folders at this point. 16:35
like, fixing intra-page links.
(there's at least some breakage on L<>'s)
moritz purl: cas?
purl cas is probably www.ja-sig.org/products/cas/
moritz purl, cas is also computer algebra system 16:36
purl okay, moritz.
Infinoid Coke: Fair enough. As long as we have something I can link to, I'm happy. 16:39
Coke for "svn latest", what dirname? 'svn' ? 'head' ? 'latest' ? 'current' ? 'bleed' ? 16:40
I think bleed is probably the best choice there.
implying the least about quality or version control.
Infinoid svn or devel also work
particle yeah, we don't talk about bleedparrot, though, it's usually devel 16:41
but i can go with either one
Coke devel is 'latest development release'
particle don't like svn because when we move to p4 that'll screw our links
16:42 gaz joined
particle coke: all our releases are numbered 16:42
Coke s/p4/git/ and it's not so funny anymore. =-)
particle: and yet, like perl, we're still going to have "latest development release" and "latest stable release".
e.g.: www.parrot.org/download which points to www.parrot.org/release/current 16:43
ew.
someone changed that from devel.
Infinoid 0.9.0 was devel too, judging from the directory name on the ftp site it links to 16:44
particle it's worth looking at the parrot support policy for verbage
Coke yes, every release we've had so far is devel.
particle: I see that chromatic has changed names all to hell. 16:46
<shrug> I have given up any sense of control here. Feel free to comment with a sane plan on the ticket.
based on chromatic's wording, what I was calling devel and stable is now called stable and milestone. 16:47
I think he's saying that after 1.0, there are NO development releases.
Infinoid isn't sure what the implications of that are 16:48
particle coke: yeah, every release is 'stable'
'devel' means 'bleed'
and we have 6mo miletstone releases
he did ask for review/comment on the list before committing, and you're welcome to do so still 16:49
Infinoid The distinction has to do with how long we expect to support a release?
particle i'm not married to the wording, just want it to be consistent
Infinoid: yes
Coke particle: this appears to be an outgrowth of the conversion at the PDC, neh? 16:50
"conversation"
16:51 Theory joined
Coke (if 0.9.1. is our last development release, there's no point in having a link for it.) 16:51
(an aliased link)
Infinoid Cool. Lemme know when we have a docs site. Migrating www.parrotcode.org/cage-cleaners/guide.html, www.parrotcode.org/faq/, www.parrotcode.org/glossary.html and www.parrotcode.org/docs/ over to parrot.org is on my list of tasks
particle Infinoid++ 16:52
Infinoid By the way, I'm not really sure what we want to do with www.parrotcode.org/todo.html and www.parrotcode.org/openpatches.html
They seem to be autogenerated from RT somehow.
particle Infinoid: they should redirect to similar generated trac queries, i suspect 16:53
Infinoid Works for me.
particle coke is a champ at creating those
Coke declines
particle coke, yes it grew out of the pds2008 conversation
Coke particle: ok. then I'm so far out of the loop, it's not worth arguing at this point.
particle coke: i think you already have created them, maybe i'm wrong 16:54
coke: we discussed things there, but chromatic wrote this mainly from his own viewpoint
its still an open item, as far as i'm concerned. i'd like to know your perspective 16:55
pmichaud where's the document c wrote?
Coke docs/project/sup*
pmichaud I had a couple of thoughts about the topic this morning. 16:56
Coke particle: the document seemed sane enough when I read it through. Just part of a general feeling of exclusion since PDS. If I have any comments worth sharing, I'll post them to the list. 16:57
pmichaud question: do we have an official PARROT_API list yet? Will we prior to 1.0? 16:58
Tene: what's your github id?
Coke pmichaud: you would think that with the stated goal of 1.0, we would. 16:59
pmichaud Coke: yes. The string functions rename that took place really shook my notion of what "deprecated" means in Parrot.
particle pmichaud: no, the PARROT_API is 2.0 i think, for embedders/extenders 17:00
purl okay, particle.
particle pmichaud: agreed
Coke pmichaud: yah, me too.
a LOT of stuff has gone under the radar there.
pmichaud particle: I'm not sure I agree with that. If we expect it to be normal that languages create custom PMCs, then the C API is very relevant for language implementors.
Coke even tickets that have deprecation notices have been done ahead of time.
particle pmichaud: yes, i understand and agree. but we're not able to define PARROT_API in a month. 17:01
pmichaud then the support policy needs to make it clear that PARROT_API doesn't yet fall into the normal deprecation cycle
particle coke: i can take some blame for that, if only not for being around enough to enforce the deprecation process
pmichaud i.e., "setting expectations" means we shouldn't surprise people with changes.
Coke particle: I'm not sure you can take allison in a fair fight. 17:02
she's the one, near as I can tell, who is putting the changes in.
(or approving when other people ask.)
particle well, one big unwritten goal of 1.0 is to have all nlnet milestones finished 17:03
one of those involved the strings refactor
it went in a little late, and broke the process a bit
Coke then we should have pushed 1.0 back.
particle that's one option. 17:04
Coke and that goal should have been written. =-)
particle: the other is apparently to break our deprecation policy. =-)
particle ayep.
17:04 mikehh joined
pmichaud or, as it stands now, to advertise a deprecation policy that isn't planned to be followed. 17:04
particle was this brought up at #ps this week? 17:05
pmichaud I didn't think of the API issue until this morning.
particle we have meetings for these reasons
pmichaud I'm still re-adjusting my worldview to accommodate these little surprises.
particle no new surprises planned. anticipate chaos. 17:06
pmichaud we also have deprecation policies for these reasons. :-)
particle actually, things really need to settle down this month.
need to be very well behaved.
...and from now on.
pmichaud anyway, I'll write a message to the list, but I think we need to explicitly note in the support document that PARROT_API doesn't yet fall under the deprecation policy. 17:07
17:07 apfel joined
particle i'm not sure that's the case 17:08
since PARROT_API doesn't exist
pmichaud particle: if we haven't defined PARROT_API, and if it's not possible to create per-language PMCs without making use of parrot internal functions, and if we expect languages to be able to create custom PMCs, then by definition we're going to break something .
either that or we tell language designers "create your own language opcodes and PMCs at your own risk" 17:09
or, more likely, "dynops/dynpmcs aren't supported in 1.0"
PerlJam or ... push 1.0 back a little 17:10
pmichaud PerlJam: for a variety of reasons I don't think "push back 1.0" is feasible.
particle agreed.
PerlJam (I have no clue as to the scope of the problem though)
pm: are they all political/social reasons?
17:10 apfel left
pmichaud fwiw, I don't see a huge problem with us saying that the PARROT_API isn't set yet and that things may break, but let's be honest about it and not try to sweep it under the rug. 17:10
particle pmichaud: we need to be direct, and clear on PARROT_API 17:11
i also want to be correct. :)
pmichaud Okay, I think that's entirely compatible with what I'm saying. :-)
particle there's no PARROT_API at all as it is.
i *don't* want to put PARROT_API everywhere PARROT_EXPORT is. 17:12
pmichaud I'm not saying we should do that.
I'm not saying we should attempt to define PARROT_API prior to 1.0.
particle great.
pmichaud I'm saying we should explicitly recognize that dynops and dynpmcs rely on Parrot internals, and that we can't guarantee those internals through 1.5
i.e., they fall outside of our current deprecation policy. 17:13
particle ok, well, deprecation implies removal to me
pmichaud I don't understand "deprecation implies removal", or how it impacts what I'm saying.
Coke no, removal and deprecation are two separate things.
particle we won't be removing PARROT_API between 1.0 and 1.5 if it doesn't exist
pmichaud I'm fully expecting that some Parrot functions that PMCs currently rely on may change or be removed between 1.0 and 1.5 17:14
Coke has anyone written anything about how we're going to have use svn differently in a post 1.0 world yet?
pmichaud Coke: do we have to use it differently?
Coke I am in the middle of a post to the list, just want to make sure I'm not duplicating effort.
particle coke: no, that's definitely needed.
Coke pmichaud: yes.
pmichaud what's different? 17:15
Coke mainly to keep our new features and deprcation stuff sane in a post-1.0 world.
I'll write it up.
pmichaud okay, but I don't see the problem there.
PerlJam It sounds like this affects the claim that Parrot 1.0 will be a stable platform for language designers though.
pmichaud PerlJam: that's my point.
PerlJam (since, to me, that's the main import of parrot 1.0) 17:16
particle yes, it does. however, from the pir level, things should be stable
PerlJam pm: I get that. I'm just having trouble reconciling it all :)
pmichaud particle: that's my point -- not everything can be done from the pir level.
particle pct, pir, nqp, ops, pmcs, stable.
pmichaud particle: nor do we _expect_ everything to be done from the pir level.
particle pmichaud: yes, i see your point. i agree, too. 17:17
pmichaud that's what surprised me about the strings refactor -- I had been led to believe that our deprecation policy included various standard c functions, but discovered (quite rudely) that it did not.
PerlJam pm: It sounds like you're saying we should be up front that parrot 1.0 won't be what we said it will be and then I'm left wondering what's the point of parrot 1.0
pmichaud PerlJam: I don't think the fact that dynpmcs and dynops will change is a significant impact to Parrot's stability. 17:18
particle PerlJam: just let us accomplish something, will you! :P
pmichaud PerlJam: on the whole, Parrot will be fairly stable for people wanting to implement their languages.
PerlJam particle: hey, you can accomplish anything you want ... I'm just trying to understand it.
pmichaud There are just one or two relatively minor areas (dynops/dynpmcs) where it might not be. I think we should be up front about that.
Coke Update the release goal to be true. it'll be stable "in these respects".
or, conversely, 'except in these' 17:19
particle it's crash-proof, like windows nt 3.0
pmichaud windows nt 3.0 _never_ crashed on me. Of course, I never ran it, but...
PerlJam maybe the "standard" I have in my head is too high for parrot 1.0 and I'm really thinking of is what will be parrot 1.5
particle PerlJam: parrot 2.0 is targeted for production-ready 17:20
pmichaud speaking as a language implementor, I don't have any problem with the stated level of stability for Parrot 1.0
s/stated level/expected level/
especially since 1.5 is only four months afterwards
but I do have a problem with us saying or implying "it's safe to rely on these features" when we know there's a significant chance they won't be available in 1.5 17:21
s/be available/be the same/
particle be the same... agreed. 17:22
PerlJam pm: given what particle said earlier about PARROT_API's non-existence, is it like likely that someone will include that in the feature list? :)
pmichaud and it bugs me a bit that our standard has somehow been *implicitly* reduced to "deprecation only affects pct, pir, nqp, ops, core pmcs"
and excluding the C functions (that we know have to be used for certain languages features) 17:23
as of four weeks ago, I thought the C API was part of the deprecation cycle.
particle it *is*
pmichaud I thought the C API that I was using was part of the deprecation cycle. 17:24
particle but we don't have an official api.
pmichaud thus my modified statement. :-)
particle :)
pmichaud so, as a language implementor, I'm not left asking "what can I safely use", and the answer comes back "nothing".
s/not/now/ 17:25
Coke I have been confused about the 1.0 release since it was announced. =-)
pmichaud Coke: okay, it just took me three months to rise to your level of confusion. Once again you've blazed the trail for us. :-)
Coke you probably had a modifier to your saving throw since you were at PDS. =-) 17:26
pmichaud perhaps, but it ended up giving me a +3 delayed disillusionment for much of January when The Plan (as I understood it) wasn't being followed. 17:27
Coke I don't understand how we can be tying features to releases at this point with volunteer staff. 17:30
particle it's an attempt to tie features to releases.
moritz we can, as long as we don't also tie it to dates
particle i've missed the mark on many of mine
Coke moritz: that's the followup, right.
we can say "all this will be in 2.0" but then we cannot say "2.0 will ship at this point." 17:31
particle our contributors have been exceptionally generous with their time
and we can always reschedule 17:32
PerlJam Coke: we can guess based on some monte-carlo simulations projecting how long the unfinished tasks will take given that we know how long the other stuff took ;)
particle but we reschedule features, not releases
coke: parrot release naming is like ubuntu
it's time-based, not feature-based 17:33
moritz then we shouldn't have critical milestones
particle moritz: we had 5 critical milestones, without which we couldn't do parrot 1.0
moritz I know
particle for example, make install
5 critical items in 5 months (since nov2008) isn't unreasonable 17:34
dalek rrot: r36878 | fperrad++ | trunk:
[squaak] re-run tools\\dev\\mk_language_shell.pl (r36833)
 17:35
Infinoid fperrad++ # updating the "Builds against" and "Passing tests" columns of the Languages wikipage 17:37
Coke particle: then we need to be very clear that the list of features targetted for each release is fluid. 17:38
there is no sense of that anywhere in the roadmap docs.
(at least in revisions I have read.)
particle post-facto it is, with (rescheduled) everywhere
rurban jit.pod says long double is supported. with 12-byte (i386) it doesn't compile. 16-byte (amd64) does not work at all 17:39
particle and the roadmap should be replaced by a trac query/report soon enough
Coke particle: I have no way of telling if that's becuase of policy or because we suck at time estimation.
particle: at which point it becomes even more important to have that documented somewhere, because it's not going to be on the automated report.
rurban with my current patch tt352-jit-i386-ld.patch it does compile with long double, but building pge crahes
particle coke: if that hasn't been written up, i agree, it needs to be clear
Coke if that's true, then we don't have to change our svn habits quite so much. 17:40
particle: so is 1.5 tied to features or a date?
Coke takes that question to the list. 17:41
particle coke: date
.0 are january release (except 1.0)
.5 are july releases 17:42
did i get those months right?...
PerlJam er, what?
17:42 riffraff joined
PerlJam for ubuntu .1 == Jan, .2 == Feb, etc. 17:42
so, july would be .7 17:43
particle PerlJam: we're not following ubuntu's numbering, just the general date-based release numbering idea 17:44
we're not releasing parrot 9.3 in march
PerlJam so ... could you explain the date-based numbering scheme then (or point me at a doc that does)? 17:45
moritz on parrot.org news, "vision for 1.0" 17:46
PerlJam so far I've only seen, heard comparisons to ubuntu, so I thought that was ultimately going to be the same scheme used
particle www.parrot.org/news/vision-for-1_0
thanks moritz, i was scanning the mailing list for that
PerlJam okie. I figured that's how it would be, thanks. 17:47
Coke particle: note that allison and chromatic disagree on what is stable and what is development.
particle yes, the wording has changed.
i'm not sure how intentional or coordinated that was
Coke how the frak am I supposed to know which is the canonical source?
particle ASK. 17:48
Coke how am I supposed to know there is a disagreement!?
particle it's a really good question.
PerlJam Ask is the canonical source? ;)
particle ask the mailing list. i can guarantee you won't be warnocked. 17:49
Coke I have already begun that thead.
"thread."
particle :)
NotFound Parrot_new_sub_from_c_func will be a good name? 17:50
17:54 iblechbot joined
rurban AIX asserts with src/string/api.c:767: failed assertion 'encoding' in dynpmc's We had that before, didn#t we? 17:56
on windows
smolder.plusthree.com/app/public_pr...st_failure
shorten rurban's url is at xrl.us/begth7
Infinoid rurban: is it another linking issue? 17:57
Coke if we had that issue since trac, should be easily searchable.
rg notfound: i would probably expect Parrot_sub_new_from_c_func
Infinoid AIX uses export files to explicitly export symbols to shared libraries
pmichaud NotFound: it's generally 'Parrot_' + name of subsystem + function 17:58
thus Parrot_str_new instead of Parrot_new_str
NotFound rurban: we don't solve adequately the problem, then it hits us again and again
rurban No, it's probably the race which you fixed but reverted
NotFound: you or Infinoid: I forgot which version got commited 17:59
NotFound Infinoid. Don't know it has been reverted
Infinoid It doesn't look reverted.
NotFound Anyway the problem was not solved, just some of the symptons. 18:00
Infinoid That was just one race, there may be others
But if it only happens in dynpmcs, I think it must be linker symbol exporting, not an init race 18:01
NotFound And no one win that races ;)
rurban Do we have access to an AIX?
Coke someone does, obviously.
previous attempts to match up smokers with smokes have been ... fruitless.
particle does ibm have something like hp's testdrive?
Infinoid NotFound: Did we ever end up committing one or the other patch to fix up those encoding/charset globals?
NotFound Instead of saerching and fixing symptons will be better to kill those pesky exported globals. 18:02
18:02 ron joined
particle coke: relying on smolder, with only one or two committers, is difficult, for sure 18:02
Infinoid Oh, that's right, someone said that a better string subsystem was on the way, so I got distracted by something shiny and wandered off.
rurban I think I've lost this patch... 18:03
NotFound Infinoid: the idea was to discard that way and use functions that returns things stored outside the interpreter.
Coke particle: given we now have (to me) a slightly more transparent smoking system, should we see about creating smoke.parrot.org? 18:06
s/smoking system/admin system/
(I feel bad saying that, because robrt and ask were always very helpful, but having ssh on the box makes it feel like I can do more damage this way. =-)
ron If I run parrot's t/harness with --help it mentions a -v option '-v ... run verbose'. In practice if I try the -v option it makes all the tests fail and leaves a flood of output. Was it supposed to do the same thing as setting HARNESS_VERBOSE=1 in the environment or does anyone know if it was supposed to do anything different? 18:07
NotFound Tell the truth, you want to be a smoker where no one can see you X-)
Coke I can't find where -v is used in t/haress 18:09
"harness"
ron Coke - did you look at the output of --help ?
Coke no, I was looking at the code in t/harness 18:10
(which has been refactored to the point of obscurity. digging.)
it's probably passing the -v along to ./parrot, which is entirely unhelpful. 18:12
(at least to me.)
perhaps if you wanted to see more verbose output on a particular test.
so, no. looks like it's not meant to correspond to HARNESS_VERBOSE. 18:13
(which is already explicitly checked elsewehere in t/harness 18:14
rurban NotFound: I remember what cuased these AIX failures (on windows then). It was a static/shared library clash 18:15
Maybe this AIX/ppc box compiles both shared and static and runs static, but the dynpmc's run the shared versions then. voila: clash
nopaste "Coke" at 65.91.151.195 pasted "yes?" (23 lines) at nopaste.snit.ch/15677 18:16
rurban did you try it? 18:17
ron Coke: fwiw I think your suggestion drops the exception $@ 18:18
in the err msg
rurban killed the bugger... 18:21
dalek rrot: r36879 | rurban++ | trunk/tools/dev/pbc_header.pl:
[tools] TT #357

so that no more pbc's get corrupted.		 18:24
Coke ron: does it matter? how many different ways can eval'ing a require fail? 18:25
is it worth duplicating the code path there?
dalek rrot: r36880 | rurban++ | trunk/docs/project/release_manager_guide.pod:
[docs] TT #357. Do not mention the broken tools/dev/pbc_header.pl --upd
 18:28
ron back to 't/harness -v' - if I or someone were to rig the -v option so it only failed tests when it was supposed to and gave the additional parrot -v output would that be reasonable behavior for the flag ?? 18:29
the parrot -v output for failed tests that is ... 18:30
moritz isn't that the default behaviour already?
ron on my cygwin, win32 and linux systems it results in all tests failing - maybe just a bug ? 18:31
rurban ron: which tests?
ron I was mostly working with t/pmc/threads.t
rurban you mean: prove t/pmc/threads.t fails for you? 18:32
Coke moritz: I would guess that it ALWAYS runs -v. 18:34
which would cause any test that looked at stderr to probably fail.
if you just want a verbose output, use /prove -v/ 18:35
if you want the exact same options t/harness uses, use HARNESS_VERBOSE=1 t/harness t/pmc/threads.t
prove -v != t/harness -v
ron sorry -no I am running perl t/harness (not prove). I wasn't really familiar with prove. But prove -v does not run parrot with -v (and with --help clearly and accurately explains what it does).
Coke prove is not a parrot tool. t/harness is. 18:36
that may explain the differences in documentation quality.
moment:
ron: updated the docs so that perl t/harness -help basically says "don't do that." 18:39
if you want verbose output, use HARNESS_VERBOSE=1 t/harness t/pmc/threads.t 18:40
(add a perl in there.) 18:41
(prove -v doesn't run parrot -v) exactly. it implies the same has HARNESS_VERBOSE=1
dalek rrot: r36881 | coke++ | trunk/lib/Parrot/Harness/Options.pm:
Update the documentation on t/harness to warn about the -v option.
rurban chmod +x t/harness
Coke rurban: no. 18:42
ron Thx. sorry for not using prove - the comment looks good though ...
Coke If you do that, which perl does it run with?
(if we had some way to force all the tools to run with the perl you config'd with, that'd be ok. but then it's a generated file anyway.)
18:43 kj joined
rurban To rephrase the AIX problem: Shouldn't we skip dynpmc and dynoplibs if parrot is linked static? 18:44
With win32 I've renamed the static lib to libparrots.lib not to get any conflicts with my tt312-win32-linking.patch 18:46
Coke: sure, just for less typing while developing
18:47 barney joined
Coke rurban: (skip dynamic stuff if linked static) That's an excellent question. One for the list, in a general "so, if we link static, what can document as nonfunctional" kind of way. 18:49
NotFound Someone is actually using static linking for something? 18:50
rurban Sure, broken hints
openbsd until recently, aix apparently
Coke (static) osx was using it for some time since installing dynamic is borked. 18:51
of course now static /and/ dynamic are borked. =-)
rurban I already had a ticket for this but it was warnocked and 0.9.1 got out without
NotFound General consensus is then Parrot_sub_new_from_c_func ? 18:52
rurban the export DYLD_LIBRARY_PATH=blib/lib thing? 18:56
Whiteknight NotFound: do we want Parrot_sub_new_from_c_func, or should it be "_call_" or "_nci_" instead? 19:05
dalek tracwiki: v8 | whiteknight++ | ParrotLongTermRoadmap
Whiteknight is "_sub_" the right subsystem name?
dalek tracwiki: peppering my name into a few 2.0 milestones that I'm interested in working on 19:06
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
rrot: r36882 | NotFound++ | trunk:
[core] add Parrot_sub_new_from_c_func to extend.h
shorten dalek's url is at xrl.us/begtto
NotFound Whiteknight: good question, but a bit too late ;)
Whiteknight haha, never mind then
where is that function defind?
defined?
purl defined() is a function that returns a Boolean value telling whether EXPR has a value other than the undefined value `undef'. If EXPR is not present, `$_' will be checked.
NotFound extend.c 19:07
Ah, you mean the c function?
Whiteknight yeah
NotFound Anywhere. I'm testing for embedding, just take his address 19:08
nopaste "NotFound" at 213.96.228.50 pasted "Testing Parrot_sub_new_from_c_func in embedding" (117 lines) at nopaste.snit.ch/15678 19:10
rurban I've fixed now the broken tools/dev/pbc_header.pl which broke our naive_pbc's and pbc_dump dumped core on the new, untested UUID data feature. 19:11
UUID data is the 10-byte fingerprint (md5) from before. 19:12
NotFound Now we can make some interesting things with embedding :)
cotto How can I figure out what function is in an NCI PMC's func ATTR? 19:13
s/in/pointed to by/
NotFound cotto: do you mean his name? 19:14
cotto that'd be sufficient
NotFound No name stored, you can use C level debug information, if present. 19:15
A way to optionally give them a name will be good 19:16
cotto The problem there is that func points to a chunk of memory.
NotFound cotto: at machine execution level, there is no other thing 19:17
Infinoid could you register it at creation time?
NotFound The NCI PMC has no attribute for it 19:18
cotto Too bad. I was hoping there'd be a sneaky trick to find the name. 19:20
Infinoid I suppose you could add one if you really wanted to.
NotFound Setting it explicitly is that perl5 does
Infinoid You might not be able to rely on it being there in all cases... it could be an anonymous function (gcc lexical function, or something produced automatically by JIT perhaps) 19:21
NotFound We can add a name attribute to nci, but to be usefull we must also add variants of the dlfunc opcode
And to be even more useful, a way to set the source file name, as perl5 does. 19:23
cotto It doesn't sound like an extra ATTR would be worthwhile just to make debugging easier. 19:24
(that would be nice, though)
NotFound But in real dlfunc usage you don't know the source file, of course.
Hum, I was fooling myself, in the dlfunc opcode you already have the symbol name. 19:26
19:26 leto_ joined
rurban I forgot to update PBC_COMPAT when I added bignum.pmc again 19:26
that's why we also got pbc reading trouble 19:27
NotFound cotto: you can open a RFC ticket about that
rurban Starting with what version are we not allowed to delete ops/pmc methods anymore? I'm asking for PBC compat, to be able to read older pbc's. 19:29
dalek rrot: r36883 | NotFound++ | trunk/t/src/embed.t:
[t] using Parrot_sub_new_from_c_func in embed
 20:07
rrot: r36884 | whiteknight++ | trunk/docs/book/ch04_pir_subroutines.pod:
[Book] Fix an error. Thanks hexcoder++
 20:11
rrot: r36885 | whiteknight++ | trunk/docs/book/ch04_pir_subroutines.pod:
[Book] Add some basic stub info about Role PMCs to chapter 4
 20:19
20:21 rurban_ joined
dalek rrot: r36886 | whiteknight++ | trunk/docs/book/ch04_pir_subroutines.pod:
[Book] two small clarifications to chapter 4
 20:28
rrot: r36887 | chromatic++ | trunk/t/pmc/ref.t:
[t] Unskipped some tests for Ref PMC and its semantics.
 20:32
Whiteknight every time we unskip a test, a FLOP-faery loses it's wings 20:39
or, as an alternative comment: I feel a great disturbance in the force. As if hundreds of developers all cried out because they lost another minute to realclean 20:40
urg, s/realclean/make test/
cotto easy fix: never run svn up
NotFound Whiteknight: I can send you a few videos of Winx Club if you ran out of fairy wings 20:42
Whiteknight no, thanks. I have a whole bag of them 20:43
Whiteknight steals a bunch every halloween 20:51
rurban I'm implementing now the uuid_data. as before? md5 of the file PBC_COMPAT? I just use 8 byte, not 10 as before. 20:52
NotFound We have parrot wings, anyway 20:53
cotto What should two String PMCs with is_equal dispatch to? I'd think Parrot_String_is_equal, but that doesn't appear to be the case. 20:57
(using mmd, i.e. Parrot_mmd_multi_dispatch_from_c_args(INTERP, "is_equal", "PP->I", item1, item2, &result); where item1 and item2 are String PMCs) 20:59
Coke finally thought he understood the plan.
cotto When you think you understand it, it changes.
Coke "the plan never changed. only your mind makes it seem so."
Infinoid chromatic++ # the 2.6 kernel series is just an extension of 2.5 and they intend to continue forever without ever bumping again; they bumped it to 2.6 as a cheap hack to increase their pool of testers 21:00
Coke ... why not switch to a 5 month deprecation scheme to avoid numbering pains. 21:02
cotto The obvious fix is to count in duodecimal. 21:04
21:07 jan joined
pmichaud ...are we going to have numbering pains? 21:09
Coke I like andrews suggestion: let's number like care models. 21:11
*car.
pmichaud I suggested date-based revision numbers at PDS but got very little support for it.
no, I should rephrase that. Allison was very commited to a 1.x 2.x etc. numbering scheme. 21:12
Coke I think sticking to the old style numbers is at odds with the core "numbers don't matter" argument that seems to be the result of PDS.
pmichaud ...numbers don't matter? I hadn't seen that (but perhaps I need to update my email reading)
NotFound Can we use NaN as release number? 21:15
pmichaud Yes, that's the March 1.0 release.
:-)
rurban -Inf maybe 21:16
I'll reserve 2 pad bytes at the end of the uuid_data so the dir starts at an even address (0x20), without uuid it was 14 pad bytes. 21:17
Whiteknight I would love to have version numbers like 2009A or 2010C 21:18
concise, shows when it was released and avoids all the bullshit about numbers and periods
pmichaud for Rakudo development releases, I've been playing with the idea of just using letters: A B C D E F G... 21:19
for cleverness, perhaps pick names that start with those letters. 21:20
NotFound remebers Clipper Summer 87
Whiteknight (being like ubuntu)++
pmichaud If we do monthly releases, I'm not planning to have more than 26 of them between now and rakudo "1.0" 21:21
(if we do biweekly releases, we might reach the end of the alphabet. So perhaps 2009A, 2009B, etc.
Whiteknight that would give you at least two christmases to get your stuff in order
pmichaud fwiw, all of the points that chromatic is making in the email thread are things I also argued for at pds. 21:22
Coke my only fear at this point is that allison will confuse me again. =-) 21:27
pmichaud deprecation points are 1.0, 1.5, etc. 21:28
major feature releases bump the second digit
other releases bump the third digit
end of story.
Coke pmichaud: no, it' snot.
chromatic just argued against that very system.
pmichaud I'm writing my email where I say "I completely agree with chromatic, and made the same points at PDS" 21:29
dalek rrot: r36888 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[install] merge from pdd30_install branch + many improvements
pmichaud however, my email also says "I don't expect the numbering system to change in 2009", and I don't.
Coke ok, but if you include those 3 things, you don't agree with him.
ok.
pmichaud I agree with him, but I expect it to not change.
Coke *sigh*
pmichaud Because the one person who decides this isn't in the conversation.
Coke I thought the whole point of the setup we have now is that there is no one person who decides anything. 21:30
pmichaud I think we've proven that isn't the case.
Coke we defer to her on a lot of stuff, but primarily technical.
21:31 petdance joined
cotto (benevolent dictatorship)++ 21:31
Whiteknight I deal with dictatorships in these cases only so far as they help us avoid design by committee 21:32
pmichaud I can tell you that the existing system was not really design by committee.
yes, we all participated in the discussion, but I was not in favor of what was chosen.
Coke no, we all didn't. =-)
(but I know what you mean.) 21:33
pmichaud (all of us who made it to PDS, that is.)
dalek rrot: r36889 | fperrad++ | trunk/tools/dev/mk_inno_language.pl:
[inno-setup] handles more files & directories
pmichaud I believe the argument for the 1.x.y scheme comes down to the marketing advantages of being able to claim "1.x", "2.x", etc. releases.
pmichaud particularly for a 1.0 release 21:34
however, I may be misrepresenting the position there.
Whiteknight later
pmichaud anyway, let's just say that I'm just trying to describe the current plan as opposed to being an advocate for it. 21:35
dalek rrot: r36890 | rurban++ | trunk:
TT #357: fix pbc_header.pl --upd

  - The pbc writer was rewritten. It adds now the UUID,
   called fingerprint before. The size was choosen as 12,
   to keep a pad of 2, and it still fits into the old header.
  - Make it binary-safe on crlf platforms.		 21:37
Infinoid I have no problem whatsoever with calling a release version "20090317"
rurban I have
pmichaud the day of month is a bit superfluous -- 200903 would be sufficient.
Infinoid True.
rurban 1.0 is 1.0. with all other numbers we are ridicolous
Infinoid But it lets us release hotfixes as 20090318, instead of that 0.9.0.1 nonsense
pmichaud I've also considered 902, 903, 904 ... 912, 1001, 1002, 1003, ... 1012, for Rakudo. 21:39
no dots.
rurban I'll implement now the UUID checker into the pbc library reader to be able to detect inter-release PBC_COMPAT changes. This this need a new ticket or do the old ones fit? TT #357 was the last complaint for those failing checks 21:42
s/This this/Does this/
Coke pmichaud: (describe the current plan) if that had been done more clearly, I wouldn't have started this thread. =-)
between chromatic's doc, allison's doc, and the email thread, we didn't really have a clear picture. 21:43
pmichaud fair enough that the docs may not have painted a clear picture. The email thread ending with lists.parrot.org/pipermail/parrot-d...01449.html is what I had been going on. 21:44
shorten pmichaud's url is at xrl.us/beguff
Coke I like chromatic's idea. 21:45
dalek rrot: r36891 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[tools] downcase PMC & Ops filenames
Coke from "The Core Problem with Parrot Version Numbers"
pmichaud I do also. I'm seriously considering something like it for Rakudo. 21:46
rurban Our only strength are timely and often releases, which can be easily numbered 1-x. Why the date now? 21:47
Professional companies also have the same strategy. 21:48
Infinoid The date makes more sense to me based on our release mindset
pmichaud I know of very few companies where their release numbering system makes any significant sense.
Infinoid 1.0 has too much marketing strings attached for my tastes
rurban 18-month cycle, only major number updates
pmichaud Infinoid: I think that's one of the reasons for "1.0" as allison was advocating it. 21:49
PerlJam marketing++ when it works in our favor.
Infinoid but in point of fact, we're releasing 1.0 in a month despite the fact that we still have a *lot* of work to do :)
pmichaud Infinoid: depends on what you view "1.0" as meaning.
rurban I'm not chatting around here :)
Infinoid (this is why I'm an engineer and not a sales guy, I guess.)
Coke Hurm. chromatic's scheme is nifty, but breaks the "ok, which version is newer" meme. 21:51
pmichaud the names are alphabetical.
Coke Yes. I noticed that. 21:52
pmichaud So Dusky 1 is newer than Budgie 4
Coke Is there a Q named parrot? Are we doing to be doing this for more than 13 years?
Infinoid I was thinking of those codenames more as aliases than actual version numbers
Coke Infinoid: that's not the impression I get from his posting.
pmichaud Infinoid: in the ubuntu world, we tend to speak in terms of the names more than the numbers
Coke It's one thing I /hate/ about OS X. 21:53
Infinoid true. debian too
Coke "you need at least leopard to run this".
Infinoid I can never remember whether sarge is 4.0r3 or 4.0r4 or what
pmichaud thus "Dapper", "Edgy", "Feisty", ....
rurban Someone once wrote a fingerprint_c.pl I suppose to read PBC_COMPAT at build-time or runtime? Really. Why not stamp the build at configure-time and store it it in config.h?
Infinoid pmichaud: ah, I never realized they were alphabetical until now.
pmichaud right. The current release is "Intrepid". The next release is "Jaunty" 21:54
Coke: I suspect that after 13 years we loop around to "A" again.
Infinoid A is the new Z!
pmichaud it's like naming hurricanes, only over a longer time cycle. :-)
Coke pmichaud: ... that's not an unreasonable answer. anyone running budgie when zombie comes out will not be confused. 21:56
pmichaud right, that's what I'm thinking.
but more I was thinking we'd have a different set of A..Z names 21:57
not that we'd re-use the ones from the first 13 years.
Coke no, I get that.
tewk Lets just extend the alphabet when the time comes.
Coke I'm saying that we only care about that reset near the boundary, and it'll be obvious at the boundary.
pmichaud tewk: we could always use Unicode. :-P
Coke good thing I deleted my objection email.
pmichaud: *THWAP*
Infinoid pmichaud: You beat me to it!
Coke Infinoid: *THWAP* 21:58
pmichaud I claim the dingbats!
tewk LOL
NotFound We can show our commitment with unicode by labeling each realease with a character in a different codepoint plane
Infinoid Requirements to install parrot: * every unicode font ever made 21:59
NotFound Forget that limiting ascii alphabet!
purl NotFound, I didn't have anything matching that limiting ascii alphabet
Infinoid purl++
pmichaud also, fwiw, a group of us could adopt whatever name/numbering scheme we want, even if it's not the "official" one. :-P
i.e., grass-roots insurrection approach :-P 22:00
Infinoid Ah, insurgency
pmichaud I've been doing that somewhat informally by always saying e.g. "February 2009 release" instead of "0.9.1".
rurban wouldn't it be nice to show our unicode support by understanding unicode pathnames to parrot? TT #326 (chinese path) 22:01
Infinoid Patches welcome. 22:02
purl it has been said that patches welcome is ponies welcome or Set Objectives, Achieve Results! or swahili for "Put up or shut up."
rurban which design?
purl i think which design is that?
rurban detect encodings automatically? new cmdline switch for the encoding? 22:03
Infinoid I'm not sure what the choices are
Is it possible to have a sensible default based on the OS?
NotFound Infinoid: no
rurban parrot -Epath:utf8 utf8/pathname.pbc
something like that 22:04
NotFound I can have a directory with a latin-1 name, inside it a file with a utf8 name
rurban for files maybe an op or op arg is enough
NotFound In fact, at work I have a lot like that
rurban really? thta should be a user problem then
utf8 encoding understands latin-1 anyway 22:05
NotFound Is a "too much bosses" problem, I think
rurban: what? latin-1 characters aren't even valid utf8 streams 22:06
Infinoid the characters are fine, the encoding changed
Coke pmichaud: if you like chromatic's scheme, Please vote it up, even if you think it'll get overruled. =-)
rurban Should I write about my UUID design to the list or to a ticket?
Coke I think it's the sanest thing I've seen all day, I'm in. 22:07
rurban latin-1 is not 1:1 the same in utf8?, right, > 128 there are differences. sorry
Infinoid rurban: ticket is easier to point at
NotFound The characters are unicode.... but we don't work that way. And even if we change, we can't have two encodings schemens in the same string
Infinoid NotFound: can you can show me a filesystem that can handle two encoding schemes in the same string?
NotFound Infinoid: ext2 22:08
Infinoid Presumably, if you give it the exact same bytes you got back from readdir(), it'll work, right?
NotFound Infinoid: yeah, the filesystem has no problem with it, but we'll have if we try to apply some encoding 22:09
Other than "plain binary"
Infinoid "plain binary" is exactly what I'm thinking
It's portable, too. I think :)
Coke chromatic++
dalek rrot: r36892 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
[tools] fix install paths
 22:10
pmichaud Coke: I added my +1.
Coke_afk pmichaud++ 22:11
-> 22:12
NotFound I think that command line arguments and environment strings must be taken as binary fixed8
Infinoid If the environment tells me what encoding to use (e.g. LANG or LC_CTYPE or whatever), that's great. Otherwise, we don't know what to expect, so use thick rubber gloves. 22:13
22:13 ron left
NotFound Infinoid: that will work nicely in a lot of cases, but can trhow transcode exceptions in worse cases 22:15
Infinoid That doesn't seem like parrot's fault 22:16
rurban TT #359 is my design goal for pbc UUID's, but of course freeze/thaw is in my way.
Infinoid if the user's environment is really badly broken, there's only so much we can do, I think
NotFound Infinoid: be unable to read a directory tree will be taken as a parrot fault by many people... including me 22:17
rurban LC_CTYPE is the solution, yes
on windows we have similar detection methods
dalek tracwiki: v20 | cotto++ | PMCUnionDeprecationTasklist 22:18
tracwiki: add moderately coherent gotcha about MULTIs
tracwiki: trac.parrot.org/parrot/wiki/PMCUni...ction=diff
rrot: r36893 | cotto++ | trunk/src/hll.c:
[PMC] avoid creating uninitialized String PMCs during interp init
shorten dalek's url is at xrl.us/begunv
rurban hmm, is the filoename encosing not stored in the mounttable?
is there an API to read the mount encoding?
Infinoid can we get away without any explicit encoding stuff at all? The base directory is a static path, we never need to modify it, and if we concatenate to it, we're only adding basic ascii 22:19
So it really seems like binary cleanliness would solve this issue
NotFound There is no such thing as a mount encoding.
rurban in user-land there's a different world
not?
NotFound rurban: you can throw any byte you want in a ext2 filesystem name, except a few forbidden 22:20
rurban so it's 1:1
Infinoid That's not because ext2 handles them properly, it's just that it doesn't care and just handles them as binary
rurban only NFS has some translations defined AFAIK
Infinoid vfat and ntfs do too, but who uses those
rurban so we shoudl treat them as binary also
Infinoid I think that's the sanest approach 22:21
NotFound It doesn't care how you interpret it. But if you try to interprte in terms of some encoding without exceptions, you have to care.
rurban so the only problem is the GetShortPathName() hack on windows to get paths without spaces
maybe this broke the chinese path 22:22
Infinoid I'd be curious what it returns for chinese paths
dalek rrot: r36894 | cotto++ | trunk/src/pmc/string.pmc:
[PMC] convert String PMC to use ATTRs
Infinoid If it asciifies it somehow, that works around the issue
rurban Infinoid: does this need a PBC_COMPAT change? I also have to add something there, which I forgot 22:23
sorry, it was cotto
NotFound Maybe the faster solution for windows is take the name in utf16 with using the unicode variants of the functions and convert it to utf8 22:24
rurban yes, use the wide-api
I'll try that out 22:25
cotto ?
rurban does removing destroy need a PBC_COMPAT change? I also have to add something there, which I forgot 22:26
22:26 slavorg joined
rurban just did, now you can. 22:27
cotto rurban, my changes should mess up pbc compat if that's what you were asking 22:29
dalek rrot: r36895 | rurban++ | trunk/PBC_COMPAT:
[core] bytecode 3.35 for adding bignum
 22:30
cotto s/should/shouldn't/ 22:32
weird typo 22:33
rurban thanks
22:45 iblechbot joined 22:52 Whiteknight joined 22:56 Limbic_Region joined
dalek rrot: r36896 | cotto++ | trunk:
[PMC] replace PMC_pmc_val with an ATTR in the NCI PMC
 22:59
rrot: r36897 | cotto++ | trunk/config/gen/makefiles/root.in:
[config] line length fix
 23:03
Coke_afk (messing up PBC compatibility) There's a topic to address in terms of our six-month cycle. 23:09
Coke I think not changing PBC_COMPAT for six months is going to be /tough/ 23:10
purl Hmm. No matches for that, Coke.
Limbic_Region pmichaud ping 23:12
23:15 TiMBuS joined 23:17 bacek_ joined
Limbic_Region idly wonders if pmichaud has been MIA, busy, or if he is just avoiding him 23:38
dalek kudo: a74de6a | pmichaud++ | docs/spectest-progress.csv:
First cut of spectest-progress.csv update, more to come.
 23:48
shorten dalek's url is at xrl.us/beguyw
pmichaud Limbic_Region: I've been busy, alas 23:49
I'll get a response to your email tonight, if you're still wanting one...?
Limbic_Region yes - still wanting one 23:50
unless of course you aren't interested
in which case you can just say so here :-)
TiMBuS is there any way to tell if rakudo is being run as a repl from action.pm? if the repl acted like non-strict perl they could be used over multiple lines 23:51
uh, 'they' being variables

Powered by Cro and the Raku® Programming Language.

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

Thank you!